ADKの機能を覚えることと、エージェントを設計できることは別です。LLMラッパーとエージェントを分ける3要件、観測から評価までの実行ループ、6つの中核コンポーネント、マルチエージェント協調の5パターン、品質を測る6指標、開発の7フェーズ。実装に入る前に押さえておくべき設計知識を学べるおすすめの書籍は『現場で役立つ マルチエージェントAI設計入門』です。今回は、書籍の「1.1 エージェントの基本概念」を抜粋してお届けします。
現場で役立つ マルチエージェントAI設計入門 Google A2A×ADKで実現する堅牢な運用システム
著：為藤 アキラ
発売日：2026年08月20日（水）
定価：4,180円（本体3,800円＋税10%）
本書について
本書は、AIエージェントをビジネスの現場で確実に稼働させるための実践的な解説書です。GoogleのADK・A2A・MCPを駆使し、複数エージェントが連携する高度なシステムの設計・実装手法を解説します。「実験環境では動いたけれど、本番運用に乗せられない」「複数のエージェントを連携させると途端に破綻する」「トークンコストが爆発してしまう」といった現場の課題を解決し、堅牢なマルチエージェントシステムを構築するためのノウハウをまとめました。
エージェントの定義
AIエージェントとは、目標達成のために自律的に動作し、環境を観測して計画・行動・評価を反復するソフトウェアシステムです。
この定義には3つの要素が含まれています。
- 目標指向：ユーザーの質問に答える・旅行プランを作成する・コードをレビューして修正するなど、達成すべきゴールを持ちます
- 環境との相互作用：外部環境（API、データベース、ファイルシステム、他のエージェント）と能動的にやり取りします
- 反復的な自律行動：1回の入出力で終わるのではなく、状況を観測し、計画を立て、行動し、結果を評価して計画を修正するサイクルを繰り返します
Stuart RussellとPeter Norvigの古典的教科書『Artificial Intelligence: A Modern Approach』では、エージェントを「センサーを通じて環境を知覚し、アクチュエータを通じて環境に作用するもの」と定義しています。LLMの登場により、この知覚→推論→行動のループを自然言語で実現できるようになったのが現在のAIエージェントです。
LLMラッパーとの違い
LLMラッパーとは、LLMのAPIを呼び出して結果を返すだけのアプリケーションです。チャットボットの多くはこの形態に該当します。エージェントとLLMラッパーを分ける要件は以下の3つです。
要件1：自律性（Autonomy）
LLMラッパーは「質問→回答」の1往復で処理が完結します。対してエージェントは、目標達成のために複数のステップを自律的に実行し、最終的な成果物を生成するまで自ら動き続けます。
「来週の大阪出張の宿を予約して」というリクエストに対して、LLMラッパーは「大阪のホテルを検索して予約することをお勧めします」と回答して終わります。エージェントは、カレンダーAPIで出張日程を確認し、ホテル予約APIで空室検索・予算照合・予約実行・カレンダー反映まで自ら完了します。
要件2：ツール使用（Tool Use）
エージェントは外部ツールを呼び出す能力を持ちます。ツールとは、API呼び出し、データベースクエリ、ファイル操作、Web検索、コード実行など、LLM単体では実行できない操作を指します。ADKはツール使用を中核機能として扱います（ツール体系は第2章、MCP（Model Context Protocol、モデルコンテキストプロトコル）統合は第6章で扱います）。
要件3：計画能力（Planning）
エージェントは目標を達成するための計画を立てる能力を持ちます。複雑なタスクを分解し、実行順序を決定し、各ステップの結果に基づいて計画を動的に修正します。
Chain of Thought（CoT）やReAct（Reasoning + Acting）といった推論パターンは、エージェントの計画能力を支える基盤技術です。ADKではAgentがLLMに計画やツール選択を委ね、Workflow Runtimeが実行順序を構造化された形で制御します。
下表にLLMラッパーとエージェントの比較を示します。
| 特性 | LLMラッパー | AIエージェント |
| 処理モデル | 1往復（入力→出力） | 反復ループ（観測→理解→計画→行動→評価） |
| 自律性 | なし（ユーザーが毎回指示） | あり（目標に向かって自律的に行動） |
| ツール使用 | なし（LLMの知識のみ） | あり（API、DB、ファイル、他エージェント） |
| 計画能力 | なし（即座に回答） | あり（タスク分解、実行順序決定） |
| 状態管理 | なし or 単純な履歴保持 | セッション、状態、長期記憶の階層管理 |
| エラー処理 | なし（ユーザーがリトライ） | あり（自動リトライ、代替戦略の選択） |
下図にLLMラッパーとエージェントの構造比較を示します。
エージェントの実行ループ
エージェントの動作は、観測→理解→計画→行動→評価の5ステップからなる実行ループで整理できます（下図参照）。
-
観測（Observe）：ユーザーの入力、前回のツール実行結果、セッションの状態など、判断に必要な情報を環境から収集します。ADKでは
InvocationContextがこのフェーズで利用可能な情報の範囲を定義します - 理解（Understand）：収集した情報をコンテキストとして統合し、現在の状況を理解します。ADKのコンテキスト型は、このフェーズで参照できる情報の範囲と権限を用途ごとに制御します（書籍の1.2.2項で詳述）
-
計画（Plan）：複雑なタスクをサブタスクに分解し、実行順序を決め、各ステップで使うツールを選定します。ADKの
AgentはLLMの推論能力を使ってこの計画を立て、Workflow Runtimeは計画の実行構造を提供します -
行動（Act）：計画に基づき、API呼び出し、データベースへの書き込み、サブエージェントへのタスク委譲などツールを実行して環境に作用します。ADKの
FunctionToolやMcpToolsetがこのフェーズの実行基盤を担います -
評価（Evaluate）：行動の結果を検証し、目標に近づいたかどうかを判定します。期待どおりなら次のステップに進み、そうでなければ計画を修正してリトライします。ADKの
adk evalはこの評価フェーズを開発プロセスに組み込むためのツールです
マルチエージェントについて、体系的に解説した書籍が発売中です！
現場で役立つ マルチエージェントAI設計入門 Google A2A×ADKで実現する堅牢な運用システム
著：為藤 アキラ
発売日：2026年08月20日（水）
定価：4,180円（本体3,800円＋税10%）
本書について
本書は、AIエージェントをビジネスの現場で確実に稼働させるための実践的な解説書です。GoogleのADK・A2A・MCPを駆使し、複数エージェントが連携する高度なシステムの設計・実装手法を解説します。「実験環境では動いたけれど、本番運用に乗せられない」「複数のエージェントを連携させると途端に破綻する」「トークンコストが爆発してしまう」といった現場の課題を解決し、堅牢なマルチエージェントシステムを構築するためのノウハウをまとめました。
6つの中核コンポーネント
エージェントを構成する中核コンポーネントは6つあり、実行ループを支えるインフラストラクチャです。
①ポリシー／推論エンジン（Policy／Reasoning Engine）
エージェントの意思決定部分に相当し、ユーザーの指示を解釈し、計画を立て、次に取るべきアクションを決定します。この役割を担うのがLLMです。ADKではAgentがLLMを推論エンジンとして使用し、modelパラメータでどのLLMを使うかを指定します。推論エンジンの能力がエージェント全体の品質の上限を決定します。モデルの選択（Gemini、GPT、Claude等）は、コスト・レイテンシ・推論能力のトレードオフに基づく設計判断です。
②ツール群（Tools）
エージェントが外部環境に作用するための手段です。ADKの代表的なツール形態をまとめます。
-
FunctionTool：Python関数をツールとして登録する最も基本的な形態 -
AgentTool：他のエージェントをツールとして呼び出す -
McpToolset：MCPサーバーが提供するツール群を統合する -
LongRunningFunctionTool：実行に時間がかかるツールを非同期で扱う
③メモリ（Memory）
エージェントが情報を記憶し、過去の経験を活用するための仕組みです。ADKでは、メモリを3つの層で管理します。
- Session：1回の対話で生じる一時的な情報。対話が終われば揮発する
-
State：セッションに紐づくキーバリューストア。プレフィックスなしのキーはセッション内で完結し、
app:接頭辞はアプリ全体、user:接頭辞はユーザー単位で複数セッションをまたいで共有される - Memory：セッションをまたいで永続する長期記憶。Vertex AI Memory Bankがこの層を担う
この3層の設計意図は書籍の1.2.3項で、実装は第4章で扱います。
④実行環境（Runtime Environment）
エージェントが動作する計算基盤です。ADKは次の実行環境をサポートしています。
-
ローカル：
adk run（CLI）／adk web（ブラウザUI）での開発・テスト - Vertex AI Agent Engine：Google Cloudのマネージドランタイム
- Cloud Run：コンテナベースのサーバーレス実行
- GKE（Google Kubernetes Engine）：Kubernetesクラスタ上での実行
⑤ガードレール（Guardrails）
エージェントの行動を制約し、安全性を確保するための仕組みです。ADKでは、コールバック機構がガードレールの主な実装手段です。
コールバックは4種あり、before_model_callback／after_model_callbackでLLMリクエスト前のフィルタリングと応答検証を、before_tool_callback／after_tool_callbackでツール実行前の許可判定と結果検証を行います。
⑥観測と評価（Observability & Evaluation）
エージェントの動作を可視化し、品質を測定するための仕組みです。ADKは次の観測・評価機能を提供しています。
-
adk eval：評価セットに基づくエージェントの品質測定 -
adk conformance：記録済みADK実行との挙動整合性テスト - トレース：OpenTelemetry互換のトレーシング
- ログ：エージェントの行動履歴の記録
下図に6つの中核コンポーネントの相互関係を示します。
1回のユーザーリクエストが6つのコンポーネントをどう流れるかを下図に示します。
マルチエージェントについて、体系的に解説した書籍が発売中です！
現場で役立つ マルチエージェントAI設計入門 Google A2A×ADKで実現する堅牢な運用システム
著：為藤 アキラ
発売日：2026年08月20日（水）
定価：4,180円（本体3,800円＋税10%）
本書について
本書は、AIエージェントをビジネスの現場で確実に稼働させるための実践的な解説書です。GoogleのADK・A2A・MCPを駆使し、複数エージェントが連携する高度なシステムの設計・実装手法を解説します。「実験環境では動いたけれど、本番運用に乗せられない」「複数のエージェントを連携させると途端に破綻する」「トークンコストが爆発してしまう」といった現場の課題を解決し、堅牢なマルチエージェントシステムを構築するためのノウハウをまとめました。
エージェントの類型
エージェントの設計アプローチは、重視する特性に応じて3つの類型に分類できます。
自律性重視型（Autonomous Agent）
人間の介入を最小限にし、エージェントが自ら判断して行動を完結させるアプローチです。ドメインが明確でリスクの限定的なタスクに適します。
知性重視型（Intelligence-First Agent）
推論の品質を最大化するアプローチです。必要な情報を必要な瞬間にLLMへ渡すContext Engineering（書籍の第3章で詳述）が、この類型の成否を分けます。
ハイブリッド型（Hybrid Agent with HITL）
自律的な処理と人間の判断を組み合わせるアプローチで、HITLパターンとも呼ばれます。承認が必要な判断ポイントで人間に確認を求め、どこまでエージェントに任せ、どこで人間が介入するかの境界設計が要です（書籍の第5章で詳述）。
下表に3類型の比較を示します。
| 類型 | 人間の関与 | 適するタスク | ADKでの実現手段 |
| 自律性重視型 | 最小限 | 定型業務、コード生成 | Agent + ツール + ガードレール |
| 知性重視型 | 問題定義時 | 複雑な分析、創造的タスク | Agent + Context Engineering |
| ハイブリッド型 | 判断ポイントで介入 | 承認が必要な業務 | Agent + HITL + コールバック |
下図に3類型のポジショニングを示します。
マルチエージェントについて、体系的に解説した書籍が発売中です！
現場で役立つ マルチエージェントAI設計入門 Google A2A×ADKで実現する堅牢な運用システム
著：為藤 アキラ
発売日：2026年08月20日（水）
定価：4,180円（本体3,800円＋税10%）
本書について
本書は、AIエージェントをビジネスの現場で確実に稼働させるための実践的な解説書です。GoogleのADK・A2A・MCPを駆使し、複数エージェントが連携する高度なシステムの設計・実装手法を解説します。「実験環境では動いたけれど、本番運用に乗せられない」「複数のエージェントを連携させると途端に破綻する」「トークンコストが爆発してしまう」といった現場の課題を解決し、堅牢なマルチエージェントシステムを構築するためのノウハウをまとめました。
マルチエージェント協調パターン
単一のエージェントでは対応しきれない複雑なタスクには、複数のエージェントを協調させます。ADK v2.2.0では、階層的な sub_agents と Workflow Runtime（Workflow／@node／ctx.run_node()）でマルチエージェント協調を構成します。SequentialAgent／ParallelAgent／LoopAgent はTemplate Workflowとして利用でき、単純な順次・並列・反復制御に向きます。主要な協調形態は次の5つです。
パターン1：マネージャー-ワーカー（Manager-Worker）
1つのマネージャーエージェントがタスクを分解し、専門化されたワーカーエージェントに作業を委譲して結果を統合するパターンです（下図参照）。
ADKでは、Agentのsub_agentsパラメータにワーカーエージェントを登録し、マネージャーのAgentがLLMの判断でタスクの委譲先を決定します。カスタマーサポートを例にすると、マネージャーが問い合わせ内容を判断し、技術サポート・請求関連・一般問い合わせのワーカーに振り分けます。
# python
# マネージャー-ワーカーパターンの概念コード
from google.adk import Agent
# 専門ワーカーエージェント
tech_support = Agent(
name="tech_support",
model="gemini-3.5-flash",
instruction="技術的な問題を診断し、解決策を提示してください",
tools=[search_logs_tool, check_system_status_tool],
)
# billing_support（請求対応）、general_support（一般問い合わせ）も同様に定義
# マネージャーエージェント
root_agent = Agent(
name="support_manager",
model="gemini-3.5-flash",
instruction=(
"ユーザーの問い合わせ内容を判断し、"
"問い合わせ内容に対応する専門チームに振り分けてください。"
),
sub_agents=[tech_support, billing_support, general_support],
)
注目点は責務分離です。マネージャーはツールを持たずsub_agentsのみを持って判断と振り分けに特化し、ワーカーが専門ツールを実行します。これがこのパターンの本質です。
パターン2：専門家合議（Expert Panel）
複数の専門エージェントが独立して分析を行い、結果を集約して最終判断を下すパターンです。医療診断、法務レビュー、投資判断など、複数の専門知識を統合するタスクに適しています。
具体例として、企業のM&A（Mergers and Acquisitions）デューデリジェンス支援を考えます。財務・法務・技術の分析エージェントが並列に分析を行い、統合レポートエージェントが各分析結果をまとめます。
# python
# 専門家合議パターンの概念コード
from google.adk import Agent
from google.adk.agents import SequentialAgent, ParallelAgent
# 専門家エージェント群
financial_analyst = Agent(
name="financial_analyst",
model="gemini-3.5-flash",
instruction="財務データを分析し、リスクと機会を評価してください",
tools=[financial_data_tool],
output_key="financial_analysis",
)
# legal_analyst（法務）、tech_analyst（技術）も同様にoutput_key付きで定義
# 並列分析
parallel_analysis = ParallelAgent(
name="parallel_analysis",
sub_agents=[financial_analyst, legal_analyst, tech_analyst],
)
# 統合レポート生成
report_generator = Agent(
name="report_generator",
model="gemini-3.5-flash",
instruction=(
"各専門家の分析結果を統合し、"
"総合的なデューデリジェンスレポートを作成してください。"
),
)
# パイプライン：並列分析 → レポート生成
root_agent = SequentialAgent(
name="due_diligence_pipeline",
sub_agents=[parallel_analysis, report_generator],
)
output_keyが分析結果のState書き込み先を指定し、レポート生成エージェントはそれを参照します。
パターン3：コンペティション／ディベート（Competition／Debate）
同じタスクに対して複数のエージェントが異なるアプローチで解を生成し、評価エージェントが品質基準に基づいて最良の解を選定するパターンです。コード生成、文章校正、戦略立案など、複数の候補から最適解を選ぶタスクに適しています。ADKではParallelAgentで候補生成を並列化し、SequentialAgentで後段の評価を直列化する設計が典型的です。
パターン4：ブラックボード（Blackboard）
共有のデータストア（ブラックボード）を中心に、複数のエージェントが非同期に情報を読み書きして問題を解決するパターンです。ADKではState機構がブラックボードの役割を果たし、output_keyで各エージェントの出力をStateに書き込み、他のエージェントが参照します。解決手順が事前に確定しない問題に有効です。複雑なバグの調査では、ログ分析エージェントが書き込んだ手がかりをもとにコード分析エージェントが関連コードを特定し、テスト生成エージェントが再現テストを作成するといった協調が自然に発生します。
パターン5：イベント駆動（Event-Driven）
エージェントがWebhook受信、スケジュールトリガー、他のエージェントからの通知といった外部イベントに反応して起動するパターンです。A2A（Agent2Agent、エージェント間通信プロトコル）がこのパターンの実現基盤で、異なるランタイム上のエージェントがHTTP/SSE（Server-Sent Events）を通じて非同期にメッセージを交換できます（A2Aの詳細は第7章で扱います）。
下表にマルチエージェント協調パターンの比較を示します。
| パターン | 構造 | 適するタスク | ADKでの実現手段 |
| マネージャー-ワーカー | 階層型 | タスク分解・委譲 | Agent + sub_agents |
| 専門家合議 | 並列型 | 多角的分析 | ParallelAgent + 集約エージェント |
| コンペティション | 競争型 | 最適解選定 | ParallelAgent + 評価エージェント |
| ブラックボード | 共有型 | 非同期協調 | State + output_key |
| イベント駆動 | 分散型 | 非同期処理 | A2Aプロトコル |
これらのパターンは排他的ではなく、マネージャー-ワーカー構造の内部で専門家合議を行うといった複合パターンが頻繁に登場し、ADKの合成可能なアーキテクチャ（書籍の1.2節で詳述）がそれを支えます。
下図に代表的な3つの協調パターンのトポロジーを示します。
マルチエージェントについて、体系的に解説した書籍が発売中です！
現場で役立つ マルチエージェントAI設計入門 Google A2A×ADKで実現する堅牢な運用システム
著：為藤 アキラ
発売日：2026年08月20日（水）
定価：4,180円（本体3,800円＋税10%）
本書について
本書は、AIエージェントをビジネスの現場で確実に稼働させるための実践的な解説書です。GoogleのADK・A2A・MCPを駆使し、複数エージェントが連携する高度なシステムの設計・実装手法を解説します。「実験環境では動いたけれど、本番運用に乗せられない」「複数のエージェントを連携させると途端に破綻する」「トークンコストが爆発してしまう」といった現場の課題を解決し、堅牢なマルチエージェントシステムを構築するためのノウハウをまとめました。
品質特性と評価軸
プロダクション環境でエージェントを運用するには、動いているだけでは不十分で、定量的な品質指標に基づく継続的改善が必要です。
- 成功率（Success Rate）：エージェントが目標を達成できた割合です。「成功」の定義はタスクごとに異なり、評価セットの設計が測定の土台になります
- 反復回数（Iteration Count）：目標達成までに実行ループを繰り返した回数です。過度に多い場合は計画能力やツール設計を見直します
- コスト（Cost）：LLM呼び出し・ツール実行・ストレージ使用に伴うコストです。主要ドライバーはトークン消費量で、コンテキスト設計が直接影響します
- レイテンシ（Latency）：リクエストから最終応答までの所要時間です。複数ステップを実行するぶんLLMラッパーより長くなります
- 安全性（Safety）：エージェントが有害な行動を取らない度合いです。プロンプトインジェクション攻撃への耐性、機密情報の漏えい防止、権限外操作の防止が含まれます
- 再現性（Reproducibility）：同じ入力に対して同じ（または十分に類似した）出力を返す度合いです。温度パラメータの制御、Seed値の固定、構造化出力の活用で高めます
下表に品質特性と測定手段の対応を示します。
| 品質特性 | 測定手段 | ADKの対応機能 |
| 成功率 | 評価セットによるテスト | adk eval |
| 反復回数 | ループカウントの記録 | トレース |
| コスト | トークン消費量の集計 | Usage Metadata |
| レイテンシ | 実行時間の計測 | OpenTelemetryトレース |
| 安全性 | 攻撃テスト | ガードレール + adk eval |
| 再現性 | 繰り返し実行の一致率 | 評価セット + Seed固定 |
品質指標は本番運用時にも監視し続けます。ADKの評価フレームワーク（書籍の第5章）とAgentOpsの運用監視（書籍の第8章）がこれを支えます。
エージェント開発ライフサイクル
エージェントの開発は、従来のソフトウェア開発とは異なるライフサイクルを持ち、以下の7フェーズで構成されます（ADKのCLIコマンド視点のライフサイクルは書籍の1.4節で扱います）。
- フェーズ1 要件化（Requirements）：ゴール・対象範囲・成功基準・制約を定義し、自動化可能性を評価します
- フェーズ2 設計（Design）：単一かマルチか、協調パターン、ツール、メモリ層構造を決めます
-
フェーズ3 プロトタイプ（Prototype）：
adk createで生成し、adk runで最小限の処理フローを動かします -
フェーズ4 評価（Evaluation）：
adk evalで評価セットを実行し、成功率・コスト・レイテンシを収集します -
フェーズ5 改善（Improvement）：Instruction・ツール・メモリ設計・ガードレールを見直します。
adk optimizeは評価結果をもとにInstructionの改善案を生成します（詳細は第5章で扱います） -
フェーズ6 本番化（Production）：
adk deployでAgent Engine／Cloud Run／GKEのいずれかにデプロイします - フェーズ7 運用学習（Operational Learning）：本番の動作を監視し、フィードバック・エラーログ・品質指標を分析して改善につなげます
7フェーズの循環構造を下図に示します。
本書の刊行を記念して、抜粋記事をお届けしました。続きは書籍を確認いただけますと幸いです。ぜひお近くの書店でお手に取ってみてください。
現場で役立つ マルチエージェントAI設計入門 Google A2A×ADKで実現する堅牢な運用システム
著：為藤 アキラ
発売日：2026年08月20日（水）
定価：4,180円（本体3,800円＋税10%）
本書について
本書は、AIエージェントをビジネスの現場で確実に稼働させるための実践的な解説書です。GoogleのADK・A2A・MCPを駆使し、複数エージェントが連携する高度なシステムの設計・実装手法を解説します。「実験環境では動いたけれど、本番運用に乗せられない」「複数のエージェントを連携させると途端に破綻する」「トークンコストが爆発してしまう」といった現場の課題を解決し、堅牢なマルチエージェントシステムを構築するためのノウハウをまとめました。
この記事は参考になりましたか？
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社
この記事は参考になりましたか？
この記事をシェア
