メール配送の状況をメトリクスで確認する

メールの滞留件数、期間内の配送結果、SMTPの応答時間を確認し、現在の待ち行列と過去の履歴を分けて把握できます。

最終更新日：2026年10月31日

1. このページで伝える機能

メールの滞留件数、期間内の配送結果、SMTPの応答時間を確認し、現在の待ち行列と過去の履歴を分けて把握できます。

システム管理者が「システム > システム運用 > メール送信 > 配送メトリクス」を開きます。集計期間を選び「更新」で取得し直します。画面では直近1時間・6時間・24時間・3日・7日・31日から選べ、初期値は24時間です。更新日時と集計開始日時も確認します。

最初に未処理・再処理待ちの件数と最古の未完了メールを見て、滞留の有無を確認します。未完了はPENDING・PROCESSING・RETRY_WAITが対象です。FAILEDは、失敗原因を調べて手動対応する状態として区別します。

表示	意味
現在のキュー	現在の状態別件数と最古の未完了要求。集計期間内に発生したものだけの件数ではありません。
期間内の配送結果	指定期間の監査ログにある受付、成功、最終失敗、再試行予定、手動再送、添付解放などの記録を集計します。
SMTP実測	現在のREST APIプロセスの送信試行数、成功・失敗数、平均・最大応答時間です。

成功率は、指定期間に終端結果となった送信成功と、恒久失敗・再試行上限到達・失敗扱いのタイムアウトをもとに計算します。再試行予定は終端結果に含めません。

現在のFAILED件数と、期間内の最終失敗件数は一致するとは限りません。再送や取消で現在の状態が変わっても、過去の失敗記録は残るためです。この例でも、手動再送後の要求がPENDINGに戻った一方、期間内の失敗履歴は残っています。

現在のキューはOutbox、期間集計は配送監査ログのDB情報から取得します。REST APIを再起動しても記録は維持されます。一方、SMTPの実測は現在のREST APIプロセスのタイマーで計測し、再起動すると試行回数・成功失敗回数・応答時間がリセットされます。

SMTP実測が0でも、過去の受付・失敗履歴がないとは限りません。SMTP接続前に失敗する場合もあるため、配送結果の件数と通信の実測は別に読み取ります。SMTP実測の欄は集計期間全体の履歴を表すものではありません。

失敗や滞留が見つかったら配送監査ログで個別の経緯を調べ、メール送信管理で対応します。APIで集計する場合はwindowHoursを1〜744の範囲で指定し、省略時は24時間です。

配送メトリクスはEntityの一覧画面ではなく、標準のシステム機能です。集計用の業務モデルを追加せず、既存メニューから利用できます。入口を調整する場合の遷移先の抜粋です。

target:
  kind: system
  feature: mail-delivery.metrics

集計期間は画面またはAPIの指定で変更します。メニューの表示制限だけでなく、APIでも管理者権限を検査します。