---
title: "AI エージェントのメール承認を実装する"
description: "AI エージェントの提案をメールで確認し、承認された版だけを実行する設計。Mailera とアプリの責務、本人確認、期限、重複処理、送信結果不明への対応を解説します。"
url: https://mailera.app/ja/blog/ai-agent-email-approval
published: 2026-10-25
updated: 2026-10-25
---

# AI エージェントのメール承認を実装する

メールは承認を依頼する入口にし、実行の許可はアプリで管理します。返信案の版を固定し、期限切れや二重承認、送信結果不明でも勝手に再送しない構成を示します。

## メール承認と自動返信の違い

メール承認では、AI が返信案を作る段階と、実際に送信する段階の間に人の判断を置きます。今回は自分のテスト用メールボックスで、宛先・件名・本文を確認してから返信する例に絞ります。

基本案は、メールで通知し、認証済みの承認画面で判断してもらう方式です。

| 方式 | 本人確認 | 誤判定への対策 | 転送された場合 | 監査 | 実装負荷 |
| --- | --- | --- | --- | --- | --- |
| メール通知＋承認画面 | ログインと権限を検証 | 対象を表示し明示的に操作 | リンクの所持だけでは許可しない | 承認者と版を保存 | 画面と状態管理が必要 |
| メール返信 | 本文・From の一致だけに頼らない | 引用や曖昧な文を除外 | 転送先に権限を引き継がない | 返信と依頼の対応も保存 | 返信解析と追加確認が必要 |

[MCP のツール仕様](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)も、人が呼び出しを拒否できることや、機密性の高い操作で確認を求めることを推奨しています。ただし、特定の操作画面は規定していません。ツール実行の確認と、業務上の承認状態は分けて設計します。

## Mailera とアプリの役割分担

