ServiceNowで通知の送信先が空になる原因は何か

送信先が入らないときの確認箇所と最短切り分け手順

ServiceNowで通知を設定したのに、実際のメールで送信先が空になる、あるいは想定した相手に届かない、というトラブルは意外と多いです。
しかもこの問題は、単純に「通知が壊れている」わけではなく、通知レコードの受信者設定、参照しているフィールドの中身、イベント渡しの設計、ユーザー情報や通知デバイス、通知除外の考え方がそれぞれ噛み合って初めて成立するため、見た目以上に切り分けが必要です。

特にCSA学習中の方にとっては、このテーマを理解すると「通知はどの条件で、誰に、どの情報を使って飛ぶのか」というServiceNowの基本構造がかなり整理されます。
この記事では、今すぐ直したい実務担当者向けに、まず確認すべきポイントから、原因の全体構造、現場での最短切り分け手順、再発防止の設計原則までまとめます。

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

通知の送信先が空になるときは、まず次の順で確認すると無駄が少ないです。

• Notificationレコードが有効か
• 誰を送信先にする設定なのか
• 送信先として参照しているフィールドに値が入っているか
• 参照先ユーザーが有効ユーザーか、メールアドレスや通知デバイスが正しいか
• Eventベース通知ならparm1やparm2の渡し方が正しいか
• 除外設定で送信対象が消えていないか
• 実際にsys_emailが作成されているか
• Preview Notificationで受信者がどう解決されるか

ServiceNowの通知は、作成時点でも更新時点でも、受信者はアクティブなユーザーであり、有効なメールアドレスを持つこと、さらに必要に応じて通知設定や通知デバイスが有効であることが前提になります。公式ドキュメントでも、受信者はsys_user上で有効であり、プライマリチャネルの有効なメールアドレスが必要とされています。

ここでまず見るべき具体的な箇所は次のとおりです。

通知レコードで見る箇所

• System Notification > Email > Notifications
• Active
• Table
• When to send
• Who will receive
• Users/Groups
• Users/Groups in fields
• Event parm 1 contains recipient
• Event parm 2 contains recipient
• Exclude delegates
• Send to event creator系の関連設定
• Preview Notification

よくある誤解は、「通知条件が真なら必ず送信される」と考えてしまうことです。
実際には、条件が真であることと受信者が正しく解決できることは別問題です。条件は通っていても、送信先解決でゼロ件になれば、期待どおりのメールにはなりません。

実データで見る箇所

• 対象レコードのassigned_to
• caller_id
• opened_by
• requested_for
• watch_list
• カスタムの参照フィールド
• カタログ変数から引きたい場合の変数値
• イベントログ
• sys_email

ここで重要なのは、通知の送信先設定が見ているのは本文ではなく受信者解決用のデータだということです。
本文で${field_name}が表示できても、そのフィールドがそのまま受信者解決に使えるとは限りません。

原因の全体構造

通知の送信先が空になる原因は、大きく分けると次の層に整理できます。

受信者設定の問題

通知のWho will receiveで、そもそも送信先の指定方法が合っていないケースです。
たとえば、固定のUsers/Groupsで送るべきなのに、Users/Groups in fieldsに寄せてしまっている、あるいは逆にレコード依存で送るべきなのに固定ユーザーしか設定していない、というパターンです。通知作成では「誰が受け取るか」をこのタブで定義するのが基本です。

レコード側の値不足

通知設定自体は正しくても、送信先として見ているレコードフィールドが空であれば、当然受信者は解決できません。
assigned_toやrequested_forが未設定のまま通知だけ作っているケースはかなり多いです。

イベント渡しの問題

Eventベース通知では、parm1やparm2を受信者として扱う設定ができますが、ここで何を渡しているかがズレると送信先が空になります。
特に公式ドキュメント上、parm1/parm2を受信者として扱う場合は、カンマ区切りのsys_idリストとして解決する前提です。さらに、どのテーブルのsys_idなのかを解決する設定も必要です。

