---
title: "メール受信から Webhook 到着までの遅延を測る"
description: "メール受信から Webhook 到着までの遅延を測る手順。Gmail・Outlook・IMAP の比較条件、p95・p99、休止や再送、期限内未達の扱いを整理します。"
url: https://mailera.app/ja/blog/email-webhook-latency
published: 2026-10-25
updated: 2026-10-25
---

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

Gmail、Outlook、IMAP の通知を比較するなら、まず測定の起点とメールボックスの稼働状態をそろえます。分位点と期限内未達を使い、待機時間や監視基準を決めるための測定手順です。

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

Webhook は、イベントの発生を HTTP リクエストで通知する仕組みです。[Mailera](https://mailera.app/ja/product) は、既存のメールボックスを接続し、新着メールなどのイベントをアプリへ通知できます。

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

![送信開始、プロバイダー到着、Mailera 検知、Webhook 受信、処理完了を分けた測定区間図](https://mailera.app/media/13a01189ed6f74f4/webhook-latency-path-ja-1200.jpg)
_主指標はプロバイダー到着から Webhook 本文の受信完了までです。送信前後の配送時間と後続処理は分けます。_

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

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

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

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

## Gmail・Outlook・IMAP の比較条件

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

[カスタム IMAP 接続](https://mailera.app/ja/providers/imap)も含め、接続方式と監視方式は分けて記録します。[RFC 2177](https://www.rfc-editor.org/rfc/rfc2177.html)では、サーバーが IDLE capability を通知しない場合、クライアントは IDLE ではなく定期確認を使う必要があります。IMAP 接続というだけで IDLE 利用と分類しないでください（資料参照日：2026-10-25）。方式の違いは[IMAP・Graph・SMTP の役割](https://mailera.app/ja/blog/ai-agent-email-protocols)でも整理しています。

| 条件 | 記録する内容 |
| --- | --- |
| 対象 | プロバイダー、個人・法人プラン、メールボックス数 |
| 接続 | 接続方式、接続テストの「リアルタイム監視」の結果 |
| 状態 | 通常稼働、アイドル、休止からの復帰、障害後の復旧 |
| 環境 | 測定期間、タイムゾーン、受信サーバー地域、負荷 |
| 試験メール | 送信元、本文・添付の条件、送信間隔、送信順序 |
| 観測 | 到着時刻の取得元、時計同期、観測期限、対象イベント |

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

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

![試験対象メールボックスのプロバイダー、接続状態、最終同期を確認する Mailera の画面](https://mailera.app/media/b97845e0900016a0/webhook-mailbox-conditions-ja-1200.jpg)
_画面は対象と接続状態の確認に使います。通知遅延は別途保存した時刻から計算します。_

接続準備は[既存メールボックスを外部システムにつなぐ手順](https://mailera.app/ja/blog/connect-existing-email-to-agents)を参照できます。準備時の操作と測定中の操作は分けて記録しましょう。

## 同じ測定を再現する手順

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

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

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

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

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

| 集計項目 | 用途 |
| --- | --- |
| 試行数・メール到着確認数 | 送信試行と受信後の測定対象を区別する |
| 有効件数 | 期限内に対応付けと署名検証ができた件数を示す |
| p50・p95・p99 | 中央値と遅い側の分布を見る |
| 最大値 | 観測期間内で最も長かった待ち時間を残す |
| 期限内未達件数 | 遅延分布に入らなかった試行を明示する |
| 署名検証失敗・重複件数 | 受信失敗や二重計上を切り分ける |

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

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

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

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

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

| よくある誤り | 修正方法 |
| --- | --- |
| 送信開始をメール到着として扱う | 配送時間と受信後の通知遅延を分ける |
| 時計のずれを無視する | 同期状態と誤差を記録し、負の遅延も調査する |
| 稼働中と休止中を混ぜる | 状態ごとに集計する |
| 重複通知を別の試行として数える | 試験メールごとに最初の有効通知を選ぶ |
| 遅い値だけ削除する | 除外理由と除外前後の集計を残す |

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

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

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

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

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

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

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

**APIで同じ操作を実行** — この記事の操作はすべてREST APIで実行できます。curlの例、API key、webhookも利用できます。 [APIドキュメントを見る](https://mailera.app/ja/docs)