For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション
Theme

サンドボックス

ChatGPT と Codex の各クライアントにおけるサンドボックスの仕組み

サンドボックスは、エージェントが自律的に作業できる範囲を定め、コンピューターへのアクセスを制限します。ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能のローカルチャットでコマンドを実行すると、デフォルトではフルアクセスが付与されず、制限された環境で実行されます。

この環境によって、エージェントが変更できるファイルや、コマンドがネットワークを利用できるかどうかなど、エージェントが単独で行える操作が決まります。その範囲内であれば、エージェントは確認のために中断することなく作業を続けられます。範囲を超える操作が必要になった場合は、承認手続きに進みます。

サンドボックスと承認は、役割の異なる 2 つの仕組みで、互いに補い合います。サンドボックスは操作に技術的な制限を設けます。承認ポリシーは、その制限を超える前にエージェントが作業を止めて承認を求める条件を定めます。

サンドボックスの適用範囲

サンドボックスは、組み込みのファイル操作だけでなく、エージェントが起動するコマンドにも適用されます。git、パッケージマネージャー、テストランナーなどのツールを実行する場合も、それらのコマンドには同じ制限が適用されます。

Codex は各 OS に備わった仕組みを使って制限を適用します。実装は macOS、Linux、WSL2、ネイティブ Windows で異なりますが、どのクライアントでも考え方は同じです。エージェントの作業範囲を明確に定めることで、エージェントはその範囲内の日常的なタスクを自律的に実行できます。

サンドボックスの利点

サンドボックスを使うと、繰り返し承認を求められる負担が減ります。すでに承認した範囲内であれば、エージェントはファイルを読み書きし、プロジェクトで日常的に使うコマンドを実行できます。リスクの低いコマンドを実行するたびに確認を求める必要はありません。

エージェントに作業を任せる際の信頼の根拠も明確になります。エージェントの意図だけに頼らず、システムが制限を適用し、その範囲内でエージェントが動作することを前提にできます。どのようなときにエージェントが作業を止めて判断を求めるかがわかるため、自律的な作業を任せやすくなります。

利用開始

デフォルトの権限モードでは、サンドボックスが自動的に適用されます。

前提条件

macOS では、組み込みの Seatbelt フレームワークにより、追加の設定なしでサンドボックスを利用できます。

Windows では、PowerShell で Codex を実行するとネイティブの Windows サンドボックスが使われ、WSL2 で実行すると Linux のサンドボックス実装が使われます。

Linux と WSL2 では、まずパッケージマネージャーで bubblewrap をインストールしてください。

Choose an option
sudo apt install bubblewrap

Codex が使用する bwrap 実行ファイルは、PATH 上で最初に見つかったものです。bwrap 実行ファイルが見つからない場合、Codex は同梱のヘルパーを使用します。ただし、ヘルパーを使うには、非特権ユーザーがユーザー名前空間を作成できる必要があります。確実に動作させるには、bwrap を提供するディストリビューションのパッケージをインストールしてください。

bwrap が見つからない場合や、ヘルパーが必要なユーザー名前空間を作成できない場合、Codex は起動時に警告を表示します。AppArmor でユーザー名前空間の作成を制限しているディストリビューションでは、bwrap 用の AppArmor プロファイルを読み込むことをおすすめします。これにより、システム全体の制限を無効にせずに bwrap を使い続けられます。

Ubuntu での AppArmor に関する注意点: Ubuntu 25.04 では、Ubuntu のパッケージリポジトリから bubblewrap をインストールすれば、通常は AppArmor の追加設定なしで動作します。bwrap-userns-restrict プロファイルは apparmor パッケージに含まれており、/etc/apparmor.d/bwrap-userns-restrict に配置されます。

Ubuntu 24.04 では、bubblewrap をインストールした後も、必要なユーザー名前空間を作成できないという警告が Codex に表示されることがあります。次のコマンドで追加のプロファイルをコピーして読み込んでください。

sudo apt update
sudo apt install apparmor-profiles apparmor-utils
sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict

apparmor_parser -r を実行すると、再起動せずにプロファイルをカーネルに読み込めます。次のコマンドですべての AppArmor プロファイルを再読み込みすることもできます。

sudo systemctl reload apparmor.service

このプロファイルが利用できない場合や、読み込んでも問題が解決しない場合は、次のコマンドで、非特権ユーザーによるユーザー名前空間の作成に対する AppArmor の制限を無効にできます。

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Work クラウドからのローカルコンピューターへのアクセス

Work クラウドからローカルコンピューターにアクセスするタスクでは、OpenAI のクラウドが会話の進行を管理します。適用されるサンドボックスの制限は、各ステップの実行場所によって異なります。

  • クラウドでの実行: Work のクラウドコンテナには、既存の Work クラウドポリシーが適用されます。デスクトップブラウザのサイトルールは、クラウドブラウザには自動的に適用されません。
  • ローカルでの実行: 接続されたコンピューターで実行するステップには、サポート対象のローカル実行要件が適用されます。

ローカルアクセスを使用する Work と dot では、管理ポリシーが有効な場合、サポート対象のグローバルポリシーが共有のクラウドオーケストレーターに適用されます。Work のクラウドコンテナと dot のクラウドコンピューターには、それぞれ固有の実行設定と要件が適用されます。ローカルとクラウドで個別に実行をテストし、各環境でどの制限が有効かを確認してください。一方の環境のポリシーによって、もう一方の環境へのアクセスが許可されることはありません。

ポリシー内での優先順位は、高い順に、OS 別の環境設定による上書き → 全 OS 共通の環境設定による上書き → グローバル設定です。優先順位の低いポリシーのほうが具体的であっても、優先順位の高いポリシーが適用されます。ローカルでの実行では、MDM と従来の管理対象デバイスの要件がエージェントセキュリティの設定よりも優先されます。エージェントセキュリティの設定は、デバイスのシステム要件ファイルよりも優先されます。

