ServiceNowに最初から入っているREST連携は今も動く？ sys_rest_messageの4件をRESTMessageV2で実機に投げてみた

2026年8月10日 08:15

OOTBのREST Message定義は、設定画面に並んでいるだけで、今も動くとは限りません。ServiceNowのsys_rest_messageには出荷時から4件のレコードが入っていますが、そのうちの1つ「Yahoo Finance」を実際にRESTMessageV2で実行すると、名前解決の時点で失敗しました。生きている宛先には同じ書き方で届くことも確かめ、標準の連携定義を業務で使う前に何を確認すべきかをまとめます。

検証環境：Zurich PDI / OOTB / 2026-08-10 確認

結論：定義があることと、動くことは別

先に全体像です。

OOTBのsys_rest_messageはわずか4件でした。Firebase Cloud Messaging向けが2件、モバイルアプリのプッシュ通知向けが1件、株価情報を取得する「Yahoo Finance」が1件で、認証方式はすべてno_authenticationです。
Yahoo Financeを名前で実行すると、名前解決の時点で失敗しました。getStatusCode()は0、getErrorMessage()は「Unknown host」です。設定上のエンドポイントはfinance.yahoo.comなのに、サーバログに出てきたホスト名はdownload.finance.yahoo.comという別の名前でした。
同じ書き方で生きている宛先に投げると、200で成功しました。「PDIから外部に出られない」という話ではありません。この定義の相手先が今は応答しない、という切り分けができます。

下の画像が、Scripts - Backgroundで両方を実行した結果です。Yahoo Financeの失敗と、公開テスト用エンドポイントhttpbin.orgへの成功が1画面に並んでいます。

この記事が焦点を当てるのは、通信が届かないという障害対応ではありません。標準機能として最初から用意されている連携定義を、業務に使う前にどう確かめるかです。ここから、この2つの実行結果を追いながら、標準で用意された連携定義を使う前に確かめておきたいことを整理します。

sys_rest_messageの4件を棚卸しする

ServiceNowから外部を呼び出す送信側REST連携の定義は、sys_rest_messageというテーブルに入っています。少ないと感じました。Zurich PDIでこのテーブルを開くと、件数はわずか4件でした。内訳はFirebase Cloud Messaging向けが2件（新旧の形式が1件ずつ）、モバイルアプリのプッシュ通知向けが1件、株価情報を取得する「Yahoo Finance」が1件です。どれも自分で作った連携ではありません。初期状態から入っているサンプル的な定義でした。

内訳をもう少し見ると、Firebase Cloud Messaging向けの2件は、名前から見る限りモバイルアプリへのプッシュ通知配信で使う定義です。新しいV1 Sendと古い形式のSendが両方残っていて、Google側のAPI移行に合わせて新旧が並んで置かれている様子がうかがえます。ServiceNowMobileApp Pushは、ServiceNow純正のモバイルアプリ向けにプッシュ通知を送るための定義です。Yahoo Financeだけが業務アプリとは無関係な、株価情報を取得するサンプルという毛色の違うレコードでした。

4件とも認証方式はno_authenticationでした。認証情報の設定が要らない分だけ手軽に見えますが、認証が不要であることと、宛先が今も応答することはまったく別の話です。むしろ認証が絡まない分だけ、動くかどうかの確認を後回しにしやすいレコード群だとも言えます。次の節では、この中の1件を選び、実際に名前で呼び出してみます。

OOTBの「Yahoo Finance」を名前で実行してみると、名前解決の時点で失敗した

送信側REST連携をスクリプトから呼ぶ場合、RESTMessageV2というAPIを使います。設定済みのレコードを対象にするなら、URLを直接書き込む必要はありません。

var req = new sn_ws.RESTMessageV2('Yahoo Finance', 'get');
req.setHttpTimeout(15000);
var res = req.execute();

sys_rest_messageのレコード名と、その下にぶら下がるsys_rest_message_fn（HTTP Method）の名前を文字列で渡すだけで、エンドポイントや認証設定はレコード側から読み込まれます。業務コードでBusiness RuleやScript Includeが外部APIを呼ぶときも、多くはこの書き方です。URLを直接書くよりも設定変更に強い呼び方だと言えます。

この呼び出し方には利点があります。後からエンドポイントや認証方式の設定を変更しても、呼び出し側のスクリプトを直す必要がありません。裏を返すと、呼び出し側のコードを読んだだけでは、その定義が実際にどこへ通信しているかまでは分からないということでもあります。動くかどうかを知りたければ、コードを読むだけでは足りません。実際に1回動かして確かめるほかありません。書き方はいつも同じです。

なぜOOTBのサンプルで確かめたのか

