ServiceNow Event が発火しないときの原因整理と最短切り分け

ServiceNowで「Event が発火しない」と感じるとき、実際には大きく3つのパターンに分かれます。
ひとつはそもそもイベントが生成されていないケース。
ふたつめはイベントは生成されているが処理されていないケース。
みっつめはイベント自体は処理済みだが、その後続処理が動いていないケースです。ServiceNowのイベントは「何かを直接実行する命令」ではなく、まずイベントキューに積まれる仕組みなので、この構造を理解すると切り分けがかなり速くなります。

現場では「通知が飛ばない」「Script Actionが動かない」「Flowや後続処理が反応しない」という相談が多いですが、原因を通知設定だけで追うと遠回りになります。
まずは Business RuleやScriptからイベントが登録されたか、次に Event レコードが sysevent に存在するか、最後に 通知やScript Action側がそのイベントを正しく拾っているか の順で見るのが基本です。イベントは Event Registry に登録され、gs.eventQueue() などで生成され、スケジュールジョブがイベントキューを読んで通知やScript Actionへつなぎます。

まず確認すべきチェックリスト

Event が発火しないときは、最初に次の項目を上から順に見てください。ここでかなりの割合を切り分けできます。

イベントレコードが sysevent に作られているか

まず System Policy > Events > Event Log または Event [sysevent] を確認します。
見るべき主なフィールドは以下です。

• Name
• Table
• Instance
• Parm1
• Parm2
• Queue
• State

gs.eventQueue() でイベントが生成されると、イベントはキューに入ります。ServiceNowの公式学習コンテンツでも、イベントはまずキューのエントリとして作られ、反応するロジックがなければその先は何も起こらないと説明されています。つまり、**sysevent にレコードがないなら「未発火」ではなく「未生成」**です。

よくある誤解は、「通知が飛んでいないからイベントも発火していないはず」と決めつけることです。
実際にはイベントは Processed まで進んでいて、通知条件側で落ちていることも珍しくありません。イベントの有無はまず sysevent で確認します。

Business Rule や Script が本当に通っているか

イベント生成元が Business Rule の場合、確認すべきフィールドは次のとおりです。

• Table
• Active
• When
• Insert / Update / Delete
• Filter Conditions
• Condition
• Advanced
• Order

ServiceNow公式ドキュメントでも、イベント生成用のBusiness Ruleは一般にafterで動かし、条件が想定どおりに成立するかを確認するよう示されています。Filter Conditions、Role conditions、Condition のどれかがずれていると、gs.eventQueue() まで処理が到達しません。

実務では、gs.info() などのログを一時的に入れて、
「Business Ruleは走ったのか」
「条件分岐を通ったのか」
「gs.eventQueue() の直前まで来たのか」
を切り分けるのが近道です。

Event Registry の定義と event 名が一致しているか

System Policy > Events > Registry で以下を見ます。

• Event name
• Table
• Queue
• Application / Scope
• Caller Access

Event Registry は、システムが認識するイベント一覧です。Queue もここで定義できます。さらに、公式ドキュメントでは登録済みイベントに対し gs.eventQueue() で Queue を省略した場合、Registry 側の Queue が使われることが説明されています。逆に gs.eventQueue() 側で Queue を指定すると、その指定が優先されます。

よくあるミスは次の3つです。

• event 名のスペル違い
• 想定と違うテーブルで登録している
• スコープ違いで参照できていない

特にカスタムアプリでは、同名に見えてもスコープ付きイベント名が違うことがあります。

Event の State が Ready のままか Error か Processed か

Event [sysevent] の State は非常に重要です。
ServiceNow公式のイベント状態は主に以下です。

• Ready: 作成されたが処理待ち
• Processed: 正常に処理された
• Error: 処理中にエラー
• Transferred: 別シャードへローテーションされたため再処理待ちの状態がありうる

Ready のまま大量に残るなら、イベント生成ではなくイベント処理系の問題です。
Error なら、パラメータ不正や後続処理内の例外を疑います。
Processed なのに何も起きないなら、通知やScript Actionがそのイベントを利用していない可能性が高いです。公式にも、Processed は「イベント自体が正常に処理された」ことを意味するだけで、追加機能がなければ何も起きないとあります。

通知まで見たいなら sys_email も確認する

通知連携まで確認したい場合は System Logs > Emails、つまり Email [sys_email] を見ます。
確認すべき主なフィールドは以下です。

• Type
• State
• Recipients
• Subject
• Error String
• Target
• User

