ServiceNowでsys_emailがreadyのまま進まない原因とは？確認箇所と最短切り分けを整理

ServiceNowで通知やメール送信の検証をしていると、sys_emailのレコードがreadyのまま動かないことがあります。通知自体は作られているのに送信されず、ユーザーにも届かない。この状態は、単に「通知設定ミス」と片づけると遠回りになりやすいです。

なぜなら、sys_emailがreadyのままという現象は、通知定義の問題だけでなく、送信ジョブ、メール送信設定、SMTP接続、重複抑止との切り分け、運用上の止め方まで複数の層にまたがって発生するからです。ServiceNow公式ドキュメントでも、Email [sys_email] は送受信メールの記録先であり、send - ready は「送信準備ができているが、まだメールサーバーから送られていない状態」と説明されています。通常は短時間しかこの状態に留まりません。

この記事では、sys_email の Type = send - ready が残り続けるときに、どこから見ればよいのかを実務向けに整理します。単発の障害対応だけでなく、CSA学習者が「通知が作られてから送られるまで」の流れを理解できるよう、構造から順に解説します。

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

まずは深掘りする前に、以下を上から順に確認してください。sys_email ready の切り分けは、最初の5分でかなり進みます。

sys_emailで本当に送信待ちになっているか確認する

System Logs > Emails で対象レコードを開き、最低でも次の項目を確認します。

