SOAPのシステム開発は、6段階で進みます。最初は要件整理と選定・PoCです。続いて設計・開発とテストを行います。その後、稼働と定着へ進みます。
難しい接続はPoCで確かめ、契約と例外処理を早めに固めておくと、技術の課題と業務の課題を分けて管理しやすくなります。
▼全体ガイドの記事
・SOAPのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SOAPのシステム開発の全体像
SOAP開発は、XMLメッセージを使って業務システム同士が契約に沿って情報をやり取りできる状態を作ることです。
SOAP 1.2は複数の下位プロトコルで交換できる拡張可能なメッセージング基盤です（出典: W3C「SOAP Version 1.2 Part 1」、2007年）。こうした性質があるため、設計の対象は通信処理だけではありません。WSDL、XML Schema、業務ロジック、連携基盤、認証、監視まで含めて設計します。
WSDL・XSD・サービスを一つの契約として扱う考え方
連携の契約は、WSDLとXSDを中心に、業務機能、呼び出し側、連携基盤から成ります。
- WSDL：操作、入出力、データ型、接続先を定める文書。
- XSD：必須項目、形式、桁数、列挙値、名前空間の取り決め。
- 関連システム：業務ロジック、画面やバッチ、APIゲートウェイやESB、認証、監視など、連携に関わるもの。
WSDLからコードを生成する案件でも、実際のXMLやFaultが仕様書と一致するかは別に確認します。
クライアント型・サービス型・連携基盤型・共存型の4類型
開発範囲は、接続を追加するのか、連携仕様を標準化するのか、既存資産を移行するのかで変わります。
- クライアント型：既存WSDLを使い、相手のサービスを呼び出します。
- サービス型：自社の業務機能をSOAPサービスとして公開します。
- 連携基盤型：ESB・EAI・APIゲートウェイで複数システムを束ねる形。
- 共存型：既存SOAPを維持しながら、RESTなどへ段階的に移行する形。
型を最初に決めておくと、開発会社へ依頼する範囲が明確になります。
開発前に決める業務上の成功条件
接続が動くかだけでは、障害復旧や二重登録の防止までは確かめられません。そこで、判定条件は連携の品質から監査までを含めて決めておきます。
- 注文連携の品質：送信成功率、応答時間、再送可能なエラーの復旧時間の数値または判定条件。
- 処理状況：連携処理の状況を照会できること。
- ログ管理：個人情報や決済情報を扱う場合は、本文をログに残さないこと。
- 追跡と監査：追跡できる担当者の権限と、監査用の保存期間の定め。
SOAPのシステム開発の進め方と6フェーズ
SOAP開発は6段階で進みます。各フェーズでは、成果物と判断基準を先に定め、次へ進む条件を発注側と開発会社で合意しておきます。
WSDLや証明書の問題は後から判明することがあり、その場合はコードだけでなく試験計画や運用手順も見直すことがあります。
1. 要件整理と、連携対象・品質条件の台帳
まず、業務データをどのシステム間で、いつ、どの頻度で渡すかを発注側と開発会社で整理します。成果物は、連携一覧と項目マッピングを中心に、業務フロー、課題一覧、受入基準を揃えます。
- 契約と接続：WSDL・XSD、SOAP 1.1または1.2、SOAPAction、名前空間、エンドポイントを確認します。
- 認証とデータ：認証方式、証明書の発行者と有効期限、操作、データ項目、最大サイズを整理します。
- 負荷と環境：ピーク時の件数、正常系・異常系XML、Fault例、既存ログ、接続先のテスト環境を集めます。
- 品質条件：応答時間、同時実行数、タイムアウト、再送回数、冪等性キー、可用性の取り決め。
非機能要件には、バックアップ、ログ保存期間、障害通知先も含めます。さらに、Fault発生時に誰が何分以内に復旧するかを決め、それをもって要件整理を完了とします。
2. 選定と、最も難しい接続からのPoC
方式は、既存SOAPの保守と新規サービスを中心に、連携基盤やRESTを前段に置く方法から選びます。自社の要件と既存環境に合うかを比べて決めます。
- パッケージやクラウド：短期間で標準機能を使えますが、特殊な署名や細かなXML変換に制約が出る場合があります。
- スクラッチ開発：柔軟ですが、SOAP 1.1・1.2、WSDL、WS-Security、証明書、障害対応の経験が必要です。
選定後は、難易度の高い1〜3本の連携でPoCを行います。業務データは使わず、接続先のテスト環境で実際に疎通させます。
PoCでは、データの形式（名前空間、配列、日付・文字コード）、通信（SOAPAction、署名・暗号化、証明書交換）、障害時の動き（Fault、タイムアウト、重複送信）を確かめます。
PoCの合格条件には、正常応答に加えて、認証失敗や相手先停止を検知し、再送または手動復旧へつなげられることも含めます。
3. 設計・開発での契約と例外処理の確定
設計では、まずWSDL・XSDの変更管理を発注側と開発会社で決めます。そのうえで、SOAPバージョン、Content-Type、SOAPAction、名前空間、Headerの項目を、接続先と合意する契約の中身として固めます。さらに、署名・暗号化の範囲、エラーコード、データ変換も確定します。
サービス側のWSDLは、利用者が解釈できる契約にしておきます。また、後方互換性を壊す変更と、追加で対応できる変更を分けて扱います。
クライアント側でも、受け取ったWSDLと実装の不一致は課題一覧に残します。WSDLをそのまま信頼せず、確かめながら進めることが大切です。
実装では、業務処理と通信処理を分けて作ります。Faultは、入力不備、認証失敗、一時障害、業務ルール違反の4種類に分類します。
- 再送：一時障害だけを対象にし、リクエストIDや冪等性キーで二重登録・二重決済を防ぎます。
- WS-Security：署名・暗号化の対象、Timestampの許容時間、証明書の保管場所と更新担当の取り決め。
WS-Securityの設定は、コードだけでなく運用設計書にも記載します。関連仕様として、OASIS仕様にはSOAPメッセージセキュリティ、UsernameToken、X.509証明書トークンなどのプロファイルがあります（出典: OASIS「Web Services Security: SOAP Message Security 1.0」、2004年）。
4. 正常系より異常系を重視したテスト
試験は、単体、契約、結合の順で行います。そのあとに、負荷、セキュリティ、障害復旧、受入の試験を重ねます。利用可能な時間帯や相手先のタイムアウトは、結合試験で確かめます。
- 単体・契約：XML項目の変換、Fault分類、WSDL・XSDどおりの要求・応答を確かめます。
- 異常入力：必須項目の欠落、型違い、想定外の名前空間を試します。
- 接続障害：期限切れ証明書、署名不一致、認証失敗、相手先停止、応答遅延を確認します。
- 再送と切断：同じ要求の再送や通信途中の切断が起きた場合の動作。
XMLを受け付ける製品では入力が攻撃面になり得るため、XMLパーサーで外部実体参照を悪用されるXXEにも注意します（出典: IPA/JVN「ProselfにおけるXML外部実体参照（XXE）に関する脆弱性」、2023年）。
5. 稼働時の切り替えと切り戻しの設計
稼働時は、本番環境の準備、切替方法、移行確認、切り戻し条件を整えます。
- 本番準備：エンドポイント、ネットワーク許可、DNS、証明書、秘密鍵を確認します。監視通知、バックアップ、担当者連絡網も含めます。
- 切り替え：業務を止められない場合は、旧SOAPとの並行稼働、段階リリース、時間限定の切替を選べます。
- RESTへの移行：旧・新サービスの処理結果を比べ、利用者ごとの状況を管理します。
- 切り戻し：条件を事前に定め、障害時に現場の判断だけへ依存しないようにします。
切り替え手順には、開始条件と実施者、レスポンス確認、業務データ照合、中止条件を記します。
AWSは、互換層を介して新REST APIへ段階移行する方法を案内しています。その流れでは、全利用者の移行後に旧サービスを停止します（出典: AWS Prescriptive Guidance「SOAP-based ASP.NET web services」、参照日: 2026年8月）。
6. 定着時の監視・保守・変更管理の運用への落とし込み
定着では、監視と情報保護を中心に、運用引き継ぎ、変更管理、定期的な振り返りを運用に組み込みます。
- 監視：HTTPステータス、操作名、相関ID、処理時間を追います。加えて、Fault分類、再送回数、業務処理の状態も見ます。
- 情報保護：個人情報や決済情報をログに残さないようにし、マスキング、アクセス権、保存期間、削除手順を定めます。
- 運用引き継ぎ：担当者が状況を把握し、安全な復旧方法を選べる状態。
- 変更と改善：変更資産の管理と、運用状況の定期的な振り返り。
証明書更新、WSDL変更の影響調査、相手先保守、障害の一次切り分けについて、手順書と連絡先を整えておきます。
開発会社がいなくても、担当者が監視アラートを受けてFaultの種類を判定できる状態にします。再送または手動処理を安全に選べることが、定着の基準です。
WSDL・XSD、ソース・テストコード、インフラ設定、証明書記録は、一つの場所にまとめます。変更時は、契約テストを自動で実行します。
1か月、3か月、6か月後に、失敗率、復旧時間、手作業、問い合わせ件数を振り返ります。
SOAPのシステム開発の費用相場
SOAP開発に公定価格はないため、既存資産や連携本数、XML変換、認証、試験、運用範囲を分けて考えると、企画段階の予算を組みやすくなります。
SIA株式会社の2026年7月資料では、一般開発相場は小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上です。人月単価は60万〜200万円程度です（出典: SIA株式会社「システム開発の費用・相場【2026年版】」、2026年）。
以下の金額は、この一般相場とリサーチノートの業務システム事例に基づく企画用の推定です。契約金額を断定するものではありません。
既存WSDLを使う単一クライアントの費用目安
接続先が1つで、WSDL・XSD・XML例が揃い、業務処理が単純なら、初期費用100万〜300万円程度が企画の目安です。
範囲は、クライアント実装、基本的なデータ対応、HTTPSや基本認証または証明書設定、正常系と代表的な異常系の試験です。
費用は、画面・バッチ改修、DB更新、監視通知、手動復旧の手順書を含めると、同じ1接続でも上限を超える可能性があります。
2〜5システムの連携アダプターの費用目安
2〜5システムを接続し、XML変換やAPIゲートウェイ、ESB連携まで整える場合は、300万〜800万円程度が目安です。加えて、再送と権限管理も整えます。さらに、複数環境と監視も対象になります。
本数が増えるほど、項目の差分や組み合わせ、相手先ごとのタイムアウト、保守時間が増えます。さらに、社外との試験調整では待ち時間も見込みます。
SOAPサービスの新規構築の費用目安
サービス側を新設し、WSDL・XSD、業務ロジック、DBを用意します。そこへ複数クライアント、認証、監視、負荷試験まで含める場合は、500万〜1,500万円程度が目安です。
操作数が多いときや、複数企業へ公開するとき、トランザクションや冪等性を厳密に扱うときは、費用が増えます。また、停止できない業務を扱う場合にも費用は増えます。
SOAP 1.1・1.2の両対応、既存利用者との互換性、長期保守用ドキュメントは、見積もりで別の項目として確認します。
REST併設やクラウド移行の費用目安
SOAPを残したままAPIゲートウェイやFacadeを置き、RESTを併用する案件があります。さらに、クラウド・データ移行と段階リリースまで行うと、1,000万〜3,000万円以上になることがあります。
特に、利用者の多い基幹系、複数ベンダーが関わる金融・行政系、災害対策や24時間運用が必要な案件では、規模が大きくなります。
AWSの移行ガイダンスやIBMのAPI Connectの公式資料にも、既存SOAPを残しながらRESTプロキシーや段階移行を組み合わせる選択肢があります。費用は、対象、可用性、運用体制によって変わります。
保守費・基盤費・証明書更新費の別途見積もり
初期費用とは別に発生する費用も、項目ごとに見積もります。
- 基盤費：クラウドやサーバーの利用料、APIゲートウェイや連携基盤のライセンス。
- 運用費：監視、バックアップ、ログ保管にかかる費用。
- 保守・更新費：証明書更新、脆弱性対応、仕様変更への対応費。
- 費用区分：月額・年額の固定費と、仕様変更などの都度費用に分けます。
年間保守は、企画上の仮置きとして初期開発費の15〜25％程度を置くことがあります。金額は、24時間365日の監視・一次対応か、平日日中の問い合わせ対応かによって異なります。
SOAPのシステム開発の見積もりを取る際のポイント
見積もりは、「連携一式」のような総額だけの提示では、安い理由も高い理由も読み取れません。そこで、工程と前提を分け、見積もり後の追加費用につながりやすい条件も確認します。
要件定義、PoC、設計、実装、各種試験の金額を分けて比べます。環境構築、移行、運用引き継ぎ、保守の金額も、同じように分けて比べます。加えて、WSDLの品質や試験環境、証明書とネットワークの責任分界も確認します。
見積もり依頼時に渡す資料
開発会社へ渡す資料は、接続条件と業務処理の両方が分かるように揃えます。
- 仕様資料：WSDL・XSD、正常系・異常系XML、SOAPバージョン、SOAPAction、認証方式を含めます。
- 業務資料：接続先、業務フロー、既存画面・バッチ、データ対応表、エラー時の対応。
- 運用条件：証明書交換、ネットワーク制約、想定件数、ピーク時間帯を伝えます。
資料に不明点がある場合は、資料の収集と仕様の復元を要件定義の見積もりに含めるよう、開発会社へ依頼します。
必須要件と希望要件は分けて示します。必須要件には、連携対象、処理の正確性、認証、個人情報保護を置き、監査ログ、復旧時間、受入試験も加えます。
希望要件には、将来のREST公開、管理画面、追加分析、他システムへの展開などを置きます。また、最小構成と二次開発の範囲を決めておくと、提案を比べやすくなります。
複数社の同一前提での比較と担当者の実績確認
相見積もりでは、どの会社にも同一の仕様、接続本数、試験範囲、保守条件を渡します。そのうえで、要件定義、PoC、実装、試験、移行、月額の費用を分けて比べます。
- 技術経験：SOAP 1.1・1.2、WSDL・XSD、WS-Security、X.509証明書、Fault設計の経験。
- 業務経験：EAI・EDI、基幹システム、レガシー移行の実績を確認します。
- 提案内容：類似案件の規模、担当範囲、障害体制、成果物の引き渡し条件を見ます。
会社名や製品名だけでなく、実際に設計・試験・運用を担うメンバーを確認します。また、WSDL変更、証明書更新、相手先障害の担当者にも質問します。
クラウドやAPI管理製品を使う場合は、SOAPプロキシー、RESTからSOAPへの変換、データマッピング、自動テストをPoCで確認します。
見積書と契約書に反映すべき契約・セキュリティ・責任分界
契約と見積もりでは、成果物、保守の責任分界、権利、セキュリティ対策を具体的に決めます。
- 成果物と権利：納品物の範囲と権利関係を契約に明記します。
- 保守の責任：相手先の仕様変更、証明書切れ、脆弱性、OS・ミドルウェア更新、別ベンダーへの保守移管について、誰が担うかの取り決め。
- 技術対策：通信、XML、ログに必要なセキュリティ対策を定めます。
- 個人情報と受入：個人情報保護委員会の指針に沿い、アクセス制御、識別・認証、不正アクセス対策、取扱状況の記録を要件化します。
個人情報に関する対策は、受入基準で確認できる形にします。
納品範囲には、WSDLとXSDを含めます。加えて、ソース・テストコードも対象です。さらに、IaC、設計書、運用手順書も含めます。
委託しただけでは、著作権やソースの引き渡しが希望どおりになるとは限りません。そのため、内製化やベンダー変更を考えるときは、RFPと契約書に明記します。
技術対策には、TLSと署名・暗号化を含めます。Timestampと、証明書や秘密鍵の保管と更新も対策に入れます。鍵のローテーションも対象です。さらに、XML外部実体参照の無効化とXMLサイズ制限も対策に入れます。
署名対象の固定、リプレイ対策、ログのマスキング、脆弱性診断も、対象に含めます。
安すぎる見積もりで確認する対象外の工程
極端に安い見積もりでは、工程や運用の対象範囲を確認します。
- 開発・試験：要件定義、接続調整、異常系テストが含まれるかを見ます。
- 稼働・保守：証明書更新、監視、移行、運用引き継ぎの有無を確認します。
- 総費用：初期費用が低くても、運用費や追加改修費が高い場合があります。3年間の総費用で比べます。
高額な一括提案でも、予算内に収める方法を説明できなければ、実行計画としては不十分です。
リスクを抑えるには、難しい接続のPoC、最小限の業務範囲、契約テスト、自動監視を優先します。
WSDLとの差分、試験環境の日程、証明書更新の担当、再送条件、切り戻し期限が未確定なら、予備費と日程の余裕を見込みます。そのうえで、条件の確定後に本開発へ進むかを判断します。
SOAPのシステム開発に関するよくある質問
SOAP開発では、技術の新旧、WSDLからの接続、REST移行がよく問われます。
既存利用者と業務上の契約を確認したうえで、通信方式だけでなく、セキュリティ、障害復旧、保守も含めて判断します。
SOAPは古い技術なので新規開発では使わないほうがよいですか？
取引先や基幹システムがWSDL、WS-Security、厳格なXML契約を前提にしている場合は、SOAPを維持することで停止や再連携のリスクを抑えられます。そのため、新規開発でも一律に避ける必要はありません。
ブラウザやモバイル向けの軽量な新規APIでは、RESTやJSONも比べたうえで、利用者が扱いやすい方式を選びます。
WSDLがあればSOAP連携はすぐに開発できますか？
WSDLがあっても、すぐ本番稼働できるとは限りません。まず、SOAP 1.1・1.2の版とSOAPActionを確認します。次に、名前空間と実際のXMLを照らし合わせます。さらに、認証・証明書とFaultも確かめる必要があります。
加えて、タイムアウトやテスト用エンドポイントも必要です。仕様書と実装に差がある場合は、PoCで通信を確かめてから本開発へ進みます。
1本のSOAP連携にかかる費用と期間はどれくらいですか？
既存WSDLを使う単一クライアントで要件とテスト環境が整う場合、初期費用100万〜300万円程度、期間1〜2か月程度が企画用の目安です。
SOAP固有の定価はなく、費用は、画面改修、DB更新、証明書、相手先調整を含めるかで変わります。異常系試験、監視、運用手順書を含めるかでも変わります。
既存SOAPをRESTへ移行するときは何から始めますか？
まず、利用者、操作、データ契約、認証、SLAを一覧にします。さらに、依存関係や停止できない業務も洗い出します。そのうえで、旧SOAPを残す互換層やAPIゲートウェイの利用を検討します。
次に、難しい操作からREST変換をPoCで確かめ、利用者単位で段階移行します。旧SOAPを停止するのは、全利用者の切り替えと切り戻し条件を確認してからです。
SOAPのシステム開発の進め方まとめ
SOAP開発は6段階で進み、フェーズごとに成果物と判断基準を決めます。進め方の全体では、WSDLやXSDに加えて、XML、認証、Fault、再送を計画に入れます。さらに、監視、証明書、保守の責任分界も同じ計画にまとめます。
費用は、単一接続の100万〜300万円程度から、複数連携、新規サービス、REST併設やクラウド移行へと広がります。比べるときは、案件の型と対象工程をそろえて見ます。
成功の要点：契約・異常系・運用の先決め
まず、SOAPが必要な業務と、RESTなども比べられる業務を分けます。連携台帳には、SOAP版、WSDL、XSD、操作、認証を残します。さらに、証明書、データ量、Fault、再送、監視も書き込みます。
難しい接続はPoCで先に確かめます。発注時は、開発費に加えて、試験、移行、保守、仕様変更、証明書更新、成果物の引き渡しを、同じ条件で確認します。
最初の一歩：連携台帳と見積もり前提の作成
見積もりの前提を固めるには、情報を集めて台帳にまとめ、要件と移行計画を整えます。
- 既存WSDL・XSD、XML例、接続先、利用者を集めます。認証、証明書期限、障害時の業務対応も加えて、不明点は課題として記録します。
- 台帳を使って要件整理とPoCの範囲を開発会社へ示し、曖昧な一式見積もりを避けます。
- SOAPを維持する場合もRESTへ移る場合も、段階的な計画と自社で運用できる体制を、開発会社と一緒に設計します。
▼全体ガイドの記事
・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を創業。