Google GeminiのManaged Agents、自律性と制御の間にフックを設置

Google Geminiは7月28日、managed-agentスタックを刷新し、3.6 Flash、実行フック、トークン予算、スケジュールトリガー、無料枠アクセスを追加した。個々の機能は段階的な改善に見える。しかし総合すると、Googleのホステッドサンドボックスは、定期的に実行されるツール利用型の作業により適した環境となる。

対立軸はもはや、単純にGoogle Geminiと他モデルの比較ではない。マネージドインフラと、開発者が制御するオーケストレーションの競争である。Googleは、エージェントループ、リモート環境、タスク状態、スケジューリング、そして複数の運用制御を、単一のAPIを通じてチームに委ねてもらおうとしている。

この約束は、自前のワーカー、キュー、コンテナ、ポリシーレイヤーを維持するチームに圧力をかける。同時に、より難しい問いも生じる。自律エージェントがコードを実行し、ファイルを変更し、パッケージをインストールし、ネットワークへアクセスできる場合、便利なマネージドランタイムは十分な制御を提供できるのか。

Googleの答えはフックを中心に据える。これらのスクリプトまたはHTTPハンドラーは、サンドボックス内でツールが実行される直前または直後にアクティビティを検査できる。開発者にエージェントランタイム全体の再構築を強いることなく、ポリシーと検証のための介入点を追加する。

ただし、この答えはなお不完全だ。一部のフックはフェイルオープンであり、適用範囲には明確な境界があり、パブリックプレビューのソフトウェアには慎重な評価が求められる。Googleはmanaged agentsを運用しやすくしたが、自動的に安全に信頼できるものにしたわけではない。

Google Gemini、3.6 FlashをManaged-Agentのデフォルトに

重要な変更は、また一つモデルがリリースされたことではない。Googleは、モデルが長時間の作業を実行できるようにする周辺システムを強化した。

antigravity-preview-05-2026エージェントは現在、デフォルトでGemini 3.6 Flashを使用する。Googleのmanaged-agent updateによれば、既存の呼び出しはコード変更なしでこのモデルに移行する。

開発者はagent_config.modelを通じてモデルを選択することもできる。ドキュメントに記載された選択肢には、Gemini 3.6 Flash、Gemini 3.5 Flash、Gemini 3.5 Flash-Liteが含まれる。Googleは最後の選択肢を、低レイテンシーと消費量を優先するワークロード向けに位置付けている。

このデフォルトが重要なのは、マネージドエージェントが単なるモデルエンドポイント以上のものだからだ。Googleはこれを、隔離されたLinux環境内で実行される構成可能なエージェントハーネスと説明している。一度のインタラクションで、推論、コード実行、ファイル操作、パッケージのインストール、Web取得を連携させられる。

この組み合わせはリスクプロファイルを変える。従来のモデル応答は、プログラムがそれに基づいて行動する前にレビューできる。エージェントは、応答を生成する過程で結果をもたらし得る。

モデルはリポジトリを調査し、依存関係を編集し、テストを実行し、複数のステップにわたってアプローチを見直す場合がある。環境が許可すれば、ネットワークアクセスや接続済みツールも利用できる。各機能は、運用担当者が観測し制約すべき新たな対象領域を生む。

したがってGoogleの3.6 Flashデフォルトは、ループ全体に影響する。異なるモデルは、ツール選択、推論時間、エラー回復、トークン消費を変え得る。また、エージェントが運用上の制約にどれほど確実に従うかも変わり得る。

モデル選択は、開発者に限定的な逃げ道を与える。チームは最新のデフォルトを受け入れる代わりに、好みのモデルを固定できる。名前付きmanaged agentsは設定済みのモデルを維持し、インラインのインタラクションではリクエストごとにモデルを指定できる。

この違いは本番チームにとって重要であるべきだ。サイレントなデフォルトアップグレードは実験時には便利だが、デプロイ時には予測可能な動作が重要になる。評価では、本番で使用する正確なモデル、ツール、環境、指示、フック設定を対象にする必要がある。

