ServiceNowの通知メールはどうすれば届く？原因の特定から送信設定の変更まで実機で試す

2026年8月9日 05:46

ServiceNowで「通知メールが届かない」と相談されたとき、原因の説明だけで終わらせず、実際に設定を直して何が起きるかまで確かめたくなります。今回のPDIでは、送信を止めていたプロパティを有効にしても、次はメールを外へ送るための接続先が1件も無いという壁に当たりました。原因の切り分け方から、実際に設定を変えて分かったことまでを、Zurich PDIで追います。

検証環境：Zurich PDI / OOTB / 2026-08-08〜09 確認

結論：原因は二段階だった

先に全体像です。

sys_emailは1,154件あり、うちsend-ready（送信待ち）が1,153件のまま滞留しています。まず疑うべきは通知定義ではなく、送信そのものです。
原因1はglide.email.smtp.activeというシステムプロパティがfalseになっていたことでした。実際にtrueへ変更しました。
ところが有効化しただけでは送信されませんでした。原因2として、メールを外へ送るための接続先（sys_email_account）が1件も設定されていないことが分かりました。
既存のインシデントに実際にコメントを1件追加し、新しい通知が生成されてから止まる場所までを最後まで確認しました。

上の図が今回たどり着いた状態です。業務レコードの変更からイベントが発生し、通知定義の条件に一致してsys_emailが生成され、送信スイッチを有効にするところまでは進みました。止まっているのは、その先にある送信アカウントの設定です。sys_email_accountが0件のため、スイッチをtrueにしてもメールは外へ出られません。図の緑色は動いている部分、赤色は止まっている箇所、橙色は送信待ちのまま溜まっている状態を表しています。

sys_emailをtypeで見ると、送信待ちだけが積み上がっている

まず見るのはメールの実体テーブルであるsys_emailです。typeでグループ化すると、状況がひと目で分かります。

全体で1,154件のうち、send-readyが1,153件、send-ignoredが1件でした。sentは0件です。通知メールが1通も出ていない状況は、この件数を見れば一目で分かります。sys_emailはメールが生成された時点でtype=send-readyとして作られ、送信が完了するとtype=sentに切り替わる仕組みです。send-readyのまま積み上がっているということは、生成はできているのに、そこから先に進んでいないという状態を意味します。仕様としては、送信に失敗するとtype=send-failed、対象外として除外されるとtype=send-ignoredになります。受信したメールは、type=receivedとして同じテーブルに記録される仕組みです。send-failedが0件だったので、送信を試みてすらいない状態でした。

sys_emailは送受信どちらのメールも1テーブルに集約するのが特徴です。outbound（通知など）とinbound（受信メール）が同じ形式で並びます。type列とmailbox列を組み合わせて見る癖をつけておくと、送信側の詰まりなのか受信側の詰まりなのかを素早く見分けられます。今回のPDIではinbound側の設定自体が無効なので、type=receivedの行は1件もありませんでした。

中身を開くと、宛先も件名も残ったまま止まっている

send-readyの中身も見ておきます。

宛先にはaileen.mottern@example.comやadmin@example.comといったアドレスが入っていました。件名も「Restocking Request For Dell Inc. PowerEdge M710HD Blade Server」のように、内容ごとに正しく組み立てられています。「On-Call Schedule: Network」のような日次のオンコール通知も混ざっていました。資産の再発注通知やパフォーマンス分析ジョブの結果通知、オンコールのリマインダーまで種類もさまざまです。Notification typeの列はSMTPで統一されています。1件1件のレコードとしては、宛先も件名も本文の元になる情報もすべて揃っている状態でした。あとは送るだけのところで、時間が止まっているように見えます。User IDの列はどの行も(empty)のままでした。宛先はRecipientsのメールアドレスで直接指定されていて、ServiceNow上のユーザーレコードとは紐付いていないケースが多いようです。

送信そのものが止まっていた — glide.email.smtp.activeを見る

sys_emailの中身が正しいのに送られていないなら、次に見るのは送信を制御するシステムプロパティです。

