n8nのAIエージェントは、AI Agentノードにチャットモデル・メモリ・ツールをつないで作ります。3つのノードを結べば会話は始まりますが、業務で任せられるかは別の設定で決まります。ツールの引数をどこまでモデルに任せるか、送信や削除の前に人の承認を挟むか、会話の記憶をどこに置くか。この記事では、最小構成から$fromAI()によるツール接続、Human reviewでの承認、メモリと構造化出力、n8n 3.0で削除される旧モードまでを、2026年11月6日時点の公式ドキュメントに沿って設定例つきで示します。
まとめ：n8nのAIエージェントはツールの範囲と承認と記憶の設定で決まる
作り方の骨格は、Chat TriggerかWebhookで入力を受け、AI Agentノードにチャットモデルとツールをつなぐ形です。ツールの引数は$fromAI()でモデルに任せ、社内処理はサブワークフローに切り出して1つのツールとして渡します。
本番で外せないのは2点です。外部への送信や削除を伴うツールには、Human reviewで承認を挟む。会話の記憶は、キューモードならSimple Memoryを使わず、Postgres Chat Memoryに会話IDをキーとして保存する。3.0では旧来のReActやPlan and ExecuteなどのモードがTools Agentに一本化されるので、これから組むなら最初からTools Agentで作ってください。
AI AgentノードとChat Modelをつないで動かす最小構成
n8n自体の機能・料金・ライセンスはn8nとは？読み方・料金・商用利用の範囲と3.0で変わる始め方で整理しています。ここでは、n8nが手元で動いている前提で、エージェント部分の組み立てから始めます。
Chat TriggerとAI AgentとChat Modelの3ノードをつなぐ手順
AI Agentノード（Tools Agent）の公式ページによると、Promptの既定は「Take from previous node automatically」で、前のノードが出力するchatInputを入力に使います。Chat Triggerを起点にすれば、この既定のままで会話が成立します。
- キャンバスにChat Triggerを置く（構築中はMake Chat Publicly Availableをオフのままにする）
- AI Agentノードを追加し、Chat Triggerの出力につなぐ
- AI Agentの下側にあるChat Modelの口に、OpenAI Chat ModelやAnthropic Chat Modelをつなぐ
- 画面下のChatを開いて話しかけ、AI Agentの実行ログでモデル呼び出しを確かめる
公式ページに挙がるチャットモデルは、OpenAI・Groq・Mistral Cloud・Anthropic・Microsoft Foundryです。社内の利用規約で使えるAPIが決まっている場合は、その事業者のChat Modelノードを選びます。
OpenAIとAnthropicのAPIキーを資格情報に登録するときの分け方
APIキーは、ノードに直接書かず資格情報（Credentials）として登録します。OpenAIの資格情報ページの手順どおりに作成すると、OpenAI Chat ModelやAnthropic Chat Modelから選べるようになります。
エージェント用のキーは、他の用途と分けて発行してください。全ワークフローで1本を共有すると、暴走したエージェントの呼び出しと通常の要約処理が請求上で区別できません。エージェント用キーにだけ事業者側で月額の上限を掛けておけば、設定漏れがあっても損失は限られます。資格情報は暗号鍵で保護されるので、セルフホストでは鍵の退避も必要です。手順はn8n docker：Composeで建てる本番構成とHTTPS公開・更新・バックアップ手順に書きました。
System MessageとMax Iterations既定10を業務向けに書き換える
AI AgentノードのOptionsには、System Message、Max Iterations、Return Intermediate Steps、Enable Streamingなどが並びます。Max Iterationsの既定は10です。モデルがツールを呼んでは結果を読む往復が、10回で打ち切られます。
問い合わせの分類や下書き作成のように、ツールを1〜2回呼べば終わる業務なら、5程度に下げても困りません。往復の上限が、そのまま費用と待ち時間の上限です。反復が止まる条件の考え方はエージェントループとは？止まる条件とSDK別の反復上限を実測で解説で詳しく扱っています。System Messageには、役割・使ってよいツール・答えてはいけない話題を、箇条書きで具体的に書きます。
あなたは株式会社サンプルの社内ヘルプデスク担当です。
- 回答は日本語で、3文以内にまとめる
- 社員情報は「社員検索」ツールで確かめてから答える。推測で答えない
- 「メール送信」ツールは人の承認が必要。拒否されたら送信せず、拒否された旨と代わりの手順を伝える
- 給与・評価・人事異動の質問には答えず、人事部の窓口へ案内する3行目のように、承認が必要なツールと拒否されたときの振る舞いをここに書いておきます。理由は後のHuman reviewの章で説明します。
ツールを接続してAIエージェントに業務システムを操作させる実装
エージェントが価値を出すのは、ツールで社内外のシステムを操作できたときです。n8nでは、既存のアプリノード（Gmail・Slack・Google Sheetsなど）をそのままツールとしてAI Agentにつなげます。
$fromAI()でツールの引数をモデルに決めさせる式の書き方と制約
ツールの各項目のうち、どこをモデルに埋めさせるかを決めるのが$fromAI()です。公式の解説ページでは、引数はkey・description・type・defaultValueの4つで、keyは1〜64文字の英数字・アンダースコア・ハイフン、typeはstring・number・boolean・jsonから選び、省略時はstringです。
# Gmail ツールの「To」欄：宛先は社内ドメインに固定し、ローカル部だけをモデルに決めさせる
{{ $fromAI("recipient_local", "宛先社員のメールアドレスの@より前", "string") }}@example.co.jp
# 「Subject」欄：固定の接頭辞を付ける
【自動送信】{{ $fromAI("subject", "30字以内の件名", "string") }}
# Google Sheets ツールの数量欄：数値として受け取り、既定値を1にする
{{ $fromAI("quantity", "発注数量。指定が無ければ1", "number", 1) }}宛先をまるごと$fromAI()に任せると、プロンプトに紛れ込んだ外部アドレスへ送る余地が残ります。固定できる部分は式の外に出し、モデルに渡すのは必要最小限の項目にします。なお、$fromAI()はTools Agentにつないだツールでのみ動き、Codeツールやツール以外のサブノードでは使えません。
Call n8n Workflow Toolでサブワークフローを1つのツールとして渡す
社員マスタの検索や在庫の引当のように、複数ノードを順に通す処理は、サブワークフローにまとめてCall n8n Workflow Toolで渡します。サブワークフローはExecute Sub-workflow Triggerで始め、入力項目を定義しておきます。JSON例で定義する場合は次のような形です。
{
"employee_id": "E12345",
"fields": "name,department,manager"
}入力を「Accept all data」にすると、呼び出し側のWorkflow Inputsに項目が出ず、$fromAI()で値を割り当てられません。項目は必ず定義します。もう1つ詰まりやすいのが公開状態です。Source を Database にしたサブワークフローは公開しておかないと、本番実行でWorkflow is not active and cannot be executedというエラーがツールの結果としてエージェントに返ります。Description 欄には「社員IDから氏名・部署・上長を返す。退職者は返さない」のように、いつ使うツールかを書きます。モデルはこの文を読んでツールを選びます。
HTTP RequestやMCP Client Toolで社外APIをつなぐ範囲指定
専用ノードの無いAPIは、HTTP RequestノードをAI Agentのツール入力につないで呼びます。3.0では旧来のHTTP Request Toolノードが削除され、この形に一本化されます。
MCPサーバーを持つサービスなら、MCP Client Toolで接続できます。認証はNone・Bearer・Header・Multiple Headers Auth・OAuth2から選び、Tools to IncludeでAll・Selected・All Exceptを指定します。業務用のエージェントでは、Allを選ばずSelectedで読み取り系のツールだけを渡すのが安全です。書き込み系を渡すなら、次章の承認を必ず挟みます。MCPサーバー側の作り方と認可の設計はMCPサーバーの作り方とAIエージェントへの接続手順にまとめています。
送信や削除の前に人の承認を挟むHuman reviewの設定と運用
AIエージェントを業務に入れるとき、最初に問われるのは「勝手に送らないか」です。n8nには、特定のツールを実行する前に人の承認を必須にする仕組みが用意されています。
Human reviewでSlackやChatへ承認依頼を送る設定手順
Human-in-the-loop for toolsの公式ページの手順は次のとおりです。
- AI AgentノードのToolsコネクタをクリックし、Tools Panelを開く
- Human reviewのセクションで承認チャネルを選び、資格情報を設定する
- 承認が必要なツールを、Human reviewのステップのツールコネクタにつなぐ
承認チャネルは、n8n内蔵のChat、Slack、Discord、Telegram、Microsoft Teams、Gmail、WhatsApp Business Cloud、Google Chat、Microsoft Outlookの9種です。承認されるとAIが指定した入力でツールが動き、拒否されると実行は取り消され、拒否された事実がAIに伝わります。利用者とはn8nのChatで会話し、承認依頼だけをSlackの上長に送る、という分け方もできます。
$tool.nameと$tool.parametersで承認者に見せる文面を組み立てる
承認依頼の文面には、呼び出そうとしているツール名の$tool.nameと、渡そうとしている引数の$tool.parametersを差し込めます。$fromAI()でモデルが決めた値もここに含まれるため、承認者は「誰に何を送ろうとしているか」を見て判断できます。
AIエージェントが「{{ $tool.name }}」を実行しようとしています。
渡す値：
{{ JSON.stringify($tool.parameters, null, 2) }}
内容を確認し、問題なければ承認してください。公式ページは、承認が必要なツールと拒否時の扱いをSystem Messageに書くよう警告しています。書いておかないと、拒否された後にモデルが同じツールを言い換えて呼び直したり、送信できたかのような返答をしたりします。前章のSystem Messageの3行目が、その対策です。承認は全ツールに掛けることも、個別のツールだけに掛けることもできます。公式も、最初は承認を広く掛け、信頼が積み上がってから外していく運用を勧めています。
会話の記憶と出力形式を固めてAIエージェントを本番の業務フローへ載せる手順
本番で会話がつながらない、後続ノードが返答を読めない。この2つはメモリと出力形式の設定で防げます。
Simple MemoryとPostgres Chat Memoryの違いとキー設計
Simple Memoryの公式ページは、キューモードの本番ワークフローでは使わないよう明記しています。呼び出しのたびに同じワーカーへ届く保証が無いためです。ワーカーを分ける構成なら、Postgres Chat Memoryを選びます。Table Nameで指定したテーブルが無ければ自動で作られ、Context Window Lengthで何往復分を文脈に含めるかを決めます。
会話を分ける鍵がSession Keyです。Chat Triggerから入るなら、その出力のsessionIdを使います。Webhookから入るなら、呼び出し側が送る会話IDを{{ $json.body.sessionId }}のように指定します。サブノードの式は常に先頭アイテムに解決される点に注意してください。複数件をまとめて流すと、全件が1件目の会話として記録されます。Chat TriggerでLoad Previous SessionをFrom Memoryにする場合は、Chat TriggerとAI Agentの両方に同じメモリノードをつなぎます。
Structured Output ParserでJSONを返させ後続ノードへ渡す設定
エージェントの返答をIFノードやGoogle Sheetsに渡すなら、文章ではなくJSONで返させます。AI AgentのRequire Specific Output Formatをオンにし、Structured Output Parserをつなぎます。Schema TypeはGenerate from JSON ExampleとDefine using JSON Schemaの2つです。
{
"type": "object",
"properties": {
"category": { "type": "string", "enum": ["請求", "障害", "契約", "その他"] },
"priority": { "type": "integer", "minimum": 1, "maximum": 3 },
"reply_draft": { "type": "string" }
},
"required": ["category", "priority"]
}JSON例から生成すると、すべての項目が必須の扱いです。任意項目を持たせたいときや、enumで値を絞りたいときは、上のようにJSON Schemaで書きます。$refによる参照には対応していないので、定義は1つのオブジェクトの中に展開します。
Webhookから会話IDを渡してcurlで動作を確かめる検証手順
社内システムからエージェントを呼ぶ構成では、Chat Triggerの代わりにWebhookノードを起点にします。AI AgentのPromptをDefine belowにして{{ $json.body.message }}を指定し、WebhookのRespondをWhen Last Node Finishesにすると、返答がHTTPの応答で戻ります。
# テスト用URL（エディターで「Listen for test event」を押してから送る）
curl -s -X POST "https://n8n.example.co.jp/webhook-test/helpdesk-agent" \
-H "Content-Type: application/json" \
-d '{"sessionId":"ticket-20261106-001","message":"先月分の請求書を再発行したい"}'
# 同じ sessionId で続けて送り、前の発言を覚えているかを確かめる
curl -s -X POST "https://n8n.example.co.jp/webhook-test/helpdesk-agent" \
-H "Content-Type: application/json" \
-d '{"sessionId":"ticket-20261106-001","message":"送付先はさっきと同じでいいです"}'2回目の返答が1回目の文脈を踏まえていれば、Session Keyは正しく効いています。踏まえていなければ、Session Keyの式と、メモリノードがAI Agentにつながっているかを見直してください。チケットIDなど業務上の識別子を会話IDに使えば、問い合わせ単位で履歴を追えます。
n8n 3.0で削除される旧エージェントモードと移行前に確かめる項目
n8n公式ブログの3.0発表によると、3.0の安定版は12月初旬の予定で、2.x系は安定版の公開後12か月、セキュリティ修正と重大なバグ修正だけが続きます。2026年11月4日時点の最新安定版は、GitHubのリリース一覧で2.46.6です。
ReActなど旧モードがTools Agentへ一本化される影響と対処
v3.0のBreaking changesは、AI Agentノードのversion 1と、次のモードの削除を挙げています。
| 3.0で消えるもの | 移行先 |
|---|---|
| ReAct・Conversational | Tools Agent |
| OpenAI Functions | Tools Agent |
| Plan and Execute | Tools Agent |
| SQL Agent | Postgres・MySQLのツール |
| HTTP Request Tool（旧） | HTTP Requestノードをツールに接続 |
| Manual Chat Trigger | Chat Trigger |
| MotorheadとZepのメモリ | 直接の代替なし |
Tools Agentで組んだワークフローは、3.0でも動作が変わりません。古いテンプレートを取り込んで作ったエージェントは、モードの欄を確認してください。ReActなどのままなら、2.x のうちにTools Agentへ作り直し、同じ入力で返答と呼ばれるツールが変わらないかを比べておきます。
Chat Hubの既定オフとMigration Reportで洗い出す移行対象
3.0では、エージェントと会話する画面だったChat Hubが既定でオフになり、4.0で削除される予定です。継続利用するには環境変数N8N_ENABLED_MODULESにchat-hubを加えます。経緯と移行先はn8n Chat Hubの使い方と3.0で既定オフになる前の対応にまとめました。
影響を受けるワークフローは、2.39以降で使えるSettingsのMigration Reportで一覧にできます。上げる前にここを確認し、旧モードのAI Agentと削除対象のノードを先に片付けておけば、当日の作業はイメージの更新だけで済みます。
n8nでAIエージェントを組むべき業務とコードで実装すべき場面の境界
既存の業務フローにLLMの判断を1か所差し込むなら、AI Agentノードは手軽です。エージェント自体が製品の中核になるなら、コードで書くほうが管理しやすくなります。
問い合わせの分類や下書き作成などn8nのAI Agentノードが向く業務
向いているのは、入力と出力の形が決まっていて、ツールが数本で足りる業務です。問い合わせメールを分類して担当へ回す、議事録から次の作業を抜き出して表に書く、申請内容を規程と照らして差し戻し文の下書きを作る、といった処理がこれに当たります。どれも、出力をStructured Output Parserで固定し、外部への送信だけをHuman reviewで止めれば、担当者は承認ボタンを押す役に回れます。
業務のどこにエージェントを入れると効果が出るかの見極めは、AIエージェントで業務効率化できる領域と効果の測り方を参考にしてください。既存のRPAやn8nのフローにエージェントを組み込む設計から任せたい場合は、一創のRPA×AIエージェント連携（インテリジェントオートメーション）で要件の整理から対応しています。
反復上限や評価の要件が厳しくn8nでの実装を見送るべきケース
次のどれかに当てはまるなら、n8nでのエージェント実装は見送り、SDKを使ったコードで書きます。
- ツールが20本を超え、呼び出す順序や条件分岐をテストコードで固定したい
- 返答の品質を毎回の変更ごとに数百件の評価データで回帰確認したい
- エージェントを自社サービスの機能として顧客に提供する
n8nのワークフローはキャンバス上のJSONとして管理され、ツールの選ばれ方をユニットテストで縛る仕組みは標準にありません。評価の設計はAIエージェント評価とは？軌跡・ツール呼び出し・タスク達成を測る指標で扱っています。3番目はn8nのライセンス条件にも関わるので、商用利用の範囲も先に確かめてください。
よくある質問：n8nのAIエージェントで多いモデル選び・無料利用・承認の疑問
n8nでAIエージェントを作るときに、よく聞かれる質問をまとめました。
n8nのAIエージェントは無料で作れますか？
n8n本体はセルフホストのCommunity Editionなら無料で、AI Agentノードも含まれます。ただし、チャットモデルの利用料はOpenAIやAnthropicなど各事業者へ別途支払う形です。費用はモデルの単価と1回の会話でツールを往復する回数でほぼ決まるので、Max Iterationsを業務に合わせて下げておくと見積もりが立てやすくなります。
ローカルLLMをn8nのAIエージェントに使えますか？
使えますが、ツール呼び出しに対応したモデルを選ぶ必要があります。Tools Agentは、モデルがツールの一覧を受け取り、どれを呼ぶかを自分で決める方式だからです。非対応のモデルでは、ツールが一度も呼ばれないか、引数の形式が崩れます。まずクラウドのモデルで動く形を作り、同じ入力でローカルモデルに切り替えて差を確かめてください。
AIエージェントが同じツールを何度も呼び続けるのはなぜですか？
ツールの結果からモデルが「まだ足りない」と判断し続けているためです。多くはツールのDescriptionが曖昧で、何が返れば完了なのかがモデルに伝わっていません。Descriptionに返す項目と、見つからない場合の返り値を書き、System Messageに「結果が空なら探し直さずにその旨を答える」と加えます。上限はMax Iterationsで切れますが、既定の10回まで回ると費用も待ち時間も膨らみます。
Human reviewで承認待ちのまま放置されるとどうなりますか？
ワークフローは承認か拒否が届くまで一時停止したままです。承認者が不在だと処理が進まないため、承認先は個人ではなく当番のチャンネルにし、毎朝未処理の依頼を確認する運用を決めておきます。急ぎの業務で人の待ち時間が許されないなら、そのツールはエージェントに渡さず、通常のワークフローで決まった条件のときだけ動かす形に戻すことを検討します。
Difyとn8nのどちらでAIエージェントを作るべきですか？
起点が業務システムの連携ならn8n、LLMアプリの画面やナレッジ検索が中心ならDifyが向きます。n8nはSaaSや社内APIをつなぐノードが豊富で、エージェントはその流れの一部です。Difyはチャット画面とナレッジの管理を最初から持ち、アプリとして公開するまでが短く済みます。DifyのアプリからWebhookでn8nのワークフローを呼ぶ併用構成も取れます。
関連記事
- n8nとは？読み方・料金・商用利用の範囲と3.0で変わる始め方：n8nの機能・料金・ライセンスの全体像と、導入方法を確認できます
- n8n docker：Composeで建てる本番構成とHTTPS公開・更新・バックアップ手順：エージェントを載せるセルフホスト環境の構成と、キューモードへ進む条件を扱っています
- n8n Chat Hubとは？使い方・ワークフローのエージェント化と3.0で既定オフになる前の対応：作ったエージェントを社内向けチャット画面で使う方法と、3.0での扱いが分かります
- エージェントループとは？止まる条件とSDK別の反復上限を実測で解説：Max Iterationsの背景にある反復と終了条件の考え方を整理しています
- AIエージェントの作り方とは？ノーコード・開発・外注の3ルートと設計手順：n8nのようなノーコードと、開発・外注のどれを選ぶかの判断材料になります
