n8nが今年初頭から段階的に拡張してきたAI Agentノードに、Agent-to-Agent連携が乗ってきた。AIエージェントが、別のAIエージェントをツールとして呼び出せる、という機能だ。一見すると地味な追加に見えるが、1ヶ月運用してみると、フロー設計の発想そのものが明確に変わる手応えがあった。本稿では筆者が実際に組んだManager/Worker構成のパイプラインと、その運用で見えてきたトークンコストのトレードオフ、そして現実的な落とし所を実機ベースで整理する。
Manager / Worker構造が、そのままノードとして組める
これまでn8nでAIエージェントを組むと、1つのAgentにツールを大量に持たせる形になりがちだった。検索ツール、コードツール、要約ツール、メール送信ツール。1個のエージェントに全部、というやつだ。ツール数が増えるほど、Agentの選択判断が鈍くなる症状はずっと気になっていた。
Agent-to-Agentでは、Manager AgentがWorker Agent（Research、Coder、QAなど）を呼び出す形に組み替えられる。Workerはそれぞれ独立した役割と、限定されたツールセットを持つ。これは組織図の構造に近い。役割を切り分けたほうがミスが減る、というのは現場の感覚と一致する話だ。
tool_descriptionの書き方が、最大の設計ポイント
Manager AgentがどのWorkerを呼ぶかは、各Workerに付ける tool description の記述で決まる。ここの書き方で精度がガラッと変わる。
筆者の最初の失敗は「コードを書くエージェント」のような抽象的な書き方だった。結果、ManagerはCoder Agentを呼ぶべき場面でResearch Agentを呼ぶ、という誤呼び出しが頻発した。体感で日に3回はミスが出ていた。
そこで書き直したのは、徹底した具体性だ。
Coder Agent:
TypeScript / Python / Go の実装専門。
ライブラリ選定や型定義の提案も含む。
ファイル読み書きが必要な処理に限定。
SQL / インフラ設定は対象外。ここまで切り分けると、誤呼び出しが3回/日から0〜1回/週に減った。劇的、と言っていい改善だ。ベテランのプロジェクトマネージャーがメンバーに振る前に「これは誰の専門か」を明確にする作業を、tool_descriptionの記述でやっている感覚に近い。
競合リサーチパイプラインで処理時間が約5分の1に
具体例を1つ。SaaS競合の動向リサーチを自動化した構成を紹介する。4階層の設計だ。Manager Agentがタスクを分解し、Research Agent（SerpAPI + Wikipediaツール）が情報収集、Writer Agentが構造化Markdownへ整形、最後にQA Agentが事実関係をチェックする流れになっている。
このパイプラインで、1社あたりの分析所要時間を計測した結果は以下の通り。
- 手動: 約47分（自分の作業計測）
- 単一Agent: 約18分
- Agent-to-Agent: 約9分30秒
単一Agentと比較しても、ほぼ半分の時間で終わる。各Agentが「自分の専門領域だけ」を見ていて、コンテキスト効率が良いのが効いているように感じる。
トークン消費は単一Agentの約1.7倍に伸びる
ここで率直に書いておきたい。Agent-to-Agentは速いが、トークン消費は単一Agentの1.7倍程度に伸びる。Worker間のメッセージ往復が増えるためだ。
Anthropic Claude Sonnet 4.6基準で計測したログを残しておく。
- 単一Agent: 約11,400 tokens / 1パイプライン
- Agent-to-Agent: 約19,300 tokens / 1パイプライン
OpenAI GPT-5.4-Miniのような廉価モデルをWorker側に充てる手はある。Manager側だけ高性能モデルに、というハイブリッド構成が現実解だと感じている。月次のAPI請求が1.5倍になるか据え置きになるかは、ここのモデル配分設計次第だ。コスト試算を事前にしておかないと、月末に請求額で驚くことになる。
Human-in-the-loopを1段挟むのが現実的
Agent-to-Agent運用で一番事故りやすいのは、QA Agentが見逃した誤情報がそのまま最終出力に乗るケースだ。完全自動化を狙うと、ここで品質事故が起きる。
n8nはこれに対して、Wait nodeを使ったヒューマン承認ステップを挟める設計になっている。筆者の運用ではWriter Agentの後ろに「Slack approval」を挟んでいる。10件中1件くらいの頻度で差し戻しが発生するので、レビュー工程としての効果は確実にある。
完全自動化に走らないほうが、結果的に運用が楽だ、という結論に今はいる。これは個人的なバイアスかもしれないが、「人間レビューを残しておくと、Agent側の品質劣化に早く気づける」という副次的効果もあった。Workerの誤呼び出しが増えたタイミングに、レビュー段階で気づけるのだ。
単一Agent設計の限界と、段階的に組み立てる流儀
これまではAgentを1個に集約する設計が無難だった。だがツール数が10を超えると、Manager-Worker構造のほうが明らかに保守しやすい。n8nに限らず、Claude Managed Agentsのmultiagent orchestration、Codex CLIのsub-agent機能、いずれも同じ方向へ動いている。「一人に全部やらせる」設計の限界が、業界全体で意識され始めている印象だ。
これから試す人向けに、現実的なスタート地点を1つ示しておきたい。最初からWorkerを4個用意すると、debugしにくくなる。Worker 2個、Manager 1個の3ノード構成から始めるのが楽だ。
筆者がやったのは、Research Agent（検索専門）とSummary Agent（要約専門）の2構成。Manager Agentが受けた要求を、まずResearchへ、次にSummaryへ流す素朴な配線。これだけでも、単一Agent運用と比べて出力品質が肌感で30%ほど上がった。慣れてからQA AgentやWriter Agentを追加していく流れが、結局のところ一番速い導入経路になる。最初から完成形を組もうとすると、tool_descriptionの調整地獄に入り込んで動かなくなる。1段階ずつ増やす流儀は、経験則として書き残しておく価値があると思う。
n8nを既に触っている開発者なら、Agent-to-Agentの設定追加は1日で慣れる範囲だ。トークンコストとパイプライン速度のトレードオフさえ意識すれば、運用に乗せやすい機能だと感じている。
※本記事は筆者個人の検証結果と所感を含みます。動作環境や利用プランによって結果は異なる場合があります。各製品の最新仕様は公式ドキュメントをご確認ください。
