Gemini API で提供される「Managed Agents（管理型エージェント）」に、環境フック（environment hooks）とモデル選択機能、無料枠アクセスが追加されました。LLM（大規模言語モデル）を使ったエージェント基盤を自社パイプラインに組み込むか検討している開発者にとって、判断材料になる変更です。
Managed Agentsは、単一のAPI呼び出しの中で推論・コード実行・パッケージインストール・ファイル管理・Web取得までを、隔離されたクラウドサンドボックス内で完結させる仕組みです。エージェントに何かを任せるたびに複数のAPIを組み合わせる必要がなく、実行環境の管理もGoogle側に任せられる点が特徴です。
何が変わったのか
今回の発表で押さえておきたい変更点は主に3つあります。
- デフォルトモデルがGemini 3.6 Flashに切り替わった
- サンドボックス内のツール呼び出しを制御する「環境フック」が追加された
- 予算制御（budget controls）、スケジュール実行トリガー、無料枠アクセスが加わった
これらは、以前のリリースで導入されたバックグラウンドタスクとリモートMCPサーバー統合（MCPはModel Context Protocolの略で、LLMが外部ツールやデータソースに接続するための標準規格）の上に積み重なる形の拡張です。エージェント基盤は一度作って終わりではなく、継続的にアップデートが乗ってくる前提で設計を考える必要があります。
モデル選択の仕組みを段階的に見る
まず押さえておきたいのは、Managed Agentsがどのエージェント設定で動いているかという点です。antigravity-preview-05-2026というエージェント設定は、今回からGemini 3.6 Flashをデフォルトモデルとして採用しています。既存のコードを変更しなくても、次回のインタラクション（API呼び出し単位のやり取り）から自動的に新モデルに切り替わります。
これは裏を返すと、明示的にモデルを固定していない構成では、意図せずモデルが変わるリスクがあるということです。本番運用しているエージェントで出力の再現性（同じ入力に対して同じ傾向の出力が返るかどうか）を重視している場合、この自動切り替えは無視できません。
回避策として、agent_config.modelパラメータを明示的に指定する方法が用意されています。インタラクション作成時、あるいはManaged Agent作成時にこのパラメータを渡すことで、モデルのバージョンを固定できます。たとえば低レイテンシ・低コストを優先するタスクでは、Gemini 3.5 Flash-Liteを明示的に選ぶ運用も可能です。
推論精度が要るタスクと、単純な分類・抽出タスクで使うモデルを分ける、という設計はRAG(Retrieval-Augmented Generation、検索拡張生成)パイプラインの実装でもよく使われる考え方です。検索クエリの前処理には軽量モデル、最終的な回答生成には高精度モデルを割り当てるといった構成と発想は同じです。
環境フックとは何か
次に環境フックについてです。これはサンドボックス内でエージェントがツールを呼び出す際に、その呼び出しをブロック・リント（lint、静的なルールチェック）・監査（audit、記録と検証）できる仕組みです。
エージェントに任せる作業範囲が広がるほど、「エージェントが何をしたか」を後から追跡できることの重要性は増します。たとえばコード実行やパッケージインストールをエージェントに任せている場合、意図しないコマンドやライブラリの導入を事前に止められるかどうかは、セキュリティ設計上の分岐点になります。
環境フックは、この「ツール呼び出しの手前で介入する」という発想をAPIレベルで提供するものです。ML(機械学習)パイプラインの文脈で言えば、モデルの出力をそのまま実行系に渡さず、バリデーション層を挟む設計に近いといえます。エージェントを本番投入する際にガードレール(逸脱を防ぐ制約層)をどこに置くか、という設計判断の選択肢が1つ増えたことになります。
関連技術との比較で位置づけを整理する
Managed Agentsのようなマネージド型エージェント基盤は、自前でオーケストレーション(複数のツール呼び出しやモデル推論を制御する処理)を組む方式と比較されることが多い領域です。
自前実装であれば、LangChainやLlamaIndexのようなオーケストレーションフレームワークを使い、ツール呼び出しの制御・サンドボックス・ログ収集をすべて自分たちで設計します。柔軟性は高い一方、サンドボックスの隔離性やスケーリングの運用コストは開発チーム側の負担になります。
一方でManaged Agentsは、サンドボックスの隔離・コード実行・ファイル管理をAPI提供側が持つため、インフラ運用の負担を軽くできる代わりに、環境フックのような制御ポイントがAPI仕様の範囲に限定されます。自社のセキュリティポリシーが、提供されているフックの粒度でカバーできるかどうかは事前に確認しておく必要があります。
今日確認できること
実際に手を動かして確認できる項目を整理します。
まず、AIコーディングアシスタントを使っている場合、以下のコマンドでInteractions APIのスキルを追加できます。
npx skills add google-gemini/gemini-skills --skill gemini-interactions-apiTypeScript/JavaScript SDKを使う場合は、以下でSDKを導入します。
npm install @google/genai導入後に確認しておきたいポイントは次の3つです。
- 使用中のエージェント設定が
antigravity-preview-05-2026かどうか、ドキュメントで確認する - 本番運用しているコードで
agent_config.modelを明示指定しているか棚卸しする - 環境フックの対象範囲(ブロック・リント・監査それぞれで何が制御できるか)がAntigravityエージェントのドキュメントに記載されているか確認する
Python版やcURLでの利用例はAntigravityエージェントのドキュメントに掲載されているとされています。TypeScript/JavaScript以外の言語で導入を検討する場合は、まずそちらのドキュメント構成を確認するのが近道です。
agent_config.modelの明示指定を棚卸しすることが実務上の最初の一歩になります。まとめ
Gemini API のManaged Agentsは、モデル自動更新・環境フック・予算制御・無料枠アクセスという4方向で拡張されました。
エージェント基盤を評価する際は、モデルのバージョン管理をどこまで自分たちでコントロールできるか、ツール呼び出しに介入できる粒度がどこまであるかの2点を軸に見ておくと判断がしやすくなります。
まずは既存のエージェント設定を確認し、モデルが暗黙的に切り替わる構成になっていないか、環境フックで自社のセキュリティ要件を満たせそうかを確かめるところから始めてみてください。