Googleはまた、managed agentsを無料枠のプロジェクトにも開放した。開発者は、有効な課金設定のないプロジェクトでもエージェント型ワークフローを試せる。同社は計測や使用制限を撤廃したわけではないが、初期実験への障壁を下げた。

より広範なagent overviewでは、managed agentsは引き続きパブリックプレビューとされている。また、機微なワークフローで利用する前に、エージェントの行動と出力をレビューするよう助言している。

この警告は適切な枠組みを示している。7月のリリースにより、プラットフォームはよりアクセスしやすく、運用面でも充実した。しかし、自律的なコーディング環境が完成されたエンタープライズ制御基盤になったわけではない。

製品は現在、エージェントのライフサイクルのより多くをカバーしている。Googleはサンドボックスをプロビジョニングし、ループを実行し、インタラクション状態を保存し、実行ステップを公開し、バックグラウンド作業をサポートする。開発者は指示、ファイル、スキル、カスタム関数、リモートMCPサーバーを追加できる。

MCP、すなわちModel Context Protocolは、エージェントを外部ツールやデータへ接続するための標準だ。リモートMCPのサポートは、エージェントがサンドボックスの外部へ到達できる範囲を広げる。同時に、チームがレビューすべき権限も拡大する。

その結果、バンドルされたアーキテクチャが生まれる。開発者は、モデル、ツールルーター、コンテナサービス、スケジューラー、状態ストア、コールバックシステムを組み立てる代わりに、Googleのマネージドコンポーネントから始められる。

これが本稿における緊張の源泉だ。バンドル化はインフラ作業を減らす一方、重要な動作をホステッドシステムへ移す。フックは、このトレードオフの中で開発者の制御を維持しようとするGoogleの試みである。

フックがエージェントループ内にポリシーを組み込む

環境フックは、自律的な作業が実際に発生する場所、すなわちツール実行の直前・直後に、開発者へ介入レイヤーを提供する。

フックとは、ライフサイクルイベントに紐付いたカスタムコマンドまたはHTTPリクエストだ。Google Geminiは、リモートサンドボックス内でのツール実行前および実行後のイベントをサポートしている。

実行前フックは、ツール呼び出しを承認または拒否できる。リクエストを拒否した場合、ランタイムはツールをスキップし、その理由をモデルに返す。モデルは別のアプローチを選ぶか、継続できない理由を説明できる。

実行後フックはツールの完了後に実行される。完了済みのアクションを元に戻すことはできないが、ファイルの整形、テストの実行、生成されたアセットの検証、監査情報の外部送信は行える。

開発者はこれらの制御を.agents/hooks.jsonで定義する。マッチャーは特定のコンテナツールまたはツールグループを対象にする。ポリシーは、すべてのコード実行、すべてのファイル書き込み、あるいはすべてのファイルシステム操作を検査できる。

hooks documentationには、サポート対象の範囲としてコード実行と組み込みファイル操作が記載されている。これらの操作には、ファイルの読み取り、書き込み、一覧表示、削除が含まれる。

この構造はいくつかの実用的な制御点を生む。実行前スクリプトは破壊的なシェルコマンドを拒否できる。別のスクリプトは、制限されたパスへのアクセスを防いだり、提案されたファイル変更がプロジェクトポリシーに違反していないかを確認したりできる。

実行後には、フックがリンターを実行し、生成コードをスキャンし、テストを起動し、テレメトリーを記録できる。HTTPハンドラーは、集中レビューのためにイベントデータを許可リストに登録された外部サービスへ送信できる。

Googleの設計では、コマンドフックをサンドボックス内に維持する。スクリプトは標準入力を通じてイベントデータを受け取り、標準出力を通じて構造化された判断を返す。HTTPフックは、同等のイベントデータを外部HTTPSエンドポイントに送信する。

この仕組みにより、エージェントの外部で必要となるオーケストレーションコードが減る。ランタイムがフック設定を検出し、該当するハンドラーを呼び出し、その応答を待ち、拒否をモデルのコンテキストに返す。

また、順序付けられたハンドラーにも対応する。チームは、パス検証、コマンド分析、承認ログ記録など、同じツール呼び出しに複数のチェックを適用できる。1つのイベントに対して複数の一致グループを実行することも可能だ。

