ServiceNowでメール通知が届かないときの確認ポイント完全整理　sys_emailから最短で切り分ける方法

ServiceNowで「メール通知が届かない」となると、現場ではかなり焦ります。インシデント更新通知が飛ばない、承認依頼が届かない、特定ユーザーだけ受信しない、といった症状は業務影響が大きく、しかも原因が1つとは限りません。

この問題が厄介なのは、通知レコードだけ見ても解決しないことが多いからです。実際には、通知条件、イベント、受信者解決、ユーザー設定、送信キュー、SMTP接続、sys_emailの状態など、複数の層を順番に見ないと真因にたどり着けません。ServiceNowでは、通知メールは Email テーブル sys_email に記録され、さらに診断画面ではメール関連プロパティ、スケジュール済みジョブ、メールアカウント接続状況も確認できます。

この記事では、ServiceNowでメール通知が届かないときに、まず何を見るべきかを実務順に整理します。今すぐ直したい運用担当者にも、仕組みから理解したいCSA学習者にも役立つように、抽象論ではなく具体的な確認箇所まで落として解説します。

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

メール通知トラブルは、最初の5分で大きく絞れることが多いです。まずは以下を上から順に確認してください。

sys_emailにレコードが出ているか確認する

最初に見る場所は System Logs > Emails です。ここは Email テーブル sys_email のログで、ServiceNowが作成または受信した通知メールはここに記録されます。Type と State の組み合わせで、おおよその詰まり位置を把握できます。たとえば sent は送信済み、send – ready は送信待ち、send – failed は送信失敗、send – ignored は送信スキップです。

確認したい主なフィールドは以下です。

• Type
• State
• Error String
• Recipients
• Target
• Notification type
• Created
• Weight

ここでレコード自体が無いなら、「通知は作られていない」ので、通知条件・イベント・受信者解決の層を疑います。
ここで send – failed や send – ignored があるなら、通知は生成されているので、送信処理や受信者データの層を疑います。
ここで sent なのに相手が受け取れないなら、相手側メール環境やアドレス不整合も含めて見る必要があります。Type ごとの意味は公式でも明示されています。

Email diagnosticsで全体状態を確認する

個別通知ではなく「そもそも全体的に送れない」気配があるなら、Email diagnostics を確認します。診断画面では、メール設定に影響するプロパティ、スケジュール済みジョブ、メールアカウント接続の状態をまとめて確認できます。全件停止に近い症状では、個別通知より先にここを見るほうが早いです。

よくある誤解は、通知レコードが正しければ送られるはずと思い込むことです。実際には、送信処理を担う基盤側が止まっていれば、通知設定が正しくても届きません。

対象NotificationがActiveか確認する

対象の Notification レコードで、まず Active を見ます。単純ですが、意外と見落とされます。更新時に一時停止したまま戻し忘れているケースもあります。

あわせて見るべきフィールドは以下です。

• Table
• When to send または Triggered By
• Condition
• Advanced condition
• Users
• Groups
• Recipients in fields
• Event parm 1 contains recipient
• Event parm 2 contains recipient
• Send to event creator
• Exclude delegates

特にイベント起点の通知では、parm1・parm2を受信者として扱う設定や、イベント作成者を含める設定が影響します。Notification の高度条件は、通常条件に加えて評価され、true を返すか global の answer を true にしないと送信されません。

対象ユーザーの通知可否とメールアドレスを確認する

特定ユーザーだけ届かない場合は、ユーザー側を見ます。受信者ログ関連の公式プロパティには、非アクティブユーザー や 通知無効ユーザー が除外された理由を記録する設定があります。つまり、これらは実際の除外要因になりえます。

見るべき代表項目は以下です。

• sys_user.active
• sys_user.email
• 通知無効系の設定
• 必要に応じて delegates
• グループ通知なら group membership

よくある誤解は、「ユーザーが存在すれば送られる」という考えです。実際には、非アクティブ、通知無効、メールアドレス未設定、グループ経由での解決失敗などで落ちます。受信者ログプロパティを有効にしている環境では、除外理由の追跡もしやすくなります。

イベント起点ならsyseventに記録されているか確認する

イベントベース通知なら、sysevent を見ないと切り分けが進みません。ServiceNowのイベントはキューに入り、スケジュール済みジョブがそれを読み取って通知やスクリプトアクションなどへ渡します。つまり、イベントが生成されていない、またはキュー処理が詰まっていると通知は飛びません。

見るべき項目は以下です。

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