任意のURLへGETを送るだけでも動作確認にはなります。ですが現場で実際に困るのは、すでに設定済みのREST Messageが動いているかどうか分からないという場面です。担当者は自分でURLを打ち込むのではなく、一覧に並んでいるレコードの1つを指して「これは今も生きていますか」と聞いてきます。今回、あえて任意のURLではなく設定済みのレコードを名前で呼び出したのは、この聞かれ方に近い形で確かめたかったためです。

実行結果：getStatusCode()は0、エラーは「Unknown host」

実行結果は、getStatusCode()が0、getErrorMessage()は「Unknown host」でした。サーバのログには「Unknown host: download.finance.yahoo.com」という行も出力されていました。ここで気づいたのは、設定上のエンドポイントがfinance.yahoo.comであるのに対し、実際に名前解決を試みたホストはdownload.finance.yahoo.comという別の名前だったことです。この違いがなぜ生まれるのかはプラットフォーム内部の実装によるもので、検証範囲外とし、断定はしません。Yahoo側の古いリダイレクト設定が関係している可能性はありますが、裏取りはしていません。

はっきり言えるのは、このPDIから見るとYahoo Financeの送信先ホストが名前解決できず、通信が成立していないという事実です。無料のCSV配信APIが終了したという話はWeb上でよく見かけますが、その裏取りは今回していません。実機で確認できたのは名前解決できなかったという1点だけです。

対比：生きているエンドポイントには同じ書き方で届く

失敗の例だけでは、sys_outbound_http_logへの記録が失敗したときだけ動くのか、成功したときも動くのかが分かりません。対照実験が要ります。そこで成功する通信も1つ用意しました。使ったのはhttps://httpbin.org/getです。認証不要・GETのみ・副作用が無い公開のテスト用エンドポイントで、リクエストの内容をそのままJSONで返すサービスとして開発者の間で広く使われています。新しいREST Messageレコードは作らず、スクリプトの中で直接エンドポイントを指定して呼び出しました。

var req2 = new sn_ws.RESTMessageV2();
req2.setHttpMethod('GET');
req2.setEndpoint('https://httpbin.org/get');
var res2 = req2.execute();

宛先に商用サービスを選ばなかった理由

宛先に実在の企業サービスを選ばなかったのには理由があります。検証目的で外部の商用APIへ繰り返しアクセスすると、相手に不要な負荷をかけてしまいます。httpbin.orgはもともと開発者の動作確認用に公開されているサービスで、今回のような1〜2回のGETであれば想定された使い方の範囲内です。呼び出し回数も必要最小限にとどめました。動作確認のためとはいえ、検証対象ではない外部サービスへの配慮は欠かせません。

結果は200。所要時間にも差が出た

こちらはgetStatusCode()が200、getErrorMessage()は空でした。返ってきた本文の先頭には"User-Agent": "ServiceNow/1.0"という文字列が含まれていて、PDIから送られたリクエストのヘッダをそのまま確認できました。所要時間はYahoo Financeの1,339〜2,524ミリ秒に対して、httpbin.orgは330〜459ミリ秒と、成功した通信のほうが明確に短時間で終わっています。

この対比から分かること

この2つの実行結果を並べると、RESTMessageV2というAPI自体やPDIの通信環境そのものには問題が無いことが分かります。書き方は共通で、違いは宛先だけでした。宛先が生きていれば200で戻り、宛先側が応答しなければgetStatusCode()は0になります。「連携の書き方が悪いのか、相手先が悪いのか」を切り分けたいとき、まず疑うべきは多くの場合コードのほうではなく相手先だということが、この対比からも読み取れます。原因の芯は、宛先でした。

成功と失敗で、記録の何が違うか

ここまでの結果を1つの表にまとめました。

注目したいのはgetStatusCode()とsys_outbound_http_log.response_statusの値です。失敗したリクエストでは、スクリプトAPIが返すgetStatusCode()は0でしたが、ログテーブルに保存されたresponse_statusは-1でした。同じ1回の失敗に対して、API側とログテーブル側で異なる数値が使われています。存在しないホスト名で起きる別の失敗パターンでも同じ不一致が確認されており、今回のように実在しそうで名前解決に失敗するOOTBサンプルでも同じ傾向が再現しました。

この不一致を知らずに調査すると、混乱のもとになります。スクリプトのログでgetStatusCode()=0だけを見て「通信自体が発生していない」と早合点すると、実際にはsys_outbound_http_logに記録が残っているのに見落としかねません。数値を見るときは、いま自分がどちらの値を見ているのかを意識しておく必要があります。

記録はsys_outbound_http_logに残る、ecc_queueは通らない

2つの通信を実行する前後で、ecc_queueとsys_outbound_http_logの件数も数えています。ecc_queueは実行前後で件数が一致し、差分はゼロでした。一方sys_outbound_http_logは2件増えており、成功・失敗のどちらも同じテーブルに記録されることが分かります。同じスクリプトを2回実行しても、差分のパターン（ecc_queueは0・sys_outbound_http_logは+2）は完全に一致しました。

