デベロッパー

ADK アーキテクチャ: 「サブエージェント」と「ツールとしてのエージェント」の使い分け

2025年11月25日

Dharini Chandrashekhar

Sr Solutions Acceleration Architect

Try Gemini 3

Our most intelligent model is now available on Vertex AI and Gemini Enterprise

Try now

※この投稿は米国時間 2025 年 11 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

シンプルに言えば、エージェントとは、自由に使用できる入力とツールに基づいて、目標を達成する最適な方法を推論するアプリケーションです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_oGjJbVH.max-800x800.png

Agent Development Kit（ADK）を使用して高度なマルチエージェント AI システムを構築する際には、「サブエージェント」と「ツールとしてのエージェント」のどちらを採用するかがアーキテクチャ上の重要な決定事項となります。この選択は、システムの設計やスケーラビリティ、効率性に本質的な影響を与えます。パターンを誤って選択すると、大きなオーバーヘッドが発生する可能性があります。単純な関数に常に会話履歴全体を渡すことになったり、複雑なシステムのコンテキスト共有機能を十分に活用できなかったりするためです。

サブエージェントとツールはどちらも複雑な問題を分解するのに役立ちますが、その目的は異なります。主な違いは、制御とコンテキストの処理方法です。

ツールとしてのエージェント: 専門家が待機

「ツールとしてのエージェント」は、特定の個別のタスク（特殊な関数呼び出しなど）のためにパッケージ化された自己完結型の専門エージェントです。メインエージェントは明確な入力でツールを呼び出し、直接出力を取得します。これはトランザクション API のように動作します。メインエージェントは、ツールの仕組みを気にする必要はありません。必要なのは信頼できる結果だけです。このパターンは、独立した再利用可能なタスクに最適です。

主な特徴:

カプセル化と再利用: 内部ロジックが隠されているため、さまざまなエージェントでツールを簡単に再利用できます。
分離されたコンテキスト: ツールは独自のセッションで実行され、呼び出し元のエージェントの会話履歴や状態にアクセスできません。
ステートレス: インタラクションはステートレスです。ツールは、必要なすべての情報を 1 回のリクエストで受け取ります。
厳密な入力/出力: 明確に定義された契約に基づいて動作します。

サブエージェント: 委任されたチームメンバー

「サブエージェント」は、複雑な複数ステップのプロセスを処理する委任されたチームメンバーです。階層的かつ協調的な関係に位置し、親エージェントのミッションというより広いコンテキストの中で動作します。推論の連鎖や一連のやり取りが必要なタスクには、「サブエージェント」を使用します。

主な特徴:

緊密に結合して統合:サブエージェントは、定義された大規模なワークフローの一部です。
コンテキストの共有: 同じセッション内で動作し、親エージェントの会話履歴や状態にアクセスできるため、より微妙なニュアンスを考慮したコラボレーションが可能になります。
ステートフルプロセス: タスクを完了するのに複数のステップが必要なプロセスの管理に最適です。
階層的な委任: 親エージェントが上位レベルのタスクを明示的に委任し、サブエージェントがプロセスを管理できるようにします。

以下は、タスクに応じた設計判断の参考になる簡易的な意思決定マトリックスです。

判断基準	ツールとしてのエージェント	サブエージェント	意思決定
タスクの複雑さ	低～中	高	単機能関数にはツールを使用する。複雑なワークフローにはサブエージェントを使用する。
コンテキストと状態	分離/なし	共有	タスクがステートレスの場合は、ツールを使用します。会話のコンテキストが必要な場合は、サブエージェントを使用します。
再利用性	高	低～中	汎用的で幅広く適用できる機能については、ツールを構築します。特定のプロセスにおける専門的な役割には、サブエージェントを使用します。
自律性と制御	低	高	簡単なリクエストとレスポンスにはツールを使用します。サブエージェントを使用して、サブ問題を丸ごと委任する。

ユースケースの活用

このフレームワークを実際のシナリオに当てはめてみましょう。

ユースケース 1: データエージェント（NL2SQL と可視化）

ビジネスユーザーが、第 2 四半期の地域別商品売上上位 5 件を棒グラフで表示するようリクエストします。

ルートエージェント : ビジネスユーザーのリクエスト（NL）を受け取り、必要なステップ（SQL の生成 → 実行 → 可視化）を決定し、タスクを委任/順序付けしてから、ユーザーに応答を返します。
NL2SQL エージェント: ツールを使用します。タスクは、再利用可能な単一の関数です。メタデータとスキーマを使用してグラウンディングし、自然言語を SQL 文字列に変換します。
データベースエグゼキュータ: ツールを使用します。これは、クエリを実行してデータを返すための、単純で決定論的な関数です。
データ可視化エージェント: サブエージェントを使用します。このタスクは複雑で、複数のステップが必要です。データベースツールから返されたデータと、元のユーザークエリを分析し、適切なグラフの種類を選択したうえで、可視化コードを生成して実行する必要があります。これをサブエージェントに委任することで、メインのオーケストレーターエージェントは全体像を把握し、サブエージェントは複雑な内部ワークフローを個別に管理できます。

ユースケース 2: 洗練された旅行プランナー

ユーザーが、パリでの 5 日間の記念旅行について、プランの作成を求めています。フライト、ホテル、アクティビティに関する具体的な希望を提示しています。この目標は曖昧で抽象的であり、継続的なコンテキストと計画が必要です。

旅行プランナー: ルートエージェントを使用して、全体的な目標（「パリへの 5 日間の記念旅行」）を維持し、サブエージェント間のフローを管理して、最終的な旅程をまとめます。注: すべてのエージェントがアクセスできるコンテキスト/メモリマネージャーツールを実装できます。その際、不変の意思決定を保存するために、シンプルな Key-Value ストア（Redis やシンプルなデータベースなど）を使って、ストレージ処理を委任することもできます。
フライト検索: サブエージェントを使用します。このタスクは単純な検索ではなく、ユーザーとの複数のやり取り（例: 「ドバイでの乗り継ぎは大丈夫ですか？」）など、旅行全体のコンテキスト（日付、目的地、クラス）を管理しながら進める必要があります。
ホテルの予約: サブエージェントを使用します。オプションを検索して提示する際に、状態とコンテキスト（日付、場所の好み、5 つ星評価）を維持する必要があります。
旅程の生成: サブエージェントを使用して、日単位で整合性のあるプランを生成します。エージェントは、確定したフライトやホテルとユーザーの興味（美術館、高級レストランなど）を組み合わせ、必要に応じて自らの予約ツールを活用して手配します。