ServiceNow公式では、通知メールが生成または受信されると sys_email に記録されると説明されています。Type の代表例は send-ready send-ignored send-failed sent です。 send-ready は送信準備済み、send-ignored は受信者なしや重複などで送信スキップ、send-failed は送信失敗を意味します。

つまり、sysevent に存在し、Processed にもなっているのに sys_email が無いなら、イベントは処理されたが通知作成条件に入っていない可能性が高いです。

原因の全体構造整理

ServiceNow Event が発火しない問題は、次の6層で整理すると漏れにくくなります。

生成前の条件層

Business Rule や Script Include、Workflow、Scheduled Script などの生成元ロジックが走っていない層です。
ここで止まると、当然 sysevent に何も残りません。

イベント定義層

Event Registry 側の event 名、対象テーブル、Queue、スコープなどがずれている層です。
特に event 名の不一致は非常に多いです。

イベント生成層

gs.eventQueue() の呼び出し自体が誤っている層です。
誤った GlideRecord を渡した、parm1/parm2 が想定外、Queue 指定が不適切などが該当します。ServiceNow公式では gs.eventQueue() は通常4引数、任意で5番目にQueue名を持てるとされています。

イベント処理層

sysevent にはあるが Ready のまま、または Error のままの層です。
ここではイベントプロセッサ、Scheduled Job、Queue 健全性を見ます。ServiceNowはスケジュールジョブがイベントキューを読み取り、処理を進めます。

後続利用層

イベントは処理されたが、Notification や Script Action が反応していない層です。
イベントはそれ自体が「何かを保証するもの」ではなく、反応ロジックが必要です。

通知送信層

Notification は作られたが、最終的なメール送信に失敗している層です。
この場合は sysevent より sys_email の調査が中心になります。

原因層ごとの詳細解説

生成前の条件層で止まっている

Business Rule の When と条件がずれている

イベント生成で最初に疑うべきは Business Rule です。
特に見るべきなのは When と Condition です。

公式のサンプルでも、イベント生成用のBusiness Ruleは after で、Insert / Update / Delete のどこで発火させるかを明示しています。更新前の値と更新後の値を使い分ける必要がある場面では、current と previous の扱いも重要です。

具体例として、更新時だけ発火させたいのに Business Rule が Insert にしかチェックされていない、あるいは current.field.changes() が成立しない条件になっていると、イベントは一度も生成されません。

よくある誤解は、「レコード更新が起きたのだから自動でイベントも出るはず」という考え方です。
イベントは明示的にキューへ入れる必要があります。

フィルタ条件とスクリプト条件の二重絞り込み

Filter Conditions で絞ったうえに、Script 内でも if (...) を重ねていると、想定以上に厳しくなります。
たとえば以下のようなケースです。

• Filter で state = 2
• Script で current.state.changesTo(2)

この場合、更新時の評価タイミングによっては通らないことがあります。
切り分け時は、まずフィルタとスクリプト条件を整理し、どちらが真でどちらが偽か をログで確認します。

サーバーサイド以外で event を起こそうとしている

gs.eventQueue() はサーバーサイドで使う前提です。
クライアントスクリプトやUI Policyの感覚で扱うと、期待どおりには動きません。公式でもイベント生成はサーバーサイドスクリプトやWorkflowの Create Event アクティビティで行う流れが示されています。

イベント定義層に問題がある

Event Registry の event 名が実際の呼び出し名と違う

System Policy > Events > Registry の Event name と、コード中の gs.eventQueue('xxx') の文字列は完全一致で見るべきです。
大文字小文字、プレフィックス、アプリスコープを含めて確認します。

たとえばカスタムアプリなら、x_company_app.some_event のような形になっていることが多く、別スコープの似た名前を見ているとハマります。

Table が想定と違う

Event Registry には Table があります。
公式でも、イベントはそのテーブルに対する GlideRecord と結びついて扱われます。 gs.eventQueue() の第2引数には通常 current を渡しますが、その current が Event Registry の想定テーブルとずれていると、後続処理で期待どおり扱えません。

実務では「Notification は incident を見ているが、実際には task を渡していた」というようなずれが起きがちです。

Queue の認識違い

Event Registry の Queue を設定している場合、gs.eventQueue() 側で Queue を省略しても Registry の Queue が使われます。一方、gs.eventQueue() 側で Queue を明示するとそちらが優先されます。

つまり、調査時は
「このイベントはどのQueueに入るはずか」
を Registry とコードの両方で見る必要があります。

イベント生成層に問題がある

gs.eventQueue の引数が不適切