これは最終出力フィルターよりも有用だ。最終チェックは不適切なレポートを検出できるが、削除されたファイルや漏えいした認証情報を確実に元へ戻すことはできない。ツール実行前のゲートなら、該当するアクションを実行前に止められる。

この違いはソフトウェア保守タスクでより明確になる。エージェントは依存関係を監査し、パッケージファイルを変更し、更新をインストールし、テストスイートを実行するかもしれない。各ステップには異なる運用リスクがある。

チームは読み取りを自動的に許可しつつ、書き込みとシェルコマンドは検査できる。承認済みディレクトリ外の編集を拒否することもできる。実行後フックは、エージェントがコードを変更するたびに整形とテストを実行できる。

Googleは、AIに特化した投資銀行OffDealを初期ユーザーとして取り上げた。同社の社内エージェントは、1つのデッキに30社を超える企業ロゴを含むことがあるプレゼンテーション資料を作成する。

OffDealの創業者兼最高技術責任者によれば、エージェントが企業リストを作成した後、実行後フックが画像検証パイプラインを実行する。このパイプラインは、承認済みファイルがデッキに入る前に候補ロゴを確認する。

この例は、フックがどこで価値を加えるかを示している。モデルは、自由度の高いリサーチと制作タスクを処理する。決定論的なソフトウェアは、成果物に対して測定可能な要件を適用する。

このアプローチは、文書中心のワークフローにも適している。エージェントは更新情報を収集し、レポートを作成し、ファイルを永続的な環境に配置できる。検証フックは、必須セクション、ファイル名、ソースマニフェストを確認できる。

ナレッジワーカーはすでに、生成された資料とプライベートなコンテキストを組み合わせており、ソース追跡の重要性が高まっている。検索可能なAI knowledge baseはそのコンテキストを整理でき、フックはエージェントランタイム内の行動を統制できる。

これらのレイヤーは異なる問題を解決する。ナレッジの整理は、ユーザーによる情報の取得と解釈を支援する。実行制御は、自律ワーカーがツールやファイルで何を行えるかを定める。

フックはHTTPハンドラーを通じて外部監査パイプラインにも対応する。トラフィックはサンドボックスネットワークを通過し、環境の許可リストに準拠する必要がある。Googleはプロキシベースの認証情報注入をサポートしており、シークレットをフックファイルに置く必要はない。

この設計により、コンテナ内での認証情報の直接的な露出は抑えられる。ただし、慎重な権限設計が不要になるわけではない。エージェントは、その環境または接続先サービスを通じて利用可能にされたあらゆる権限を使用できる。

最も安全なアプローチは、引き続き最小権限である。レポート作成エージェントに必要なのは、リポジトリへの読み取りアクセスと、1つの出力ディレクトリへの書き込み権限かもしれない。広範な管理者権限が必要になることは稀だ。

フックにより、このようなポリシーを実行の近くで表現しやすくなる。それらは、アイデンティティ制御、ネットワーク制限、環境分離、レビューゲートを置き換えるものではない。より大きなシステムを構成する一つのレイヤーである。

マネージドランタイムと開発者所有のオーケストレーション

Googleが競っているのは他のモデルプロバイダーだけではなく、インフラチームがすでにモデルの周囲に構築している仕組みでもある。

新パッケージには、通常はモデルAPIの外部に存在する複数の機能が含まれる。managed agentsは、リモート環境、複数ステップの実行、保持された状態、トークン制御、スケジュール、環境管理を提供する。

GoogleのInteractions APIは、これらの要素を結び付ける。このインターフェースは通常のモデル呼び出しと、managed agentsおよびDeep Researchを含む専門エージェントをサポートする。また、バックグラウンド実行と継続的なインタラクションにも対応する。

ドキュメントによれば、Interactions APIは2026年6月に一般提供となった。Googleは新規プロジェクトにこれを推奨する一方、旧来のgenerateContentインターフェースも引き続きサポートしている。

サーバーサイドの会話状態により、呼び出し元は以前のインタラクション識別子を使用して作業を継続できる。これは、タスクが一時停止した場合、予算上限に達した場合、あるいは追加の指示が必要な場合に重要となる。

