Integration Hubは何者か
ServiceNowを触り始めると、まずはインシデントやカタログ、承認、通知…という「プラットフォーム内の自動化」に目が行きます。ところが運用を現実に寄せていくほど、必ずぶつかるのが外部システムとの連携です。人事、会計、ID管理、チャット、監視、CRM…どれか一つでも外にあると、ServiceNowの中だけで完結しません。
そこで登場するのがIntegration Hubです。公式ドキュメントでは、Integration Hubは「サードパーティシステムとの再利用可能な統合を構築し、それをServiceNow AI Platformのどこからでも呼び出せる」ものとして説明されています。さらに、REST/SOAP/PowerShellなどのプロトコル手段や、必要に応じてMID Server上での実行にも触れられています。
ここで大事なのは、Integration Hubを「単なるコネクタ集」だと思わないことです。もちろん、事前に用意された連携部品（いわゆるSpoke）を使う場面も多いのですが、本質はそこではありません。
- “外部とつなぐ処理”を、再利用できる部品として標準化する
- その部品を、フローの中から呼び出して業務を端から端までつなぐ
- 接続情報や実行場所（インスタンス／MID Server）を運用しやすい形に寄せる
この3点が、Integration Hubを学ぶ価値です。CSAの学習段階でも、ここを理解していると、Flow Designerや通知、カタログの話が「点」ではなく「線」でつながり始めます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
Flow DesignerとIntegration Hubの関係
混乱しやすいポイントを先に言い切ると、Flow Designerが“業務の流れ”を組み立てる場所で、**Integration Hubは“外部とやり取りするための部品群（と仕組み）”**です。
Flow Designerは、承認、タスク、通知、レコード操作などを、自然言語に近い形で組み立てられる統合的な自動化環境として説明されています。新しいプロセス要件では、従来のWorkflowよりFlow Designerを推奨する旨も明記されています。
では、Flow Designerだけで外部連携も全部できるのか？
ここが誤解の入口です。
- Flow Designerは「流れ」を作る
- 外部連携は「流れの中の一手段」
- その一手段を、使い回せる形で提供するのがIntegration Hub
公式ドキュメントでも「Flow DesignerとIntegrationHub」という節で、Integration Hub側の設計プラクティスが具体的に示されています。たとえば、“統合先システムごとにSpokeを1つ作る”、“接続はインラインではなくConnection Aliasを使う”、**“バージョンを見据えた命名や属性設計をする”**といった考え方です。
このあたりは、暗記で乗り切るより「なぜそうするのか」で腹落ちさせた方が、あとで効きます。
具体例：チャット通知を「ただ送る」から「業務を完了させる」へ
- Flow Designerで「申請が承認されたらSlackに通知」を作るのは比較的簡単です（流れの組み立て）。
- でも現場で求められるのは「Slackで承認ボタンを押したらServiceNowのレコードも更新される」など、往復の連携だったりします。
- このとき、Slack側とのやり取りを“部品化”しておくと、別の申請でも同じやり方で使えます。
この「部品化して再利用する」という思想が、Integration Hubの位置づけを理解する鍵です。
Zurichで押さえたいIntegration Hubの位置づけ
ZurichのIntegration Hubリリースノートでは、Integration HubがWorkflow Studioの自動化機能を拡張し、ServiceNowのデータと外部システムのデータを統合するためのものだと明確に説明されています。
つまり、ZurichではIntegration Hubは「連携オプションの一つ」ではなく、**“自動化スタジオ（Workflow Studio）を外部まで広げる中核”**として捉えるのが自然です。
さらにZurichでは、実務で効く改善がいくつか入っています。代表的な例を、位置づけの観点で整理します。
“つなぐ”の前段が速くなる：RESTベースのData Streamアクション改善
RESTベースのData Streamアクションで、レスポンス解析（パース）や出力設定の手間を減らす方向の改善が入っています。
現場目線で言うと、「連携の最初の試作が早い」＝「検証の回転が上がる」。この効果が大きいです。
“止まらない連携”に寄る：MID Serverクラスタなどの強化
Stream Connectで、単体MID ServerではなくロードバランシングされたMID Serverクラスタを使ったメッセージ複製が扱えるようになっています。
連携は“作る”より“落とさない”方が難しいので、ここが強化されているのは位置づけとして象徴的です。
“運用しやすい接続”に寄る：Connection Aliasのテストなど
Connection Aliasを、テンプレートから直接テストできるようにするなど、設定～検証の動線が改善されています。
Integration Hubを「開発者の道具」だけに閉じず、運用や標準化に寄せたい意図が見えます。
ライセンスの話も“位置づけ”の一部
Zurichでは、Spokesの一覧や詳細ページがIntegration Hub Starter Packに含まれる一方、OpenAPIやPostman仕様、Now Assistを使ったSpoke作成には上位ライセンスが必要、といった記載があります。
ここから読み取れるのは、“使う（参照・利用）”と“作る（生成・拡張）”で求められる権限や契約が分かれるという現実です。学習段階でも、「どこまでが標準で、どこからが拡張なのか」を意識しておくと混乱しにくくなります。
また、リリースノート内には、Integration HubがWorkflow Data Fabricのサブスクリプションパッケージの有効化で利用可能、といった位置づけも示されています。
“データとワークフローをつなぐ基盤”の側にIntegration Hubが置かれている、と捉えると理解が安定します。
よくある誤解と、設計で困らない整理術
Integration Hubは、名前だけ聞くと「統合＝難しい」「コネクタ＝設定が多い」と身構えがちです。ここでは、初学者が混乱しやすいポイントを、仕組み理解として整理します。
誤解：Integration Hubがあれば何でもノーコードで全部つながる
実際には、外部システムのAPI品質、認証方式、ネットワーク制約、データ整合性など、現実の壁は残ります。Integration Hubはそれを“魔法のように消す”ものではなく、「連携を作る・使う・運用する」をServiceNow側で標準化する枠組みです。
整理のコツ
- 「外部の事情」は外部にある（API・権限・仕様変更）
- Integration Hubは「ServiceNow側の作法」を揃える
- だから、設計プラクティス（Spoke分割、Alias、バージョニング）が効く
誤解：Flow DesignerとIntegration Hubは別物なので、どちらかを覚えればいい
実務ではだいたいセットで登場します。Flow Designerが“流れ”、Integration Hubが“外部の一手”なので、片方だけ学ぶと途中で行き止まりになりがちです。
整理のコツ
- Flow Designer：業務プロセスの骨格
- Integration Hub：骨格に外部連携という手足を付ける
- 「再利用できる部品」という共通目的で見れば一体に見える
誤解：Spokeは“便利な既製品”だから、深く理解しなくていい
既製品として使うだけでも価値はあります。ただ、運用で困るのはだいたいここです。
- 認証情報をどこで管理するか
- 環境ごとの接続先差分をどう扱うか
- APIバージョンが上がったとき、どこを直すか
- 失敗時にどんなエラーが返り、どこでリトライするか
こういう論点は、Connection Aliasやバージョンを見据えた設計などのプラクティスに直結します。
試験対策としても、「なぜConnection Aliasを使うのか」を説明できる状態が、暗記より強いです。
“位置づけ”が腹落ちするチェック質問
学習中、次の問いに答えられるかで理解度が測れます。
- この自動化は「プラットフォーム内で完結」している？それとも「外部と往復」している？
- 外部とのやり取りは、別の業務でも再利用したい？（＝部品化したい？）
- 接続先が変わったとき、フローを直す？それとも接続情報だけ差し替える？
この3つにスムーズに答えられるようになると、Integration Hubの位置づけはかなり安定します。
CSA学習の進め方と、Udemyの使いどころ
CSAを目指す段階では、Integration Hubの“細かい実装”を丸暗記するより、ServiceNowの自動化をどう整理して捉えるかが効きます。Flow DesignerとIntegration Hubの関係を理解しておくと、後続の学習（Catalog、通知、承認、ACL、データ連携）でも「それはどの層の話か」を見失いにくくなります。
おすすめの学習順（仕組み理解を優先）
- Flow Designerの基本
トリガー→アクション→分岐→エラーハンドリング、という“流れの文法”を掴む。 - Integration Hubの役割
「外部連携を再利用可能な部品として扱う」ことを、定義レベルで理解する。 - Connection Aliasと運用目線
接続情報を分離し、環境差分に強くする発想を身につける。 - Zurichの改善点は“方向性”として見る
開発体験の改善、運用品質の改善、という方向性を掴む。
Udemyの自然な使いどころ
独学で詰まりやすいのは、「用語の関係性」と「画面操作の流れ」が頭の中でつながらない瞬間です。
この段階では、体系的に並んだ教材を1本、辞書のように手元に置くのが効きます。
- Flow Designerの基本操作と設計の考え方
- Integration Hubで“どこが連携の責務”なのか
- 接続設定（Aliasや認証）の勘所
こうした内容を、短いハンズオンで確認できるUdemy講座を**「体系的に学べる教材の一例」**として持っておくと、理解の穴埋めがしやすいです（必要な章だけつまみ食いでもOK）。特に、Flow Designer→Integration Hubの順で“位置づけを確認し直す”用途で相性がいいです。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
ZurichでのIntegration Hubは、「外部連携のための便利機能」というより、Workflow Studioの自動化をインスタンス外へ拡張する中核として捉えるのが自然です。
Flow Designerが業務プロセスの骨格を組み立て、Integration Hubが外部システムとのやり取りを再利用可能な部品として提供する。この関係が腹落ちすると、学習も実務もブレにくくなります。
そしてZurichの改善点は、「作りやすさ」だけでなく「止まりにくさ」「運用しやすさ」へ寄っているのがポイントです。RESTのData Stream周りの効率化、MID Serverクラスタ、接続テストの動線、ライセンスの整理など、いずれも“Integration Hubの位置づけが上がっている”ことを示しています。
CSAを目指す段階では、細部の暗記よりも、Flow DesignerとIntegration Hubを一体の自動化設計として理解することが、後々の伸びを作ります。迷ったら「これはプラットフォーム内の自動化か、外部まで含む自動化か」「再利用したい部品か」という問いに戻る。これだけで、Integration Hubの見え方はかなりクリアになります。
