Gemini APIのManaged Agents拡張が示す本番AIエージェント設計｜背景実行・remote MCP・権限更新をどう使うか

目次

---

1. AIエージェントは「会話」から「非同期ワーカー」へ進み始めた

AIエージェントを業務に入れようとすると、最初にぶつかるのはモデル性能ではなく「待てない」「つなげない」「権限を保てない」という運用上の問題です。チャット画面で数十秒待つだけなら許容できても、コード解析、調査、レポート作成、複数システムをまたぐ処理では、数分から数十分かかることがあります。途中で接続が切れたらどうするのか。社内APIにどう安全につなぐのか。期限切れの認証情報をどう更新するのか。こうした問いに答えられないと、AIエージェントはデモから本番へ進めません。

Google DeepMindは2026年7月7日、Gemini APIのManaged Agentsに、背景実行、remote MCP server integration、custom function calling、ネットワーク認証情報の更新機能を追加したと発表しました。公式発表では、Managed AgentsをGemini Interactions APIから利用し、推論、コード実行、パッケージインストール、ファイル管理、Web情報の利用を、隔離されたクラウドサンドボックス内で扱えると説明されています。

この更新は、単にGemini APIの機能が増えたという話ではありません。企業がAIエージェントを「人が見ているチャット」から「業務を任せられる非同期ワーカー」へ移すための部品がそろい始めた、という意味を持ちます。この記事では、Googleの公式発表をもとに、背景実行、remote MCP、custom function、認証情報更新を、企業の本番AIエージェント設計にどう落とし込むべきかを整理します。

2. Google DeepMindの発表で何が変わったのか

Googleの公式発表では、Managed Agents in Gemini APIに4つの主要な更新が示されています。第一に、長時間処理をHTTP接続に依存せずサーバー側で非同期に実行できる背景実行です。クライアントはIDを受け取り、状態確認、進捗ストリーミング、再接続を行えます。第二に、remote Model Context Protocol、つまりremote MCPサーバーへの接続です。これにより、社内データベースや内部APIへつなぐための独自プロキシを都度作るのではなく、MCPの道具立てで外部ツールを扱いやすくなります。

第三に、custom function callingです。Googleの説明では、組み込みのサンドボックスツールはサーバー側で自動実行され、ローカルで実行すべき業務ロジックはrequires_actionに遷移してクライアント側で処理できます。第四に、ネットワーク認証情報の更新です。短命のアクセストークンやAPIキーが期限切れになる現実を前提に、既存のenvironment_idを使いながらネットワーク設定を更新し、サンドボックス内のファイル、インストール済みパッケージ、クローン済みリポジトリは維持できるとされています。

この4点を合わせると、AIエージェントの役割が変わります。これまでのエージェントは、入力に対して即時応答する「賢いチャット」に近い使われ方が中心でした。今回のような機能群が整うと、調査、実装、社内データ照会、成果物生成、進捗報告、途中承認を含む、より長い業務フローを扱いやすくなります。

3. 背景実行が本番運用で重要になる理由

業務AIエージェントでは、完了までの時間が読みにくい処理が多くあります。たとえば、社内規程の差分を読み、関連する契約書を探し、要約を作り、レビュー観点を出す作業は、数秒で終わるとは限りません。開発支援でも、リポジトリを読み、依存関係を確認し、テストを実行し、修正案を作るには時間がかかります。こうした処理を通常の同期API呼び出しだけで扱うと、接続タイムアウト、ブラウザ離脱、再試行時の重複実行が問題になります。

背景実行は、この問題をアプリケーション設計のレベルで解きやすくします。リクエストを投げた時点でジョブIDを返し、UIは「実行中」「確認待ち」「完了」「失敗」といった状態を表示する。ユーザーが画面を閉じても処理は継続し、戻ってきたら進捗や結果を確認できる。これは、AIエージェントを通常の業務システムに組み込むうえで重要な前提です。

特に企業では、エージェントの途中経過が見えることも大切です。単に最後の回答だけが出ると、なぜその結論になったのか、どのデータを見たのか、途中でどのツールを使ったのかが分かりません。背景実行を導入するなら、進捗ログ、ツール実行履歴、エラー理由、再実行条件をセットで設計するべきです。非同期にするだけではなく、非同期でも監査できる状態にすることが本番運用の要点になります。

4. remote MCPとcustom functionをどう使い分けるか

AIエージェントを本当に業務で使うには、社内システムとの接続が避けられません。顧客管理、在庫、請求、勤怠、ドキュメント管理、ナレッジ検索など、価値のある情報は既存システムの中にあります。ただし、エージェントにすべてのAPIキーを渡し、自由に実行させる設計は危険です。どの道具をどの権限で使わせるかを分ける必要があります。

remote MCPは、エージェントが外部ツールや社内APIに接続するための標準的な入口として使えます。MCPサーバー側で、利用できる操作、入力形式、認証、ログ、権限制御をまとめておけば、エージェントごとに個別の接続実装を増やさずに済みます。たとえば、社内文書検索、チケット作成、顧客情報の読み取りなど、サーバー側で監査しやすい操作はMCP化しやすい領域です。