フィールドごとのマージルールと実行時の制限については、管理対象の設定を参照してください。実際に適用されるファイルとネットワークの制限は、Work のローカルセキュリティと Work のクラウドセキュリティで確認してください。

権限の仕組み

利用中のクライアントの権限設定で、Codex がローカル操作を行う際の動作を変更できます。

承認の設定によって、Codex がどのような操作の前に一時停止するかが決まります。サンドボックスは、コマンドがアクセスできるファイルとネットワークリソースを制限します。今回だけ承認するか、セッション中は承認するかなど、承認の有効範囲を選べる場合は、タスクを続けられる最小限の範囲を選んでください。デフォルトのアクセス範囲はプロジェクト内にとどめてください。関連のないリポジトリにまでアクセス範囲を広げずに、別のプロジェクトや Worktree を使用してください。

ChatGPT デスクトップアプリでは、コンポーザーの下にある権限設定を使用します。構成によっては、メニューに承認を求める、対象の承認リクエストに対する代わりに承認する、フルアクセスのほか、名前付きの権限プロファイルやカスタム権限プロファイルが表示されます。

この例でモードを選択して、権限設定を試してみてください。ここでの選択は、ChatGPT や Codex の実際の権限には影響しません。

How should ChatGPT actions be approved?Learn more

Approve for me

Approve for me keeps the same workspace-write sandbox as Ask for approval, but eligible approval requests are routed through automatic review instead of showing a prompt for manual approval. More details about automatic review.

Sandbox
workspace-write
Approvals policy
on-request
Reviewer
auto_review

デフォルトの設定

毎回同じ設定で作業を開始するには、config.toml にデフォルト値を設定します。設定の仕組みは設定の基本を参照してください。設定リファレンスには、sandbox_mode、approval_policy、approvals_reviewer、sandbox_workspace_write.writable_roots の各キーの詳細が記載されています。これらの設定で、エージェントがデフォルトで自律的に行える操作の範囲、書き込み可能なディレクトリ、承認を求めて一時停止する条件、対象の承認リクエストのレビュー担当者を指定します。

主なサンドボックスモードは次のとおりです。

  • read-only:エージェントはファイルを読み取れますが、ファイルの編集やコマンドの実行には承認が必要です。
  • workspace-write:エージェントはファイルを読み取ることができ、ワークスペース内でファイルを編集したり、日常的なローカルコマンドを実行したりできます。ローカル作業を少ない手間で進められるデフォルトのモードです。
  • danger-full-access:エージェントはサンドボックスの制限を受けずに動作します。ファイルシステムとネットワークの制限が解除されるため、エージェントにフルアクセスで作業させる場合にのみ使用してください。

主な承認ポリシーは次のとおりです。

  • on-request:エージェントはデフォルトでサンドボックス内で作業し、その範囲を超える必要がある場合に承認を求めます。
  • never:エージェントは承認を求めて一時停止することはありません。

Codex と ChatGPT Work では、承認ポリシーとして untrusted を選択できなくなりました。既存の設定でこの値を使用している場合は、廃止された untrusted 承認ポリシーからの移行を参照してください。

対話形式で承認を求める場合は、approvals_reviewer でレビュー担当者も指定できます。

  • user:ユーザーに承認リクエストが表示されます。これがデフォルトです。
  • auto_review:対象の承認リクエストはレビュー担当のエージェントに送られます(自動レビューを参照)。

フルアクセスにするには、sandbox_mode = "danger-full-access" と approval_policy = "never" を組み合わせます。一方、ローカルでの自動化のリスクを抑えるプリセットは、sandbox_mode = "workspace-write" と approval_policy = "on-request" の組み合わせです。対応する CLI フラグ --sandbox workspace-write --ask-for-approval on-request でも同じ設定ができます。手動で承認する場合は approvals_reviewer = "user" のままにし、承認リクエストの自動レビューを使用する場合は approvals_reviewer = "auto_review" に設定します。

エージェントが複数のディレクトリで作業する必要がある場合は、書き込み可能なルートディレクトリを指定することで、サンドボックスを解除せずに変更可能な範囲を広げられます。信頼する範囲を広げたり狭めたりする必要がある場合は、その都度例外を設けるのではなく、デフォルトのサンドボックスモードと承認ポリシーを調整してください。

ワークフローに特定の例外が必要な場合は、ルールを使用してください。ルールを使うと、サンドボックス外で実行するコマンドについて、プレフィックスごとに許可するか、承認を求めるか、禁止するかを指定できます。アクセス範囲を一律に広げるよりも、この方法が適している場合が多くあります。IDE 固有の設定を開く方法は、Codex IDE 拡張機能の設定を参照してください。

自動レビューが利用できる場合も、サンドボックスの範囲は変わりません。自動レビューは、承認が必要になったときに approvals_reviewer で指定できるレビュー方法の 1 つです。対象となるのは、サンドボックスの制限を超える権限のリクエスト、ブロックされたネットワークへのアクセス、外部の状態を変更するツール呼び出しのうち承認が必要なものなどです。サンドボックス内ですでに許可されている操作は、追加のレビューなしで実行されます。レビュー担当エージェントのライフサイクル、レビューが開始される条件の種類、リクエストが拒否された場合の動作、設定の詳細については、自動レビューを参照してください。

プラットフォーム固有の詳細は、各プラットフォームのドキュメントに記載されています。ネイティブ Windows でのセットアップ、動作、トラブルシューティングについては、Windows を参照してください。管理者が指定する要件や、サンドボックスと承認に関する組織レベルの制限については、エージェントの承認とセキュリティを参照してください。