n8n AIエージェントはワークフローと何が違う？実測で選び方を検証

条件をそろえた30回のサポート対応では、どちらの構成も同じ20件を完了しました。ただし、新しい n8n Agent は範囲を限定したワークフローを40回呼び出し、20件の会話セッションを保持しています。n8n AIエージェントとワークフローを比べるとき、重要なのはどちらが多く自動化できるかではありません。手順が決まっているならワークフローを中心に据え、会話の内容に応じて次の一手を決める必要がある場合だけ Agent を使うのが正解です。

n8n AIエージェントとワークフロー：結論

実行前に手順を描けるなら、n8n ワークフローを選びます。次に取るべき行動が、相手の発言、ツールの返答、またはそれまでの会話内容によって変わるなら、n8n Agentの出番です。本番のサポートや運用では、Agent が判断し、用途を絞ったワークフローが処理を担うハイブリッド構成が、多くの場合もっとも堅実です。

自動化のどこかでモデルを使っているかどうかより、この違いのほうが重要です。ワークフローはモデルを呼び出しても決定論的なまま運用できます。一方、Agent はワークフローを呼び出しても、キャンバスではなくモデルが次のツールを選ぶため、エージェント型の動作を保ちます。

判断基準はシンプルです。次の一手を誰が決めるべきかを考えてください。答えが自動化の設計者なら、ワークフローに主導権を持たせます。現在の会話とツールの結果を読んだモデルなら、Agent を使います。n8n も発表資料で同じ考え方を示しています。手順が固定された処理はワークフローに、手順をあらかじめ決められない依頼は自ら進め方を考える Agent に向いていると、n8nの発表記事では明確に説明されています。

9月25日のアップデートで何が変わったのか

n8n は2026年9月25日、新しい Agents 画面を公開しました。Agent は独立したプロジェクト成果物となり、専用のモデル、指示、ツール、メモリ、セッション、ドラフト、公開版、チャネル、スケジュールを持ちます。特定のキャンバス内に置かれるのではなく、ワークフローと並んで存在します。現在のn8n Agentsドキュメントでは、固定ワークフローでは対応しきれない、手順の定まらない仕事を扱う場所と説明されています。

この共通の実体を持てる点こそ、今回の変更の価値です。同じ公開済み Agent が、チャネルで応答し、スケジュールで動き、別のワークフローからメッセージを受け取れます。セッション履歴には、会話、ツール、出力、エラー、保留中の承認が記録されます。ドラフトを編集しても、公開版が知らないうちに変わることはありません。

それでも、すべてのシステムへ広範にアクセスできる権限をモデルに渡すべきではありません。ワークフローツールなら、名前付きの入力、管理された認証情報、既知の出力、必要に応じた承認境界という、狭い操作契約を与えられます。初期利用者の反応にも要点がよく表れていました。新たなチャット画面を増やすより、既存のワークフローをツールとして再利用できることに価値があります。

n8n AI Agent Workflow Builderで変わったこと

従来は、Chat Trigger、メモリ、AI Agent node、モデル、ツールを組み合わせ、ワークフロー内にエージェントを構築していました。この方法は現在も利用できます。新しいビルダーでは、永続的な Agent の実体、セッション、バージョン、複数の入口が、共通の成果物へ移されました。

単なるエディターの見た目の変更ではありません。役割の持ち方が変わります。

• Agent が会話とツール選択のループを管理します。
• 公開済みワークフローが、アカウント照会や返信文の下書きといった範囲の明確な処理を担います。
• Agent に作業が届くタイミングは、呼び出し元のチャネル、スケジュール、またはワークフローが管理します。
• 機密性の高いツールを最終的に実行するかどうかは、承認者が決めます。

n8n AgentsとAI Agent nodeの違い

既存のAI Agent nodeは、今もワークフローのノードです。チャットモデルと少なくとも1つのツールに接続され、そのワークフローの実行中に使用するツールを選びます。n8n は、既存の AI Agent node を使った構成も引き続き動作すると説明しています。現行のノードドキュメントにも、モデルとツールを組み合わせる設計が記載されています。

