Gemini Managed Agentsにフックと予算上限　自動実行を任せる前に見るべき制御

何が起きたか

Googleは2026年7月28日、Gemini APIのManaged Agentsへ、モデル選択、environment hooks、トークン予算、scheduled triggersなどを追加したと発表しました。既定モデルはGemini 3.6 Flashです。

Managed Agentsは、隔離されたクラウド環境で推論、コード実行、ファイル操作、パッケージ導入、Web取得などを組み合わせる仕組みです。今回の更新で注目すべきなのは、エージェントの能力が増えたことより、動作の前後へ制御を差し込めるようになったことです。

エージェントの前後へ制御を置く構成 実行前フック、実行後監査、予算上限、スケジュール、停止経路は別々の役割を持つ。

4つの更新を実務へ翻訳する

1. Environment hooks：道具を使う直前・直後に検査する

公式説明では、pre_tool_executionとpost_tool_executionのイベントへ独自処理を置き、ツール呼び出しをブロック、検査、監査できます。

たとえば、送信先ドメインを許可リストと照合する、生成ファイルを秘密情報スキャンへ通す、書き込み先が指定フォルダー内か確認するといった制御です。プロンプトで「安全に行動して」と頼むのではなく、モデルの判断とは別の処理で止められる点が重要です。

ただし、フックがあるだけで安全になるわけではありません。すべてのツールへ適用されているか、検査処理が失敗したとき許可ではなく拒否になるか、フック自体をエージェントが変更できないかを確認する必要があります。

2. Budget controls：長いループに上限を置く

max_total_tokensは入力、出力、思考を含む総トークン量の上限です。到達時はincompleteとなり、環境状態を残して継続できると説明されています。

これは費用の暴走を抑える一つの境界ですが、API以外の費用まで自動で止めるとは限りません。外部ツールの課金、クラウド処理、ストレージ、メール送信件数などは別の上限が必要です。

3. Scheduled triggers：無人実行を前提に設計する

スケジュールは、エージェント、環境、指示、cron設定を結び付けます。各回で同じサンドボックスを再利用し、ファイルが残る設計と説明されています。

状態が残ることは継続作業に便利ですが、古いデータ、失敗途中のファイル、前回の指示が次回へ影響する可能性もあります。各実行の開始条件、前回状態の扱い、同じ処理の重複防止を決めます。

4. Environments API：残った環境を把握して消す

環境の一覧、確認、削除ができれば、接続が切れた後のサンドボックスを回収できます。作成だけを自動化して、終了・削除を人の記憶へ依存させないことが大切です。

誰に影響するか

Gemini APIで調査、コード、資料作成を自動化している開発者
エージェントへWeb取得や外部ツールを許可する管理者
夜間や週次に無人実行したい業務部門
AIの利用量とクラウド費用を管理する責任者
生成物の送信・公開前に品質検査を置きたいチーム

単発のチャット利用者には直接の変更が小さくても、社内ツールを作る側には大きな更新です。操作できる範囲が広いほど、プロンプトではなく実行基盤の制御が重要になります。

フックで止められること、止められないこと

失敗モード	フックでできる対策	別に必要な対策
許可外フォルダーへ書く	実行前にパスを検査して拒否	OS・クラウド側の書込権限も絞る
秘密を含む成果物を渡す	実行後にパターン検査して隔離	入力段階で秘密を渡さない
外部へ大量送信する	宛先・件数を検査して拒否	API側のレート・送信上限
間違った内容を丁寧に作る	出力形式や必須根拠を検査	人による事実・妥当性確認
フック処理自体が停止する	fail-closedでジョブを中断	監視、通知、復旧手順
認証情報が奪われる	一部のツール呼出しを拒否	短期資格情報、保管分離、失効

フックはアプリの判断を強制する場所ですが、基盤側の権限を置き換えるものではありません。モデル、フック、OSやクラウド権限の三層で同じ禁止事項を守ります。

Scheduled triggerと一般的なcronの違い

一般的なcronは、指定時刻にコマンドを起動するだけです。Managed Agentsのscheduled triggerは、エージェント、環境、指示を結び付け、同じサンドボックスの状態を次回へ残せる点が特徴です。

そのため運用では、次の追加項目が必要です。

前回作ったファイルを次回の入力に含めるか
失敗途中の状態から再開するか、初期化するか
同じ予定が遅れて実行されたとき、当日分として扱うか
環境をいつ削除し、次回は新規作成するか
前回と同じ入力なら費用を使わずskipするか

「状態が残る」を便利なキャッシュとしてだけ考えず、入力データの一部として管理します。

既定の保存条件も確認する

Interactions APIの公式ドキュメントでは、既定でInteractionを保存し、サーバー側の状態管理やバックグラウンド実行に利用すると説明されています。2026年8月11日時点の記載では、Paid Tierは55日、Free Tierは1日で、store=falseを選べる一方、バックグラウンド実行やprevious_interaction_idによる継続と両立しない条件があります。

長時間・定期実行を選ぶときは、処理能力だけでなく、入力とツール結果がどこへ何日残るかを確認します。組織の保存方針より長い場合は設定を短縮し、保存できないデータを扱う仕事はstatelessな別経路へ分けます。

導入前の確認表

確認対象	合格条件の例
実行前フック	許可外ツール・送信先・書込先を拒否する
実行後フック	生成物を検査し、合格品だけ次工程へ渡す
予算	トークンと外部サービス費用に別々の上限がある
定期実行	重複実行を防ぎ、前回失敗を引き継がない
状態保持	保存期間、閲覧者、削除条件が決まっている
停止	担当者が次回実行と進行中ジョブを止められる
監査	指示本文や秘密を残さず、操作と結果を追跡できる

今すぐ試すなら

本番データではなく、架空データと読み取り専用の作業環境で次を確かめます。

許可外の書き込み先を指定し、実行前フックが拒否するか
検査に失敗する生成物を作り、次工程へ渡らないか
小さな予算上限でincompleteになり、外部処理も止まるか
同じscheduled triggerが二重起動したとき、重複成果物を作らないか
環境削除後に、ファイルや資格情報が残っていないか

AI活用ナビの判断

今回の更新は「より自律的になった」という機能紹介より、AIエージェントを運用可能にする制御が製品機能として揃い始めたニュースです。

ただし、フック、予算、スケジュールは自動的に正しいポリシーを作ってくれません。何を拒否するか、失敗時に止めるか、どの状態を次回へ残すかは利用者側の設計です。プロンプトインジェクション対策とAIエージェントの権限設計を先に決め、機能をそのルールへ当てはめる順番が安全です。

確認日と留意点

確認日：2026年8月11日

Managed Agents、モデル名、無料枠、API仕様は変更される可能性があります。公式ドキュメントではManaged Agentsをpreviewとしており、仕様やスキーマが変わり得ると明記されています。実装時は最新版と自分のGoogle Cloudプロジェクトの利用条件を確認してください。公式ブログの利用事例はベンダー掲載事例であり、このサイトによる独立検証ではありません。

PRIMARY SOURCES