ServiceNowでOutbound Emailが無効なときの確認ポイントと切り分け方　送信されない原因を構造的に整理

ServiceNowで通知やメール送信の確認をしているとき、思ったより多いのが「通知設定は合っているように見えるのに、そもそもOutbound Emailが無効になっていて送れない」というケースです。

この状態は、単純にメールが飛ばないだけではありません。通知レコード、イベント、Flow Designer、ユーザー設定などを一生懸命見ても、土台となる送信機能自体が無効なら原因の切り分けが遠回りになります。
特に管理者になりたての時期やCSA学習中は、通知の条件ミスと送信機能の無効化を混同しやすく、調査が長引きやすいポイントです。

ServiceNowでは、Email Propertiesの送信設定でアウトバウンドメールの有効・無効を制御できます。また、システムメールログでは sys_email テーブルを使って、send-ready、send-ignored、send-failed、sent などの状態を確認できます。これらは切り分けの起点として非常に重要です。

この記事では、ServiceNowでOutbound Emailが無効なときにどこを見ればよいのかを、実務の切り分け順で整理します。
「今すぐ直したい」人にも、「なぜそうなるのかを構造的に理解したい」CSA学習者にも役立つように、確認箇所・フィールド名・よくある誤解まで具体的にまとめます。

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

最初に、深く調べる前に見るべきポイントをまとめます。
緊急時はこの順で確認すると、遠回りしにくくなります。

Email Propertiesで送信自体が有効か確認する

まず確認したいのは、メール送信機能そのものが無効になっていないかです。
ServiceNowのEmail Propertiesには、Outbound Mail Configurationがあり、glide.email.smtp.active で送信有効・無効を制御します。画面上では通常、Email sending enabled のような項目として確認できます。

ここが無効なら、通知の条件やテンプレートが正しくても、外向きメールは送れません。

確認箇所
System Mailboxes > Email Properties
または
System Properties > Email Properties

実際に見るべきフィールド名や状態例
glide.email.smtp.active = true なら送信有効
glide.email.smtp.active = false なら送信無効

よくある誤解
通知レコードがActiveならメールも飛ぶ、と思い込みがちですが、通知の有効化とメール送信機能の有効化は別です。

sys_emailにレコードが作成されているか確認する

次に、sys_email に対象メールのレコードが作られているかを見ます。
ここに何も出ていないなら、送信以前に通知やイベントが生成されていない可能性が高いです。逆に、sys_email に出ているなら、少なくともメール生成までは進んでいます。

確認箇所
sys_email.list

実際に見るべきフィールド名や状態例
type または状態欄
send-ready
send-ignored
send-failed
sent

ServiceNowのシステムメールログでは、send-ready は送信準備完了、send-ignored は送信スキップ、send-failed は送信失敗、sent は送信済みを意味します。

よくある誤解
sys_email にあるから送信済み、ではありません。send-ready のまま停滞していることもあります。

エラー文字列と受信者情報を確認する

sys_email にレコードがある場合は、その詳細を開き、受信者やエラー内容を確認します。
特に send-ignored や send-failed のときは、エラー文字列がかなり重要です。

確認箇所
sys_email レコード詳細

実際に見るべきフィールド名や状態例
recipients
direct
copied
blind_copied
error_string

よくある誤解
エラーが出ていないから正常、とは限りません。受信者が空で send-ignored になるケースもあります。

通知レコードが本当に発火対象か確認する

Outbound Emailが有効でも、通知レコードが条件不一致ならメールは生成されません。
通知の問題なのか、送信機能の問題なのかを分けるために、通知レコードも並行して確認します。

確認箇所
System Notification > Email > Notifications

実際に見るべきフィールド名や状態例
Active
Table
When to send
Who will receive
条件欄
イベント名

よくある誤解
「条件は見た」「イベント名も合っている」と思っても、対象テーブル違い、イベント名のスペル違い、受信者指定漏れが残っていることは珍しくありません。

PDIや検証環境かどうかを確認する

開発用のPersonal Developer Instanceでは、実メール送信の挙動が本番・正式環境と同じ前提で考えないほうが安全です。コミュニティでもPDIでOutboundが使えない前提の話題が継続的に見られます。

確認箇所
利用中インスタンスの種別
環境方針
メール送信制限の有無

よくある誤解
「以前は動いたから今回も同じはず」と考えてしまうことです。環境ポリシーや設定差分で条件が変わることがあります。