エージェントが1つのワークフローに属し、そのワークフローでトリガー、メモリ構成、ライフサイクルを管理したい場合は、AI Agent node が適しています。複数の会話にまたがって同じ実体を維持したい場合や、複数の場所から呼び出したい場合は、新しい Agent を使います。移行は任意であり、既存のノード型エージェントを動かし続けるための必須条件ではありません。

同じサポート業務を2通りで構築して比較

比較には、使い捨てのローカル n8n 2.40.7環境、決定論的に応答するOpenAI互換のローカルモデルエンドポイント、固定JSONフィクスチャを使用しました。これはルーティングとオーケストレーションのテストであり、モデル品質やクラウド遅延のベンチマークではありません。

n8n AIエージェントの例：サポート振り分け

フィクスチャには、架空のサポートチケット20件を収録しました。

• 10件は、チケットID、アカウントID、製品領域、問題内容を含む固定形式で届きます。
• 残りの10件は、意図的にアカウントIDと製品領域を省き、有効な回答を得るには1回の追加質問が必要な状態にしました。
• 最終的な振り分け先はすべて、billing、technical、generalのいずれかに固定しました。

どちらの構成にも、同じ30回のユーザー発言を処理させました。情報がそろった10件は、それぞれ1ターンで完了します。不完全な10件では、最初の質問と1回の追加回答が必要となり、さらに20ターンを使いました。

1. 1

   固定手順を構築する

   ワークフローは3つのノードで構成しました。Webhookがチケットを受信し、共通のローカルモデルが分類し、パーサーが構造化JSONを返します。すべての受信メッセージが、この順序で同じノードを通ります。

2. 2

   Agentを構築する

   Agent には、同じモデル、明示的な振り分け指示、保存済みセッションメモリ、公開済みの3つのワークフローツール（Get Account Context、Draft Support Reply、Page On Call）を設定しました。最初の2つは直接利用でき、Page On Call は承認を必須にしました。

3. 3

   完了した処理を採点する

   期待した最終キューが出力に含まれた場合のみ、そのケースを完了と判定しました。確認質問、実行、セッション、モデルエンドポイントへのリクエスト、ワークフローツールの呼び出し、失敗、不要な操作は、それぞれ分けて記録しました。

どちらの構成も、最終的な20件すべてを期待どおりのキューへ振り分けました。この結果から、Agents とワークフローの判断力が同等だとは言えません。今回のスタブは、オーケストレーションだけを切り分けて調べるため、意図的に決定論的な動作にしています。違いは、追加処理がどこで発生するかです。固定ワークフローは1ターンにつき1回モデルへリクエストしました。一方の Agent は、ツールの選択、ツール結果の取り込み、応答の生成、実行状態の維持のため、モデルを繰り返し呼び出しました。

Agent が行った100回のエンドポイントリクエストは、このローカル環境では、ストリーミングによる推論またはツールループが70回、非ストリーミングの補助リクエストが30回でした。これはプロバイダー利用量を計測すべきという警告であり、普遍的な倍率ではありません。モデル、メモリ構成、プロンプト、製品バージョンが変われば、この数も変わります。

n8n Agentを使うべき場面

会話によって計画が変わるなら、Agent を使います。「請求がおかしい」というサポート依頼でも、アカウント照会、確認質問、ポリシーの確認、操作前の承認が必要になる場合があります。不足情報が届くまでは、正しい分岐を決められません。

すでに計画が決まっているなら、ワークフローを使います。夜間エクスポート、WebhookからCRMへの同期、リード情報の拡充といった処理では、明示的なノード、予測しやすい再試行、モデルの判断を再構成しなくても確認できる実行経路が強みになります。

制御とデバッグはワークフローが優位

次に進み得るノードがキャンバス上に並ぶため、ワークフローのほうが動作を把握しやすくなります。決定論的な処理で障害が起きても、実行履歴を見れば失敗したノードが分かります。送金、レコード削除、権限変更など、柔軟性が利点よりリスクになりやすい処理では、これを基本設計にすべきです。

Agent のセッションには、別の種類の追跡情報が残ります。メッセージ、ツール選択、出力、エラー、承認です。これは役立ちますが、確率的な判断が宣言済みのグラフに変わるわけではありません。手順を変える必要がないなら、推論ループを加えても障害要因が1つ増えるだけです。

会話と状態管理はAgentが優位

