7月8日、Bala Priya Cが「Tools vs. Subagents: Building Effective AI Agents Without Over-Engineering」と題した記事を公開した。AIエージェント設計において「推論が必要かどうか」という一点だけを判断軸にすれば、ツールとサブエージェントの使い分けはほぼ自動的に決まる——これが記事の中核にある設計哲学だ。判断を誤れば、一方では肥大化した単一エージェントが生まれ、他方では不要な協調オーバーヘッドとデバッグ地獄が待つ。
AIエージェント開発が普及するにつれ、「この機能はツールで実装すべきか、それともサブエージェントに任せるべきか」という設計判断が避けられない局面が増えている。記事が提示する答えはシンプルだ。「そのタスクに推論ループが必要か？」——この一問で判断できる。
ツールとサブエージェント、何が違うか
ツールは、エージェントが外部システムと連携するための実行可能な関数やAPIコールだ。モデルがツールを呼び出すと、アプリケーション側でコードが実行され、結果がそのままオーケストレーターの会話コンテキストに返ってくる。ツール自体は推論を行わない。決定論的に動作し、低レイテンシ・低コストが特徴だ。
サブエージェントは、独立した推論ループを持つLLMインスタンスだ。独自のシステムプロンプト、独立したコンテキストウィンドウ、専用のツールセットを持ち、タスクを受け取って自律的に推論ループを回し、結果だけをオーケストレーターに返す。オーケストレーターからは内部のステップは見えない。
両者の違いを一言で言えば、「ツールはコードを実行し、サブエージェントは推論を実行する」。
| 観点 | ツール | サブエージェント |
|---|---|---|
| 実行するもの | 決定論的なコード | 独立した推論ループ |
| コンテキスト | オーケストレーターと共有 | 独立・隔離 |
| 推論 | なし（決定論的） | マルチステップ推論ループ |
| コスト | 実行コストのみ | 追加のLLM呼び出し |
| レイテンシ | 低 | 高 |
| デバッグ容易性 | 高（結果がコンテキストに残る） | 低（内部ステップが不透明） |
「3つの問い」で判断する
記事では、どちらを選ぶかの判断を以下の3問に集約している。
① タスクは「実行」か「推論」か？
DBクエリ、API呼び出し、ファイル操作、計算処理など、入力と出力が明確に定義できるならツールで十分だ。「競合他社のリサーチ」のように、何を調べるかを決め、結果を読んで次の検索を判断し、最終的に統合するといった多段階の意思決定が必要ならサブエージェントが適する。
② 中間処理の結果はオーケストレーターに必要か？
DBの1レコードや検索結果1件ならコンテキストに置いても邪魔にならない。一方、数十件のドキュメントを横断した調査過程をすべてオーケストレーターのコンテキストに積み上げると、推論の質が低下する。この場合、サブエージェントで中間処理を隔離し、結論だけを返させる。
③ タスクは独立して実行できるか？
k件のドキュメントを並列処理したい場合、k個のサブエージェントを並走させる方が逐次処理より速い。Microsoft AutoGenはこのパターンを中心に設計されたフレームワークの一例だ。同様のマルチエージェント並列実行のアプローチは、Google Agent Development Kit（ADK）やAnthropic Claude のサブエージェント実装でも採用されており、いずれも「独立した推論ループを並走させる」設計を基本に置いている。
最も避けるべき失敗：過剰なサブエージェント化
記事が最も強調するのが「オーバーエンジニアリングの罠」だ。
サブエージェントはアーキテクチャをクリーンに見せることもあるが、同時に複雑性を加える。コンテキストウィンドウが増え、推論ループが増え、コンポーネント間のハンドオフが増える。それはレイテンシ増加、コスト増加、デバッグ難易度の上昇を意味する。
実践的な指針として記事が示すのは、「タスクを渡し、結論を返させる（Pass tasks down; pass conclusions back up）」という原則だ。リサーチサブエージェントなら、「3社の競合を特定し、価格モデルと差別化ポイントをまとめた」という結論を返すべきであって、途中の検索クエリや取得したドキュメントの断片をすべて返すべきではない。
また、エージェントに与えるツール数が増えるほどツール呼び出しの精度が落ちるという研究結果も引用されている。サブエージェントごとにツールセットをスコープすることで、各エージェントの判断空間を小さく保てる。
設計の原則
- デフォルトはツール。単一エージェント＋少数の明確なツールから始める。まず最もシンプルな構成で動くものを作り、そこから必要に応じて拡張するのが基本姿勢だ
- サブエージェントを追加するのは3条件のいずれかを満たすときだけ。「大量の中間処理の隔離」「並列実行」「専用の推論空間が必要」——これ以外の理由でサブエージェントを導入すると、ほぼ確実に過剰設計になる
- 「このサブエージェントは何をもたらすか？」を問い直す。「少量の処理をしてから返すだけ」ならツールで十分だ。付加価値が推論ループの有無に帰着しないなら、サブエージェントである必要はない
- サブエージェント間で可変状態や途中結果を共有させない。そうした設計は協調の複雑性をすぐに手に負えない水準まで引き上げる。サブエージェントはあくまで「タスクを受け取り、結論を返す」単位として独立させる
詳細はTools vs. Subagents: Building Effective AI Agents Without Over-Engineeringを参照していただきたい。
