AIエージェントを「作ってみたい」と思って調べ始めると、すぐに選択肢の多さに困ることがあります。LangChain、AutoGen、CrewAI、そしてクラウドベンダー製のSDK群。どれを選ぶべきか迷いながら、とりあえず最初に試したものをそのまま使い続けているという人も少なくないのではないでしょうか。そこに2025年、Googleが本格的にオープンソース化したエージェントフレームワークが登場しました。今回は google/adk-python を紹介しつつ、設計のどこが上手く、どこに注意が必要かを一緒に見ていきます。
リポジトリURL: https://github.com/google/adk-python
どんな Skill / フレームワークか
ADK（Agent Development Kit）は、Googleが提供するPythonファーストのAIエージェント開発フレームワークです。PyPIパッケージ名は google-adk で、Python 3.10以上があれば pip install google-adk 一行で導入できます。スター数は執筆時点で21,000を超えており、Googleのプロダクトとしては比較的短期間でここまで伸びた印象です。
ADKの中心には2つのクラスがあります。Agent はLLMへの指示、ツール、ふるまいを定義する単位で、Workflow は複数のAgentをグラフ構造で接続してオーケストレーションする単位です。CLIで adk run を叩けばローカルで動き、adk web を実行すると開発用UIがブラウザで立ち上がります。評価ツール adk eval も内蔵されており、テスト用のevalsetを用意すれば自動評価も回せます。GeminiモデルへのサポートがネイティブですがAPIが抽象化されているため、他のLLMへの接続も可能な設計になっています。
想定ユーザーは、Pythonでプロダクションレベルのエージェントを構築したい開発者です。「ちょっとしたチャットボット」より一段上の、複数エージェントが連携するシステムを作りたい場面が主な対象といえます。
設計でここが上手い
グラフベースの実行エンジン
ADKの Workflow はグラフ構造でエージェント間の実行順序を記述します。edges=[（"START", agent_a, agent_b）] のように書くだけでシーケンシャルな実行が定義でき、fan-out（並列分岐）やfan-in（合流）、ループ、リトライもサポートしています。この設計の良さは、実行の流れをコードの構造として可視化できる点にあります。「このエージェントが成功したら次に進む、失敗したら別のエージェントに委ねる」という条件分岐を、グラフのエッジとして宣言的に書けるため、後から読み返したときに処理フローが把握しやすくなっています。ノード単位でテストもしやすく、複雑なマルチエージェントシステムでも部分的に差し替えながら開発できます。
コードファーストの一貫性
設定ファイルのフォーマットを覚えるより先に、Pythonのクラスとして完結するのがADKの強みのひとつです。エージェントの指示もツールの実装もPython関数として書けるため、バージョン管理やユニットテストがそのまま適用できます。「YAMLで設定を書いて、別のファイルにロジックを書いて」という二重管理が起きにくい設計です。さらに、コードを書かずに設定だけでエージェントを組める「Agent Config」モードも用意されており、プロトタイプ段階から実装段階への移行を柔軟に選べます。
Human-in-the-Loop の組み込み
ツール実行の前に人間の確認を挟む「Tool Confirmation」がフレームワークレベルで提供されているのは注目です。エージェントが外部APIを叩く前に承認フローを入れるケースはプロダクションで頻繁に発生しますが、これを自前で実装するとセッション管理やイベントモデルとの整合性が崩れがちです。ADKはこのフローをHTIL（Human-in-the-Loop）として抽象化して組み込んでいるため、承認フロー付きのエージェントを標準的な方法で実装できます。
llms.txt の存在
リポジトリルートに llms.txt と llms-full.txt が置かれています。これはLLMをコンテキストとして使って開発する、いわゆる「vibe coding」向けのコンテキスト提供ファイルです。要約版と全量版を使い分けられるように分けてあり、コンテキストウィンドウの大きさに応じて選べる設計になっています。ドキュメントをコンテキストとして与えるときのトークン消費を意識した工夫といえます。
こういう人に向くかも
すでにGCPのサービス群（Cloud Run、Vertex AI）を使っているチームには、デプロイまでの摩擦が少ない選択肢になります。ADKはCloud RunやVertex AI Agent Engineへの直接デプロイをサポートしており、「ローカルで動いたら次はどこに出すか」という判断が比較的シンプルです。
一方、Googleのエコシステムと距離を置いて使いたい場合は、若干の注意が必要です。GeminiモデルへのネイティブサポートはADKの強みですが、同時に「最適化されている先」がGeminiであるという傾きを持つフレームワークでもあります。OpenAIやAnthropicのAPIを主軸に使いたい人には、別のフレームワークのほうが素直に動く場面もあるかもしれません。また、2.0でAPIモデルやセッションスキーマに破壊的変更が入っており、1.x系からの移行にはある程度の対応コストを見込んでおく必要があります。
設計の良し悪しをどこで見るか
機能の単一性
ADKは単機能ツールではなくフレームワークです。Agent、Workflow、Tool、Session、Eval、CLIといった複数の層を持っています。この広さは「フレームワーク内で完結できる範囲が広い」というメリットに直結しますが、同時に「何かうまくいかないときにどの層に問題があるのかを追うのが難しくなる」というコストも生じます。たとえば、マルチエージェントのフローでトークンが想定より多く消費されたとき、それはPromptの設計なのか、Workflowのイベントモデルなのか、ツールの戻り値の形式なのかを切り分けるデバッグ力が求められます。
ドキュメントの深度
READMEにはQuick Startと主要機能の概要が載っており、公式ドキュメントサイトも整備されています。docs/guides/ ディレクトリにはタスク指向のウォークスルーが並んでいて、contributing/samples/ には実行可能なサンプルエージェントが置かれています。ドキュメントの層が「READMEのざっくり概要 → ガイド → サンプル → コミュニティリポジトリ」と段階的に用意されているのは、学習コストを分散させる上手い構造だと思います。ただ、2.0の破壊的変更に関するマイグレーションガイドの詳細は、READMEの警告ボックスだけでは足りないと感じます。「何が変わったか」より「どう直すか」を求める人には、もう少し厚みが欲しい場所です。
トークン経済性
llms.txt の存在はトークン消費を意識した設計の表れです。ただ、フレームワーク本体でも、マルチエージェント間でセッション状態をどこまで引き継ぐかによってコンテキストウィンドウの消費量が大きく変わります。fan-outで並列起動した複数エージェントが全員フルのセッション履歴を持つ設計にするとトークン消費が急増するため、どの情報をどのエージェントに渡すかという「状態の切り分け」はADKを使う上でも開発者が意識し続ける必要があります。
メンテナンスの継続性
Googleがオープンソースとして公開しているリポジトリである以上、継続性への信頼はある程度担保されています。リリースサイクルは約2週間ごとと明記されており、Java・Kotlin・Go・TypeScriptへの移植版も並行して開発されています。コミュニティリポジトリも別に用意されており、エコシステムとして育てようとする意図が見えます。一方で、Apache-2.0ライセンスの採用はフォークや商用利用の自由度を確保しており、ライセンス面での不安は小さいです。
自分が書くなら、どこを変えるか
READMEの構成でひとつ気になるのは、1.xから2.0への移行者向けの情報が警告ボックスひとつに集約されている点です。「Sessions generated by ADK 2.0 are readable by ADK 1.28+」とあるだけで、具体的に何のAPIが変わったか、どのコードをどう書き直せばよいかは書かれていません。ADKを既存プロジェクトに入れようとしているエンジニアが最初にREADMEを読んだとき、この警告だけでは移行の全体像が見えず、ドキュメントサイトを探し回ることになります。マイグレーションガイドへの直リンクを警告ボックス内に置くだけでも、体験は変わるはずです。
もうひとつは llms.txt と llms-full.txt の使い分けについてのガイドが薄い点です。「コンテキストウィンドウが十分に大きければfull版を使え」と書いてあるだけで、どのモデルでどちらを使うと開発が捗るかの具体例がありません。モデルの種類やコンテキスト長によって使い分けの目安を示してあると、vibe coding目的で使おうとしている人にとってよりわかりやすくなると思います。
スキルパックを設計するときのチェック観点
以下は、ADKのようなエージェントフレームワークを評価・選定するときに使えるチェックリストです。
- エージェント間でセッション状態をどこまで引き継ぐかを設計段階で決めているか
- デバッグ時に「どの層に問題があるか」を切り分けられる仕組みが揃っているか
- Human-in-the-Loopフローが必要な場合、フレームワークがそれをネイティブにサポートしているか
- 採用するLLMのモデルとフレームワークの最適化対象が一致しているか
- ローカル開発からデプロイ先までのパイプラインがどこまで統一されているか
- 破壊的変更のサイクルと自分たちのリリース速度が噛み合うか
- コミュニティサポートとドキュメントの更新が、本体のリリースサイクルに追いついているか
結び
ADKはエージェント開発のさまざまな関心事、オーケストレーション、評価、デプロイ、Human-in-the-Loopを一枚のフレームワークにまとめた、スコープの広いツールです。GCPとの親和性が高く、Googleが継続的に更新しているという安心感もあります。ただし、フレームワークが広いということはトレードオフもあり、問題の切り分けには慣れが必要です。「作りたいものの複雑さとフレームワークのスコープが釣り合っているか」を一度確認してから導入を検討するのが、判断の出発点として良いのではないでしょうか。
