メール通知が飛ぶまでの4段階（Notification）
ServiceNow で「インシデントが割り当てられるとメールが届く」「変更が承認されると通知が来る」といった挙動は、いくつかのテーブルの連携で実現されています。通知が飛ぶまでには①きっかけ／②通知定義／③メールレコードの生成／④送信という段階があります。それぞれ別のテーブルが担当します。
この記事では、メール通知をプロセス論ではなく、実際のテーブルを起点に追います。確認するのは、きっかけになるイベント（sysevent）や record の登録/更新です。あわせて、通知の中身を定義する Notification（sysevent_email_action）と、生成されるメールレコード（sys_email）も確認します。さらに、登録済みイベント名を持つ Event Registry（sysevent_register）とメールテンプレート（sysevent_email_template）も確認します。
この記事は、ServiceNow の Incident は触ったことがあるが、メール通知が「どのテーブルを通って飛ぶのか」をこれから理解したい人を想定しています。管理者・開発者が実機で「通知が飛ばない／二重に飛ぶ」を切り分けるときに見るべき、テーブルと項目をまとめます。
この記事で分かること
メール通知が飛ぶまでの 4 段階（きっかけ→通知定義→メール生成→送信）と担当テーブル
通知定義 sysevent_email_action が「いつ・誰に・何を」をどの項目で持つか
「いつ（Send when）」の 3 種別（Record inserted or updated / Event is fired / Triggered）の違い
生成されるメールレコード sys_email の type / state / mailbox の値
Event Registry（sysevent_register）の役割と、イベントキュー（sysevent）との関係
「飛ばない／二重に飛ぶ」を切り分けるとき、どのテーブルを見るか
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、通知定義・フィールド・件数・選択肢の内容が異なる場合があります。送信スケジューラや SMTP の実挙動には踏み込みません。
Email Notification（メール通知）とは
Email Notification は「いつ・誰に・何を」を 1 つの通知定義にまとめて登録しておく仕組みです。ServiceNow の Email Notification は、レコードの登録/更新やイベントの発火をきっかけに、宛先・件名・本文を定義しておき、自動でメールを生成・送信します。「割り当てられたら担当者にメール」「承認待ちになったら承認者にメール」といった連絡を、コードを書かずに通知定義として登録できます。公式の概要は Email and SMS notifications を参照してください。
通知は 1 つのテーブルで完結していません。通知の定義、実際に作られる個々のメール、きっかけになるイベントは、それぞれ別のテーブルに分かれています。だから「通知が飛ばない」ときも、どの段階で止まっているのかをテーブルで切り分けられます。
通知が飛ぶまでの 4 段階
まず全体像です。今回確認した PDI（Zurich / OOTB）では、メール通知は次の流れで動く構成でした。
① きっかけ … イベント（sysevent にイベントが積まれる）か、対象テーブルのレコード登録/更新。
② 通知定義 … Notification（sysevent_email_action）が「いつ・誰に・何を」を定義し、条件と宛先で送るかどうかを判定。
③ メール生成 … 送る場合、メールレコード（sys_email）が 1 通＝1 レコードとして作られ、送信キュー（Outbox 系）に置かれる。
④ 送信 … メールレコードが実際に外部へ送られる。送信処理（スケジューラ／SMTP）の中身は本記事の範囲外です。
つまり「通知定義」と「実際のメール」は別物です。sysevent_email_action は設計図（テンプレート）、sys_email はそこから作られた 1 通 1 通の実体、と捉えると切り分けやすくなります。
通知定義（sysevent_email_action）の構成要素
通知定義は「いつ・誰に・何を」「条件」の 4 軸で読むと迷いません。通知定義は sysevent_email_action テーブルに保存され、画面ラベルは Notification です。今回の PDI では super_class が sysrule（Rule）で、メタデータ（Application File）系として管理されていました。固有フィールドは 54 ありますが、読み解く軸は「いつ・誰に・何を」「条件」の 4 つです。公式の作成手順 Create an email notification も、When to send / Who will receive / What it will contain という同じ並びで項目を説明しています。
4つの軸で読み解く
いつ … generation_type（画面ラベル Send when）。後述の 3 種別。
誰に …
recipient_users（ユーザー）
recipient_groups（グループ）
recipient_fields（レコード上のユーザー/グループ項目）
send_self（イベント作成者本人に送るか）
exclude_delegates（委任先を宛先から除外するか）
何を … subject（件名）／ message（本文）／ message_html（HTML本文）／ template（→ sysevent_email_template）／ style（→ sysevent_email_style、Stationery）／ category（→ sys_notification_category）。
条件 … condition（条件）／ advanced_condition（スクリプト）／ event_name（待ち受けるイベント名）。
宛先は「ユーザー」「グループ」「レコード上の項目（例：Assigned to）」の複数経路で指定できます。二重送信を調べるときは、この複数経路で同じ人が重複していないかを見ます。固有フィールドには digestable / default_digest / digest_template というダイジェスト配信用の項目もありました。個別送信をまとめて送る仕組みも標準で用意されていますが、動作までは確認していません。
「いつ（Send when）」の 3 種別
「通知が飛ばない」でまず見るのは、この generation_type（Send when）です。今回の PDI では 3 種類でした。
value 画面ラベル 意味（いつ通知が動くか） 主に見る項目
------------------------------------------------------------------------------------------------
engine Record inserted or updated 対象テーブルのレコード登録/更新で評価される condition（条件）
event Event is fired 指定イベント名が発火したときに動く event_name
triggered Triggered Flow Designer 等から明示的に呼ばれる 呼び出し元（Flow）同じテーブルでも when は混在する
Record inserted or updated（engine） … 対象テーブルのレコードが登録/更新されたときに、condition（条件）で送るか判定します。条件に合わなければ飛びません。
Event is fired（event） … 指定した event_name のイベントが発火したときに動きます。イベントが積まれなければ飛びません。
Triggered（triggered） … Flow Designer などから明示的に呼ばれて動きます。
実機の OOTB 通知を見ると、同じ incident テーブルの通知でも when は混在します。「Incident Opened and Unassigned」は Record inserted or updated でした。「Incident Escalated」は Event is fired です。「Incident Priority Raised」は Triggered でした。だから「通知が飛ばない」ときは、まずその通知の when を確認します。engine なら condition、event なら event_name とイベント発火、triggered なら呼び出し元（Flow）を見ます。
通知定義の一覧は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。
https://<YourInstance>/sysevent_email_action_list.do?sysparm_query=active=true
生成されるメールレコード（sys_email）
通知定義が「送る」と判定すると、実際のメール 1 通が sys_email テーブルに作られます。sys_email は独立テーブル（super_class 空）で、固有フィールドは 33 でした。ここを見れば「メールが作られたのか／送られたのか」が分かります。
区分 フィールド / 値 内容
------------------------------------------------------------------
主フィールド target_table / instance どのレコード由来か（対象テーブルと対象レコード）
主フィールド recipients / copied / blind_copied 宛先・Cc・Bcc
主フィールド subject / body 件名・本文
type（処理種別） send-ready 送信待ち（生成直後）
type sent 送信済み
type send-failed 送信失敗
type send-ignored 送信対象外として無視
type received / received-ignored 受信メール側
state ready / processed / ignored / error 処理状態
mailbox（→sys_mailbox） Outbox / Sent / Failed / Skipped 送信前/済/失敗/スキップの置き場type・state・mailboxの3項目で状況が分かる
type … 処理種別です。今回の PDI で確認できた値は、生成直後の send-ready（送信待ち）／送れた sent／失敗の send-failed／対象外の send-ignored／翻訳待ちの send-translation-ready などでした。received 系は受信メール用です。
state … ready / processed / ignored / error の処理状態。
mailbox … sys_mailbox を参照する項目で、Outbox / Sent / Failed / Skipped のほか、受信側で使う Inbox / Junk / Received もありました。送信・受信の両方の置き場を、この1テーブルで管理する作りです。
切り分けるときは、sys_email に行があるかどうかが分岐点になります。行が無ければ、通知定義の段階（条件・宛先・when）で止まっています。行はあっても type=send-ignored / state=ignored なら、生成はされたが送信対象外になっています。
送信前後のメールレコードは、次のURLで確認できます。
https://<YourInstance>/sys_email_list.do?sysparm_query=ORDERBYDESCsys_created_on
Event Registry（sysevent_register）とイベントキュー（sysevent）
when が「Event is fired」の通知は、イベントが発火しないと動きません。そのイベントの「名前の定義」を持つのが Event Registry（sysevent_register）です。
整理すると次の関係です。
定義とキューは別テーブル
sysevent_register（Event Registration） … システムが扱えるイベント名の登録簿。Application File 系（メタデータ継承）のテーブルで、「どんなイベント名が存在するか」を定義します。今回の PDI では 763 件ありました。
sysevent（Event） … 実際に発火したイベントが積まれるキュー。super_class が空の独立テーブルで、gs.eventQueue('incident.commented', ...) のような呼び出しで行が積まれます。参考までに、今回の PDI では発火済みのイベントが 9,201 件たまっていました。定義（763件）より実行ログ（9,201件）のほうが多いのは、1つの定義に対して同じイベントが繰り返し発火するためです。
Notification（when=event） … event_name でこのキューを待ち受け、一致したイベントで動きます。
だから event 型の通知が飛ばないときは、「そのイベントが本当に発火しているか（sysevent にイベント名の行があるか）」を確認します。逆に、同じ event_name を待つ通知が複数 active なら、1 つのイベントで複数のメールが飛ぶ（＝二重に見える）原因になります。
イベント登録簿は、次のURLで確認できます。
https://<YourInstance>/sysevent_register_list.do
「飛ばない／二重に飛ぶ」をどこで見るか
読者の一番の疑問は「通知が飛ばない／二重に飛ぶのはどこを見ればいいか」です。これまでのテーブルを使うと、次のように切り分けられます。
飛ばない：まず Notification が active か、condition と宛先が合うか、when と event_name の対応を確認。次に sys_email に行があるか、type=send-ignored / state=ignored になっていないかを確認。行が無ければ定義側、行があれば送信側の問題、と層が分かれます。
二重に飛ぶ … 同じ event_name や同じ条件の Notification が複数 active になっていないかを確認します。宛先（users＋fields＋groups）で同じ人が重複していないかも確認します。
「通知定義（sysevent_email_action）」と「実体（sys_email）」を分けて見るのがコツです。どちらの段階で起きている問題かが分かれば、見るべきテーブルが決まります。
メール通知まわりのテーブル件数
参考として、メール通知に関わる主要テーブルの件数を載せます。今回確認した PDI（Zurich / OOTB・2026-06-20確認）の値です。
テーブル 役割 件数
---------------------------------------------------------------------------------
sysevent_email_action（Notification・全体） 通知定義（いつ・誰に・何を） 386
sysevent_email_action（active=true） 有効な通知定義 364
sys_email（Email） 生成された個々のメールレコード 700
sysevent_register（Event Registration） 登録済みイベント名の定義 763
sysevent_email_template（Email Template） メールテンプレート 83
OOTBの通知定義386件が「原因不明の通知」の正体
「何もしていないのに通知が飛ぶ」場合、たいていは OOTB の通知定義が原因です。今回の PDI では、OOTB の時点で 386 件（うち active 364 件）もの通知定義が登録されていました。メールテンプレート（sysevent_email_template、Application File 系のテーブル）も 83 件ありました。侮れない数です。自分で作った覚えがなくても、まず active な通知定義の一覧を、対象テーブル（collection）や event_name で絞って探すのが近道です。どんな通知が初期から入っているかは、公式の一覧 Baseline email notifications でも確認できます。
ServiceNow のメール通知のポイント
メール通知は 1 テーブルでは完結しません。きっかけ（sysevent / record）→通知定義（sysevent_email_action）→メール実体（sys_email）→送信 の段階に分かれています。問題の切り分けは、この段階のどこで止まったかを見ます。
通知定義（sysevent_email_action・ラベル Notification）は「いつ・誰に・何を」を 54 の固有フィールドで持ちます。内訳は、いつ（generation_type）・誰に（recipient_users/groups/fields・send_self）・何を（subject/message/template）です。
「いつ」は Record inserted or updated（engine）／ Event is fired（event）／ Triggered（triggered）の 3 種別です。同じテーブルでも混在します。飛ばないときは when ごとに見る項目（condition / event_name / 呼び出し元）が変わります。
実際のメールは sys_email に 1 通＝1 レコードで作られます。type（send-ready / sent / send-ignored 等）・state・mailbox（Outbox / Sent / Failed）で状況が分かります。行の有無が定義側と送信側の分かれ目です。
Event Registry（sysevent_register・763 件）は扱えるイベント名の登録簿で、実際の発火はキュー sysevent に積まれます。event 型の通知はこの発火を待ち受けます。
二重送信は「同条件の通知が複数 active」または「宛先の重複」を疑います。
メール通知を調べるときは、まず「定義（sysevent_email_action）」と「実体（sys_email）」のどちらを見るかを切り替えます。when（Send when）に応じて condition・event_name・呼び出し元のどれを確認するかを決めるのが近道です。
実機で気づいたこと
同じ Incident テーブルの通知でも Send when が engine・event・triggered の3種に混在していたのは意外でした。てっきり1つのテーブルなら送信方式も統一されていると思っていましたが、実際には機能追加の時期や用途によって、レコードベース・イベントベース・Flow起点が混ざって共存しています。調査するときは「このテーブルの通知は when で統一されている」という前提を捨てたほうがよさそうです。
sys_email は送信専用のテーブルだと思っていましたが、type に received / received-ignored という受信メール用の値もあり、送信も受信も同じ1テーブルで管理する作りだと分かりました。送受信共通の起点です。メール関連のトラブルでは、まずここを確認します。
Event Registry（sysevent_register）の定義は763件なのに対し、実際に発火したイベントを積む sysevent は9,201件でした。「定義」と「実行ログ」は別物で、1つの定義に対して同じイベントが繰り返し発火するぶん、ログの件数のほうが大きく膨らむと分かります。通知定義（sysevent_email_action）と実体（sys_email）の関係と、根っこは同じ構図です。
次に読むなら
次に確認するなら、Notification の condition と advanced_condition の書き分けです。recipient_fields でレコード上のどの項目（Assigned to など）を宛先にするかも確認どころです。そしてメールテンプレート（sysevent_email_template）と Stationery（style）による本文の組み立ても対象になります。さらに、event 型通知の前提になる Event Registry の登録方法があります。sys_email から実際に送信されるまでのスケジューラ側の挙動は、本記事で「範囲外」とした部分です。これらは別記事で扱う予定です。
用語
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Notification：sysevent_email_action テーブルの通知定義（「いつ・誰に・何を」の設計図）
メールレコード：sys_email テーブルの 1 通 1 通の実体
イベントキュー：sysevent テーブル（発火したイベントが積まれる）
Event Registry：sysevent_register テーブル（扱えるイベント名の登録簿）
Send when：通知定義のフィールド generation_type（いつ送るか）
自分の環境で確認するときのURL
先頭に自分のインスタンスを付けると、同じ画面が開けます。
通知定義(active) : sysevent_email_action_list.do?sysparm_query=active=true
メールレコード : sys_email_list.do?sysparm_query=ORDERBYDESCsys_created_on
イベント登録簿 : sysevent_register_list.do
イベントキュー : sysevent_list.do?sysparm_query=ORDERBYDESCsys_created_on
メールテンプレート : sysevent_email_template_list.do
通知定義のフィールド : sys_dictionary_list.do?sysparm_query=name=sysevent_email_action^elementISNOTEMPTY検証範囲とおことわり
確認した範囲（すべて PDI／Zurich／2026-06-20 確認の OOTB で取得）:
sysevent_email_action / sys_email / sysevent の super_class（テーブルの位置づけ）
sysevent_register / sysevent_email_template の super_class（テーブルの位置づけ）
固有フィールド数（通知定義 54 / メール実体 33）
Send when（generation_type）の 3 種別
sys_email の type / state / mailbox の値
各テーブル件数
代表的な OOTB 通知の when と event_name の混在
確認していない範囲（これらは別記事で扱います）:
送信スケジューラ（Email Sender）や SMTP の実挙動
sys_email が実際に外部へ送られるまでのタイミング
各通知の condition / advanced_condition のスクリプト内容
ダイジェスト配信の動作
Flow Designer から triggered で呼ぶ通知の実行経路
メールテンプレートの組み立て詳細
今回は PDI の OOTB（初期設定）を前提に、メール通知が飛ぶまでのテーブル構造を確認しました。実環境では、既存のカスタマイズによって通知定義や設定の数・内容が変わります。
