外部APIを呼びに行く出口（送信側REST Message）

ServiceNow から外部のシステムを呼び出したいとき、たとえば「インシデント発生時に外部のチャットへ通知する」「承認結果を別システムへ送る」といった場面で使うのが、送信側の REST 連携です。その中心にあるのが REST Message（sys_rest_message）というテーブルです。その下には HTTP Method（sys_rest_message_fn）がぶら下がります。

この記事では、送信側 REST 連携を機能論だけで説明しません。起点にするのは sys_rest_message（REST Message＝定義）と sys_rest_message_fn（HTTP Method＝呼び出し）の2つのテーブルです。メッセージとメソッドの関係、送信先URL（endpoint）と変数置換、HTTP メソッドの選択肢、認証の継承を扱います。値はすべて PDI（Zurich）の OOTB で確認した実測です。

想定読者は、ServiceNow の Incident や Table API は触ったことがある管理者・開発者です。「ServiceNow が外部APIを叩く側」の裏側、つまりどこに endpoint や認証が保存され、どうメソッドが紐づくかを、これから押さえたい人に向けています。実機で見るのは、メッセージとメソッドの継承・主要フィールド・http_method・認証の継承の4点です。

この記事で分かること

• 送信側 REST 連携（ServiceNow が呼ぶ）と受信側 Scripted REST API（ServiceNow が受ける）の役割の違い。

• REST Message が メッセージ（sys_rest_message）→ HTTP Method（sys_rest_message_fn）の1:N で構成されること。

• 送信先URLが endpoint で決まり、${variable} で変数置換できること。

• sys_rest_message_fn がどんなフィールドを持つか（送信先・本文・認証・経路）。

• http_method（6値）の選択肢と OOTB 実測分布。

• 認証が親（メッセージ）から子（メソッド）へ継承される仕組み。

REST Message（送信側REST連携）とは

ServiceNow の REST 連携には、向きが2つあります。1つは 受信側で、外部から ServiceNow を呼ばせる Scripted REST API（sys_ws_definition / sys_ws_operation）です。もう1つが本記事の 送信側で、ServiceNow 自身が外部の REST API を呼び出すための REST Message（sys_rest_message）です。

定義を格納する中心テーブルは sys_rest_message で、画面ラベルは REST Message です。その下には sys_rest_message_fn（画面ラベルは HTTP Method）がぶら下がります。1つのメッセージに、複数の HTTP Method が紐づく形です。

Scripted REST API は「外から呼ばれる入口を自分で公開する」仕組みです。REST Message は「外を呼びに行く出口を自分で定義する」仕組みで、ちょうど逆を向いています。Qiita などの解説でも、REST Message は外部APIへの接続情報（endpoint・認証・本文）を1か所にまとめる入れ物として紹介されています。スクリプト（RESTMessageV2）から、その入れ物を呼び出します。

今回確認した PDI（Zurich / OOTB）では、sys_rest_message（メッセージ）は 4 件でした。sys_rest_message_fn（HTTP Method）は stats で 6 件ありました（うち実機リストで取得できたのは 4 件・後述）。受信側の Scripted REST API（Service 225 件・Resource 1,158 件）と比べると桁違いに少なく、送信側の OOTB 定義は限定的です。OOTB のメッセージは Firebase Cloud Messaging（プッシュ通知）や Yahoo Finance など、ServiceNow が外部サービスを呼ぶための例でした。

メッセージと HTTP Method の関係（継承とリンク）

REST Message に関係するテーブルは、「メッセージ（定義）」「HTTP Method（呼び出し）」「ヘッダ（子）」に分けて見ると整理できます。

継承とリンクの構造

今回確認した PDI（Zurich / OOTB）では、それぞれ次の構造でした。

• sys_rest_message（REST Message / 定義） … super_class は sys_metadata（Application File）でした。task は継承していません。固有フィールドは 13 です。

• sys_rest_message_fn（HTTP Method / 呼び出し） … こちらも sys_metadata（Application File）を継承していました。固有フィールドは 17 です。

• リンク … HTTP Method の rest_message（REST Message）が sys_rest_message を参照します。どのメッセージに属するメソッドかを、この項目が指します。