ユーザー情報や通知デバイスの問題

受信者として解決されたユーザーがいても、そのユーザーが非アクティブ、または有効なメールアドレスを持たない場合、通知は期待どおりに送れません。
ServiceNow公式も、ユーザーは有効で、通知先となる有効なメールアドレスが必要だと明示しています。

除外や通知設定による問題

送信対象を解決したあとで、除外ロジックや通知設定によって対象が消えるケースです。
たとえば「自分が起点の更新では送らない」設計になっていて、唯一の候補者が除外され、結果的に送信先ゼロになることがあります。

生成結果の見方の問題

実際にはメールが生成されているのに、確認方法がずれていて「送信先が空」と見えている場合もあります。
この切り分けで重要なのがsys_emailです。通知により生成されたメールレコードの可視性制御も公式にあり、閲覧条件によって見え方が変わることがあります。

原因層ごとの詳細解説

送信先の指定方法が通知設計と合っていない

最初に確認したいのは、通知がどうやって受信者を決める設計になっているかです。
通知のWho will receiveでは、固定ユーザー、グループ、レコード上のユーザー参照フィールド、イベントパラメータなど、複数の指定方法があります。

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

確認箇所

• NotificationのUsers
• NotificationのGroups
• NotificationのUsers/Groups in fields
• Event通知ならEvent parm 1 contains recipient
• Event通知ならEvent parm 2 contains recipient

見るべき状態例は次のとおりです。

• 固定送信ならUsersまたはGroupsに値がある
• レコード依存送信ならUsers/Groups in fieldsに対象フィールドがある
• Event依存送信ならparm設定が有効になっている

よくある誤解は、本文で使える変数なら受信者指定にも使えると思ってしまうことです。
たとえばカタログ変数や文字列フィールドを本文中で表示できても、それがそのまま受信者として解決されるわけではありません。
受信者に使うなら、通知が解決可能なユーザーまたはグループ情報として渡す必要があります。

受信者として見ているフィールドの値が空

これは最も基本ですが、最も見落としやすい原因です。
Users/Groups in fieldsにassigned_toを設定していても、対象レコードのassigned_toが空なら送信先は空です。

確認箇所

• 対象テーブルの実レコード
• assigned_to
• caller_id
• opened_by
• requested_for
• カスタム参照フィールド
• watch_listのような複数値フィールド

見るべき状態例は以下です。

• assigned_toに実在ユーザーが入っている
• 参照先が削除済みや無効ユーザーになっていない
• 想定フィールドが実際に更新タイミングまでにセットされている

よくある誤解は、画面で最終的に値が見えていれば通知時点でも入っていたはずという考え方です。
実務では、Business RuleやFlowで後から値が入ることがあります。通知の発火タイミングがその前なら、通知時点では空です。

Event通知でparm1やparm2の渡し方が誤っている

Event通知を使う場合、受信者をparm1やparm2で渡せますが、ここでの設計ミスは非常に多いです。
ServiceNow公式では、parm1/parm2を受信者として扱うときは、カンマ区切りのsys_idとして解決する前提で、必要に応じて解決元テーブルも指定します。

確認箇所

• Event Registry
• イベントを発火しているScript
• gs.eventQueue(...)
• NotificationのEvent parm 1 contains recipient
• NotificationのEvent parm 2 contains recipient
• Resolve Parm1 recipients from table
• Resolve Parm2 recipients from table

見るべき状態例は以下です。

• parm1にsys_user.sys_idが入っている
• 複数人ならカンマ区切りになっている
• 解決元テーブルがsys_userなど適切に設定されている
• メールアドレス文字列をそのままsys_id前提で渡していない

よくある誤解は、parm1にメールアドレス文字列を入れれば送れるというものです。
実際には、通知側でparmを受信者として解決する設定をした場合、sys_idの解決前提で考える必要があります。
メールアドレスをそのまま扱いたいなら、イベント設計か通知設計を見直す必要があります。

