SOAPのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

SOAPのシステム開発は、WSDLやXML Schemaで連携契約を固め、要件整理から定着まで6つのフェーズで段階的に進める方法が基本です。

SOAPのシステムを作るときは、単にXMLを送受信するプログラムを実装するだけでは不十分です。既存の基幹システムや外部サービスとの接続条件、SOAP 1.1・1.2の違い、認証、障害時の再送、監視、将来のREST移行まで先に整理しておく必要があります。本記事では、SOAPのシステム開発の進め方、やり方、流れ、工程、手順を、実務で使える判断基準とチェックポイントに分けて解説します。

▼全体ガイドの記事
・SOAPのシステム開発の完全ガイド

SOAPのシステム開発の全体像を理解します

SOAPのシステム開発とは、XMLで構造化されたメッセージを使い、業務システム同士が決められた契約に沿って情報を交換できる状態を作ることです。W3CのSOAP 1.2仕様は、複数の下位プロトコル上で交換できる拡張可能なメッセージング・フレームワークを定義しています（出典: W3C「SOAP Version 1.2 Part 1」、2007年）。したがって、対象は通信処理だけでなく、WSDL、XML Schema、業務ロジック、連携基盤、認証、監視まで広がります。

SOAP連携の中心にあるWSDLは、呼び出せる操作、入力と出力、データ型、接続先などを定義します。XSDは、必須項目、文字列や日付の形式、桁数、列挙値、名前空間を定めます。さらに、サービス側の業務ロジックとデータベース、呼び出し側の画面やバッチ、APIゲートウェイやESB、認証基盤、監視・ログ基盤が組み合わさって、実際の「SOAPのシステム」になります。WSDLを受け取ってコードを生成するだけの案件でも、実際に届くXMLやFaultが仕様書と一致するかを確認しなければなりません。

開発パターンは、既存WSDLを使って相手のサービスを呼び出すクライアント型、自社の業務機能をSOAPサービスとして公開するサービス型、複数システムをESB・EAI・APIゲートウェイで束ねる連携基盤型、既存SOAPを残したままRESTなどへ段階移行する共存型に分けられます。1本の接続を急いで追加するのか、全社の連携仕様を標準化するのか、レガシー資産を現代化するのかで、必要な体制と費用は変わります。最初にこの型を決めると、開発会社へ依頼する範囲が曖昧になりにくいです。

「SOAPで接続できること」だけを成功条件にすると、稼働後に業務が止まったときの復旧方法や、二重登録を防ぐ仕組みが抜けます。たとえば、注文連携なら送信成功率、応答時間、再送可能なエラーの復旧時間、処理状況を照会できることまで数値または判定条件にします。個人情報や決済情報を扱う場合は、本文をログに残さないこと、権限を持つ担当者だけが追跡できること、監査に必要な期間だけ保存することも要件に含めます。

SOAPのシステム開発の進め方を6フェーズで確認します

SOAPのシステム開発は、要件整理、選定・PoC、設計・開発、テスト、稼働、定着の6フェーズで進めると、技術課題と業務課題を分けて管理しやすくなります。特にSOAPでは、後からWSDLや証明書の問題が見つかると、実装済みのコードだけでなく試験計画や運用手順までやり直すことがあります。各フェーズの成果物と判断基準を先に置き、次へ進む条件を合意しておくことが重要です。

最初に、どの業務データを、どのシステムから、どのシステムへ、いつ、どの頻度で渡すのかを整理します。既存WSDL・XSD、SOAP 1.1または1.2、SOAPAction、名前空間、エンドポイント、認証方式、証明書の発行者と有効期限、利用する操作、データ項目、最大サイズ、ピーク時の件数を一覧にします。仕様書だけでなく、正常系と異常系の実XML、Faultのサンプル、既存ログ、接続先のテスト環境も収集します。

非機能要件では、レスポンスタイム、同時実行数、タイムアウト、再送回数、冪等性キー、可用性、バックアップ、ログ保存期間、障害通知の宛先を決めます。成果物は連携一覧、データ項目マッピング、業務フロー、課題一覧、受入基準です。「WSDLが存在する」「接続先が決まっている」だけでは要件整理の完了とはせず、Fault発生時に誰が何分以内に復旧するかまで決まっていることを完了条件にします。

方式選定では、既存SOAPを保守するのか、サービスを新設するのか、連携基盤を導入するのか、RESTを前段に置くのかを比較します。パッケージやクラウドのSOAPアダプターは短期間で標準機能を使える一方、特殊な署名や細かなXML変換で制約が出ることがあります。スクラッチ開発は柔軟ですが、担当者のSOAP 1.1・1.2、WSDL、WS-Security、証明書、障害対応の経験を見極めなければなりません。