複数ターンにまたがる仕事では、Agent に分があります。セッションは保存して再開でき、セッションメモリは標準で有効です。フィクスチャでは、不完全だった10件のチケットにアカウントと製品の不足情報が届くと、それぞれ元のセッション内で処理を続けました。固定ワークフローが同じ回答を出せたのは、追加メッセージに、状態を持たない分類器でも処理できるだけのコンテキストを再掲していたからです。

実際のサポート業務では、この差がさらに広がります。2通目のメッセージが「EUのアカウント」としか書かれていない場合、ワークフローは以前のチケットをデータストアから再取得するか、入力で履歴を受け取る必要があります。Agent のセッションには、すでに会話のコンテキストがあります。エピソード記憶ならセッションをまたぐこともできますが、現在この機能にはOpenAIの認証情報が必要です。

機密性の高い操作はワークフローが優位、前段にはAgent

もっとも安全なハイブリッド構成では、読み取り専用ツールは Agent に自由に使わせ、副作用のある操作には承認を設けます。緊急チケットを使った別のスモークテストでは、Agent が読み取り専用のアカウント照会を終え、Page On Call を選択した時点で処理を一時停止しました。承認者がツール呼び出しを受け入れるまで、ページング用ワークフローは動きませんでした。

これが適切なセキュリティモデルです。Agent は操作を提案または要求できますが、影響範囲を管理するのは、用途を絞ったワークフローと明示的な承認です。認証情報はツールに紐づくため、あらゆる操作が可能な1つの強力な認証情報を Agent に渡す必要はありません。

総合的にはハイブリッドが優位

新しい画面は、ワークフローの代替ではなく、ワークフローを束ねる会話型のコントロールプレーンとして使うときに真価を発揮します。Agent が解釈し、質問し、選択します。ワークフローは入力を検証し、システムを変更し、構造化された結果を返します。この分担なら、操作を選ぶモデルとは切り離して、各処理を個別にテストできます。

n8n Agentsの実行コスト

2026年9月26日時点で、n8n は Agents に専用プランを設けていません。Agent の1ターンは1実行として数えられ、Agent とワークフローの実行は同じ実行枠を消費します。n8nの発表記事には、もう1つ重要な点が記載されています。そのターン内で呼び出すワークフローツールとサブエージェントは、プラン上の個別実行として数えられません。

現在の年払い料金は、Starterが月額$20で2,500実行、Proが月額$50で10,000実行です。どちらも、年払いの切り替えで17%割引と表示されるn8nの料金ページで確認しました。各プランの違いを詳しく知りたい場合は、別記事のn8n料金分析を参照してください。

要件にある試算例として、各3ターンの会話が200件ある場合を考えます。

• Agentの実行は600回です。200 × 3で求められ、内部のワークフローツールは実行枠上、このターン数に含まれたままです。
• Starterでは、$20 ÷ 2,500から、プランに含まれる1実行あたりの配賦額は**$0.008です。600ターンには月額料金のうち$4.80**を配賦でき、1,900実行が残ります。
• Proでは、$50 ÷ 10,000から、プランに含まれる1実行あたりの配賦額は**$0.005です。同じ600ターンへの配賦は$3.00**で、9,400実行が残ります。

この割り算の結果は配賦計算であり、追加請求の単価ではありません。601回目のターンがプランの上限内なら、Starterの請求書に$0.008が追加されるわけではありません。

境界になるのは、Agent とワークフローの割引差ではなく、実行枠の上限です。Starterでは、3ターンで完了する会話を833件、2,499実行まで処理できます。834件目で2,502実行となり、2,500の上限を超えます。Proでは同じ会話を3,333件、9,999実行まで処理でき、3,334件目で10,002実行となって10,000の上限を超えます。

固定ワークフローがチャットメッセージ1件につきWebhookを1回受け取る場合も、同じ600ターンで600実行を消費します。したがって、実行料金は引き分けです。ただし、Agent がツールを巡って複数回判断するのに対し、固定ワークフローはモデルへのリクエストを1回で済ませられる場合があるため、モデル側の費用は安くなる可能性があります。

