ServiceNowのデータ連携 全体地図：取り込みと連携を1枚で
インポート・連携シリーズの締めくくりです。ここまで、取り込み（Import Set）と連携（REST / SOAP）の各部品を1つずつ実機で見てきました。今回は、それらを1枚の地図にまとめ、全体像を俯瞰します。似た用語が多くて迷いやすい領域ですが、「取り込みなのか、連携なのか」「送るのか、受けるのか」で整理すると、驚くほどすっきりします。
ServiceNow を運用していると、「外部システムとつなぎたい」という要望は、必ずと言っていいほど出てきます。人事システムからユーザーを取り込む、監視ツールからアラートを受ける、承認システムへ申請を送る。そのたびに、どの機能を使えばよいのか。ServiceNow には取り込みと連携で数多くの部品があり、名前も似ているので、初めてだと途方に暮れます。この記事の地図は、そんなときの道しるべです。個々の部品を覚える前に、まず全体のどこに何があるかを掴む。それが、この領域を効率よく理解する近道です。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測に基づく総括です（確認日 2026-07-13）。件数は各回の実測値。本番環境では異なります。
2つの世界：取り込みと連携
まず、大きく2つの世界を分けます。
取り込み（Import Set） … 外部のデータを、いったん受け取って、本番テーブルに載せる
連携（REST / SOAP） … 外部システムと、その場で直接やり取りする
取り込みは「データをまとめて移住させる」イメージ、連携は「必要なときに問い合わせる」イメージです。CSV を毎晩取り込んでユーザーを同期するのは取り込み、フォームを開いた瞬間に外部の在庫を問い合わせるのは連携。目的が違えば、使う仕組みも違います。この2つを最初に分けておくと、どの機能がどちらの話かで迷いません。
もう少し踏み込むと、この2つは「データを ServiceNow の中に持つかどうか」でも分かれます。取り込みは、外部データを ServiceNow のテーブルにコピーする。取り込んだあとは、ServiceNow の中のデータとして、検索も加工も自由にできます。一方、連携は、データを ServiceNow に持たず、必要なときに外部へ取りに行く、あるいは外部へ送るだけです。手元にコピーを置くのが取り込み、置かずに都度やり取りするのが連携。どちらがよいかは、「そのデータを ServiceNow の中で使い倒したいか、それとも外部が持つ最新をその都度見たいか」で決まります。ユーザーやCIのように ServiceNow の機能の土台になるデータは取り込み、外部の在庫や為替のように常に最新が要るデータは連携、という住み分けが自然です。
取り込みの全体像
取り込みは、このシリーズの前半で見た3段構造が骨格でした。
データソース（どこから）→ ステージング（一時置き場）→ 変換マップ（どう移すか）→ ターゲット（本番）。この一本道に、coalesce（重複を防ぐ突合キー）、変換スクリプト（途中の割り込み）、スケジュール（自動実行）、ログと行の状態（結果の記録）が絡みます。1つずつは小さな部品ですが、組み合わさって「外部データを安全に取り込む」流れを作ります。
各部品は、シリーズの各回で詳しく扱いました。取り込みの入口が知りたければデータソースの回、重複が心配なら coalesce の回、自動化したいならスケジュールの回、というふうに、地図の各所を拡大した記事があります。
この3段構造の美しさは、部品がきれいに分離していることです。取り込み口（データソース）を変えても、移し方（変換マップ）はそのまま。移し方を変えても、いつ走らせるか（スケジュール）はそのまま。それぞれが独立した部品なので、変えたいところだけをピンポイントで直せます。CSV での試作から本番の JDBC への切り替えも、口の差し替えだけで済む。この「疎結合」の設計が、取り込みを柔軟で壊れにくいものにしています。1つの巨大な設定にすべてを詰め込む代わりに、小さな部品を組み合わせる。ServiceNow の取り込みは、その好例でした。
連携の全体像
一方、連携は「送信」と「受信」で分かれ、さらに「REST（現在）」と「SOAP（旧来）」の世代があります。
送信（アウトバウンド） … ServiceNow から外部を呼ぶ。REST Message（現在）／ SOAP Message（旧来）
受信（インバウンド） … 外部から ServiceNow を呼ぶ。Scripted REST API（現在）／ Web Service（旧来 SOAP）
新規の連携は、すべて REST 側で作ります。SOAP は、⑧で見たとおり、古い外部サンプルと内部運用向けが残るだけでした。連携を設計するときは、まず「送るのか受けるのか」を決め、次に「REST（ほぼ常にこちら）」を選ぶ。この順で考えれば、部品選びで迷いません。
送信と受信を分けて考えるのは、想像以上に大切です。同じ「連携」でも、この2つは向きが真逆で、使う部品も別だからです。送信は、ServiceNow が能動的に外部へ問い合わせる。だから「どのURLに、どんなデータを送るか」を ServiceNow 側で決めます。受信は、外部が ServiceNow を呼ぶ。だから「どんなリクエストを受け付けて、どう応えるか」の窓口を ServiceNow 側に用意します。方向が違えば、設定する場所も、考えることも変わる。「連携がうまくいかない」という相談の多くは、この送受信を取り違えているか、片方だけ設定して満足しているケースです。まず自分がやりたいのは送信か受信か、これを最初にはっきりさせるだけで、つまずきはぐっと減ります。認証も、送信なら「相手に認証情報を渡す」、受信なら「相手を認証する」と、向きで意味が変わります。方向を意識することが、連携を正しく組む第一歩です。
なぜ混同しやすいのか
取り込みと連携が紛らわしいのは、どちらも「外部システムとつながる」機能で、しかも一部で同じ技術を使うからです。
たとえば、データソースには JDBC や REST を使うタイプがあります。REST という言葉は、連携（REST Message）にも、取り込み（REST データソース）にも出てきます。同じ REST でも、片方は「取り込みの入口として外部から一括で読む」もの、もう片方は「連携として1件ずつ外部APIを呼ぶ」もの。使う技術が同じでも、目的とテーブルは別物です。ここを混同すると、「REST の設定をどこでするか」で迷子になります。
だから、技術（REST か SOAP か）で覚えるのではなく、目的（取り込みか連携か）で覚えるのが近道です。まず「何がしたいのか」を決め、それに合う世界（取り込み／連携）を選び、その中で部品を選ぶ。この順序を守れば、同じ技術名が別々の場所に出てきても、混乱しません。用語の重なりは、この領域の分かりにくさの正体ですが、目的から入れば解きほぐせます。
取り込みと連携が交わるところ
2つの世界は完全に別物かというと、実は接点もあります。それが、前半で見たデータソースの「REST タイプ」や「JDBC タイプ」です。
これらは分類上は取り込み（データソース）ですが、やっていることは外部への問い合わせ、つまり連携に近い動きです。外部DBに繋いで一括で読む JDBC、外部APIから一括で取る REST データソース。これらは「連携の技術を使って、取り込みを行う」ハイブリッドな存在です。実際、REST データソースは、REST で外部を呼ぶという点で連携と同じですが、呼んだ結果を1件ずつ処理せず、まとめてステージングに落として変換マップに流す、という点で取り込みです。技術は連携、目的は取り込み。この二面性が、混乱のもとにもなります。だから、取り込みと連携は、くっきり二分されるというより、地続きでつながっている面もあります。とはいえ、初めて全体像をつかむときは、まず「取り込みと連携は別の世界」と割り切って覚えるのがおすすめです。二分法で骨格を掴んでから、こうした接点を知ると、かえって理解が深まります。地図はまず大まかに、細部はあとから、が習得のコツです。
使い分けを1枚で
取り込みと連携、送信と受信。役割を表にまとめます。
分かれ目は「データをまとめて動かすのか、その場で問い合わせるのか」です。大量のデータを定期的に同期するなら取り込み。1件ずつ、必要なときに外部とやり取りするなら連携。そして連携の中では、送信か受信か、で部品が決まります。この3つの問い（取り込みか連携か・送信か受信か・RESTかSOAPか）を順にたどれば、どの機能を使うべきかにたどり着けます。
表の各行を、実際の業務に置き換えてみると、地図の使い方がさらにはっきりします。「毎晩、基幹システムの社員マスタを ServiceNow に反映する」なら1行目の取り込み。「同じ人を二重に作りたくない」なら2行目の coalesce。「変更申請を外部の CAB ツールに送って承認をもらう」なら3行目の REST Message。「監視ツールがアラートを ServiceNow にインシデントとして起票する」なら4行目の Scripted REST。このように、やりたいことを言葉にすれば、表のどの行かが決まり、使う部品が見えます。逆に言えば、部品から入るのではなく、業務から入る。この表は、業務の言葉と部品の名前をつなぐ辞書のようなものです。
設計の第一歩：3つの問い
実際に「外部とつなぎたい」となったとき、この地図をどう使うか。3つの問いを順にたどるだけです。
1つめ、「データをまとめて持ってきたいか、その都度やり取りしたいか」。まとめて持ってくるなら取り込み、都度やり取りなら連携。ここで大きな世界が決まります。2つめ（連携を選んだ場合）、「ServiceNow から呼ぶのか、外部から呼ばれるのか」。呼ぶなら送信、呼ばれるなら受信。3つめ、「相手は何に対応しているか」。ほぼ常に REST ですが、相手が古ければ SOAP。この3問で、使うべき部品が1つに絞られます。
たとえば「毎朝、人事システムのユーザーをまとめて同期したい」なら、問い1で取り込み、そこから先はデータソースと変換マップとスケジュール。「外部の承認システムに、変更申請を送って結果を受け取りたい」なら、問い1で連携、問い2で送信、問い3で REST、つまり REST Message。このように、やりたいことを3問に分解すれば、迷わず部品にたどり着けます。逆に、いきなり「REST か SOAP か」から考え始めると、目的を見失いがちです。まず目的、次に技術。この順序が、連携設計の鉄則です。
この3つの問いは、他人に相談するときにも役立ちます。「外部連携を作りたい」とだけ言われても、相手は答えようがありません。ですが「まとめて取り込みたくて、社員データを毎晩同期したい」と、3問の答えを添えて相談すれば、話が一気に具体的になります。取り込みなら変換マップの話、送信なら認証の話、と、議論すべき論点も定まります。この地図は、自分が迷わないためだけでなく、チームで連携を設計するときの共通言語にもなる。同じ言葉で「これは取り込みの送信じゃなくて連携の受信だね」と話せると、認識のずれが減ります。技術の会話は、まず土俵をそろえることから。その土俵が、この2つの世界と送受信の区別です。
この環境の実測サマリ
シリーズを通して実測した件数を、1つの表に集めます。
数字を眺めると、ServiceNow の作りが見えてきます。取り込みは変換マップ14・データソース17と、部品が一式そろっている。連携の受信（Scripted REST）は225定義と桁違いに作り込まれている一方、送信（REST Message）はOOTBでわずか4件。ServiceNow は「外部から呼ばれるサーバー」として厚く、「外部を呼びに行く」定義はユーザーが自作する前提、という非対称が読み取れます。SOAP は送受信とも少数のレガシーのみ。件数の多寡が、その機能の位置づけを物語っています。
この非対称は、ServiceNow という製品の性格をよく表しています。ServiceNow は、企業の業務データが集まる「中心のシステム」を目指しています。だから、外部から「ServiceNow のデータをください」「ServiceNow に登録してください」と呼ばれる側の受け口を、手厚く用意している。受信の Scripted REST が225もあるのは、その表れです。一方、ServiceNow が外部を呼びに行くのは、あくまで業務上必要なときだけ。だから送信の定義はユーザーが個別に作る前提で、OOTB は最小限です。件数を見るだけで、その製品が「呼ばれる側」なのか「呼ぶ側」なのかが分かる。実測の数字は、機能の使い方だけでなく、製品の思想まで教えてくれます。取り込みの部品が一式そろっているのも、「まず外部データを取り込んで、中心のデータベースを作る」ことが重視されている証拠です。
シリーズ各記事へのリンク
このシリーズと、関連する既存記事を、地図の順にまとめておきます。
取り込み（Import Set）
連携（REST / SOAP）
まとめ
ServiceNow のデータ連携は、取り込み（まとめて移す）と連携（その場でやり取り）の2つの世界に分かれていました。取り込みは3段構造を骨格に、coalesce やスケジュールなどの部品が絡む。連携は送信・受信に分かれ、新規は REST、旧来は SOAP。この地図さえ頭にあれば、新しい用語が出てきても、どの世界の、どの役割の話かをすぐ見抜けます。
この10本を振り返ると、一貫して見えたのは「部品を小さく分け、組み合わせる」という ServiceNow の設計思想でした。取り込み口と移し方を分け、送信と受信を分け、値の生成と処理の割り込みを分ける。どれも、1つの巨大な仕組みに詰め込む代わりに、役割ごとに部品を切り出しています。だからこそ、変えたいところだけを直せて、試作から本番へ滑らかに移れる。この思想が分かると、初めて見る機能でも「これはどの役割の部品か」と読み解けるようになります。
似た名前に惑わされず、「取り込みか連携か」「送信か受信か」を分けて考える。この2つの問いを持つだけで、データ連携の設計は一気に見通しがよくなります。シリーズを通して伝えたかったのは、個々の機能名より、この全体の地図でした。
最後に、この地図を自分の環境で使う一歩を挙げておきます。実機を触れる立場なら、まず sys_data_source_list.do と sys_transform_map_list.do を開いて、自社にどんな取り込みが設定されているかを眺めてみてください。次に sys_rest_message_list.do と sys_ws_definition_list.do で、どんな連携があるかを見る。この4つの一覧を眺めるだけで、「うちの ServiceNow は、どこと、どうつながっているか」の全体像がつかめます。個々の設定を細かく追う前に、まずこの4画面で地図を描く。そこから、気になった部品を、シリーズの各回で拡大していけば、迷わず細部まで追えます。名前を覚えることより、この地図を持って実機を歩けることのほうが、ずっと役に立ちます。10本を通じて、その地図をお渡しできていれば幸いです。
その他
用語
取り込み（Import Set） … 外部データを受け取り本番テーブルに載せる仕組み
連携（REST / SOAP） … 外部システムと直接やり取りする仕組み
送信 / 受信 … ServiceNow から呼ぶ / 外部から呼ばれる
REST / SOAP … 現在の標準 / 旧来の方式
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/sys_transform_map_list.do（変換マップ・取り込みの要）
/sys_data_source_list.do（データソース・取り込みの入口）
/sys_rest_message_list.do（REST Message・送信）
/sys_ws_definition_list.do（Scripted REST・受信）
実測の要点（再掲）
取り込み: 変換マップ14 / データソース17 / 変換スクリプト12 / スケジュール2 / 行の状態10種
連携（REST）: 送信 REST Message 4 / 受信 Scripted REST 225定義・1158リソース
連携（SOAP）: 送信 8（レガシー）/ 受信 16（内部）
非対称: 受信サーバーとして厚く、送信定義は自作前提
検証範囲とおことわり
この記事は①〜⑧および関連既存記事の実測を統合したものです。件数は PDI（Zurich / OOTB）の実測に基づきます。
実際の取り込み実行・連携の送受信挙動は、sys_import_set が0件・外部WSDL停止などのため未確認（検証範囲外）です。
MID Server（ecc_agent）はこの PDI に未登録のため扱っていません。
list.do のURL形式は規約に基づくもので、実クリック確認は今回の範囲外です。
