Gemini APIでエージェントを実装したいものの、サーバー側で履歴を持つのか、Linux実行環境をどこまで自前で管理するのか、外部ツール接続の境界をどう切るのかで止まっている企業は多いはずです。2026年5月19日にGoogleが発表した Managed Agents は、その設計負荷をかなり前倒しで吸収する更新です。1回のAPIコールで、推論、ツール利用、コード実行、Web取得まで含むエージェント実行環境を立ち上げられるようになりました。
ただし、便利になったからといって、すぐ本番投入してよいわけではありません。Google公式情報を見ると、Managed Agents は preview 提供で、通常の generateContent とは役割が異なり、Enterprise 側では network allowlist や資格情報の扱いを開発者が明示的に設計する前提です。この記事では、Google公式ブログと公式ドキュメントだけをもとに、導入前に確認すべき判断ポイントを整理します。
Managed Agentsで何が変わったのか
Google公式ブログによると、Managed Agents in the Gemini API は、単一のAPIコールで隔離された Linux 環境を持つエージェントを起動できる仕組みです。エージェントは Antigravity harness を基盤にしており、Gemini 3.5 Flash を土台として、推論、計画、ツール呼び出し、コード実行、ファイル操作、Web取得をまとめて扱えます。自前で sandbox を立てたり、セッションの再開状態を持つ制御層を書いたりする負担を減らすのが狙いです。
HelloCraftAIの読者目線で重要なのは、モデルの性能差そのものよりも、『どこまでをモデルAPIではなく実行基盤として任せられるか』 が変わった点です。これまでエージェント実装では、履歴管理、ファイル保持、長時間処理、ツール権限の束ね方まで含めてアプリ側で組む必要がありました。Managed Agents は、そのうち実行基盤に近い部分をGoogle管理に寄せられるため、開発チームは業務指示やスキル設計に集中しやすくなります。
通常のGemini API利用と何が違うのか
Googleが Interactions API の説明で明示している通り、従来の generateContent は stateless な request-response に強い一方、agentic application に必要な interleaved messages、thinking、tool calls、その状態管理には向いていません。Interactions API は /interactions という単一エンドポイントで、モデルとエージェントの両方を扱えるようにし、必要に応じて server-side state や background execution を持てるようにしています。
つまり導入判断としては、単発の要約、分類、文章生成なら generateContent のままでも十分です。逆に、複数ターンでファイルを持ち回る、途中でWebを見に行く、コードを実行して成果物を出す、といった長めのワークフローなら Managed Agents を検討する価値があります。Google自身も、Interactions API は modern agentic applications 向けの複雑な context management を扱うための基盤だと位置付けています。
実務で効きやすい3つのユースケース
1つ目は、調査からメモ作成までを1セッションで回したい業務です。たとえば新しいAI製品の比較調査では、公式ページを読み、要点を抽出し、比較表を作り、途中成果物を残しながら追記したくなります。Managed Agents は follow-up calls で state と files を保持したまま再開できるため、単発チャットを継ぎ足すよりも、調査タスクを1つの作業単位として扱いやすくなります。
2つ目は、コードやファイル操作を伴う社内自動化の試作です。Google公式ブログでは isolated Linux sandbox 内で code execution と file management ができると明示されています。たとえばCSV整形、ログ解析、レポート下書き生成のような軽量処理なら、まずは Managed Agents 上で再現し、使いどころが見えた時点で既存基盤へ移す判断がしやすくなります。
3つ目は、業務固有の指示書を markdown で管理したいケースです。Managed Agents では AGENTS.md や SKILL.md のような markdown files で custom instructions と skills を定義できると案内されています。これは、営業支援、監査チェック、FAQ更新のように、部署ごとに手順が違う運用で効きます。複雑な orchestration code を最初から書くより、まずは指示とスキルを versionable files として分離した方が、運用レビューと差分管理がしやすいためです。
Enterprise導入で先に見るべきセキュリティ境界
Enterprise向けの公式ドキュメントでは、Managed Agents API on Agent Platform は default で external systems、networks、credentials へアクセスできない sandbox から始まると説明されています。これはかなり重要です。つまり、初期状態では『勝手に社内DBへつながる危険』よりも『何もつながらない』設計になっており、必要な接続だけを開発者が明示的に足す前提です。
そのうえで、外部接続を許可する場合の論点も明確です。ドキュメントでは network access は use case に必要な時だけ enable し、allowlist を狭く保つこと、internal services や admin panels や databases を安易に向けないこと、資格情報は least privilege と short-lived tokens を基本にすること、production data source に接続する前に sample data で検証することを勧めています。要するに、便利になったのは実行基盤であり、権限設計まで自動で安全になるわけではありません。
導入前に決めておくチェックリスト
まず決めるべきは、Managed Agents を使うタスクの長さです。単発生成で済むなら generateContent、複数ターンでファイルや状態を保持したいなら Managed Agents と分けるだけで、設計の迷いがかなり減ります。次に、接続先を決めます。何もつながない sandbox で十分な検証から始め、どうしても必要なAPIだけ allowlist に載せる順番が安全です。最後に、レビュー地点を決めます。生成コード、データ変換、設定変更のような critical outputs は人間確認を必須にする、という線引きを最初に置くべきです。
実務では、次の4点を満たせるなら小さく始めやすいです。1) 調査や整形対象が公開情報または疑似データである。2) 認証情報を渡さなくても価値検証できる。3) 成果物がレポート、CSV、ドラフト文書など review しやすい。4) 失敗しても本番影響が出ない。逆に、この4点を満たさない場合は preview 段階の採用を急がず、まず Interactions API や既存ワークフローで代替できないかを見る方が堅実です。
Gemini API や Claude、ChatGPT を含む生成AIの導入で、業務フローに合わせた権限設計やレビュー手順まで整理したい場合は、 HelloCraftAIにご相談ください 。要件整理から小規模PoC、運用チェックリスト作成まで一緒に設計できます。
よくある質問
Q. Managed Agents はすでに本番前提で使えますか？ A. Google公式ブログでは Gemini API 側は preview、Enterprise Agent Platform 側も preview と案内されています。したがって、いきなり全社本番へ広げるより、限定用途でのPoCから始めるのが妥当です。
Q. Managed Agents を使うと自動で安全になりますか？ A. いいえ。初期状態が isolated sandbox なのは強みですが、外部ネットワークや資格情報をつなぐ時点で設計責任は開発者側に残ります。Google公式ドキュメントでも allowlist、least privilege、short-lived credentials、human oversight が明示されています。
Q. 既存の generateContent はもう不要ですか？ A. そうではありません。Googleは Interactions API を modern agentic applications 向けとしつつ、standard production workloads では generateContent が primary path だと説明しています。単発生成中心なら、まだ generateContent の方が適切なケースは多いです。
Q. まず何から試すべきですか？ A. 公開情報の調査、CSV整形、議事メモ生成のように、資格情報なしで再現できる軽い業務から始めるのが現実的です。Managed Agents の価値は『賢い返答』だけでなく『状態を持った実行環境をまとめて扱えること』にあるため、その強みが出る作業を選ぶべきです。
Managed Agents は、Gemini API を単なるモデル呼び出しから、状態と実行環境を持つエージェント実装基盤へ広げる更新です。強いのは、開発チームが sandbox、state、resume を毎回自前実装しなくて済む点です。一方で、どの接続を開けるか、どの資格情報を渡すか、どこで人間が止めるかは依然として実装側の責任です。導入判断では、機能の派手さよりも『どの業務を、どの権限で、どこまで自動化するか』を先に決めるのが正解です。
