ZurichでREST連携を使うべきか迷ったときの判断基準まとめ

REST連携を語る前に押さえる前提 Zurichで変わらない考え方

ServiceNowで「REST連携」と言ったとき、実は選択肢がいくつかあります。代表的なのは次の3つです。

• 外部へ呼び出す：Outbound REST（REST Message、スクリプト実行など）
• 外部から呼ばれる：Inbound REST（Scripted REST APIなど）
• ローコードでつなぐ：Flow Designer / IntegrationHub のアクション（RESTステップなど）

ここで大事なのは「RESTを使える」ことより、なぜRESTを選ぶのかです。RESTは万能ではありますが、万能ゆえに設計の幅が広く、最初の判断を誤ると運用が苦しくなります。たとえば、ちょっとした外部通知のつもりで作った連携が、いつの間にか複雑な同期処理に育ってしまい、障害時の切り分けが地獄になる…みたいな話はよくあります。

判断の軸を作るために、まず「連携は結局、何を解決したいのか」を3つに分けます。

• データの同期：レコードを作る・更新する・取り込む
• 業務の自動化：ある条件で外部アクションを起こす、ワークフローを進める
• 体験の統合：ポータルやUIから外部情報を見せる、外部操作をする

そしてZurichで特に押さえたいのが「秘密情報の扱い」です。今のServiceNowの基本姿勢は、連携で使う接続先や認証情報をConnections / Credentials / Aliasesで管理し、スクリプトやフローにベタ書きしない方向です。Flow DesignerやIntegrationHubなど、多くの機能がこの枠組みを前提にしています。
さらに、CredentialsやConnectionsに対してスコープ保護の考え方も用意されています。アプリやスコープを跨いだ「うっかり参照」事故を減らすための仕組みです。

CSA学習者の目線だと、ここは暗記ポイントというより「設計思想の理解ポイント」です。
連携の作り方が複数あっても、根っこの考え方はわりと一貫しています。

---

まずはREST以外を検討する 標準機能とIntegrationHubの立ち位置

RESTを選ぶ前に、あえて確認しておきたいことがあります。本当にRESTが必要ですか、という問いです。

たとえば外部システムがServiceNow連携に慣れている場合、Table APIなど標準APIの利用で済むことがあります。一方で、相手が独自仕様のAPIや独自の認証方式を持っていたり、オンプレ環境でネットワーク制約が強いと、こちら側で工夫が必要になりがちです。

ここで整理しておくと、選択肢はだいたい次の順で検討すると判断がブレにくいです。

標準機能で済むなら標準機能に寄せる

標準APIや既存の機能で満たせる要件は、基本的にそちらが運用しやすいです。
理由はシンプルで、アップグレード追従やセキュリティの前提が揃っていて、チーム内の引き継ぎもしやすいからです。

ローコードの強みを活かせるならIntegrationHubを検討する

IntegrationHubのRESTステップは、外部へのRESTリクエストをフローやアクションの中で扱えます。加えて、接続情報をエイリアスで管理し、環境差（開発・本番など）にも対応しやすい設計ができます。
また、RESTステップはIntegrationHubのサブスクリプションが前提という注意点もあります。機能面だけでなく、契約や運用体制も判断材料になります。

それでも足りないときにRESTを使う

「標準機能では表現できない」「ローコードだけだと厳しい」なら、REST（＋スクリプト）に落とします。
ここでようやく、RESTMessageV2やScripted REST APIといった具体の選択に入ります。

この順番にしておくと、設計レビューでも話が早いです。「なぜRESTなのか」が説明できるからです。

---

RESTMessageV2を選ぶ判断基準 スクリプトで握る価値がある場面

OutboundのRESTを、スクリプトで自由に握りたいときに出てくるのがRESTMessageV2です。ServiceNow公式でも、スクリプト可能な場所ならOutbound RESTを送れる、と整理されています。
また、直接RESTMessageV2を使った例も用意されています。例ではtry-catchでエラー処理をしており、呼び出し失敗が前提で設計するのが自然だと分かります。

判断基準を、実務で迷いがちなポイントに寄せてまとめます。

1 回の呼び出しに細かい制御が必要

• ヘッダーやボディの組み立てが複雑
• 返却値を条件分岐に使い、例外処理も含めて制御したい
• 失敗時に独自のリトライやフォールバックを入れたい

ローコードで表現できても「読めないフロー」になりそうなら、スクリプトでシンプルにした方が運用が楽なことがあります。

実行タイミングがフローに乗らない

たとえばビジネスルール、スクリプトインクルード、ジョブなど、既にスクリプト主体の設計になっている場合、RESTMessageV2で揃えた方が整合が取れます。

体験統合で秘密情報をクライアントに出したくない

UIから外部APIを叩きたいケースでも、クライアントから直接外部へ行くのは避けたいことが多いです。
理由は単純で、APIキーやトークンが露出しやすいからです。サーバ側でRESTMessageV2を叩く設計に寄せると、秘密情報を守りやすくなります（秘密情報の保管はConnections/Credentials/Aliasesに寄せるのが基本線）。

ただしRESTMessageV2に寄せすぎると起きる問題

スクリプトは自由度が高い分、チーム運用だと属人化しやすいです。
また、連携が増えるほど「似たような呼び出し処理」が散らばりがちです。エンドポイントや認証方式が変わったときの修正範囲が読みにくくなります。