つまり、メッセージと HTTP Method はどちらも「メタデータ（設定）」のテーブルで、task のような業務レコードではありません。1つのメッセージの下に、メソッド違いの呼び出しが複数ぶら下がるのが基本構造です。受信側の Scripted REST API（Service → Resource）とまったく同じ「1:N の定義テーブル」の形をしていますが、呼ぶ向きが逆です。

下の実画面は、Firebase Cloud Messaging V1 Send メッセージのフォームです。Endpoint（送信先URL）と Authentication type、そして下部に紐づく HTTP Methods 関連リストが確認できます。

テーブル定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_rest_message_list.do?sysparm_query=ORDERBYname

送信先URLの組み立て（endpoint ＋ 変数置換）

REST Message でまず押さえるのは「どこへ、どう送るか」です。送信先URLは endpoint フィールドで決まり、メッセージ側と HTTP Method 側のどちらにも持てます。

endpoint の決め方と変数置換

組み立ては次の関係でした。

• メッセージ（sys_rest_message）の rest_endpoint（Endpoint） … 外部APIのベースURL。必須フィールドでした。例として Firebase Cloud Messaging V1 Send の endpoint を見ます。値は https://fcm.googleapis.com/v1/projects/${project_id}/messages:send でした。

• 変数置換 … endpoint には ${project_id} や ${pushHost} のような ${変数} を埋め込めます。実行時に実際の値へ置き換わるため、1つのメッセージを宛先違いで使い回せます。OOTB の ServiceNowMobileApp Push は複数の変数を含んでいました。endpoint は https://${pushHost}/api/now/v1/push/${applicationName}/enqueue です。

• HTTP Method（sys_rest_message_fn）の rest_endpoint … メソッド側にも endpoint があります。親メッセージの endpoint を上書きでき、指定しなければ親のものが使われます。

分担はこうです。メッセージで共通の接続情報（endpoint・認証）を定義し、HTTP Method ごとに動詞（GET/POST 等）と本文を変えます。受信側 Scripted REST API の「base_uri ＋ relative_path」は、公開URLを足し算で作ります。送信側 REST Message は、外部の固定URLに変数を差し込む形です。

公式の Variable substitution in outbound REST messages（Zurich） に、endpoint やリクエスト本文で ${変数} を使う変数置換の仕組みが説明されています。

実際の HTTP Method フォームでは、http_method・Endpoint・Authentication type（Inherit from parent）がまとまっています。

HTTP Method の主なフィールド

sys_rest_message_fn は、「どのメッセージの・どのメソッドで・どこへ・何を・どう認証して」送るかを表す項目を持ちます。役割で分けると、識別/動詞・親への参照・送信先/本文・認証・経路に整理できます。

主なフィールドの代表は次のとおりです。ラベルは画面上の表示名で、実機どおり記載します。

送信内容は content（リクエスト本文）と http_method（動詞）に分かれて持たれています。GET なら本文なし、POST/PUT なら content に JSON などを書きます。

また、rest_message（REST Message）で親メッセージを必ず指します。HTTP Method は単独では存在せず、必ずどこかのメッセージにぶら下がります。経路に関わる use_mid_server（Use MID Server → ecc_agent）も特徴的です。ファイアウォール内や直接インターネットに出られない環境では、MID Server 経由で外部へ送信できます。

全フィールドは、次のURLで一覧できます。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_rest_message^elementISNOTEMPTY

HTTP メソッド（http_method）

各 HTTP Method は、どの HTTP メソッドで外部を呼ぶかを http_method で持ちます。これは task 系の State のような業務状態ではなく、REST の動詞です。

今回確認した PDI（Zurich / OOTB）の sys_rest_message_fn.http_method は、次の6値でした（value = label, sequence順）。

選択肢は GET / POST / PUT / PATCH / DELETE / HEAD の6値でした。受信側の sys_ws_operation が5値（HEAD なし）だったのに対し、送信側は HEAD を含む6値です。送信時にヘッダだけ確認したい場合などに HEAD が使えます。

OOTB の件数分布は、stats（aggregate count）で全6件のうち GET が 1、POST が 2、残り2件は http_method が空でした（未設定）。一般的な REST の慣習では、GET=取得／POST=送信/処理起動／PUT=置換更新／PATCH=部分更新／DELETE=削除／HEAD=ヘッダのみ取得と使い分けます。OOTB の送信メッセージは、プッシュ通知系の POST が中心でした。母数が少ないため、この分布は傾向ではなく「OOTB にたまたまある定義の内訳」として読んでください。