一方、custom function callingは、ローカル側で実行すべき業務ロジックを分離するために使えます。たとえば、最終承認が必要な発注登録、社内端末上のファイル処理、既存アプリのセッションを使う処理、組織固有の検証ルールなどは、サンドボックス内で完結させるより、クライアント側で明示的に実行したほうがよい場合があります。Googleの発表にあるrequires_actionの考え方は、人間承認やローカル実行を挟む設計と相性がよいものです。

5. 認証情報更新と環境維持が示す運用課題

本番環境のAIエージェントでは、認証情報の扱いが必ず課題になります。短命のアクセストークン、期限付きAPIキー、ネットワーク許可リスト、社内VPN、テナントごとの接続設定。これらはセキュリティ上必要ですが、長時間タスクとは相性が悪い面があります。途中でトークンが切れれば、エージェントは処理を続けられません。かといって、長期間有効な秘密情報を広く渡すと、漏えい時の被害が大きくなります。

Googleの発表では、既存の環境IDを使いながら新しいネットワーク設定を渡すことで、認証情報やルールを更新できると説明されています。さらに、サンドボックス内のファイル状態、インストール済みパッケージ、クローン済みリポジトリは維持されます。この仕組みは、業務エージェントの継続性という観点で重要です。毎回ゼロから環境を作るのではなく、作業途中の状態を保ちながら、接続権限だけを更新できるからです。

ただし、環境が維持されるということは、管理すべき状態も増えるということです。どのジョブがどの環境を使っているのか、環境内に機密ファイルが残っていないか、古いパッケージや一時ファイルが残り続けないか、終了後にいつ破棄するのかを決める必要があります。便利な持続環境は、監査とライフサイクル管理があって初めて安全に使えます。

6. 企業が導入前に決めるべき判断基準

Managed Agentsのような仕組みを使うと、AIエージェントの開発は速くなります。しかし、導入前に決めるべきことを飛ばすと、運用で詰まります。最初に決めるべきなのは、エージェントに任せる業務の粒度です。1回の会話で完了する相談なのか、数分かかる調査なのか、承認を挟む実行業務なのかで、設計は変わります。

次に、ツール境界です。クラウドサンドボックスで実行してよい処理、remote MCP経由で呼ぶ社内ツール、ローカルのcustom functionとして扱う処理、人間承認が必要な処理を分けます。この境界を曖昧にすると、便利さを優先して権限が広がり、後から監査できなくなります。

三つ目は、状態管理です。背景実行を使うなら、ジョブID、実行者、対象データ、途中ログ、利用ツール、エラー、再実行、キャンセル、成果物の保管場所を記録します。エージェントが作業環境を維持するなら、その環境の保存期間、削除条件、秘密情報の扱いも決めます。AIエージェントを本番業務に組み込むほど、通常のワークフローエンジンやジョブ管理に近い設計が必要になります。

7. 注意点

AIエージェントの本番化では、機能の豊富さよりも責任境界が重要です。背景実行、MCP、custom function、認証情報更新は便利ですが、それぞれにリスクがあります。背景実行は、処理がユーザーの目を離れて進むため、誤った入力や古い前提で長時間走り続ける可能性があります。キャンセル、タイムアウト、再確認の設計が必要です。

remote MCPは、社内ツールへの入口になります。だからこそ、MCPサーバー側で操作を絞り、引数を検証し、実行ログを残す必要があります。エージェントに「何でもできる万能API」を渡すのではなく、業務単位で小さな操作に分け、読み取りと書き込みを明確に分離するべきです。個人情報や機密情報を扱う場合は、取得範囲、マスキング、ログへの記録方法も確認しなければなりません。

custom functionは、人間承認やローカル業務処理を挟める一方で、クライアント側の実装品質に依存します。AIが提示した関数呼び出しを無条件に実行すると、想定外の更新や二重実行が起きる可能性があります。入力バリデーション、確認画面、冪等性、権限チェックを通常の業務アプリと同じ水準で作る必要があります。

認証情報更新についても、便利さだけで判断してはいけません。短命トークンを更新できる仕組みは実用的ですが、誰が更新を許可するのか、どのジョブにどの権限が引き継がれるのか、古い認証情報が環境に残らないかを確認する必要があります。AIエージェントの運用では、モデルの回答品質と同じくらい、権限、ログ、状態、破棄の設計が重要です。

8. まとめ

Google DeepMindが発表したGemini APIのManaged Agents拡張は、AIエージェントを本番業務に近づける重要な更新です。背景実行は長時間処理をジョブとして扱いやすくし、remote MCPは社内ツール接続の標準化を助けます。custom functionはローカル実行や人間承認を挟む設計に向いており、認証情報更新は長時間タスクと短命トークンを両立しやすくします。

一方で、これらの機能は「AIに任せる範囲」を広げるものでもあります。企業が導入する際は、実行方式、ツール境界、権限、状態管理、失敗時対応を先に決めるべきです。AIエージェントは、チャットの延長として導入するより、ジョブ管理、監査ログ、承認フロー、社内API統制を含む業務システムとして設計したほうが成果につながります。

OpenBridgeでは、AIエージェント、MCP、RAG、ローカルLLM、業務システム連携を組み合わせ、企業ごとの運用体制に合わせたAI導入を支援しています。Managed Agentsのようなクラウド型エージェント基盤を使う場合も、社内データの扱い、権限境界、人間承認、監査ログを含めて設計することが重要です。