State が Ready のまま滞留しているなら、イベント処理系を疑います。イベントが Processed でも通知が無いなら、その通知がイベントに正しく紐付いているかを見直します。イベント state の意味も公式で整理されています。

原因の全体構造整理

メール通知が届かない原因は、次のように層で分けて考えると整理しやすくなります。

原因は大きく分けて6層で考える

1つ目は 通知定義の問題 です。Notification が inactive、条件不一致、高度条件が false、対象テーブル違いなどです。
2つ目は イベント起点の問題 です。イベント自体が発火していない、別テーブルのイベントを見ている、parm1・parm2設定が不整合などです。
3つ目は 受信者解決の問題 です。Users、Groups、Recipients in fields、parm1・parm2のいずれかが正しく解決されていません。公式でも受信者の指定方法は複数あり、イベントパラメータを受信者として扱うには明示設定が必要です。
4つ目は ユーザー・宛先データの問題 です。inactive、通知無効、メールアドレス不備などです。これらの除外理由は受信者ログ関連プロパティでも追跡対象になっています。
5つ目は 送信基盤の問題 です。sys_email が send-ready で滞留、send-failed、メール関連スケジュール済みジョブ不調、接続不備などです。Email diagnostics はまさにこの層の把握に向いています。
6つ目は 送信後の問題 です。sys_email が sent でも、受信側の迷惑メール判定や配送拒否、アドレス誤りなどで届かないことがあります。ServiceNow側だけで完結しない層です。

この6層で考えると、「設定を見る」「ログを見る」がばらばらにならず、どこまで進んだかが明確になります。

図解イメージで流れをつかむ

流れとしては、概ね次の順です。

対象レコード更新
→ イベント発火または条件判定
→ Notification 条件評価
→ 受信者解決
→ sys_email生成
→ 送信ジョブ処理
→ SMTP送信
→ 受信側到達

このどこで止まっているかを、sysevent と sys_email を軸に前後から挟み撃ちで見るのが最短です。
syseventが無い なら前段で止まっています。
syseventはあるがsys_emailが無い なら通知定義か受信者解決です。
sys_emailがsend-readyのまま なら送信基盤寄りです。
sys_emailがsent ならServiceNow外も視野に入れます。

原因層ごとの詳細解説

ここからは、実務で詰まりやすい原因を層ごとに詳しく見ます。

通知定義に問題がある

Notification 設定そのものに問題があるケースです。

具体的な確認箇所は以下です。

• sysevent_email_action.active
• Table
• When to send / Triggered By
• Condition
• Advanced condition
• Weight
• Users
• Groups
• Recipients in fields

よくある状態例は、以下のようなものです。

• Active が false
• Triggered By が Event なのに、想定イベント名と違う
• Condition は合っているが Advanced condition が false
• テーブルが親子継承をまたぐ前提なのに想定通りに評価されていない
• Recipients in fields に必要なフィールドが入っていない

Notification は、イベントに紐づく場合は同じテーブルのイベントしか選べません。また、高度条件は通常条件に追加で評価されます。ここを見落とすと、「条件は合っているのに飛ばない」という状態になります。

よくある誤解は、Condition だけ見て終わることです。実務では Advanced condition の return true 漏れや answer 設定漏れが原因になることがあります。

イベントが発火していない、または合っていない

イベントベース通知で非常に多い原因です。

確認箇所は以下です。

• sysevent.name
• sysevent.table
• sysevent.instance
• sysevent.parm1
• sysevent.parm2
• sysevent.state
• 必要に応じて queue

ServiceNowのイベントはキューに記録され、スケジュール済みジョブが処理します。イベントが Ready のままなら処理待ち、Processed なら処理済みです。ただし、Processed だから必ずメール送信されたとは限りません。イベントは通知以外にも使われるためです。

状態例としては以下があります。

• イベント自体が存在しない
• イベント名はあるが Notification 側の対象イベントと違う
• parm1 / parm2 に想定外の値が入っている
• Queue が独自で、処理側が想定通り動いていない

よくある誤解は、Business Rule が走ったならイベントも飛んでいるはず、という前提です。gs.eventQueue の呼び出し条件や分岐で外れていることは普通にあります。

受信者の解決に失敗している

Notification が正しくても、受信者が0件なら届きません。

確認箇所は以下です。

• Users
• Groups
• Recipients in fields
• Event parm 1 contains recipient
• Event parm 2 contains recipient
• Resolve Parm1 recipients from table
• Resolve Parm2 recipients from table
• Additional recipients 関連設定

