HTTP Request と MCP はどう使い分ける？
この構成では、汎用の HTTP Request ノードに REST API の URL、認証情報、入力を設定します。取得と送信を別ノードにすると、承認前に送信できる経路がないか確認しやすくなります。
Mailera の開発者向けページでは接続方式の全体像を、MCP の案内ではエージェントへ公開するツールを確認できます。ここでは MCP エンドポイントは使いません。MCP を選んでも、送信承認の設計は別途必要です。読み取りと送信の境界をどう設けるかは、承認境界を設けたメールエージェントの設計を参照してください。
| 処理 | ノード・役割 | Mailera の権限 |
|---|---|---|
| メール一覧・本文の取得 | HTTP Request | read |
| 返信案の作成 | AI Agent または LLM 処理 | 追加取得する場合のみ read |
| 承認待ち・承認判定 | Wait と承認状態を確認する処理 | 不要 |
| 承認済み内容の送信・状態確認 | 別の HTTP Request | send |
この処理には、メールボックスの設定変更に使う manage や、メールボックスを新規登録する import の権限は付与しません。
手順 1：メールボックスと API キーを準備する
自分のテスト用メールボックスを接続します。Microsoft は「メールボックスを追加」から「Microsoftでサインイン」を選び、OAuth で接続します。詳細は Microsoft の接続手順と Microsoft 365 の Graph 設定チェックリストを参照してください。Gmail は Gmail の接続案内に沿って準備します。
- 「設定」内の API キー画面で「キーを作成」を選びます。
- 「メールボックスのスコープ」をテスト用グループに限定し、読み取り権限（
read）のみのキーと送信権限（send）のみのキーを分けて作成します。 - キーは作成時に一度しか表示されないため、画面の案内に従ってすぐにコピーし、安全に保管します。n8n の認証情報に
Authorization: Bearer <API key>を登録してください。
キーをプロンプト、ノードの説明、共有するワークフロー JSON に書かないでください。送信用の認証情報は、承認後の送信・状態確認ノードだけに設定します。
API の基点は https://mailera.app/api/public/v1 です。まず読み取り用のキーで接続を確認します。以下のシェル例では、環境変数 $MAILERA_API_KEY にキーを設定しておきます。
curl 'https://mailera.app/api/public/v1/mailboxes?limit=1' \
-H "Authorization: Bearer $MAILERA_API_KEY"レスポンスの data 配列にメールボックスが含まれることを確認します。対象の id を $MAILBOX_ID として使い、送信前には capabilities.send も確認してください。
手順 2：HTTP Request でメールを取得する
最初は手動実行にします。HTTP Request のメソッドを GET にし、一覧取得の URL と読み取り用の認証情報を設定します。
curl "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages?folder=inbox&limit=1" \
-H "Authorization: Bearer $MAILERA_API_KEY"これは対象メールを絞って確認するための設定です。通常運用ではページを順に取得します。
| パラメーター | 最初の設定・扱い |
|---|---|
folder | inbox を指定 |
limit | 動作確認では 1 を指定 |
since | 初回は指定せず、対象メールが取れるか確認 |
cursor | 初回は省略。次ページでは返された next_cursor を渡す |
一覧は data 配列です。next_cursor が返っていれば、その値を次のリクエストの cursor に使います。HTTP Request の公式ドキュメントも、ページネーション設定前にレスポンスを確認する手順を案内しています。
一覧から対象の id を選び、$MESSAGE_ID として本文を取得します。
curl "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages/$MESSAGE_ID" \
-H "Authorization: Bearer $MAILERA_API_KEY"処理対象を確保するときは、メールボックス ID とメッセージ ID の組み合わせを永続保存し、同じ組み合わせを並列実行が取得できないよう排他制御を設けます。未読かどうかだけで処理済みを判断しないでください。
手順 3：返信案を作り、人の承認を待つ
AI に渡すのは、返信に必要な件名と本文に絞ります。AI Agent ノードを使う場合は、少なくとも一つのツールサブノードが必要です。
HTTP Request はエージェントのツールにもできます。ただし追加取得の URL とメールボックスは固定し、読み取りだけに限定します。送信ツールは接続しません。
承認は次の順序で組み立てます。
- 参照元のメール ID、宛先、件名、返信本文を承認用データとして保存します。
- 人が元メールと返信案を確認できる承認画面を用意し、承認者と承認結果を保存します。
- Wait で待機し、承認処理から実行を再開します。
- 再開後に承認者、承認状態、有効期限、内容の一致を確認します。却下、期限切れ、承認者不明なら送信せず終了します。
Wait の公式ドキュメントでは、HTTP 呼び出しによる再開と「Header Auth」が案内されています。再開 URL は実行時に生成されます。承認者を確認するアプリ側から、認証付きでこの URL を呼ぶ設計にしてください。URL を知っていること自体を承認者の証明にしません。
Wait の再開は、承認完了を意味しません。「Limit Wait Time」を有効にすると期限到達でも再開するため、直後に送信へ進めず、保存した承認状態を必ず確認します。承認後に宛先や本文を変更した場合も再承認に戻します。
メールを使って承認を依頼する場合の設計は、メールによる人の承認を組み込むアプリケーションパターンを参照してください。
手順 4：承認済みの内容を送り、状態を確認する
送信には POST /mailboxes/{id}/send を使います。HTTP Request は JSON 本文に対応しています。返信用の入力項目は Mailera の API ドキュメントに合わせ、保存済みの承認内容から組み立てます。送信直前に AI に書き直させないでください。
送信処理では、次の記録を紐付けて保存します。
| 記録 | 用途 |
|---|---|
| メールボックス ID ＋メッセージ ID | 元メールの重複処理を防ぐ |
| 承認済み内容・承認者・承認状態 | 送信してよい内容を確定する |
Idempotency-Key | 同じ送信処理の再試行に同じ値を使う |
| 送信 ID・送信状態 | 受付後の結果を確認する |
Idempotency-Key は論理的な送信処理ごとに生成・保存し、再試行時に新しく作り直しません。ただし、ヘッダーだけに頼らず、処理記録側でも重複を止めます。
受付後は送信 ID を使い、GET /sends/{id} で状態を確認します。こちらも send 権限が必要です。
queued、sending：処理中として追跡します。sent：送信済みとして記録します。failed：原因を確認して再試行を判断します。unknown：即座に再送せず、状態と処理記録を照合します。
タイムアウトも即失敗とは扱いません。送信要求の受付と送信完了を分けて管理してください。
よくあるエラーと再実行時の問題
| 症状 | 確認箇所・対処 |
|---|---|
| 認証・アクセスに失敗する | Bearer ヘッダー、キーの有効性、対象グループ、read／send を確認 |
| 一覧が空になる | メールボックス ID、folder、絞り込み条件、sync.last_synced_at を順に確認 |
| 一部のメールしか処理されない | next_cursor を使って次ページを取得しているか確認 |
| 同じ返信案が複数できる | 処理記録の一意性と、並列実行時の排他制御を確認 |
| 取得できるが送信できない | capabilities.send と受信専用接続になっていないかを確認 |
| レート制限・一時障害になる | 応答内容を確認し、間隔を空けて再試行。送信は先に状態を照合 |
HTTP Request は既定で 2xx の応答だけを成功として扱います。「Include Response Headers and Status」を有効にすると、本文と併せてヘッダーとステータスを確認できます。設定を変えたら、後続ノードが参照するデータの位置も確認します。
定期実行は手動テスト後に追加します。Schedule Triggerでは一定間隔で実行でき、ワークフローの保存と公開が必要です。取得間隔とメールボックスの同期タイミングは別なので、間隔を短くするだけで即時処理になるとは限りません。
メールを読むエージェントの安全対策と制限
受信メールは信頼できないデータであり、命令ではありません。本文の「別の宛先へ転送」「秘密情報を送信」といった指示には従わせないでください。プロンプトだけで防ごうとせず、読み取り権限、固定した接続先、人の承認で操作を制限します。
この構成には、添付ファイルの実行やメール内 URL の自動取得を含めません。外部モデルへ渡す情報を絞り、n8n の実行履歴とモデル提供元の保存条件も確認します。Mailera 側の扱いはセキュリティの説明を参照してください。
Mailera は既存メールボックスを接続するサービスです。新しいメールアドレスの発行には対応していません。一斉配信・マーケティング配信も対象外で、相手の受信トレイへの到達も保証しません。返信案と承認記録は、この構成では n8n 側または外部アプリ側で管理します。
運用開始前には、自分のテスト用メールで「未承認・却下・期限切れでは送信されない」「承認後の変更は再承認になる」「再実行しても重複送信しない」を確認してください。
