「条件は合っているはずなのに通知が飛ばない」「Previewではよさそうなのに本番で動かない」「イベントは投げているのにメールが出ない」。ServiceNowの通知トラブルは、通知レコードだけを見ても解決しないことが多いです。実際には、通知条件、イベント、受信者判定、メール送信基盤、ログの読み方がつながって初めて原因が見えます。ServiceNow公式ドキュメントでも、個別メールの確認には sys_email、受信者の採否理由にはメールログ、イベント起点の確認にはイベントログ、全体状態の確認には Email diagnostics を使う流れが案内されています。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まず確認すべきチェックリスト
通知の条件が動かないと感じたら、最初に次の順で確認してください。ここを外すと、通知条件のロジックだけ見直しても遠回りになります。
System Logs > Emailsで対象メールのsys_emailレコードが作成されているかTypeが送信済み相当なのか、失敗系なのか、無視系なのか- 対象メールの関連リスト
Email Logに、受信者が含まれた理由・除外された理由が出ているか - 通知の
Send whenが「レコード更新系」なのか「Event is fired」なのか - Event起点なら
System Policy > Events > Event Logに対象イベントが存在するか - 通知の受信者定義で、ユーザーが inactive、通知無効、メールアドレス不正になっていないか
Email Propertiesでglide.email.smtp.activeが有効か- 通知を保存したうえで
Preview Notificationを実行し、赤の打ち消し表示になっている受信者がいないか
ServiceNowでは、すべての通知メールが sys_email に記録され、個別メールの Email Log では受信者の採否理由を確認できます。さらに Preview Notification では、実際に受信しないユーザーが赤の取り消し線で表示され、理由も確認できます。イベント起点の通知は Event Log に痕跡が残るため、まず「メールが作られていないのか」「メールは作られたが送れていないのか」「受信者が除外されているのか」を切り分けるのが最短です。
よくある誤解は、「通知レコードの条件式が正しければ動くはず」という見方です。実務では、条件以前にイベント未発火、受信者ゼロ、送信基盤停止、重複抑止、ユーザー側の通知無効が混ざります。条件をいじる前に、ログの事実を取ることが先です。
原因の全体構造整理
通知トラブルは、次の流れで考えると整理しやすくなります。
通知が動くまでの流れ
レコード変更
→ 通知条件またはイベント発火
→ 通知レコードが評価される
→ 受信者が決まる
→ sys_email が作られる
→ SMTP送信
→ 相手に届く
ServiceNow公式の情報をつなげると、イベントは Event Log に残り、通知から生成されたメールは sys_email に残り、個別の受信者判定は syslog_email で追えます。つまり、どこで痕跡が切れているかを見るだけで、原因の層がかなり絞れます。
原因は大きく分けて七つある
通知の条件が動かないときは、実務上は次の七分類で見ると漏れにくいです。
- 通知レコードの設定不整合
- レコード条件の評価ミス
- イベント未発火またはイベント設定不整合
- 受信者判定での除外
- メール送信基盤の停止や送信失敗
- 重複抑止や無視状態
- 更新タイミングとデータ状態の食い違い
この分類は、公式ドキュメントで案内されている確認ポイントを実務向けに再整理したものです。特に sys_email、Event Log、Email Log、Email diagnostics の四点を軸にすると、調査順を固定化できます。
原因層ごとの詳細解説
通知レコードの設定がずれている
最初に疑うべきなのは、通知レコードそのものの設定ずれです。ServiceNowでは、通知条件が正しく見えていても、Send when の選択、対象テーブル、イベント設定、保存状態の不整合によって実際には動かないことがあります。通知条件のロジックだけを見直す前に、まず通知レコードの基本設定が意図どおりかを確認することが重要です。
実際に見るべき確認箇所は、通知レコードの Send when、Table、When to send、Who will receive、更新日時です。特に Send when が「レコード更新系」なのか「Event is fired」なのかで、調査先は大きく変わります。ここを取り違えると、条件式をいくら見直しても原因にたどり着けません。
よくある誤解は、「条件ビルダーが正しければ通知は動くはず」という考え方です。実務では、通知が動かない原因が条件式ではなく、通知の起動方式そのものにあることが少なくありません。
Send whenの選び方が実装と合っていない
最初に見るべきフィールドは通知の Send when です。ここが「レコード挿入・更新時」なのか「Event is fired」なのかで、確認先が変わります。レコード更新系なら対象レコードの更新そのものがトリガーで、イベント系なら Event Registry に登録されたイベントと実際の発火が必要です。
実際によくあるのは、Business Rule で gs.eventQueue() を使っているのに通知側がレコード更新条件のまま、あるいは逆にイベント通知なのにイベント名や対象テーブルが一致していないケースです。Event Log にイベントが無ければ通知条件以前の問題ですし、イベントがあるのにメールが無ければ通知との紐づきか受信者側を疑います。
具体的な確認箇所は、通知レコードの Send when、イベント名、対象テーブル、Event Log の記録有無です。状態例としては、「イベントを投げているのに通知は更新条件のまま」「通知は Event is fired だが、イベント名が一致していない」といったものがあります。
よくある誤解は、通知の Preview が通ったから本番も動くという考え方です。Preview は検証に有効ですが、イベント発火そのものを保証するものではありません。
通知が保存前の状態や古い条件のまま見られている
意外に見落とされるのが保存漏れです。通知のフィールドを修正した直後に保存せず確認してしまうと、古い条件のまま評価している可能性があります。とくに複数人で設定を触る環境では、「直したつもり」と「実際に保存された設定」がずれていることがあります。
確認箇所は通知レコードの更新日時、Who will receive、When to send、テンプレートの本文と件名です。状態例としては、「条件を修正したつもりだったが保存されていない」「別の管理者が古い設定のまま上書きしていた」といったケースです。
よくある誤解は、「画面上で変更した内容はそのまま評価される」というものです。実際には、保存されていない変更は通知動作に反映されません。本文の問題に見えて、実は古い通知設定を前提に調査していた、ということもあります。
レコード条件の評価が想定と違う
変更後の値で見ているのか、変更前後の差分を見ているのかが曖昧
通知条件で起きやすいのは、「更新後の現在値」で考えているのか、「その更新で変化したか」を見たいのかが混ざることです。通知は見た目が単純でも、実際には更新タイミングと評価タイミングを意識しないとズレます。公式には、レコード挿入・更新時の通知は条件ビルダーで送信条件を設定する形ですが、条件に一致する現在値と、今回更新で条件に入ったことは別です。
具体的な確認箇所は、対象テーブルのレコード履歴、通知条件で参照しているフィールド、更新を発生させている Business Rule や Flow の順番です。状態例としては、「State が In Progress になっているが、その前の自動更新で既に通知条件を通過していた」「更新自体はあったが条件対象フィールドは変わっていない」といったものです。これは通知の問題というより、条件設計の問題です。
よくある誤解は、「条件が今 true だから通知は飛ぶはず」という考え方です。通知は評価の瞬間で決まるので、今見て true でも、その更新時点では false だった可能性があります。CSA学習でも、フォーム上の現在値だけで判断しない視点は重要です。
条件ビルダーと実データの型がずれている
参照フィールド、真偽値、Choice、空値判定は特にズレやすい箇所です。例えば、見た目では空欄でも実際には参照値が入っている、または期待したユーザーではなくグループが入っていることがあります。通知が動かないというより、条件が合っていないだけのケースです。
見るべきフィールド名は、assigned_to、assignment_group、state、active、カスタムフィールド群です。状態例として、「Assigned to に値が入る想定だったが実際は Assignment group のみ」「active=false のレコードは別処理で除外されていた」があります。
イベントが正しく発火していない
Event Registryと実装側のイベント名が一致していない
イベント通知で最初に見るべきは System Policy > Events > Registry と Event Log です。ServiceNowでは、イベントは登録され、Business Rule などから発火され、Event Log に記録されます。イベント名が一文字でも違えば、通知条件以前にヒットしません。
具体的な確認箇所は、イベント名、対象テーブル、キュー名、発火元スクリプトです。状態例としては、「Registry は incident.updated.notify なのに実装は incident.update.notify を投げている」「違うテーブルのイベントとして登録している」などです。
よくある誤解は、「イベント名さえ合えばよい」というものです。実際には、どのテーブルに対するイベントか、どのキューに入るか、どのレコード文脈で投げているかも調査対象です。Event Log の Table、Parm1、Parm2 まで見るとヒントが増えます。
parm1とparm2を受信者として使う設定が合っていない
イベント通知では parm1 と parm2 を本文表示だけでなく受信者解決にも使えます。通知側には「Event parm 1 contains recipient」「Event parm 2 contains recipient」があり、必要なら recipient を解決するテーブル指定も必要です。ここがずれていると、イベント自体は出ていても受信者ゼロになります。
見るべきフィールドは通知の recipient 関連設定と、イベント発火側で渡している parm1、parm2 の中身です。状態例としては、「emailアドレス文字列を入れているのに sys_id 前提で解決しようとしている」「複数ユーザーの sys_id をカンマ区切りで渡す想定なのに別フォーマットになっている」があります。
よくある誤解は、parm1 と parm2 は自由文字列だから何を入れても受信者にできる、というものです。本文差し込み用と受信者解決用は使い方が違います。受信者として扱うなら通知側の該当設定が必要です。
受信者判定で落ちている
ユーザーがinactiveか通知無効かメールアドレス不正
通知条件が合っていても、受信者として最終的に落ちることがあります。ServiceNowのメールログでは、受信者が含まれた理由・除外された理由を確認できます。関連するプロパティでは、inactive、通知無効、無効なメールアドレス、イベント起票者除外などの理由がログ化されます。
具体的な確認箇所は、sys_user.active、ユーザーレコードの Notification 設定、メールアドレス形式、通知の Send to event creator、Exclude delegates です。状態例として、「Assigned to は入っているがユーザーが inactive」「起票者自身には飛ばない設定になっている」「メールアドレスが空で候補から外されている」があります。
よくある誤解は、「Assigned to にユーザーが入っていれば受信する」というものです。実際には、受信者候補に上がったあと除外判定があります。Preview で赤い取り消し線が出るのは、まさにこの層です。
GroupsやUsers in Fieldsの解決結果が想定と違う
通知の Users/Groups in fields やグループ宛て設定では、誰が最終受信者になるかを誤解しやすいです。ServiceNowのログ関連プロパティでは、グループメール、グループ管理者、メンバーシップ、recipient fields、recipient users、subscription など、どの経路で受信者になったかを記録できます。
確認箇所は通知の受信者定義、対象フィールドの中身、グループ構成、メールログの Message です。状態例として、「assignment_group は入っているがメンバー想定と実際の通知先が違う」「Users in Fields で user参照を想定したのに group参照を見ている」などがあります。
メール送信基盤で止まっている
通知は作られたがSMTP送信が止まっている
sys_email にレコードがあるのに届かないなら、通知条件そのものではなく送信基盤を見るべきです。ServiceNowでは glide.email.smtp.active が outbound mail の有効化プロパティで、Email diagnostics からも送信有効・無効の状態を確認できます。
具体的な確認箇所は System Properties > Email Properties、Email diagnostics、sys_email.Error string、送信ジョブの状態です。状態例として、「send-ready のまま滞留している」「Error string にSMTP系エラーがある」「環境設定で送信が無効化されている」があります。
よくある誤解は、「通知レコードが正しいからメール基盤も問題ない」というものです。通知設定とメール送信機能は別レイヤーなので、全通知が止まるときは glide.email.smtp.active と diagnostics を先に見るほうが早いです。
失敗と再試行を見落としている
公式ドキュメントでは、SMTP送信失敗時の再試行として exponential back-off が案内されており、再試行中のメールは send-retry-backoff、アドレス検証系は send-retry-delayed といった状態になります。見た瞬間に未送信でも、完全停止とは限りません。
確認箇所は sys_email.Type と Error string です。状態例として、「すぐに届かないが再試行中」「5xxで恒久失敗」「アドレス問題で遅延再試行」といった違いがあります。通知条件に手を入れる前に、配信レイヤーの状態を区別してください。
重複抑止や無視状態に入っている
send ignoredを条件不一致と誤認している
ServiceNow公式のトラブルシューティングには、メールが send-ignored になるケースが別問題として案内されています。また、重複メールに関する案内も別建てで存在します。つまり、「飛ばない」には、条件不一致だけでなく意図的に無視されたケースが含まれます。
具体的な確認箇所は sys_email.Type、同時刻前後の類似メール、同一イベントからの複数通知です。状態例として、「同内容メールが同時発生して重複扱いになった」「条件は通っているが無視状態で送られていない」があります。こういうときは通知条件をいじっても直りません。
よくある誤解は、「sys_email があれば送信処理は正常」というものです。実際は Type を見ないと意味がありません。送信済み、失敗、無視、再試行では意味が全く違います。
更新タイミングとデータ状態がずれている
条件を満たす前にイベントが投げられている
イベント通知では、イベントを投げた瞬間のレコード状態や parm 値が重要です。Event Log には Parm1、Parm2、対象テーブルなどが残るため、想定どおりの情報でイベントが上がっているか確認できます。
具体的な確認箇所は、Business Rule の実行タイミング、レコード更新順、イベント発火行、Event Log の Parm1 Parm2 です。状態例として、「まだ Assigned to が入る前にイベントを投げた」「State が確定する前にイベントが評価された」などです。通知条件が悪いのではなく、投げる場所が早すぎるケースです。
よくある誤解は、「最終的にレコードが正しい値になればイベント通知も正しい」というものです。イベント通知は、いつ投げたかが重要です。特に自動処理が複数重なる設計では、更新後に見える値とイベント発火時点の値が一致しないことがあります。これはCSA学習でも押さえておくべき設計視点です。
実務での最短切り分けフロー
まず痕跡の有無で三分割する
実務では次の順で見れば、かなり短時間で絞れます。
sys_emailが無い
この場合は、通知条件以前で止まっています。レコード更新通知なら条件不一致か通知設定ミス、イベント通知なら Event Log にイベントがあるかを確認します。Event Log が無ければ発火側、Event Log があるのにメールが無ければ通知との結線を見ます。
sys_emailはあるが受信者がいない
この場合は、個別メールの Email Log を見ます。ServiceNow公式では、受信者が含まれた理由・除外された理由がここで確認できます。inactive、通知無効、イベント起票者除外、recipient fields の解決結果などを見ます。
sys_emailはあるが送れていない
この場合は Type、Error string、Email diagnostics、SMTP送信有効化を確認します。再試行状態なのか、恒久失敗なのか、送信無効なのかを分けます。
現場で使いやすい確認順
おすすめの順番は次の通りです。
1つ目は通知レコード。Send when、対象テーブル、受信者、Send to event creator を見ます。
2つ目は Preview。保存後に実行し、受信しない候補が赤表示になっていないか確認します。
3つ目は Event Log。イベント起点なら痕跡があるか見ます。
4つ目は sys_email。メール自体が生成されたか見ます。
5つ目は Email Log。受信者の採否理由を確認します。
6つ目は Email diagnostics と Email Properties。全体停止か個別失敗かを切り分けます。
この順に固定すると、「通知を修正したのに直らない」を減らせます。実際には通知そのものが原因でないケースがかなりあります。
設計観点からの再発防止
通知は条件の正しさではなく追跡可能性で設計する
再発防止で重要なのは、条件を複雑にしすぎないことよりも、「あとから追える設計」にすることです。イベント通知を使うなら Event Registry の命名と用途を明確にし、どの Business Rule や Flow から投げるのかを揃えます。ServiceNowではイベント登録時にイベント名、対象テーブル、キュー名、発火元の説明を持てるため、ここを雑にしないことが運用効率に直結します。
具体的には、イベント名は用途が分かる命名に統一する、通知は一つの責務に絞る、受信者解決を parm に寄せるならルールを文書化する、という設計が有効です。これは単なる運用メモではなく、CSA学習でも重要な「仕組みとして読める設定」を作る考え方です。
ログで分かるように受信者設計を単純化する
受信者が複数経路から集まると、なぜ飛ばないかが急に分かりづらくなります。Users、Groups、Users/Groups in fields、parm1、parm2、subscription を混在させるなら、それぞれの役割を分けるべきです。ServiceNow側も include と exclude の理由をログ化できる前提なので、ログから逆算しやすい設計にすると保守しやすくなります。
よくある失敗は、「とりあえず全部受信者に足す」設計です。これだと除外理由も追いにくく、重複や誤配信も増えます。誰をどの経路で含めるかを整理すると、通知条件が動かない問題も減ります。
本番前にPreviewと実イベント確認をセットにする
通知の内容確認だけなら Preview で十分なこともありますが、イベント通知は Event Log を使った確認まで含めて完成です。公式でも Preview Notification で既存イベントを使って確認できます。机上で正しい設定と、本当に動く設定は別物です。
実務では、「Previewで受信者が正しい」「Event Logに想定イベントが出る」「sys_emailが作られる」の三点セットをリリース前チェックに入れるのがおすすめです。これだけで、公開後の通知事故はかなり減らせます。
まとめ
ServiceNowで「通知の条件が動かない」とき、実際の原因は条件式そのものより広い範囲にあります。見るべき順番は、通知レコード、Preview、Event Log、sys_email、Email Log、Email diagnostics です。この流れで確認すると、条件不一致なのか、イベント未発火なのか、受信者除外なのか、SMTP送信失敗なのかを短時間で切り分けられます。
特に覚えておきたいのは、sys_email があるかどうか、Type が何か、Email Log に除外理由が出ているか、Event Log に痕跡があるか、の四点です。ここが読めるようになると、通知トラブル対応だけでなく、ServiceNow全体の仕組み理解もかなり深まります。CSA学習者にとっても、設定画面の暗記ではなく、通知がどう流れるかを構造で理解するきっかけになります。
次に読むべき関連記事
通知まわりの理解を固めたいなら、次は次のテーマにつなげると理解が深まります。
関連記事として相性がよいテーマ
- ServiceNow 通知 イベント 違い
- ServiceNow sys_email 見方
- ServiceNow Event Log 使い方
- ServiceNow メール通知 送信されない
- ServiceNow 通知 受信者 決まり方
- ServiceNow CSA向け 通知とイベントの基礎
体系的に学ぶ方法の一例
独学で通知、イベント、メールログ、Business Rule の関係を整理するのが難しいときは、体系的に学べる教材を一つ持っておくと理解が早くなります。たとえば Udemy などで、CSA対策やServiceNow管理者向けの基礎講座を使って、通知、イベント、テーブル、ACL、Flow Designer を関連づけて学ぶ方法があります。単発の不具合対応だけでなく、「なぜその設定になるのか」を整理したい人には相性がよい学び方です。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