選定後は、難易度の高い1〜3本の連携でPoCを実施します。名前空間、配列、日付・文字コード、SOAPAction、署名と暗号化、証明書交換、Fault、タイムアウト、重複送信を実際に検証し、接続先のテスト環境で業務データを使わずに疎通させます。PoCの合格条件は「正常応答が返る」だけでなく、認証失敗や相手先停止を検知し、再送または手動復旧へつなげられることです。

設計では、WSDL・XSDの変更管理、SOAPバージョン、Content-Type、SOAPAction、名前空間、Headerの項目、署名・暗号化の範囲、エラーコード、データ変換を確定します。サービス側を作る場合は、利用者が解釈できる契約としてWSDLを設計し、後方互換性を壊す変更と追加可能な変更を区別します。クライアント側を作る場合も、受け取ったWSDLをそのまま信じず、実装との不一致を課題一覧に残します。

実装では、業務処理と通信処理を分離し、Faultを入力不備、認証失敗、一時障害、業務ルール違反に分類します。一時障害だけを再送対象にし、二重登録や二重決済を防ぐために、リクエストIDや冪等性キーで同一処理を識別します。WS-Securityを使う場合は、署名対象、暗号化対象、Timestampの許容時間、証明書の保管場所と更新担当を、コードだけでなく運用設計書にも記載します。OASISのWS-Security仕様には、SOAPメッセージセキュリティ、UsernameToken、X.509証明書トークンなどのプロファイルがあります。出典はOASIS「Web Services Security: SOAP Message Security 1.0」（2004年）です。

テストは、単体テスト、契約テスト、結合テスト、負荷テスト、セキュリティテスト、障害復旧テスト、受入テストに分けます。単体テストではXMLの項目変換やFault分類を確認し、契約テストではWSDL・XSDどおりのリクエストとレスポンスになっているかを検証します。結合テストでは、実際の認証、ネットワーク、相手先のタイムアウト、利用可能な時間帯まで確認します。

異常系のチェックリストには、必須項目の欠落、型違い、想定外の名前空間、期限切れ証明書、署名不一致、認証失敗、相手先の停止、応答遅延、同じリクエストの再送、途中での通信切断を含めます。XMLを解析するパーサーでは、外部実体参照を悪用するXXEなどの脆弱性にも注意が必要です。IPAが公開したXXE脆弱性情報からも、XMLを受け付ける製品では入力の扱いが攻撃面になり得ることが分かります。出典はIPA/JVN「ProselfにおけるXML外部実体参照（XXE）に関する脆弱性」（2023年）です。

稼働前には、本番エンドポイント、ネットワーク許可、DNS、証明書、秘密鍵、監視通知、バックアップ、担当者連絡網を確認します。基幹業務を止められない場合は、旧SOAPを残した並行稼働、対象利用者を限定した段階リリース、時間帯を限定した切り替えなどを選びます。切り替え手順には、開始条件、実施者、確認するレスポンス、業務データの照合、異常時の中止条件を記載します。

既存SOAPの利用者を維持したままRESTへ移行する場合は、旧サービスと新サービスの処理結果を比較し、利用者ごとに切り替え状況を管理します。AWSの公式ガイダンスでも、旧SOAPの利用者を一度に変更せず、互換層を介して新REST APIへ段階的に移行し、全利用者の移行後に旧サービスを停止する方法が説明されています（出典: AWS Prescriptive Guidance「SOAP-based ASP.NET web services」、参照日: 2026年8月）。切り戻し条件を事前に定義すると、障害時に現場判断だけへ依存せずに済みます。

稼働後は、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年）。以下はこの一般相場とリサーチノートの業務システム事例をもとにしたSOAP連携案件の企画用推定であり、契約金額を断定するものではありません。

接続先が1つで、WSDL・XSD・XMLサンプルが整備され、業務処理も単純な場合は、初期費用100万〜300万円程度を企画用の目安にできます。想定範囲は、SOAPクライアントの実装、基本的なデータマッピング、HTTPSや基本認証または証明書の設定、正常系と代表的な異常系の試験です。画面やバッチの改修、データベース更新、監視通知、手動復旧の手順書まで含めると、同じ1接続でも上限を超える可能性があります。

2〜5システムをつなぎ、XML形式の変換、APIゲートウェイやESBへの接続、エラー時の再送、権限管理、開発・検証・本番の複数環境、監視まで整える場合は、300万〜800万円程度を企画用の目安にできます。連携本数が増えるほど、項目の差分、システム間の組み合わせ、相手先ごとのタイムアウト、メンテナンス時間が増えます。社外の接続先と試験日程を調整する必要がある場合は、開発会社の工数だけでなく、待ち時間と調整の負荷も見込むことが大切です。