公式では、parm1・parm2を受信者として使うときは、そのチェックを有効にし、必要に応じてどのテーブルから sys_id を解決するか指定します。ここが合っていないと、parm1 に値が入っていても受信者として扱われません。

状態例は以下です。

• Recipients in fields に空のフィールドを指定している
• parm1 に email 文字列を入れているのに sys_id 解決前提の設定になっている
• parm1 contains recipient をオンにしていない
• グループ指定しているが、実際のメンバーが空
• 対象ユーザーはいるが、通知で参照しているフィールドが別テーブルの値を見ている

よくある誤解は、「イベントにユーザーを渡しているから大丈夫」というものです。実際には、その値が sys_id なのかメール文字列なのか、どのテーブルで解決するのかまで揃っていないと失敗します。

ユーザー設定や宛先データに問題がある

特定ユーザーだけ届かないなら、ここをかなり疑います。

確認箇所は以下です。

• sys_user.active
• sys_user.email
• ユーザーの通知関連設定
• delegate
• group membership
• 必要なら受信者ログ関連設定

公式の追加プロパティでは、inactive ユーザーや通知無効ユーザーが除外されたことをログに残す設定があります。また、どの経路で受信者に含まれたかの include logging も用意されています。つまり、受信者問題はログで追える設計になっています。

状態例は以下です。

• ユーザーが inactive
• メールアドレスが空または誤り
• ユーザー通知が無効
• グループにはいるが無効ユーザー
• 代理通知を期待しているが Exclude delegates が有効

よくある誤解は、「グループに入っていれば届く」です。実際には、グループ経由で解決された後にユーザー側条件で除外されることがあります。

sys_emailはできているが送信処理で止まっている

sys_email に記録があるなら、次は送信状態を見ます。

確認箇所は以下です。

• sys_email.type
• sys_email.state
• sys_email.error_string
• sys_email.notification_type
• sys_email.weight
• Email diagnostics の scheduled jobs
• Email diagnostics の email account connections

公式では、sys_email の Type に send – ready、send – failed、send – ignored、sent などがあり、Email diagnostics ではスケジュール済みジョブと接続状態も確認できます。

状態例は以下です。

• send – ready のまま増え続ける
• send – failed で Error String に失敗理由が出る
• send – ignored で recipient 不備や重複扱い
• 全通知で同じ時間帯から停止している

よくある誤解は、sys_email ができていれば通知設定は問題ないから安心、というものです。通知設定は正しくても、送信ジョブや接続側が止まっていれば配送されません。

sentなのに相手に届かない

ServiceNow側では送れているのに、相手が受け取れないケースです。

確認箇所は以下です。

• sys_email.type = sent
• Recipients
• Subject
• From
• 受信側の迷惑メール
• メールゲートウェイや許可リスト
• 宛先アドレスの実在性

ここはServiceNow内だけでは完結しません。ただし、ServiceNow側で sent まで行っている事実があるなら、インスタンス内の通知ロジックより、配送後の外部要因を優先して確認したほうが早いです。

よくある誤解は、「相手が受け取れない＝ServiceNowの通知設定不備」と決めつけることです。sent まで行っている場合は、少なくとも通知生成と送信実行は完了しています。

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

現場で早く直すなら、順番が重要です。おすすめは次の流れです。

まず個別事象を1件決めて証拠を固定する

「誰に」「どの通知が」「どの更新で」「いつ届かなかったか」を1件に絞ります。
曖昧なまま全体を見ると、複数原因が混ざって迷子になります。

確認するものは以下です。

• 対象レコードの sys_id
• 実行日時
• 想定Notification名
• 想定受信者
• 実際の更新操作

次にsys_emailの有無で前段か後段か分ける

その事象時刻で sys_email を検索します。
検索結果なしなら前段、ありなら後段です。

• 無し → 通知条件、イベント、受信者解決を追う
• 有りで send-failed / ignored / ready → 送信基盤を追う
• 有りで sent → 受信側も含めて追う

この1手で、見る場所がかなり減ります。公式でも sys_email は全通知メールの中心ログです。

イベント通知ならsyseventを照合する

Event ベースなら、対象レコードと時刻で sysevent を確認します。

• イベントなし → 発火元ロジックを確認
• イベントあり、Processed → Notification 側設定を確認
• イベントあり、Ready滞留 → イベント処理系を確認

イベントはキュー処理で後続機能へ渡されるため、Ready 滞留は見逃せません。