glide.email.smtp.active という項目があり、説明欄には「Email sending enabled」とあります。このプロパティ1つが、通知定義が何件あっても、sys_emailが何件生成されても、送信そのものを止めるスイッチです。この記事の検証を始めた時点では値はfalseでした。原因が分かったところで、実際にtrueへ変更しました。上の画面がその後の状態です。Updated列には変更した日時とadminというユーザーが記録されていて、直前に値が書き換わったことが分かります。あわせて確認すると、受信を制御するglide.email.read.activeもfalseのままでした（今回は変更していません）。System Propertiesの一覧を「glide.email.smtp」で絞り込むと、対象はmax_recipients_overallとこのactiveの2件だけでした。設定項目自体は少なく、探すのに迷う場所ではありません。

通知定義の数を確認しても、送信可否までは分からない

送信スイッチの話に入る前に、通知定義そのものの状態も確認しておきます。

通知定義（Notification）は全体で403件あり、activeなものが379件、inactiveが24件でした。一覧にはTable・Category・Email template・Conditions・Users/Groups in fieldsといった列が並び、条件や宛先の作りをざっと見渡せます。カテゴリを見るとConnect・Visual Task Board・Creator Studio・Service Catalogなど、自分でアプリを入れていなくても最初から多くの定義が入っています。Active=trueは「この定義は有効です」という意味であって、「メールが届きます」という意味ではありません。定義が有効でも、その先の送信処理が止まっていれば結果は同じになります。

inactiveな24件が何のために残っているかは、今回の調査範囲では確認できていません。実装の途中で無効化した定義や、別の仕組みに置き換えられた定義が含まれている可能性があります。Conditions列にはencoded query形式の条件式がそのまま表示されていて、GUIの条件エディタで組んだ内容が文字列として1行に収まる形です。Users/Groups in fields列は、レコード上の項目（Assigned toなど）を宛先に使う設定がある場合に埋まります。この列が空でも、Who will receiveタブ側でユーザーやグループを直接指定しているケースがあるため、空欄=宛先未設定とは限りません。

定義があっても届くとは限らない — 実際の1件を開く

一覧だけでは分かりにくいので、実際の定義を1件開いてみます。

開いたのは「Incident Opened and Unassigned」です。対象テーブルはIncident、Activeはチェック済み、Categoryは「IT Service Management」でした。フォームはWhen to send・Who will receive・What it will containの3タブに分かれています。When to sendタブの条件には「Assigned to is empty」が設定されていて、担当者が未設定のままIncidentが登録されたときに送る、という分かりやすい定義でした。設定そのものに問題は見当たりません。ただし今回のPDIでは、Incidentの新規登録を示すincident.insertedイベントが1件しか発生しておらず、この定義の対象になる場面自体がほとんどありませんでした。定義が正しく作られているかどうかと、実際にメールが生成・送信されるかどうかは、別の軸で確認する必要があります。

フォームには、複数回の更新をまとめて1通に配信するAllow Digestという機能も用意されていました。今回開いた定義ではMandatoryもAllow Digestもチェックが入っていません。Send whenの初期値は「Record inserted or updated」でした。Insertedにチェックを入れるかUpdatedにチェックを入れるかで、新規登録時に送るのか更新時に送るのかを切り替える仕組みです。今回の定義はInsertedのみが対象でした。条件を1つ足すごとにAND/ORの分岐が増えていく作りです。定義が複雑になるほど、この画面だけで送信可否を判断するのは難しくなります。困ったときはsys_email側から逆引きしたほうが早い理由は、ここにもあります。

イベントは動き続けているのに、メールは0通のまま

通知の起点にあたるイベントの状況も見ておきます。イベントは、レコードの更新や定期処理などをきっかけに「何かが起きた」という合図をキューに積む仕組みです。

イベントキューは合計12,326件で、常に増え続けています。内訳はglide.heartbeatが6,825件、flow.fireが3,313件でした。pa.dc.collect.predictive.completedのような分析ジョブ関連も585件あり、バックグラウンド処理由来のものが大半を占めています。イベントの発生自体は活発です。それでもsys_emailのsentは0件のままでした。差は歴然です。イベントは休みなく積まれているのに、メールだけが1通も外に出ていない。この差が、送信処理だけが止まっていることを裏付けています。

送信ログでも同じ件数が確認できる

最後に、イベント・通知定義・メールの対応関係を記録するsys_email_logも確認します。