モデル利用量は、実行枠の対象外です。n8n Gatewayのクレジットは別のプリペイド残高を使い、自分で用意したプロバイダーの認証情報も選べます。Gatewayクレジットのドキュメントによると、残高が0になると、オーナーがクレジットを追加するか、自動追加を有効にするか、認証情報を切り替えるまで、対応ノードは失敗します。ローカル環境で30対100という結果が出たからこそ、実行数とモデル費用の両方をダッシュボードで監視する必要があります。

セッション、バージョン、承認、ワークフロー呼び出し

複数の入口で同じ振る舞いが必要な場合、新しい Agent を採用する意味が生まれます。n8n は、メッセージ、ツール、保留中の承認を含め、すべての会話をセッションとして保存します。測定用フィクスチャでは、チケットごとに1つ、計20のセッションを作成し、追加対応が必要な10件は、それぞれ2ターン目に既存セッションを再開しました。

バージョン管理により、実験と本番運用を分けられます。編集内容はドラフトとして保存され、Publishを実行すると、チャネル、スケジュール、本番チャットで使うスナップショットが作られます。ローカル確認では、ドラフトだけに追加した指示から新しいドラフトバージョンが作成されても、有効なバージョンIDと公開済みの指示は変わりませんでした。本番運用中にプロンプトを調整するなら、期待したい挙動です。

n8n Message an Agent：1つのAgentに複数の入口

Message an Agentノードを使うと、ワークフローから既存の公開済み Agent を呼び出せます。2ノードのスモークテスト用ワークフローから同じSupport Triage Agentへ請求関連のチケットを送信したところ、完全な結果が返り、アカウント情報の取得と返信文の下書きという、同じ2つの限定的なツール呼び出しが記録されました。このノードはカスタムセッションキーにも対応しているため、ワークフローから新規会話を始めるだけでなく、既存の会話を継続できます。

これにより、次のような構成が可能になります。

1. 決定論的なワークフローがイベントを受信し、検証します。
2. Message an Agentが、会話による判断だけを公開済みAgentへ渡します。
3. Agentが、範囲を限定したワークフローツールから使用するものを選びます。
4. 呼び出し元のワークフローが、Agentのテキスト、使用量、ツール呼び出しログ、セッション参照を受け取ります。

ただし、循環する構成は避けてください。Agent を呼び出すワークフローを、その Agent のツールとして登録してはいけません。入口となるワークフローと実際の処理を担うワークフローは分け、境界が名前から分かるようにします。

承認も同じセッション履歴に組み込まれます。機密性の高いツールが選ばれると、Agent は一時停止し、引数を提示します。Approveならその地点から続行し、Rejectなら操作を取り消します。認証情報が使われる前に、提案されたツールと入力を承認者が確認できるため、単なる「ヒューマン・イン・ザ・ループ」という触れ込みより実用的です。

リスクの高い自動化では、セッション履歴だけでは不十分です。Agent の失敗や不審なツール選択を独立したレビュー経路へ送り、対象データに合わせて保持期間、マスキング、アラートを設定してください。この独立した可観測性レイヤーについては、AIエージェントの障害分析ガイドで解説しています。

すべてを作り直さずに移行する方法

移行とは、安定したワークフローをプロンプト内で描き直すことではなく、Agent から呼び出せる形に包むことです。既存ワークフローには、認証情報、検証、API呼び出し、変換処理、障害対応といった重要な資産がすでに含まれています。

1. 1

   決定論的な中核を残す

   スケジュール、webhook、検証、元に戻せない書き込みはワークフローに残します。構成をエージェント型に見せるためだけに、固定手順を移行してはいけません。

2. 2

   操作を契約に変える

   呼び出し可能な各ワークフローに、範囲の狭い入力スキーマと構造化出力を用意します。読み取り専用の照会と副作用のある操作を分け、必要な場所だけに承認を適用します。

3. 3

   ツールセットを最小限にする

   まず、1つの仕事に必要な少数のワークフローだけを Agent に設定します。具体的な名前と説明を付けると、モデルが正しく選びやすくなり、セッションログも監査しやすくなります。

4. 4

   promptではなく会話をテストする

   固定形式、不足情報、重複メッセージ、安全でない依頼を含むケースを使います。スナップショットを公開する前に、最終出力、確認ターン、ツール呼び出し、却下された操作、モデル利用量を採点します。