サービス側を新しく作り、WSDL・XSDの設計、業務ロジック、データベース、複数のクライアント、認証、監視、負荷試験まで含める場合は、500万〜1,500万円程度を目安にできます。操作数が多い、複数企業へ公開する、トランザクションや冪等性を厳密に管理する、停止できない業務を扱うといった条件が重なるほど増額します。SOAP 1.1と1.2の両対応、既存利用者との後方互換性、長期保守用のドキュメントも見積書の項目として分けて確認します。

レガシーSOAPを残しながらAPIゲートウェイやFacadeを前段に置き、RESTとの併用、クラウド移行、データ移行、段階リリースまで行う案件は、1,000万〜3,000万円以上になることがあります。利用者が多い基幹系、複数ベンダーが関わる金融・行政系、災害対策や24時間運用まで必要な案件では、さらに大規模化します。AWSの移行ガイダンスやIBMのAPI Connectの公式資料でも、既存SOAPを残したままRESTプロキシーや段階移行を組み合わせる選択肢が示されていますが、実際の費用は移行対象と可用性、運用体制で変わります。

初期費用とは別に、クラウドやサーバーの利用料、APIゲートウェイや連携基盤のライセンス、監視、バックアップ、ログ保管、証明書更新、脆弱性対応、仕様変更対応が発生します。年間保守は初期開発費の15〜25％程度を企画上の仮置きにすることがありますが、24時間365日の監視・障害一次対応を含むか、平日日中の問い合わせだけかで金額は大きく異なります。月額・年額の固定費と、仕様変更などの都度費用を分けて確認します。

SOAPのシステム開発で見積もりを取る際のポイントを確認します

SOAP案件の見積もりは、「連携一式」という総額だけで比べると、安い理由も高い理由も分かりません。要件定義、PoC、設計、実装、各種試験、環境構築、移行、運用引き継ぎ、保守を分け、どの前提で金額が出ているかを確認します。特に既存WSDLの品質、相手先の試験環境、証明書やネットワークの責任分界は、見積もり後に追加費用が発生しやすい項目です。

開発会社へ渡す資料には、WSDL・XSDだけでなく、正常系と異常系のXMLサンプル、接続先一覧、業務フロー、既存画面やバッチの処理、データ項目の対応表、SOAPバージョン、SOAPAction、認証方式、証明書交換条件、ネットワーク制約、想定件数、ピーク時間帯、エラー時の業務対応を含めます。既存資料に不明点がある場合は、資料の収集と仕様復元を要件定義の見積もりに含めるよう依頼します。

次に、必須要件と希望要件を分けます。必須要件には、連携対象、処理の正確性、認証、個人情報の保護、監査ログ、復旧時間、受入試験を置き、希望要件には、将来のREST公開、管理画面、追加の分析、他システムへの横展開などを置きます。最初からすべてを盛り込むのではなく、業務を止めないために不可欠な最小構成を定め、二次開発へ回せる範囲を明確にすると、提案の比較がしやすくなります。

相見積もりでは、同じWSDL、同じ接続本数、同じ試験範囲、同じ保守条件を渡し、要件定義費、PoC費、実装費、試験費、移行費、月額費を分けて比較します。確認したい実績は、単に「Web APIの経験があるか」ではなく、SOAP 1.1・1.2、WSDL・XSD、WS-Security、X.509証明書、Fault設計、EAI・EDI、基幹システム、レガシー移行の経験です。提案書では、似た案件の規模、担当範囲、障害時の体制、成果物の引き渡し条件を確認します。

担当者の経験は、会社名や製品名だけでは判断できません。実際に設計・試験・運用を担当するメンバーが誰か、WSDL変更時の影響調査を誰が行うか、証明書更新や相手先障害の一次切り分けを誰が担うかを質問します。クラウドやAPI管理製品を使う場合も、WSDLのSOAPプロキシー、RESTからSOAPへの変換、データマッピング、テスト自動化が自社要件で可能かをPoCで確かめます。

契約では、WSDL、XSD、ソースコード、テストコード、IaC、設計書、運用手順書の納品範囲と権利関係を明記します。相手先の仕様変更、証明書期限切れ、脆弱性対応、OSやミドルウェアの更新、別ベンダーへの保守移管を誰が担うかも決めます。成果物の著作権やソースコードの引き渡しは、委託しただけで自動的に希望どおりになるとは限らないため、将来の内製化やベンダー変更を考える場合はRFPと契約書に具体化します。

