n8nのAgentsが担う役割とワークフローとの境界

2026年10月3日 ・ 朝倉 凛

• ワークフロー自動化
• AIエージェント
• セルフホスト
• オープンソース

追加された機能の範囲を確かめる

n8nのAgentsは、目標と使える道具を与えると、過程を自分で組み立てる実行単位として記されている。 具体的には、何を達成すべきかを説明し、用いるモデルと、利用を許可するツールやワークフローを渡す。 エージェントはその情報をもとに手順を決めて動く。 Slackで話しかける、スケジュールで走らせる、既存のワークフローから呼び出すといった入口が用意され、どの入口でも同じエージェントを共有できるとしている。

固定の手順に落とし込みにくい往復型のやりとりや、都度状況が違う依頼を扱う用途に向くという説明がある。 エージェント自体の構築は、ワークフローの作り方を先に学ばなくても始められるとしており、学習コストを抑える意図がうかがえる。 一方で、エージェントはワークフローと並列に置かれ、両者は連携する前提で設計されている。 エージェントはワークフローを道具として呼べるため、システム内で許可する操作の範囲をワークフロー側で明示的に制御できる。

ワークフローからエージェントを呼ぶために、Message an Agentノードが追加されたとされる。 既存のAI Agentノードについては、変更がなく、これまでに構築したものはそのまま動作すると説明されている。 ここで重要なのは、新しい仕組みが既存機能の置き換えではないという点である。

公式の記述を並べて読む

変更履歴のページは、エージェント機能を「一度設定してどこからでも使える」と要約している。 公開はn8n 2.40で行われ、公開日は2026年9月21日としている。 安定版とベータ版の併記もあり、当時点の安定版と直近のベータ版が示されている。 この記述は、ブログの「どこからでも同じエージェントを使える」という説明と整合している。

MCP接続ガイドは、ClaudeやCursorなどのクライアントをn8nのMCPサーバーに接続する手順を示す資料である。 この文書は接続方法と認証の流れを扱っており、エージェント機能そのものの説明ではない。 両者は用途が異なるため、混同しないほうがよい。 エージェントの入口として挙げられるSlackやスケジュール起動の話はブログ側の説明に限られている。

設計と運用で生じる影響

ワークフローを道具としてエージェントに渡せるという設計は、権限境界の作り方に影響する。 任せてよい操作をワークフローとして明示し、そのリストだけをエージェントに渡せば、想定外の副作用を避けやすくなる。 固定手順をワークフローに封じておき、判断や探索だけをエージェントに受け持たせる分業が取りやすい。 逆に、道具の渡し方が広すぎると、探索の自由度が上がるぶん挙動の再現性は下がる。

複数の入口から同じエージェントを使えるという前提は、運用の一貫性に寄与する。 Slackでの問い合わせ、定刻バッチ、既存フローの一部など、入口が違っても同じ目標と道具の組で実行される。 呼び出し元を変えても振る舞いの差を抑えられるため、検証はエージェント単位で進めやすい。 一方で、入口ごとに入力の粒度や頻度は変わるため、観測や制限の仕組みは合わせて設計する必要がある。

Message an Agentノードの追加は、ワークフロー側からの呼び出し点を明確にする。 これにより、既存のフローの中に判断のステップだけを差し込みやすくなる。 既存のAI Agentノードが変更されていないという記述は、導入時の移行作業が不要であることを意味する。 置き換えではなく選択肢を増やす追加と読めるため、既存資産の保持と新機能の併用計画を立てやすい。

導入判断の材料をそろえる

ブログは、モデルが手順を組み立てられるようになったことと、人が結果を頼みたいという期待の高まりを根拠としている。 入力が毎回違い、前の応答に次の手が依存する場面では、あらかじめ工程を書けないため、目標駆動の実行が適合しやすいという主張だ。 この前提が当てはまらない、決まった順番で確実に実行したい処理は、従来のワークフローのほうが扱いやすい。 固定フローの中に意思決定だけを差し込む形で、両者を併用する余地がある。

変更履歴には、機能の公開バージョンと一度設定してどこでも使えるという位置づけが示されている。 機能の可用性はバージョンに依存するため、利用中の環境が対象版に達しているかの確認が前提になる。 MCP接続ガイドは別の話題であり、外部クライアント連携の仕組みを扱う文書だ。 エージェントの仕組みと混ぜると設計の前提が曖昧になるため、導入時は範囲を分けて考えるとよい。