sys_email_logは1,153件で、send-readyの件数とぴったり一致します。列はCreated・Email・Event・Notificationの4つです。Eventの列にはasset.restock、pa.job.dc.ended.with.warning、rota.on_call.reminderといった名前が並びます。どのイベントがどの通知（Asset RestockingやOn-Call Reminderなど）を経由してメールになったかを、この1行で追えます。sys_emailだけでは分からない「どの通知定義が原因でこのメールが作られたか」を調べたいときは、このテーブルが手がかりになるはずです。

ここまでの数字を一つの表にまとめました。sys_email・sysevent・sysevent_email_actionに加えて、この記事の後半で登場する送信アカウント（sys_email_account）も並べています。

切り分けの6ステップ

数字が揃ったところで、実際の調査順序を整理します。

この順番を守る理由は単純です。1〜3で送信側の状態が分かれば、通知定義を疑う前に原因を特定できます。逆に、いきなり通知定義の条件から調べ始めると、379件のactiveな定義を1件ずつ確認する作業になり、時間がかかるはずです。sys_email・glide.email.smtp.active・送信アカウントの3箇所を先に見るだけで、送信そのものが止まっているパターンは数分で判断できます。

実際に設定を直して、コメント追加から送信までを試した

原因の説明で終わらせず、実際にPDIの設定を変更し、既存のインシデントを1件更新して、メールが生成から送信までどこまで進むかを最後まで追いました。

既存のインシデントにコメントを1件追加する

対象に選んだのは、Assigned toにHoward Johnson（howard.johnson@example.com）が入っているINC0000002です。新規のIncidentは作らず、既存のレコードにコメントを1件追加しました。

コメントを投稿すると、フォーム下部のActivitiesにその内容がそのまま記録されます。ここまでは通知の有無に関係なく、Incidentの更新として当然に起きることです。

新しいsys_emailが1件、send-readyとして生成された

コメントの追加によってincident.commentedイベントが発生し、「Comment left on incident」という通知定義が反応しました。

宛先はfred.luddy@example.com、件名は「Comment added to INC0000002」、typeはsend-readyです。fred.luddyはPDIに最初から入っている組み込みのデモユーザーで、実在の相手ではありません。ここまでは、この記事の前半で見てきた1,153件の送信待ちメールと同じ生成のされ方です。

興味深いのはここからです。この記事で最初に例として開いた「Incident commented for ITIL」という別の通知定義も、同じincident.commentedイベントとconditionに一致するはずでした。ところが、実際にメールが生成されたのは「Comment left on incident」の1件だけでした。条件が一致することと、実際にメールが1通生成されることは、同じではないようです。

送信を有効にしても、数分待っても状態は変わらなかった

glide.email.smtp.activeはすでにtrueに変更済みです。このメールが実際に送信されるかどうかを、20秒間隔で20回、繰り返し確認しました。

結果は、type・stateとも変化なし。送信待ちのままでした。type=send-failedにすら変わりませんでした。送信を試みて失敗した形跡がない、という状態です。

原因はもう1段深かった：送信アカウントが1件も無い

システムログを確認すると、理由がそのまま記録されていました。

「There is currently no active SMTP account configured, cannot send email」というメッセージです。コメントを追加した直後から繰り返し記録されていました。送信を試みるたびに、接続先が無いことを確認して止まっている、という動きです。

実際にEmail Accountの一覧を開くと、レコードは1件もありませんでした。

glide.email.smtp.activeは「送信処理を試みるかどうか」のスイッチで、実際に送るための接続先（SMTPサーバーのホストや認証情報を持つEmail Account）は別に用意する必要があります。このPDIには、そのEmail Accountが最初から1件も設定されていませんでした。レガシーな単一プロパティ（サーバー・ユーザー・パスワードを直接指定する方式）も確認しましたが、こちらも空欄で、新旧どちらの経路にも接続先がない状態でした。

外部の実在するSMTPサーバーの資格情報は、この記事のためには用意していません。本番の受信者に誤って送信してしまうリスクを避けるため、架空のサーバー情報を追加で作ることもしませんでした。したがって、この記事で確認できたのは「送信スイッチを直しても、送信アカウントが無ければ止まる」というところまでです。1通が実際に外部へ送信されたところまでは確認していません。

インシデントのActivityに残ったもの

最後に、目的だったActivityの状態を振り返ります。先ほどのコメント追加の画面のとおり、INC0000002のActivityにはコメント自体は通常どおり記録されました。一方で、メールを送信したことを示す記録は最後まで現れませんでした。送信そのものが成立しない限り、Activity側にも送信のログは反映されないようです。

