2026-08-08 発行（読了 6 分）
実プロダクトのアーキテクチャ・使用例から AI 開発の現在地を週 3 回・1 号 1 テーマで深掘り
コード生成・実行までを自律的にこなすエージェントが増え、生成コードをどこで安全に走らせるかが2026年前半のインフラ論点になった。Cloudflare は container 基盤の永続サンドボックスと、V8 isolate 基盤の軽量実行の両方を GA させ、Vercel は Firecracker microVM 方式を GA、OpenAI は Agents SDK に7社のホスト型プロバイダを差し替え可能な形で組み込んだ。単一の「正解アーキテクチャ」に収束したのではなく、ワークロードの性質ごとに分離方式を使い分ける設計判断がこの数ヶ月で急速に明文化された。
この方式は、エージェント1つに対してコンテナないしmicroVMを1台割り当て、シェル・ファイルシステム・バックグラウンドプロセスを持つ「本物のコンピュータ」として使わせる。起動のたびにゼロから作り直すのではなく、アイドル時はスリープし、要求が来たら再開する。ディスク状態・依存関係・OS設定をまるごと保存するスナップショット機能が中核で、これによりゼロから作り直すコストを毎回払わずに済む。
各社がこの形に収束した理由は、エージェントのタスクが単発の実行では終わらないからだ。コード生成→実行→エラー確認→修正、という往復や、人間のレビューを挟んで数日後に再開するような運用が現実に発生する。使い捨て前提のサンドボックスだと、その都度リポジトリのcloneや依存関係のインストールをやり直すことになり、これが待ち時間として蓄積する。持続性を前提にした設計に切り替えることで、この待ち時間をアーキテクチャレベルで消している。
もう一つの系統が、V8 isolate（Cloudflare Workersを2016年から支えてきた分離機構）でエージェント生成コードを動かす方式だ。コンテナが数百ミリ秒〜数秒かかるのに対し、isolateは数ミリ秒で起動し、メモリ効率も10〜100倍高い。ただし任意のOS環境ではなく、JavaScript/TypeScriptで書かれた短命なコードの実行に用途が絞られる。
この方式が伸びているのは、エージェントが実行するコードの性質が必ずしも「フル開発環境」を必要としないケースが多いためだ。複数のAPI呼び出しを連結するだけのグルーコードであれば、コンテナ起動の待ち時間もOSの重装備も不要で、むしろ足かせになる。Cloudflareはこれを"Code Mode"と呼び、APIをツール呼び出しではなくコードとして実行させることでトークン消費を81%削減した事例を公表しており、分離方式の選択がコストにも直結することを示している。
OpenAI Agents SDKは自社製のサンドボックス技術を持たず、代わりにプロバイダインターフェースを公開し、Cloudflare・Vercel・E2B・Modal・Daytona・Runloop・Blaxelという7社のホスト型サンドボックスと、Docker/Unixローカル環境を差し替え可能にした。E2Bは最小限の設定変更でこのインターフェースに対応したことを自社ブログで説明し、Modalは同時期にAnthropicのClaude Managed Agentsとも統合し、ツール呼び出しをすべてModal Sandboxes内で実行する構成を発表している。
この収束の仕方は、LLMプロバイダをルーティング層で抽象化してベンダーロックインを避けた流れと同じ設計判断が、実行基盤側にも及んだものと見える。サンドボックス技術そのものがコモディティ化しつつあり、どのエージェントフレームワークを選ぶかと、どの実行基盤（isolate系かmicroVM系か）を選ぶかが別レイヤーの意思決定として分離され始めている。