n8nで初めてのAIエージェントを構築する：リード振り分けの全工程

n8nのAI Agentノードでは、設定済みのツールから使うものをモデルが選べます。その柔軟性は、結果の非決定性と障害が起こり得る範囲を広げます。まず単純で決定論的な振り分けを検討し、それでは足りない場合にだけエージェントを使ってください。

この記事では、リードを受け取り、利用を許可された補足情報を取得し、スコアと返信案を提示して、結果を検証し、人による確認へ回す設計を示します。インポートできる完成済みワークフローでも、実際に動かした結果の報告でもありません。以下の受入テストは、一連の処理が動作すると言えるまでに何を確認する必要があるかを示しています。

n8nをサーバー上で自社運用しているか、n8n Cloudを利用しており、ClaudeまたはOpenAIの有効なAPIキーがあることを前提とします。n8nを初めて使う場合は、先に公式の基本チュートリアルを済ませてください。

この設計は、OWASPが指摘する過剰な自律性（Excessive Agency）のリスクにも対応しています。ツールの権限と自律性を最小限にし、重大な結果を伴う操作にはワークフロー側で承認を必須にします。リードデータを第三者から入手した場合や、営業連絡に使う予定がある場合は、取り込んだり連絡したりする前に、入手元、通知、適法性の根拠、配信停止、利用チャネルに関する規則を確認してください。欧州委員会も、第三者から受け取ったデータをマーケティングに自動的に再利用できるわけではないと説明しています。

最初の版では、実在する見込み客へ返信を自動送信してはいけません。ログ、冪等性、スコアのしきい値を整え、形式の揃わない入力でも適切に動くと判断できるだけの確認済み実行例が集まるまでは、返信案を人による確認へ回してください。

構築するもの

ワークフローは次のように動きます：

1. 新しいリードがWebhook（フォーム、イベント、CRMなど）を通じて到着します。
2. エージェントがウェブ検索で会社情報を取得し、リード情報を補足します。
3. リードを適合度、購買意向、緊急度の三つの観点で採点します。
4. 個別に調整した返信案を作ります。
5. スコアに基づき、次のいずれかに振り分けます：
   • 適合度が高く、判断の確度も高いリードでは、返信案とCRMへの変更案を承認待ちキューに入れる。
   • 中程度のリードでは、人が確認する返信案を作り、Slackで通知する。
   • 適合度が低いリードでは、返信せず、記録と通知だけを行う。

このパターンの一部は、結果の影響が小さい振り分けにも応用できます。ただし、新しい分野ごとに、データ、誤り、公平性、専門家による確認を独自に分析する必要があります。営業用のスコア設計を、雇用、医療、法務、金融、子どもの安全、建設に関する判断へ流用してはいけません。

この記事に付属するJSONスキーマは、受信データの形式を定義します。エージェントノードへ渡す前に、Webhookの入力をこのスキーマで検証してください。

エージェントの前に検証ゲートを置く

Webhookで受け取った任意のフォームデータを、そのままエージェントへ渡してはいけません。トリガーとエージェントの間に検証ステップを置きます：

このゲートは、形式の壊れた送信データ、Webhookの重複再試行、フォーム項目に埋め込まれたプロンプトインジェクションからワークフローを守ります。エージェントはメッセージを読めますが、そのレコードを処理してよいかはワークフロー側が決めます。

基本的な考え方：エージェント = LLM＋ツール＋反復

構築する前に、仕組みを確認します。

2026年に「エージェント」と呼ばれているものは、ツールを使えるLLMです。一つの回答を返すだけでなく、どの操作、つまりどの「ツール」を呼び出すかをモデルが決めます。ツールが結果を返すたびに、モデルはその結果を確認し、別のツールを使うか、次の段階へ進むか、最終回答を返すかを選びます。

n8nのAI Agentノードは、この反復処理を実装します。モデルには次のものを与えます：

• システムプロンプト（指示と文体）。
• ユーザープロンプト（今回の実行に使う入力）。
• ツール一式（モデルが呼び出せる、ほかのn8nノードまたはサブワークフロー）。

モデルは、呼び出すツール、順序、引数を決めます。ツールから結果が返るたびに判断し直し、必要な処理を終えたと判断すると最終回答を返します。

