デモでは完璧に動いていたエージェントが、本番に出した途端に無限ループに陥ったり、あり得ない分岐へ迷い込んだりする。ADK 2.0の開発チームが記事で率直に語っているのは、こうした失敗の経験則だ。

なぜプロトタイプは本番で壊れるのか

プロトタイプ段階では、想定した入力に対してモデルがそれらしい応答を返せば十分に見える。しかし本番運用では、モデルが幻覚を起こして誤った分岐を選ぶ、例外が起きたときの後処理がない、同じ思考ループを繰り返して終わらない、といった問題が現実の頻度で発生する。記事はこれを他人事の失敗談としてではなく、Google自身が直面した課題として書いている点が誠実だ。

決定論とモデルの柔軟性の綱引き

ADK 2.0が導入したのは、ワークフローの骨格部分は決定論的な制御構造で固定し、判断が必要な部分にだけモデルの柔軟性を委ねるという役割分担だ。ルーティング、スケジューリング、リトライやエラー処理をLLMの気まぐれな出力に委ねず、通常のコードで囲うという発想は、実は目新しいものではない。ワークフローオーケストレーションの世界でTemporalやAirflowのようなツールが長年やってきたことと構造的には近く、AIエージェントの世界にもようやく同じ考え方が輸入されてきたと見ることができる。

実務で置き換わる作業のイメージ

たとえば、経費精算エージェントが一定額を超える申請に対して人間の承認を挟む、といった業務フローを考えると分かりやすい。モデル任せの実装では「承認を求めるべきタイミング」の判断自体がぶれてしまう可能性があるが、決定論的な制御構造の中に承認ステップを組み込んでおけば、モデルの気分に左右されず必ず止まる。ADK 2.0が目指しているのは、まさにこの種の「絶対に外してはいけない業務ルール」を構造として保証することだ。具体的なAPI設計や各言語への対応状況は、Google Developers Blogの記事(https://developers.googleblog.com/why-we-built-adk-20/)にまとめられている。