原因の全体構造整理

Outbound Emailが無効、または送れないときの原因は、だいたい次の層に分けて考えると整理しやすくなります。

送信基盤の層

ここはメール送信機能そのものです。
代表例は glide.email.smtp.active が false のケースです。
この層で止まると、通知設計が正しくても外部へ送れません。

メール生成の層

通知、イベント、Flow Designer、スクリプトなどが動き、sys_email にメールレコードが作られるかどうかの層です。
ここで失敗すると、sys_email に何も出ません。

送信対象の層

受信者が取得できているか、メールアドレスが有効か、送信対象として除外されていないかを見る層です。
ここに問題があると、send-ignored になりやすいです。ServiceNowのドキュメントでも、受信者不備や重複が send-ignored の代表例として示されています。

SMTP処理の層

send-ready から sent に進むところで失敗していないかを見る層です。
SMTP接続や送信処理の問題があると send-failed の確認が必要になります。

設計運用の層

そもそも「検証環境では送らない運用」「特定ドメインだけ制限」「通知を個別に乱立」など、設計や運用ルールによって意図的に無効化されている場合があります。
実務ではこの層が地味に多く、設定ミスではなく運用判断の結果であることもあります。

原因層ごとの詳細解説

ここからは、実際に起こりやすい原因を層ごとに深掘りします。

送信設定が無効になっている

Email sending enabledがオフになっている

もっとも直接的な原因です。
Email Propertiesで送信機能がオフなら、まずそこを戻さない限り前に進みません。ServiceNow公式ドキュメントでは、Outbound Mail Configurationの中心項目として glide.email.smtp.active が示されています。

確認箇所
System Mailboxes > Email Properties

実際に見るべきフィールド名や状態例
glide.email.smtp.active = false

よくある誤解
通知側だけをずっと見続けてしまうことです。
まず送信基盤を確認するのが先です。

環境方針で意図的に無効化されている

開発環境や検証環境では、誤送信防止のためにOutbound Emailを止めていることがあります。
設定ミスではなく、運用ルールの結果かもしれません。

確認箇所
環境運用ルール
インスタンスの用途
管理者間の取り決め

実際に見るべきフィールド名や状態例
glide.email.smtp.active = false
ただし変更禁止対象の可能性あり

よくある誤解
自分が直せばよい設定だと思い込むことです。
本番以外では意図的に止めていることがあります。

メール自体が生成されていない

通知条件が成立していない

Outbound Emailの有効・無効とは別に、通知条件が成立していなければ sys_email にレコード自体が作られません。
このケースは「送信されない」と感じますが、実際には「生成されていない」です。

確認箇所
Notificationレコード
条件式
イベント購読設定
対象テーブル

実際に見るべきフィールド名や状態例
Active = true か
対象 Table が正しいか
イベント名が一致しているか
条件式が現在のレコード値と一致しているか

よくある誤解
通知がActiveなら必ず生成される、という理解です。
実際は条件不一致なら何も起きません。

イベントは発火しているつもりで発火していない

イベントベース通知では、通知側だけでなく、イベント登録や発火処理も見ないといけません。
イベント名のスペル差異、対象レコードの違い、発火タイミングの誤りで止まることがあります。

確認箇所
Event Registry
Business Rule
Script Action
Flow Designerからの呼び出し

実際に見るべきフィールド名や状態例
イベント名
引数
現在のレコードが通知対象テーブルと整合しているか

よくある誤解
イベント名が似ていれば同じ扱いになる、という思い込みです。
スペル違いはそのまま不一致になります。

Flow Designerやスクリプトの処理分岐で送信まで到達していない

最近は通知設計がFlow Designer経由になっていることも多いため、通知だけ見ても不十分です。
手前の条件分岐やエラーハンドリングで送信アクションまで到達していない場合があります。Flow Designerにはエラーハンドリング関連の学習資源も整理されています。

確認箇所
Flow Designerの実行履歴
条件分岐
サブフロー
スクリプトアクション

実際に見るべきフィールド名や状態例
対象フローの実行結果
失敗ステップ
条件成立可否

よくある誤解
通知がないからEmail Propertiesの問題だと決めつけることです。
実際はフロー未到達のことがあります。

受信者が取れていない

通知の受信者設定が空になっている

ServiceNowの通知は「いつ送るか」と同じくらい「誰に送るか」が重要です。
受信者の指定が不足していると、メールが生成されても送信対象不備になります。

