メール受信から Webhook 到着までの遅延を測る

メール到着と Webhook 到着の定義

Webhook は、イベントの発生を HTTP リクエストで通知する仕組みです。Mailera は、既存のメールボックスを接続し、新着メールなどのイベントをアプリへ通知できます。

主指標は「Webhook のリクエスト本文を受信し終えた時刻 − プロバイダー側のメール到着時刻」とします。受信時刻は本文を読み終えた時点で記録し、署名検証に成功した通知を集計に採用します。検証や後続処理の完了時刻は別に残してください。

送信開始から測ると、プロバイダーに届くまでの配送時間も入ります。これは別指標です。Mailera の検知時刻や送出時刻を観測できない場合、その区間を推定値で分割せず、メール到着から Webhook 受信までの合計として扱います。

起点の意味もそろえます。Gmail API の internalDate の定義では、通常の SMTP 受信メールは Google が最初に受け付けた時刻をエポックミリ秒で表します。一方、API で移行したメールでは、クライアントが Date ヘッダー由来の値に設定できます。両者を同じ母集団に入れないでください（資料参照日：2026-10-25）。

Date ヘッダー、IMAP の INTERNALDATE、API の received_at を、名前だけで同じ到着時刻と判断しないようにします。各値の取得元と意味を記録し、起点がそろわなければ別集計にします。X-MailHub-Timestamp もメール到着時刻の代わりには使いません。

正確な到着時刻を取れない試行は、「最初に存在を確認した時刻」などの代理指標として分けます。時計同期の方法、時刻の分解能、確認間隔も残してください。ミリ秒表記で保存しても、測定精度までミリ秒になるわけではありません。

Gmail・Outlook・IMAP の比較条件

Mailera の Microsoft 接続は Microsoft Graph の変更通知で新着を受け取り、定期的なバックグラウンド確認で補完します。Gmail 接続はアプリパスワード（app password）認証の IMAP です。Gmail API の日時を独立した観測に使っても、Mailera の接続方式は変わりません。

カスタム IMAP 接続も含め、接続方式と監視方式は分けて記録します。RFC 2177では、サーバーが IDLE capability を通知しない場合、クライアントは IDLE ではなく定期確認を使う必要があります。IMAP 接続というだけで IDLE 利用と分類しないでください（資料参照日：2026-10-25）。方式の違いはIMAP・Graph・SMTP の役割でも整理しています。

Mailera は使用中のメールボックスをより頻繁に確認し、アイドル時は確認頻度を下げます。非アクティブなメールボックスは休止し、利用時に復帰する場合があります。状態別の集計を基本にし、初回同期や手動同期も通常受信から分けます。

同じ送信元と内容条件を使い、送信順序を入れ替え、複数の時間帯とメールボックスで反復してください。送信量と間隔は各サービスの規約に従います。

接続準備は既存メールボックスを外部システムにつなぐ手順を参照できます。準備時の操作と測定中の操作は分けて記録しましょう。

同じ測定を再現する手順

1. 試験環境を用意します。 自分が管理する試験用メールボックスと HTTPS 受信サーバーを使います。時計同期を確認し、メール到着を起点とする観測期限を事前に決めます。
2. Webhook を登録します。 試験用グループに範囲を限定した webhooks 権限の API キーを用意し、POST /webhooks で登録します。リクエストの設定項目は API ドキュメントに従ってください。署名シークレットは作成時に一度だけ返るため、安全な場所に保存します。
3. 署名検証と記録を実装します。 本文の受信完了時刻を保存し、文書化された方式で署名を検証します。検証失敗は有効通知に数えず、失敗件数を別に残します。X-MailHub-Event、X-MailHub-Delivery、X-MailHub-Timestamp も照合用に保存します。
4. メールと通知を対応付けます。 件名などに試行ごとの一意な識別子を付け、試験台帳に残します。通知とメールを対応付ける処理を先に確認し、対応できない通知を遅延の集計に入れないようにします。
5. 記録後に速やかに応答します。 受信記録を永続化し、重い後続処理は分離します。HTTP 応答結果と処理完了時刻を別に残すと、通知到着とアプリ処理の遅さを区別できます。
6. 観測期限まで追跡します。 最初の有効通知、以後の通知、期限超過後の到着を記録します。匿名化したログ、集計コード、環境情報を同じ測定単位で保存します。

イベント一覧には message.received と message.junk があります。購読対象と対象フォルダーを事前に決め、受信トレイと迷惑メールを別集計にします。API と Webhook の接続全体は開発者向け案内から確認できます。

休止状態の測定では、到着確認のために行う操作も記録してください。特に POST /mailboxes/{id}/sync は同期を実行すると同時に休止中のメールボックスを起こします。バックグラウンド受信を測る試行には混ぜません。

平均値ではなく、何を集計する？

まず、プロバイダー、接続方式、稼働状態、到着時刻の取得元でグループを分けます。各試行の最初の有効通知だけを遅延分布に採用し、後から届く重複通知を別メールとして数えないようにします。

分位点の計算方法も固定します。例えば nearest-rank 法なら、有効な遅延を昇順に並べ、件数を n、分位を q として、切り上げた n × q 番目の値を使います。p95 には q = 0.95 を指定します。標本が少ない場合、p99 は最大値付近の少数の試行に左右されるため、件数を必ず併記してください。

平均値だけでは、一部の長い待ち時間がどの程度起きたかを読み取りにくくなります。ただし、p99 だけを見れば十分でもありません。期限内に届かなかった通知を除いた分布だからです。

全試行に対する期限内未達率に加え、メール到着確認済みの試行に対する通知未達率を出します。プロバイダー到着自体を確認できない試行も別に残すと、メール配送と受信後の通知を混同せずに済みます。表には測定期間、単位、期限、ログと集計コードの参照を添えてください。

遅い通知や未達の切り分け

期限までに有効通知が来なければ「期限内未達」です。永久に届かないという意味ではありません。後から届いた場合は期限超過として記録し、期限時点の未達件数も残します。

調査は、プロバイダーへの到着、Mailera の接続状態、Webhook の購読設定、受信サーバーのアクセス記録の順に進めます。mailbox.disconnected、署名検証失敗、受信側エラー、迷惑メールへの振り分けも確認してください。内部時刻を観測できない区間は、原因を断定しません。

Microsoft Graph と Mailera の配送仕様も混同しないようにします。Graph の Webhook 配信仕様では、受信先が 3 秒以内に 2xx を返すと配信済みとみなし、配信失敗時は指数バックオフで再試行します。これは Graph から通知受信先への仕様であり、Mailera から利用者のサーバーへの再送条件として使うものではありません（資料参照日：2026-10-25）。

待機時間と監視基準にどう使う？

アプリの待機時間は、対象の稼働状態における分位点と期限内未達率から決めます。通常稼働の p95 だけを、休止からの復帰にも適用しないでください。観測した最大値も将来の上限にはしません。

監視では「メール到着済みだが有効通知なし」「通知は届いたが署名検証に失敗」「通知後の処理が未完了」を分けます。待機期限を超えたときの表示や運用上の確認手順まで決めておくと、遅延のたびに障害と判断せずに済みます。

Mailera はプロバイダーの迷惑メールフィルターを回避できず、受信トレイへの到着も保証しません。この測定は、プロバイダーから Mailera、ネットワーク、受信サーバーまでを含む経路の観測であり、プロバイダー単体の性能順位ではありません。

公開するログと画像からは API キー、署名シークレット、メールアドレス、本文を除きます。試験用メールだけを使い、照合に必要な識別子と時刻を残してください。