受信者ユーザーが有効でない、またはメールアドレスが不正

通知はユーザーを見つければ終わりではありません。
そのユーザーが有効で、通知を受けられる状態でなければ、期待どおりに送信されません。ServiceNow公式でも、アクティブユーザーであり、有効なメールアドレスが通知デバイスに定義されていることが前提とされています。

確認箇所

• sys_user.active
• sys_user.email
• cmn_notif_device
• Notification Preferences
• ユーザーのプライマリ通知チャネル

見るべき状態例は以下です。

• active=true
• emailが空でない
• 無効なメール形式になっていない
• 通知デバイスが有効
• 必要な通知チャネルが利用可能

よくある誤解は、ユーザーレコードにメールアドレスが入っていれば十分という考え方です。
サブスクライブ型通知やチャネル設定が絡む場合は、通知設定やデバイス設定まで見ないと判断できません。

除外設定で唯一の受信者が消えている

通知には、「レコードを更新した本人を含めるか」「起点ユーザーを除外するか」など、送信対象の最終調整に関わる考え方があります。
これにより、候補者はいたのに最終的にゼロ件になることがあります。

確認箇所

• Who will receive内の起点ユーザー関連設定
• 受信者除外用のスクリプト
• Delegateや購読設定
• 高度な条件

見るべき状態例は以下です。

• レコード更新者と送信先候補者が同一人物
• 起点ユーザー除外設定が有効
• スクリプトでrecipient追加前に除外している
• 複数候補のうち全員が除外条件に該当

よくある誤解は、更新者除外は便利だから常にONでよいというものです。
承認通知や担当者本人向け通知では、唯一の対象者が更新者本人というケースもあります。その場合、除外設定がそのまま障害になります。

通知発火時点とデータ確定時点がずれている

レコード更新系通知では、いつ値が確定するかが重要です。
たとえばBefore Business Rule、After Business Rule、Flow、イベント発火、通知評価の順序を意識しないと、「最終画面では値があるのに通知時は空」という状況が起きます。

確認箇所

• 通知の送信契機
• Business Ruleの実行順
• Flow Designerの更新タイミング
• eventQueueの呼び出し位置
• レコード保存後に別処理で代入していないか

見るべき状態例は以下です。

• 通知がInsert直後に走る
• assigned_toはAfter処理で後付けされる
• イベント発火時のcurrentにまだ値がない
• 別トランザクションで値が更新される

よくある誤解は、画面表示の最終状態が通知評価時点の状態と同じという考え方です。
ServiceNowでは処理順が結果を大きく左右します。通知の送信先問題は、設定ミスというよりタイミング設計ミスで起きることも多いです。

sys_emailを見ずに通知の成否を判断している

通知のトラブルでは、必ずsys_emailまで追うべきです。
通知レコードだけ見て「設定は正しそう」と判断しても、実際に生成されたメールレコードを見ないと、受信者解決がどうなったかは分かりません。sys_emailは生成結果の事実確認に役立ちます。なお、メールレコードにはアクセス制御がかかることもあります。

確認箇所

• sys_email
• type
• recipients
• target_table
• instance
• user
• subject
• error_string
• 生成時刻

見るべき状態例は以下です。

• メールレコード自体がない
• レコードはあるがrecipientsが空
• error_stringにヒントがある
• 同一トランザクションで複数通知が発生している

よくある誤解は、受信箱に届かない＝通知が飛んでいないというものです。
実際には、通知は生成されていても、受信者解決や配信段階で問題が起きているかもしれません。逆に、sys_emailが無ければ通知条件や発火条件側の問題を疑いやすくなります。

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

現場では、次の順番で見るとかなり早く絞れます。

通知が本当に発火対象か確認する

まずNotificationの条件を見て、対象レコードがその条件に一致しているか確認します。
ここで条件不一致なら、送信先以前の話です。

Preview Notificationで受信者を確認する

公式でも通知作成後や更新後はPreview Notificationで検証することが推奨されています。受信者解決がゼロ件かどうかを早く確認できます。

