google/adk-python 2.0 採用判断: Workflow グラフと Task API が変えたもの

ADK が解こうとしているのは「エージェントの制御をコードに戻す」問題

ADK は README で「code-first Python framework for building, evaluating, and deploying sophisticated AI agents」と説明されている。対象は、単発のプロンプト呼び出しではなく、複数のエージェントとツールを組み合わせた処理をアプリケーションとして保守したい開発者だ。中心にあるのは 2 つのクラスで、Agent が「instructions, tools, and behavior」を定義し、Workflow が「orchestrates agents and tasks in a graph-based flow」を担う。プロンプトとモデル設定がコードの外に散らばる構成ではなく、エージェントの分岐や委譲の構造そのものを Python のモジュールとして扱う点が設計の出発点になっている。README はモデル非依存かつデプロイ非依存を掲げつつ、Gemini 向けに最適化されていると明記しており、この 2 文は並列ではなく優先順位の表明として読める。

Workflow は edges で実行順を固定する、LLM に順序を決めさせない

README の Quick Start にある Workflow の例は短いが、設計意図がはっきり出ている。edges=[("START", generate_fruit_agent, generate_benefit_agent)] という 1 行が、果物名を返すエージェントから健康上の利点を答えるエージェントへの遷移を定義する。ここで次にどのエージェントを呼ぶかをモデルが選んでいるわけではない。グラフの辺として順序が決まっており、モデルは各ノードの入出力だけを担当する。README が Workflow Runtime の説明で挙げる機能は routing、fan-out/fan-in、loops、retry、state management、dynamic nodes、human-in-the-loop、nested workflows で、決定的なフローと再試行や状態管理を同じ実行エンジンに載せている。エージェントの自律性を上げる方向ではなく、呼び出し順をテスト可能な形で固定する方向の機能追加だと読める。

Task API はエージェント間の委譲を「タスク」という単位に切る

Task API は structured agent-to-agent delegation と説明され、multi-turn task mode、single-turn controlled output、mixed delegation patterns、human-in-the-loop、task agents as workflow nodes が列挙されている。エージェント A がエージェント B をツールとして呼ぶだけの構成と違い、委譲がタスクという明示的な単位になり、複数ターンにわたるタスクと単一ターンで出力を固定するタスクを混在させられる。README の記述からは、この 2 つのモードの使い分けの基準までは読み取れない。単一ターンで出力を制御したい場面と多ターンで対話させたい場面の境界は、ドキュメント本文を確認する必要がある。タスクエージェントがワークフローのノードとして置ける点は重要で、委譲の入れ子構造がグラフ上の位置として表現される。

インストールは制約ファイル込みで実行するのが README の推奨

安定版は pip install google-adk で入る。要件は Python 3.10 以上。README は推移的依存の保護のため、Python のバージョンに対応した制約ファイルと一緒にインストールすることを勧めている。手順は、curl -o constraints-3.10.txt https://raw.githubusercontent.com/google/adk-python/main/constraints-3.10.txt で取得し、pip install google-adk -c constraints-3.10.txt を実行し、最後に rm constraints-3.10.txt で消す。制約ファイルは Python 3.10 から 3.14 向けが用意されていると書かれている。任意の連携を使う場合は pip install "google-adk[extensions]" を使う。未リリースの修正が必要な場合のみ pip install git+https://github.com/google/adk-python.git@main で main から入れられるが、README 自身が experimental changes or bugs を含みうると注記している。リリース間隔はおよそ 2 週間ごとと明記されている。

2.0 のセッション互換性は片方向で、古い 1.x には戻れない

README の警告ブロックは、このリリースが agent API、event model、session schema に破壊的変更を含むと述べている。互換性の向きが重要で、ADK 2.0 が生成したセッションは ADK 1.28 以降では読めるが、それより古い 1.x では読めない。余分なフィールドは無視されるという記述から、前方方向の読み取りは許容される設計だと分かる。逆に、1.28 より前のバージョンで生成したセッションを 2.0 で扱ったときにどうなるかは、この README の範囲では確認できない。セッションスキーマが変わっている以上、既存データの移行可否は本番データのコピーで検証するしかない。破壊的変更の影響範囲が agent API と event model にも及ぶため、コードの修正だけで済むのか、保存済みの対話履歴にも手当てが要るのかを先に切り分ける必要がある。

モデル抽象化だけが目的なら、ADK は重すぎる

ADK はモデル非依存を掲げているが、README が挙げる機能の重心は Workflow Runtime と Task API にある。複数プロバイダのモデルを同じインターフェースで呼びたいだけの用途では、グラフ実行エンジン、状態管理、ツール確認フローは使わないまま依存だけが増える。同じ Python のエージェントフレームワークでも、LangGraph は状態を持つグラフを明示的に組み立てる点で近いが、ADK は edges の宣言に加えて Task API による委譲単位と、Agent Config によるノーコード定義、adk web の開発 UI までを 1 つの配布物に含める。軽量なモデル呼び出しのラッパーが欲しい場合、この同梱物の多さは利点ではなく導入時の検討事項になる。どの機能を使わないかを決められないなら、この依存は選ばないほうがよい。

ライセンスと保守コスト: Apache-2.0 と隔週リリースの意味

ライセンスは Apache-2.0。特許条項を含む寛容なライセンスで、商用利用や改変、再配布が許される。ただし本記事は法的助言ではない。自組織のポリシーに照らした確認は別途必要になる。保守の観点で見るべきは、リリース間隔がおよそ 2 週間ごとと README に書かれている点だ。このペースは修正が早く入ることを意味する一方、依存バージョンの更新も同じ頻度で発生しうる。制約ファイルが Python 3.10 から 3.14 向けに用意されているのは、この更新を吸収するための仕組みだと読める。バージョンを固定して四半期ごとに上げる運用にするなら、constraints-3.10.txt のような制約ファイルをリポジトリに取り込んでおき、更新時に差分を確認する流れになる。破壊的変更がセッションスキーマに及ぶ以上、アップグレード手順にはデータの読み込み確認を 1 ステップとして組み込む必要がある。

編集部の結論

ADK 2.0 を採用すべきなのは、エージェントの制御フローを Python のコードとしてバージョン管理したいチームと、Cloud Run か Vertex AI Agent Engine のどちらかにデプロイ先を寄せる前提がすでにあるチームだ。採用すべきでないのは、1.28 より前の ADK で生成したセッションデータを保持したままアップグレードする必要がある場合と、モデル呼び出しの抽象化だけが目的でグラフ実行エンジンを必要としない場合である。導入前に確認するのは 3 点。自分の Python バージョンに対応する constraints-3.10.txt などの制約ファイルが取得できるか。pip install google-adk -c constraints-3.10.txt で依存解決が通るか。そして既存セッションのスキーマが 2.0 の読み込みで壊れないかを、本番データのコピーで先に確かめること。この 3 つが通らない限り、2.0 系への移行は後戻りのコストを伴う。

公式情報源

1. google/adk-python on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases