n8nで最も過小評価されている機能は、AI Agentノードです。このノードにより、静的なワークフロー（「Xが起きたらYを実行する」）が、状況に応じてAIモデルが取るべきアクションを決める、より柔軟なワークフローに変わります。
この記事では、新規リードを受け取り、情報を補完し、スコアを付け、個別の返信案を作成して適切な場所へ振り分ける、実際に動くエージェントを最初から最後まで構築します。最後まで読めば、n8nエージェントの仕組みと、実用的なエージェントを壊れやすいデモから分ける設計パターンの両方を理解できます。
n8nがインストール済み（サーバー上で自社運用、またはn8n.cloudを利用）で、ClaudeまたはOpenAIの有効なAPIキーがあることを前提とします。n8nを初めて使う場合は、先に公式の基本チュートリアルを進めてください。
最初のバージョンでは、実在するリードへ返信を自動送信させないでください。ログ、冪等性、スコアのしきい値を整備し、乱雑な入力でもワークフローが適切に動くと判断できるだけの確認済み実行例が蓄積するまでは、下書きを人による確認に回してください。
構築するもの
ワークフローは次のとおりです。
- Webhook（フォーム、イベント、CRMなど）を通じて新規リードが届きます。
- エージェントがWeb検索を使って企業情報を補完します。
- 適合度、意欲、緊急度という3つの観点でリードを採点します。
- 個別に最適化した返信案を作成します。
- スコアに基づいて、次のいずれかを実行します。
- 確信度と適合度が高いリードには、自動返信してCRMレコードを作成します。
- 中程度のリードには、人が確認する返信案を作成し、Slack通知を送信します。
- 適合度が低いリードには、返信せず、記録と通知のみを行います。
このパターンは広く応用できます。「リード選別」を「サポートチケットの選別」「候補者の審査」「報道関係者からの問い合わせ対応」「顧客フィードバックの振り分け」に置き換えても、構造は同じです。
この記事からリンクしている付属のJSONスキーマは、受付ペイロードを定義しています。エージェントノードが入力を受け取る前に、このスキーマを使ってWebhook入力を検証してください。
エージェントの前に検証ゲートを追加する
Webhookから任意のフォームデータをそのままエージェントに渡してはいけません。トリガーとエージェントの間に検証ステップを配置します。
| フィールド | ルール | 失敗時の動作 |
|---|---|---|
email | 必須、有効なメールアドレス、小文字に正規化 | 拒否して所有者に通知 |
message | 必須、空でない、最大長以内 | 拒否するか、手動レビューに振り分け |
source | website-form、event、crmなどの必須列挙値 | 未知の送信元を拒否 |
timestamp | 必須のISOタイムスタンプ、またはWebhookが生成 | 受信時刻を使用してフラグを付与 |
lead_id | 必須の安定したID、または生成した冪等性キー | 処理前に重複排除 |
このゲートは、不正な形式の送信、Webhookの再試行による重複、フォームフィールド内に隠されたプロンプトインジェクションからワークフローを守ります。エージェントは引き続きメッセージを読めますが、レコードを処理するのに十分な妥当性があるかどうかはワークフローが決定します。
考え方：エージェント = LLM + ツール + ループ
構築を始める前に、概念を説明します。
2026年における「エージェント」とは、ツールを使用できるLLMを指します。モデルは単一の応答を生成する代わりに、どのアクション（「ツール」と呼びます）を呼び出すかを決定します。各ツールから結果が返るたびに、モデルはその結果を確認し、次に何をするかを決めます。別のツールを呼ぶか、別のステップに進むか、最終回答を返すかを判断します。
n8nのAI Agentノードは、このループを実装しています。モデルには次のものを与えます。
- システムプロンプト（指示と人格設定）。
- ユーザープロンプト（今回の実行に対する入力）。
- ツール一式（モデルが呼び出せる他のn8nノードまたはサブワークフロー）。
モデルは、呼び出すツール、その順序、引数を決定します。各ツールから結果が返るたびに再検討し、十分な処理を行ったと判断したら最終回答を返します。
これは静的なワークフローとは根本的に異なります。ステップの順序を決めるのは、利用者ではなくモデルだからです。エージェント設計の要点は次のとおりです。
- 適切なツールをモデルに与える（少なすぎず、多すぎず）。
- 動作範囲を定めるシステムプロンプトを書く。
- 脱線を防ぐガードレールを追加する。
- 後続ノードが確実に利用できる出力を設計する。
ステップ1：トリガー
n8nを開き、新しいワークフローを作成します。トリガーは次のように設定します。
- ノード： Webhook
- HTTPメソッド： POST
- レスポンスモード： 「When last node finishes」
- パス：
/lead-triageなど
このWebhookがリードの送信を受け取ります。n8nが提供するURLを、フォームの送信先やCRMの送信Webhookとして設定できます。
テストするには、Webhook URLを有効にするために一度ワークフローを保存し、サンプルペイロードを用意します。一般的なリード用Webhookのペイロードは次のようになります。
{
"name": "Anna Lehtinen",
"email": "anna@somecompany.fi",
"company": "Some Company OÜ",
"role": "マーケティング責任者",
"message": "御社のAIコンサルティングサービスに関心があります。10人のチームがあり、プロンプトエンジニアリング研修の支援を必要としています。",
"source": "website-form",
"timestamp": "2026-05-15T14:30:00Z"
}
「Test step」をクリックしてテストペイロードを送信し、データが流れることを確認します。
ステップ2：AI Agentノード
Webhookの後にAI Agentノードを追加し、次のように設定します。
- エージェントタイプ： Conversational（新しいバージョンでは「Tools Agent」の場合もあります。ツール呼び出しに対応するものを選びます）。
- チャットモデル： Claude（Anthropic）またはOpenAI。エージェントワークフローには、Claude Sonnet 4.5またはGPT-5がまず選ぶモデルとして無難です。推論モデルも動作しますが、エージェントのループでは遅くなります。
- メモリ： 状態を持たない選別ではNone（各リードを独立して扱います）。複数ターンのエージェント対話には、メモリノードを使用します。
- システムメッセージ： エージェントの動作を定義する場所です。以下のテンプレートを使用します。
- ユーザーメッセージ： Webhookからリードデータを取得します。
システムメッセージは次のとおりです。
あなたは、AIコンサルティング会社である[Your Company Name]のリード選別エージェントです。
あなたの仕事は、届いたリードを処理し、構造化された選別結果を生成することです。
各リードについて、必ず次の処理を行ってください。
1. `enrich_lead`ツールを使用して、企業に関する背景情報を収集する。
2. リードを次の3つの観点で採点する。
- 適合度：リードは当社の理想的な顧客像に合っているか。
- B2B、製造業、プロフェッショナルサービスのいずれかに該当する、従業員10～200人の企業。
- マーケティング、業務、エンジニアリング部門のリーダー、または経営幹部の役職。
- 意欲：問い合わせはどの程度真剣か。
- 「興味があるだけ」「積極的に評価中」「購入準備ができている」のいずれか。
- 緊急度：明示または暗示された期限があるか。
3. `score_lead`ツールを使用してスコアを記録する。
4. `draft_response`ツールを使用して、個別に最適化した返信を作成する。
5. `route_lead`ツールを使用し、"auto_reply"、"human_review"、"log_only"のいずれかを指定する。
振り分けルール：
- 適合度が7/10以上、かつ意欲が7/10以上なら"auto_reply"。返信は自動送信される。
- 適合度が5/10以上、または意欲が5/10以上なら"human_review"。送信前に人が確認する。
- 適合度が5/10未満、かつ意欲が5/10未満なら"log_only"。記録のみ行い、次へ進む。
情報を決して創作しないでください。不明な点がある場合は、採点理由に[不明]と記載してください。
最後に必ず次のJSONオブジェクトを返してください。
{
"fit_score": <1-10>,
"intent_score": <1-10>,
"urgency_score": <1-10>,
"reasoning": "<2～3文>",
"drafted_response": "<メール本文>",
"routing": "<auto_reply|human_review|log_only>"
}
構造に注目してください。ここには次のものがあります。
- 明確な仕事内容。
- 明示的な手順（ステップ1～5）。
- 明示的な採点基準。
- 明示的な振り分けロジック。
- 必須の出力形式。
エージェントが必ずしも完全に従うとは限りません。しかし、システムメッセージを具体的にするほど、毎回同じ形式で確実に実行できるようになります。
JSONオブジェクトだけでは不十分です。エージェントノードの後に検証ステップを追加し、スコアがない、振り分けが許可された列挙値の範囲外、または返信案が空の場合は、その実行を拒否してください。
ステップ3：ツール
エージェントには、呼び出すためのツールが必要です。n8nでは、ツールをエージェントノードの配下に設定します。ツールとして使用できるものは次のとおりです。
- サブワークフロー。
- HTTPリクエスト。
- 組み込みのツールノード。
エージェント用に4つのツールを構築しましょう。
ツール1：enrich_lead
次の処理を行うサブワークフローです。
- 企業名とメールドメインを入力として受け取ります。
- HTTPノードを使用して、Web検索API（Perplexity、Serper、Brave Search、Tavily）で企業を検索します。
- 企業の事業内容、おおよその規模、最近の注目すべきニュースを3文で要約して返します。
ツールの説明文（エージェントはこれを読み、いつ呼び出すかを判断します）は次のとおりです。
企業を検索して、リードの情報を補完します。入力：企業名とメールドメイン。出力：企業の事業内容、おおよその規模、最近の注目すべき背景情報の短い要約。
ツール2：score_lead
エージェントのスコアを受け取り、どこかに書き込む単純なツールです。たとえば次のものを利用できます。
- Google Sheetsの行。
- データベースへの挿入。
- CRM APIの呼び出し。
テストでは、Google Sheetsへの追記が最も簡単です。ツールの説明文は次のとおりです。
リードのスコアを記録します。入力：fit_score、intent_score、urgency_score、reasoning。出力：確認結果。
ツール3：draft_response
リードの背景情報とスコアを受け取り、個別に最適化したメールの下書きを作成するサブワークフローです。このサブワークフローは内部で別のAIノードを呼び出し、次のような専用の作成プロンプトを使用します。
B2Bの問い合わせに対する、個別に最適化した返信を作成してください。入力：リードから届いた元のメッセージ、企業情報を補完した要約、適合度／意欲／緊急度のスコア。
文体：温かみがあり、率直で、企業的な無駄な表現を使わない。具体的な依頼内容に言及する。企業情報の補完結果から何かを具体的に取り上げる（一般的な表現にしない）。具体的な次のステップ（例：「来週15分ほどお時間をいただけますか？」）で締めくくる。
長さ：80～120語。
ツールの説明文は次のとおりです。
リードに対する個別に最適化したメール返信を作成します。入力：リードのメッセージ、企業情報を補完した要約、スコア。出力：メールの下書き。
ツール4：route_lead
最後の振り分けアクションです。このツールはroute引数に基づいて、次のいずれかを実行します。
- メールを送信し、CRMレコードを作成します（auto_reply）。
- 下書きを保存し、Slack通知を送信します（human_review）。
- 記録し、CRMレコードを作成するだけにします（log_only）。
これは、引数に基づいて3つの異なる分岐へ振り分けるswitchノードを備えたサブワークフローとして実装します。
ツールの説明文は次のとおりです。
選別結果に基づいてリードを振り分けます。入力：振り分け結果（“auto_reply”、“human_review”、“log_only”）と返信案。出力：確認結果。
ステップ4：エージェントをテストする
エージェントを設定し、4つのツールを接続したら、サンプルペイロードを使ってテストを実行します。
n8nの実行ビューには、次の流れが表示されます。
- Webhookがペイロードを受信します。
- AI Agentが起動します。
- エージェントが
enrich_leadを呼び出します。ツールが実行され、結果を返す様子が表示されます。 - エージェントが次のステップを選択します（モデルと設定によっては、中間トレースが表示される場合と表示されない場合があります）。
- エージェントが
score_leadを呼び出します。 - エージェントが
draft_responseを呼び出します。 - エージェントが3つの振り分けオプションから1つを指定して
route_leadを呼び出します。 - エージェントが最終的なJSONを返します。
問題が発生した場合は、n8nのデバッグパネルでエージェントとツール間のメッセージを確認できます。最も一般的な問題は次のとおりです。
- ツールの説明が具体的でない。 モデルがツールを使うべき場面を推測できません。説明をより具体的にしてください。
- ツールの入出力スキーマが一致しない。 エージェントが正しい引数を渡せません。スキーマを明示してください。
- エージェントが無限にループする。 解決に至らず、ツールを呼び出し続けます。最大反復回数を設定し、システムプロンプトを見直してください。
ステップ5：ガードレールを追加する
最低限のエージェントをそのまま本番環境で使うのは安全ではありません。実際の処理を任せる前に追加すべき6つのガードレールを示します。
1. 最大反復回数。 エージェントの最大反復回数を妥当な値（10～20）に設定します。これにより、完了せずにツールを呼び出し続ける暴走ループを防ぎます。
2. auto_replyの承認ゲート。 エージェントが「auto_reply」と判断しても、最初の数週間は人による承認キューを経由させます。レビューなしで顧客に送信できるようにする前に、エージェントの自動返信判断が本当に適切か検証してください。
3. 外部向けアクションの許可リスト。 CRMツールとメールツールは、想定したパターンに一致するレコードだけを操作するように設定します。これにより、エージェントが誤ったアドレスにメールを送ったり、リードではない対象のレコードを作成したりすることを防ぎます。
4. ログ記録。 入力、すべてのツール呼び出し、最終出力を含め、エージェントの全実行を記録します。n8nの組み込み実行ログを使用するか、専用のログサービスに送信してください。問題が発生したときは、ログを使ってデバッグします。
5. コスト上限。 1日あたりのトークン予算を設定します。AIエージェントは暴走する可能性があります。設定を誤ったループにより、たった1回の不具合でAPI呼び出しに$50を費やすこともあります。n8nクラウドにはこの機能が組み込まれています。自社運用の場合は、APIキーの使用量を監視してください。
6. 判断の所有権。 モデルはauto_reply、human_review、log_onlyを推奨できますが、最終ルールはワークフロー側で強制する必要があります。振り分けの列挙値、スコアのしきい値、承認要件はプロンプトの外に置き、テスト可能かつ可視化された状態にします。
ステップ6：本番運用に向けた堅牢化
動作するプロトタイプを信頼できるものに変えるパターンをいくつか紹介します。
冪等性。 Webhookの再試行や手動での再実行により同じリードが2回処理されても、レコードが重複して作成されないようにします。ワークフローの先頭に「このリードは以前に処理されたか」という確認を追加してください。
エラー処理。 各ツール呼び出しをエラー処理で保護します。情報補完APIが停止していても、エージェントが異常終了してはいけません。情報が減った状態で処理を続け、不足データにフラグを付けます。
可観測性。 平均実行時間、ツールの呼び出し頻度、各経路へ振り分けられた割合など、主要な指標を追跡します。異常は重要な兆候です。
実行結果の確認。 最初の実在する50件のリードについて、すべての実行結果を元のリードと照合します。誤った企業情報の補完、不適切なスコア、不適切な振り分け、期限の見落とし、返信案の品質不足を追跡してください。これらの失敗がまれになり、原因を理解できるまでは、人による確認を緩和しないでください。
「キルスイッチ」。 再デプロイせずにエージェントを停止できる手段を用意します。単純な環境変数や、エージェントが最初に確認するワークフローの切り替え設定で構いません。本番環境で不適切な判断を発見し、一時停止したい場合に役立ちます。
最も重要な設計判断：エージェントに与えるツール
エージェントの品質を最も大きく左右するのは、ツール一式です。失敗には2つの形があります。
ツールが少なすぎる。 エージェントが仕事を遂行できません。不足した機能を取り繕おうとして、しばしばハルシネーションを起こします。
ツールが多すぎる。 エージェントが混乱し、間違ったツールを選んだり、探索に反復回数を浪費したりします。品質が低下します。
有効な原則は、実用最小限のツール一式から始め、エージェントに明確な必要性が生じた場合に限って追加することです。
リード選別では、今回選んだ4つのツールがほぼ適切です。次のようなツールを追加してもよいでしょう。
- リードが既存顧客かどうかを確認する「lookup_existing_customer」ツール。
- カレンダーと連携する「schedule_meeting」ツール。
- 複数の言語でリードが届く場合の「translate」ツール。
ただし、新しいツールを追加するたびに、エージェントが下す判断も1つ増えます。どのツールにも、追加するだけの明確な価値が必要です。
応用できるパターン
リード選別のために構築したものは、ほかの多くのユースケースにも使えます。
サポートチケットの選別。 情報補完を「lookup_customer_history」に、振り分けを「auto_solve / escalate / categorise」に置き換えます。
採用候補者の審査。 情報補完を「parse_cv」に、採点を職務適合基準に、振り分けを「interview / reject / flag for human review」に置き換えます。
報道関係者からの問い合わせ対応。 情報補完を「lookup_publication」に置き換え、優先度に基づいて返信を振り分けます。
顧客フィードバックの振り分け。 情報補完を感情分析と製品分類に置き換えます。
調達依頼。 情報補完をベンダー検索に、採点をポリシー遵守に、振り分けを承認フローに置き換えます。
根本的なパターンは常に同じです。受信イベント → 情報補完 → 採点／分類 → 返信案の作成 → 振り分けです。エージェントが判断し、ツールが実行します。
エージェントを使用すべきでない場合
エージェントを使っても利点のないワークフローもあります。ロジックが完全に決定論的、つまり「常にA、次にB、次にCを実行する」のであれば、エージェントを使わない通常のn8nワークフローのほうが高速で、安価で、信頼性も高くなります。
次のような場合に、エージェントを使う価値があります。
- 考えられる経路が多い。
- 適切な経路が厳密なルールではなく、判断に依存する。
- 複数の情報源を横断して情報を統合しなければならない判断がある。
判断ツリーが数個のif-then-else文で済むなら、if-then-elseノードを使用してください。if-then-elseでは管理できない場合に、エージェントを使いましょう。
実務で一度構築する
n8nのAIエージェントとは、与えられたツール一式を使い、どのアクションをどの順序で実行するかをモデルが決めるワークフローです。適切に構築すれば、従来は人が関与しなければならなかった、判断を多く伴う複数ステップの作業を処理できます。
今回構築したリード選別ワークフローは、n8nエージェントを初めて使う人なら約2時間で構築でき、その後、実データを使った調整に数週間かかります。その成果として、届いたすべてのリードの情報が数分以内に補完され、採点され、返信案が作成されて振り分けられます。人による確認は、実際に価値を加えられる場合だけで済みます。
関心のある実際のワークフローで、一度構築してみてください。エージェントの設計パターンは、2026年のAI業務で最も大きな効果を生むスキルの1つです。