5. 5

   入口は最後に追加する

   公開済み Agent が安定した後で、チャネル、スケジュール、Message an Agentワークフローを接続します。複数のキャンバスへ指示を複製せず、同じ Agent の実体を再利用します。

手順が固定されている場合、現在の AI Agent node が1つのワークフローだけに属する場合、またはPreviewソフトウェアを受け入れられないコンプライアンス要件がある場合は、移行すべきではありません。セルフホストのEnterprise環境とqueue-mode環境には、さらに明確な答えがあります。現時点では待つべきです。n8nを含む自動化基盤全体を選んでいる段階なら、AI自動化ツールの比較で広い視点から検討できます。

移行コストが潜むのはノード数ではなく、インターフェースです。すべてのワークフローツールに、明確な入力、管理された認証情報、予測可能な出力、重複実行に耐える操作、承認の責任者が必要です。Agent は、元のワークフロー設計者が想定しなかった順番で同じツールを呼ぶ可能性があるため、弱い契約をすぐに露呈させます。

Previewの制約と推奨構成

n8n AgentsはPreviewです。n8n Cloudでは、最新の安定版を使うすべてのユーザーが利用できます。セルフホストは2.32.3以降に対応し、手動セットアップでagentsモジュールを有効にする必要があります。完全なAI支援ビルダーは任意ですが、セルフホストのナレッジベースにはDaytonaサンドボックスが必要で、チャネルには公開Webhook URLが必要です。

一見魅力的な移行でも、2つの制約が妨げになります。AgentsはセルフホストのEnterpriseに対応しておらず、queue modeもサポートしていません。また、Telegramなどのセルフホスト型チャネル接続は失敗する可能性があるとn8nは注意しているため、現時点ではregular modeが推奨されています。

本番環境では、保守的な構成が誠実な選択です。すでに手順が分かっている処理は、すべてワークフローに主導させます。会話によって次の一手を選ばなければならない地点にだけ Agent を置きます。範囲を限定したワークフローをツールとして渡し、セッションを保存し、テスト済みのsnapshotを公開し、意味のある副作用を伴うすべての操作に承認を設けてください。

これなら、Previewの Agent に自動化システム全体を任せることなく、新しい画面の価値を引き出すのに十分な自律性を得られます。

よくある質問

n8nでエージェント型AIを構築できますか？

はい。新しいAgents画面では、セッションをまたいでツールを選べる永続的なAgentを構築できます。既存のAI Agent nodeなら、ワークフロー内にエージェント型の動作を組み込めます。用途に合う範囲を選んでください。

主要な4つのAIエージェントとは？

AIエージェントに権威ある「4大」の定義はありません。一般的な人気リストではなく、担当する業務、必要な連携、承認モデル、導入上の制約、コストで選びます。

AIエージェントの5つの種類とは？

普遍的な5分類はありません。n8nの構築で役立つのは、固定グラフが次の操作を決めるのか、モデルが範囲を限定したツールから選ぶのかという区別です。

n8nワークフローとエージェント型ワークフローの違いは？

n8nワークフローは、宣言されたノードのgraphに従います。エージェント型の構成では、モデルが次の操作を選び、その下で承認済みのツールをワークフローが実行できます。

ChatGPTはエージェント型AIですか？

チャットの応答だけで、必ずエージェント型になるわけではありません。目標に向けて操作やツールを選び、結果を観察し、次に何をするか判断するのがエージェント型の動作です。

エージェントの4つの種類とは？

n8nを規定する単一の4分類はありません。代わりに、状態、計画、ツールへのアクセス、自律性という運用上の特性を評価してください。

上位3つのAIエージェントは？

普遍的な上位3つはありません。適切なAgentは、接続先のシステム、必要な制御の強さ、実行できる環境によって決まります。

AIの7つの種類とは？

7分類のリストは学習用の分類法であり、設計ルールではありません。サポートや運用プロセスをn8nワークフローとAgentのどちらに置くべきかは、その分類では決まりません。

AIエージェントを構成する5つの要素は？

n8nで実装するなら、まずモデル、指示、ツール、メモリ、アクセス制御から始めます。ナレッジ、チャネル、スケジュール、サブエージェントは、用途で必要な場合だけ追加します。

会話による判断がいちばん難しい部分なら、ワークフローを制御レイヤーに残したまま、Agentの設計と構築を支援できます。