これはGoogle Cloud NEXT Writing Challengeへの投稿です
Google Cloud NEXT '26は、ほとんどの開発者がまだ準備できていない問題を、ひっそりと持ち込んできました。
あなたのシステムはもう、バグが原因で失敗することはありません。
失敗するのは、エージェントが下した“もっともらしい判断”が、結果的に間違っていたときです。
この違いは些細に聞こえるかもしれません。
でも、違います。
信じてください。これは本当に面倒なやつなので、こう言っているのです。私はGemini 3 HackathonとGemini Live Agent Challengeの両方で働いたことがあり、そうした罠に落ちやすいことを知っています。
この記事では、Googleが実際にステージで示した内容を使って、その変化を解説します：
- エージェント開発キット（ADK）が開発をどう変えるか
- マルチエージェントシステムが本番環境でどう振る舞うか
- そしてGemini Cloud Assistが、あなたのデバッグの“レイヤー”になること
コードを書く、そしてそのコードが行動する
基調講演はインフラやAPIから始まりません。もっと不穏なものから始まります。
音楽はAIで生成されます。映像はライブでレンダリングされます。
そして、その映像は？ 音声入力をもとに、Geminiがリアルタイムに書いたコードによって生成されます。
これが、基調講演の残りが従うパターンです。
しかし、より重要なのは、私たちが今からデバッグしなければならないのも、このパターンだということです。
開始から02:00までは映像を確認できます。これはVeo、Nano Banana、Gemini Flash Liveを使って作成され、すべてMusic AI Sandboxで行われています。
ADK：もはやロジックを書いていない
すべての中心にあるのが、エージェント開発キット（ADK）です。
一見すると単なる別のフレームワークに見えます。ですが、本質的に何かが変わります。もはや“物事がどう起きるか”を定義しません。
あなたが定義するのは：
- エージェントにやらせること
- エージェントがアクセスできるツール
- エージェントが使える知識
そして…あなたはそれを“決めさせる”。
基調講演の間、RichardとEmmaはMarathon Planner Agentを構築しました。関数でもありません。サービスでもありません。エージェントです。
エージェントには以下が与えられます：
指示（マラソンのルートを計画する）
ツール（MCP経由のGoogle Maps）
スキル（GISロジック、レース計画ルール）
そこから先は、エージェントが考えて組み立てます。
明示的な制御フローはありません。手順ごとのオーケストレーションもありません。
些細だが危険な転換
通常のシステムなら、何かがうまくいかなかったときに、どこを見ればいいか分かります。ADKベースのシステムでは：
- エージェントが間違ったツールを選ぶかもしれない
- 正しいツールを誤って使うかもしれない
- プロンプトを別の意味で解釈するかもしれない
- 文脈を予想外の組み合わせで扱うかもしれない
- まだ私たちが把握できていない、新しい種類の問題が起きるかもしれない
“厳密に”壊れているわけではありません。単に…間違った振る舞いをするのです。
1人のエージェントでは足りないとき
デモはすぐに、単一のエージェントを超えて進化します。すべてを1人のエージェントにやらせるのではなく、責任を分割したのです：
- プランナーエージェントがルート案を提示する
- 評価者エージェントがそれを採点する
- シミュレーターエージェントが世界を実行する
ここからは、ソフトウェアというより共同作業者のシステムに見えてきます。これらのエージェントはAPIを直接呼び出しません。代わりに互いを見つけます。
Googleは次を導入します：
- A2A（Agent-to-Agentプロトコル） => エージェント間の通信方法
- エージェントレジストリ => エージェントがお互いを見つける方法
エージェントにとってのDNSだと思ってください。
最も過小評価されている機能：エージェントが自分でUIを作る
基調講演の中でも特に面白い瞬間のひとつは、見落とされがちです。
UIは手作業で構築されません。エージェントが生成します。A2UIと呼ばれる仕組みを使って、エージェントは：
- 結果をどう表示するべきかを決める
- コンポーネントを構築する
- それらを動的にレンダリングする
これにより、開発の一層まるごとが不要になります。
コンテキストエンジニアリングこそが、システムを壊す
システムが進化するにつれて、より多くのデータが投入されます：
- 市の規制
- 交通の制約
- 過去のパターン
これは次で扱われます：
- セッション（相互作用をまたいだ状態）
- メモリ（長期的な知識）
- RAG（データベースからの検索）
エージェントは、より賢く振る舞い始めます。
その一方で、ずっと脆くもなります。ある時点でエージェントは学習しました：「公共の道路にラクダを置くわけにはいかない」
単独で見れば笑えます。でも、そのルールがルート計画に影響すると致命的です。
デバッグは機械的ではなくなる
従来のシステムなら、あなたは：
- ログを見る
- スタックトレースを調べる
- コードを直す
ですが、ここではそれらはどれも十分ではありません。あなたは答える必要があります：
- なぜエージェントはこのツールを選んだのか？
- なぜこの文脈を引き継いだのか？
- なぜメモリが制御不能に増えてしまったのか？
これはコードのデバッグではありません。推論のデバッグです。
Gemini Cloud Assist：本当のイノベーション
Googleの答えは、より良いログではありません。あなたのAIシステムをデバッグするAIシステムです。Gemini Cloud Assistは、次のように振る舞います：
- 捜査官
- デバッガ
- インフラオペレーター
- コードアシスタント
失敗が起きると、それは：
- ログを分析する
- トレースを確認する
- あなたのコードを読む
- インフラの問題を関連付ける
- 根本原因を特定する
そして、修正案を提案します。
何が実際に壊したのか？
デモにおける根本原因：
- コンテキストが大きくなりすぎた
- Geminiのトークン上限を超えた
- イベントのコンパクションが十分に頻繁ではなかった
修正は書き直しではありませんでした。行動（振る舞い）の調整です：
- コンテキストをより頻繁に圧縮する
- 1ステップあたりのメモリ使用量を減らす
すべて問題ありません。
さて、ここまでの導入の後で私があなたを放置すると思いました？
ここまででできることを見てきました。では、いよいよそれを使う番です
これまで話してきたことは、すべてキーノートの中の話でした。
すごいデモです。凝った仕組みです。「すごい！エージェントだ！」
でも、それらが実際に“そのように振る舞う”何かを構築できるかどうかで決まります。
そこで、「マルチエージェント、クラウドネイティブ、分散型の魔法」へいきなり飛び込む代わりに…小さく始めます。制御された形で。理解できる形で。
私たちは、次のようなシステムを作ります：
- エージェントが意思決定をする
- その意思決定が、実際の何かに影響する
- そして、そのインパクトを視覚的に見ることができる
ステップ1：世界を定義する
Geminiを投入する前に、意思決定に反応できるシステムが必要です。
なので、簡単なシミュレーションを作ります：
- ルート（座標の連続）
- そのルートに沿って動くランナー
- 時間経過における彼らの位置の可視化
この段階では、すべてが決定論的です。
次に、これを密なパスに変換します：
そしてランナーをシミュレートします：
各ランナー：
- わずかに異なる速度で動く
- 少しのランダム性を持つ
- 他のランナーと完全には重ならない
これにより、すでに“レースっぽく”見えるものが手に入ります。
ステップ2：Geminiを投入する
いよいよ重要なパートです。Geminiに座標を生成させようとはしません。
それは罠です。
代わりに、制約をかけます。いくつかのルートテンプレートを定義します：
これでGeminiの役割は単純です：ルートのタイプを選ぶ。
ステップ3：プランナーエージェント
ここでやったことに注目してください：
- 出力できる領域を制限した
- 解析（パース）の地獄を避けた
- システムを予測可能なまま保った
これこそが、LLMをシステムで使うときの正しいやり方です。
ステップ4：意思決定 => 振る舞いをつなぐ
では、すべてを配線しましょう：
あなたが実際に見ているもの
これは次を表しています：
- 位置 => ランナーが今どこにいるか
- 色 => どれだけ進んだか
- 形 => Geminiが選んだルート
プロンプトを変えれば、ルートが変わります。ルートを変えれば、分布全体が変わります。
カーブしたパスの選択：
ステップ5：壊れたとき（でも何も壊れているようには見えなかった）
ある時点で、システムは…妙な挙動をし始めました。
Geminiは、プロンプトが明らかにまっすぐなルートを好む状況であっても、常に曲がりくねったルートを選びました。
何も失敗しませんでした。
例外なし。
クラッシュなし。
警告なし。
シミュレーションは完璧に実行されました。しかし、出力分布が間違っていました。
最初は、ランダムに見えました。次にバイアスに見えました。そして最終的に、はっきりしました。モデルがプロンプト内の特定のキーワードに過剰な重みを置き、それらをルートのテンプレートに誤って対応づけていたのです。
問題はシミュレーションにありませんでした。
データにもありませんでした。
それは、エージェントが意図をどう解釈したかにありました。
これをデバッグするのは、通常のデバッグとはまったく違う感覚でした：
見るべき単一の場所がない
明確な因果関係の連鎖がない
複数回の実行で現れてくる挙動だけがある
修正はコード変更ではありませんでした。
それは：
- プロンプトを引き締めること
- 曖昧さを減らすこと
- 出力制約をより厳しくすること
システムが「正しく」なったわけではありません。
「間違い」が減ったのです。
非決定的なシステムにおけるマインドセットの転換は、こういうことです。非決定的なシステムでは、正しさは状態ではありません。
許容できる範囲内に保とうとする「幅」なのです。
なぜこれが重要か
この時点で、Geminiは「何でもやっている」わけではありません。もっと重要な何かをしています：
システムが動作する条件を決めているのです。
それが転換点です。
私たちは、振る舞いを制御する静的なコードから、AIがシステムのダイナミクスに影響を与える世界へ移行しました
いまあなたがやったこと
あなたはコードをデバッグしていません。
あなたは挙動をデバッグしました。
意思決定の領域を制約しました。
エージェントが意図をどう解釈するかを形づくりました。
システムがどれだけ間違える可能性があるかを減らしました。
それは、本質的に別のスキルです。なぜなら、これらのシステムでは正しさが保証されないからです。それは交渉されるものです。
注: これはキーノートに合わせる意図ではありません。より大きな考えを示す最小の例です。つまり、固定されたロジックを書くことから、実行時にどう振る舞うかを決めるシステムを構築することへ、という転換です。
最終的な要点
Googleは単にツールをローンチしたのではありません。次の転換を明らかにしました：
ソフトウェアはもはや決定論的な実行ではない
確率的な意思決定なのだ
つまり：
- デバッグはより難しい
- 観測可能性が極めて重要
- アーキテクチャの重要性がこれまで以上
- 最後に一言
将来いちばん難しいバグは、次のどれでもありません。
「なぜ失敗したのか？」
それは、
「なぜシステムはこれを正しいと思ったのか？」
です。
私たちは単にソフトウェアをより強力にしただけではありません。
はるかに複雑な形で誤り得る能力も持たせたのです。
いつかホットフィックスが出るのを待ちましょう：「AIパイプラインを直せ」。ありがたいことに、私たちはGoogleのスタックを使っているので、少なくともそのときは適切なツールが手元にあるはずです。