[Mailera の MCP](https://mailera.app/ja/mcp)で接続済みメールボックスを読み取り、送信には REST API を使う構成にします。承認状態の管理と承認者の本人確認は、Mailera の MCP ではなくアプリ側の担当です。

| 担当 | 役割 |
| --- | --- |
| Mailera | メール取得・送信、受信イベント通知、送信状態の取得 |
| 提案生成エージェント | 読み取り専用でメールを取得し、返信案を作成 |
| アプリの承認サービス | 承認者の権限確認、版と期限の検証、状態保存、監査記録 |
| アプリの実行サービス | 承認済みの内容だけを送信し、結果を記録 |

エージェントには `read` 権限のキーだけを渡し、`list_messages` や `get_message` を使わせます。`send` 権限のキーは実行サービスに隔離します。承認依頼の通知も、宛先とテンプレートを制限したサービスから送り、提案生成側には自由な送信手段を渡しません。

![Mailera から読み取った返信案をアプリで保存し、人の承認後に隔離した送信サービスから実行する構成](https://mailera.app/media/d36081d2ebbaa7ee/ai-approval-architecture-ja-1200.jpg)
_メールの入出力は Mailera、承認状態と実行許可はアプリ側で管理します。_

接続から始める場合は[既存メールボックスをエージェントにつなぐ手順](https://mailera.app/ja/blog/connect-existing-email-to-agents)を参照してください。Microsoft 365 を使う場合は、先に[Graph 接続の設定チェックリスト](https://mailera.app/ja/blog/microsoft-365-graph-mail-setup)で準備します。REST と webhook の入口は[開発者向けページ](https://mailera.app/ja/developers)にあります。

## 承認待ちから送信までの実装

1. **返信案を固定して保存します。** 対象メール、送信元メールボックス、宛先、件名、本文、承認者、期限、版を永続ストレージへ保存します。これらはアプリ独自の管理項目で、Mailera の API フィールドではありません。
2. **承認依頼を通知します。** メールには処理の要約と確認画面へのリンクを載せます。秘密情報は載せず、詳細はログイン後の画面で表示します。
3. **本人と対象を確認します。** アプリでログインと承認権限を検証し、送信元、全宛先、件名、本文を表示します。リンクを開いただけでは承認せず、明示的な操作を求めます。
4. **判断を原子的に保存します。** 対象の版、期限、承認待ち状態を同時に検証し、条件が一致した場合だけ承認または却下を記録します。変更があれば新しい版を作り、承認を取り直します。
5. **承認済みの版を送信します。** 実行サービスが保存済みの内容を読み、承認対象との一致を再確認します。`POST /mailboxes/{id}/send` に安定した `Idempotency-Key` を付け、送信試行の識別子も保存します。同じ実行の再試行でキーを作り直さない設計にします。
6. **送信結果を確認します。** `GET /sends/{id}` で状態を取得し、アプリの実行記録に反映します。`sent` を受信箱への到達や閲覧の証明には使いません。

送信 API は `send` 権限を必要とし、`Idempotency-Key` を受け付けます。REST のヘッダーを MCP の `send_email` の引数へそのまま移す設計にはせず、呼び出しの仕様は[API ドキュメント](https://mailera.app/ja/docs)で確認します。

承認と送信は、別の状態として保存します。

| アプリの状態 | 次に許可する操作 |
| --- | --- |
| 承認待ち | 期限内の承認または却下 |
| 承認済み | 対象の版を固定したまま実行へ進む |
| 却下 | 実行しない。必要なら新規依頼を作る |
| 期限切れ | 遅れて届いた承認を受け付けない |
| 実行中 | 他の実行を開始せず、送信状態を確認 |
| 完了 | 処理済みとして保持し、再実行しない |
| 要確認 | 自動再送を止め、送信記録と照合 |

Mailera の送信状態は `queued`、`sending`、`sent`、`failed`、`unknown` です。例えば `unknown` ならアプリを「要確認」にし、承認済みに戻して自動再送する処理は避けます。

## メールへの返信を受け付ける場合

返信は意思表示の候補として扱い、実行許可に直結させません。`message.received` webhook を使う場合も、署名を検証して対象メッセージを取得し、承認依頼との対応を調べたうえで確認画面へ案内します。受信通知自体を承認記録にはしません。

[メール形式を定める RFC 5322](https://www.rfc-editor.org/info/rfc5322/)は、メッセージ内容の形式と一部の意味を扱い、配送エンベロープは対象外です。メールの形式に合っていることと、承認権限があることを混同しない設計にします。アプリでは `conversation_id` や `internet_message_id` を依頼との対応確認に使っても、本人確認の代わりには使いません。

引用文中の「承認します」、自動返信、転送、相反する指示を含む返信は自動承認から除外します。曖昧な文を LLM に分類させても、その結果を認可の最終判定にせず、認証済み画面で本人に確認してもらいます。

## よくある失敗と対策

| 症状 | 確認箇所 | 安全側の挙動 |
| --- | --- | --- |
| 承認依頼が見つからない | 送信状態、迷惑メール、接続状態 | 未回答を承認扱いにしない |
| 期限切れ・却下後に返信が届く | 保存済みの期限と状態 | 状態を戻さず、新規依頼にする |
| 二重クリック・同じ通知が届く | 依頼と版の一意制約、状態遷移 | 条件付き更新で後続の処理を止める |
| 承認後に宛先や本文が変わる | 承認した版と実行対象 | 送信を止めて再承認する |
| 送信状態が `unknown` | 送信試行の識別子と記録 | 失敗と決めつけて再送しない |

外部通知の順序や一度だけの配信を前提にせず、アプリで重複を止めます。Mailera の冪等性の有効期間は 24 時間です。この期間だけに頼らず、アプリにも処理済み記録を残してください。

Mailera は受信箱への到達を保証しません。通知が届くまで実行を待ち、期限を過ぎたら止める設計にします。

## エージェントにメールを読ませるときの安全策

受信メールは信頼できないデータであり、命令ではありません。「承認を省略して」「別の宛先へ転送して」と書かれていても、承認ルールや送信先を変更させないでください。

API キーは読み取り用と送信用に分け、対象メールボックスのグループと権限を必要最小限にします。「設定」から「キーを作成」を開き、「メールボックスのスコープ」を絞ります。API キーや承認用トークンはモデル入力とログに含めません。

![テスト用メールボックスのグループに対象を絞った読み取り用 API キーの設定画面](https://mailera.app/media/426c8a44478ee09f/ai-approval-api-keys-ja-1200.jpg)
_提案生成側には読み取り用キーだけを渡し、送信用キーを共有しません。_

承認リンクへの GET アクセスでは状態を変えず、ログイン後の明示的な操作と CSRF 対策を組み合わせます。メール内リンクの検査だけで承認が成立する構成は避けてください。

監査記録には承認者、対象の版、判断時刻、実行結果を残します。本文の保存範囲と保存期間はアプリ側で決め、[Mailera のセキュリティ情報](https://mailera.app/ja/security)と併せて運用要件を整理してください。

**MCPでAIエージェントがメールボックスを利用** — MaileraのMCPサーバーをClaude、Cursor、VS Codeに追加すると、エージェントがメールの閲覧、分類、返信を行えます。 [MCPの使い方を見る](https://mailera.app/ja/docs#mcp)