ServiceNowの標準通知403件、実際に飛んでいるのはどれ？ 送信実績で棚卸しする手順

通知が多すぎる、あるいは肝心なときに全然飛ばない。管理者ならどちらの声も聞いたことがあるはずです。ServiceNowには標準だけで403件のNotificationが登録されていますが、実際に動いているのは何件なのでしょうか。今回はZurich PDIで、通知定義（sysevent_email_action）と送信ログ（sys_email_log）を突き合わせ、"生きている通知"だけを数えてみました。この環境では403件中37件、約9%でした。数字は環境ごとに変わります。同じ手順を自分の環境で回せる形にまとめます。

結論から：有効かどうかと、実際に飛んでいるかは別の軸

先に全体像を3点にまとめます。

• 通知定義（sysevent_email_action）は403件。うち有効379件、無効24件

• 送信ログ（sys_email_log）は1,165件生成されていたが、参照元の定義をdistinctで数えると37件しかなかった

• 残り342件の有効な定義は、少なくともこの環境では一度も送信ログを残していない

新しく環境を任された担当者が最初にぶつかる疑問がこれです。Notification一覧のActive列を眺めるだけでは、どれが実際に使われているかは分かりません。有効と実績は別の軸です。

まずは実機の画面で確認します。Email Logs（sys_email_log）の一覧を「Notification」列でグルーピングすると、どの通知が何件生成したかが一目で分かります。

上位は Asset Restocking（345件）、On-Call Schedule - Gaps and Conflicts（307件）と続きます。3位はPA collection job with error（131件）でした。見慣れたIncidentやChangeの通知は、意外にも上位には出てきません。担当者が普段の運用で目にする通知と、実際に件数を稼いでいる通知は、必ずしも同じではないということです。

通知定義（sysevent_email_action）を素直に数えると403件だった

通知の実体は sysevent_email_action テーブルで、画面上のラベルは「Notification」です。いつ・誰に・何を送るかを1レコードにまとめて登録する仕組みで、公式の概要は Email and SMS notifications にまとまっています。作成手順は Create an email notification を参照してください。フィールドの一覧は Notifications reference にまとまっています。

このPDIで件数を数えると、次の内訳になりました。

標準で入っているNotificationの一覧そのものは、Baseline email notifications という公式リファレンスにも載っています。ただしこの一覧はあくまで定義の目録です。どれだけ生成されたかまでは書かれていません。棚卸しをするなら、実機のテーブルを直接数えるほうが確実です。

トリガーの持ち方は一様ではない

トリガーの持ち方には幅があります。event_nameが設定されている「イベント発火型」が386件で大半を占めます。Insert（レコード作成）だけで発火するものが84件、Update（レコード更新）だけで発火するものが115件ありました。両方を併用している定義もあります。

event_nameに指定するイベント名は、あらかじめ登録しておく必要があります。この仕組みは Event Registry という公式ページで説明されています。中にはevent_name・Insert・Updateのいずれも未設定という定義が4件ありました。標準の経路では発火しない定義で、詳しくは後半の「なぜ飛ばないのか」で扱います。

対象テーブルは99種類に分散していた

有効379件のうち、対象テーブル（collection）でグルーピングすると99種類のテーブルに分散していました。もっとも件数が多いのは asmt_assessment_instance（26件）です。incident（23件）、sc_req_item（19件）、change_request（17件）、live_group_member（16件）と続きます。空欄（グローバル扱い）も21件ありました。

99種類のうち、定義が1件しかないテーブルは38件、4割近くを占めていました。1テーブルに1通です。特定の業務プロセス専用に1通だけ用意されているパターンが、標準の作りとしてはむしろ多数派だということです。10件を超える定義を持つテーブルはasmt_assessment_instanceやincidentなど7つしかなく、少数派に入ります。

定義と実績を正しくつなぐには sys_email_log を使う

「定義は403件、では実際に飛んだのは何件か」を調べようとして、最初につまずいたのがここでした。定義と実績を単純な文字列一致で結ぼうとすると、思わぬ取りこぼしが出ます。

