SOAPとは？ RPCからわかるWebサービスの仕組み

身近な場面：ネット通販の裏側にある3つのシステム

コーヒー豆をネットショップで注文するとき、「在庫あり」「注文を受け付けました」「明日発送予定」と表示されます。1つの画面に見えますが、裏側では通販サイト・在庫管理・配送管理という別々のシステムが動いていることがあります。

通販サイトが倉庫システムに電話できるわけではありません。そこでシステム同士が決められた形式で依頼と結果を送り合う必要があります。SOAPは、そのとき使えるメッセージの形式と処理ルールを定めた仕組みです。

そもそもAPIとは？ ――システムの「受付窓口」

API（Application Programming Interface）は、ソフトウェアが別のソフトウェアの機能を利用するための取り決めです。たとえば通販サイトは「在庫数を返す」という窓口に、商品コードを渡します。

APIは必ずしもネットワーク越しではありません。自分のプログラム内のライブラリ関数を呼ぶのもAPIです。Web APIは、HTTPなどを利用してネットワーク経由で使うAPIを指します。

RPC：離れたコンピュータの処理を呼ぶ

RPC（Remote Procedure Call）は、別のコンピュータにある処理を、関数や手続きを呼ぶように依頼する考え方です。RPCはSOAPだけの用語ではなく、gRPCやJSON-RPCなどにも共通します。

const stock = getStock("COFFEE-01");
// stock = 12

大切なのは、ローカル関数と違って、RPCではネットワーク障害・タイムアウト・相手側のエラーが起こることです。「配送依頼の返事が来なかったから再送したら、同じ商品が二重に出荷された」という問題もあり得ます。RPCだから自動的に安全・確実というわけではありません。

XML：データの意味をタグで示す

SOAPメッセージはXMLで表します。XML（Extensible Markup Language）は、データのまとまりに名前を付けて表現する書き方です。HTMLと形は似ていますが、画面表示ではなく意味のある構造化データを伝える目的で使われます。

<product>
  <code>COFFEE-01</code>
  <quantity>2</quantity>
</product>

ここでは「商品コードはCOFFEE-01、個数は2」と読めます。開始タグと終了タグを対応させ、1つのルート要素の下に内容を入れます。xmlnsは名前空間と呼び、別の組織が同じタグ名を使っても区別できるようにします。

SOAPは「書式が決まった封筒」

封筒で手紙を送るとき、差出人の情報や本文などの置き場が決まっていると扱いやすくなります。SOAPにも「大きな封筒」を表すEnvelopeがあり、その中にHeaderとBodyを入れます。

SOAPは、XMLをどのように包むかだけでなく、Headerの処理やエラー（Fault）の表し方も定めています。ただし、業務操作の名前や、誰にどんな権限を与えるかまでSOAPが自動的に決めるわけではありません。

在庫を問い合わせるときのリクエストとレスポンス

通販サイトが「COFFEE-01の在庫数を知りたい」と依頼するSOAP 1.2メッセージの例です。上部はHTTPリクエスト、空行より下がSOAPのXMLです。

POST /InventoryService HTTP/1.1
Host: inventory.example.com
Content-Type: application/soap+xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
  xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
  xmlns:inv="https://example.com/inventory">
  <soap:Header>
    <inv:ClientId>online-shop</inv:ClientId>
  </soap:Header>
  <soap:Body>
    <inv:GetStock>
      <inv:productCode>COFFEE-01</inv:productCode>
    </inv:GetStock>
  </soap:Body>
</soap:Envelope>

在庫管理システムが処理に成功したら、たとえば次のXMLを返します。

<?xml version="1.0"?>
<soap:Envelope
  xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
  xmlns:inv="https://example.com/inventory">
  <soap:Body>
    <inv:GetStockResponse>
      <inv:availableQuantity>12</inv:availableQuantity>
    </inv:GetStockResponse>
  </soap:Body>
</soap:Envelope>

通販サイトはavailableQuantityの値「12」を取り出し、商品ページに「在庫あり」と表示できます。このように、呼び出し → XML送信 → サーバーで処理 → XML応答がひと続きになります。

Header・Body・Fault：それぞれの役目

