sys_emailを起点に最短で切り分ける実務ガイド
ServiceNowでメールがerrorになると、通知設定が悪いのか、イベントが飛んでいないのか、SMTP側の問題なのかがすぐ見えず、調査が長引きやすいです。
しかも現場では「通知は作った」「条件も合っているはず」「なのにメールが届かない」という状態になりやすく、原因が1つではなく複数層にまたがっていることも珍しくありません。
この手のトラブルは、やみくもに通知レコードだけを見ても解決しません。
まずは sys_emailの状態、Error string、関連ログ、Email Diagnostics、SMTP Senderの状態 を起点に、どの層で止まっているかを整理するのが最短です。ServiceNowでは、送受信されたメールは Email テーブルに記録され、Type や State によって送信失敗、送信スキップ、送信待ちなどを見分けられます。さらに、公式ドキュメントでもログとDiagnosticsを使った切り分けが案内されています。
この記事では、ServiceNowでメールがerrorになるときに、まず何を見ればよいのか、どの順で切り分けるべきかを、原因網羅型で整理します。
今すぐ直したい運用担当者だけでなく、CSA学習者が「通知はどの経路で送られるのか」を構造的に理解できる内容としてまとめます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まず確認すべきチェックリスト
メールエラー調査で最初に見るべき項目は、次のとおりです。
ここを飛ばして通知設定だけ触ると、遠回りになりやすいです。
sys_emailにレコードが作られているか確認する
最初に System Logs > Emails を開き、対象メールの sys_email レコードが存在するかを確認します。ServiceNowでは、送受信されたメールは Email テーブルに記録されます。ここに記録がないなら、通知生成以前で止まっている可能性が高いです。
見るべき主なフィールドは以下です。
- Type
- State
- Error string
- Target
- User
- Created
- Notification type
特にTypeは重要です。公式には、主に以下の状態が定義されています。
- sent
- send – failed
- send – ignored
- send – ready
- received
- received – ignored
実務上の見方はこうです。
- sys_emailがない
通知が生成されていない、イベント未発火、条件不一致の可能性 - send – readyのまま
送信ジョブやSMTP連携側を疑う - send – failed
送信試行はしたが失敗。Error string確認が最優先 - send – ignored
送信自体がスキップされた。重複、宛先なしなどを疑う - sent
ServiceNowからは送れている。受信側や中継先を疑う
よくある誤解は、通知レコードが有効なら必ずsys_emailが作られる と思ってしまうことです。実際には、条件不一致やイベント不発火なら作られません。
Error stringを必ず確認する
公式にも、個別メールが失敗した場合は Error string field を確認するよう案内があります。
Error stringでよく見るパターンは次のようなものです。
- 宛先アドレス不正
- SMTP接続失敗
- 認証失敗
- メールサーバー側拒否
- 重複送信判定
- recipient不在
ただし、公式にもある通り、一部のメールサーバーは詳細なerror stringを返さない場合があります。 その場合は「Error stringが空だから正常」とは言えません。
Email Diagnosticsを確認する
メール設定全体の健全性を見るなら、System Mailboxes > Email Diagnostics または System Diagnostics > Email Diagnostics を確認します。
この画面では、メール設定、スケジュールジョブ、アカウント接続など、送受信に影響する構成の状態を確認できます。
最低限見るべき項目は以下です。
- Email Sending Status
- Email in Queue
- Last Sent Mail
- SMTP Sender State
公式では、SMTP Senderジョブはデフォルトで毎分実行されるとされています。ここが止まっていると、send-readyが滞留しやすくなります。
送信待ちが溜まっていないか確認する
Email Diagnosticsの Email in Queue が多い、または sys_email の Type が send – ready に偏っている場合、通知自体は生成されているのに、送信側で詰まっている可能性があります。
このとき通知条件をいじっても根本解決になりません。
対象通知の条件と宛先を確認する
sys_emailが作られていても、宛先の生成結果 や 通知の受信者条件 が意図通りとは限りません。
Notification レコードでは特に以下を見ます。
- Active
- Table
- When to send
- Who will receive
- Users/Groups
- Send to event creator
- Exclude delegates
- Weight
- Content / Template / Layout
よくある誤解は、通知本文が見えているから送信条件も正しいと考えることです。本文生成と送信判定は別です。
原因の全体構造整理
ServiceNowでメールがerrorになる原因は、だいたい次の層に整理できます。
通知生成前の層
ここではまだメールレコード自体が作られていません。
- Notification条件不一致
- Event未発火
- Business RuleやFlowのロジック不備
- 送信対象テーブルの取り違え
- トリガーの想定違い
この層の特徴は、sys_emailが見つからない ことです。
通知生成の層
メールは作られたが、送る前に止まる層です。
- recipientが空
- 重複送信判定
- send-ignored化
- メールスクリプトエラー
- テンプレート参照ミス
この層では send – ignored が出やすいです。公式でも、send-ignoredは宛先不足や重複などでスキップされたメールとして説明されています。
送信処理の層
メールは送信待ちになったが、外に出ていかない層です。
- Email sending disabled
- SMTP Sender停止
- 送信キュー滞留
- SMTPアカウント設定不整合
この層では send – ready の滞留がヒントになります。Email Diagnosticsで把握しやすい領域です。
外部SMTP連携の層
送信処理は動いたが、SMTP側との通信で失敗する層です。
- 接続失敗
- 認証失敗
- TLS設定不整合
- 送信元制限
- サーバー側拒否
この層では send – failed と Error string が重要です。
受信者到達の層
ServiceNow上ではsentでも、利用者に届かない層です。
- 迷惑メール振り分け
- 受信側ゲートウェイ隔離
- 宛先ドメイン制限
- 配信後バウンス
- 共有メールボックス側の設定
公式でも、エンドユーザーに届かない場合は Junk 系のメールボックスや個別ログ確認が案内されています。
設計ミスの層
一時対処ではなく、設計思想の不足で再発する層です。
- イベント駆動と条件判定の役割分離不足
- 宛先設計の曖昧さ
- 通知乱立
- テンプレート依存の肥大化
- 監視運用の不足
CSA学習者にとって大事なのは、通知エラーを「設定ミス」ではなく、通知生成、送信処理、外部配信、到達確認の多層構造 として捉えることです。
原因層ごとの詳細解説
sys_emailが作られていない
この場合、メールエラーというより 通知がまだ生成されていない 可能性が高いです。
確認箇所
- 対象 Notification レコード
- Event Registry
- Event Log
- Flow Designer の実行履歴
- Business Rule の条件
- 対象レコードの更新履歴
実際に見るべきポイント
Notificationで確認するフィールドは以下です。
- Table
- Active
- When to send
- Condition
- Event name
- Advanced condition
イベントベースなら、イベント名のスペル違い、発火元スクリプトの条件不一致、対象テーブルのズレが頻出です。
レコード条件ベースなら、更新前後で条件を満たしていないことがあります。
たとえば、担当者変更時に送るつもりでも、Business Rule側が after update で別条件を持っていて、実際はイベントが飛んでいないことがあります。
よくある誤解
- 通知がActiveならメールは作られる
- イベント名が似ていれば問題ない
- Flowで通知アクションを置けば必ず送れる
実際は、通知トリガーの前段が止まればsys_emailは生成されません。
send – ignoredになる
send-ignoredは「送信失敗」ではなく、送信しない判断が行われた状態 です。
公式では、宛先メールアドレス不足や重複メールなどが典型例として挙げられています。
確認箇所
- sys_email の Type
- sys_email の Error string
- 通知の受信者設定
- ユーザーレコードの email
- 重複送信条件
- メールスクリプトでの宛先追加処理
実際に見るべきポイント
- 対象ユーザーの email が空でないか
- 参照先ユーザーが無効化されていないか
- グループ通知でメンバーのメールが欠けていないか
- 固定To/CC/BCCの指定が競合していないか
- メールスクリプトで
email.addAddress()などの処理が想定どおりか
特に、申請者や担当者を参照で持つ設計では、参照先ユーザーのメール空欄が原因になりやすいです。
また、複数の宛先生成ロジックが重なると、結果的に「同一送信」と判定されるケースもあります。
よくある誤解
- send-ignoredは軽微だから無視してよい
- 本文が生成されていれば送れる
- ユーザーが存在すれば宛先も有効
send-ignoredは「なぜ送らない判断になったか」を設計的に見直す入口です。
send – readyのまま進まない
send-readyが残り続ける場合、通知生成は成功していて、送信処理側で詰まっている と見てよいです。
確認箇所
- Email Diagnostics
- SMTP Sender Job
- Email sending enabled プロパティ
- メールアカウント設定
- キュー件数
実際に見るべきポイント
Email Diagnosticsでは次を見ます。
- Email Sending Status
- Email in Queue
- Last Sent Mail
- SMTP Sender State
公式では、Diagnosticsページで送信有効化状態やSMTP Senderの状態を確認でき、SMTP Sender job はデフォルトで毎分実行とされています。
たとえば、
- Email SendingがDisabled
- SMTP Senderが停止
- Last Sent Mailが古い
- Queueが増え続ける
この組み合わせなら、通知条件より先に送信基盤側を疑うべきです。
よくある誤解
- send-readyならもうすぐ送られる
- 通知を再保存すれば直る
- テストメールが1件送れたから本番も正常
ジョブ停止や送信無効化は、個別通知ではなく全体障害になりやすいです。
send – failedになる
send-failedは、送信しようとして失敗した 状態です。
ここでは Error string と外部SMTP要因の確認が最重要です。公式でも、個別失敗時は message log や Error string の確認が案内されています。
確認箇所
- sys_email の Error string
- メールアカウント設定
- SMTP認証情報
- 送信元アドレス
- 中継サーバー制限
- TLSや接続要件
実際に見るべきポイント
Error stringに以下のような示唆がないか見ます。
- authentication failed
- connection timeout
- relay denied
- invalid address
- mailbox unavailable
また、送信元アドレスのドメイン制限、SMTPサーバー側の許可IP、認証方式変更の影響など、ServiceNow外部に原因があることもあります。
よくある誤解
- send-failedなら通知設定が悪い
- エラーが空なら失敗原因はない
- 一部送れたからSMTPは正常
メールサーバー側は相手先や宛先ドメインごとに挙動が変わることがあります。
そのため、1件成功だけで全体正常とは判断できません。
sentなのに届かない
sys_emailが sent なら、少なくともServiceNowは「正常送信した」と認識しています。
ここから先は、受信者側や中継経路も視野に入れる必要があります。
確認箇所
- sys_email の Type = sent
- Junk 系メールボックス
- 受信側の迷惑メール
- 社内メールゲートウェイ
- 共有アドレスの転送設定
- バウンスメールの有無
公式でも、エンドユーザーが受信していない場合は、Junk System Mailbox や Error string、個別メールのメッセージログ確認が案内されています。
実際に見るべきポイント
- 同一宛先に他の通知は届いているか
- 特定件名だけ隔離されていないか
- 送信元アドレスが許可されているか
- HTMLレイアウトがフィルタ条件に触れていないか
よくある誤解
- sentならユーザーの受信箱に必ず届いている
- ServiceNow側で見えないので原因調査不可
- 受信者の迷惑メール設定は運用対象外
実務では、到達確認まで含めて通知品質です。
メールスクリプトやテンプレートが原因になる
通知条件ではなく、本文生成や宛先加工のスクリプトが原因でエラーになることもあります。
確認箇所
- Notification の Message HTML / Message text
- Email Template
- Email Layout
- Mail Script
- Script Include 参照
- ログ出力
実際に見るべきポイント
- テンプレート参照名の誤り
- Mail script の名前不一致
- null参照
- 宛先追加処理の条件漏れ
- レコード未存在時の例外
特にMail Scriptは、動いている前提で見てしまいがちです。
宛先加工や差し込みロジックを持たせている場合、そこで失敗すると通知全体が不安定になります。
よくある誤解
- 画面で保存できたからスクリプトも正常
- 本文エラーは送信失敗に関係ない
- テンプレート化すれば安全
テンプレート化は再利用性を高めますが、依存が深くなるほど切り分けは難しくなります。
実務での最短切り分けフロー
現場で最短で見るなら、次の順が効率的です。
まずsys_emailの有無を確認する
System Logs > Emails で検索します。
対象レコード、対象時刻、対象宛先で絞り込み、sys_emailがあるかを見ます。
- ない → 通知生成前の問題
- ある → 次へ
この一手で、通知条件を疑うべきか、送信基盤を疑うべきかが分かれます。
次にTypeとError stringを見る
ここで大まかな調査方向を決めます。
- send – ignored → 宛先、重複、通知生成ロジック
- send – ready → 送信ジョブ、送信設定、SMTP Sender
- send – failed → SMTP接続、認証、外部サーバー
- sent → 到達先、迷惑メール、ゲートウェイ
この切り分けは、ServiceNow公式のメールログの考え方と整合しています。
Email Diagnosticsで全体健全性を見る
個別メールだけ見ていると、全体障害を見落とします。
Email Diagnosticsで、Email Sending、Queue、Last Sent Mail、SMTP Sender State を確認します。
通知レコードに戻って条件と宛先を確認する
ここで初めてNotification設定を深掘りします。
- Tableは正しいか
- Event名は一致しているか
- Activeか
- 宛先は実在するか
- ユーザーemailは入っているか
- 余計な除外条件はないか
それでも不明なら受信側まで追う
sentでも届かないなら、受信側担当者と連携して迷惑メール、ゲートウェイ隔離、転送設定まで確認します。
設計観点からの再発防止
一度直して終わりにすると、同じ系統の障害がまた起きます。
ここでは、再発防止のための設計原則を整理します。
通知条件とイベント発火を分離する
通知ロジックを1か所に押し込まず、
- いつ送るか
- 誰に送るか
- 何を送るか
を分けて考えると保守しやすくなります。
イベント駆動に寄せると、トリガーの可視性が上がり、sys_email未生成の切り分けも速くなります。
宛先設計をデータ品質込みで考える
通知は設定だけで成立しません。
受信者にするユーザー、グループ、参照先レコードの email品質 が前提です。
再発防止としては、次を整備しておくと強いです。
- 必須ユーザーのemail空欄を監視
- 共有メールの運用ルールを定義
- 送信対象ロールと受信対象ロールを整理
- 参照先不在時の代替宛先ルールを決める
テンプレートとスクリプトの責務を軽くする
Mail Scriptに宛先判断、表示整形、条件分岐を詰め込みすぎると障害点が増えます。
本文整形はテンプレート、業務条件は前段ロジック、宛先決定は通知設定寄りに寄せた方が読みやすくなります。
監視対象を決める
通知が重要運用なら、少なくとも以下は定期監視候補です。
- send-failed件数
- send-ready滞留件数
- send-ignored増加
- Last Sent Mail の異常停止
- SMTP Sender State
- 重要通知の配信実績
Email notifications dashboard や diagnostics は、通知の健全性可視化にも役立ちます。公式でも、通知ダッシュボードや診断ダッシュボードによる可視化が案内されています。
通知を乱立させない
似た通知が複数あると、重複、送信漏れ、条件競合が起きやすくなります。
「誰に、どの状態変化で、何を通知するか」を一覧で整理し、通知設計を棚卸しすることが大切です。
まとめ
ServiceNowでメールがerrorになるときは、まず通知設定を触るのではなく、sys_emailを起点にどの層で止まっているかを見極める のが最短です。
見る順番を整理すると、次の流れが基本です。
最初に見る順番
- System Logs > Emails で sys_email を確認する
- Type と Error string を確認する
- Email Diagnostics で全体状態を確認する
- Notification の条件と宛先を確認する
- 必要に応じて受信側まで追う
特に覚えておきたい対応関係は以下です。
- sys_emailがない → 通知生成前の問題
- send – ignored → 宛先不足、重複、送信スキップ条件
- send – ready → 送信ジョブや送信基盤側
- send – failed → SMTPや外部連携側
- sentなのに未着 → 受信側や配信経路側
CSA学習の観点でも、通知は単なる設定画面ではなく、
イベント発火 → 通知生成 → sys_email記録 → SMTP送信 → 受信者到達
という流れで理解すると、仕組みの解像度がかなり上がります。
次に読むべき関連記事
メールerror調査の精度をさらに上げるなら、次のテーマもあわせて理解しておくと実務でつながります。
通知が飛ばないときの基本構造を整理したい場合
- ServiceNow 通知 条件が合っているのに送られない原因
- ServiceNow Event が発火しないときの確認ポイント
- ServiceNow sys_email の見方と状態一覧
通知設計そのものを見直したい場合
- ServiceNow 通知設計で重複送信を防ぐ考え方
- ServiceNow メール通知の宛先設計
- ServiceNow FlowとNotificationの使い分け
学習を深めたい場合
- ServiceNow CSAで押さえたい通知とイベントの基本
- ServiceNowでメール関連テーブルをどう理解するか
- ServiceNow運用担当者が知っておきたいログ確認の基礎
ServiceNowの通知まわりは、個別の障害対応だけで追うと断片知識になりがちです。
仕組みをまとめて整理したい場合は、公式ドキュメントを軸に学べる教材を1本持っておくと理解が進みやすいです。たとえば、体系的に学ぶ方法の一例としてUdemyのServiceNow講座を活用し、通知、イベント、ユーザー、ロール、ログのつながりをまとめて押さえる進め方があります。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