http_method の選択肢は、次のURLで一覧できます。

https://<YourInstance>/sys_choice_list.do?sysparm_query=name=sys_rest_message_fn^element=http_method^inactive=false^ORDERBYsequence

認証の継承（メッセージ → HTTP Method）

外部APIを呼ぶ以上、REST Message は「どう認証するか」を持ちます。認証はメッセージ（親）と HTTP Method（子）の2層で考えます。

メッセージと HTTP Method、それぞれの認証設定

今回確認した PDI（Zurich / OOTB）では、次の傾向でした。

• メッセージ（sys_rest_message）の authentication_type … 選択肢は4値でした。No authentication / Basic / Basic (simple) / OAuth 2.0 で、既定は No authentication です。OOTB の4件はすべて No authentication で、認証情報は変数や実行時に差し込む想定と読めます。

• HTTP Method（sys_rest_message_fn）の authentication_type … 選択肢は上記4値に1つ足した5値です。加わるのは Inherit from parent（親から継承）で、既定もこの値でした。OOTB の HTTP Method は全6件が inherit_from_parent で、親メッセージの認証をそのまま使う形でした。

• プロファイル参照 … Basic は basic_auth_profile（→ sys_auth_profile_basic）を参照します。OAuth 2.0 は oauth2_profile（→ oauth_entity_profile）です。相互TLS は protocol_name（→ sys_protocol_profile）を使います。いずれも別レコードの認証プロファイルを指します。

認証はメッセージで一度決めれば、配下の HTTP Method が既定で継承します。子側で明示的に別の認証を選べば、そのメソッドだけ親を上書きできます。実画面のメッセージフォーム上部にも、次の案内が出ていました。「Authentication configured on the REST Message will automatically apply to child HTTP Methods」。メッセージの認証は子 HTTP Method に自動適用される、という意味です。

公式の Outbound REST authentication（Zurich） に、Basic・OAuth 2.0・相互認証など送信側 REST の認証方式が説明されています。

REST Message に関わる周辺機能

REST Message の動きも、フィールド定義だけでは決まりません。保存時の処理やテスト送信、権限など、複数の設定が組み合わさって動きます。大まかには、保存時の処理は Business Rule、テスト送信などの操作は UI Action、権限は ACL が関係します。

今回確認した PDI（Zurich / OOTB・active 中心・2026-06-21 確認）では、メッセージ / HTTP Method に次のような設定が紐づいていました。

ここで数えているのは、sys_rest_message / sys_rest_message_fn という「定義テーブル」に直接紐づく設定だけです。実際の送信処理を決めるのは、各メッセージを呼び出す RESTMessageV2 スクリプト（Business Rule や Script Include の中身）です。そこに変数置換・認証プロファイル・MID Server の設定が合わさります。定義テーブルの周辺設定だけを見て、連携全体の挙動やセキュリティを判断しないようにします。

自分のインスタンスでは、次のURLで各一覧を開けます（先頭の <YourInstance> は置き換えてください）。

HTTP Methods（全件）: https://<YourInstance>/sys_rest_message_fn_list.do?sysparm_query=ORDERBYfunction_name
Business Rules      : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=sys_rest_message
Access Controls     : https://<YourInstance>/sys_security_acl_list.do?sysparm_query=name=sys_rest_message

ServiceNow における REST Message のポイント

• REST 連携には向きがある。受信側 Scripted REST API（外から呼ばれる入口） と 送信側 REST Message（外を呼びに行く出口） で、ちょうど逆向きです。

• 送信側は sys_rest_message（メッセージ）→ sys_rest_message_fn（HTTP Method）の1:N で構成されます。どちらも Application File（sys_metadata）を継承する定義テーブルで、固有フィールドはメッセージ 13・HTTP Method 17 でした。

• 送信先URLは endpoint で決まり、${変数} で変数置換できます。メッセージで共通の接続情報を定義し、HTTP Method ごとに動詞（http_method）と本文（content）を変えます。

• http_method は GET / POST / PUT / PATCH / DELETE / HEAD の6値（受信側より HEAD が1つ多い）。今回の PDI ではメッセージ 4 件・HTTP Method は stats 6 件（実機リストで確認できたのは 4 件）。