sys_emailには通知定義への参照がない

生成されたメールの実体である sys_email テーブルには、target_table（対象テーブル）はあります。しかし、どの通知定義から作られたかを示す参照フィールドはありません。テーブル名や件名の文字列で名寄せしようとすると、あとで触れるような食い違いを見逃します。

sys_email_logのnotification参照が正確なリンクになる

代わりに使えるのが sys_email_log（Email Logs）です。このテーブルには notification（sysevent_email_actionへの参照）と event（syseventへの参照）が両方あります。生成されたメール1件ずつに「どの定義から作られたか」がひも付いているわけです。

全体の流れを図にすると、次のようになります。

sys_email自体は1,166件、sys_email_logは1,165件とほぼ1対1で対応していました。この環境のメールはほぼ全てNotificationの仕組みを経由して作られていることになります。なお type=sent（実際に外部へ送信済み）の記録は0件でした。このPDIはSMTP送信自体が止まっており、これは別記事「通知メールはどうすれば届く？」で扱った内容と一致します。本記事では sys_email_log に記録が残った時点を"発火した"の基準にしています。外部へ届いたかどうかは検証範囲外です。

生きている通知だけを数えると、ごく一部に偏る

sys_email_logをnotificationでdistinct集計すると、参照されている定義はちょうど37件でした。403件中37件ですから、割合にすると約9%です。中身を見ると、かなりの偏りがありました。

スケジュールジョブ由来が上位を占める

上位5件だけで1,009件、全体の約87%を占めていました。内訳はAsset RestockingとOn-Call Schedule - Gaps and Conflictsです。続くのはPA collection job with errorとwarning、On-Call Reminderでした。これらはいずれもスケジュールジョブが起点でした。資産の再発注チェックやOn-Callローテーションの確認、Performance Analyticsの収集ジョブが典型例です。人が操作しなくても、決まった間隔で走る処理から発火します。バッチ由来の通知には、運用日数が長いほど積み上がる性質があります。

人の操作で増える通知は件数がずっと少ない

Incident closed（8件）やComment left on incident（3件）、Request approved（3件）は、人がレコードを実際に操作したときだけ増える通知です。棚卸しの数字を読むときは、この2系統を混ぜずに見る必要があります。件数の多さがそのまま「よく使われている」を意味しないからです。

37件のうち残り32件は、1桁の件数がほとんどでした。KM記事の公開通知やSurvey Invitationのように、条件がそろったときだけぽつりと1件生成されるものが目立ちます。ランキング上位だけを見て主力通知を判断すると、業務担当者が実際に困っている通知を見落とすことになりかねません。

「定義のテーブル」と「実績のテーブル」が食い違うことがある

ここでもう一つ、棚卸しの落とし穴に気づきました。sys_emailをtarget_tableでグルーピングすると、もっとも件数が多かったのは alm_stock_rule（345件）でした。ところが sysevent_email_action に collection=alm_stock_rule の定義は、有効・無効を問わず1件も存在しません。

sys_email_logのnotification参照から逆にたどると、この345件の正体はAsset Restockingという通知でした。定義自体はTable=Asset（alm_asset）で作られていて、asset.restockというイベントで発火します。

定義画面のTableはalm_assetです。実際にイベントが発生する対象レコードは在庫ルール（Stock Rule）側になっており、生成されたメールのtarget_tableはalm_stock_ruleになっていました。Notificationの定義画面に表示されているTableと、実際に生成されたメールのtarget_tableは必ずしも一致しません。テーブル名だけで名寄せしようとすると、全体で最も件数の多いこの通知を見失うことになります。sys_email_logのnotification参照を起点にすべき理由は、ここにあります。

なぜ飛ばないのか：4つに分けて見る

有効な379件のうち342件は、少なくともこの環境では一度も送信ログを残していませんでした。なぜ飛ばないのかを実機の例で分類すると、次の4パターンに整理できます。

無効になっている

