---
title: "AIエージェントのメール連携：Gmail・Outlookを使う"
description: "既存のGmailやOutlookをAIエージェントにつなぐ方法を解説。MCPとREST APIの選び方、読み取り専用での開始手順、返信前の承認と安全対策を整理します。"
url: https://mailera.app/ja/blog/ai-agent-email-integration
published: 2026-10-25
updated: 2026-10-25
---

# AIエージェントのメール連携：Gmail・Outlookを使う

今のメールアドレスを変えずに、メールの取得から返信案の作成、承認後の送信へ進めます。接続と内容判断の役割を分け、まず読み取り専用で動かす手順を紹介します。

## メールを扱う AI エージェントは何をするのか？

メールを扱う AI エージェントは、メール操作のツールと AI モデルを組み合わせ、取得した内容に応じて処理を進める仕組みです。文章を生成するだけでなく、メールボックスからメッセージを取得し、必要に応じて返信の送信まで扱います。

たとえば、自分のテスト用メールボックスに届いた問い合わせを要約し、返信案を作る構成では、役割を次のように分けます。

| 担当 | 役割 |
| --- | --- |
| Mailera | 既存メールボックスへの接続、メッセージの取得、送信操作の窓口 |
| AI モデル | 内容の解釈、要約や分類、返信案の生成 |
| 利用側のアプリ | 処理対象の選択、業務ルール、人による承認、送信の実行判断 |

