AIエージェントを「壊れてもいい部屋」で走らせる — OpenAI Agents SDKのサンドボックスが解決すること

AIエージェントにファイル操作やコマンド実行をさせたいが、本番環境で暴走されたら困る。この問題に対する答えを、OpenAIが4月16日にAgents SDKのアップデートという形で出した。

公式発表のキーワードは2つ。サンドボックスとハーネス。どちらも聞き覚えのある概念だが、Agents SDKに組み込まれたことで、エージェント開発の実用性が一段上がった。

サンドボックス — エージェントに「専用の部屋」を与える

サンドボックスは、エージェントが操作できる範囲を物理的に隔離する仕組みだ。ファイルシステム、シェル、インストール済みパッケージ、メモリ。これらをコンテナの中に閉じ込め、エージェントがホスト環境を汚さないようにする。

これまでも自前でDockerコンテナを立ててエージェントを走らせることはできた。だが、セットアップが面倒で、各プロバイダーのAPIを個別に叩く必要があった。

今回の統合では、7社のサンドボックスプロバイダーが組み込みサポートされている。

• E2B — コードインタプリタ特化
• Cloudflare — エッジ実行
• Daytona — 開発環境
• Modal — GPUワークロード
• Runloop — コーディングエージェント向け
• Vercel — フロントエンド実行
• Blaxel — マルチモーダルエージェント

SandboxRunConfigでプロバイダーを指定するだけで、エージェントが隔離環境内でファイル操作・シェルコマンド・パッケージインストールを実行できる。自前サンドボックスも持ち込める。

ローカル開発ではUnixLocalSandboxClientから始められるので、いきなりクラウドに繋ぐ必要はない。

ハーネス — 長時間タスクの「心臓部」

もう1つのハーネスは、エージェントが長時間にわたる複雑なタスクを自律的にこなすための仕組みだ。

具体的には以下が含まれる。

• 設定可能メモリ — エージェントのコンテキストウィンドウとは別に、永続的な記憶領域を持てる。タスクが長くなってもコンテキストが溢れない
• Codex風ファイルシステムツール — ファイルの読み書き、差分の確認、ディレクトリ操作をエージェントが直接行える
• サンドボックス対応オーケストレーション — 複数のサンドボックスにサブエージェントを振り分けて並列実行できる

OpenAI Codexを使ったことがある人なら、このハーネスが「Codexの裏側をSDKとして切り出したもの」であることに気づくだろう。Codexで磨かれたファイル操作・メモリ管理・タスク分割の仕組みが、汎用のエージェントフレームワークに降りてきた形だ。

100以上のLLMで動く

地味だが重要な点がある。このSDKはOpenAIのモデル専用ではない。Chat Completions API互換であれば、100以上の非OpenAI LLMでも動作する。ClaudeやGemini、ローカルのLlamaで動くエージェントにも、同じサンドボックスとハーネスの仕組みが使える。

ここが素直にすごい。OpenAIが自社SDKを他社モデルにも開放しているのは、「エージェント開発の標準」を取りにいく戦略だろう。モデルで勝てなくても、開発基盤で勝てばロックインできる。

現状の制約

Python先行で、TypeScriptは後日対応。エージェント開発の主戦場がPythonであることを考えれば妥当だが、Next.jsベースのプロダクトに組み込みたいケースでは待ちが発生する。

また、サブエージェントと「コードモード」は近日公開予定とされており、まだ使えない。フル機能が揃うまでにはもう少し時間がかかりそうだ。

誰が使うべきか

LangChainやCrewAIでエージェントを組んでいて「実行環境の管理が面倒」と感じている開発者には、このサンドボックス統合が刺さる。特に、エージェントにコード生成→実行→検証のループを回させたい場合、E2BやRunloopとの統合は実用的だ。

一方、Claude CodeやCursor Agentのように完成されたエージェント製品を使っている人には、直接の恩恵は薄い。あくまでSDKレベルの話であり、自分でエージェントを組む開発者向けのアップデートだ。