共有:

Agent Runtime · Gemini API

常駐エージェントから、
HTTP コネクションが消える日。

Google が Gemini API に「バックグラウンド実行」を追加し、リモート MCP サーバーへの接続もサポートしました。単なる非同期 API ではなく、エージェントの居場所そのものが移動するのが要点です。

AI Navigate 編集部·2026.07.19·読了 6分

HTTP KEEP-ALIVE Client held open the whole run Server 切断 = 失敗 BACKGROUND EXEC Client Gemini API (queue) Remote MCP tools fire & forget
FIG. 従来はクライアント側の HTTP コネクションが「エージェントの寿命」だった。新設計はそれをサーバー側に移す。
01

What Was Announced

Gemini API に「消えないエージェント」が加わった

Gemini API のドキュメントによると、API がバックグラウンド実行に対応し、クライアントとの HTTP コネクションを維持しなくても長時間動くタスクを回せるようになりました。同時に、MCP(Model Context Protocol)越しにリモートのツールサーバーへ接続する機能もサポートされます。MCP は元々 Anthropic が提唱したオープン仕様で、Gemini がこれに対応したことでツール接続の互換性が一気に広がります。

要点はふたつ。ひとつは、「常駐エージェント=常時 open な HTTP」という前提が消えること。もうひとつは、ツール接続がベンダー独自プロトコルから MCP へ収れんし始めたことです。前者は運用インフラ、後者はエコシステム全体に効いてきます。

02

By The Numbers

アーキ変更の勘所

0 conn
クライアント側の常時接続不要に
MCP
共通プロトコルで tool 互換性が拡大
Async
Job モデル前提の設計に移行
03

Why It Matters Now

なぜ「今」効くのか

HTTP を握り続ける実装は、ここ半年でエージェント運用の最大のバグ源になっていました。

コーディングエージェントや自動リサーチエージェントが 30 分〜数時間走るようになった結果、ロードバランサー切断・タイムアウト・NAT リセットが失敗理由の上位を占めるようになりました。従来は WebSocket や SSE を工夫しても、途中で切れた瞬間にエージェントは「継続不能」に落ちます。今回の Gemini API 側の変更は、この寿命管理をクライアントからサーバーに引き取るものなので、切断リスクそのものが工程から消えます。

MCP 対応も、単なる「もう一個の連携方式」ではありません。ChatGPT の GPTs、Claude の Tool Use、Gemini の Function Calling——これまで各社ごとに書き直していたツール接続コードが、MCP 一本で並列に動かせるようになる方向です。すでに Anthropic、OpenAI、Cursor、Zed 等が採用しており、Google が加わったことで 「事実上の標準」に固まる速度が上がったと捉えるのが妥当です。


04

Who Should Do What

誰に、どう効くか

影響は「長寿命エージェントを書く」チームに集中し、単発 API 呼び出しでは誤差です。

01

長寿命エージェント開発者: サーバレスへ回帰できる

これまで「HTTP を保持するために EC2 常駐」が既定路線でした。今回の変更で、Cloud Run / Lambda のような短命プロセスから submit → 後で job id で取りに行く設計が現実的になります。Terraform 側の常駐 VM を削れるチームは多いはずです。

02

ツール提供側: MCP サーバー化の重み増加

SaaS 各社は、自社 API に MCP サーバーの薄いラッパーを載せておくと、Claude・ChatGPT・Gemini・Cursor から等しく叩かれる入口を用意できます。「特定 LLM 向けプラグイン」ではなく「MCP 対応」という言い方が採用時のチェック項目に格上げされます。

03

単発 API 用途: 影響なし

1 プロンプトで済むテキスト生成や埋め込みは、これまで通り。バックグラウンド実行を有効化するかどうかは、タスクの想定実行時間が 30 秒を超えるかで判断すると分岐が明確です。

05

What Comes Next

直近で起きること、取れる手

Job API
submit/poll の非同期パタンが定着
MCP
Registry 系サービスが立ち上がる
Cost
起動しっぱなしコストの解放

短期の見通し。(a) OpenAI Responses API と Anthropic Messages Batch がすでに近い方向で走っており、Google 参入で 「LLM = 非同期 Job キュー」という抽象が業界の合意になります。(b) MCP サーバーのディレクトリ(Registry)や、権限管理レイヤーを扱う中間サービスが出てきます。(c) 実装側で今すぐ動けるのは、既存の常駐 daemon を Job モデルにリファクタする設計レビュー——特に「HTTP 切断で死んでいたエラー」の統計を出しておくと、移行の効果が見積もれます。


エージェントを長時間動かすとは、
誰がその寿命を握るかを決めることだ。


06

Counterpoint

反対視点・限界・見落としがちな点

まず、非同期化はデバッグが難しくなる。従来は 1 リクエスト= 1 セッションで、ログの分岐が単純でした。バックグラウンド Job では途中状態を能動的に取りに行かないと見えず、「なぜ止まったのか」を再現するコストが上がる可能性があります。可観測性ツール(trace / span)への投資が別途必要になります。

MCP についても手放しでは推せません。権限モデルとサンドボックスがまだ緩いのは、実運用に入る前の懸案です。リモート MCP サーバーを叩けるということは、そのサーバーが返す結果をエージェントが「信頼して」次のツール呼び出しにつなげるということ。敵対的 MCP サーバーによる prompt injection 攻撃面が新規に開く点は、初日から意識しておく必要があります。