想像してみてください。
エージェントに 5 つのツールと 1 つの指示を与えたとします。
返金プロセスは完璧に動くかもしれません。
ところが、確認メールの送信が失敗します。
エージェントはシーケンスを最初からやり直し、すでに成功したアクションを繰り返します。
結果は？二重返金です。
プロトタイプは完璧に動作しました。本番システムはそうではありませんでした。
問題はプロンプトではありません。
問題は、そもそもモデルに実行させるべきではないプロセスを走らせていることです！
LLM は常にルーティング、スケジューリング、エラー管理を強いられています。
こうしたタスクは、標準的なソフトウェアなら、すでに完璧な予測可能性で処理できます。
それなのに、私たちは AI に 2 つの相反する役割を課しています：
- 世界を読む：予測不可能で非構造化されたデータを理解する
- プロセスを実行する：厳格で事前定義された一連のイベントを調整する
前者は AI が最も輝く分野です。後者は従来のコードが担うべき領域です。
次のステップがすでに分かっているなら、モデルに推測させるべきではありません。
1 つの自律エージェントに 5 つのツールと 1 つの大きな指示を与えた場合を想像してください：
→ 購入履歴を取得する
→ 返金ポリシーを確認する
→ 条件を満たしていれば返金を実行する
→ メールを送信する
→ チケットをクローズする
これをやり遂げるには、エージェントはシーケンスを覚え、すべてのツール結果を確認し、次に何が来るかを推測しなければなりません。
返金が実行された後に確認メールが失敗すると、モデルは安全な実行状態から再開する代わりに、コンテキストウィンドウからワークフローを再構築しようとします。
結果は、先ほど触れた二重返金です。
ADK 2.0 がカオスに秩序をもたらす仕組み
Google の ADK 2.0 は、まったく新しいアプローチでこの問題を解決します。
予測可能なアクションを具体的なワークフローステップに戻し、実際に解釈が必要な箇所にのみ AI を挿入します。
[返金ワークフロー図 - 出典：「ADK 2.0 を開発した理由」]
上記の例では、購入履歴の取得、返金の実行、チケットのクローズは通常のソフトウェアアクションです。
クレームの分析とパーソナライズされた確認メッセージの作成は AI に任されます。
結果は美しいハイブリッドです。固定された実行と、焦点を絞った推論の融合です。
でも、こう思うかもしれません。これは単に硬直した自動化への回帰ではないか？
エージェントが置き換えるはずだったワークフローそのものをハードコーディングしているだけではないのか？
まあ、そうでもありません。
ワークフローは、すでに分かっている境界を定義します。
エージェントは引き続き、解釈、言語、判断を必要とする部分を処理します。
目標は柔軟性を取り除くことではなく、毎回の実行でモデルに同じ実行パスを再発見させ続けるのをやめることです。
不要なモデル判断を排除することで、このアーキテクチャはコスト計算を根本的に変えます。
同じ返金ワークフロー。同じモデル。
しかし ADK 2.0 では、トークン数が 5,152 から 2,265 に減少し、レイテンシーが 7.2 秒から 5.7 秒に短縮されました 🔥
[出典：「ADK 2.0 を開発した理由」]
この構造は自然なフィルターとして機能し、トークン使用量を半分に削減します。
履歴全体を渡す代わりに、エージェントは必要なものだけを参照します（例：ポリシーエージェントはクレームのみを参照）。
メリットはすぐに現れます：
- プロンプトのノイズが減り、プライバシーが向上
- 厳密に制約された実行
- フェイルセーフ：モデルが誤った判断を下すことはあっても、独自のルートを編み出すことは決してできません
フロントエンドにも境界が必要：A2UI が UI を制御下に置く仕組み
素晴らしい。返金ワークフローは制御下に置かれました。
ADK 2.0 はパスを定義し、エージェントが独自のシーケンスを編み出すのを防ぎました。
しかし、ユーザーには、エージェントが生成した結果を安全に確認して操作する方法がまだ必要です。
言い換えれば、フロントエンドにも境界が必要なのです！
承認されたすべての返金に、上長の承認が必要になったと想像してください。
エージェントは、「この返金は承認されました。」 というテキストを単純に生成すべきではありません。
代わりに、以下の内容を含む構造化カードを表示する必要があります：
- 金額
- 取引
- ポリシー上の理由
- 明確な「承認 / 拒否」ボタン
ここでまさに、Google の A2UI の出番です！
A2UI では、エージェントは実行可能なフロントエンドコードではなく、宣言的な JSON ペイロードを返します。
ホスト側はそのペイロードを検証し、カタログでサポートされているコンポーネントのみをレンダリングします。
エージェントは表示する情報を決定し、アプリはそのレンダリング方法を制御します。
👇 以下は A2UI でレンダリングされたカードの例で、A2UI が実現できる多彩な UI 構成を示しています：
Google の A2UI-over-MCP Recipe Studio デモは、このアーキテクチャの実際の動作を示しています：
出典：Google Developers Blog。
👆 静的な選択フォームは MCP Resource を介して配信され、動的に生成されたレシピカードは MCP Tool を介して返されることがわかります。
A2UI はその両方をホストアプリケーション内でネイティブにレンダリングします。
この対称性に気づきましたか？
- ADK 2.0 は、バックエンドでエージェントができることを制約します
- A2UI は、フロントエンドでエージェントが作成できるものを制約します
どちらの場合も、モデルには推論の余地がありますが、それはアプリケーションが定義した境界内に限られます。
先ほどの返金の例に戻ると、標準的な返金にはシンプルな承認カードだけで十分かもしれません。
しかし、例外、添付ファイル、部分返済などを伴う紛争ケースでは、よりリッチな体験が必要になる場合があります。
そこで MCP App が登場し、複雑なインタラクションのための閉じたワークスペースを提供します：
→ ADK は起こり得ることを制御する
→ A2UI は結果を見える化し、操作可能にする
→ MCP Apps は複雑なワークスペースを処理する
もっと詳しく知りたいですか？
ADK 2.0、A2UI、そして Google Cloud のより広範なエージェントプラットフォームを探索するために必要なものは、すべてここにあります：
- ADK 2.0：https://fandf.co/4yJhcyh
- A2UI：https://fandf.co/3S1O9pe
- A2UI over MCP：https://fandf.co/45vomJ3
- Gemini Enterprise Agent Platform：https://fandf.co/4x59VY7
このプロジェクトで @googlecloud と提携できたことは、大変光栄でした！🤝
LLM、AI エージェント、ワークフローの最新情報をチェックしたい方は、@datachaz をフォローしてください。毎日のインサイトを発信しています。