確認箇所
Notificationの受信者設定
ユーザー参照先フィールド
スクリプトでの受信者追加処理

実際に見るべきフィールド名や状態例
Who will receive
Users/Groups/Users in fields
Email addresses
イベントパラメータ利用の有無

よくある誤解
対象レコードに assigned_to があれば自動で飛ぶ、という理解です。
通知でそのフィールドを受信者として指定していなければ飛びません。

ユーザーにメールアドレスが入っていない

通知対象ユーザーを取れていても、ユーザーレコードのメールアドレスが空なら送れません。
この場合、send-ignored になったり、期待した送信にならないことがあります。ServiceNowドキュメントでも、受信者不備は送信スキップの代表例です。

確認箇所
sys_user レコード

実際に見るべきフィールド名や状態例
email が空でないか
active が適切か

よくある誤解
ユーザー参照が埋まっていれば十分、という考え方です。
実際に必要なのは送信可能なメールアドレスです。

重複や不正形式で送信が無視されている

受信者の形式や重複によっては、送信が期待通りに進まないことがあります。
また、一部リリースでは非ASCIIを含む個人名で send-ignored になる修正事項も出ています。

確認箇所
sys_email の recipients
error_string

実際に見るべきフィールド名や状態例
不正なメール形式
異常な区切り文字
同一アドレス重複

よくある誤解
メールアドレスが表示されていれば正常、という理解です。
形式不正や内部処理上の問題は別途確認が必要です。

sys_emailにはあるが送信状態が進まない

send-readyのまま滞留している

send-ready は「送る準備はできたが、まだ送信していない」状態です。通常は短時間で次の状態に進むため、長く残るなら送信処理の停滞を疑います。ServiceNow公式でも send-ready は短時間だけ滞留するのが一般的と説明されています。

確認箇所
sys_email.list
送信キューの推移
メール関連ジョブや処理状況

実際に見るべきフィールド名や状態例
type = send-ready のまま大量に残る
作成日時が古い

よくある誤解
レコードがあるからそのうち送られる、と放置することです。
長く残るなら異常を疑ったほうがよいです。

send-failedになっている

送信処理まで進んで失敗した状態です。
この場合は error_string が重要で、SMTP側や接続側の問題が見えてくることがあります。

確認箇所
sys_email 詳細
メールログ
SMTP設定

実際に見るべきフィールド名や状態例
type = send-failed
error_string に接続失敗や認証失敗に近い文言

よくある誤解
通知条件が悪いと思って通知側を修正し続けることです。
send-failed まで来ているなら、通知生成は済んでいます。

attachment制限や本文制限に引っかかっている

大量添付や大きすぎる本文で、期待通りの送信にならないこともあります。
ServiceNowには添付制限やアウトバウンド本文サイズのプロパティがあり、超過時にログ上の手掛かりになります。

確認箇所
添付数
添付合計サイズ
本文サイズ
メールログ

実際に見るべきフィールド名や状態例
関連ログの警告
添付が一部無視される挙動

よくある誤解
メール本文や添付は大きくても送れるはず、という思い込みです。

送信はされているが期待通り届かない

sentなのにユーザーが受け取っていない

sys_email が sent なら、ServiceNow側では送信済みとして扱われています。
この場合は、ServiceNow内の問題というより受信側のフィルタ、迷惑メール判定、社内メールゲートウェイの制限などを疑う段階です。

確認箇所
sys_email の最終状態
受信側メールシステム
迷惑メールフォルダ
社内フィルタ

実際に見るべきフィールド名や状態例
type = sent

よくある誤解
ServiceNowで sent なら受信トレイ到達まで保証される、という理解です。
実際には送信後の経路は別管理です。

組織ルールで特定ドメインだけ制御されている

実務では、開発環境で外部ドメイン送信を止めたり、社内ドメインだけ許可したりすることがあります。
その場合、ServiceNowの標準設定だけ見ても原因が見えにくいです。コミュニティでもドメイン制御の実装例が議論されています。

確認箇所
カスタムBusiness Rule
送信制御スクリプト
環境ルール

実際に見るべきフィールド名や状態例
sys_email 生成はされる
ただし後段処理で除外

よくある誤解
標準Notificationだけ見れば全体が分かる、という考え方です。
実運用ではカスタマイズが介在していることがあります。

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

緊急時は、次の順で進めると効率的です。

最初に送信基盤を確認する