ServiceNow公式の説明では、gs.eventQueue() は通常以下です。

• event 名
• GlideRecord
• parm1
• parm2
• 任意で queue 名

ここでありがちなのが、第2引数に適切な GlideRecord を渡していないケースです。
current を渡すべき場面で null や別テーブルのレコードを渡すと、後続処理が record 文脈を失います。

また、parm1 と parm2 は単なる飾りではありません。公式学習コンテンツでも、parm1/parm2 は Event Log 上で解決済み文字列として見えるため、トラブルシュートに役立つと説明されています。つまり、ここに record number や user 名を入れておくと追跡が楽になります。

eventQueueScheduled と eventQueue を混同している

遅延実行を想定しているのに通常の eventQueue() を使っている、または逆に即時想定なのにスケジュールイベントを使っていると、発火タイミングの認識違いが起きます。公式でも eventQueueScheduled() は有効期限付きイベント用として案内されています。

「発火しない」のではなく「まだその時刻ではない」だけのこともあります。

イベント処理層に問題がある

sysevent が Ready のまま滞留している

Event Log にレコードはあるが State = Ready のまま進まない場合、イベント処理系を見ます。
ServiceNow公式では、イベントはスケジュールジョブがキューを読み、通知やスクリプトなどのハンドラへ渡す仕組みです。

ここで確認したいのは次です。

• Queue
• State
• 同じQueueで他イベントも滞留していないか
• System Diagnostics > System Events Dashboard でアラートが出ていないか
• Active Processors や Active Jobs の状態

Yokohama系の公式ドキュメントでは、System Events Dashboard で Queue、Event、Processors、Alerts を見られるとされています。滞留調査ではかなり有効です。

sysevent が Error になっている

公式では Error は「処理中エラー」であり、無効なイベントパラメータが原因になることがあるとされています。

この場合は以下を見ます。

• Parm1
• Parm2
• 後続の Script Action ログ
• Notification 側の参照条件
• Event 名の対象テーブルとの整合性

よくある誤解は、Error なら eventQueue の書き方だけが悪いと思うことです。
実際には、イベント自体は作られていても、後続処理の中で例外になっていることがあります。

Transferred を異常と決めつけている

Transferred は必ずしも故障ではありません。
公式では、Event [sysevent] テーブルの別シャードへローテーションされ、処理待ちになる状態として説明されています。再処理対象として扱われることがあります。

この状態を見た瞬間に「壊れている」と判断するのは早計です。

後続利用層に問題がある

Script Action が event を拾っていない

Script Action はイベントによってのみ起動します。公式ドキュメントでも明示されています。

確認すべきフィールドは以下です。

• Active
• Event name
• Order
• Condition
• Script

sysevent が Processed でも、Script Action 側が非アクティブ、あるいは別イベント名を見ていれば何も起きません。

Notification が event 起点になっていない

Notification 側では Trigger が「Record change」なのか「Event」なのかを必ず確認します。
公式でも通知はレコード変更起点でもイベント起点でも送れるとされています。

イベント通知を作る場合に見るべき項目は次です。

• Active
• Table
• When to send
• Event name
• Condition
• Who will receive
• Send to event creator
• Advanced View の追加設定

ここで event 名がずれていたり、受信者条件が成立していないと、イベントは処理済みでもメールは作成されません。

parm1 と parm2 の使い方を誤解している

公式ドキュメントでは、Notification のメールスクリプトなどで event.parm1 event.parm2 を参照できます。

しかし、parm1/parm2 に受信者sys_idや補助情報を入れていても、Notification 側の設定がそれを利用する構成になっていなければ意味がありません。
「parm1に入れたから通知先になるはず」と思い込むのは危険です。

通知送信層に問題がある

sys_email に send-ignored が出ている

これは「イベント未発火」ではありません。
Notification までは進んでいますが、送信がスキップされています。公式では、主な理由として受信者メールアドレスなしや重複メールが挙げられています。

この場合は次を見ます。

• Recipients
• User
• Error String
• 通知重複条件
• 受信者ユーザーの email フィールド

sys_email に send-ready が残り続ける

公式では send-ready は通常短時間だけ滞在する状態です。長時間残る場合は、メール送信側の処理や設定も見ます。

ただしこの記事のテーマは Event なので、ここまで来たらEvent は発火していると判断してよい場面が多いです。
つまり、問題は Event ではなく Outbound Email 側です。

実務での最短切り分けフロー

現場では次の順で見ると速いです。

まず sysevent にその event があるか確認する

