人間がメインで執筆しています。
ADK 2.0 とは？
ADK は Google のエージェント開発フレームワークです。初出は 2025 年 4 月の Cloud Next '25 なので、フレームワーク自体は今年発表されたものではありません。今年は「2.0」が発表され、2026 年 4 月の Next '26 で launch、Python 版 v2.0.0 が I/O '26 期間中の 2026-05-19 に GA されました。Next で発表され I/O で GA された、という流れです。
2.0 の中核は 3 つです。
- Flexible Execution Graphs — 非線形・条件分岐・循環を含むエージェント実行を、モデル非依存のエンジンで束ねる「実行グラフ」。
- Intelligent Task Delegation — 並列サブエージェント、入れ子のチーム、動的スケジューリング。
- Native Inter-Agent Routing — エージェント間のメッセージ・状態受け渡し・コンテキスト伝播をフレームワークが仕切る。
加えて Automatic Retries（RetryConfig）、Human-in-the-Loop（ワークフローの一時停止・再開）、そして永続化（framework 管理）の機能も考慮されています。かなり大きなアップデートだと思います。
ADK 1.x と何が変わったのか
1.x にも Sequential / Parallel / Loop という workflow agent はありました。順番に呼ぶ・並列に呼ぶ・繰り返す、くらいの構造は組めました。ただし、あくまで LLM 主体の非決定論的なものであり、決定論的で複雑なワークフローを書けるものではありませんでした。2.0 の Workflow Runtime ではこれができるようになったのが大きいです。
特に、後述する Graph 構造をベースにした設計は、LangGraph などグラフでエージェントを組む流れの中にあり、もっと基礎的なコンピュータサイエンスとしてのグラフにも通じていて、美しいなと思います。
Static graphs と Dynamic workflows
2.0 では、ワークフローの実装方法が 2 通り用意されています。
Static graphs（＝ Flexible Execution Graphs） は、ノードとエッジを宣言して流れを組む書き方です。分岐・ループ・条件を「構造」として書き下します。マルチステップだが流れが決まっているプロセスに強いです。良さは、流れが構造として固定されること。予測可能で、図にもしやすいです。裏返すと、型にはめるぶん自由度は制限されます。
Dynamic workflows は、while ループ・async/await・再帰を普通のコードで書く方法です。反復ループや込み入った分岐で static graph では自由度が足りない時に有効です
なぜ 2 つ用意されているかというのは、示唆に富んでいて面白いなと思います。公式は「どちらが優れているかではなく、use-case で選びましょう」と言っており、この２つの方法に以下のようなトレードオフがあることがわかります。
自由・表現力 ◀━━━━━━━━━━━━━━▶ 扱いやすさ・予測可能
dynamic workflows static graph
while/async/再帰を ノード＋エッジを宣言
普通にコードで書く
この２つの記法のトレードオフを考える上で、最近バズワードになっているループエンジニアリングに触れてみると面白いので、ご紹介します。
ループエンジニアリングとは？
「ループエンジニアリング」の元ネタは Addy Osmani さんの Loop Engineering という記事です。
大きな主張としては、以下のように Osmani さんが書いてくれています。
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
（エージェントに直接プロンプトするのはもうやめろ。エージェントをプロンプトするループを設計しろ）
毎回人間がプロンプトを打つのではなく、一度ループを設計したら、あとは人間が関与しなくても回るようにしよう、という話です。Automations（スケジュール実行）・Worktrees（並列時の隔離）・Skills（知識の明文化）・Connectors（外部接続）・Sub-agents（作者と検証者の分離）・State（会話の外の永続記憶）といった、今のパラダイムの要素を組み合わせたベストプラクティス、という側面が強いです。
ループエンジニアリングについては、日本語でもいろいろな方が解説記事を出されているので、詳細の解説はそちらに譲ります。
ループエンジニアリングのトレードオフと ADK 2.0 の解決策
ここが本題です。ループエンジニアリングという「AI をワークフローに縛らず、AI の判断でループを回させる」構造は、かっこいいし聞こえはいいのですが、明確なトレードオフを抱えています。「プロンプトエンジニアリング」「コンテキストエンジニアリング」が "とりあえずやっとけば精度が上がる" 感じだったのに対して、ループエンジニアリングは手放しでやろう！というものではないです。
ループエンジニアリングには、以下のようなデメリットがあります。
- モデル精度が高いことが前提。Agent が連鎖的に動作する関係上、そのシステム全体の成功率は、各 Agent の精度の掛け算になります。なので、一部だけ安いモデルにする、とかは難しく、ちゃんと運用するなら Fable 5 や Opus 4.8 のような高精度モデルの使用が前提になると考えていいと思います。もちろんコストもかさみます。
- 実装とチューニングが重い。汎用な自由ループを安定させるプロンプト調整のコストは、かなり重いと思います。一つのプロンプトのチューニングがシステム全体の精度に大きく影響するので、大量のトライアンドエラーが必要になるかと思います。
ADK 2.0 が素晴らしいと思ったのは、このような AI エージェント設計におけるトレードオフを前提として、選択肢を与えてくれている点です。
static graph を使用すれば、ワークフローの流れをある程度固定し、扱いやすい方向に倒すこともできます。
これは私個人の考えですが、AI エージェント設計において、その AI エージェントアプリケーションは特定のドメインやユーザーのイベントに紐づいているはずであり、そのドメイン知識を使用すれば、ある程度、決定論的で具体的なワークフローが構成できるはずです。そのような考え方に基づくと、static graph はとても素晴らしい選択肢になります。
そして static graph の自由度に限界を感じる場合は、dynamic を使用して自由を高く保つという選択肢が用意されています。
ADK 2.0 を使ってもマネージドに解決されない部分
ADK 2.0 では面倒な部分を勝手にやってくれますが、意識する必要がある部分もあると思います。
まず、sub agent ごとのコンテキストのチューニングについてです。ADK では state を app:（全 user 共有）/ user:（user 横断）/ temp:（invocation 内のみ）/ 無印（session 内）という prefix で scope 制御する仕組みがありますが、これは「どこまで永続化するか」を指定するもので、「誰に何を見せるか」ではありません。
実際、同一 session 内では全 agent が full state を共有します。「このレビュアーには題材の要約だけ渡して本文は見せない」といった per-agent のコンテキスト可視性の絞り込みは、標準機構として存在しないようです。LLM はコンテキストの流れに合わせてしまう等の性質がある以上、コンテキストの範囲のチューニングは重要と考えており、ADK 2.0 を使う上でもここは意識したほうがいいなと感じました。
つくってみたもの
ADK 2.0 を使って、30 分くらいで AI に手伝ってもらってデモを作ったので、ご紹介します。
「テーマを入力したら、そのテーマの記事のタイトルと構成を考える」というシンプルなアプリケーションですが、このくらいであればサクッと作れるのは ADK 2.0 素晴らしいなって思いました。
感想
僕は ADK 2.0 好きだなって思いました。AI エージェントと言っても多くのユースケースがある中で、ADK 2.0 が提案してくれている解決策は、多くのユースケースにシンプルに対応していると思います。
ループエンジニアリングに全部乗るべきか、それともドメインを絞ってワークフローを固定するかで悩んでいる人こそ、static graph と dynamic を両方持つ ADK 2.0 を触ってみると、判断の解像度が上がると思います。ぜひ AI エージェントを構築するときは試してみていただきたいです。