Googleの新しいmax_total_tokens設定は、自律実行に消費上限を追加する。この上限は、タスクのループ全体における入力、出力、思考トークンを対象とする。

エージェントがその上限に達すると、実行は未完了ステータスで一時停止する。環境の状態は保持される。開発者は新しい予算を設定し、以前のインタラクションから継続できる。

この仕組みは、自律型エージェントにおける基本的な問題に対処する。呼び出し側は、タスクに必要な推論やツール実行のサイクル数を予測できないことが多い。一見単純な監査でも、ファイル、依存関係、エラー、再試行へと対象が広がる可能性がある。

厳格な予算は、未知のプロセスを制限されたものに変える。エージェントがトークンを効率的に使うことを保証するわけではない。長時間のループがより多くのリソースを消費する前に、運用担当者へ停止条件を提供する。

スケジュールトリガーは、同じエージェントをオンデマンドのアシスタントから定期的に動くワーカーへと拡張する。トリガーは、エージェント、環境、プロンプト、cronスケジュールを永続リソースとして結び付ける。

Cronは、繰り返しジョブをスケジュールするための一般的な構文である。GoogleのTriggers APIは、ベータエンドポイントを通じてこれらのスケジュールを公開し、実行に失敗した場合の連続失敗回数を記録する。

各スケジュール実行では、同じサンドボックスを再利用できる。そのためファイルは実行をまたいで保持され、エージェントはスケジュールされたタスク間で作業成果物を維持できる。

この永続性は実用的なジョブを支える。エージェントは毎朝リポジトリを確認し、移行レポートを更新したり、届いた調査ファイルをレビューしたりできる。一方で、クリーンアップ方針がなければ、古いデータや機密性の高いデータを蓄積する可能性もある。

Googleは、そのライフサイクルの一部に対応するためEnvironments APIを追加した。開発者はサンドボックスセッションの一覧表示、検査、削除を行える。切断後に環境識別子を復旧したり、完了した環境を直接削除したりできる。

非アクティブな環境には、それ以外の場合、文書化された7日間の存続期間が適用される。この自動削除は無期限の永続化を抑えるが、機密性の高いワークフローにおける意図的な保持ルールの代替にはならない。

これらの機能を組み合わせることで、定期的なエージェント作業に必要な外部の接着コードを減らせる。小規模チームは、自前のコンテナランチャー、ジョブスケジューラ、状態ストア、トークン監視機構を構築する必要がなくなるかもしれない。

これがマネージドランタイムを支持する論点である。Googleが実行レイヤーを運用し、開発者はタスク、ツール、権限、データ、制御を提供する。

開発者所有のオーケストレーションは、対照的な選択肢を提示する。チームは独自のモデル、ランタイム、ポリシーエンジン、キュー、ストレージ、可観測性システムを選択できる。その代わり、あらゆる統合障害と運用負荷を自ら担う。

どちらの道筋も、すべてのワークロードに適するわけではない。規制対象のプロセスでは、パブリックプレビューのサービスを超える制御が求められる場合がある。プロトタイプや範囲の限定された社内タスクでは、単一のマネージドインターフェースから大きな利益を得られる可能性がある。

Google自身のVertex AIポートフォリオは、この区分を示している。Agent Engineは、エージェントのデプロイとスケーリングのためのマネージドランタイムを提供し、セッション、メモリ、評価、関連運用向けのサービスを備える。

Gemini API managed agentsは、Antigravity agentとInteractions APIをより直接的に利用する開発者向けの経路を提供する。Vertex AIは、より広範な本番デプロイメントとエンタープライズインフラ要件を対象とする。

この重複は購入者を混乱させる可能性がある。チームは、すぐに使えるエージェントハーネス、汎用的なエージェントデプロイメントプラットフォーム、あるいはカスタムのオーケストレーションスタックのどれが必要かを判断しなければならない。

7月のアップデートは、最初の選択肢を明確にする。Google Geminiは現在、マネージドオーケストレーションが既存スタックの一部を置き換えられるかを開発者が検証するのに十分な組み込みライフサイクル支援を提供している。