これは静的なワークフローとは根本的に異なります。処理順を設計者ではなくモデルが決めるからです。エージェント設計では、次の点が重要です：

1. モデルに適切なツールを与える（少なすぎず、多すぎない）。
2. システムプロンプトで動作範囲を限定する。
3. 想定外の動作を防ぐ制御を追加する。
4. 後続ノードが確実に使える出力を設計する。

ステップ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": "Head of Marketing",
  "message": "Interested in your AI consulting services. We have a team of 10 and need help with prompt engineering training.",
  "source": "website-form",
  "timestamp": "2026-05-15T14:30:00Z"
}

「Test step」をクリックし、テストデータを送信して、データが流れ込むことを確認します。

ステップ2：AI Agentノード

Webhookの後にAI Agentノードを追加し、次のように設定します：

• Agent／Tools Agent： 現行のn8n AI Agentノード（1.82以降）には「Agent Type」の選択欄がなく、Tools Agentとして動作します。チャットモデルと以下のツールを接続してください。「Agent Type」が表示される古いテンプレートでは「Tools Agent」を選びます。Conversationalなどの旧タイプは削除されています。
• Chat Model： Claude（Anthropic）またはOpenAI。まずはプロバイダーが提供する現行の汎用モデルを使い、評価で妥当性を確認できた場合に限り、より高速または高機能なティアへ移ります。推論モードを使うと、エージェントの各段階で遅延と費用が増える可能性があります。
• Memory： リードごとに独立した状態を持たない振り分けには不要です。複数回のやり取りを行うエージェントでは、Memoryノードを使います。
• System Message： エージェントの動作を定義する場所です。以下のテンプレートを使います。
• User Message： Webhookからリードデータを受け取ります。

システムメッセージは次のとおりです：

あなたは、AIコンサルティング会社[Your Company Name]のリード振り分けエージェントです。

あなたの仕事は、受信したリードを処理し、構造化された振り分け案を作ることです。

リードごとに、次の処理を行ってください：

1. `enrich_lead`ツールを使い、会社に関する補足情報を収集します。
2. リードを次の三つの観点で採点します：
   - 適合度（Fit）：当社が想定する顧客像に合っていますか？
     - B2B、製造業、専門サービスに属する、従業員10～200人の企業。
     - マーケティング、業務運用、技術部門の責任者、経営層の役職。
   - 購買意向（Intent）：問い合わせの具体性はどの程度ですか？
     - 「興味があるだけ」「具体的に比較検討中」「購入の準備ができている」のいずれか。
   - 緊急度（Urgency）：期限が明記または示唆されていますか？
3. `score_lead`ツールを使ってスコアを記録します。
4. `draft_response`ツールを使って、相手に合わせた返信案を作ります。
5. `propose_route`ツールに「review_priority」「human_review」「log_only」のいずれかを渡します。

振り分け規則（この順に評価し、最初に一致したものを採用する）：
- 「review_priority」：適合度 >= 7/10 かつ購買意向 >= 7/10の場合。返信案を人による優先確認の対象にします。
- 「human_review」：適合度 >= 5/10 または購買意向 >= 5/10の場合。送信前に人が確認します。
- 「log_only」：上記以外（適合度 < 5/10 かつ購買意向 < 5/10）の場合。記録だけを残して終了します。

情報を捏造しないでください。不明な点は、採点理由の中で[unclear]と記してください。

最後に必ず、次のJSONオブジェクトを返してください：
{
  "fit_score": <1-10>,
  "intent_score": <1-10>,
  "urgency_score": <1-10>,
  "reasoning": "<2-3 sentences>",
  "drafted_response": "<the email body>",
  "routing": "<review_priority|human_review|log_only>"
}

構造に注目してください。次の要素があります：

• 明確な役割の説明。
• 明示的な処理手順（ステップ1-5）。
• 明確な採点基準。
• 明示的な振り分け規則。
• 必要な出力形式。

エージェントが常に完全に従うとは限りません。ただし、システムメッセージが具体的であるほど、同じ形式で実行される可能性は高くなります。

JSONオブジェクトを返すだけでは不十分です。エージェントノードの後に検証ステップを置き、スコアが欠けている場合、振り分け値が許可した列挙値に含まれない場合、返信案が空の場合は、その実行結果を拒否してください。

