Agent Development Kit（ADK）は、AI エージェントを構築するためのフレームワークで、adk.dev で配布されている。Google は自社の開発者ブログで、ADK を、独自の統合コードを組み上げるのではなくエージェントアプリケーションを構築するためのクイックスタート用リソースとして紹介しており、ADK を使ってマルチエージェントシステムを構築するためのドキュメントも公開している。
機能
Google の開発者向けの記事は、オープンなエージェントプロトコルを 1 つずつ重ねていく多段階のエージェントを構築する手段として ADK を提案している。具体例として挙げられているのはレストラン向けのサプライチェーンエージェントで、プロトコルが追加されるにつれて、実際の在庫データベースを確認し、リモートの仕入れ先エージェントと通信し、安全な取引を実行し、インタラクティブなストリーミングダッシュボードを描画できるようになる。このフレームワークは Model Context Protocol のようなオープン標準と組み合わせて使うものとして示されており、Google がこれを推す論拠は、そうすることでエージェントが扱うツールごとに壊れやすい統合コードを書いて保守する必要がなくなるという点にある。
プロトコルのサポート
Google の AI エージェントプロトコルのための開発者ガイド は、このレストラン向けエージェントを ADK で構築し、プロトコルごとに、フレームワークがそれぞれをどこでサポートしているかを示している。ADK は McpToolset を通じて Model Context Protocol サーバーに接続し、MCP Toolbox for Databases を通じてデータベースに接続する。Agent2Agent プロトコル（A2A） については、任意の ADK エージェントを A2A サービスに変換するユーティリティがあり、RemoteA2aAgent は 1 ターンごとに 1 つのリモートエージェントへルーティングする。複数のリモートエージェントに同時にまたがるクエリについては、ガイドは代わりに a2a-sdk を直接使っている。フレームワークの adk web インターフェースは Agent-to-User Interface Protocol（A2UI） のコンポーネントをネイティブに描画できるため、独自のレンダラーなしでエージェントの UI 出力をテストできる。ADK はストリーミングイベント用のネイティブな /run_sse エンドポイントも備えている。Agent-User Interaction Protocol（AG-UI） については、ガイドはエージェントを ag_ui_adk パッケージでラップし、FastAPI アプリにマウントしている。すべてのプロトコルがコアに含まれているわけではない。ガイドは、Agent Payments Protocol（AP2） の型は ADK のコアに組み込まれているのではなく、別パッケージとして提供されていると指摘している。ガイドの助言は、これらのプロトコルのいずれかを使って構築する前に、ADK との統合、公式 SDK、サンプルコードがあるかを確認することである。
ツール
Google Codelabs の「Building AI Agents with ADK」シリーズのチュートリアルは、ADK におけるツールを、リアルタイムのデータを調べたり外部 API を呼び出したりといった特定の動作をエージェントが行えるようにするモジュール化されたコードと説明し、ADK のツールを 3 つのカテゴリーに分けている。開発者が自作するカスタムツールである関数ツール、Google 検索やコード実行など一般的な操作のためにフレームワークが提供する組み込みツール、そして LangChain や CrewAI のツールを含む外部ライブラリ由来のサードパーティツールである。このチュートリアルでは Python 関数を FunctionTool としてラップしており、関数の名前と docstring こそが、ツールが何をするのか、いつ使うべきかを判断するためにエージェントのモデルが読むものだと強調し、明確な docstring を、エージェントがツールを正しく使ううえで唯一にして最も重要な要素と呼んでいる。
同じチュートリアルは、基本的なものとして提示するパターン、すなわち専門化されたエージェントをツールとして使うパターンを示している。Google 検索だけをツールとして持つ検索エージェントを、エージェント全体を標準的なツールのように見せて振る舞わせる AgentTool でラップし、他のツールとともにルートエージェントに渡す。すると、ルートエージェントは各リクエストを適切なツールに渡すオーケストレーター、あるいはルーターとして機能する。チュートリアルでは adk web 開発 UI を通じてエージェントを実行・検査しており、そのイベントインスペクターにはエージェントがどのツールを呼び出したかが表示される。
エージェントの種類と評価
Google の「AI Agent End to End」ワークショップは、エージェントクラスの違いを示す 2 つの ADK エージェントを構築している。物語を書くエージェントは LlmAgent を使っており、ワークショップはこれを宣言的と呼ぶ。つまり、モデルが指示から出力を生成する。これに対し、画像を生成するエージェントは BaseAgent を使っており、ワークショップはこれを命令的と呼ぶ。つまり、開発者がその _run_async_impl メソッドに正確な段階的ロジックを書き、画像ツールを呼び出すかどうかをモデルに判断させるのではなく直接呼び出す。ワークショップは、エージェントが決まった手順に従わなければならない場合、モデルの介在なしにツールを呼び出さなければならない場合、あるいはモデルがプロンプトから確実に推論するには複雑すぎるロジックを実行する場合に BaseAgent を使うよう推奨している。
同じワークショップは、ADK の評価フレームワークを、エージェントのコードが動くかどうかだけでなく、その振る舞いが期待を満たしているかどうかをテストする自動化された手段として説明している。evalset.json ファイルには評価ケースが収められ、各ケースは理想的な「ゴールデン」応答を伴うサンプル会話である。test_config.json ファイルは、response_match_score のしきい値やカスタム評価器などの成功基準を設定する。結果は adk web UI の eval タブで確認する。ワークショップでは、Gemini CLI にプロンプトからこれらのファイルを生成させている。
Google はこれに付随する Agent Starter Pack も配布しており、本番品質のエージェントをデプロイするための手段と説明している。
6 つのエージェント協調フレームワークを比較した Jimmy Song のオンラインハンドブック『智能体构建指南』の 1 章は、ADK の強みとして、柔軟なオーケストレーション、階層的なエージェント構成のサポート、組み込みの評価フレームワーク、Vertex AI とのネイティブ統合の 4 つを挙げている。この章は ADK を階層型のアーキテクチャパターン、すなわち上位の層が複雑さを抽象化し、下位の層が細部を実行する多層の監督構造に対応づけており、そこで LangGraph と並べて挙げたうえで、ADK は専門化されたエージェントを組み合わせてモジュール化されたスケーラブルなアプリケーションにするために設計されているので、特にこのパターンに適していると述べている。そこで示されている最適な用途は、Google Cloud Platform 上で LLM ベースのマルチエージェントシステム を構築することである。この章は、ADK についての記述を裏づける数値や測定結果を何も示していない。