まずEmail Propertiesで glide.email.smtp.active を確認します。
ここがfalseなら、通知やイベントの確認より先に送信無効の理由を確認します。変更してよい環境かどうかもあわせて確認します。

次にsys_emailの有無で分岐する

sys_email に対象メールがあるかで大きく切り分けます。

ない場合
通知、イベント、Flow、スクリプト側を確認する

ある場合
type と error_string を確認する

これだけで調査範囲がかなり狭まります。

sys_emailの状態で原因を絞る

send-ready
送信待ちの滞留を疑う

send-ignored
受信者不備、重複、送信スキップ条件を疑う

send-failed
SMTPや送信処理失敗を疑う

sent
受信側や社内メール基盤を疑う

この読み方はServiceNowのシステムメールログの状態定義と一致します。

受信者と条件を最後に詰める

通知が生成されているなら、最後は受信者設定とデータ実体です。
対象ユーザーの email、通知の Who will receive、参照先フィールド、イベントパラメータを1つずつ確認します。

ここで「通知の設計」と「マスタデータの品質」の両方を見るのが実務的です。

設計観点からの再発防止

その場しのぎで直すだけだと、同じ問題がまた起きます。
ここでは再発防止のための設計原則を整理します。

通知設計と送信基盤の責任範囲を分ける

通知が悪いのか、送信基盤が悪いのかを混ぜないことが大切です。
運用設計として、次の責任分界を明確にしておくと再発しにくくなります。

通知担当
条件、イベント、受信者、本文

基盤担当
Email Properties、SMTP、環境制御、外部送信方針

この分け方をしておくと、障害時の初動が速くなります。

検証観点を標準化する

毎回ゼロから調べるのではなく、確認順を固定化すると強いです。

確認順の例
Email Properties
sys_email
状態値
error_string
通知条件
受信者
ユーザーメールアドレス
環境制約

この順番をチーム内で共通化すると、調査品質が安定します。

通知ごとに受信者取得方法を明文化する

「誰に送るのか」をレコード参照で取るのか、グループなのか、イベントパラメータなのかを曖昧にしないことが重要です。
設計書や運用メモに受信者取得元を書いておくと、send-ignored の原因調査が速くなります。

sys_emailを見れば分かる状態を増やす

カスタム送信制御や除外ロジックがある場合、なぜ止めたのかが残るようにしておくと有効です。
単に送らないのではなく、ログやエラー文字列に調査可能な痕跡を残す設計のほうが、保守しやすいです。

ATFなどで通知検証を仕組み化する

ServiceNowにはATFのEmailカテゴリがあり、通知やアウトバウンドメールの検証に使えます。通知の正常系だけでなく、意図的に送られない条件もテスト観点に含めると、変更時の事故を減らせます。

まとめ

ServiceNowでOutbound Emailが無効なときは、通知設定だけを見ても解決しないことが多いです。
まず見るべきなのは、Email Propertiesで送信自体が有効かどうか です。特に glide.email.smtp.active は最優先の確認項目です。

そのうえで、sys_email にレコードがあるか、状態が send-ready、send-ignored、send-failed、sent のどれかを確認すれば、調査範囲をかなり絞れます。

実務では、原因を次の5層で考えると整理しやすくなります。

送信基盤
メール生成
送信対象
SMTP処理
設計運用

この構造で見ると、「今起きている不具合の修正」だけでなく、「なぜその問題が起きたのか」まで見えるようになります。
CSA学習の観点でも、通知は単独機能ではなく、プロパティ、イベント、レコード生成、ログ確認まで含めて理解すると、ServiceNowの全体像がかなり深まります。

次に読むべき関連記事

通知が出ないが、そもそも sys_email が作られていないケースを整理したい場合は、通知生成側の切り分け記事を読むと理解がつながります。
イベントを使った通知でつまずきやすい場合は、Eventが発火しない原因整理の記事も相性がよいです。
また、通知条件や通知レコードの設定ズレが起点になることも多いため、Notification設計の基礎をまとめた記事もあわせて読むと全体が整理しやすくなります。

体系的に学ぶ方法の一例としては、UdemyなどのServiceNow講座で、通知・イベント・Flow Designer・管理系設定をまとめて追うやり方があります。独学だと個別事象の対処で終わりがちですが、講座形式だと「どの設定がどの層に属するのか」をつなげて理解しやすくなります。
実務での切り分けを速くしたい人や、CSA学習と並行して基礎を整理したい人には、そうした体系学習も選択肢のひとつです。