Google Cloud、Agent Runtimeに不変のバージョンとパーセンテージベースのルーティングを提供

Why it matters

Agent deployments need the same rollback and canary-release controls as other production software. Google is building those controls into its managed runtime, with Preview-stage limits and added capacity costs.

Google Cloud は7月6日までに Agent Runtime に、不変のリビジョンとパーセンテージベースのトラフィック分割を追加しました。これにより開発者は、実行中のエンジン、リソース名、またはエンドポイントを置き換えることなく新しいエージェントコードをリリースできるようになりました。

この機能は月曜に Google Cloud Tech post on X で改めて取り上げられ、Dani Zamora が公開した technical walkthrough の約1か月後に再浮上しました。タイミングが重要なのは、Google がマネージドなエージェント基盤を、従来のクラウドアプリケーションで既に標準となっているリリース制御を必要とするワークロードに向けて位置づけているためです。

Google の実装は、開発者がバージョン管理されたフィールドを変更するたびに不変のスナップショットを作成します。これらのフィールドには、パッケージ化されたコード、依存関係、Python バージョン、環境変数、スケーリング制限、コンテナの同時実行数、アイデンティティ構成、エージェントカードなどが含まれます。古いリビジョンは、廃止または削除されるまで利用可能なままです。

エンドポイントは固定されたまま、背後にあるリビジョン間でトラフィックが移動します。開発者はすべてのリクエストを最新バージョンに向けることも、手動でパーセンテージ分割を設定することもでき、割り当ては合計で100%になる必要があります。チームは例えばリクエストの10%を新しいコードに送ってその挙動を既存のリリースと比較し、割合を徐々に増やして別のデプロイを作成せずにトラフィックをロールバックすることもできます。

この仕組みにより、エージェントのアップデートは計測可能な本番実験になります。モデルを切り替えたり、指示を作り直したり、ツールを追加したり、オーケストレーションコードを変更したりすると、エージェントの挙動は実質的に変わり得ます。安定したエンドポイントと並行するリビジョンにより、開発者は即時にフリート全体を置き換えるのではなく、ライブトラフィック上でレイテンシ、タスク完了率、ツールの失敗、ユーザーの嗜好などを比較できます。

エージェントの状態を中心に据えたリリースシステム

Agent Runtime（以前は Agent Engine と呼ばれていた）は、エージェントコードをコンテナにパッケージ化し、Google Cloud がマネージドセッション、メモリ、スケーリング、コード実行、アイデンティティ、可観測性、プライベートネットワーキングなどのインフラを扱います。リビジョンはそのマネージドレイヤーをソフトウェアデリバリへと拡張します。

Zamora の例では、研究用エージェントの2つのバージョンを同じエンジンにデプロイしました。最初のバージョンは Google Search を使って迅速なブリーフィングを生成しました。2つ目はより遅い Deep Research ジョブを開始し、レポートを取得するためのハンドルを返しました。Zamora は1つの URL を維持したまま、その2つのバージョン間でトラフィックを分割しました。

50-50 設定で行った12件のテストリクエストでは、7件がより高速なバージョンに到達し、5件がより深いリサーチプロセスを開始しました。この小さなサンプルはパフォーマンスを確定するものではありませんが、ルーティングモデルを示しています：異なるエージェント実装が同一の本番リソースの背後で同時に動作し得る、ということです。

Google は付随するコードを open-source demonstration repository に公開しており、エンジンの作成、リビジョンでの更新、リビジョン一覧表示、Vertex AI SDK を通じたトラフィック割り当ての変更のためのスクリプトが含まれます。

そのウォークスルーは、開発者が予算に組み込む必要のある容量制約も露呈しています。手動のトラフィック分割は、対象となるすべてのリビジョンをウォームな状態に保ちます。Zamora の最初の試行は、デプロイがインスタンスを1つしか許可していなかったため失敗し、2つ目のリビジョンに割り当てる容量がありませんでした。インスタンスの範囲を増やすことで失敗は解消されました。つまり、安全なロールアウトはテスト期間中に追加の稼働容量を要求することがあります。

トラフィック設定自体はバージョン管理されません。分割を変更すると、既存のリビジョン間でコードを出荷したり別のスナップショットを作成したりすることなくリクエストが再ルーティングされます。Google はまた、古いリビジョンを廃止または削除しておかないとクォータを消費したり、陳腐化したコードや潜在的なセキュリティ問題を抱えたままアクセス可能になったりする旨を開発者に警告しています。

Google はまだインターフェイスをテスト中

Google は revisions and traffic splitting をプレビュー機能としてラベリングしており、事前 GA 条項により管理されています。これらの制御は v1beta1 API を通じて利用可能であり、フィールド名、挙動、サポートに関する約束はまだ変更され得ます。Zamora はまた、コマンドラインのデプロイツールがまだトラフィック分割を直接公開しておらず、デモには Vertex AI SDK が必要だったと指摘しました。

この追加により、開発者がプロトタイプを終えた後に誰が本番エージェントを運用するかを巡るクラウドプラットフォームの競争において、Google はより深く関与することになります。Amazon Bedrock AgentCore は分離されたユーザーセッションを備えたマネージドランタイムを提供し、Microsoft Foundry Agent Service はコンテナ化されたエージェントコードをマネージドスケーリング、セッション持続性、アイデンティティ、可観測性とともに実行します。

リビジョン制御は新しいモデルのリリースほど目立ちませんが、エージェントが本番運用に耐えうるかを左右する運用作業に対処します。Google Cloud は、エンドポイントとワークロード周辺のステートフルなインフラを維持しつつ、エージェントコードをパッチ適用し、競合する挙動をテストし、失敗したリリースを元に戻すための制御されたパスをチームに提供しています。