実機で気づいたこと

今回いちばん印象に残ったのは、「送信を許可するスイッチ」と「実際に送るための接続先」が別物だという点です。glide.email.smtp.activeをtrueにすれば送信が始まると考えていましたが、実機ではそこから先にもう1段、送信アカウントという壁がありました。この2つを分けて考えるようになると、本番環境で「有効化したのに届かない」という相談を受けたときの見る場所が変わります。

もう一つ意外だったのは、同じイベントに複数の通知定義が紐づいていても、実際にメールが生成されるとは限らないことです。「Incident commented for ITIL」と「Comment left on incident」はどちらもincident.commentedイベントとcommentsVALCHANGESという条件を持っています。それでも、今回生成されたのは後者だけでした。条件が一致するかどうかと、宛先が解決してメールが1通生成されるかどうかは、別の話のようです。担当者への通知が来ないという相談を受けたとき、条件だけを見て「合っているから届くはず」と判断するのは早計だと分かりました。

イベントの数がスクリーンショットを撮っている間にも増え続けていたことも、あらためて実感しました。glide.heartbeatのような定期処理が絶えず動いていて、PDIは何も操作しなくても内部では常に処理が走っています。その一方でsys_emailのsentは常に0件のままでした。動いている部分と止まっている部分が、これほどはっきり分かれているとは思っていませんでした。

send-readyの宛先を見比べると、ほとんどがexample.comドメインでした。デモ用のユーザーはメールアドレスがexample.com固定になっていて、実際に外部へ届くかどうかを試せる前提そのものがPDIには無いことも、あらためて確認できました。素のPDIにはデモ用の資産データやオンコールのローテーションが最初から入っていて、それに紐づく通知定義も日々動いています。本番構築の練習中に「メールが増えている」と感じたら、自分の設定を疑う前に、こうした標準データの存在を思い出す価値があります。

実務では何に使えるか：本番で通知が止まったときの確認順

本番環境で「通知メールが届かない」という報告を受けたとき、自分なら次の順番で見ます。

sys_emailをtypeでグループ化し、send-readyやsend-failedが積み上がっていないか確認する
積み上がっていれば、glide.email.smtp.activeを確認する。falseなら、まずここを直す
trueなのに送信されない場合は、System Mailboxes > Outbound > AccountsでEmail Accountが1件以上、activeな状態で存在するか確認する
sentになっているのに届かない場合は、SMTPサーバー側のログやバウンスメールを確認する範囲に切り替える
sys_emailに該当レコードが無い場合だけ、通知定義の条件・宛先・activeを個別に開く
それでも原因が分からない場合は、対象のイベントがsysevent側で発生しているかまで遡る

通知定義から先に調べ始めると、379件を1件ずつ開く作業になりがちです。sys_email・送信有効化・送信アカウントの3点を先に確認する習慣をつけておくと、原因の多くはこの時点で判断できます。

本番環境でglide.email.smtp.activeやEmail Accountを変更する場合は、検証環境よりも一段注意が必要です。送信待ちのメールが大量に溜まった状態でスイッチを有効化すると、その時点で宛先が有効な全件に対して一斉送信が走るおそれがあります。変更前には、対象件数と宛先の妥当性をまず確認してください。営業時間外や利用者が少ない時間帯に切り替えると安全です。テスト用のEmail Accountで少数だけ試してから、本番のAccountに切り替える方法もあります。glide.email.smtp.activeもEmail Accountも管理者権限が必要な設定です。変更の前後にはインシデントやチェンジの記録を残しておくと、あとから見直しやすくなります。

メール通知が飛ぶまでの4段階(Notification) — sysevent_email_actionの構造から理解したい人向けの前提知識
送信待ちで止まったメールを追う(sys_email) — sys_emailのtype・mailbox・state をさらに詳しく追う実務編
通知の宛先を持つ通知デバイス(cmn_notif_device) — 送信は有効なのに特定の人にだけ届かない場合に見る次のテーブル

よくある質問

Q1. send-readyが溜まっているとき、通知定義を直せば届きますか

直りません。送信そのものがglide.email.smtp.activeやEmail Accountの設定で止まっている場合、通知定義をどう直しても結果は変わりません。まず送信側の3ステップ（送信の有効化・送信アカウント・sys_emailの状態）を確認するのが先です。

