OpenAI Agents SDK、sandboxで長時間agentを本番投入しやすくした

Agentを本番投入するときの難所は、もはやmodel callだけではない。実用的なagentはfileを読み、commandを実行し、codeを編集し、stateを保ちながら多段の作業を続ける必要がある。OpenAIは4月15日のAgents SDK updateで、この実行loopをSDKの標準機能に近づけた。

中心はmodel-native harnessとnative sandbox executionだ。Harnessはfile、document、systemを横断して作業するagent向けに、configurable memory、sandbox-aware orchestration、Codex-like filesystem toolsを備える。OpenAIはMCP tool use、skills、AGENTS.md、shell tool、apply patch editsといったagentic primitiveを標準部品として扱い、各チームが同じ基盤を作り直す負担を減らす狙いを示した。

Sandbox層はさらに実務的な変更だ。Agentはtaskに必要なfile、tool、dependencyを持つcontrolled computer environmentの中で実行できる。開発者は自前のsandboxを使うか、Blaxel、Cloudflare、Daytona、E2B、Modal、Runloop、Vercelの支援を利用できる。Manifest abstractionはworkspaceを記述し、local fileのmount、output directory、AWS S3、Google Cloud Storage、Azure Blob Storage、Cloudflare R2からのdata接続をそろえる。

この設計はsecurityにも関わる。OpenAIはagent systemではprompt injectionとexfiltration attemptを前提にするべきだとしている。Harnessとcomputeを分ければ、model-generated codeが走る環境にcredentialを直接置かずに済む。Snapshottingとrehydrationにより、sandbox containerが失効または失敗しても、新しいcontainerでstateを復元しcheckpointから続行できる。

新機能はAPI顧客にGA提供され、tokenとtool useに基づくstandard API pricingで使える。まずPythonから始まり、TypeScript support、code mode、subagentsは今後の計画に入っている。大きな意味は、OpenAIがagentをprompt patternではなくruntime問題として扱い始めたことだ。開発者はdata boundaryとworkspace policyを明確に設計する必要があるが、基本的なorchestrationを毎回作る必要は小さくなる。