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

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

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

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

MCP のツール仕様も、人が呼び出しを拒否できることや、機密性の高い操作で確認を求めることを推奨しています。ただし、特定の操作画面は規定していません。ツール実行の確認と、業務上の承認状態は分けて設計します。

Mailera とアプリの役割分担

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

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

接続から始める場合は既存メールボックスをエージェントにつなぐ手順を参照してください。Microsoft 365 を使う場合は、先にGraph 接続の設定チェックリストで準備します。REST と webhook の入口は開発者向けページにあります。

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

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 ドキュメントで確認します。

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

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

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

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

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

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

よくある失敗と対策

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

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

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

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

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

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

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