競合各社も、同じアーキテクチャ層で圧力にさらされる。モデル品質は依然として重要だが、エージェント構築者は実行環境、ツール制御、スケジューリング、トレーシング、状態、障害処理を比較するようになっている。

モデルベンチマークだけでは、その比較に決着を付けられない。チームは、エージェントが実際のタスクを予測可能に完了するか、ポリシーの範囲内にとどまるか、そして運用担当者がその行動を理解するのに十分な証跡を残すかを評価する。

Googleの優位性は統合にある。モデル、エージェントハーネス、サンドボックス、検索アクセス、API群、クラウドサービスを、単一の製品経路で共有できる。

その統合は依存関係でもある。完全なスタックを採用するチームは、Googleのエージェントセマンティクス、環境の挙動、クォータ、プレビューでの変更、モデルの提供状況により依存することになる。

モデル選択はこの依存の一部を減らせるが、すべてではない。周辺のハーネスは依然としてGoogleのものだ。フック、トリガー、インタラクション状態、環境管理は、プラットフォーム固有のインターフェースを使用する。

したがって真の競争上の試金石は、運用面での移植性である。要件が変化した場合に、ポリシー、評価、タスク状態を別の場所でどれほど容易に再現できるかを、開発者は知る必要がある。

Google Gemini Hooksには依然として重要な欠落がある

Hooksは制御を改善するが、その失敗時の挙動と適用範囲により、絶対的なセキュリティ境界として機能することはできない。

最も重要な制約は、Google自身のドキュメントに記載されている。コマンドフックがクラッシュ、タイムアウト、無効な出力の返却、または特定のエラーに遭遇した場合、ランタイムはツール呼び出しを許可する。

このフェイルオープンの挙動は、壊れたポリシースクリプトによってエージェント全体が停止することを防ぐ。しかし同時に、壊れたセキュリティゲートが本来阻止すべきアクションを許可してしまう可能性もある。

このトレードオフは、書式設定やテレメトリ用のフックには適している。失敗したリンターが必ずしもすべてのワークフローを停止させるべきではない。だが、フックが破壊的なコマンド、制限されたデータ、規制対象のアクションを守る場合には受け入れにくい。

チームは、影響に応じてフックを分類しなければならない。利便性のためのチェックはフェイルオープンでもよい。重要な認可判断は、制限された認証情報や読み取り専用リソースなど、フック外の制御にも依存すべきである。

フックの適用範囲には、もう一つの境界がある。Googleによれば、環境フックはサンドボックス内で動作する組み込みツールをインターセプトする。コンテナ外で処理されるカスタム関数呼び出しやリモートMCPツールでは発火しない。

外部ツールは重大な結果をもたらし得るため、この違いは重要である。カスタム関数は、顧客レコードを更新したり、メッセージを送信したり、デプロイを開始したりする可能性がある。サンドボックスフックは、その呼び出しを自動的に統制しない。

開発者は、外部ツールごとの境界で認可と検証を分けて実装する必要がある。受信側サービスは、呼び出し元を認証し、引数を検証し、権限を強制し、アクションを記録すべきである。

実行後フックも、完了済みの作業を元に戻すことはできない。不適切なファイルや検証失敗を検出できても、元のツールアクションはすでに発生している。復旧にはアプリケーション固有の対策が必要となる。

設定の完全性にも同等の注意が必要である。フックファイルやスクリプトは書き込み可能な環境内に存在し得る。十分なファイルシステムまたはコード実行アクセスを持つエージェントは、これらの制御を変更できる可能性がある。

Googleは、変更に対する厳格な耐性が必要な場合、読み取り専用のリポジトリソースを使うよう助言している。この推奨は、機密性の高いデプロイメントにおけるベースラインとして扱うべきだ。

ネットワークアクセスも、もう一つの開かれた境界を生む。エージェントのドキュメントによれば、managed-agent環境ではデフォルトで無制限のアウトバウンドアクセスが有効になっている。開発者は許可リストを適用するか、アクセスを無効化できる。

