2026年9月22日時点で、OpenAIの公式資料はAgents API、計算環境、サンドボックスエージェント、実行トレースを別々の資料で説明しています。Agents APIの公式紹介とAgents SDKのサンドボックス文書を突き合わせると、OpenAI Hosted Sandboxesはコード実行型エージェントの素早い検証には向いていますが、そのまま本番環境とは判定できません。
症状： デモではコード実行とファイル生成に成功するのに、権限、再実行、ネットワーク障害、監査ログの確認ができていない。
最短の解決策： OpenAI Hosted Sandboxesの検収チェックリストを準備、初回実行、灰度運用、継続監視の順に実施し、1項目でも証拠が残らなければ本番公開を止めてください。
このガイドは、コードを安全に実行したいAgent開発者、サンドボックスや認証情報を管理するプラットフォームエンジニア、そして本番採用の可否を判断する技術責任者向けです。OpenAI Agents APIの入門やパラメーター一覧ではなく、公開前の検収に絞ります。
OpenAI Hosted Sandboxes は本番環境に向いていますか
結論は「タスクの種類とデータ境界次第」です。次のように分けると、過大評価を避けられます。
| 判定 | 向いている処理 | 検収で確認する証拠 | 次の判断 |
|---|---|---|---|
| 進めやすい | コード実行、帳票や画像などの一時ファイル生成、限定されたデータ加工 | 同一入力で同一形式の成果物が取得できる | 小規模な検証を継続 |
| 条件付きで可能 | 長時間処理、外部APIの参照、複数ツールを連続利用するAgent | タイムアウト、再試行、重複実行、利用量の記録 | 灰度運用で観測 |
| 直接托管を避ける | 個人情報や秘密情報の大量処理、社内ネットワークへの書き込み、複雑なVPC接続、物理機器の操作 | 権限分離と監査証跡を自社要件で説明できない | 自有サンドボックスやVPCを評価 |
OpenAIの計算環境に関する説明は、Agentがコードやコンピューター環境を利用する構成を示すものです。計算環境の公式説明だけを根拠に、任意の社内システムへ安全に接続できる、あるいは全てのリソース仕様が固定されていると判断してはいけません。具体的なリソース、利用可能なリージョン、ネットワーク、料金、API仕様は、公開時点の公式文書と契約条件を再確認してください。
適性を決める三つの質問
- 失敗しても、入力データを再投入できる処理ですか。
- Agentが書き込む先を専用ディレクトリやテスト用サービスに限定できますか。
- 成果物が失われた場合に、人間が再生成または復旧できますか。
三つのうち一つでも「いいえ」なら、Hosted Sandboxだけで本番処理を完結させる設計は避けます。特に外部システムへの書き込みは、コード実行の成功とは別の承認段階に分けるべきです。
第1段階：起動前に権限とデータ境界を固定する
最初に確認するのは、モデルが何を呼び出せるかではなく、呼び出した結果として何を変更できるかです。Agentにツールを登録できることは、OS、ファイル、データベース、外部サービスの完全な権限を与える理由にはなりません。
Agents API サンドボックスのファイルとネットワーク権限を制限する方法
次の順番で権限を狭めます。
- ファイル領域を用途別に分けます。 入力専用、作業用、成果物用を分離し、作業用から元データを上書きできないようにします。
- 秘密情報をファイルへ直書きしません。 APIキーや接続情報は、実行時に必要な範囲だけ注入し、プロンプトや生成ログへ出ないテストを行います。
- ネットワークを段階化します。 まず外部通信なしで動かし、次に許可先を限定した通信、最後に実サービスへの接続を試します。
- 書き込み操作を別ツールにします。 読み取りと更新を同じツールにせず、更新時には対象、操作者、承認情報を記録します。
- 機密データを最小化します。 本番データの代わりに匿名化済みの固定サンプルを使い、マスキング前後の差分を確認します。
ここでの「権限が狭い」は、単にプロンプトへ禁止事項を書くことではありません。実行ユーザー、許可ディレクトリ、環境変数、送信先、ツールの引数検証をそれぞれ設定し、Agentが指示を誤解しても被害範囲が増えない構造にします。
Kvmzenのリモート開発環境におけるMacの利用方法でも、接続方式と利用者権限を分けて考える必要があります。Hosted Sandboxの検収でも、認証情報を持つ実行主体と、人間が承認する主体を同一にしないことが重要です。
第2段階：依存関係、ファイル、再起動を同じサンプルで検証する
「一度成功した」は検収結果になりません。最小の固定サンプルを作り、同じ入力を複数回実行して、依存関係の導入、作業ディレクトリ、出力ファイル、終了状態を記録します。
OpenAI Hosted Sandboxesで依存関係と永続化ファイルを確認する手順
- 再現用リポジトリを固定します。 実行スクリプト、依存関係の定義、入力ファイル、期待する出力形式を同じ場所に置きます。
- 空の環境から開始します。 既存のキャッシュに頼らず、パッケージのインストールが成功するか、バージョンの不一致がないかを記録します。
- 入口を一つにします。 Agentが自由に複数のスクリプトを選ばないよう、検証用の実行入口と引数を限定します。
- 作業ディレクトリを表示します。 相対パスだけで処理せず、入力、途中生成物、最終成果物の保存場所を実行ログに残します。
- 成果物を外部から取得します。 サンドボックス内にファイルが存在するだけでなく、利用者が識別できる名前、形式、サイズで取得できることを確認します。
- 途中で停止させます。 強制終了後に、壊れたファイル、残った一時情報、再実行時の重複がないか確認します。
- 同一サンプルを繰り返します。 成功回数ではなく、入力、実行ID、依存関係、成果物の対応関係が毎回追跡できるかを見ます。
ファイルの永続化は「サンドボックスが再起動しても全て残る」と解釈しないでください。永続領域、実行中だけの一時領域、外部ストレージへ退避する成果物を分け、各領域の保持条件を公式資料で確認します。Agents SDKの実行とトレースの説明も参照しながら、実行IDと成果物IDを結び付けてください。
第3段階：ネットワーク、タイムアウト、失敗復旧を灰度運用で試す
クラウドAI Agentのコード実行を本番前に確認するなら、成功ケースより失敗ケースを先に設計します。ネットワークが使える状態だけで試すと、DNS障害、許可先の変更、外部サービスの遅延によって、同じ処理がいつまでも終わらない危険があります。
次の三つの境界を分けて試します。
- 通信なし： ローカル処理、ファイル変換、計算だけで完了するか。
- 限定通信： 許可したエンドポイントだけに接続し、その他の送信が拒否されるか。
- 外部サービス接続： 応答遅延、認証失敗、5xx相当のエラー、空の応答を受けたときに安全に終了するか。
各試験では、制限時間、キャンセル、再試行回数、重複防止キーを確認します。再試行は便利ですが、決済、チケット発行、データ更新のような副作用を持つ処理では、同じ操作を二重に実行する可能性があります。読み取りと書き込みを分離し、書き込み前に人間または別の承認処理を挟む設計が安全です。
OpenAIのトレース機能に関する公式文書が示すように、Agentの実行を追跡する仕組みは、最終回答だけを見るためのものではありません。リクエスト、ツール呼び出し、エラー、終了理由、成果物を同じ実行単位で確認できる状態を目指します。
第4段階：ログ、監査、コスト上限を公開条件にする
本番公開の判定では、成功した成果物だけでなく、失敗した実行を後から説明できるかを確認します。最低限、次の項目をログに残します。
- 実行ID、開始時刻、終了時刻、終了理由
- Agentへの入力の識別子と、機密情報を除いたリクエスト概要
- 呼び出したツール名、引数の検証結果、承認者
- コード実行の標準出力、標準エラー、失敗箇所
- 生成物の識別子、保存場所、取得結果
- 再試行回数、キャンセル、タイムアウト、ネットワークエラー
- 利用量、処理時間、同時実行数
入力全文や秘密情報を無制限に保存すると、監査のためのログが新たな漏えい源になります。マスキング方針、保存期間、閲覧権限、削除手順を先に決めてください。利用量の確認にはAgents SDKの用量統計文書を使い、具体的な料金は推測せず、公開時点の公式価格と契約条件から算出します。
Go / No-Go判定
次の項目を一つずつ実行し、証拠のリンクまたは実行IDを添えて判定します。
- [ ] 読み取り権限と書き込み権限を分離した
- [ ] 秘密情報がプロンプト、標準出力、トレースに現れない
- [ ] 外部通信なし、限定通信、実サービス接続を個別に試した
- [ ] 依存関係を空の環境から導入できた
- [ ] 作業用ファイルと成果物の保存先を区別した
- [ ] 再起動後のファイル保持条件を確認した
- [ ] タイムアウトとキャンセル後に処理を再開できた
- [ ] 再試行による二重書き込みを防止した
- [ ] 失敗した実行を実行IDから追跡できた
- [ ] 同時実行数、処理時間、利用量、予算上限を設定した
- [ ] 機密データを匿名化済みサンプルで置き換えた
- [ ] 公式資料で仕様変更を再確認する担当者と手順を決めた
一つでも未確認ならNo-Goです。特にファイル保持、秘密情報、ネットワーク、書き込み操作の四つは、デモの成功だけでは代替できません。
Hosted Sandboxを続けるか、自有環境へ移すか
Hosted Sandboxを続ける判断は、処理が短く、データを限定でき、失敗後に再実行でき、外部接続を許可先へ絞れる場合です。反対に、社内ネットワークの複雑な経路、厳格なデータ所在要件、専用監査基盤、長時間の常駐処理、物理インターフェースが必要なら、自有サンドボックスやVPCを比較します。
自社運用へ移すと、ネットワーク制御や監査方式を細かく設計できますが、パッチ適用、隔離、容量管理、障害対応を自分で負担します。クラウドMac環境は、macOS固有のツール、GUI操作、物理OSに近い検証が必要な場合の候補ですが、ネットワークとファイル権限を自動的に解決するものではありません。必要ならKvmzenのMacレンタル利用案内で、用途と接続条件を確認してから比較してください。
現在の簡易な共有サーバーや開発者個人のマシンで運用すると、権限が広すぎる、実行状態を再現できない、失敗ログが分散するという欠点が出やすくなります。さらに、同じ環境を長期間維持するための更新作業と、他の処理とのリソース競合も避けにくい問題です。
そのため、短期の検証や一時的なコード実行ならHosted Sandboxを検収表に沿って使い、macOSの実機相当環境や隔離された開発ノードが必要なら、KvmzenのMacレンタルを候補に加えるのが現実的です。まず固定サンプルを一度実行し、上のチェック項目に証拠を付けてください。未確認項目が残るなら公開を急がず、権限分離、ファイル保持、ログ設計を直してから次の環境を選びます。