もっとも単純なのは、無効化されているケースです。理由は明快です。「Incident Inactive」はActive=falseで、無効な24件の一覧に含まれていました。

トリガーが設定されていない

次はトリガーが1つも設定されていないケースです。発火経路そのものがありません。「Incident Priority Raised」はevent_name・Insert・Updateのいずれも空で、conditionも空でした。標準の発火経路を持たない4件のうちの1つです。スクリプトやFlow Designerから明示的に呼び出す前提の定義とみられますが、実機からは断定できません。

条件・宛先で絞られて発火しない

3つ目は条件や宛先で絞られて実質的に発火しないケースです。興味深いのは、同じincident.commentedイベントから2つの通知が定義されている例でした。「Comment left on incident」は宛先がcaller_id（ほぼ必ず値が入る項目）で3件の実績があります。一方「Incident commented for ITIL」は宛先がassigned_to・watch_list（未割り当てのレコードでは空になりやすい）で、実績はゼロでした。

宛先が解決できないと、そもそもsys_emailのレコード自体が作られません。定義が有効で、イベントも実際に発生していても、宛先条件のせいで実績ゼロのまま埋もれてしまう通知があります。宛先の組み立てルールは Define email recipient qualifiers に整理されています。

生成された後に送信対象外になる

最後は生成された後に送信対象外になるケースです。sys_emailにはtype=send-ignoredが1件だけありました。件名は「Incident INC0010019 was created」、宛先はabel.tuter@example.com（PDI標準のデモユーザーで、実在の相手ではありません）です。error_stringは空欄で、具体的な抑制理由はこのレコードからは特定できませんでした。send-failed（送信失敗）とは違い、send-ignoredはエラーではなく意図的な抑制を意味する状態です。件数がごく少数だったため、この環境では大きな影響は見えませんでしたが、宛先の重複や配信除外の設定を持つ環境ではもっと目立つ可能性があります。

自分の環境で同じ棚卸しをする手順

ここまでの手順は、自分のインスタンスでもそのまま再現できます。

1. Notification一覧を開き、active=true^GROUPBYcollection で絞り込んで、有効な定義がどのテーブルに何件あるかを確認する

2. Email Logs一覧を開き、GROUPBYnotification で絞り込んで、実際に生成された件数を通知名ごとに確認する

3. 手順1の一覧にあって、手順2の一覧に出てこない通知名が「一度も生成されていない」候補になる

4. 気になる通知は、Email Logsを notification=<通知名> で絞り込み、0件かどうかを個別に確認する

5. 0件だった通知は、Active・When to send（Event/Insert/Update）・Conditions・Who will receiveの順に開き、4分類のどれに当たるかを見る

この手順の利点は、業務レコードを一切変更せずに読み取りだけで完結することです。棚卸しのためにテスト通知を送る必要はありません。

棚卸しの結果をどう使うか

実績ゼロの定義が大量に見つかった場合でも、その場で無効化するのは早計です。低頻度でも年に数回だけ発火する通知や、四半期末・年度末にしか条件を満たさない通知が混ざっている可能性があります。まずは一覧化して、業務担当者に「この通知は今も必要か」を確認する材料にするのが安全な進め方です。宛先やカテゴリの見直しを合わせて行うなら、Set notification preferences も参考になります。バージョンアップ前の棚卸しや、通知が多すぎるという苦情への一次回答としても使える手順です。逆に「実績はあるが飛びすぎている」通知が見つかった場合は、conditionを絞るか、対象のイベント自体の発火頻度を見直す方向で検討することになります。どちらの場合も、まず数字で全体像をつかんでから個別の定義を開くほうが、手戻りが少なく済みます。

実機で気づいたこと

テーブル名の一致だけでは棚卸しできない

