SOAPとWeb Service：REST以前の連携が今も残る場所
インポート・連携シリーズの8本目です。ここから、取り込みの隣にある「連携」の領域に入ります。外部システムと ServiceNow をつなぐ現在の主役は REST ですが、その前の世代の方式が SOAP です。今回は、この SOAP と Web Service が実機にどう残っているかを読み解きます。
OOTB の SOAP はほとんどが古いサンプルか、内部運用向けでした。新規の連携は REST で作るのが定石で、SOAP は「既存資産を動かし続けるため」や「内部の仕組み」として残っています。その実像を、実機の件数とレコードで確かめます。
このシリーズのまとめ：全体像は ServiceNowのデータ連携 全体地図 を参照してください。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・レコード・プロパティはすべて REST と実画面で確認しました（確認日 2026-07-13）。本番環境では設定が異なります。
SOAP と REST：新旧の関係
SOAP も REST も、「外部システムと HTTP でやり取りする」点は同じです。違うのは形式です。SOAP は XML で厳格に定義された、やや重い規格。REST は、より軽く柔軟な方式です。時代とともに、連携の主役は SOAP から REST へ移りました。
もう少しかみ砕くと、SOAP は「決まりごとが多い」方式です。やり取りするデータは必ず XML で包み、WSDL という定義書に沿って形を守る。相手と厳密に取り決めるので、大規模で堅い連携には向きますが、準備が重く、ちょっとしたやり取りには大げさです。一方 REST は、URL と HTTP メソッド（GET / POST など）で軽く呼べて、データも JSON で扱える。手軽さが受けて、今の連携はほぼ REST になりました。ServiceNow が SOAP を捨てずに残しているのは、過去に SOAP で作られた連携が世の中に存在し続けているからです。新しく作らないけれど、動いているものは動かし続ける。そのために、SOAP の仕組みが温存されています。
ServiceNow でも、新規の連携は REST で作るのが標準です。外部APIを呼ぶなら REST Message、外部からの受信を受けるなら Scripted REST API。これらは、このシリーズとは別に、既にそれぞれ記事があります（送信側 REST Message、受信側 Scripted REST API）。では SOAP は何のために残っているのか。それを、実機で見ていきます。
全体像はこの図のとおりです。SOAP には送信（sys_soap_message）と受信（sys_web_service）があり、REST にも送信（REST Message）と受信（Scripted REST API）がある。同じ「送信・受信」の役割を、旧世代の SOAP と現世代の REST がそれぞれ持っている。新規の連携は、この矢印のとおり REST 側へ移っています。以下では、左側の SOAP が実機でどんな状態かを確認します。
送信：SOAP Message は8件、すべてサンプル
外部へ SOAP で送るための定義が sys_soap_message です。実測で8件でした。
一覧を見て、まず作成日に目が行きます。2010年から2015年。10年以上前のものばかりです。名前も Amazon、StockQuote、WeatherForecast、TemperatureConvert。WSDL（SOAPの定義書）のURLは、webservicex.net や w3schools.com といった、当時の公開サンプルサービスを指しています。説明欄にも「Sample ... web service」とあります。
つまり、これらは動く連携ではなく、SOAP の書き方を示すための古いサンプルです。指しているサービスの多くは、今では停止しています。ServiceNow 自身に向けたもの（demoi1 incident、Instance Clone Schedule）もありますが、これらも内部運用やデモ用です。OOTB の SOAP 送信は、実質「教材」として置かれている、というのが実測から見える姿でした。
「サンプルが古い」こと自体が1つの情報です。もし SOAP が今も主役なら、新しいサンプルや、現役の外部サービスへの定義が並んでいるはずです。ところが実際は、10年以上前の、しかも多くが停止したサービスばかり。これは、ServiceNow が SOAP に新しい投資をしていない、言い換えれば「SOAP は枯れた技術として扱っている」ことの表れです。逆に、REST 側には新しい機能が次々と追加されています。どちらに力が注がれているかは、こうした OOTB のサンプルの新しさからも読み取れる。機能の一覧を眺めるときは、件数だけでなく「いつ作られたか」にも目を向けると、その機能が現役か、それとも保守モードかが見えてきます。
WeatherForecast を開いてみる
1件、中身を見ます。WeatherForecast です。
WSDL の URL が設定され、そこから読み取った操作（関数）がぶら下がる構造です。SOAP では、この WSDL が「相手のサービスがどんな操作を受け付けるか」を定義しています。REST が比較的自由なのに対し、SOAP はこの WSDL に沿って、決められた形でやり取りする。かっちり決まっているぶん、相手との齟齬は起きにくいのですが、その定義を用意する手間がかかります。この「WSDL ありき」の重さが、REST に主役を譲った理由の1つでもあります。
SOAP 関数：1つのメッセージに複数の操作
SOAP Message には、sys_soap_message_function という関数がぶら下がります。件数は46件でした。
関数の名前を見ると、execute / getRecords / insert / update といったものが並びます。1つの SOAP Message が、複数の操作をぶら下げられる、という構造がここに表れています。とくに getRecords は、.../incident/getRecords のような形で、旧 SOAP 版の Table APIの名残です。今でこそ、レコードの取得は REST の Table API（/api/now/table）を使いますが、かつては SOAP の getRecords で同じことをしていました。1つの SOAP Message に複数の操作がぶら下がる、というこの構造にも、SOAP 時代の作りが表れています。REST の登場前、ServiceNow のデータ連携は、この SOAP の getRecords / insert / update が担っていた、という歴史が読み取れます。
getRecords が語る、Table API の世代交代
SOAP 関数の中でも、getRecords は、連携の歴史を象徴する存在です。
かつて、外部システムから ServiceNow のレコードを取得したいとき、SOAP の getRecords を呼んでいました。レコードを作るなら insert、更新なら update。これらは、テーブルを SOAP 経由で操作するための「SOAP 版 Table API」でした。今、同じことをするには、REST の Table API（/api/now/table/{テーブル}）を使います。GET でレコード取得、POST で作成、PATCH で更新。やることは同じでも、方式が SOAP から REST へ変わったわけです。
この世代交代は、連携全体の縮図です。「レコードを外から読み書きする」という基本的な用途が、まず SOAP で提供され、のちに REST に置き換わった。だから、古い環境や古い連携コードには、まだ SOAP の getRecords が残っていることがあります。もし既存の連携を引き継いで「なぜ SOAP を使っているのか」と思ったら、それは REST 以前に作られたものだ、という可能性が高い。歴史的な経緯を知っておくと、そうした既存資産に出会ったときに、慌てずに対応できます。
受信：Web Service は内部向け
外から SOAP を受ける側が sys_web_service（Scripted Web Service）です。件数は16件でした。
名前を見ると、MIDServerCheck、InstanceInfo、MIDFileSyncSnapshot、CMDBApiWS、GetProperty…といった名前が並びます。MID Server やインスタンス管理に関わるものが大半でした。つまり、これらは外部の一般ユーザー向けというより、ServiceNow の内部の仕組みや、MID Server との通信に使われています。送信側が古いサンプルなら、受信側は内部運用の道具。どちらも、新規の外部連携を SOAP で作るためのものではありませんでした。新しく外部から受けるなら、Scripted REST API を使う、というのが今の作法です。
とくに MID Server 関連が多いのは、示唆的です。MID Server は、社内ネットワークに置いて、ServiceNow と社内システムを橋渡しする中継サーバです（次回詳しく扱います）。その MID Server と ServiceNow の間の通信の一部に、この Scripted SOAP が使われています。MIDServerCheck なら「MID Server が生きているか確認する」、MIDFileSyncSnapshot なら「MID Server とファイルを同期する」といった具合です。これらは、利用者が意識することのない、裏方の通信です。だから、Web Service の一覧を見て「知らない SOAP がたくさんある」と驚く必要はありません。その多くは、ServiceNow が自分の仕組みを動かすために内部で使っているもので、私たちが新しく触るものではない、と分かれば十分です。
SOAP のセキュリティ設定
SOAP は今も内部で動いているので、セキュリティのプロパティは有効に保たれています。実測したものです。
glide.soap.strict_security = true（厳格なセキュリティ）
glide.soap.request_processing_timeout = 60（処理のタイムアウト秒）
com.glide.soap.guest_user = soap.guest（認証なしアクセス用のユーザー）
古い方式とはいえ、内部で使われている以上、セキュリティは締めてあります。とくに strict_security が true になっているのは、SOAP 経由の不正なアクセスを防ぐためです。レガシーだからといって、放置されているわけではない、という点は押さえておきたいところです。
com.glide.soap.guest_user に soap.guest が設定されているのも、覚えておくと役立ちます。これは「認証情報なしで SOAP を呼んだとき、どのユーザーとして扱うか」の設定です。もし SOAP のエンドポイントを認証なしで公開する必要があるなら、この guest ユーザーの権限が、そのままアクセスできる範囲になります。裏を返せば、この guest ユーザーに強い権限を与えてしまうと、認証なしで重要なデータに触れてしまう危険があります。SOAP を触るときは、この guest 設定と strict_security を必ず確認する、というのがセキュリティ上の勘所です。古い機能ほど、こうした設定が見落とされがちなので、注意が要ります。
いつ SOAP を使うのか
ここまでで、実機の SOAP の姿が見えてきました。整理すると、こうなります。
新規の連携は、SOAP では作りません。 外部APIを呼ぶなら REST Message、外部から受けるなら Scripted REST API。これが今の標準です。では SOAP を触るのはどんなときか。1つは、相手が SOAP しか対応していない古い外部システムとつなぐとき。もう1つは、既にある SOAP 連携を保守するとき。どちらも「既存資産があるから SOAP」であって、ゼロから SOAP を選ぶ理由は、ほぼありません。
だから、SOAP は「知っておくが、新しくは作らない」機能として捉えるのが実務的です。一覧に SOAP が並んでいても、慌てて使う必要はありません。まず REST で足りないかを考え、相手の都合でどうしても SOAP が要るときだけ、この仕組みに手を伸ばす。この判断の順序を持っておけば、迷いません。
とはいえ、既存の SOAP 連携に出会う可能性は、現場では決して低くありません。長く使われている大企業のシステムほど、10年前、15年前に作られた連携が今も動いていることがあります。そのとき「SOAP は古いから」と切り捨てず、なぜそれが SOAP なのか、どう動いているのかを読み解けることが、運用者には求められます。今回見たように、SOAP Message で送り、Web Service で受け、関数で操作を分ける。この基本構造さえ分かっていれば、既存の SOAP 連携も怖くありません。新しく作る技術というより、既存を理解する知識として、SOAP を頭の片隅に置いておく。それが、この機能との正しい距離感です。
確認導線
実機で開くときの入口です（URL形式は list.do 規約に基づきます。実クリック確認は今回の範囲外です）。
SOAP Message（送信）… sys_soap_message_list.do
SOAP 関数 … sys_soap_message_function_list.do
Web Service（受信・Scripted SOAP）… sys_web_service_list.do
まとめ
SOAP と Web Service は、REST 以前の連携方式でした。OOTB の SOAP 送信8件はすべて2010年代の古いサンプル、受信16件は MID Server などの内部向け。新規の外部連携は REST（REST Message / Scripted REST API）で作るのが標準で、SOAP は「既存資産の保守」や「内部の仕組み」として残っています。
とはいえ、内部で動いている以上、セキュリティは締めてあり、無視してよいわけではありません。SOAP は「歴史として知り、必要なときだけ触る」機能。この距離感を持っておくと、連携の設計で迷わなくなります。
このシリーズでは、取り込みから連携へと視野を広げてきました。取り込み（Import Set）は「外部データを取り込んで本番テーブルに載せる」ための仕組み、連携（REST / SOAP）は「外部システムと直接やり取りする」ための仕組みです。SOAP は、その連携の古い層にあたります。新規では使わないけれど、既存資産を理解し、内部の動きを追うためには、知っておく価値がある。ServiceNow を長く運用するほど、こうした古い層に出会う場面が増えていきます。そのとき、この層が何で、なぜ残っているかを知っていれば、落ち着いて対応できる。「知っているが、新しくは作らない」。SOAP との付き合い方は、この一言に尽きます。次回は、外部システムと ServiceNow を社内ネットワークで中継する MID Server を見ていきます。今回、受信 Web Service のところで何度も名前が出てきた、あの中継サーバの中身です。
その他、実機で確認した記録
用語
SOAP … REST 以前の連携方式。XML と WSDL で厳格に定義する
WSDL … SOAP サービスの定義書。どんな操作を受け付けるかを記述
SOAP Message（sys_soap_message） … 外部へ SOAP を送る定義（OOTBは古いサンプル）
Web Service（sys_web_service） … 外から SOAP を受ける定義（OOTBは内部・MID向け）
REST との関係 … 新規は REST（REST Message / Scripted REST API）が標準
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/sys_soap_message_list.do（SOAP Message 8件）
/sys_soap_message_function_list.do（SOAP 関数 46件）
/sys_web_service_list.do（受信 Web Service 16件）
実測の要点（再掲）
送信 SOAP Message 8件（Amazon / StockQuote / WeatherForecast 等・2010〜2015のサンプル）
SOAP 関数 46件（execute / getRecords / insert / update ＝旧 SOAP Table API）
受信 Web Service 16件（MIDServerCheck / InstanceInfo 等・内部運用向け）
glide.soap.strict_security=true・request_processing_timeout=60・guest=soap.guest
検証範囲とおことわり
この記事の件数・レコード・WSDL・プロパティは、PDI（Zurich / OOTB）の実測です。
SOAP の実際の送受信挙動は、外部WSDLの多くが停止しており、内部SOAPも運用系のため未確認（検証範囲外）です。
新規連携は REST が標準です。REST Message / Scripted REST API は、それぞれ別の記事で扱っています。
list.do のURL形式は規約に基づくもので、実クリック確認は今回の範囲外です。
