---
title: "LangGraph メールエージェントの送信前承認設計"
description: "LangGraph メールエージェントで、読み取りと送信を分離する設計を解説。外部画面での承認、返信案の版管理、再開時の検証、重複送信対策を整理します。"
url: https://mailera.app/ja/blog/langgraph-email-approval
published: 2026-10-25
updated: 2026-10-25
---

# LangGraph メールエージェントの送信前承認設計

返信案を作るモデルに、送信権限まで渡さない構成にします。外部画面での承認対象を固定し、再開時の検証と送信の再試行をサーバー側にまとめます。

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

外部承認とは、エージェントの実行とは別の画面で、人が送信内容を確認する方式です。メールへの返信を承認に使う方式は、[メールを使った承認のアプリ設計](https://mailera.app/ja/blog/ai-agent-email-approval)で扱います。

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

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

承認を境にモデルと送信処理の権限を分ける考え方は、[承認境界を設けたメールエージェントの設計](https://mailera.app/ja/blog/build-email-agent-with-approval)で整理しています。

接続全体の考え方は、[既存メールボックスをエージェントにつなぐ手順](https://mailera.app/ja/blog/connect-existing-email-to-agents)を参照してください。承認画面と承認状態の管理は、この構成ではアプリ側に実装します。

![読み取り専用 MCP から返信案を作り、外部承認とサーバー検証を経て REST で送信する設計図](https://mailera.app/media/fb557c64a30fab84/langgraph-approval-flow-ja-1200.jpg)
_承認画面と記録はアプリ側に置き、送信権限はサーバー側だけに持たせます。_

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

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

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

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

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

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

`read` 権限で使えるツールを、すべてモデルへ渡す必要はありません。[MCP のツール仕様](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)では、`tools/list` でツールを取得し、各ツールの `inputSchema` で引数を確認できます。アプリ側で許可した名前だけを公開する構成にします。

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

![対象グループを限定し、読み取り権限だけを付ける API キー作成画面](https://mailera.app/media/45ab9abad23c6280/langgraph-read-key-ja-1200.jpg)
_モデル用のキーには送信権限を付けません。_

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

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

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

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

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

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

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

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

[MCP 仕様の安全上の考慮事項](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)も、人がツール実行を拒否できることと、呼び出し前に入力内容を表示することを推奨しています。ユーザーが回答を送る前に確認・修正できるようにすることは、[MCP の elicitation 仕様](https://modelcontextprotocol.io/specification/2025-06-18/client/elicitation)でも推奨されています。

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

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

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

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

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

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

同じ送信処理を再試行するときは、保存済みの `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 のセキュリティ案内](https://mailera.app/ja/security)も参照してください。キーを失効させると、そのキーによる呼び出しは直ちに拒否されます。

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