デフォルトで開かれたネットワークは、調査やパッケージのインストールを簡単にする。一方で、信頼できないコンテンツ、予期しないダウンロード、環境外へのデータ流出への露出も高める。

Hooksは一部の操作を検査できるが、ネットワークポリシーをモデルの挙動に依存させるべきではない。選択したサービスだけを必要とするエージェントには、明示的な許可リストの方が明確な境界を提供する。

プロンプトインジェクションも依然として重要である。Webページやリポジトリのコンテンツを取得するエージェントは、その挙動を誘導し直すよう設計されたテキストに遭遇する可能性がある。その誘導がどれほど有害になるかは、ツールの権限によって決まる。

この問題を解消するモデルのデフォルト設定は存在しない。Gemini 3.6 Flashが推論やツール利用を改善したとしても、運用担当者には依然として、制約された権限、信頼できるソース、重要な出力に対する検証が必要である。

永続的なサンドボックスは、利点と並行して運用上のリスクも増やす。スケジュール実行をまたいでファイルを再利用すれば継続性が得られる。一方で、破損した状態、古い指示、汚染されたコンテンツが後続の実行へ持ち越される可能性もある。

したがって、スケジュールされたジョブには再現性の確認が必要となる。チームは、各実行を生成したモデル、エージェント定義、環境ソース、フックバージョン、プロンプトを把握すべきである。

トリガーには障害管理も必要だ。連続失敗カウンターは有用だが、誰かがアラートのしきい値と対処方法を定義しなければならない。責任者のいない定期的な自律実行は、定期的なサイレント障害になってしまう。

トークン予算にも同様の制約がある。上限は無制限の消費を防ぐが、有用な完了を保証するわけではない。エージェントは、生産性のない経路に割り当て全体を費やす可能性がある。

運用担当者には、トークン使用量以外のタスクレベルの指標が必要である。完了率、検証成功率、再試行、人手による修正、ロールバック頻度の方が、エージェントが信頼できる価値を提供しているかを適切に示す。

パブリックプレビューのステータスは、製品の不確実性を加える。インターフェース、上限、対応ツール、挙動は、一般提供前に変わる可能性がある。本番環境の採用者は、プラットフォーム固有のコードを分離し、可能な限り設定を固定すべきである。

独立した性能データがないことも、別の欠落である。GoogleはGemini 3.6 Flashを、推論、コーディング、ツール利用のバランスが取れたモデルとして説明している。発表では、managed-agentワークフローに関する比較タスク結果は示されていない。

開発者は、モデル名だけから本番環境での信頼性を推測すべきではない。自社のリポジトリ、データ、権限、障害ケースに基づく評価が必要である。

効果的なテストセットには、通常のタスクと敵対的なタスクの両方を含めるべきだ。曖昧な指示、失敗するツール、悪意あるコンテンツ、利用不能な依存関係、拒否されたアクションにエージェントがどう応答するかを測定すべきである。

チームはHooks自体もテストすべきだ。あるコマンド形式で機能するポリシーが、別の表現による同等のアクションを見逃す可能性がある。正規表現マッチャーはツール名を識別するものであり、すべての意味的な結果を識別するものではない。

最も堅牢なデプロイメントパターンは、重層的な制御を用いる。認証情報を制限し、ネットワークを制限し、設定ソースを保護し、ツール引数を検証し、出力を検査し、影響の大きいアクションには人による承認を求める。

Google Gemini Hooksは、この多層モデルによく適合する。チームが一つのインターセプトポイントを完全なガバナンスと誤認した場合にのみ、危険なものとなる。

managed agentsが準備できているかを示す3つの兆候

次の試験は、Googleがプレビューに追加する機能数ではなく、現実の制約下での採用である。

最初の兆候は、Hooksが本番環境の障害モードを乗り越えられるという証拠である。開発者は、文書化された信頼性指標、より豊富な強制オプション、重要なフック障害のより明確な扱いを注視すべきである。

選択したポリシーに対するフェイルクローズモードは、Googleの制御に関する説明を強化する。必須のゲートがクラッシュまたは到達不能になった際に、運用担当者が実行を停止できるようになる。