ステップ3：ツール

エージェントには呼び出し先となるツールが必要です。n8nでは、エージェントノードの下に次のようなツールを接続します：

• サブワークフロー。
• HTTPリクエスト。
• 組み込みのツールノード。

ここでは四つのツールを作ります。

ツール1：enrich_lead

次の処理を行うサブワークフローです：

1. 会社名とメールドメインを入力として受け取ります。
2. 利用条件でその用途が認められている、承認済みの検索サービスまたは企業データAPIを使います。
3. 情報源の正規URLと取得日を添えた、構造化された情報を返します。会社の規模や同一性を確認できない場合は、不明のままにします。

ツールの説明です。エージェントはこれを読み、呼び出す場面を判断します：

リードの企業について、利用を許可された公開情報を取得します。入力：会社名とメールドメイン。出力：情報源のURLと取得日を添えた確認済み情報、および曖昧な点／エラー。情報源がない状態で、企業の同一性、規模、ニュースを推測しないでください。

ツール2：score_lead

次の処理を行う、決定論的な検証ツールです：

• 提案されたスコアを受け取り、データ型、範囲、必須の根拠、許可されたラベルを確認します。
• 検証エラー、または正規化済みのスコアオブジェクトを返します。
• データベース、スプレッドシート、CRM、メールなどへの書き込み権限は持ちません。

エージェントの最終出力が、サーバー側にある同じスキーマの検証に合格した後でだけ保存してください。

ツールの説明：

提案されたリードスコアを、保存せずに検証します。入力：fit_score、intent_score、urgency_score、rationale。出力：{valid, errors, normalized_scores}。このツールはレコードを書き込んだり、メッセージを送ったりできません。

ツール3：draft_response

リードの補足情報とスコアを受け取り、相手に合わせたメールの返信案を作るサブワークフローです。このサブワークフローから、専用の作成用プロンプトを設定した別のAIノードを呼び出します：

B2Bの問い合わせに対し、相手に合わせた返信案を作成してください。入力：元のリードメッセージ、企業の補足情報、適合度／購買意向／緊急度のスコア。

文体：親しみがあり、率直で、企業的な決まり文句は使わない。具体的な依頼内容に触れる。補足情報に触れるのは、その内容に情報源があり、返信に関係する場合だけにし、それ以外は省く。人による確認に向けて、次の対応案を示して終える。

長さ：80～120語。

ツールの説明：

リードに合わせたメールの返信案を作成します。入力：リードのメッセージ、企業の補足情報、スコア。出力：メールの返信案。

ツール4：propose_route

このツールは、提案された三つの振り分け先のいずれかを受け取り、提案オブジェクトとして返します。メール送信やCRMへの書き込みは行いません：

• review_priority：返信案を人による優先確認キューへ送る候補として示す。
• human_review：返信案を人による通常の確認キューへ送る候補として示す。
• log_only：外部向け操作を準備せず、振り分け結果だけを残す候補として示す。

スキーマ検証後に置く決定論的なSwitchノードで、許可された列挙値だけを受け入れ、review_priorityとhuman_reviewを承認キューへ送ります。顧客から見える変更を実行できるのは、承認ゲートを備えた別のサブワークフローだけにします。

副作用を起こさず、提案オブジェクトだけを返すサブワークフローとして実装します。Agentノードの完了後、決定論的なスキーマ検証ノードとSwitchノードが、どの分岐で提案を保存できるかを決めます。別の承認ワークフローを通らない限り、どの分岐からも送信ノードへ到達できないようにします。

ツールの説明：

振り分け先を提案します。入力：振り分け値（review_priority、human_review、log_onlyのいずれか）、スコア、根拠、返信案。出力：決定論的なスキーマ検証に使う、メモリ上の提案オブジェクト。このツールは保存、メール送信、CRM更新を行えません。

ステップ4：エージェントをテストする

エージェントを設定して四つのツールを接続したら、サンプルデータでテストします。

n8nの実行画面では、次の流れを確認できます：

1. Webhookはペイロードを受信します。
2. AIエージェントが起動します。
3. エージェントがenrich_leadを呼び出し、ツールが実行されて結果を返します。
4. エージェントが次のステップを選択します（モデルや設定によっては、中間のトレースが表示されない場合があります）。
5. エージェントがscore_leadを呼び出します。
6. エージェントがdraft_responseを呼び出します。
7. エージェントが三つの振り分け値のいずれかを指定してpropose_routeを呼び出します。
8. エージェントは最終的なJSONを返します。

