ADK 2.0は、AIエージェントに任せすぎていた実行制御をコード側へ戻し、必要な場面だけLLMを使うための実装基盤です。2026年7月1日に公開されたGoogleの解説では、graph-based workflows、dynamic workflows、human-in-the-loopを中核に据え、試作止まりのエージェントを本番運用へ持っていく方向性が明確になりました。業務導入の観点では「どこを固定フローにし、どこだけAIに判断させるか」を設計しやすくなった点が最大の変化です。
ADK 2.0の結論: LLMに実行順を決めさせない設計へ移る
Googleの公式ブログは、従来の自律型エージェントでは routing、scheduling、error handling までLLMが抱え込み、無限ループや手順飛ばし、例外の見落としが起きやすいと整理しています。ADK 2.0では execution routing を workflow runtime に分離し、曖昧な判断だけをAIに任せる形へ寄せました。つまり、業務フローがA→B→Cで決まっているなら、その遷移はコードで固定し、メール文面の要約や例外判定のような非構造部分だけをLLMノードにする考え方です。
何が新しい？ graph workflowsとdynamic workflowsの2本立て
公式ドキュメントでは、ADK 2.0の新機能として graph-based workflows が "New in ADK 2.0!" と明記されています。graph workflows は、Function、Tool、Agent、Human input などのノードを明示的な edge で結び、条件分岐や fan-out/fan-in をコードで表現する仕組みです。一方で dynamic workflows は、loop、conditionals、recursion のように静的グラフでは扱いづらい制御を、Pythonなら async/await、Goなら通常の control flow で書けます。単純な承認フローなら graph、再試行やサブタスクの繰り返しが多いなら dynamic という使い分けがしやすくなりました。
自律エージェント運用と比べて何が改善するか
Googleがブログ内で示した返金処理の例では、Vanilla LLM Agent が 5,152 tokens / 7.2秒、ADK 2.0 Workflow が 2,265 tokens / 5.7秒という illustrative benchmark results になっており、トークン約50%削減、遅延約20%削減のイメージが示されています。これは実測保証ではありませんが、少なくとも Google 自身が「中間の遷移判断をLLMに何度もさせるコスト」を問題視していることは明確です。コスト削減だけでなく、長い tool output がそのまま会話履歴に積み上がる context bloat を抑えやすい点も、本番運用では重要です。
業務実装で先に設計したい3つのポイント
第1に、固定すべき工程を切り出すことです。申請受付、DB照会、決済実行、CRM更新のように順序が決まる部分は deterministic node に寄せます。第2に、AI判断が必要な工程を狭く定義することです。クレーム文面の分類、例外理由の要約、返信メールの下書きなどは single-turn agent に閉じ込めると扱いやすくなります。第3に、状態の受け渡しを最小化することです。ADKの公式ドキュメントでも strict state boundaries や typed input/output を強調しており、全部の履歴を次ノードへ渡さない設計が安定運用の前提になります。
HITLと再開性は、社内承認フローとの相性が良い
ADK Go 2.0の発表では、human-in-the-loop を built-in primitive として扱い、実行中に承認待ちへ入ったグラフをあとで再開できると説明されています。これは経理承認、法務確認、対外送信のレビューなど、人が最後に責任を持つ企業フローと相性が良い設計です。さらに dynamic workflows では checkpointing により、再開時に成功済みノードを自動スキップできるとされています。つまり、長い業務フローを丸ごとやり直すのではなく、止まった地点から続ける設計を標準機能で持てるのがADK 2.0の強みです。
導入手順: まずは1業務をgraph化してから広げる
最初の対象には、例外はあるが基本フローは固定されている業務を選ぶのが安全です。たとえば問い合わせ一次振り分け、返金審査、見積もり作成、社内申請レビューなどが候補になります。1. 現行業務をA→B→Cで書き出す。2. その中でAIが必要な判断だけを抽出する。3. graph workflow で固定遷移を実装する。4. ループや再試行が複雑なら dynamic workflow に切り出す。5. 承認や確認が必要な箇所に HITL を入れる。この順で始めると、いきなりフル自律の multi-agent にせず、費用対効果を見ながら拡張できます。
注意点: 公式の数値は参考値であり、そのまま鵜呑みにはしない
今回確認できた性能数値は、Googleブログ内でも gemini-3.5-flash と mock API responses を使った illustrative benchmark results と書かれていました。したがって、全業務で同じ削減率が出ると断定するのは危険です。また、ADK 2.0は Python と Go で workflow 機能が強化されていますが、既存システムへの組み込みや監査ログ要件、権限設計は別途詰める必要があります。記事や提案書では「業務フローを deterministic に分解できるか」を先に評価し、その後にフレームワーク選定へ進む方が失敗しにくいでしょう。
ADK 2.0を使って、どの業務を固定フロー化し、どこだけAI判断に任せるべきか迷う場合は、 無料相談はこちら 。既存の承認フローや監査要件を踏まえて、PoCで止まらない導入設計を一緒に整理できます。