最初に Name = 対象event名 で絞り、最新レコードを確認します。
無ければ、生成元ロジックへ戻ります。
あれば State を見ます。

• 無い → Business Rule / Script / Workflow を確認
• Ready → Queue / Processor / Scheduled Job を確認
• Error → パラメータと後続処理を確認
• Processed → Notification / Script Action / sys_email を確認

次に生成元コードまで戻る

Business Rule なら、以下を確認します。

• When = after か
• Insert / Update / Delete が合っているか
• Condition が成立しているか
• gs.eventQueue() が条件分岐の内側で届いているか
• 第2引数の GlideRecord が正しいか

Event Registry と Queue を確認する

次に Registry で event 名、Table、Queue を見ます。
カスタムQueueを使っているなら、そのQueue側の滞留も見ます。
公式では Queue 単位の可視化に System Events Dashboard が使えます。

後続処理を確認する

Script Action か Notification のどちらに反応させたいのかを明確にします。
Processed なのに反応しない場合、だいたいここです。

• Script Action の Event name / Active
• Notification の Trigger / Event / Active / Condition
• sys_email の生成有無

設計観点からの再発防止

Event トラブルは、その場しのぎで直すより、設計を揃えると再発しにくくなります。

event 名と用途を命名規則で固定する

Event 名は用途が一目で分かるようにします。
たとえば「何が起きたイベントか」を統一しておくと、Registry、Business Rule、Notification の対応が追いやすくなります。

• x_app.incident.assigned
• x_app.request.approved
• x_app.task.reminder

ServiceNow公式でも Event Registry の説明欄や Fired By は将来のトラブルシュートに役立つ情報として扱われています。

parm1 と parm2 を調査しやすい値にする

parm1 と parm2 は空でも動くことがありますが、切り分けの観点では
record number
user id / user name
状態変化の要点
を入れておくと非常に便利です。公式学習コンテンツでも、parm1/parm2 は Event Log 上で見えるため、トラブルシュートに役立つとされています。

生成元と後続処理を分離して考える

「イベントを出す責務」と「通知やScript Actionで反応する責務」を分けると保守しやすくなります。
これはCSA学習でも重要な見方です。Event は疎結合化のための仕組みであり、生成元が直接メール送信ロジックを抱え込まない設計のほうが整理しやすくなります。イベントはキューに積まれ、必要なハンドラがそれを使うという構造です。

監視ポイントを最初から決める

本番運用では、問題発生後に見る場所を探すのでは遅いです。
最初から以下を定点観測対象にしておくと強いです。

• sysevent の Ready / Error 件数
• Queue ごとの滞留
• System Events Dashboard の alerts
• sys_email の send-failed / send-ignored
• 主要 Script Action の実行結果

まとめ

ServiceNowで「Event が発火しない」と見えるときは、まず「本当に未発火なのか」を疑うことが大切です。
実際には、

• イベント自体が生成されていない
• sysevent にはあるが処理待ち
• Processed だが後続処理が無い
• 通知までは進んだが sys_email 側で止まっている

という分岐がほとんどです。

最短で直したいなら、
Business Ruleを見る前に sysevent、
通知を見る前に State、
メールを見るなら sys_email
という順番で追うのが効率的です。

CSA学習の観点でも、Event を「通知の前段」ではなく、イベント生成 → キュー投入 → プロセッサ処理 → 後続利用という仕組みとして理解すると、Business Rule、Notification、Script Action の関係がかなり整理しやすくなります。

次に読むと理解が深まる関連記事

Event の切り分けでつまずきやすい人は、次のテーマもあわせて整理しておくと実務で強くなります。

Notification が飛ばない原因整理

Event は出ているのにメールが届かない場合は、Notification と sys_email の切り分けが次の論点になります。
特に send-ready send-ignored send-failed の意味を理解すると、Event 問題との境界が見えやすくなります。

Business Rule が動かない原因整理

Event の未生成は、結局 Business Rule 側の条件ずれであることも多いです。
When、Condition、Order、current / previous の理解を深めると、Event トラブルの初動が速くなります。

Script Action の基礎理解

イベント処理後に何が起きるかを理解するには、Script Action の役割整理が有効です。Script Action はイベントをトリガーにする仕組みなので、Event 設計とセットで押さえると理解しやすいです。

体系的に学ぶ方法の一例としては、UdemyのServiceNow講座で Event Registry、Business Rule、Notification、Script Action のつながり をまとめて学ぶやり方もあります。単発の不具合対応だけでなく、CSA学習の基礎整理にもつながりやすいです。