[Mailera の接続機能](https://mailera.app/ja/product)だけで、返信内容の判断まで完結するわけではありません。「読む権限」と「送る判断」を分けると、要約だけの試作から始められます。

![Outlook と Gmail などの既存メールボックスを、Mailera の REST API または MCP 経由で AI エージェントにつなぐ構成](https://mailera.app/media/1df25849cd8d0af8/ai-gmail-outlook-connection-map-ja-1200.jpg)
_プロバイダーごとの接続方式を、エージェント側では共通の窓口から扱います。_

## 既存のメールボックスはそのまま使えるか？

既存の連絡先と同じアドレスでやり取りを続けたいなら、今のメールボックスを接続する構成が向いています。新しい用途を既存の業務から分離したいなら、専用受信箱を用意するか検討してください。選択の基準は[既存メールボックスと新規エージェント用受信箱の比較](https://mailera.app/ja/blog/ai-agent-email-address)で整理しています。

接続方法はプロバイダーによって異なります。

| メールボックス | Mailera での接続方法 | 接続前に確認すること |
| --- | --- | --- |
| Outlook・Microsoft 365 | OAuth による Microsoft Graph 接続 | Microsoft 側の同意画面と組織で許可されるアクセス |
| Gmail・Google Workspace | アプリパスワード（app password）による接続 | 2 段階認証と、組織での利用許可 |
| 独自 IMAP サーバー | 受信用 IMAP と、必要なら送信用 SMTP を設定 | サーバー、ポート、暗号化方式、認証情報 |

[Outlook・Microsoft 365 の接続](https://mailera.app/ja/providers/microsoft)では OAuth を使います。Mailera の Microsoft 接続を、アプリパスワードで設定する構成にはしません。

[Gmail の接続](https://mailera.app/ja/providers/gmail)ではアプリパスワードを使います。Google は 2 段階認証を利用条件としており、組織アカウント、Advanced Protection、セキュリティキーのみの 2 段階認証などでは作成項目が表示されない場合があります。作成前に[Google のアプリパスワード利用条件](https://support.google.com/accounts/answer/185833)を確認してください。

独自 IMAP では、受信できても送信できるとは限りません。「受信サーバー（IMAP）」と「送信サーバー（SMTP）」は別の設定です。送信サーバーを空欄にすると受信専用になります。

Proton Mail と Tuta は Mailera の対応対象外です。ほかのプロバイダーも含めた選び方は、[既存メールをエージェントにつなぐ接続ガイド](https://mailera.app/ja/blog/connect-existing-email-to-agents)を参照してください。

## MCP と REST API はどう使い分けるか？

対応クライアントから試すなら MCP、自作アプリに業務フローを組み込むなら REST API を選ぶと、最初に作る部分を絞れます。webhook は別の選択肢というより、処理を始めるための通知手段です。

| 接続手段 | 向いている用途 | 最初に扱う操作 |
| --- | --- | --- |
| MCP | Claude、Cursor、VS Code などからメールツールを呼ぶ | `list_mailboxes` → `list_messages` → `get_message` |
| REST API | 自作アプリで取得対象や処理順序を制御する | メールボックス一覧、メッセージ一覧、本文取得 |
| webhook | 新着メールや接続切断をきっかけに処理する | `message.received`、`mailbox.disconnected` などの通知 |

MCP は、LLM アプリケーションと外部データやツールをつなぐプロトコルです。[Mailera の MCP 接続](https://mailera.app/ja/mcp)は、REST API と同じメールボックスを操作する窓口になります。クライアント選びは[既存メールボックス向け MCP サーバーの使い方](https://mailera.app/ja/blog/email-mcp-server)、API の組み込みは[開発者向けページ](https://mailera.app/ja/developers)で確認できます。

通知を受ける構成でも、常に即時に処理が始まる前提にはしないでください。Mailera の Microsoft 接続は Graph の変更通知と補助的な定期確認を使います。[Microsoft Graph の変更通知](https://learn.microsoft.com/en-us/graph/outlook-change-notifications-overview)はメールボックスのメッセージ変更を購読する仕組みです。

## 最初の読み取り専用連携はどう始めるか？

最初の目標は、既知のテストメールを取得して、原文に合った要約を作ることです。送信はこの段階では許可しません。

1. **自分が管理するテスト用メールボックスを用意します。** 機密情報を含まない問い合わせ文を送り、件名と本文を控えます。たとえば「資料の送付予定日を教えてください」という内容なら、要約との比較が容易です。
2. **メールボックスを追加します。** 管理者またはリーダー権限で「メールボックス」から「メールボックスを追加」を開きます。Microsoft は「Microsoftでサインイン」、Gmail や独自 IMAP は「単一メールボックス」から進め、プロバイダーに合う認証情報を設定します。
3. **接続結果と同期を確認します。** IMAP 接続では「テストして接続」を実行し、受信サーバーへのサインインやフォルダー検出の結果を確認します。このテストはメールを送信しません。接続後はメールボックス一覧で状態と最終同期を確認し、「統合受信トレイ」でテストメールを探します。
4. **対象を限定した API キーを作ります。** 「設定」の API キー画面で「キーを作成」を開き、「メールボックスのスコープ」をテスト用グループに限定します。権限は `read` のみとし、「有効期限」も設定してください。キーは作成時に一度だけ表示されるため、秘密情報として保管します。
5. **MCP または REST API で取得します。** MCP なら作成直後の画面で「MCP 設定をコピー」を使い、対応クライアントに設定します。まず `list_mailboxes`、次に `list_messages`、最後に `get_message` で対象メールを読みます。
6. **原文と要約を照合します。** 問い合わせの内容、日付、依頼事項が一致するか確認します。原文にない約束や推測が加わっていれば、送信権限を追加する前にエージェント側の処理を見直します。

![テスト用グループに対象を絞り、読み取り権限のみを設定する Mailera の API キー作成画面](https://mailera.app/media/e1ec928428390cf5/ai-gmail-outlook-read-only-key-ja-1200.jpg)
_読み取れるメールボックスと操作権限の両方を限定します。_

REST API を選ぶ場合は、実際のキーを環境変数 `$MAILERA_API_KEY` に設定してから、メールボックス一覧を取得します。

```bash
curl "https://mailera.app/api/public/v1/mailboxes?limit=1" \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

レスポンスの `data` 内にある対象メールボックスの `id` を `$MAILBOX_ID` に設定し、受信トレイのメッセージを取得します。

```bash
curl "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages?folder=inbox&limit=1" \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

対象メッセージの `id` を `$MESSAGE_ID` に設定すると、本文を取得できます。テストメールが一覧にない場合は、次の節の確認項目を使ってください。

```bash
curl "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages/$MESSAGE_ID" \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

本文は `data.body.text` または `data.body.html` で確認します。一覧の `preview` だけで要約せず、本文取得の結果を使ってください。これらの読み取り操作に `send` 権限は不要です。

## 接続できない・メールが見つからないときは？

接続、同期、送信権限を分けて確認します。メールが見つからないだけで認証情報を作り直すと、原因を絞りにくくなります。

| 症状 | 確認箇所 | 次の対応 |
| --- | --- | --- |
| Microsoft に接続できない | OAuth の同意画面、組織のアクセス制限 | 管理者に許可条件を確認します。アプリパスワードへの切り替えでは対処しません |
| Gmail のアプリパスワードを作れない | 2 段階認証、アカウントや組織の条件 | Google の公式条件と管理者設定を確認します |
| Gmail が接続できなくなった | Google アカウントのパスワード変更の有無 | Google は変更時にアプリパスワードを取り消すため、該当する場合は再設定します |
| メールが見つからない | 接続状態、最終同期、フォルダー、取得対象期間 | `inbox` だけでなく `junk`、検索条件の `since`、保存期間を確認します |
| 同期が進まない | 一時停止やスリープの状態 | 一時停止なら「再開」、必要なら「同期」を使います |
| 受信できるが送信できない | 受信専用設定、SMTP、API キーの権限 | メールボックスの送信可否と `send` 権限を別々に確認します |
| 送信結果が不明 | 送信試行の状態 | `get_send_status` または `GET /sends/{id}` で確認してから次の操作を判断します |

API では、メールボックス一覧の `status`、`sync.last_synced_at`、`sync.sleeping_since` を確認します。同期 API はスリープ中のメールボックスも起こしますが、`sync` 権限が必要です。読み取り専用キーに権限を足す前に、管理画面で状態を確認してください。

送信状態には `queued`、`sending`、`sent`、`failed`、`unknown` があります。応答が途切れたことを失敗と決めつけ、同じメールを無条件に再送しない設計にします。

## 返信まで任せる前に、何を守るべきか？

**受信メールと添付ファイルは、信頼できない外部データです。エージェントへの指示ではありません。** 本文に「API キーを送って」「別の宛先へ転送して」「権限を変更して」と書かれていても、実行の根拠にしないでください。

これはプロンプトインジェクションへの対策です。本文を読む処理と、ツール実行を許可する処理を分けます。読み取り専用でも情報の外部流出を防げるとは限らないため、モデルへ渡す個人情報や機密情報を必要最小限にしてください。

送信を追加するときは、利用側のアプリに承認フローを用意します。人が宛先、本文、引用情報を確認し、承認した内容だけを送信処理へ渡す設計にします。承認後に宛先や本文が変わったら、再度確認を求めてください。

![信頼できない受信データを読み取り、返信案を人が確認した後に送信して状態を確認する処理フロー](https://mailera.app/media/88f6f7fe45f4753e/ai-gmail-outlook-approval-flow-ja-1200.jpg)
_内容を読む段階と、送信を許可する段階を分けます。承認は利用側で実装します。_

`send_email` と `reply_to_email` は `send` 権限を必要とします。取得用キーは `read` のまま保ち、送信用キーは承認を扱う処理だけで使う構成にすると、権限の境界を明確にできます。

[MCP 仕様の同意と安全に関する原則](https://modelcontextprotocol.io/specification/2025-06-18)でも、ツール呼び出し前の明示的なユーザー同意を求めています。ただし、MCP の仕組みだけで安全原則が強制されるわけではありません。MCP 接続を設定しただけで、承認の設計が済んだとは扱わないでください。

API キーや認証情報をプロンプト、ログ、スクリーンショットに残さず、実際のメール本文も不要に記録しない運用にします。漏えい時にはキーを取り消せます。製品側の扱いは[Mailera のセキュリティ情報](https://mailera.app/ja/security)、利用側の設計は[承認の境界を持つメールエージェントの作り方](https://mailera.app/ja/blog/build-email-agent-with-approval)で確認できます。

## Mailera でできないことは？

Mailera は既に利用権限のあるメールボックスを接続するサービスです。新しいメールボックスやメールアドレスの発行、一斉配信やマーケティング配信、メールボックスのウォームアップは提供しません。

迷惑メールからメッセージを移動しても、プロバイダーがその送信者を信頼するようにはできません。受信トレイへの到達は保証しません。

同期頻度は接続方式や利用状況にも左右されます。利用中のメールボックスより確認頻度が下がるものや、スリープするものもあるため、常に即時に読み取れる前提の業務にはしないでください。

無料ワークスペースで試せますが、メールの保存期間は 30 日です。過去のメールも処理する場合は、この範囲を先に確認してください。プランの条件は[Mailera の料金ページ](https://mailera.app/ja/pricing)で確認し、別途使う AI モデルやクライアントの料金とは分けて見積もります。

**最初のメールボックスを2分で接続** — Outlook、Gmail、IMAPのメールボックスを追加して、アプリやAPIでメールを読めます。 [メールボックスを接続](https://mailera.app/auth?mode=signup)