問題が起きた場合は、n8nのデバッグパネルで、エージェントとツールの間のメッセージを確認できます。よくある問題は次のとおりです：

• ツールの説明が具体的でない。 モデルが、いつそのツールを使うべきか判断できません。説明を具体化してください。
• ツールの入出力スキーマが一致しない。 エージェントが正しい引数を渡せません。スキーマを明示してください。
• エージェントが無限に反復する。 処理を終えられないままツールを呼び続けます。最大反復回数を設定し、システムプロンプトを見直してください。

ステップ5：安全制御を追加する

制御のないエージェントを本番で使うのは安全ではありません。実際のデータを任せる前に、次の六つの安全制御を追加します：

1. 最大反復回数。 成功した評価例で必要だった最小回数を基に、有限の上限を設定します。上限に達した場合に人による確認へ回り、途中まで実行された操作が残らないことをテストしてください。

2. すべての返信案に承認ゲートを置く。 review_priorityはキュー内の順番を変えるだけで、送信を許可するものではありません。別途承認された方針で明示的に定めない限り、顧客への連絡には、認証済みの担当者による承認を必須にします。数週間問題が起きなかったという理由だけで、安全だと判断してはいけません。

3. 外部向け操作を許可リストで制限する。 CRMツールとメールツールは、想定した条件に一致するレコードだけを操作できるように設定します。エージェントが誤った宛先へメールを送ったり、リードではない対象のレコードを作ったりするのを防ぎます。

4. ログ。 実行ごとに、保存が認められたメタデータを出力します。安定した実行ID／リードID、ワークフローとモデルのバージョン、ツール名と結果、検証結果、振り分け先、承認者、再試行回数、エラーを含めます。リードの生データ、補足情報、返信案、ツールの引数には個人情報や機密情報が含まれます。そのため、利用目的、伏字処理、アクセス権限、保存期間を別途判断する必要があります。

5. コスト上限。 エージェントの反復回数とワークフローのタイムアウトに有限の上限を設定し、モデルプロバイダー側でも支出額や利用頻度の通知・制限を設定します。n8nのプラン上限は、実行回数や機能を基準に説明されています。自分で用意したプロバイダーのAPIキーに対して、n8n Cloudが日次予算を強制するとは考えないでください。プロバイダー側の使用量を監視し、緊急停止機能をテストします。

6. 判断の責任者。 モデルはreview_priority、human_review、log_onlyのいずれかを提案できますが、最終規則を適用するのはワークフローです。振り分けの列挙値、スコアのしきい値、承認要件はプロンプトの外で管理し、確認とテストができるようにしてください。

ステップ6：本番向けに堅牢化する

動作する試作を信頼できる仕組みに近づけるための要点です：

冪等性。 Webhookの再試行や手動での再実行により、同じリードを二度処理しても、レコードやメッセージを重複作成しないようにします。読み取ってから書き込む検査は競合状態を起こしやすいため、データベースで一意のキーを原子的に確保し、後続のすべての書き込みで同じキーを使います。原子的な確保、リース、承認トークン、アウトボックスの設計も参照してください。

エラー処理。 ツールの呼び出しごとにエラー処理を加えます。補足情報を取得できない場合や企業の同一性が曖昧な場合は、不足データを明示し、人による確認へ回してください。返信案を完成させるために、相手に関する事実を捏造してはいけません。

可観測性。 平均実行時間、ツールの呼び出し頻度、各経路へ振り分けられた割合など、主要な指標を追跡します。異常な変化は問題の兆候です。

試行の確認。 同意を得て範囲を限定した試行では、実行結果を一件ずつ元のリードと照合します。入手元の種類、言語、欠落項目、曖昧な会社名、インジェクションの試行、優先度の区分を含むように試行範囲を決めてください。誤った補足情報、スコア、振り分け先、期限、返信案を記録します。固定した50件だけでは、信頼性の水準を確立できません。