今回いちばん意外だったのは、「定義のTable」と「実績のtarget_table」がずれる例が、しかも最大件数の通知で起きていたことです。Asset Restockingを見つけるまでは、target_tableとcollectionを単純に突き合わせれば棚卸しできると考えていました。ところがalm_stock_ruleという、定義側には存在しないテーブル名がsys_email側に出てきます。最初はNotification経由ではない特殊な送信元があるのかと疑いました。正体が分かったのは、sys_email_logのnotification参照まで遡ってからです。Asset Restocking（Table=Asset）は、Stock Rule側のレコードを対象にイベントを発火させていました。テーブル名の一致だけを根拠にする棚卸しは、こういう例を静かに取りこぼします。

同じイベントでも宛先設定で明暗が分かれる

もう一つ気づいたのは、同じイベントから飛ぶ通知でも、宛先設定次第で実績がゼロになりうる点です。Comment left on incidentとIncident commented for ITILは、どちらもincident.commentedイベントから発火する設計です。ところが宛先フィールドの違いだけで、実績には大きな差が出ていました。宛先が解決できないとsys_emailのレコード自体が作られないため、エラーとしてもログとしても残りません。障害調査で「通知が飛ばない」と言われたとき、条件式だけを疑って宛先設定を見落とすと、この種の原因は長く見つからないだろうと感じました。

collectionの値も鵜呑みにしない

集計の途中で、collection=incidentの定義を眺めていたときにも小さな驚きがありました。「Reset Password」や「System Upgraded」のように、Incidentと直接関係のなさそうな通知にもcollection=incidentが設定されていたのです。定義画面のTableは、必ずしも通知の意味的な対象を表しているとは限りません。棚卸しをするときは、名前と件名まで見て初めて中身が分かる、という前提で進めたほうが安全です。

用語

• Notification（sysevent_email_action）: 通知の定義そのもの。いつ・誰に・何を送るかを1レコードにまとめたもの

• Email Logs（sys_email_log）: 生成されたメール1件ごとに、どの通知定義・どのイベントから作られたかを記録するログ

• sys_email: 生成されたメールの実体。件名・宛先・送信状態（type/state）を持つ

• Send when: 通知フォームの「いつ送るか」を決めるタブ。Event is fired / Inserted / Updatedなどから選ぶ

• target_table: sys_emailが持つ、生成対象になった実際のレコードのテーブル名。通知定義側のcollectionとは別の値になることがある

• distinct集計: 同じ値の重複を除いて種類数だけを数える集計方法。本記事では「何種類の通知が実績を持つか」を数えるのに使った

自分の環境で確認するときのURL

https://<YourInstance>/sysevent_email_action_list.do?sysparm_query=active=true^GROUPBYcollection
https://<YourInstance>/sys_email_log_list.do?sysparm_query=GROUPBYnotification
https://<YourInstance>/sysevent_email_action_list.do?sysparm_query=active=false

検証環境・検証範囲

件数・画面はZurich PDI（OOTB）で2026-08-10に確認したものです。読み取り専用で調査しており、通知の有効・無効やデータの作成・更新は行っていません。メールも送信していません。本番環境やカスタマイズ済みの環境では数値が異なります。

以下は本記事の検証範囲外です。

• sys_emailが実際に外部のメールサーバーへ配信されたかどうか（type=sentは0件。原因は別記事「通知メールはどうすれば届く？」で確認済みです）

• sysevent（イベントキュー）は処理後に削除される設計のため、対象イベントが過去に一度も発生していないことの完全な証明はできません。本記事はsys_email_logの有無のみを実績の判定基準にしています

• 「Incident Priority Raised」がFlow Designer等から呼び出される設計かどうかは推測です

• 通知名が日本語の1件（ソフトウェア利用申請 受付のお知らせ）がOOTBかデモ拡張かは未確認です

• 本番環境での件数・比率。PDI固有の値であり、他インスタンスでは異なります

関連記事

• メール通知が飛ぶまでの4段階（Notification） — 通知定義の基本構造を先に押さえたい方向け

• 送信待ちで止まったメールを追う（sys_email） — sys_emailのフィールドや状態遷移を詳しく知りたい方向け

• ServiceNowの通知メールはどうすれば届く？ — 送信そのものが止まっている場合の切り分け手順