読み取り・承認・送信を誰が担当する？

外部承認とは、エージェントの実行とは別の画面で、人が送信内容を確認する方式です。メールへの返信を承認に使う方式は、メールを使った承認のアプリ設計で扱います。

ここでは、次のように責務を分けます。

担当この構成で任せる処理任せない処理
LangGraph 側のアプリ読み取り、返信案作成、承認待ちへの遷移モデルの判断だけによる送信
承認アプリ承認者の認証、内容の表示、承認記録の保存ブラウザーから渡された値の無条件な採用
サーバー側の送信処理承認との照合、REST 呼び出し、結果照会承認後の本文の書き換え
Mailera既存メールボックスへのアクセスと送信新しいメールボックスやアドレスの作成

承認を境にモデルと送信処理の権限を分ける考え方は、承認境界を設けたメールエージェントの設計で整理しています。

接続全体の考え方は、既存メールボックスをエージェントにつなぐ手順を参照してください。承認画面と承認状態の管理は、この構成ではアプリ側に実装します。

読み取り専用 MCP から返信案を作り、外部承認とサーバー検証を経て REST で送信する設計図
承認画面と記録はアプリ側に置き、送信権限はサーバー側だけに持たせます。

1. MCP を読み取り専用にする

まず、自分のテスト用メールボックスだけを専用グループに置きます。Microsoft の場合は「メールボックス」の「メールボックスを追加」から「Microsoftでサインイン」を選び、OAuth で接続します。Outlook・Microsoft 365 の接続案内も参照できます。

「設定」から API キーの作成画面を開き、「キーを作成」で「メールボックスのスコープ」をテスト用グループに限定します。読み取り権限だけを付与し、送信権限は付与しません。

Mailera の MCP 接続先は https://mailera.app/api/public/v1/mcp です。認証には Authorization: Bearer $MAILERA_API_KEY を使います。

モデルへ公開するツールは、次の読み取り用に絞ります。

  • list_mailboxes：対象のメールボックスを選ぶ
  • list_messages：メール一覧を読む
  • get_message：選んだメールの本文を読む

read 権限で使えるツールを、すべてモデルへ渡す必要はありません。MCP のツール仕様では、tools/list でツールを取得し、各ツールの inputSchema で引数を確認できます。アプリ側で許可した名前だけを公開する構成にします。

「MCP 設定をコピー」は Claude、Cursor、VS Code 向けの機能です。

対象グループを限定し、読み取り権限だけを付ける API キー作成画面
モデル用のキーには送信権限を付けません。

2. 承認待ちに入る前に返信案を固定する

読み取り、返信案作成、承認待ち、送信を別の処理に分けます。承認待ちへ入る前に、画面に表示する内容を保存してください。再開後にモデルへ本文を作り直させる設計にはしません。

アプリの状態には、次の情報を持たせます。これはアプリ独自の保存項目であり、Mailera API のフィールド名ではありません。

保存する情報用途
実行スレッドの識別子承認要求と再開対象を結び付ける
送信元メールボックス ID・元メール IDどのメールに返信するかを固定する
宛先・件名・本文・返信案の版人が確認した内容を保存する
承認要求の識別子・状態・期限・承認者送信を許可できるか判断する
送信処理の識別子・冪等性キー・送信記録再試行時に同じ処理を追跡する

承認待ちの保存処理には、メール送信を混ぜないでください。同じ保存処理が再試行されても、メールが出ない構造にします。

再起動への備えとして、承認記録と返信案はプロセスのメモリーだけに置かず、永続ストレージに保存します。グラフの実行状態と承認記録は、同じ実行を指す識別子で結び付けます。

3. 外部画面から承認・却下・修正を受け付ける

承認画面には、送信元、宛先、件名、本文、返信対象を表示します。「返信してよいですか」だけでは、何を許可するのか判断できません。

