接続先は Outlook.com ですか、職場・学校のメールですか？
まず、Outlook というアプリ名と、Outlook.com というメールサービスを分けて考えます。確認するのは、アプリの名前ではなく、読もうとしているメールの提供元です。
| メールの接続先 | 確認する認証方式・設定 | 次に取る対応 |
|---|---|---|
| 個人用 Outlook.com・Hotmail | アプリが OAuth に対応し、その方式で設定されているか | OAuth 対応の設定で接続し直す |
| 職場・学校の Microsoft 365（Exchange Online） | OAuth 対応、組織で利用できる接続方法と同意要件 | 管理者と設定を確認する |
| Outlook アプリで読む iCloud など | 実際のメール提供元の認証要件 | 提供元の手順に従う |
| オンプレミスの Exchange | 組織のサーバー設定 | 本記事の手順をそのまま適用せず、管理者に確認する |
会社の独自ドメインという理由だけで、Exchange Online と判断しないでください。接続先が不明なら、メール管理者にサービス名を確認してください。
Outlook アプリで Gmail を読んでいる場合は、Gmail のアプリパスワード設定と接続手順を参照してください。
なぜアプリパスワードを作り直しても直らないのですか？
アプリパスワード（app password）は、2 段階認証に対応していない機器などで使うためのパスワードです。OAuth のアクセストークンではなく、基本認証の終了を解決する手段でもありません。
Microsoft の Outlook.com 向け移行案内では、2024 年 9 月 16 日に基本認証が利用できなくなったと説明されています。個人用 Outlook.com の接続では、先進認証に対応した方法へ切り替えます。
職場・学校のメールについては、Exchange Online の基本認証廃止の説明を参照してください。IMAP の基本認証は廃止され、対象アプリではアプリパスワードも使えません。管理者や Microsoft サポートに依頼して基本認証を再度有効にすることもできません。
アプリパスワードの作成案内が見つかっても、それだけで対象サービスの IMAP が受け付けるとは判断できません。提供元ごとの使い分けは、メールボックス接続のアプリパスワードガイドでも整理しています。
ここで注意したいのは、廃止されたのが基本認証であって IMAP 自体ではない点です。Microsoft は Outlook.com と Microsoft 365 の両方で、IMAP の OAuth 認証を案内しています。
OAuth へ切り替えるには、何をすればよいですか？
- 接続先と現在の設定を確認します。 アプリが OAuth に対応していても、既存アカウントが基本認証のままなら、認証方式の変更が必要です。
- 提供元が案内する方法で再設定します。 アカウントやプロファイルを削除する前に、端末内だけに保存されているメールがないか確認してください。
- 職場・学校のメールは管理者に確認します。 IMAP を利用できる設定か、アプリへの同意が必要か、組織のアクセス制御で許可されるかを確認します。
- 自分のメールボックスにテストメールを送ります。 サインインが完了したことと、メールを取得できたことを別々に確認してください。
具体例として、Microsoft のサポート情報では、Outlook.com・Hotmail を Thunderbird で使う場合、受信サーバーの認証方式（Authentication method）を「Normal password」から「OAuth2」に変更するよう案内しています（表記は Microsoft の英語ドキュメントに基づきます）。
一方、Outlook for Windows で Outlook.com を POP・IMAP として設定した構成は、先進認証に対応しないと説明されています。Microsoft が案内するのは、新しい Outlook Desktop プロファイルでアカウントを自動設定する方法です。「OAuth 対応アプリだから、今の IMAP 設定でも使える」とは限りません。
OAuth 非対応のアプリは、対応版への更新か、別のアプリへの変更を検討してください。自作クライアントの場合は、Microsoft の IMAP OAuth 実装手順を参照します。IMAP では SASL XOAUTH2 形式でアクセストークンを渡すため、パスワード欄の値だけを置き換える対応では済みません。
Mailera で Outlook のメールボックスを接続するには？
Mailera は、既存のメールボックスをアプリや AI エージェントにつなぐサービスです。Microsoft メールボックスの接続には OAuth と Microsoft Graph を使います。アプリパスワードによる IMAP 接続は行わないため、IMAP サーバー名やポートの入力も不要です。
IMAP と Microsoft Graph の役割の違いは、エージェント開発者向けの IMAP・Graph・SMTP ガイドで確認できます。
- Admin または Leader 権限のユーザーで、「メールボックス」から「メールボックスを追加」を開きます。
- 「Microsoftでサインイン」タブを選びます。「単一メールボックス」タブでプロバイダーとして「カスタムIMAP」を選ぶ流れには進みません。
- Microsoft 側で、接続するアカウントと同意内容を確認します。職場・学校用では、個人用とアカウントを取り違えていないかも確認してください。
- 「統合受信トレイ」で対象メールボックスを選び、自分のテストメールが表示されるか確認します。
Microsoft Graph の権限には、ユーザー自身で同意できるものと、管理者の同意が必要なものがあります。承認を求められた場合は、Microsoft Graph の認証と認可の説明を参考に、管理者へ利用するアプリと目的を伝えてください。職場・学校のメールボックスを接続する際は、Microsoft 365 の Graph 接続チェックリストも参照してください。
よくあるエラーでは、どこを確認すればよいですか？
認証に失敗しても、原因が基本認証の廃止とは限りません。どの段階で止まっているかを確認してください。
| 症状 | 確認箇所 | 次の対応 |
|---|---|---|
| 「Outlook アプリパスワードの入力が必要です」と表示される | 接続先と、アプリに残っている認証方式 | 基本認証なら、パスワードの再発行ではなく OAuth 設定へ切り替える |
| Microsoft 側で管理者承認を求められる | アプリの同意要件と組織の利用方針 | 管理者に承認を依頼する |
| サインイン後も Mailera にメールが見えない | 対象メールボックス、受信トレイと迷惑メール | 自分の新しいテストメールで取得を確認する |
| 古いメールだけが見えない | 保存期間 | 無料セルフサービスワークスペースの保存期間は 30 日と確認する |
API でも確認するなら、GET /mailboxes/{id}/status は Microsoft へのサインインが引き続き機能するかを直接調べます。メッセージ取得は別に GET /mailboxes/{id}/messages で確認します。どちらも必要な権限は read です。最終同期の日時は、GET /mailboxes/{id} の data.last_sync_at で確認できます。
次の例は受信トレイのメッセージを取得します。環境変数 $MAILERA_API_KEY と $MAILBOX_ID に、自分のキーと対象メールボックスの ID を設定して使ってください。
curl "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages?folder=inbox&limit=1" \
-H "Authorization: Bearer $MAILERA_API_KEY"返された data 配列の各メッセージにある subject と received_at を見て、テストメールか確認します。data が空なら、この応答にはメッセージが含まれていません。API の利用方法は Mailera のドキュメントにあります。
パスワード更新を促す通知が届いても、そのリンク先で認証情報を入力せず、Microsoft の公式画面を自分で開いて確認してください。
接続後の安全性と Mailera の制約は？
Mailera の Microsoft 接続では Microsoft 側の OAuth 同意フローを使います。Microsoft Graph の権限によっては管理者の同意が必要です。Mailera は新しいメールボックスやメールアドレスを作成するサービスではありません。
API キー、アクセストークン、refresh token は、問い合わせ本文やスクリーンショットに含めないでください。キーの権限と利用範囲を決める際は、Mailera のセキュリティ情報も確認できます。
AI エージェントに接続する場合は、対象メールボックスを含む必要なグループにキーの範囲を絞り、受信確認には read だけを付与します。受信メールは信頼できないデータです。本文中に指示があっても、エージェントへの命令として実行させないでください。送信も許可する構成では人の確認を挟み、受信確認のためだけに send 権限を追加しないようにします。