• 認証はメッセージ（親）→ HTTP Method（子）で継承されます。子は既定 Inherit from parent で、必要なら子側で上書きできます。

REST Message を調べるときは、まず「このメッセージは、どの外部 endpoint を、どの認証で呼ぶか」を読みます。次に見るのは、HTTP Method 単体ではありません。上のメッセージ（endpoint・認証）、横の content・http_method、呼び出し元のスクリプトをセットで追います。

実機を見て気づいたこと

• OOTB の4件は全部サンプルだろうと思っていましたが、Yahoo Finance のメッセージは GET で http://finance.yahoo.com/d/quotes.csv という実在の外部URLをそのまま指していました。PDI には最初から、本物のインターネットAPIを呼ぶ設定が1つ入っているということです。

• ヘッダを定義する子テーブルを見ると、メッセージ側の sys_rest_message_headers は4件あるのに対し、HTTP Method 側の sys_rest_message_fn_headers・sys_rest_message_fn_parameters はどちらも0件でした。てっきりメソッドごとにヘッダを個別調整するものだと思っていましたが、OOTB ではヘッダはメッセージ単位でまとめて持ち、メソッド側での上書きは使われていませんでした。

次に読むなら

次に確認するなら、RESTMessageV2 スクリプトAPIでの実行です。対象は setStringParameter での変数差し込み、execute() / executeAsync() の実行です。レスポンスは getBody() / getStatusCode() で読み取ります。Variable Substitutions（変数）と HTTP ヘッダの設定、REST Message フォームの Test での実送信確認も残っています。特に「定義（テーブル構造）」と「実行（RESTMessageV2 スクリプト）」を分けて理解すると、外部連携が動かないときの切り分けが一気に楽になります。これらは本記事の「送信先URLの組み立て」「HTTP Method の主なフィールド」で触れた仕組みの先にあたり、別記事で扱う予定です。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• 送信側 REST 連携：ServiceNow が外部の REST API を呼び出すこと（Outbound）

• 受信側 REST 連携：外部が ServiceNow を呼び出すこと（Inbound・Scripted REST API）

• REST Message（sys_rest_message）：外部APIへの接続定義（endpoint ＋ 認証）

• HTTP Method（sys_rest_message_fn）：メッセージ配下の1呼び出し（method ＋ content）

• endpoint：送信先URL（${変数} で変数置換できる）

• MID Server：ファイアウォール内から外部へ中継する ServiceNow のエージェント

自分の環境で確認するときのURL

先頭に自分のインスタンスを付けると、同じ画面が開けます。

REST Message 一覧 : sys_rest_message_list.do?sysparm_query=ORDERBYname
HTTP Method 一覧  : sys_rest_message_fn_list.do?sysparm_query=ORDERBYfunction_name
フィールド一覧    : sys_dictionary_list.do?sysparm_query=name=sys_rest_message^elementISNOTEMPTY
http_method       : sys_choice_list.do?sysparm_query=name=sys_rest_message_fn^element=http_method^inactive=false^ORDERBYsequence
テーブル定義      : sys_db_object_list.do?sysparm_query=name=sys_rest_message^ORname=sys_rest_message_fn

検証範囲とおことわり

• 確認した範囲：sys_rest_message / sys_rest_message_fn の階層（Application File 継承）、固有フィールド数（メッセージ 13 / HTTP Method 17）、http_method の選択肢（6値）と分布、authentication_type の選択肢（親4値 / 子5値・Inherit from parent 追加）と実測、主要フィールドと参照先（rest_message / rest_endpoint / oauth2_profile / use_mid_server）、レコード件数、周辺設定件数。すべて PDI（Zurich / 2026-06-21 確認）の OOTB で取得しています。

• 確認していない範囲（断定しません）：RESTMessageV2 スクリプトAPIの挙動（execute / executeAsync・レスポンス取得）。変数置換の実行時動作、MID Server 経由送信の実挙動。Basic / OAuth 2.0 / 相互認証の各認証フローの実動作。Table API から非可視だった sys_rest_message_fn 2件・sys_rest_message_headers 4件の中身。本番でのカスタムメッセージのセキュリティ設定。これらは別記事で扱います。