この図が示すのは、RESTMessageV2による直接送信では、成功しても失敗しても記録が同じテーブルに集まるという経路です。MID Serverを使う構成であればecc_queueも経路に加わりますが、今回のような直接送信ではそのルート自体が最初から選ばれません。

Outbound HTTP Logs一覧をCreated（作成日時）の降順で開くと、先頭2行が今回実行したhttpbin.orgとfinance.yahoo.comの結果です。

なぜecc_queueだけ差分ゼロだったのか

RESTMessageV2はインスタンスから直接HTTP通信を送るAPIで、途中にMID Serverを挟む設定を明示的に行わない限り、ECC Queueという待ち行列を経由しません。今回の2回の呼び出しはどちらもMID Serverを指定していないため、この経路自体が使われていないだけです。言い換えると、直接送信の経路を調べているときにecc_queueを見て「動いていない」と判断するのは意味を持ちません。見るべきテーブルを取り違えないことが、この先の調査時間を左右します。

ECC Queueの中身や、MID Serverが0台の環境で何が起きるかは、以前に実機で追った記事のほうが詳しく扱っています。連携が届かないという相談を受けたときにどのテーブルを見るかは、外部連携が届かないときどこを見る？ ECC Queueに答えが無い理由を参照してください。

実機で気づいたこと

いちばん気づかされたのは、OOTBのサンプルデータを「動くはず」と決めつけていた自分自身でした。Yahoo Financeは初期状態から入っているレコードで、見た目には何年も変わっていないように見えます。ですが宛先のサービス側は当然変化し続けており、設定画面だけを眺めていても実際に動くかどうかは分かりません。定義が存在することと、その定義が今も機能することは別の話だと実感しました。

もう1つ気づいたのは、設定上のエンドポイント（finance.yahoo.com）と、実際に名前解決を試みたホスト名（download.finance.yahoo.com）が食い違っていたことです。REST Messageのフォーム画面を見るだけでは、この違いには気づけません。実際に実行してサーバログまで読んで初めて見えてくる差でした。

意外だったのは、失敗したYahoo Financeへの通信のほうが、成功したhttpbin.orgへの通信よりも時間がかかっていたことです。エラーというと一瞬で終わる印象がありましたが、名前解決の失敗そのものにも相応の時間がかかっていました。download.finance.yahoo.comという一見実在しそうなホスト名に対して、DNSへの問い合わせが実際に行われ、応答が返るまで待つことになったためだと見ています。

以前の記事で使った、存在しないトップレベルドメイン（.invalid）宛てのGETは、ローカルの仕組みだけで即座に失敗と判定されるため、応答時間はごく短時間でした。今回のように実在するトップレベルドメインに対しては、DNSサーバへの問い合わせが実際に発生した分だけ時間がかかっています。同じ「名前解決失敗」でも、宛先の文字列がどこまで実在に近いかによって、失敗までの体感速度が変わることに気づきました。

no_authenticationという表示にも見方が変わりました。認証設定が無いというのは「手軽に使える」という意味であって、「相手が今も応答する」という保証ではありません。この2つを混同していると、設定画面を眺めただけで「準備ができている」と判断してしまいます。

Firebase Cloud Messaging向けの定義が新旧2件とも残っていた点も印象に残りました。片方だけ消さずに両方置いてあるということは、切り替え時期にどちらを使うか迷った利用者が過去にいた、あるいは移行が完了していないまま両方が使われている可能性を感じさせます。実際に動いているかどうかまでは今回確認していませんが、レコードが並んでいる本数だけでも運用の歴史が透けて見えることに気づきました。

気づきは細かいものばかりでした。ですが1つずつ拾っていくと、「動くはずだと決めつけない」という同じ結論に行き着きます。設定画面の情報だけで判断せず、実際に1回動かしてみる。それだけで防げる失敗は、思っているより多いはずです。

実務では何に使えるか：標準の連携定義を使う前に確認する手順

開発環境を本番環境へ移行するとき、sys_rest_messageのレコードもUpdate Setなどに乗って一緒に運ばれます。誰かが意図して作った連携だけでなく、初期状態から入っていたサンプルまで、気づかないうちに本番へ持ち込まれるケースは珍しくありません。持ち込まれたレコード自体に害は無いものの、「設定画面に並んでいる＝使える」と思い込んだまま放置するのは危険です。実際に必要になったタイミングで初めて失敗に気づく、という展開になりかねません。

