メールの送信状況を確認して再送・取消を行う

管理者がメールの送信状態と最終エラーを確認し、失敗したメールを再送待ちへ戻したり、不要なメールを取り消したりできます。

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

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

管理者がメールの送信状態と最終エラーを確認し、失敗したメールを再送待ちへ戻したり、不要なメールを取り消したりできます。

システム管理者が「システム > システム運用 > メール送信 > メール送信管理」を開きます。メールの送信要求だけを対象とする検索ビューで、対象モデル・対象データID・状態・日時などから調べるメールを絞ります。Outbox IDは、送信要求と監査ログを対応付ける識別子です。

状態	意味と運用上の扱い
PENDING	送信待ち。不要な要求は送信取消できます。
PROCESSING	送信処理中。処理中の取消はできません。
RETRY_WAIT	自動再試行を待っている状態。送信取消できます。
FAILED	失敗。原因を確認して手動再送するか、不要なら送信取消します。
SUCCESS	送信処理が完了。送信取消はできません。
CANCELLED	取消済み。自動送信と手動再送の対象になりません。

詳細画面では、再試行回数、処理日時、次回試行日時、最終エラーなどを確認できます。業務データの元レコードを削除しても、登録済みのメール送信要求は自動では取り消されません。不要な要求はメール送信管理で対象を特定して取り消します。

「再送」はFAILEDのときだけ表示されます。原因の設定や連携先の状態を確認してから操作します。再送はその場でSMTP送信を完了する操作ではなく、状態をPENDING、再試行回数を0へ戻し、通常の配送処理に再び渡す操作です。処理日時・次回試行日時・最終エラーなどもリセットします。

添付の実体がすでに解放されているなど、必要なファイルが使えない場合は再送できません。再送後は現在の状態と配送監査ログを確認します。画面のボタンの表示だけでなく、APIでも管理権限と対象の状態を検査します。

PENDING・RETRY_WAIT・FAILEDのメールには「送信取消」が表示されます。対象を確認して続行するとCANCELLEDになります。PROCESSINGとSUCCESSは取り消せず、送信処理と競合した場合もAPI側で拒否します。送信済みメールを受信者から回収する機能ではありません。

取消日時を記録し、配送監査ログにはMANUAL_CANCELとして操作者と状態遷移を残します。画面からの取消理由は「管理画面から送信取消」として操作ログへ記録します。取消済みの添付実体は定期クリーンアップで解放します。

開発中の不要な送信待ちメールを片付けるために、DB全体を作り直す必要はありません。SMTPを有効にする前に対象を確認して取り消します。操作後は画面を再表示し、対象のOutbox IDと状態を確認してください。

標準リポジトリには送信管理モデルと再送・取消の操作が用意されています。利用のために独自の送信状態項目を追加する必要はありません。次は既存のメール送信管理メニューの遷移先を示す抜粋です。

target:
  kind: entity
  entity: jmail_outbox
  screen: search
  definition_id: mail-delivery

jmail_outboxは共通基盤のOutboxを参照する読み取り専用のシステムモデルです。状態変更は標準の再送・取消操作へ任せ、モデルの登録・更新・削除機能を追加しません。標準メニューがある場合は同じIDの入口を重複定義しません。