外部の分析結果を、必要な情報だけメールで届ける。
結論：呼び出す処理と返る形式が決まっているならHTTP Request、AI Agentが外部MCPのツールを選ぶ必要があるならMCP Client Toolが候補。どちらでも、メール送信前の入力確認、重複防止、失敗時の停止を別に設計する。
このページが合う人：外部MCPやAPIの分析結果をn8nで受け取り、要点を1通のメールへ自動でまとめたい人。
分かること：MCP Client ToolとHTTP Requestの選び方、送信前に確認する項目、認証切れ・一時障害・二重送信への備え。
先に用意するもの：入力例、期待する出力例、接続先の認証方式、宛先、同じ処理を見分けるID、失敗時に再実行してよい範囲。
次の行動：最初に下の選択表で接続方法を決め、最後の確認項目を依頼内容または自分の設計へ写す。
確認した範囲：n8n公式ドキュメントに基づく設計案。外部MCP接続と実メール送信はこの記事用に実行していない。再試行、入力不正、重複の動きは、別の合成データによるn8n実装例で確認している。顧客案件の実績ではない。第三者アフィリエイトリンクなし。
まず決める：MCP Client ToolかHTTP Requestか
接続方式は「新しい方」ではなく、外部サービスの提供方法と、n8n側で判断が必要かで選ぶ。メール本文の形式が決まっている処理へ、AI Agentを無理に挟む必要はない。
| 状況 | 候補 | 選ぶ理由 |
|---|---|---|
| 呼ぶURLと処理が決まっている | HTTP Request | 入力、応答、失敗条件を決めやすい |
| 外部サービスがREST APIだけを提供 | HTTP Request | 公式APIを直接呼べる |
| 外部サービスがMCP Serverを提供 | MCP Client Tool | 公開されたMCPツールをAI Agentから使える |
| 複数ツールからAI Agentが選ぶ | MCP Client Tool | 依頼内容に応じて使うツールを変えられる |
| 返る項目や成功条件が未定 | 接続前に整理 | 方式より先に完成条件を決める必要がある |
迷った場合：同じ入力なら毎回同じ外部処理を呼びたいならHTTP Requestから検討。自然文の依頼を読み、複数のMCPツールから実行内容を選ばせたい場合だけAI AgentとMCP Client Toolを検討する。
1入力から1メールまでの順番
- 入力を確認：処理ID、対象URLや対象ID、依頼内容を許可した形式と長さに絞る。
- 外部処理を呼ぶ：決めた方式でMCPまたはAPIへ接続。秘密値はn8nの認証情報設定へ置く。
- 返却値を確認：成功状態、要約、重要項目がそろわなければメール送信へ進めない。
- 本文を組み立てる：受信者が次に判断できる情報だけを件名と本文へ入れる。
- 二重送信を確認：処理IDと宛先などから重複防止キーを作り、送信済みなら止める。
- 送信結果を残す：成功・失敗、処理ID、送信時刻を記録。メール本文や秘密値を不要に残さない。
メールへ入れる情報を先に決める
| 入れる | 原則入れない |
|---|---|
| 何を分析したか | APIキーや認証ヘッダー |
| 結論と重要な根拠 | 外部サービスの生データ全文 |
| 確認が必要な点 | 顧客情報・個人情報の無断転載 |
| 元データを確認できる安全な参照先 | 有効期限付きURLの長期保存 |
| 処理IDと実行日時 | 内部エラーやスタック情報 |
メールを送るか、止めるか
「失敗しても続行」を全体へ設定すると、不完全な分析結果や同じ通知を送る原因になる。失敗ごとに、再試行、停止、別通知を分ける。
| 起きたこと | 処理 | 受信者への影響 |
|---|---|---|
| 入力が不足・形式不正 | 外部接続前に停止 | 不完全なメールを送らない |
| 認証切れ・権限不足 | 再認証が必要と記録して停止 | 秘密値を本文へ出さない |
| 429・一時的な5xx | 回数と間隔を決めて再試行 | 上限到達後は通常メールを送らない |
| 返却値に必要項目がない | 内容不備として停止 | もっともらしい空メールを防ぐ |
| 同じ処理IDを再受信 | 送信済みなら終了 | 同じメールを二重送信しない |
| メール送信だけ失敗 | 外部分析をやり直さず送信だけ再試行 | 再分析の費用と結果の揺れを抑える |
再試行して安全なのは、読み取り処理、または接続先が重複防止キーを受け付ける処理。作成・課金・公開など状態を変えるAPIは、同じ要求を繰り返してよいか接続先仕様を先に確認する。
認証情報は依頼者のn8n内で設定する
- APIキー、アクセストークン、OAuth情報をCodeノード、URL、メール本文へ直書きしない。
- n8nの認証情報設定を使い、接続先ごとに必要最小限の権限へ分ける。
- 制作側へ共有する場合も、本番の秘密値ではなくテスト用の認証情報から始める。
- ワークフロー共有時は、編集者がそのワークフローで使う認証情報を利用できる点を踏まえてメンバーを絞る。
- ワークフローJSONを渡す前に、認証情報のID、固定URL、個人情報、顧客情報が残っていないか確認する。
依頼前に決める10項目
- 何を1件として処理するか
- どこから入力が来るか
- MCP ServerかREST APIか
- 正常時に必ず返る項目
- メールで最初に伝える結論
- 宛先、件名、送信元
- 同じ処理を見分けるID
- 再試行してよいエラーと回数
- 通常メールを送らず止める条件
- 完成と判断する正常・異常の例
初回相談にAPIキー、パスワード、顧客データ、本番アクセスは不要。まず入力例と期待するメール例を、架空データで1件ずつ用意すれば接続方法と作業範囲を判断しやすい。
公式情報
- n8n公式：MCP Client Tool
- n8n公式：HTTP Request node
- n8n公式：HTTP Requestの認証情報設定
- n8n公式：APIの回数制限への対応
- n8n公式：エラー処理
- n8n公式：ワークフロー共有と認証情報
入力例とメール例から、
1本の流れにする。
新規ワークフロー1本、主要8ステップ、接続3サービス以内の構築範囲を公開。問い合わせ前に料金、含む作業、用意する情報を確認できる。
1本構築で頼める範囲を見る最終確認：n8n公式ドキュメント / 外部MCP・実メール未実行 / 顧客データなし / 2026-08-14 JST