たとえば、通知連携のBusiness Ruleがtry-catchでエラーを握りつぶす作りになっていると、この種の失敗は画面にも通知にも出てきません。処理自体は正常に完了したように見え、実際には何も届いていない、という状態が静かに続くことになります。本番環境に標準の連携定義を組み込む、あるいは既存の定義を流用するときは、次の順番で確認すると失敗に気づきやすくなります。

まず1回、名前で実行してみます。設定を読むだけでなく、実際に動くかどうかを確かめます
getStatusCode()だけでなくgetErrorMessage()とサーバログの両方を見ます。0や-1のような数値だけでは原因が分かりません
設定上のエンドポイントと、エラーメッセージに出てくるホスト名が一致しているかを見比べます。今回のように食い違うことがあります
認証方式がno_authenticationでも、それだけで「安全に使える」と判断しません。相手が生きているかどうかは別の確認が要ります
本番投入前に、生きていると分かっている先へ同じ書き方で投げてみて、コードの書き方自体に問題が無いかを切り分けておきます
定義済みのOOTBサンプルを流用する場合は、疎通確認を1回きりで終わらせず、定期的に確かめる対象としてリストに残しておきます

この手順は障害調査だけでなく、新しい連携を組み込む前の事前確認にも使えます。本番投入前に一度だけ疑わしい呼び出しを実行し、sys_outbound_http_logに想定通りの1行が増えるかを確かめておけば、リリース後に「そもそも呼ばれていなかった」という事態を避けやすくなります。手順自体は今回のスクリプトとほぼ同じで、対象のレコード名とエンドポイントを差し替えるだけで流用できる作りです。

この考え方はsys_rest_messageに限った話ではありません。LDAPサーバやメールサーバなど、初期設定や過去の作業として残っている接続定義全般に当てはまります。設定画面に登録されていることと、その接続先が今も使えることは別の情報だと意識しておくと、思わぬところでの手戻りを減らせるはずです。

用語

sys_rest_message：ServiceNowから外部を呼び出す送信側REST連携の定義（REST Message）。1レコードが1つの呼び出し先に対応する
sys_rest_message_fn：REST Messageの下にぶら下がるHTTP Method（GET・POSTなど）の定義
RESTMessageV2：REST Messageのレコードを名前で呼び出す、またはURLを直接指定して実行するスクリプトAPI
sys_outbound_http_log：ServiceNowから外部への全てのHTTP通信を記録するログテーブル。成功・失敗を問わず1回の通信につき1行増える
ecc_queue：MID Serverとのメッセージをやり取りするキュー。MID Serverを介さない直接送信では使われない
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま、という意味で使われる）

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

REST Message 一覧        : sys_rest_message_list.do?sysparm_query=ORDERBYname
Outbound HTTP Logs 一覧  : sys_outbound_http_log_list.do?sysparm_query=ORDERBYDESCsys_created_on
ECC Queue 一覧            : ecc_queue_list.do?sysparm_query=ORDERBYDESCsys_created_on
MID Server 登録簿        : ecc_agent_list.do
Scripts - Background      : sys.scripts.do

ServiceNowの外部連携が届かないときどこを見る？ ECC Queueに答えが無い理由 — 今回実行した通信が実際にどのテーブルへ記録されるかを詳しく扱った実務編
外部APIを呼びに行く出口（送信側REST Message） — sys_rest_messageのテーブル構造そのものを掘り下げる前提知識
連携トラブルはまずここ：ECC Queue（ecc_queue） — ECC Queueのフィールド構造を詳しく追う基礎知識

検証範囲とおことわり

確認した範囲は次の3点です。OOTBのsys_rest_messageレコード4件の内容、そのうち「Yahoo Finance」をRESTMessageV2で名前実行した結果、そして公開テスト用エンドポイント（httpbin.org）への直接実行結果です。あわせて、実行前後のecc_queue・sys_outbound_http_logの件数差分（2回実行して再現性を確認）も確認しました。すべてZurich PDIのOOTBです。

確認していない範囲：Yahoo Financeがdownload.finance.yahoo.comという別ホストの名前解決を試みた理由（プラットフォーム内部の実装は未確認）。Yahoo側のサービス終了時期の裏取り。Firebase Cloud Messaging向け3件のエンドポイントが実際に生きているか（外部サービスへの負荷を避けるため未実行）。MID Serverを実際に登録した場合のecc_queueの挙動。認証あり（Basic・OAuth 2.0）のREST Message実行時の記録の違い。本番環境での件数・挙動。

今回確認できたのは、あくまで2026-08-10時点・このPDI1台での結果です。REST Messageの定義そのものは変わっていなくても、宛先側の状態はいつでも変わり得ます。同じ確認を別の日に行えば、Yahoo Financeが復旧している可能性もゼロではありません。「一度動いたから今後も動く」「一度失敗したから今後も失敗する」のどちらも決めつけず、定期的に確かめる対象として扱うのが安全です。

参考リンク：