対象レコードの受信者フィールドを直接確認する

assigned_toやrequested_forなど、通知が見ているフィールドに値があるかをレコード上で確認します。
ここで空なら、通知ではなくデータ投入側の問題です。

Event通知ならイベントログとparm値を確認する

parm1とparm2に何が入っているかを見ます。
sys_id想定なのにメールアドレスや表示値を渡していたら、その時点で設計修正です。

sys_userとcmn_notif_deviceを確認する

受信者候補のユーザーが有効か、メールアドレスが有効か、通知チャネルに問題がないか確認します。

sys_emailで結果を確認する

最後にsys_emailで、生成されたか、受信者は何になったか、エラーが出ていないかを確認します。
ここまで見ると、設定、データ、イベント、配信のどの層で止まっているかがはっきりします。

設計観点からの再発防止

この問題を繰り返さないためには、単発修正ではなく、通知設計の原則を決めておくのが有効です。

受信者は参照フィールドで持つ

可能なら、通知先になる相手は文字列ではなくsys_user参照で保持します。
これにより、通知側でUsers/Groups in fieldsを素直に使えますし、ユーザーの有効性確認もしやすくなります。

Event受信者はsys_idで統一する

Event通知を使うなら、parm1やparm2に何を渡すかをチームで統一してください。
最も運用しやすいのは、受信者はsys_idで渡すというルールです。ServiceNowのparm受信者解決もこの考え方と相性がよいです。

通知前に必須項目が埋まる順序を固定する

担当者や依頼者が必須なら、通知発火より先に必ず値が入るよう、Business RuleやFlowの順序を整理します。
通知時点で未確定の値に依存させないことが重要です。

Previewとsys_email確認を標準手順にする

開発・検証時に、通知作成後は必ずPreview Notificationを行い、必要に応じてsys_emailまで確認する運用にします。
これだけでも本番での空送信先トラブルはかなり減ります。

送信先ゼロ時の代替動作を決める

実務では、担当者未設定ならグループに送る、依頼者不在なら管理者へ送る、などのフォールバック設計が有効です。
「本来の送信先が空のときは誰にも送らない」のか、「別の宛先に逃がす」のかを事前に決めておくと運用事故が減ります。

まとめ

ServiceNowで通知の送信先が空になるときは、単に通知レコードだけを見ても解決しません。
見るべきポイントは、次の5つです。

• 通知の受信者設定方法が正しいか
• 参照しているレコードフィールドに値があるか
• Event通知ならparm1やparm2の渡し方が正しいか
• 受信者ユーザーが有効で、メール通知可能な状態か
• sys_emailで実際の生成結果がどうなっているか

特に実務では、通知設定の問題よりも、受信者フィールドの空値、イベントパラメータ設計ミス、処理順のズレで詰まることが多いです。
CSA学習の観点でも、このテーマは「通知は誰にどう解決されるのか」を理解する良い題材になります。

通知の不具合を最短で直したいなら、まずは
NotificationのWho will receive → 対象レコードの受信者フィールド → Eventのparm → sys_userとcmn_notif_device → sys_email
の順で追ってみてください。かなりの確率で原因に辿り着けます。

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

通知の送信先が空になる問題は、単体で終わらせるより、次のテーマと一緒に理解すると整理しやすいです。

• ServiceNow 通知 条件に一致しているのに送信されない
• ServiceNow Eventが発火しないときの確認ポイント
• ServiceNow sys_emailが作られない原因
• ServiceNow メール通知の仕組み
• ServiceNow CSA学習者向け 通知とイベントの基礎

体系的に学ぶ方法の一例としては、ServiceNowの通知、イベント、メール処理、ユーザー管理をまとめて確認できるUdemy講座を使う方法もあります。
実務で詰まりやすい部分を画面付きで追える講座は、設定箇所の位置関係をつかむのに役立ちます。特に独学中で、Notification、Event、sys_emailのつながりを一気に整理したいときは相性がよいです。