このあたりで迷ったら、次の章のIntegrationHub寄りの判断軸と比較すると腹落ちしやすいです。

---

IntegrationHubのRESTステップを選ぶ判断基準 低コード運用に寄せる場面

RESTステップは、フローやアクションの一部としてアウトバウンドRESTを実行するための部品です。
ポイントは「呼べる」ことではなく、運用しやすい形で呼べることです。

連携を部品化して再利用したい

同じ外部APIを複数の業務で使う場合、アクション化しておくと再利用が楽です。フロー側は「このアクションを呼ぶ」だけになり、実装詳細を隠せます。

接続先や認証情報を環境ごとに差し替えたい

RESTステップは、接続情報をインライン定義することもできますが、現実には「環境差」が厄介です。
そこで Connection Alias を使う設計に寄せると、接続先変更や認証差し替えの影響範囲が小さくなります。公式ドキュメントでも、エイリアスを使うことで複数環境での再設定を減らせる旨が説明されています。

実装担当と運用担当が分かれている

実務でありがちなのが「作った人しか直せない」問題です。
フローで見える化できる範囲が増えるほど、運用側の自己解決力が上がります。もちろん、難しい部分はスクリプトに逃がしてもいいのですが、まずローコードに寄せる価値はあります。

ライセンスと運用コストを先に見積もる

RESTステップはIntegrationHubが前提です。
つまり「技術的にベスト」でも、契約や運用体制が合わないなら別解になります。
このあたりは設計というより、プロジェクト全体の判断になります。

---

Zurichで事故を減らす設計ポイント 認証・秘密情報・セキュリティ・運用

最後に、REST連携で詰まりやすいところを「判断基準」ではなく「事故予防」の視点でまとめます。
CSA学習にも繋がるのは、ここが単なる手順ではなく、プラットフォームの考え方が出やすいからです。

認証はスクリプトに埋め込まない

Outbound REST Messageの作成手順では、OAuth 2.0を含む認証設定が前提として整理されています。
そして今のServiceNowは、Connections / Credentials / Aliases で統一的に管理する前提が強いです。

実務の落とし穴は、検証の勢いで「一時的に」トークンやAPIキーをスクリプトに書いてしまうことです。動くのは早いのですが、後で必ず苦しみます。
まずはエイリアスで管理できないかを検討し、難しい場合でも保管場所を決め、棚卸しできる状態にしておくのが安全です。

スコープと権限の境界を意識する

Connections/Credentialsは重要情報なので、スコープ保護の考え方が用意されています。
アプリ開発や複数チーム運用が進むほど「見えてはいけないものが見える」事故が起きやすくなります。連携は特に影響が大きいので、早めに境界を意識しておくと後が楽です。

Inboundを作るならScripted REST APIの作法を守る

外部からServiceNowを叩かせる場合、Scripted REST APIで独自エンドポイントを提供する設計もあります。ここは自由度が高い分、作法が重要です。
公式のガイドでも、GETは参照のみ、POSTは作成、PUT/PATCHは更新…といったRESTの慣習に沿うことが推奨されています。
この作法に従うだけで、外部利用者の理解コストが下がり、将来的なメンテもしやすくなります。

失敗を前提にログと切り分けを用意する

REST連携は、相手都合で落ちます。ネットワークも落ちます。タイムアウトも起きます。
だから「失敗したときに、誰が何を見れば原因に辿り着けるか」を先に決めるのが重要です。スクリプトならtry-catchを含めた設計が取りやすく、公式の例でも例外処理が前提になっています。

迷ったときの最短チェックリスト

最後に、判断を一気に固めるためのチェックリストを置いておきます。

• 標準機能や既存APIで要件を満たせるか
• 連携はデータ同期か、業務自動化か、体験統合か
• 運用担当がフローで追える形が望ましいか
• 接続先や認証情報の差し替えが頻繁に起きるか
• スクリプトで細かく制御する必要があるか
• 秘密情報を安全に保管できる設計になっているか
• 失敗時の切り分け手順が想像できるか

これを通して、ローコード寄りならIntegrationHub、制御寄りならRESTMessageV2、受け口が必要ならScripted REST API、という整理が自然にできます。

学び方の一例としてのUdemy活用

もし「判断軸は分かったけど、実装の粒度で不安が残る」という場合は、体系的に触れる教材を1つ持っておくと安心です。
Udemyには、Flow DesignerとIntegrationHubの基本から、Outbound RESTの扱い、認証情報の管理の考え方までを一通り触れられる講座があります。手を動かしながら「なぜそう設計するのか」を確認できるものを選ぶと、暗記に寄らず理解が進みやすいです。

---

まとめ

ZurichでREST連携を使うか迷ったときは、「RESTを使えるか」ではなく「RESTを使う理由が説明できるか」で判断するとブレません。まずは標準機能や既存APIで済むかを確認し、次にローコードで運用しやすいIntegrationHubに寄せられるかを考えます。それでも要件を満たせない、あるいは細かな制御が必要ならRESTMessageV2でスクリプト主体にする。外部から呼ばれる受け口が必要ならScripted REST APIを作り、RESTの作法とセキュリティを守る。さらに、接続情報や認証情報はConnections/Credentials/Aliasesで管理し、スコープや権限の境界を意識して事故を減らす。この順番で考えるだけで、連携の設計が「場当たり」から「再現性のある判断」に変わります。