OpenAI Agents SDK Sandbox 2026：リリース前にどう受け入れ検証する？
サンプル実行は成功したのに、実環境では作業領域の外を読み書きし、途中停止後に同じ処理を繰り返します。
最短の解決策は、Sandboxをすぐ本番へ進めず、作業領域の契約、決定論的テスト、実環境統合、権限分離、状態復元、失敗時のロールバックをこの順に通過させることです。
この検証手順は、すでにSandboxAgentのサンプルを動かしたものの、リリース基準が決まっていない開発者向けです。ファイル操作、コマンド実行、ネットワーク、資格情報の境界を確認するプラットフォームエンジニアや、ローカル、コンテナ、クラウドMacのどこで検証するか判断するAI技術責任者にも適しています。
最終更新：2026年8月26日。Sandbox Agentsがbeta扱いであること、APIや既定値、対応機能が正式提供前に変わる可能性があることは、Sandbox Agents公式クイックスタートと公式の概念・ライフサイクル説明を基準に確認しています。
最初に作業領域の契約を固定する
受け入れ検証で最初に確認するのは、モデルの回答品質ではありません。Agentが「どこまで触れてよいか」です。
作業領域について、次の項目を1つの基準ファイルに固定します。
- 読み取り可能なディレクトリ
- 作成、変更、削除できるファイル
- 生成物の保存先
- 実行を許可するコマンド
- 利用可能な環境変数
- ネットワーク接続の範囲
- 資格情報や外部ストレージへの経路
- 実行時のユーザー、グループ、ホスト側パス
Manifest、実行主体、利用するツール、SandboxRunConfigの想定値も記録します。設定値を開発者のマシンから暗黙に引き継ぐ構成は、再現可能な検証環境とは呼べません。新しい環境を作り直しても同じ契約が適用されることが、最初の合格条件です。
SandboxAgentの検証では、成功した生成物だけでなく、外部パスへのアクセス拒否や、許可されていないコマンドの停止結果も証拠として保存します。
まず決定論的テスト、次に実行環境の検証
先にSDKの編成境界を確定する
実際のモデルやサンドボックスを毎回動かす前に、公式のテスト機能で編成ロジックを固定します。Agents SDKのテストガイドでは、実行結果をあらかじめ定義したテストや、サンドボックスセッションを制御する方法が説明されています。
この段階では、次の経路を分けて記録します。
- 正常なツール呼び出し
- 不正な引数や許可外の引数
- コマンド失敗
- 対象ファイルが存在しない場合
- ツール応答が空、または想定外の形式の場合
- リトライ後に処理を終了する場合
- 途中で最終出力へ移る場合
scripted_sandbox_sessionのAPI仕様を使うテストは、引数、能力の振り分け、例外処理、最終応答の組み立てを再現しやすくします。ただし、これはファイルシステム、プロセス、実際の権限境界を証明するものではありません。決定論的テストが合格でも、実環境統合を省略してはいけません。
実環境では依存関係と作業ディレクトリを照合する
次の段階では、交付先と同じ依存関係、ディレクトリ構成、起動方法で代表タスクを実行します。確認対象は、単にコマンドが終了するかではありません。
- 作業ディレクトリが毎回同じ意味になるか
- 相対パスが別の場所を指さないか
- 必要なファイルだけが初期状態に存在するか
- 生成物の名前、内容、保存先が一致するか
- 読み取り専用の領域へ変更を試みたときに拒否されるか
- コマンド終了コードをAgentが正しく解釈するか
- 冷たい起動、連続実行、並行実行で状態が混ざらないか
冷たい起動や並行実行の所要時間を記録する場合、一般論の数字を合格基準にしないでください。採用する環境、依存関係、タスク内容を固定し、同じ条件で得た記録だけを比較対象にします。
macOS専用のツールチェーン、署名処理、システムコンポーネントを含む場合は、他のOSのコンテナ結果で代用できません。実際のMac環境で、権限、キーチェーン、ファイル属性、署名後の生成物まで再確認します。
ファイルとコマンドの権限を段階的に拒否する
SandboxAgentの権限検証では、許可された操作を実行できることより、不要な操作を確実に止められることが重要です。
検証は低リスクから高リスクへ進めます。最初は作業領域内の読み取り、次に指定範囲への書き込み、その後に削除、上書き、外部送信、高権限コマンドへ移ります。各操作について、許可、拒否、承認要求のどれになるかを明文化します。
本番式の検証で最低限保存する証拠は次のとおりです。
- Agentが要求したパスと実際に解決されたパス
- 実行したコマンドと終了結果
- 利用した環境変数の名前
- 外部通信の宛先と拒否結果
- 承認が必要になった時点
- 失敗時に残ったファイルとプロセス
ローカルのクライアントが見せる操作画面を、安全な隔離環境そのものと見なしてはいけません。ホスト側のパス、認証情報、ネットワーク、プロセス名前空間がどのように分離されるかを、採用するクライアントと実行形態ごとに確認します。SandboxRunConfigの公式リファレンスに記載された設定境界も、使用中のバージョンと照合してください。
中断と再開で、成功経路以外を検証する
長時間のタスクでは、最後まで正常終了したケースだけでは不十分です。実行中に意図的な中断を入れ、状態がどこに保存され、何を復元できるかを確認します。
確認手順は次の流れです。
- 初期ファイルと実行識別子を保存します。
- 低リスクの準備処理を完了させます。
- ファイル変更や外部送信の直前で実行を中断します。
- セッション状態、スナップショット、作業領域の保存結果を取得します。
- 新しい実行として復元し、完了済みの処理が再実行されないか確認します。
- 復元後の生成物と、開始前の基準ファイルを比較します。
- 復元不能、内容不一致、清掃失敗のそれぞれに対する終了規則を適用します。
特に危険なのは、復元後に削除や外部送信を二重実行するケースです。処理済みの操作を識別できない場合は、再開を合格にせず、環境を破棄して新規作成へ戻します。古いタスクのファイルが新しいセッションへ混入する場合も同じ扱いです。
状態とイベントの確認には、Agents SDK Tracingの公式説明を使って、ツール呼び出し、分岐、失敗、再開点を追跡できる形にします。ログが最終回答しか残さない構成では、原因調査と再現性の証拠が不足します。
放行前に「合格・補測・阻断」を分ける
最後は、1回の成功デモではなく、証拠の状態で判断します。次のチェックリストをリリース判定にそのまま使えます。
- [ ] ManifestとSandboxRunConfigの基準版を保存した
- [ ] 初期ディレクトリと許可パスを新規作成環境で再現した
- [ ] 正常、失敗、ファイル不存在、早期終了の編成テストを実行した
- [ ] 実環境で代表タスクの生成物と終了結果を照合した
- [ ] 作業領域外の読み書き、許可外コマンド、不要な通信を拒否できた
- [ ] 環境変数と資格情報が必要最小限に限定されている
- [ ] 中断後に状態、スナップショット、作業領域を復元できた
- [ ] 完了済みの高リスク操作を二重実行しないことを確認した
- [ ] 復元不能時に環境を破棄して再作成する手順がある
- [ ] 設定版、ログ、異常記録、判定者、責任者を保存した
判定は次の3分類にします。
- 合格：契約、権限、復元、ロールバックの証拠がそろい、再実行でも結果が一致する。
- 補測：性能差や一部の互換性など、追加条件を固定すれば判断できる。
- 阻断：越権アクセス、資格情報の露出、環境の再現不能、復元不一致、ロールバック不足がある。
macOS依存の署名処理やシステムツールを使う場合、複数の実行を分離して短期間に回帰する場合、開発者の端末と交付環境の差が大きい場合は、独立したクラウドMacを追加します。逆に、長期の安定した高負荷処理や物理インターフェースへの依存が中心なら、レンタル環境だけで恒久運用を決めるべきではありません。
実行環境の申請や引き渡し条件を確認する場合は、ProxyMacのヘルプとコンソール案内を参照できます。環境を借りた後も、開発環境をそのまま本番へ移すのではなく、このチェックリストを使って再度、作業領域、権限、復元を検証します。
ローカル環境だけで進める方法は、費用や準備の面では扱いやすい一方、macOS固有の依存関係、チーム間の環境差、並行回帰用の分離不足が残りやすいです。コンテナだけに寄せる方法も、署名やシステムコンポーネントの再現、ホスト権限の確認で詰まることがあります。そこが阻断要因なら、検証期間と必要な分離単位を決めたうえでProxyMacのクラウドMacを使う方が、交付前の再検証を組み立てやすくなります。短期の検証環境が必要な場合は、ProxyMacの料金案内で条件を確認し、最終判定は必ず本稿の放行基準に戻してください。