より細かな適用範囲も重要になる。Hooksは現在、組み込みのサンドボックスツールに重点を置いている。外部関数やMCP呼び出しに対するポリシー統合が拡張されれば、断片化された認可ロジックを減らせる。

Googleがこれらの制御を提供すれば、マネージドオーケストレーションを採用する根拠はより強くなる。重大な結果を伴うアクションに依然として別個のポリシーシステムが必要であれば、開発者はより多くのインフラをランタイム外に残すだろう。

二つ目の兆候は、プレビューおよびベータコンポーネントから、安定したサービスコミットメントへの移行経路である。managed agentsは引き続きパブリックプレビュー中であり、Triggers APIはベータエンドポイントを使用している。

チームは、一般提供、バージョニングに関するコミットメント、リージョン対応、クォータ、サポートポリシー、移行ガイダンスを注視すべきである。これらの詳細は、成功したプロトタイプが保守可能な製品になれるかを左右する。

安定性は、このAPIが定期実行ワーカーをホストできるというGoogleの主張を強めるだろう。頻繁な挙動変更や不明確なサービス境界がある場合、重要なワークロードでは開発者が管理するオーケストレーションが有利になる。

3つ目のシグナルは、測定可能なユーザー導入だ。最も有用な証拠は、手作業による介入やカスタムのインフラコンポーネントを減らして完了できる、再現性のあるワークロードから得られる。

OffDealのロゴ検証パイプラインは、具体例の一つを示している。今後は、エージェントが何を行うのか、どのような制御が適用されるのか、障害をどう処理するのか、どれだけ人によるレビューが残るのかを、より多くの事例で明らかにすべきだ。

チームは洗練されたデモの先を見る必要がある。定期実行エージェントが価値を持つのは、不完全なデータ、拒否されたアクション、ネットワーク障害、モデルの変更、実行の中断を乗り越えられる場合だ。

同じテストは社内でも適用される。出力を検証できる、範囲を限定したワークフローから始めよう。エージェントには必要最小限の権限を与え、すべてのツール操作を記録する。

トークン上限と制限されたネットワークを使用する。必須のポリシーファイルは保護されたソースに配置する。スケジュールを有効にする前に、固定された評価ケースでワークフローを繰り返し実行する。

次に、完了品質、ポリシーによる拒否、再試行、人による修正、環境のクリーンアップを測定する。その結果を、既存の手作業またはオーケストレーション済みプロセスと比較する。

Google Geminiは現在、このマネージドな経路を試すための信頼できる手段を提供している。Gemini 3.6 Flashがデフォルトの推論エンジンを担い、hooks、予算、トリガー、永続的な環境が、より広い運用領域をカバーする。

このリリースは、マネージド型と開発者管理型のオーケストレーションの争いに決着をつけるものではない。しかし、その競争を実践的なものにする。チームは今や、抽象的なエージェントフレームワークを議論するのではなく、稼働するシステム同士を比較できる。

開発者にとって、直近の問いは具体的だ。今日、オーケストレーション作業を過度に消費している、範囲を限定したタスクはどれか。元に戻せるアクション、観測可能な出力、明確な成功基準を備えたものを一つ選ぶ。

エンタープライズの購入担当者にとっての問いは、制御にある。マネージドランタイムは、既存のアイデンティティ、ネットワーク、監査、保持、承認の要件を満たせるのか。機能チェックリストでは、そのレビューの代わりにはならない。

ナレッジワーカーにとっての問いは、信頼だ。エージェントは、何を変更したのか、なぜ変更したのか、どの検証に合格したのかを示せるのか。その証拠を伴わない自律性は、レビュー作業を増やす。

Googleの次のリリースで、hooksが信頼できるポリシーレイヤーになるのか、それとも運用上の利便機能にとどまるのかが明らかになるだろう。それまでは、マネージドエージェントは多層的な制御を備えた、慎重に測定されたパイロットで運用すべきだ。

繰り返し実行されるワークフローを一つ選び、許可するアクションを定義し、スケジュール設定前にすべての障害パスをテストする。その規律によって、Google Geminiがインフラを取り除くのか、それとも単に別の場所へ移すだけなのかが分かる。