Q2. glide.email.smtp.activeをtrueにすれば、溜まっているメールは届きますか

届くとは限りません。実機で確認したところ、trueに変更しただけでは送信されませんでした。かわりに「There is currently no active SMTP account configured, cannot send email」というログが記録され続けました。送信にはEmail Account（sys_email_account）で接続先を設定する必要があります。溜まっている件数が多い環境でEmail Accountを追加する場合は、有効化した直後に一斉送信される可能性も考えておく必要があります。

Q3. active=trueの通知定義が379件もあるのはなぜですか

自分で作っていなくても、標準機能や各アプリが最初から多数の通知定義を持ち込んでいるためです。Connect・Visual Task Board・Service Catalogなど、カテゴリを見るだけでも由来が多様なことが分かります。

Q4. イベント(sysevent)とメール(sys_email)の件数が一致しないのはなぜですか

数えている対象が違うためです。sysevent側は「発生した合図の数」、sys_email側は「その合図から実際に生成されたメールの数」です。1つのイベントが複数の通知定義に一致することもあれば、条件に合わず何も生成されないこともあります。今回のように、条件が一致していてもメールが1件しか生成されないケースもありました。

Q5. Email Accountを追加すれば、実際にメールは届きますか

本記事では確認していません。実在するSMTPサーバーの資格情報を用意していないためです。本番環境では、自社のメールサーバーやクラウドメールサービスの接続情報（ホスト名・ポート・認証情報）が必要になります。設定後は、まず自分宛てなど限定した宛先で1通だけ試すことをおすすめします。

まとめ

sys_emailは1,154件のうち1,153件が送信待ちで止まり、送信済みは0件でした。原因は二段階あります。1つ目はglide.email.smtp.activeがfalseだったこと、2つ目はtrueに変更したあとも送信アカウント（sys_email_account）が1件も設定されていなかったことです。実際にインシデントへコメントを追加して新しい通知を1件発生させ、送信スイッチを直しても、送信アカウントが無ければ送信待ちのまま止まることを最後まで確認しました。

通知が届かないという相談を受けたら、通知定義から調べ始めるより先に、sys_emailの滞留状況・送信の有効化・送信アカウントの3点を確認したほうが早く原因にたどり着けます。

用語

sys_email … メールの実体レコード。type（送信状態）やmailboxを持つ
sysevent … イベントキュー。何かが起きた合図を一時的に積むテーブル
sysevent_email_action … 通知定義(Notification)の実体テーブル
glide.email.smtp.active … メールの送信処理そのものを有効／無効にするシステムプロパティ
sys_email_account … 実際にメールを送るための接続先(SMTPサーバー・認証情報)を持つテーブル。System Mailboxes > Outbound > Accountsで管理する
sys_email_log … イベント・通知定義・メールの対応関係を記録するログテーブル

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

/sys_email_list.do?sysparm_query=GROUPBYtype
/sys_email_list.do?sysparm_query=type=send-ready^ORDERBYDESCsys_created_on
/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.email.smtp
/sysevent_email_action_list.do?sysparm_query=active=true^ORDERBYname
/sysevent_email_action.do?sys_id=<通知定義のsys_id>
/sysevent_list.do?sysparm_query=GROUPBYname
/sys_email_log_list.do?sysparm_query=ORDERBYDESCsys_created_on
/incident.do?sys_id=<インシデントのsys_id>
/syslog_list.do?sysparm_query=messageLIKEcannot send email^ORDERBYDESCsys_created_on
/sys_email_account_list.do

参考リンク

検証環境と未検証範囲

件数・画面はZurich PDI（OOTB）で確認したものです。本番環境やカスタマイズ済みの環境では数値が異なります。この記事のために、検証環境のglide.email.smtp.activeをfalseからtrueに変更しました。元には戻していません。

実際に外部のメールサーバーへ1通が届いたかどうかは、今回は確認していません。実在するSMTPサーバーの資格情報を用意していないためです。受信（インバウンドメール）の動作、宛先解決（Users・Groups・Email addresses）の優先順位、メール本文のテンプレート展開結果も確認範囲の外です。sysevent（イベントキュー）の件数は常時変動するため、本文の数字は確認した時点のスナップショットとして読んでください。