SOAP の案件で本当に困るのは、たいてい新規開発ではありません。現場で多いのは次の3つです。
- こちらから仕様を変えられない政府系・公共系 API
- 会社の中核を握っている ERP や基幹系システム
- JSON で開発したいのに、背後に SOAP が残っているフロントエンド案件
SOAP を REST に変換する価値は、単に「今風になる」ことではありません。上流システムを触れないまま、下流の開発を前に進められることです。
1. 仕様を変えられない政府系・公共系システム
これはかなり分かりやすいユースケースです。
省庁、自治体、調達、税務、申請、給付のようなシステムでは、次のような状況が珍しくありません。
- SOAP 1.1 固定
- XML schema が厳格
- namespace の癖が強い
- 仕様書が PDF 中心で、モダンな API ドキュメントがない
この種の案件でつらいのは、業務ロジックよりも XML の儀式を毎回きれいに再現しないといけないことです。
REST の入口を挟むと、下流チームは次を手に入れられます。
- 安定した JSON の入出力
- SOAP version や namespace を1か所で管理できる構成
- SOAP を知らないチームでも触りやすいテスト導線
- バックエンド、フロントエンド、自動化担当の引き継ぎしやすさ
公共側のシステムを変えられないなら、複雑さを減らせる場所は手前の境界しかありません。
2. ERP や基幹系を残したまま開発したいケース
ERP 連携もかなり相性がいいです。
典型的には次のようなシステムです。
- 会計・財務系の古い基幹パッケージ
- 在庫・出荷・購買システム
- 承認ワークフローや仕入先向けシステム
- SAP、Dynamics、Oracle まわりの SOAP endpoint
現場で起きていることはだいたい同じです。
- ERP 自体は残る
- でもその上で新しい開発は続く
- 下流チームは JSON、OpenAPI、扱いやすい認証とテストを欲しがる
つまり、ERP を置き換えなくても開発体験だけは改善できます。
REST の入口を挟む価値が出るのは、たとえば次のケースです。
- 社内アプリには REST 契約を出したい
- XML 組み立てロジックの重複をやめたい
- 認証、エラー処理、可観測性をそろえたい
- 下流に見せる operation を必要最小限に絞りたい
全面刷新が政治的に無理でも、連携だけ生きやすくすることはできます。
3. フロントエンドが JSON で触りたいケース
これも現実的ですが、少し注意が必要です。
React、Next.js、モバイルアプリのチームが SOAP の機能を使いたいとき、REST 化された facade はかなり魅力的です。フロント側は次の形で扱えるからです。
- JSON
- OpenAPI
- 普通の HTTP ツール
- SOAP 固有のエッジケースを意識しない実装
ただし、ここには境界があります。
今すぐ相性がいいケース
- サーバー間連携
- バックエンド付きの社内ツール
- BFF を挟む構成
- cron、worker、自動化バッチ
追加で設計した方がいいケース
- パブリックなブラウザアプリから直接叩く
- origin 制御が厳しい
なぜなら、ブラウザが入ると次の論点が増えるからです。
- CORS をどうするか
- API key をどこに置くか
- cookie / session の境界をどう切るか
- allowlist や公開範囲をどう扱うか
なので、ブラウザ主体の案件では、CORS とドメイン運用が十分に揃うまでは、薄い BFF を1枚入れる方が安全なことが多いです。
そもそもサービス登録は重くないのか
単発の疎通確認だけをしたいなら、登録はたしかに重く見えます。
でも、さっきのように
- 複数チームで使う
- 認証や method の扱いを固定したい
といった話が出ているなら、重いのは登録ではなく、毎回バラバラに扱う方です。
WSDL を登録する価値は、初回セットアップだけではありません。次の情報を1か所に集められることです。
- オペレーションの発見
- method の割り当て
- 認証設定
- テスト導線
- OpenAPI 生成
要するに、登録は「最初のひと手間」ではなく、「下流チームが SOAP の癖を毎回再学習しなくて済む状態を作ること」です。
単発スクリプトを1本だけ書きたいなら、登録しない方が早いです。逆に、
- 本番で使う
- チームをまたぐ
- 審査や運用説明が必要
- 将来ブラウザ対応やチーム展開まで見えている
なら、登録して管理された状態にしておく方が自然です。
まとめ
相性がいいユースケース:
- 変更不能な政府系・公共系 SOAP
- 残し続ける前提の ERP / 基幹系
- リライトせずに REST JSON へ寄せたい社内ツールや自動化
追加で 1 段設計したいユースケース:
- ブラウザからの直接利用
- CORS 要件が強い案件
SOAP を REST にする話は、全部同じではありません。実際に刺さるのは、「上流は触れないが、下流の開発速度だけは上げたい」という案件です。