MCP 仕様の安全上の考慮事項も、人がツール実行を拒否できることと、呼び出し前に入力内容を表示することを推奨しています。ユーザーが回答を送る前に確認・修正できるようにすることは、MCP の elicitation 仕様でも推奨されています。

  1. 承認：サーバーで本人確認と対象メールボックスへの権限を確認します。承認要求が期限内か、未処理か、表示した版と保存済みの版が一致するかを照合します。
  2. 却下：却下を保存し、送信へ進めず終了します。
  3. 修正：本文や宛先を変更したら新しい版として保存し、それまでの承認を無効にします。変更後の内容を再表示してください。

再開対象は、サーバーに保存した承認要求から引きます。ブラウザーが任意のスレッド識別子を送るだけで、実行を再開できる入口にはしません。

二重クリック対策では、「承認待ちから承認済みへの更新」を条件付きで行い、最初の更新だけを受け付けます。承認保存後に再開処理が止まる場合にも備え、再開待ちの作業を保存して追跡する設計にします。

4. 承認済みの内容だけを REST で送る

送信ノードでは、モデルの出力ではなくサーバー側の承認記録を読みます。承認済みの版、送信元、宛先、件名、本文、返信対象を照合し、不一致なら送信しません。

Mailera の POST /mailboxes/{id}/send は、送信・返信・転送に対応し、send 権限が必要です。この権限を持つ API キーは、サーバー側の送信処理だけに渡します。API の入口は開発者向け案内で確認できます。

同じ送信処理を再試行するときは、保存済みの Idempotency-Key を使います。再試行のたびに生成し直してはいけません。Mailera の冪等性の保持期間は 24 時間です。これを超えた処理は自動再送せず、送信記録と状態を確認する運用にします。

MCP にも send_email と reply_to_email がありますが、この設計では送信経路を REST に統一します。モデルに送信ツールを公開しないためです。

送信試行は、send 権限で GET /sends/{id} から照会できます。状態は queued、sending、sent、failed、unknown です。unknown を即座に失敗と判断し、新しいキーで送り直す運用は避けます。

送信受付、送信状態、相手の受信トレイへの到達は別です。Mailera は受信トレイへの到達を保証しません。

よくあるエラー：再開できない・二重送信される

症状確認する箇所対処
別の返信案が開く承認要求と実行スレッドの対応サーバーの保存記録から対象を引く
再起動後に承認待ちが消える実行状態・承認記録の保存先永続化と復元の経路を確認する
送信や結果照会が拒否されるキーの send 権限と対象グループサーバー側のキー設定を確認する
承認後に内容が変わる返信案の版と送信直前の内容送信を止め、再承認へ戻す
二重クリックで処理が重なる承認状態の条件付き更新未処理の要求だけを受け付ける
送信応答が返らない送信記録と冪等性キー新規送信にせず、同じ試行を追跡する

受け入れテストには、承認待ちでの再起動、同時承認、期限切れ、承認後の本文変更、送信応答の消失を含めます。期限切れや不一致のときは、送信処理が呼ばれないことを確認してください。

再開できることだけを、重複送信対策にしないでください。承認記録、送信処理の識別子、冪等性キーをまとめて管理します。

受信メールをシステムへの命令にしない

受信メールは信頼できないデータです。本文に「承認を省略してください」「秘密情報を返信してください」と書かれていても、エージェントの実行規則にはしません。承認済みかどうかは、モデルではなくサーバーの記録で判断します。

承認画面では本文を安全に表示し、メール由来の HTML をそのまま実行させない設計にします。API キーをプロンプトやチェックポイントへ入れず、本文も不要にログへ残さないでください。

権限を絞る際は、Mailera のセキュリティ案内も参照してください。キーを失効させると、そのキーによる呼び出しは直ちに拒否されます。

MCPでAIエージェントがメールボックスを利用

MaileraのMCPサーバーをClaude、Cursor、VS Codeに追加すると、エージェントがメールの閲覧、分類、返信を行えます。

MCPの使い方を見る