セキュリティの見積もりには、TLS、メッセージ署名、暗号化、Timestamp、証明書と秘密鍵の保管、鍵のローテーション、XML外部実体参照の無効化、XMLサイズ制限、署名対象の固定、リプレイ攻撃対策、ログのマスキング、脆弱性診断を含めます。個人情報を扱う場合は、個人情報保護委員会のガイドラインに沿ってアクセス制御、識別・認証、不正アクセス対策、取扱状況の記録を要件化します。安全対策を「開発会社の標準対応」とせず、受入基準として確認できる形にすることが大切です。

他社より極端に安い見積もりが出たときは、要件定義、相手先との接続調整、異常系テスト、証明書更新、監視、移行、運用引き継ぎが含まれているか確認します。初期費用だけを下げ、運用費や追加改修費が高く設定されているケースもあるため、3年間の総保有コストで比較します。反対に、すべてを一括で高く見積もる提案も、何を削れば予算内に収まるのか説明できなければ、実行計画として不十分です。

リスクを減らすには、最初から本番相当の全機能を作るのではなく、難しい連携のPoC、最小限の業務範囲、契約テスト、自動監視を優先します。検討段階で「WSDLと実装の差分」「テスト環境の利用可能日」「証明書の更新担当」「障害時に再送してよい条件」「切り戻しの期限」が未確定なら、予備費とスケジュール余裕を見込み、確定後に本開発へ進む判断が安全です。

SOAPのシステム開発に関するよくある質問

SOAPのシステム開発では、「古い技術なのか」「WSDLがあればすぐに接続できるのか」「RESTへ移行すべきか」といった疑問がよく出ます。結論は、既存の利用者と業務上の契約を確認し、通信方式だけでなくセキュリティ、障害復旧、保守まで含めて判断することです。

一律に使わないと決める必要はありません。既存の取引先や基幹システムがWSDL、WS-Security、厳格なXML契約を前提としている場合は、SOAPを維持するほうが停止や再連携のリスクを抑えられます。一方、ブラウザやモバイル向けの軽量な新規APIなら、RESTやJSONも比較し、利用者が扱いやすい方式を選びます。

WSDLがあっても、すぐに本番稼働できるとは限りません。SOAP 1.1・1.2、SOAPAction、名前空間、実際のXMLサンプル、認証・証明書、Fault、タイムアウト、テスト用エンドポイントが揃っているかを確認する必要があります。仕様書と実装に差がある場合は、PoCで実通信を確かめてから本開発へ進めます。

既存WSDLを使う単一クライアントで、要件とテスト環境が整っている場合は、初期費用100万〜300万円程度、期間1〜2か月程度を企画用の目安にできます。ただし、これはSOAP固有の定価ではありません。業務画面の改修、DB更新、証明書、相手先調整、異常系試験、監視、運用手順書まで含めるかで、費用と期間は変わります。

まず、利用者、操作、データ契約、認証、SLA、依存関係、停止できない業務を棚卸しします。そのうえで、旧SOAPを残した互換層やAPIゲートウェイを置き、難易度の高い操作からRESTとの変換をPoCで検証し、利用者単位で段階移行します。全利用者の切り替え確認と切り戻し条件を用意してから、旧SOAPを停止する流れが安全です。

SOAPのシステム開発の進め方まとめ

SOAPのシステム開発は、要件整理、選定・PoC、設計・開発、テスト、稼働、定着の6フェーズで進めます。成功のポイントは、WSDLやXSDだけでなく、実際のXML、認証、Fault、再送、監視、証明書、保守の責任分界を一つの計画にまとめることです。費用は単一接続の100万〜300万円程度から、複数連携、新規サービス、REST併設やクラウド移行で大きく広がるため、案件の型と含む工程を揃えて比較します。

最初に、SOAPが必要な業務と、RESTなどを比較できる業務を分けます。次に、連携台帳でSOAPバージョン、WSDL、XSD、操作、認証、証明書、データ量、Fault、再送、監視を可視化し、最も難しい接続でPoCを行います。発注時は、開発費だけでなく、試験、移行、保守、仕様変更、証明書更新、ソースコードや設計書の引き渡しまで同じ条件で確認します。

まずは、既存のWSDL・XSD、XMLサンプル、接続先、利用者、認証方式、証明書の期限、障害時の業務対応を集め、分からない項目を課題として残してください。その台帳をもとに、要件整理とPoCの範囲を開発会社へ示せば、「SOAP連携一式」という曖昧な見積もりを避けやすくなります。既存SOAPを維持する場合もRESTへ移行する場合も、業務を止めない段階的な計画と、稼働後に自社で運用できる体制を同時に設計することが、長期的な成功につながります。

▼全体ガイドの記事
・SOAPのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。