実効性のある緊急停止機能。 モデルの外側で、ワークフローの実行と、副作用を伴うすべての処理を制御します。権限のある運用担当者が、再デプロイせずに新規実行と再開処理を停止できるようにしてください。無効化した状態で、キュー内と処理中の送信がどちらも止まることを確認します。停止フラグをエージェントが「確認する」だけのプロンプト指示は、緊急停止機能ではありません。

最も重要な設計判断：エージェントに何のツールを与えるか

エージェントの品質を大きく左右するのは、ツールの構成です。失敗には二つの型があります：

ツールが少なすぎる。 エージェントが仕事を完了できません。不足する機能を補おうとして、多くの場合は情報を捏造します。

ツールが多すぎる。 エージェントが迷い、誤ったツールを選んだり、探索に反復回数を浪費したりして、品質が下がります。

有効な原則は、必要最小限のツールから始め、エージェントに必要だと実証できた場合だけ追加することです。

このリード振り分けでは、選んだ四つのツールは、おおむね妥当な構成です。次のツールを追加する余地もあります：

• リードが既存顧客かを確認する「lookup_existing_customer」ツール。
• カレンダーと連携する「schedule_meeting」ツール。
• 複数言語で問い合わせを受ける場合の「translate」ツール。

ただし、ツールを増やすたびに、エージェントが行う判断も増えます。追加するツールごとに、必要性を実証してください。

応用できるパターン

同じ制御の考え方は、ほかの振り分けワークフローでも役立つ可能性があります。ただし、次のラベルと操作は、対象分野の確認なしに転用できません：

サポートチケットの振り分け。 利用を許可された顧客履歴を取得し、カテゴリと優先度を提案します。アカウント操作、安全上の対応、返金、利用権限、顧客への連絡は、方針と人による確認の対象にします。

雇用ワークフロー。 営業用のリードスコアを、面接や不採用の自動判断に転用してはいけません。雇用判断には法的リスクや差別のリスクがあります。専門性のある人事・法務担当者による確認、アクセシビリティへの配慮、偏りの評価、労働者・応募者への透明性、実質的な人の判断が必要です。

報道機関からの問い合わせ。 補足情報の取得を「lookup_publication」に置き換え、優先度に基づいて対応を振り分けます。

顧客フィードバックの振り分け。 補足情報の取得を、感情分析と製品分類に置き換えます。

調達申請。 補足情報の取得をベンダー検索に、採点を方針への適合確認に、振り分けを承認フローに置き換えます。

影響の小さい用途で再利用できる基本形は、次のとおりです。受信イベントを検証する → 利用を許可された最小限の補足情報を取得する → 構造化された提案を求める → 決定論的に検証する → 承認済みの方針または担当者に判断を委ねる → 冪等性とゲートを備えたツールで実行する。モデルは提案するだけで、重大な判断の責任者にはなりません。

エージェントを使わない方がよい場合

エージェントを使っても利点がないワークフローもあります。「必ずAを行い、次にB、その後Cを行う」のように処理が完全に決定論的なら、エージェントを使わない通常のn8nワークフローの方が速く、安く、信頼できます。

エージェントを使う価値があるのは、次のような場合です：

• 考えられる経路が非常に多い。
• 適切な経路が、厳格な規則ではなく判断に左右される。
• 複数の情報源を組み合わせて判断する必要がある。

判断の分岐が数個のif-then-elseで表せるなら、そのまま条件分岐ノードを使ってください。条件分岐では管理しきれない場合に、エージェントを検討します。

実務用に一度構築する

n8nのAIエージェントは、設定済みのツールから使うものをモデルが選べるワークフローです。本番向けの設計ではその選択範囲を制限し、重大な判断は、責任を負う人と決定論的な方針で制御し続けます。

設計が完了したと言えるのは、重複配信、不正な出力、プロバイダーのタイムアウト、承認拒否をテストし、承認なしでは送信ノードへ到達できないと確認した後だけです。構築時間、遅延、修正率、費用は、自分のインスタンスで測定してください。この記事は設定時間や本番での成果を保証しません。

まず、合成データ、または利用に同意を得た本番環境以外のレコードで構築・テストしてください。ツールの範囲を絞る、スキーマを使う、冪等性を保つ、停止規則と確認ゲートを設けるという制御パターンは再利用できます。ただし、対象分野とリスクの分析は、新しいワークフローごとにやり直します。