Headerは処理に必要な付加情報を記述する場所です。たとえば「このメッセージをどのように扱うか」を伝えます。SOAP 1.2にはmustUnderstand属性があり、対象ノードが必須のHeaderブロックを理解できないときはFaultを返すなどのルールがあります。

Bodyは主に業務データを入れる場所ですが、エラーが起きた場合にはBody内にSOAP Faultを格納します。商品コードが不正な場合なら、次のようなイメージです。

<soap:Body>
  <soap:Fault>
    <soap:Code>
      <soap:Value>soap:Sender</soap:Value>
    </soap:Code>
    <soap:Reason>
      <soap:Text xml:lang="ja">商品コードが不正です</soap:Text>
    </soap:Reason>
  </soap:Fault>
</soap:Body>

SOAP 1.2のFaultにはCodeとReasonなどがあり、SOAP 1.1のFaultではfaultcodeやfaultstringが使われます。単に「HTTPエラーが返った」と考えず、HTTPの状態とSOAP Faultの両方を確認するのが重要です。

WSDL：外部システムの「取扱説明書」

ここまで見たXMLを、毎回担当者同士が口頭で決めたら大変です。そこでSOAPベースのWebサービスでは、サービスのインターフェースを定義するWSDL（Web Services Description Language）がよく使われます。

<wsdl:operation name="GetStock">
  <wsdl:input message="tns:GetStockInput"/>
  <wsdl:output message="tns:GetStockOutput"/>
</wsdl:operation>

上の断片はWSDL 1.1の操作定義を簡略化したものです。WSDLの定義からクライアント用コードを生成できる開発環境もあり、大規模な企業システムで採用されてきました。

HTTP・SOAP・RPCは同じ階層のものではない

混同しやすい3つを、配送業者に荷物を頼む例で分けましょう。

SOAPはHTTPに載せる使い方が代表的ですが、SOAP自体はHTTP専用の規格ではありません。またSOAPの全利用がRPC形式とは限らず、文書形式の交換もあります。

操作して確かめる：SOAPメッセージを作ってみよう

操作する業務を「在庫照会」から「配送依頼」に変えたらBodyはどう変わるでしょうか？ 商品コードを「UNKNOWN」にした場合や、処理失敗を選んだ場合には何が返るでしょうか？ XMLを実際に見比べてください。

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:m="https://example.com/store/ws">
  <soap:Header>
    <m:ClientId>shop-front</m:ClientId>
  </soap:Header>
  <soap:Body>
    <m:GetStock>
      <m:productCode>COFFEE-01</m:productCode>
    </m:GetStock>
  </soap:Body>
</soap:Envelope>

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:m="https://example.com/store/ws">
  <soap:Body>
    <m:GetStockResponse>
      <m:availableQuantity>12</m:availableQuantity>
    </m:GetStockResponse>
  </soap:Body>
</soap:Envelope>

REST APIとの違い：「処理」を呼ぶか「資源」を操作するか

最近よく見かけるREST風のWeb APIでは、商品というリソースをURLで表し、HTTPのGET・POSTなどを使って操作します。比較のため、同じ在庫照会を並べてみます。

ただしこれは典型的な設計例です。SOAPだから必ず操作型、RESTだから必ずJSONという決まりではありません。RESTはアーキテクチャスタイルであり、SOAPと同じ層の単一プロトコルではありません。

実際の選択は、既存システムとの互換性、相手企業の仕様、セキュリティ要件、運用ツールなどで決まります。SOAPを「古いから不要」と切り捨てず、相手がどの契約で通信しているかを見ることが大切です。

SOAPを使えば通信が自動的に安全になる？

なりません。SOAPはメッセージ形式と処理の枠組みなので、それ自体で機密性、送信元の認証、業務権限の確認がすべて提供されるわけではありません。

たとえば出荷APIに対して、quantity=999999と送られても無条件で処理してはいけません。また、配送依頼がタイムアウトしたときにむやみに再送すると二重処理が起こるため、重複排除用IDなどの設計も重要です。

全体をもう一度つなぐ

ネットショップで「在庫を調べる」という日常の小さな操作が、RPCという発想、SOAPというメッセージのルール、XMLという表現、HTTPという通信手段を組み合わせて実現されることが分かれば、企業間のシステム連携も読み解きやすくなります。