n8nのAI Agentノードを2週間ちゃんと使ってみた結論から先に書く。「LLMを繋ぐだけで自律実行できる」は半分本当で半分ウソだった。
できることはたしかにある。でも「繋げば動く」と思って組み始めると、だいたい最初の2〜3日でツール設計の罠にはまる。僕は1回の実行で6,000トークン以上消費するエージェントを作ってしまって、「これ毎日動かしたら1ヶ月でいくらかかるんだ」と焦った経験がある。
この記事では、AI Agentノードを実際に試してわかった「できること」「できないこと」「実務で使える条件」を全部書く。
この記事でわかること：
- n8n AI AgentノードとLLMを接続する仕組みの整理
- 実際に試してわかった「できないこと」3つ
- 実務で使える場面・使えない場面の判断基準
n8n AI Agentノードで何ができるのか、先に結論を言う
普通のn8nワークフローは「決まった手順を決まった順番で実行する」もの。Gmailを受信したらSlackに通知、みたいな処理。ここにAIは必要ない。
AI Agentノードが違うのは「LLMが自分で判断してツールを呼ぶ」という点だ。
たとえばSlackで「先週の問い合わせの件数を集計して」と話しかけると、エージェントが「Google Sheetsからデータを取ってくる必要があるな」と判断して、Sheetsのツールを呼び出して、結果を受け取って、「件数は47件でした」と回答する。この判断→実行→回答のループを自動でやってくれるのが要点だ。
普通のワークフローとAI Agentノードの違いはここ
普通のワークフロー：手順が事前に固定されている。ノードを自分で繋いで「この順番でこれを実行する」と明示的に設計する。
AI Agentノード：手順を自分で考える。「何をすべきかは自分（LLM）が判断する」という設計。ユーザーの入力に応じて、どのツールをいつ呼ぶかを都度決める。
正直、最初にこの違いを把握していないと「AI Agentって結局どこで役立つんだ」と思い続けることになる。手順が毎回変わる・ユーザーの問いに応じて柔軟に動かしたい場面には向いている。逆に、毎回同じ手順でいい処理にAI Agentを使うのは過剰投資だ。
「LLMが自分で判断してツールを呼ぶ」という仕組みを整理する
内部ではReActループというものが回っている。LLMが「どのツールを使うか」を考えて（Reason）、ツールを呼び出して（Act）、結果を受け取って、また考えて、という繰り返し。これが自律実行に見える動作の正体だ。
対応LLMはOpenAI（GPT-4o等）、Anthropic Claude、Google Gemini、Ollama（ローカルLLM）など。自分はGPT-4oとClaude 3.5 Sonnetを試した。動作の安定感はClaude 3.5 Sonnetの方が若干上だったが、日本語の理解精度はどちらも同じくらいだった。
AI Agentノードを使う前に知っておきたいこと
実際に試し始める前に、一度整理しておきたい話がある。
AI Agentノードは「n8n LangChain統合」の一部として動いている。LangChainはAIエージェントを構築するためのPythonライブラリで、n8nはこれをノーコードで使えるように包んでいる。つまり内部的には、LangChainのエージェントが動いていると思って差し支えない。
現時点（2026年4月）で使えるエージェント種別は主に以下：
- Conversational Agent：会話の流れを保持しながら対話するタイプ
- Tools Agent：ツール呼び出しに特化。最も汎用的
- ReAct Agent：推論→行動を繰り返すタイプ。複雑なタスクに向く
- SQL Agent：SQLデータベースを自然言語で操作するタイプ（ただし後述の制限あり）
自分が2週間でメインに使ったのはTools AgentとReAct Agentの2種類だ。
セルフホストで使う場合、現在OpenAIとAnthropicのどちらのAPIキーを持っていても接続できる。自分はVPS（月800〜1,500円）でn8nをセルフホストしており、APIキーの費用は別途かかるがクラウド版のサブスク代（Starterで月20€）は不要なのでトータルコストは安く抑えられている。
実際に組んでみた構成と動いた結果
最初に組んだのは「Slackで自然言語の問いかけ→Google Sheetsから月次データを取得→集計して返答する」エージェントだ。
構成はシンプル：
- Slack Trigger（メッセージを受信）
- AI Agentノード（GPT-4oに接続）
- Google Sheets Tool（データ取得）
- Slack Tool（返答送信）
普通に手動でノードを繋いで作ると、条件分岐・データ変換・エラーハンドリングを含めると15〜18ノードになるような処理が、AI Agentを使うと5ノードで動いた。これは正直すごいと思った。
問題はそこからだ。
最初にハマったのはツールの渡し方だった
「賢くなるかも」と思って最初にツールを7個渡した。Google Sheets × 3シート、Gmail取得、Slack送信、Notion更新、カレンダー確認。
1回実行するたびにトークン消費が5,000〜8,000になった。LLMが「今回は何のツールを使うべきか」を考えるためにツール一覧をコンテキストに突っ込むので、ツール数が増えるほど毎回のオーバーヘッドが増える。
さらにまずかったのが、ツールの実行結果がそのままLLMのコンテキストに追加されていくことだった。1回目の実行結果が残り、2回目の結果も残り、会話を繰り返すほどコンテキストが膨れ上がる。5〜6回やり取りした時点でトークン消費が1回10,000超えになっていて、「これ続けたら1ヶ月で数万円いくぞ」と気づいた。
解決策として、ツール数を3個以内に絞ること、ツールのレスポンスを前処理（Codeノード）で圧縮してからエージェントに渡すことで、1回の実行を1,000〜2,000トークン程度に落とせた。ただし、この設計を最初から知らないとほぼ確実にはまる。
GPT-4oを繋いだときに起きたこと
GPT-4oで組んだエージェントがなぜかループから出てこないことがあった。ツールを呼び出して結果を受け取っても、また別のツールを呼び出してを繰り返す。「最大イテレーション数」の設定をしていなかったのが原因で、n8nのAI Agentノードにはデフォルトで上限を設定しないと無限ループになるリスクがある。
やってみてわかった「できないこと」3つ
期待値と実際のギャップが大きかったのは以下の3点だ。
ツールの結果がトークンを食い続ける問題
上でも書いたが、これが一番の落とし穴だった。特にRAGやWebスクレイピングのツールを組み込むと、返ってくるデータが大量のメタデータを含む。Googleの検索結果をツールで取得すると groundingMetadata、webSearchQueries、domainUri みたいな不要なフィールドが何十行もコンテキストに追加される。
設計として正しいのは「ツール→前処理（不要フィールドを削除・圧縮）→AI Agent」という流れにすること。最初からこの設計で組めば問題ないが、「ツールを繋ぐだけで動く」という期待で入ると必ずここにぶつかる。
動的なSQL・クエリの生成はほぼ無理だった
SQL Agentというエージェント種別があるが、SQLは固定値でしか設定できない。「AIがSQLを動的に生成してDBに渡す」という使い方はできなかった（2026年4月時点）。
同じ理由で、「状況によってAPIのクエリパラメータを変えながら複数回取得する」という処理も、ツールの設計次第では動かないことがあった。ノーコードの範囲内で動的なデータ操作をやらせようとすると、どこかで制約に当たる。
ループが止まらないケースがある
最大イテレーション数を設定していないと、エージェントが無限にツールを呼び続ける可能性がある。特に「完了条件」が曖昧なタスクでは起きやすい。「全部のデータを処理して」という指示でループを回すと、何をもって「全部」とするかをLLMが間違えることがある。
対策として「最大ループ数：10」などの上限を必ず設定すること、タスクの完了条件を具体的にシステムプロンプトに書くことが必要だ。
n8n AI Agentが実務で使えると思うケース、使えないと思うケース
2週間使って、自分なりに判断基準ができてきた。
使えると思うケース：
- ツール数が3個以内で、各ツールのレスポンスが軽い場合
- 「自然言語で問いかけて、決まったデータソースから答えを引き出す」チャットボット的な用途
- ユーザーの問いかけ内容によって毎回処理が変わるが、使うツールの種類は固定されている場合
- 実行頻度が1日数回程度（トークンコストが許容できる範囲）
使えないと思うケース：
- 大量のツールを「とりあえず全部渡せば賢くなる」という設計
- リアルタイム処理（複雑な構成だと1回の実行に5〜15秒かかることがある）
- 動的なSQL生成など、ツールが動的なクエリを受け付けない場合
- 毎回まったく同じ手順でいい処理（普通のワークフローの方がシンプルで速い）
「全部AIに任せれば自動化できる」というイメージで入ると期待を裏切られる部分がある。設計次第では確実に使えるが、「繋ぐだけで動く」はそのままでは成立しない。ツール設計・トークン管理・ループ制御の3つを理解した上で使うと、かなり強力なツールになる。
ちなみにMakeにAI Agentはない
n8nを使う理由の一つとして、Makeには現時点でAI Agentノードに相当するものがない。MakeはAIステップ（OpenAI接続など）はあるが、「LLMが自分でツールを選んでReActループを回す」という仕組みは持っていない。AI Agentっぽいワークフローを組みたいなら、現状n8nを選ぶのが自然な選択肢になる。
自分はMakeとn8nを両方使っているが、「通知・ファイル保存・フォーム処理」といった決まり切ったシナリオはMake、「LLMを絡めた処理・動的な判断が必要な処理」はn8nという使い分けが今のところしっくりきている。
セルフホスト版でもAI Agentノードは使える
気になる人がいると思うので補足すると、n8nのセルフホスト版（Community Edition）でもAI Agentノードは使える。クラウド版限定の機能ではない。APIキーさえ設定すれば、n8nの公式ドキュメントを参照しながら同等の構成が組める。
ただし、クラウド版に比べてドキュメントやサポートが薄い部分はある。特にAI Agentノード系のエラーは、コミュニティフォーラムで情報を探しながら解決することになるケースが多かった。
トークン消費の設計について詳しく知りたい場合は、DevelopersIOのAI Agent設計改善記事が参考になった。Classmethod社のエンジニアがトークン爆発を解消した手順を丁寧にまとめている。また、Zennのn8n AI Agent比較検証記事も手動実装との差を具体的に示しており、設計の比較検討に役立った。
まとめ：「繋ぐだけで動く」は半分本当、半分ウソ
2週間試した率直な感想を書く。
n8n AI Agentノードは、ちゃんと設計すれば確かに便利だった。手動で15〜18ノード必要だった処理が5ノードで動いたのはインパクトがあった。「LLMが判断してツールを呼ぶ」という仕組みは本物で、ちゃんと動く。
ただ、「LLMを繋ぐだけで賢く自律実行してくれる」という期待通りではなかった。トークン管理・ツール設計・ループ制御を理解しないで組み始めると、1回の実行コストが想定の3〜5倍になることがある。
設計が悪いと自動化したはずなのに毎月のAPI費用が増え続けるだけという状況になる。設計が正しければ、工数も費用も手動より大幅に削減できる。この差がすごく大きい。
を使う場合、まずはツール数を絞った小さな構成から試して、動作とトークン消費を確認してから拡張するのが現実的なやり方だと思う。n8nのセルフホスト環境があるなら、APIキーの費用だけで試せるのでリスクは低い。
「試す価値はある。ただし、繋ぐだけで動くとは思わないこと。」
これが2週間使って出した評価だ。
なお、この記事では「人間が途中で承認を挟む」承認フロー（Human-in-the-loop）には触れていない。それについては別の記事に書いているので、承認フロー設計に興味がある方はそちらを参照してほしい。また、OllamaなどのローカルLLMを使ってAPI費用をゼロにする構成については、No.53の記事で詳しく扱う予定だ。
合わせて読みたい
コメント