• Table: sys_email
• Type: send - ready
• State: Ready
• Notification type: SMTP
• Recipients
• Subject
• Target
• Created
• **Error string`

ServiceNow公式では、sys_email は送受信メールのログであり、Type と State の組み合わせでどのメールボックスに見えるかが決まります。また send - ready は「送信準備完了だが未送信」、send - failed は送信失敗、send - ignored は送信スキップです。

ここで重要なのは、readyのままなら“通知生成までは成功している”可能性が高いことです。つまり、通知レコードが全く作られていない問題とは切り分けが変わります。

Email sending enabledが有効か確認する

System Properties > Email を開き、Email sending enabled を確認します。公式ドキュメントでは glide.email.smtp.active が外向きメール送信の有効・無効を制御すると明記されています。falseなら、送信側は進みません。

確認項目は次のとおりです。

• glide.email.smtp.active
• glide.email.test.user
• 必要に応じて送信先テストアドレスの設定有無

検証環境では「本番誤送信を避けるために送信を止めていた」ことを忘れているケースがよくあります。特に、通知は生成されるのに送られないときは最初に見るべきです。

Email Diagnosticsで送信系の全体状態を見る

System Mailboxes > Email Diagnostics または System Diagnostics > Email Diagnostics で、送信基盤が生きているかを見ます。公式ではこの画面で以下を確認できるとされています。

• Email Sending is [Status]
• Email in Queue
• Last Sent Mail
• SMTP Sender State
• SMTP Processing Time
• SMTP Job Last Run
• Default SMTP Status

sys_email を1件ずつ眺めるより、まずここでシステム全体が送れる状態かを見るほうが速いです。

SMTP Senderジョブが動いているか確認する

ServiceNow公式では、SMTP Sender scheduled job が送信頻度を決め、デフォルトでは通常1分ごとに動くと説明されています。

確認箇所は次です。

• System Scheduler > Scheduled Jobs
• System Scheduler > Today's Scheduled Jobs
• ジョブ名: SMTP Sender

ここでジョブが止まっている、実行間隔より処理時間が長い、最終実行時刻が古い、といった状態なら、send - ready が滞留しやすくなります。

Default SMTP Statusや接続状態を確認する

Email Diagnostics上で Default SMTP Status が正常か確認します。公式でも、Email Diagnosticsではアカウント接続状態を確認できるとされています。

よくある誤解は、「readyだからSMTPまでは関係ないだろう」という見方です。実際には、送信待ちキューから外へ出す段階でSMTP側の問題が影響するため、ここは必須確認です。

導入

sys_email が ready のまま残ると、現場では「通知条件が違うのでは」「イベントが飛んでいないのでは」と考えがちです。しかし、sys_email にレコードが作成されている時点で、少なくとも通知生成の入口は通っているケースが多いです。

そのため、真っ先に考えるべきは次の問いです。

• 通知は作られたのか
• 送信ジョブは動いているのか
• 送信設定は有効なのか
• SMTP接続は正常か
• そもそも設計上、今は送らない状態にしていないか

この順番を外すと、通知定義やスクリプトばかり触って時間を失います。sys_email ready は、通知ロジックの障害というより、送信パイプライン途中の滞留として捉えると整理しやすくなります。

原因の全体構造整理

sys_email ready を構造で見ると、原因は大きく次の層に分けられます。

通知生成までは成功している層

この層では、通知・イベント・Flowなどが動いた結果、sys_email に送信レコードが作成されています。つまり、完全な未生成障害ではありません。

見るべき項目は次です。

• sys_email.Target
• sys_email.Subject
• sys_email.Recipients
• sys_email.Notification type
• 生成元の通知レコードやイベント

ここで値が入っているなら、少なくとも「メールレコードが作られるところ」までは進んでいます。

送信実行ジョブが止まっている層

この層では、送信待ちメールはあるが、SMTP Sender が処理できていません。公式でもSMTP Senderが外向きメールの送信ジョブであり、デフォルトで1分ごとに実行されるとされています。

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

この層では、glide.email.smtp.active = false などにより、送信系そのものが無効です。非本番で意図的に止めていることもあります。公式のOutbound email configurationでも、このプロパティが送信有効化を制御すると説明されています。

SMTP接続や外部送信基盤の層

この層では、ServiceNow側の内部生成は問題ないが、SMTP接続状態や外部メール基盤側に問題があります。Email Diagnosticsの接続状態確認が有効です。

重複抑止や送信抑制設計の層

公式ドキュメントでは、同一トリガーから複数通知が発生したとき、重複通知は1通だけ送られ、他はスキップされる仕組みがあると説明されています。重複判定にはターゲットテーブル・受信者・重みなどが関わります。

これは厳密には send - ignored の文脈で出やすいですが、実運用では「readyが詰まっていると思ったら、別メールが優先されていた」「設計上、送信数が想定より少ない」などの誤認につながります。

検証環境や運用手順の層

検証時に

• 送信を止める
• テストアドレスへ集約する
• キューを残したまま設定だけ戻す

という運用をすると、sys_email の ready が大量に残ることがあります。これは障害ではなく、運用の結果として滞留している状態です。

原因層ごとの詳細解説

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

確認箇所

System Properties > Email

確認するフィールド・プロパティは以下です。

• Email sending enabled
• glide.email.smtp.active
• Send all email to this test email address
• glide.email.test.user

公式では glide.email.smtp.active が送信有効化、glide.email.test.user が非本番で全メールの送信先集約に使われるプロパティです。

状態例

• glide.email.smtp.active = false
• テストアドレスが古いまま残っている
• 本番想定なのに非本番運用の設定が残っている

よくある誤解

よくあるのは、**「通知がreadyだから通知設定は正しい。なら送信されるはず」**という考え方です。実際には、通知が作られても送信スイッチがOFFなら進みません。

SMTP Senderジョブが止まっている

確認箇所

• System Scheduler > Today's Scheduled Jobs
• System Scheduler > Scheduled Jobs
• Email Diagnostics の SMTP Sender State
• Email Diagnostics の SMTP Job Last Run
• Email Diagnostics の SMTP Processing Time

公式では、SMTP Senderは外向きメール送信を担うジョブで、通常1分ごとに動きます。

状態例

• SMTP Senderが not operational
• 最終実行時刻が古い
• 処理時間がジョブ間隔を上回っている
• Email in Queue が増え続ける

よくある誤解

ジョブ停止を見落として、通知条件やイベントに時間をかけるケースです。sys_email に ready が増えているなら、送信実行者がいないだけということが実務ではかなりあります。

SMTP接続やメール基盤側に問題がある

確認箇所

• Email Diagnostics の Default SMTP Status
• 接続テスト結果
• 対象メールレコードの Error string
• 個別メールのメッセージログ

公式のトラブルシューティング資料でも、Diagnostics and Connection で接続状況や送受信に影響する状態を確認でき、個別メールでは Error string や関連ログが手掛かりになるとされています。

状態例

• SMTP接続が非正常
• 一部だけ送れない
• 接続は一見正常でも遅延が大きい
• ready から failed へ進むものと、readyに残るものが混在する

よくある誤解

ServiceNow内だけ見て完結させようとすることです。sys_email はあくまで送信処理の記録なので、外部メール基盤との境界を意識しないと詰まります。

通知は作られているが受信者や内容設計に問題がある

確認箇所

• sys_email.Recipients
• 通知レコードの Who will receive
• ユーザーのメールアドレス
• 受信者に使っている参照フィールド
• グループの Include members

公式では、通知受信者は Users、Users/groups in fields、Groups などから決まり、inactiveなユーザーには送られないこと、グループ送信は Include members の設定が関係することが説明されています。

状態例

• Recipients が空に近い
• 宛先フィールドの参照が期待と違う
• inactiveユーザーが含まれる
• グループは指定したがメンバー送信条件が満たされていない

よくある誤解

「readyなら宛先は問題ない」と思い込むことです。実際には、後段で send - ignored に流れることもありますし、通知設計の時点で受信者定義が不安定だと、再現性の低い不具合になります。

重複通知や送信抑止設計が影響している

確認箇所

• 通知レコードの Weight
• 同一タイミングで発火する複数通知
• 同一ターゲット・同一受信者への競合
• 直前に同じレコードで送られたメールの有無

公式では、同じトリガーから複数通知が生成された場合、最も優先されるものだけ送信し、他は送られないという重複制御があります。

状態例

• 更新系通知が複数同時に走る
• 重み付けが曖昧
• 送るべき通知と補助通知が競合する

よくある誤解

「通知が複数あるほど安心」と考えることです。実務ではむしろ逆で、通知の責務が重なるほど挙動確認が難しくなります。

運用上わざと止めたメールが残っている

確認箇所

• いつ送信無効にしたか
• ready が増え始めた時刻
• 検証作業の履歴
• 一括再送や削除の運用ルール

状態例

• 検証中に送信停止
• 後から送信有効にしたがキュー整理をしていない
• 過去のreadyが大量に残っている

よくある誤解

これは障害ではなく、環境運用の癖で起きることがあります。とくに非本番では「送らない前提」でreadyを積み上げてしまい、本番同様の挙動確認ができなくなることがあります。

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

sys_email ready に遭遇したら、現場では次の順で見ると効率が良いです。

sys_emailの実レコードを1件開く

まず対象の sys_email レコードを開きます。

見る項目は以下です。

• Type
• State
• Recipients
• Target
• Created
• Error string

ここで send - ready / Ready なら、通知未生成ではなく送信待ち滞留として扱います。

Email Diagnosticsで全体状態を確認する

次に Email Diagnostics で、

• Email Sending
• Email in Queue
• SMTP Sender State
• SMTP Job Last Run
• Default SMTP Status

を見ます。公式でも、この画面は送受信に影響する設定・ジョブ・接続状況の把握に使うものです。

ここで異常が出ていれば、個別通知より基盤側を優先します。

Email Propertiesで送信設定を確認する

glide.email.smtp.active を確認します。falseなら、まずそこを直さない限り先へ進みません。

また、glide.email.test.user により想定外のテストアドレスへ送っていないかも見ます。

SMTP Senderの実行状況を確認する

ジョブが定期実行されているか、最終実行が止まっていないかを確認します。公式上、SMTP Senderは通常1分ごとの送信ジョブです。

それでも基盤が正常なら通知設計へ戻る

ここまで問題がなければ、通知側を確認します。

• 受信者定義
• inactiveユーザー混入
• グループ送信条件
• 重複通知設計
• イベント競合

この順番なら、通知設計の見直しは最後で済みます。

設計観点からの再発防止

sys_email ready を減らすには、その場しのぎの運用ではなく、通知設計と運用設計の両方を整える必要があります。

通知の責務を分けすぎない

同じレコード更新に対して、似た通知を複数作ると、重複抑止や優先順位が見えにくくなります。公式でも通知の重みと重複制御の関係が説明されています。

実務では、1つの状態変化に対して「誰へ・何を・どの条件で送るか」を明確に分け、通知の責務重複を減らすことが重要です。

宛先定義を安定したフィールドに寄せる

受信者を複雑なスクリプトや不安定な参照に頼ると、再現しにくい不具合になります。

見るべき設計ポイントは次です。

• sys_user.email が安定しているか
• inactiveユーザー除外が前提になっているか
• グループ送信時の運用ルールがあるか
• Users/groups in fields の参照先が明確か

非本番のメール運用ルールを決める

検証環境では、送信停止のままreadyを積み上げないことが大切です。止めるなら止める、テスト宛先へ集約するなら集約する、古いキューは整理する、というルールを明文化しておくと混乱が減ります。

公式のOutbound email configurationでも、非本番向けに全メールを特定アドレスへ集約する設定が用意されています。単に送信OFFにするだけでなく、検証目的に応じた使い分けが有効です。

障害時の標準切り分け手順を決める

運用チーム内で次の順番を固定すると、対応品質が上がります。

• sys_email を見る
• Email Diagnostics を見る
• Email Properties を見る
• SMTP Sender を見る
• 個別通知を確認する

この順序が定着すると、担当者ごとの属人差が減ります。

まとめ

ServiceNowで sys_email が ready のまま残るときは、まず「通知が作られていない」のではなく、作られたメールが送信パイプラインのどこかで止まっていると考えるのが近道です。

見る順番はシンプルです。

• sys_email で Type / State / Recipients / Error string を確認する
• Email Diagnostics で Email Sending / Email in Queue / SMTP Sender State / Default SMTP Status を確認する
• Email Properties で glide.email.smtp.active と glide.email.test.user を確認する
• SMTP Senderジョブの稼働状況を見る
• 最後に通知定義や受信者設計へ戻る

この流れで見れば、場当たり的な修正を減らせます。CSA学習の観点でも、通知は「定義」だけでなく、生成、キュー、ジョブ、接続、配送という一連の流れで理解すると、仕組みの解像度が上がります。

次に読むと理解が深まる関連記事

通知トラブルを横断的に理解したい場合は、次のテーマを続けて読むとつながりやすいです。

通知が送信されないときの全体像を整理したい場合

• ServiceNow 通知が飛ばない原因まとめ
• ServiceNow メール通知の条件が効かないときの確認ポイント
• ServiceNow eventが発火しているのに通知されない原因

仕組み理解を深めたい場合

• ServiceNow 通知の基本設計
• ServiceNow eventとnotificationの関係
• ServiceNow sys_emailの見方

学習やキャリアの文脈で広げたい場合

• CSA学習で押さえたい通知まわりの基礎
• ServiceNow管理者が理解しておきたいメール運用
• ServiceNow運用保守でよくある障害切り分け

体系的に学ぶ方法の一例

ServiceNowの通知やメールは、個別の不具合だけ追っていると「その場では直せるけれど、全体像がつかみにくい」と感じやすい分野です。もし独学で整理したいなら、Udemyなどの講座で通知、イベント、メール、ユーザー、ロール、運用設計をまとめて学ぶ方法もあります。

特にCSA学習者は、画面操作だけでなく「なぜその設定で送られるのか」「どこで止まるのか」を体系で押さえると、今回のような sys_email ready の切り分けもかなり速くなります。