---
title: "IMAP IDLE 対応の確認方法と通知が届かないときの切り分け"
description: "IMAP IDLE 対応を CAPABILITY、新着通知、再接続の順に確認する手順を解説。993 番ポートや Mailera の Webhook との違い、通知が止まる際の確認点も紹介します。"
url: https://mailera.app/ja/blog/imap-idle-support
published: 2026-10-25
updated: 2026-10-25
---

# IMAP IDLE 対応の確認方法と通知が届かないときの切り分け

仕様上の対応、実際の新着通知、切断後の復旧を分けて確認します。Mailera の監視表示や Webhook との違いも整理します。

## IMAP IDLE 対応は何を確認すればよいですか？

IMAP IDLE は、クライアントがメールサーバーに変更通知を受け取る準備ができたと伝え、接続上で通知を待つ仕組みです。定期的に更新を問い合わせるポーリングとは、変更を知る方法が異なります。

[RFC 2177 の IDLE 仕様](https://www.rfc-editor.org/info/rfc2177/)では、IDLE 中にサーバーが `EXISTS` や `EXPUNGE` などの応答を送れます。同仕様では、サーバーが `IDLE` capability を通知しない場合、クライアントは IDLE を使わず、ポーリングする必要があります。

判定は次のように分けると、失敗した段階を追えます。

| 確認する段階 | 残す記録 |
| --- | --- |
| 仕様上の対応 | 公式資料の記載と確認日 |
| 接続先が示す機能 | 認証後の `CAPABILITY` 応答とプロトコルの版 |
| 実際の動作 | IDLE 開始応答、新着通知、対象メールの取得結果 |
| 切断後の復旧 | 再接続と、切断中に届いたメールの再同期結果 |

[RFC 9051](https://www.rfc-editor.org/info/rfc9051/)では、993 番は Implicit TLS のポートです。ポート番号は接続方式の情報であり、IDLE の動作確認の代わりにはなりません。

## どのメールサービスが対応していますか？

Gmail の公式資料には、`IDLE` を含む `CAPABILITY` 応答例があります。[Gmail の IMAP 拡張の説明](https://developers.google.com/workspace/gmail/imap/imap-extensions)で確認できます。利用するアカウントでも、認証後の応答と通知の受信を記録してください。Mailera 側の接続条件は [Gmail 接続ガイド](https://mailera.app/ja/providers/gmail)にまとめています。

サービスを比較するときは、サービス名だけの対応表ではなく、次の条件を各試行に添えます。

- プラン、地域、接続先、認証方式
- 試験日時とタイムゾーン、接続元、クライアント名とバージョン
- 宣言された IMAP 仕様、選択したフォルダー
- IDLE 開始、新着通知、再接続後の結果、匿名化したログの保存先

認証失敗は認証段階の失敗として残します。タイムアウトも、発生した段階を記録してください。どちらも、それだけで IDLE 非対応とは判定しません。

Outlook.com と Microsoft 365 は別枠です。[Mailera の Microsoft 接続](https://mailera.app/ja/providers/microsoft)は OAuth と Microsoft Graph を使います。新着検知は Graph 変更通知と定期的な補完確認によるため、その成功を IMAP IDLE の結果に数えないでください。

## 同じ条件で確認する手順

自分が管理する試験用メールボックスを使います。サービス間で比較するなら、観測時間と試行回数、成功条件を先に決め、失敗した試行も残してください。

1. **接続条件を固定します。** 前節の項目を記録し、TLS で接続して認証します。別のプランや接続元で試した結果は、別の行に分けます。
2. **認証後の機能を保存します。** `CAPABILITY` 応答を記録します。接続直後の応答だけで判断せず、宣言された IMAP の版も残してください。RFC 2177 の判定条件を使うときは、その適用範囲をそろえます。
3. **通知と取得を別々に確認します。** `INBOX` を選択して IDLE を開始し、継続応答を記録します。別の送信経路から識別用の件名を付けた試験メールを送り、`EXISTS` などの応答を待ちます。通知を受けた時刻と、対象メールを取得できた時刻を分けて残します。
4. **IDLE を終了して入り直します。** `DONE` を送り、終了を確認してから次のコマンドを実行します。RFC 2177 では、サーバーが `DONE` を待つ間に別のコマンドを送ってはいけません。再度 IDLE を開始できるかも確認します。
5. **切断と復旧を試します。** 意図的に接続を切り、その間に試験メールを送ります。再接続後、切断中のメールを再同期できるか、その後の IDLE 通知を受け取れるかをそれぞれ記録します。

長時間の観測では、接続を放置しないでください。RFC 2177 は、非活動によるログアウトを避けるため、29 分を超えない間隔で IDLE を終了して再発行するよう勧めています。これはメールサービスごとの実測タイムアウト値ではありません。

独自サーバーを Mailera に接続する際の入力項目は、[カスタム IMAP 接続ガイド](https://mailera.app/ja/providers/imap)で確認できます。

## IDLE 通知と Webhook はどう違いますか？

IDLE は IMAP 接続上の変更通知です。アプリの URL に届く HTTP 通知ではありません。変更を知る処理、メールを取得する処理、Webhook を配信する処理を分けて観測します。

![IMAP サーバーから変更通知、メール取得、Webhook 受信へ進む流れ](https://mailera.app/media/c4b74ab3a248e91a/imap-idle-idle-webhook-flow-ja-1200.jpg)
_変更通知、メール取得、Webhook 受信を別々に記録します。_

[Mailera](https://mailera.app/ja/product)は既存のメールボックスを REST API や Webhook につなぎます。Webhook は `POST /webhooks` で登録し、新着イベントには `message.received` があります。迷惑メールの `message.junk`、接続切断の `mailbox.disconnected` も区別して扱えます。

Webhook の操作には `webhooks` スコープが必要です。登録時の署名用シークレットは一度だけ返されるため、安全に保存してください。登録形式は [開発者向け案内](https://mailera.app/ja/developers)から API 資料を参照できます。

メール到着から Webhook 受信までの時間を比較する場合は、[プロバイダー別の到着から Webhook 受信までのベンチマーク](https://mailera.app/ja/blog/email-webhook-latency)を参照してください。

Microsoft Graph も、メールボックス内のメッセージの変更を購読し、通知先 URL を指定する仕組みです。[Microsoft の変更通知の説明](https://learn.microsoft.com/en-us/graph/outlook-change-notifications-overview)と、[IMAP・Graph・SMTP の役割の違い](https://mailera.app/ja/blog/ai-agent-email-protocols)を参照すると、監視経路を整理できます。

## Mailera の監視表示はどう読みますか？

「メールボックスを追加」から「テストして接続」を実行すると、「リアルタイム監視」の結果を確認できます。この接続テストではメールを送信しません。試験メールを使った新着通知の確認は、別に行ってください。

![Mailera の接続テストにあるリアルタイム監視の確認項目](https://mailera.app/media/b12cb977e2574d90/mcp-gmail-outlook-imap-add-test-mailbox-ja-1200.jpg)
_接続テストはメールを送信しません。新着通知の受信は、試験メールで別に確認します。_

画面の監視結果と、生の IMAP 接続で採ったログを並べて確認します。画面には接続条件を添えて記録し、サービス全体の対応表として扱わないようにします。

API では `GET /mailboxes/{id}` の `protocol`、`capabilities.live`、`sync` を確認できます。特に `protocol` を見て、Graph 経由の接続と IMAP の試験を分けてください。

## よくある失敗：対応しているのに通知が届きません

「接続できた」「IDLE に入れた」「新着を取得できた」は別の結果です。最後に成功した段階から調べます。

| 症状 | 確認する記録 | 次の操作 |
| --- | --- | --- |
| 認証を通過できない | 認証応答、アカウントの接続設定 | 認証と IMAP 利用条件を確認し、IDLE 判定は後にします |
| 接続できるが IDLE を開始できない | 認証後の `CAPABILITY`、プロトコルの版 | 適用する仕様と開始時の応答を照合します |
| IDLE 中に試験メールの通知がない | 選択フォルダー、メールの到着先、接続状態 | 同じフォルダーに届いたか確認します |
| しばらくすると通知が止まる | 切断時刻、IDLE の終了・再発行記録 | IDLE の更新と再接続を分けて試します |
| 通知はあるが処理に進まない | メール取得結果、Webhook 受信記録 | 通知後の取得と HTTP 受信を別々に調べます |
| Mailera の確認が止まって見える | `sync.state`、`sync.sleeping_since` | 使用状態を確認し、必要なら同期を実行します |

Mailera は使用中のメールボックスをより頻繁にバックグラウンド確認し、使われていないメールボックスでは確認頻度を下げます。非アクティブなメールボックスはスリープし、利用時に復帰する場合があります。この状態を、プロバイダーの IDLE 非対応と取り違えないでください。

`POST /mailboxes/{id}/sync` は同期を開始し、スリープ中のメールボックスを復帰させることもできます。必要なスコープは `sync` です。

## 検証の範囲と Mailera の制限

試験結果は、その日時、アカウント、プラン、地域、接続条件に限って扱います。Proton Mail と Tuta には対応しておらず、新しいメールボックスやメールアドレスも作成しません。

ログや画像から、認証情報、メールアドレス、本文を除去してください。API キーは試験対象と必要な権限に絞ります。

[既存メールボックスを AI エージェントにつなぐ構成](https://mailera.app/ja/blog/connect-existing-email-to-agents)へ進む場合も、受信メールは信頼できないデータとして扱います。メール内の指示を実行命令にせず、送信前には人の確認を挟んでください。

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