Processors（sys_processor）：URLの裏で動く処理エンドポイント
ServiceNow を触っていると、画面のボタンや裏側の処理が、いつのまにか特定の URL を叩いていることがあります。PDF を作る、添付ファイルを落とす、レコードの画像を返す。こうした「URL を受け取って、サーバ側で何か処理し、応答を返す」小さな係が、今回の主役 プロセッサ（Processors） です。テーブル名は sys_processor。ふだん名前を見ることは少ないですが、プラットフォームの足元でずっと働いています。
プロセッサは、Scripted REST API よりも古い、低レベルの仕組みです。新しく API を作るなら今は Scripted REST API を使いますが、標準機能の内部では、今でも多くのプロセッサが現役で動いています。だから「知らないけど使っている」典型例です。この記事では、その正体を PDI の実機で数えながら読み解きます。件数・型・項目は、すべて手元のインスタンスで確認した実測値です。
難しく身構える必要はありません。プロセッサの核は「path で URL を受け、処理して、応答を返す」という一本道です。まずはその一本道を図で押さえましょう。次に206件の内訳を数え、java と script の違いを確かめます。誰が呼べるかの制御、そして Scripted REST API との住み分けまで、順番にたどります。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-20）。本番環境では設定が異なります。
プロセッサとは：URLの裏で動く処理係
まず言葉から。プロセッサは、特定の URL パスを受け取り、サーバ側で処理して応答を返すエンドポイントです。ブラウザや外部システムが、ある URL にアクセスする。すると、その URL に結び付いたプロセッサが呼ばれ、処理を実行し、結果を返す。この「URL 1つに、処理1つを結び付ける」のが、プロセッサの役割です。
イメージしやすいのは、レコードの PDF 出力です。レコードを PDF にする URL があり、そこにアクセスすると PDFProcessor という組込みプロセッサが動いて、PDF を作って返します。添付ファイルのアップロードやダウンロードも、同じようにそれぞれの処理係が受け持っています。画面の裏で「この URL が来たら、この処理を回す」という対応表が、sys_processor テーブルの正体です。
なぜこんな仕組みがあるのか。ServiceNow はレコードの一覧やフォームだけでできているわけではありません。ファイルを返したい、画像を返したい、外部からの通信を受けたい。そういう「ふつうのフォーム画面では扱いにくい入出力」を担う口が必要になります。その口が、古くからプロセッサでした。だから用途は地味ですが幅広く、プラットフォームの縁の下を支えています。
図で見る：リクエストから応答まで
言葉より図のほうが早いので、一本道を描いてみます。
流れはこうです。ブラウザや外部が、ある URL にリクエストする。その URL の入口を path が受ける。対応するプロセッサが呼ばれ、type に応じて java の組込みクラス、または script のスクリプトが処理する。最後に応答を返す。分岐は「java か script か」の1か所だけで、あとはまっすぐです。
この単純さが、プロセッサの古さでもあり強さでもあります。リクエストとレスポンスを直接さわる、飾りの少ない作り。だから細かい制御が効きますが、そのぶん自分で書くことも多くなります。後半で見る Scripted REST API は、この一本道の上に「バージョン管理」や「リソースの整理」といった枠組みをかぶせた、より新しい仕組みだと捉えると分かりやすいです。
全部で206件、内訳を数える
では実機で数えます。sys_processor を type 順に並べたのが次の画面です。
REST で件数を集計すると、全体は 206件 でした。内訳は、type=java が 131件、type=script が 75件。131 と 75 を足すと 206 で、ちょうど合います。type の値は、実測ではこの2種類だけでした。
有効・無効も数えました。active=true で絞ると、java は 131件すべてが有効、script は 74件が有効。合計205件が有効で、無効は1件だけ、しかも script 側にありました。標準の組込み処理はほぼ全部が生きていて、止まっているのはごくわずか、という健全な状態です。プラットフォームの土台なので、うかつに止まっていないのは理にかなっています。
数字を眺めると、プロセッサが「特別な機能」ではなく「日常的に大量に使われている部品」だと分かります。206件の大半が有効で、静かに動き続けている。ふだん意識しないだけで、これだけの数の処理係が URL の裏に控えている、というわけです。
type=java：ServiceNowが組み込みで持つ処理
まず java 型から。type=java のプロセッサは、処理の本体を Java クラス（class_name 項目）に持ちます。ServiceNow がプラットフォームとして作り込んだ、標準の処理係です。実測した名前を並べると、役割が見えてきます。
PDFProcessor（path: sys_confirm_pdf+）… PDF を作って返す
FileAttachmentProcessor（path: sys_file_attachment）… 添付ファイルを扱う
RecordImageProcessor（path: record_image）… レコードの画像を返す
AMBLoginProcessor（path: amb_login）… リアルタイム通信のログイン
AJAXJellyRunner / AJAXCachedJellyRunner … 画面裏の AJAX・Jelly 実行
どれも「言われてみれば使っている」ものばかりです。PDF 出力、添付、画像。日々の操作の裏で、これらの java プロセッサが URL を受けて働いています。java 型は、path と名前が一致するもの（AJAX 系）もあれば、sys_file_attachment のように機能を表す path を持つものもあり、混在していました。
java 型で押さえたいのは、中身はさわれないという点です。処理は Java クラスに焼き込まれているので、スクリプトのように開いて書き換えることはできません。標準機能そのものだから当然です。java プロセッサは「ServiceNow が用意した、動かしてはいけない土台」だと思っておくと安全です。
補足すると、java プロセッサの名前には、その分野が透けて見えます。AMB で始まる一群（AMBLoginProcessor など）は、画面とサーバをつなぐリアルタイム通信（AMB）の入口です。Export を含むものはデータの書き出し、Attachment や Image を含むものはファイルや画像のやり取り。名前を眺めるだけで、プラットフォームがどんな「URL の口」を標準で抱えているかが見渡せます。ふだんは意識しない部品ですが、一覧を一度眺めておくと、裏側の地図が頭に入ります。
type=script：スクリプトで書くカスタム処理
もう一方の script 型は、処理を Script フィールドのスクリプトに書きます。java クラスを持たず、開発者が JavaScript で中身を書く、カスタム側のプロセッサです。実機で type=script に絞ると、次の一覧になります。
新しく script プロセッサを作ると、Script 欄には次のような雛形が入っていました（実測の既定テンプレート）。
(function process(g_request, g_response, g_processor) {
// Add your code here
})(g_request, g_response, g_processor);ここが低レベルたるゆえんです。g_request でリクエスト（URL のパラメータなど）を読み、g_processor で出力を書いたりリダイレクトしたりし、g_response で応答そのものを操作する。3つの引数を直接さわって、リクエストからレスポンスまでを手作りします。整った枠組みは無い代わりに、自由度は高い。昔ながらのサーブレットに近い手触りだと考えると、しっくりきます。
実測した script プロセッサには ExportRota（path: export_cmn_rota）や ExportWorkflowVersion がありました。ほかに OpenAppFile、LiveFeedAjaxProcessor なども見られます。エクスポート系、リダイレクト系、AJAX 系が目立ちます。path も export_* や *_redirect のように、機能がそのまま名前になっているものが多く、読めば用途の見当がつきます。
java と script、どこが違うか
java と script を並べると、住み分けがはっきりします。
分かれ目は「処理の本体をどこに持つか」です。java 型は Java クラスに焼き込まれた標準機能で、131件。script 型はスクリプトで書くカスタム寄りの仕組みで、75件。標準の PDF・添付・画像などは java が担い、個別のエクスポートや画面遷移などは script が受け持つ、という分担でした。
実務での意味も違います。java 型は原則さわりません。標準機能の一部なので、書き換えると壊れます。一方 script 型は、自作したものなら中身を編集できます。ただし OOTB に最初から入っている script プロセッサは、それ自体が標準機能なので、これも安易にはさわらないのが無難です。「java は絶対に土台、script は自作なら手を入れられる」と線を引いておくと、迷いません。
path が URL の入口になる
プロセッサの動作は path 項目で決まります。ここに書いた文字列が、その処理を呼び出す URL の入口になります。amb_login という path なら、その名前のパスへのリクエストを AMBLoginProcessor が受け取る。record_image なら RecordImageProcessor が受ける。URL と処理を結ぶ対応表が、この path 列だと考えてください。
だから一覧で path 列を眺めると、「このインスタンスは、どんな URL を裏で受け付けているか」が読めます。export_cmn_rota はローテーションのエクスポート、sys_file_attachment は添付、livefeed はライブフィード。path の語感から、その処理係が何をする口なのか、おおよそ推測できます。障害調査で見慣れない URL に出くわしたとき、sys_processor の path を検索すると、正体にたどり着けることがあります。
もう少し踏み込むと、path は単なる飾りではなく、システムの入口の一覧そのものです。同じ path を持つプロセッサが二重にあると、どちらが呼ばれるか分からなくなります。だから自作するときは、既存の path とぶつからない名前を選ぶのが鉄則です。標準の path（sys_ で始まるものなど）を避け、アプリの接頭辞を付けておくと、衝突の心配がありません。URL の入口に名前を付ける、という感覚を持っておくと、設計を誤りません。
ひとつ正直に断っておきます。今回は path から URL を組み立てて、実際にアクセスして応答を得る、というところまではテストしていません。path が「URL の入口を定義する」ことは公式ドキュメントの説明に基づく整理で、実際の呼び出し挙動の確認は今回の範囲外です。ここは推測と事実を分けておきます。
誰が呼べるか：roles と CSRF 保護
URL の口である以上、「誰でも叩けてよいのか」は大事な論点です。プロセッサには、それを制御する項目があります。
ひとつは roles。呼び出しに必要なロールを指定する項目で、実測では 21件 に何らかのロールが付いていました。たとえば ExportRota は admin、CopyIncidentRelatedLists は snc_internal が必要です。逆に残りの185件はロール指定が空で、プラットフォーム側の認証に委ねる形でした。ロールを付ければ、その処理を叩ける人を絞れる、という素直な仕組みです。
ここで185件がロール未指定だった点に、少し触れておきます。ロールが空でも、誰でも自由に叩けるわけではありません。多くはプラットフォームのログイン認証を前提にしていて、ログイン済みの利用者向けに動きます。つまり「ロールで細かく絞る必要がある処理」だけに roles を付け、それ以外はログインの有無で足りる、という設計です。roles が付いているかどうかは、その処理がどれだけ限られた人向けか、の目安になります。
もうひとつは require_csrf（CSRF protect）。既定は false で、true になっていたのは 22件 でした。CSRF は、利用者が意図しないうちに別サイトから処理を叩かれてしまう攻撃です。それを防ぐトークン検証を要求するかどうかのスイッチが、この項目にあたります。データを更新するような口では、この保護を効かせる意味が大きくなります。
roles と CSRF、どちらも「URL の口を、無防備にしない」ための仕掛けです。プロセッサは古い仕組みですが、こうしたアクセス制御の項目はちゃんと備わっています。自作するときは、その口が誰に開いていて、更新を伴うのかを考えて、roles と CSRF を設定するのが基本の作法になります。
Scripted REST API との違い
ここまで来ると、「じゃあ Scripted REST API と何が違うの？」という疑問が自然に湧きます。両者を並べたのが次の表です。
ひとことで言えば、プロセッサは古くて低レベル、Scripted REST API は新しくて高レベルです。プロセッサは g_request / g_response / g_processor を直にさわる素朴な作りで、path が URL の入口になります。Scripted REST API は /api/ 配下にリソースとしてパスが整理され、バージョン管理（v1, v2 …）や構造化されたリクエスト・レスポンスの枠組みを持ちます。
新規に外部連携の API を作るなら、今は Scripted REST API が推奨です。整理された枠組みがあり、認証やバージョンの扱いも楽だからです。プロセッサは、その前の世代の仕組み。ただし「古い＝使われていない」ではありません。標準機能の内部では、PDF や添付のように、今もプロセッサが現役で動いています。新規は Scripted REST API、既存の土台はプロセッサ、という住み分けで理解しておくと、両者の関係がすっきりします。
実務でどう向き合うか
多くの人にとって、プロセッサは「自分で作るもの」ではなく「動いているのを知っておくもの」です。標準の java プロセッサは土台なので、原則さわりません。それでも存在を知っておくと、役に立つ場面があります。
たとえば、見慣れない URL がログに出たとき。sys_processor の path を検索すれば、その URL がどの処理係のものか当たりを付けられます。あるいは、特定の機能だけを URL で叩けるようにしたい、というレアな要件が来たとき。そこで初めて「プロセッサという選択肢もあるが、今なら Scripted REST API が素直だ」と判断できます。仕組みを知っているからこそ、正しく選べます。
新しく何かを作る側に回るなら、原則は Scripted REST API です。プロセッサをわざわざ新規採用する理由は、いまはほとんどありません。それでも、プラットフォームの足元で206件が静かに URL を受け続けている、という事実は覚えておく価値があります。ServiceNow の画面の裏側が、こういう小さな処理係の集まりで動いている、と分かるだけで、トラブル時の見通しが変わります。
まとめ
プロセッサ（sys_processor）は、URL の path を受け取り、サーバ側で処理して応答を返す、古くからある処理エンドポイントでした。実機では全206件。内訳は組込みの java が131件、スクリプトの script が75件で、ほぼ全部が有効です。java は Java クラスに焼き込まれた標準機能です。script は g_request / g_response / g_processor を直にさわるカスタム処理という違いがありました。
path が URL の入口になります。roles と CSRF で、誰が叩けるかと安全性を制御する。そして新規開発では、より新しい Scripted REST API が推奨で、プロセッサは既存の土台として今も現役、という住み分けです。「知らないけど使っている」機能の代表格ですが、正体を一度つかんでおけば、URL 絡みの調査でぐっと有利になります。
次回も、プラットフォームの縁の下で働く仕組みを、実機で1つずつ確かめます。
その他、実機で確認した記録
用語
プロセッサ（Processors / sys_processor） … URL の path を受け、処理して応答を返すエンドポイント
path … その処理を呼び出す URL の入口を定義する文字列
type=java … 処理を Java クラス（class_name）に持つ組込み型
type=script … 処理を Script フィールドのスクリプトに書くカスタム型
g_request / g_response / g_processor … script プロセッサが受け取る3つの引数（要求・応答・処理）
require_csrf（CSRF protect） … 不正な横断リクエストを防ぐトークン検証を要求するか
調べるときの入口URL（先頭に自分のインスタンスを付ける）
/sys_processor_list.do?sysparm_query=ORDERBYtype（type 順の一覧）
/sys_processor_list.do?sysparm_query=type=script（script 型だけ）
/sys_processor_list.do?sysparm_query=rolesISNOTEMPTY（ロールで絞れるもの）
/sys_processor.do?sys_id=...（プロセッサ1件の設定）
実測の要点（再掲）
全体206件（type=java 131 / type=script 75、合計一致）
active=true は205件（java 131 全件・script 74）。無効は1件のみ
roles あり21件（例: admin / snc_internal）、require_csrf=true は22件
script の既定雛形は process(g_request, g_response, g_processor) のシグネチャ
検証範囲とおことわり
件数・型別・フィールド定義・サンプル name/path/roles は REST と実画面の実測です。
path から URL を組み立てて実際に呼び出す挙動は未検証（検証範囲外）。path→URL は公式ドキュメントの定義に基づく説明です。
各プロセッサの script 実装コードは個別精査していません（既定テンプレートのシグネチャのみ実測）。
「無効1件」は active 合計205と総数206の差からの導出で、個別レコードの特定は範囲外です。
「Scripted REST API が新規の推奨」は公式ドキュメントの位置づけに基づきます（参考リンク参照）。