受信者が本当に解決できているかを確認する

Users、Groups、Recipients in fields、parm1・parm2 のどれで受信者を作る想定なのかを明確にし、その経路だけを確認します。複数経路が混在していると、人によって届いたり届かなかったりが起きやすくなります。

ここで見るべき例です。

• Assigned to を Recipients in fields に使っているなら、対象レコードの Assigned to が空でないか
• Group 指定なら、その時点で group member がいるか
• parm1 指定なら、値が sys_id か文字列か
• Resolve Parm1 recipients from table が合っているか

設計観点からの再発防止

毎回その場しのぎで直すと、同じ事故が再発します。ここからは設計原則です。

通知は条件と受信者経路をシンプルにする

再発しやすい通知は、たいてい設定が複雑です。
Condition、高度条件、イベント、parm1、parm2、Groups、Recipients in fields を全部盛りにすると、どこで落ちたか追いにくくなります。

設計原則としては以下が有効です。

• 1通知1責務に近づける
• 受信者の決定経路を増やしすぎない
• parm1・parm2を使うなら値の型を統一する
• 高度条件を使うなら目的をコメントで残す
• 「誰に送る通知か」を名前で分かるようにする

CSA学習の観点でも、通知は「いつ送るか」と「誰に送るか」を分けて理解すると整理しやすくなります。

sys_emailとsyseventを前提に運用手順を標準化する

メール通知障害の一次切り分けは、担当者ごとの差が出やすいです。だからこそ、運用手順として固定しておく価値があります。

おすすめは、次の順をテンプレート化することです。

• 対象レコード確認
• sysevent確認
• Notification確認
• 受信者解決確認
• sys_email確認
• diagnostics確認
• 外部配送確認

この順なら、前段から後段まで漏れなく見られます。
特に sys_email と sysevent を必須確認にしておくと、属人化しにくくなります。公式でも、通知トラブルにはログと診断の活用が推奨されています。

受信者ログを活用できる状態にしておく

公式には、どの理由で受信者が含まれたか、あるいは除外されたかを記録する通知受信者ログ関連プロパティがあります。常時フル活用するかは環境次第ですが、少なくとも「届かない時に追跡できる」状態を理解しておくと強いです。inactive、通知無効、delegate、group membership、event parm 由来などが追跡対象です。

これは実務だけでなく、CSA学習でも重要です。通知は単なる設定画面ではなく、裏で「条件評価」「受信者解決」「ログ化」が行われていることを理解すると、知識がつながります。

まとめ

ServiceNowでメール通知が届かないときは、やみくもに Notification レコードだけを見ても解決しません。
最短で切り分けるには、次の考え方が重要です。

届かない問題は層で分けると解ける

まず sys_email があるかどうか を見て、通知が作られたのかを判定します。
次に、イベント通知なら sysevent を見て、発火しているかを確認します。
その上で、通知条件、受信者解決、ユーザー設定、送信基盤、受信側の順に見ます。

この流れで見れば、かなり高い確率で真因までたどり着けます。

実務で最初に見るべき場所は明確

特に重要なのは以下です。

• System Logs > Emails
• Email diagnostics
• Notification レコード
• Events
• sys_user
• 必要に応じて受信者ログ関連設定

「通知が届かない」は1つの症状ですが、実際の原因は複数あります。だからこそ、層で整理し、具体的なテーブルとフィールドで追うことが大切です。

次に読むべき関連記事

メール通知の理解をさらに深めるなら、次は次のテーマと相性が良いです。

ServiceNowのNotificationの基本設計

通知の Triggered By、Condition、Advanced condition、Recipients in fields、Users、Groups の役割を整理しておくと、今回の切り分け内容がかなり腹落ちします。特にCSA学習者は、通知が「画面設定」ではなく「設計要素」だと理解しやすくなります。

ServiceNowのイベントとsyseventの仕組み

イベント通知でつまずきやすい人は、sysevent の流れを理解すると強いです。通知、スクリプトアクション、ワークフローなどがイベントをどう使うかが見えてきます。

ServiceNow運用担当に必要な切り分け力

なお、体系的に学ぶ方法の一例としては、ServiceNowの管理・通知・イベントまわりを順番に学べる講座や教材を使う方法があります。独学で個別トラブルを追うだけだと知識が点になりやすいため、Udemyなどで管理者向けの基礎講座を補助線として使うと、今回のようなメール通知トラブルも「設定ミス探し」ではなく「仕組み理解」で見られるようになります。