SOAPのシステム開発会社は、WSDLやXMLを扱えるかだけでなく、基幹連携・認証・監視・移行まで設計できるかで比べます。
SOAPは古い通信方式ですが、対応できる会社であればどこでもよいとは限りません。既存資産を残すか、RESTと併用するかで、必要な技術力と開発体制が変わります。
▼全体ガイドの記事
・SOAPのシステム開発の完全ガイド
- SOAPの基幹連携・認証・監視・移行
- 6社の技術力と開発体制の比較
- 選定時の確認事項と費用の考え方
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SOAPのシステム開発でパートナー選びが重要な理由
画面やデータベースを作る開発と違い、SOAPのシステムは、送信側と受信側を連携基盤と認証基盤を介して正しくつなぎ、業務データを受け渡す必要があります。
SOAP 1.1と1.2では、Envelopeの名前空間やHTTPの扱いが異なります。さらに、WSDLやXSDの定義と実際のXMLメッセージが一致しないケースもあります。そのため、会社の知名度だけでなく、契約と運用を含めて比べることが大切です。
WSDL契約と相互運用性を確認できる会社
WSDLがサービスの操作とデータ型を、XSDが要素の構造や必須項目を定めます。開発会社には、WSDLからクライアントを生成できるだけでなく、相手先と細部まで取り決める力が求められます。
特に、名前空間や配列、日付の扱いは、相手先と必ず合意しておく必要があります。文字コード、SOAPAction、Faultの返し方も取り決めの対象です。
提案時は、作った画面の数より、異なる製品や言語のシステムを接続した工程や、疎通試験、障害時の切り分け方法を尋ねてください。
セキュリティと運用まで設計できる力
SOAPのヘッダーには、認証情報や署名が入ることがあります。また、暗号化の情報やTimestamp、相関IDを載せる場合もあります。
TLSを使うだけでなく、WS-Securityのプロファイルや証明書の期限管理まで確認する必要があります。さらに、リプレイ攻撃への対策と、XML外部実体参照を無効にするパーサ設定、機密情報をマスクしたログ設計も見ておきます。
OASISのWS-Security 1.0では、UsernameTokenとX.509証明書のプロファイルが整理されています（出典: OASIS Web Services Security v1.0、2004年）。開発後の証明書更新や相手先の仕様変更は、どこまでを誰が受け持つかを発注前に決めておく必要があります。
株式会社ripla｜コンサルから開発まで一気通貫で支援
riplaは、コンサルティングから開発まで一気通貫で支援できる企業です。IT事業会社として社内DXを推進してきた経験を生かし、ビジネスへの成果創出とシステムの定着支援に強みがあります。
営業や顧客、生産、販売管理など、幅広い基幹システムの構築・導入実績があります。また、企業の業務要件に合わせて柔軟に対応できる体制を整えています。
業務要件と連携仕様を一緒に整理できる強み
SOAPの開発で最初から技術仕様だけを見ると、どの業務を、どのタイミングで連携させるのかが曖昧になりがちです。
riplaでは、まず業務の流れや現場の運用を確認し、必要な機能と連携範囲を整理します。そのうえで、企画・要件定義から設計、開発、導入までつなげて検討できます。
既存のWSDLを使うクライアント開発や、複数システムの業務連携、画面やデータベースを含む基幹システムの見直しなど、目的に応じて必要な範囲を切り分けられます。
段階的な改善を目指す企業向けの進め方
既存SOAPをすぐに全廃せず、利用者を止めないまま連携の状況を把握し、優先度の高い部分から改善したい企業に適しています。
流れとしては、まずWSDLや接続先を台帳にまとめ、認証方式と障害履歴も加えます。次に、1本から3本の難しいインターフェースでPoCを行い、その後にAPIゲートウェイやRESTの併用を検討します。
問い合わせ時は、SOAP 1.1か1.2か、WSDLの有無、WS-Securityの方式を伝えます。さらに、連携本数や既存利用者、希望時期、クラウド移行の意向も伝えると、相談内容が具体化します。
NEC｜基幹系・公共系の高信頼な連携基盤に強み
NECは、公共や金融を含む大規模システムや、サービス実行基盤を重視する企業にとって候補になる会社です。
NECの公式WebOTX導入事例では、小規模システムから基幹系システムまで幅広い事例が紹介されています。そのため、サービス実行基盤やESBを含めた構成を検討しやすいのが特徴です。
SOAPの具体的な開発範囲は案件や担当チームによって変わるため、現行の製品サポートと、WSDL・WS-Securityへの対応経験を確認してから依頼します。
高可用性や運用管理を含む基盤設計の相談
複数の業務システムをESBやアプリケーション基盤でつなぎ、障害監視や処理の再実行を整備したい場合に向いています。さらに、アクセス制御や監査ログまで含めて検討しやすい会社です。
NECの公開事例には、WebOTXを中核に、約30万件を超える児童手当の支給に関わる大量バッチを安定稼働させた横浜市の事例もあります（出典: NEC「WebOTX導入事例」、公開事例）。
ただし、この事例はSOAP案件そのものではありません。大量処理や公共系の運用要件を相談する際の参考にはなります。
現行製品と担当体制の確認
大規模SIでは、提案会社の技術資料だけでなく、実際にSOAPを担当するチームの経験を確かめる必要があります。
SOAP 1.1と1.2が混在する場合の切り分けや、証明書の更新について尋ねます。相手先の障害時の連絡経路、24時間運用の有無、設計書とソースコードの引き渡し範囲も確認します。
公共・金融・基幹系で高い可用性が必要なら、PoCの段階から異常系と復旧手順を試験項目に入れてもらいます。
富士通｜既存資産の移行と大規模業務基盤の検討
長年使ってきた業務システムやアプリケーション基盤を、段階的に移行したい企業には、富士通も候補になります。
富士通の公式Interstage関連資料には、旧バージョンで開発したSOAPサービスの資源を移行する手順が公開されています。そのため、既存資産を調べながら刷新する際の論点を整理しやすくなっています。
資料が古い場合もあるため、現行製品や保守期限、移行先のクラウドやアプリケーションサーバが提案対象に入るかを確認します。
レガシーSOAPを止めずに移行する計画づくり
古いSOAPサービスは、仕様書が不足していたり、実装とWSDLがずれていたりします。
富士通のように既存の企業向け基盤や移行資料を持つ会社へ相談するなら、まず既存資産を洗い出してもらいます。接続先ごとの依存関係と利用者数を調べ、証明書やバッチ、障害履歴も確認してもらいます。
そのうえで、現行SOAPを残す期間と新基盤へ載せ替える範囲を決めます。RESTを前段に置く範囲や、切り戻しの方法も段階的に設計します。
移行対象と保守期限を分けた見積もり
「クラウドへ移行する」と書かれた見積もりでは、費用と期間を比べにくくなります。
SOAPサービスとデータベースの移行を、項目別に見積もってもらいます。ネットワークや証明書の再設定、性能試験、利用者の切り替え、旧環境の保管も、別の項目として出してもらいます。
発注側は、WSDL変更が起きたときにどこまでを誰が受け持つかや、移行後の障害対応、別ベンダーへ保守を移す場合に何を引き渡すかを、契約書に書いておきます。
日本IBM｜SOAPとRESTの共存とAPI管理
既存のSOAPサービスを残しつつ、API管理やREST連携を加えたい企業には、日本IBMが候補になります。
IBM API Connectの公式情報では、WSDLからSOAPプロキシーを作成する機能や、既存WSDLをもとにRESTからSOAPへ接続する機能が案内されています。
SOAPを一度に廃止せず、外部には新しいAPIを公開して、内部や既存利用者にはSOAPを残す構成を考える場合、製品と開発支援の両方を相談できます。
APIプロキシーで既存資産を段階的に公開する方法
たとえば、業務システム内のSOAPサービスをAPI管理基盤の背後に置き、利用者の認証・流量制御・アクセスログを集約する構成が考えられます。
新しい利用者はREST形式で接続し、既存のクライアントはSOAPのまま使い続けます。これにより、全社一斉の切り替えを避けられます。
AWSの移行ガイダンスでも、SOAPベースのサービスとRESTベースのサービスを分類し、認証・認可の方法を先に整理することが示されています（出典: AWS Prescriptive Guidance、2026年閲覧）。
製品機能と個別開発の境界
API管理製品を入れても、XML変換や業務ルールまで自動で解決するとは限りません。
WSDLの読み込みやSOAPAction、複雑な名前空間は、個別の設計と試験が必要になる場合があります。さらに、署名・暗号化、Faultの変換、冪等性、バックエンドのトランザクションも、確認が必要になることがあります。
見積もりでは、製品ライセンスと基盤構築を分けて提示してもらいます。インターフェース開発やセキュリティ設定、負荷試験、運用設計は、それぞれ区切って出してもらいます。
SCSK｜EAI・EDIを含む複数システム連携に強み
SCSKは、SOAP単体ではなく、ERPやEDI、EAI、ファイル連携などをまとめてつなぎたい企業の候補です。
公式サイトでは、SOAやEAIが広く知られる前から20年以上にわたってシステム連携に携わってきたと紹介されています。1,000本を超えるインターフェースや、ミッションクリティカルな基幹系との連携実績もあります。
SCSKは、ASTERIA Warp、DataSpider、HULFT、ACMSなどの選択肢があり、既存資産を生かした連携基盤を検討しやすい会社です。
PoCから運用引き継ぎまでの一括構築
SCSKは公式の一括構築サービスとして、PoC支援から要件定義、基本・運用設計まで案内しています。さらに、インターフェース開発、各種テスト、本番稼働支援までの工程も示されています。
複雑な連携を先にプロトタイプで確かめ、標準化したフローを横に展開する進め方は、SOAPの接続先が多い案件と相性がよいです。
公開事例のi-PROでは、カットオーバー時に214本の連携インターフェースを4か月で構築したと紹介されています（出典: SCSK「システム連携 SCSKの『つなぐ』ソリューション」、公開事例）。
連携本数だけでなくデータ変換と障害運用の確認
SOAP案件では、インターフェースの本数が同じでも難易度は変わります。XMLの変換ルールや相手先ごとの認証の違いに加え、リアルタイム処理かバッチ処理か、再送と重複排除の有無も影響するためです。
SCSKへ相談する場合は、WSDLやXMLサンプルだけでなく、1日あたりの件数やピーク時間を提示します。さらに、タイムアウト、再送条件、機密項目、運用担当者の体制も示しておきます。
EAIやEDIが混在する企業では、接続方式を整理してから依頼すると、過剰な個別開発を避けやすくなります。
TISI株式会社｜EDIとAPIをつなぐ企業間連携を支援
既存のEDIや企業間連携を維持しながら、APIを使った接続へ広げたい企業には、TISI株式会社が候補になります。
公式のAPIプラットフォームサービスでは、EDIとAPIの融合や企業間連携のアセスメントを案内しています。さらに、コンサルティングと、業界標準に準拠したセキュリティ基盤の構築支援も含まれています。
SOAPを単独の技術として扱わず、取引先や社内システムとの接続方式を全体で整理したい場合に、相談しやすい領域です。
企業間データ連携の将来像から逆算する進め方
取引先からSOAP接続を求められる一方で、今後はAPIやクラウドサービスも増える企業では、接続方式を一社ごとに場当たり的に追加すると管理が複雑になります。
TISIの公開情報にあるとおり、API利用アプリとAPIサービスを適切につなぐ共通機能や、セキュリティ、データ流通のルールを整えることが求められます。
新しい接続先だけをAPI化し、SOAPをバックエンドに残すのか、既存EDIを含めて連携基盤を再設計するのかを、事業計画に照らして検討できます。
現行接続の保守責任と新規APIの範囲の分担
企業間連携では、自社の開発会社だけでなく、取引先、通信事業者、EDIサービス事業者など複数の関係者が関わります。
TISIへ依頼する際は、各接続の契約主体と、相手先の仕様変更を受ける窓口を整理します。さらに、障害時の一次対応や証明書の更新、APIのバージョン管理も整理しておきます。
なお、サービス名称や契約主体は時期によって変わる可能性があります。そのため、2026年時点の提供範囲と担当会社を、見積もりの時点で確認します。
SOAPのシステム開発会社を選ぶ3つのポイント
6社を比べるときは、会社サイトにSOAPという言葉があるかどうかだけで判断しないことが大切です。
発注側は、自社の案件が「既存WSDLを使う接続」「複数システムの連携」「SOAPサービスの新規構築」「REST併設・クラウド移行」のどれに近いかを分け、必要な技術と運用を確認します。
初回の相談では、実績、見積もり、障害対応と契約の3点について質問を組み立てます。
SOAP 1.1・1.2とWSDLの実績の確認
まず、SOAP 1.1と1.2の両方に対応した経験や、WSDL・XSDの設計と変更管理を確認します。さらに、SOAPAction、Fault、証明書認証、WS-Securityの実装経験も見ておきます。
実績は、担当した工程や扱ったインターフェースの本数、接続先の試験環境がなかった場合の検証方法まで聞きます。
公開事例と自社の案件は一致しないため、最終的には担当チームの経歴を確かめます。
連携本数と試験範囲ごとに分けた費用と期間
2026年の一般的なシステム開発の相場は、小規模で100万〜300万円、中規模で500万〜1,000万円、大規模で1,000万円から数千万円以上とされています。人月単価は60万〜200万円程度とされています（出典: SIA株式会社「システム開発の費用・相場 2026年版」）。
SOAPに固有の公定価格はありません。ただし、企画段階の推定として、既存WSDLを使う単一接続なら100万〜300万円、2〜5システムの連携アダプターなら300万〜800万円を置けます。SOAPサービスの新規構築なら500万〜1,500万円、クラウド移行やREST併設なら1,000万〜3,000万円以上が目安になります。
見積もりでは、要件定義や設計、XML変換を分けてもらいます。さらに、セキュリティやテスト、運用も項目ごとに示してもらいます。
障害対応と契約上の責任の範囲
SOAPでは、接続できない原因が自社と相手先のどちらにあるかが分かりにくいことがあります。ネットワークや証明書、XML変換、業務データも、原因になり得ます。
相関IDを使ったログやFaultの分類を、受入条件に含めます。さらに、再送の上限、重複登録を防ぐ冪等性キー、監視通知、手動復旧の手順も入れておきます。
また、WSDLやテストコード、IaC、証明書の管理責任を契約前に明文化します。ソースコードの引き渡しや、別会社への保守移管、年間保守費用の範囲も決めておきます。
よくある質問
SOAPのシステム開発会社を探す企業から寄せられやすい質問を、発注前の判断材料として取り上げます。SOAPを残すべきか、費用はどのくらいか、開発会社へ何を渡せばよいかが中心です。
SOAPのシステム開発では何を作るのですか？
SOAPのシステム開発では、既存WSDLを使うクライアントや、SOAPサービス、XML変換処理を作ります。さらに、APIゲートウェイやESB、認証・監視基盤、業務データベースを作る場合もあります。
WSDLを受け取って接続するだけの案件もあれば、相手先に公開するサービス側や、画面・業務ロジックまで含む案件もあります。
依頼する前に、「クライアント開発か、サービス開発か、基幹システム全体か」を切り分けておくことが大切です。
SOAPをRESTへ移行したほうがよいですか？
一律に移行する必要はありません。
新規の軽量な公開APIでは、RESTやJSONが適する場合があります。一方、取引先や基幹システムがSOAPを前提にしている場合は、既存利用者を止めずにSOAPを維持します。そのうえで、前段のAPIゲートウェイやFacadeにより、RESTを段階的に追加する方法が現実的です。
判断にあたっては、利用者や認証方式、データ契約を比べます。さらに、移行期限と運用費も見たうえで、全廃・共存・現状維持の3案から選びます。
開発会社への相談時に何を準備すればよいですか？
まず、WSDLやXSD、SOAP 1.1か1.2かの別を用意し、接続先とエンドポイント、認証方式、XMLの正常系・異常系サンプルもそろえます。連携本数や1日あたりの件数、ピーク時間、希望納期も伝えます。
既存の利用者やデータの機密度、ログ保存期間を伝えます。さらに、障害時の復旧目標、クラウド可否、保守担当者の体制も共有します。
資料が不足していても、まず現状調査や難しい1本のPoCから依頼すれば、追加調査の範囲を見積もりやすくなります。
まとめ
SOAPのシステム開発会社は、SOAPに対応できるかだけでなく、WSDL・XSDの契約管理やXML変換まで確かめて選びます。さらに、WS-Security、基幹システム連携、監視、障害復旧、将来のREST併用も確認します。
今回紹介した6社は、得意領域が異なります。一気通貫の相談や基幹・公共系の高信頼基盤、既存資産の移行に強い会社があります。加えて、API管理やEAI・EDI連携、企業間APIの整備を得意とする会社もあります。
まずWSDLと連携台帳の整理
最初の一歩は、WSDLだけでなく、実際のXMLサンプルや接続先を一覧にすることです。認証・証明書、Fault、処理件数、障害履歴も、同じ表にまとめます。
単一接続なら小規模の見積もりで済む可能性があります。一方で、接続先が増えたり、仕様が不明だったり、クラウド移行やREST併設が含まれたりすると、調査・試験・運用の工数が大きくなります。
複数社に同じ資料を渡し、要件定義、開発、試験、保守に分けて比べます。
実績と将来の移行方針をあわせた相談
既存SOAPを「古いから」という理由だけで急いで廃止すると、取引先や業務利用者への影響が大きくなります。
まず現状を一覧にし、維持・共存・段階移行のどれが自社に合うかを決めます。そのうえで、WSDL変更や証明書更新まで含めた運用体制を作ります。
SOAPの技術要件と業務のゴールを一緒に整理できる開発会社へ相談します。次に、PoCと分解見積もりを通じて、無理のない開発計画を立てます。
▼全体ガイドの記事
・SOAPのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。