Sandbox Agents は「agent 本体」と「作業用 compute」を同じものとして扱う雑設計をやめさせる

要点

要点まとめ

OpenAI が言いたいのは、『AI に作業させる箱』を本体アプリと同じ場所に雑に置くな、ということだ。
shell を使えるかどうかより重要なのは、考えて段取りを決める側と、実際に files や commands を触る側を分けることにある。
『前回の続き』も一種類ではない。会話の続きなのか、作業箱への再接続なのか、保存済み file 群の再利用なのかを分けて持てるようにしている。
日本の開発者にとっての読みどころは、agent に shell を混ぜる話ではなく、成果物の回収、再開方法、preview、credential 配置をどの境界に置くかという運用設計である。

読解

何が変わったのか

この guide の核心は、sandbox を『tool の一種』ではなく container-based execution environment として前に出したことです。OpenAI は Sandbox Agents を、files、commands、packages、ports、snapshots、resumable state を扱う Unix-like 環境として説明しつつ、orchestration stays separate from execution と明示しています。つまり、賢いモデルに shell を足すだけの話ではなく、進行管理と手作業箱の責務分離を system design として固定し始めています。

日本の文脈

なぜ重要か

日本の小規模開発では、agent 本体、shell 実行、temporary files、preview server が一つの process に雑に同居しがちです。その形は最初は速いですが、resume、監査、artifact review、権限説明がすぐ破綻します。この guide は、その雑な同居をやめ、agent product を compute boundary つきの system として扱えと迫っています。PM や創業者にとっても、『どの files が sandbox 内にあるか』『どの credentials を application server 外へ出すか』『どの成果物を review 後に昇格させるか』を説明しやすくする原典です。

技術ポイント

技術的ポイント

Sandbox Agents は container-based environment の上で agent work を走らせる前提で、files、commands、packages、ports、snapshots、resumable state を扱う。単なる shell helper ではない。
capability は明示的に足す。guide の表では `Shell` は command execution、`Filesystem` は file edit と local image inspection、`Skills` は sandbox 内の skill discovery、`Memory` は follow-on runs 向け記憶、`Compaction` は長時間 flow の context trimming を担う。
`RunState`、session state、`snapshot` は同じ『前回の続き』ではない。harness 側の state、sandbox へ戻る再接続情報、保存済み workspace contents を分けて持つことで、再開責務を切り分けている。
`Memory` は conversation history の保存と別物で、guide では prior runs から reusable lessons を蒸留する設計として説明されている。resume と memory を同一視しないほうがよい。
provider 選択も責任分界の話として出てくる。managed execution、previews、storage mounts、snapshots、application server 外に置きたい credentials が必要なら hosted provider を検討すべきだとしている。

用語

英日キーワード

英語	日本語	補足
SandboxAgent	サンドボックスエージェント	agent が独立した execution environment と組で動く形。agent 本体と作業箱を同居させない設計の単位。
orchestration	オーケストレーション	model loop、tool state、承認などを持つ進行制御層。execution environment そのものとは別に考える。
execution environment	実行環境	files や commands を実際に扱う箱。agent の思考や承認フローとは責務を分けて設計する。
session state	セッション状態	sandbox session へ再接続するための状態。会話履歴や長期 memory と同一視しないほうがよい。
snapshot	スナップショット	保存済み workspace contents から新しい sandbox を始めるための状態。会話継続ではなく作業箱の再利用に効く。
artifact	成果物	sandbox run が出す review 対象の files や output。生成しただけで本番へ昇格させない運用が必要。

試す

試すなら

今の agent 実装で、『会話の続き』『workspace の続き』『成果物の再利用』を同じ意味で扱っていないか確認する。
shell 実行が要るなら、application server 内で直接叩く代わりに、sandbox 側へ切り出せる責務を列挙する。
`Shell`、`Filesystem`、`Memory` など必要 capability を最小から足し、何を与えたか設定で説明できる形にする。
生成物はそのまま本番へ流さず、sandbox 内 artifact として回収し、review 後に昇格させる手順を置く。

注意

注意点

guide ページ上に公開日は明記されていない。必要なら changelog や docs 履歴の別確認が要る。
sandbox を separate にしただけで安全や再現性が完成するわけではない。provider の isolation、storage、credential 配置、artifact review は別設計が要る。
preview や ports を扱えることは便利だが、そのぶん application server と sandbox の責任分界が曖昧だと、どこで secrets や state が漏れるか追いにくくなる。