［開発者向け］Windowsに「コーディングエージェント向けサンドボックス」はなかった——OpenAI Codexが採用した4層アーキテクチャの設計思想

2026-05-17

はじめに

　OpenAIのCodexチームのメンバーであるDavid Wiesen氏が2026年5月13日、WindowsにおけるCodexのサンドボックス実装を詳細に解説した技術記事を公開しました。本稿では、既存Windowsツールの限界を出発点に、2段階のプロトタイプを経て最終アーキテクチャに至るまでの設計判断を整理します。

参考記事

タイトル: Building a safe, effective sandbox to enable Codex on Windows
著者: David Wiesen（Member of Technical Staff）
発行元: OpenAI Engineering Blog
発行日: 2026年5月13日
URL: https://openai.com/index/building-codex-windows-sandbox/

要点

macOSにはSeatbelt、LinuxにはseccompやBubblewrapという実績ある分離機能があるが、Windowsには「エージェント型開発ワークフローを安全に隔離できる」機能が標準で存在せず、AppContainer・Windows Sandbox・MICはいずれも採用要件を満たすものではなかった
第一プロトタイプは合成SID（セキュリティ識別子）と書き込み制限トークンでファイル書き込みを制御したが、ネットワーク遮断は環境変数ベースの「助言的」な方式にとどまり、意図的な回避が可能であった
ネットワーク遮断を強化するにはWindowsファイアウォールが必要であり、そのためにはCodexが生成するコマンドを「別のWindowsユーザー」として実行する設計への転換が不可欠であった
最終設計（昇格サンドボックス）は管理者権限での初回セットアップを前提とし、2つの専用ローカルユーザー（CodexSandboxOffline/Online）・ファイアウォールルール・専用バイナリ（codex-command-runner.exe）を組み合わせた構成である
最終アーキテクチャはcodex.exe・セットアップバイナリ・コマンドランナー・子プロセスの4層からなり、各層が職責を明確に分離した設計である

詳細解説

Codexにとってのサンドボックスとは何か

　Codexはデベロッパーのラップトップ上で動作するコーディングエージェントであり、CLI・IDEプラグイン・デスクトップアプリを通じて利用されます。エージェントはクラウド上のモデルからの指示を受け、テストの実行・ファイルの読み書き・Gitブランチの作成など、多様なローカルコマンドを実行します。

　Codexはデフォルトで実ユーザーと同等の権限で動作するため、強力である一方で潜在的なリスクも伴います。そのリスクを抑えながら生産性を損なわないために、「ファイル書き込みをワークスペース内に限定し、インターネットアクセスを遮断する」デフォルトモードをサンドボックスとして実装しています。macOSでは同機能をSeatbeltで、LinuxではseccompやBubblewrapで実現していますが、Windowsにはこれらに相当する汎用的なプロセス分離機能が標準で用意されておらず、ゼロから設計する必要がありました。

候補3つがいずれも不採用となった理由

　Windowsが既に提供している3つの機能を検討しましたが、いずれも採用に至りませんでした。

　AppContainerはWindowsネイティブのサンドボックスであり、事前に利用リソースが明確なアプリ向けの能力ベース分離モデルです。しかしCodexが必要とするのは、シェル・Git・Python・パッケージマネージャ・ビルドツールなど、実行前にリストアップできないオープンエンドなワークフローです。「利用するリソースを事前に宣言する」という前提がCodexの用途と合わず、採用を見送りました。

　Windows Sandboxは強力な隔離境界を持つ軽量VMですが、ユーザーの実際のコードベースとは分離された「使い捨てデスクトップ」として動作します。Codexが直接ユーザーの実環境で操作することを前提としている点と根本的に相容れず、加えてWindows Home SKU（一般向けエディション）では利用できないという制約もありました。

　MIC（Mandatory Integrity Control、必須整合性制御）は、プロセスやファイルに整合性レベル（低・中・高）を付与し、低整合性プロセスが高整合性オブジェクトへ書き込めないようにする仕組みです。ワークスペースを低整合性としてマークすれば書き込み制限を実現できるように見えましたが、この変更はCodexだけでなくホストOS上の低整合性プロセス全般に影響します。開発機のセキュリティモデルを広範に変えることになるため、採用しませんでした。

第一プロトタイプ：SIDと書き込み制限トークンによる制御

　既存ツールが使えないと判断したOpenAIは、独自のサンドボックス実装に着手しました。第一プロトタイプの設計目標は「管理者権限（UAC昇格）不要で動作すること」でした。

　ファイル書き込みの制限には、SID（Security Identifier、セキュリティ識別子）と書き込み制限トークンを組み合わせました。SIDはWindowsがアクセス許可を紐付けるIDで、実ユーザーやグループのほか、ACL（アクセス制御リスト）に登録できる「合成SID」も作成できます。この仕組みを利用し、Codexサンドボックス専用の合成SID（sandbox-write）を作成しました。

　書き込み制限トークン（Write-restricted Token）とは、書き込み操作に「通常のユーザー権限チェック」に加えて「トークンの制限SIDリスト内の少なくとも1つにも書き込み許可があるか」という追加チェックを課すプロセストークンです。この仕組みにより、sandbox-write SIDに書き込みが許可されたディレクトリ（カレントワーキングディレクトリや追加設定したルート）のみへの書き込みを制限しました。.git や .codex ディレクトリには明示的に書き込みを拒否する設定も行っています。

　一方、ネットワーク遮断は HTTPS_PROXY=http://127.0.0.1:9 などの環境変数で疎通しないエンドポイントに向ける方式でした。GitのHTTP(S)やSSHの経路を遮断するよう設計されていましたが、この方式は「助言的（advisory）」な制御にとどまります。環境変数を無視するプログラムや、独自のソケット実装を持つコードは容易に回避できる構造でした。

なぜWindowsファイアウォールが必要になったか

　環境変数ベースのネットワーク抑制は、悪意のあるコードだけでなく、プロキシ設定を無視する通常のツールによっても回避されます。真のネットワーク遮断にはWindowsファイアウォールが必要でしたが、管理者権限なしではファイアウォールルールを作成できませんでした。

　また、Windowsファイアウォールは「特定のバイナリ」や「特定のユーザー」単位でのルール適用はできますが、「合成SIDを含む制限トークン配下のプロセスツリー」という粒度にはマッチングできません。たとえば codex.exe 自体をブロックしても、エージェントが起動するGit/Pythonプロセスは対象外となります。逆にポートやアドレス単位での制限は設計意図に合いません。

　結論として、Codexが生成するコマンドを「実ユーザーとは別のWindowsユーザー」として実行し、そのユーザーにファイアウォールルールを適用する設計が必要でした。これが「昇格サンドボックス」への転換を促した根本的な理由です。

最終設計：昇格サンドボックスの4層アーキテクチャ

　現行の実装（昇格サンドボックス）は、初回セットアップ時に管理者権限を必要とします。Codexが内部的に2つの専用ローカルユーザーを作成し、これをコマンド実行の主体として利用します。

CodexSandboxOffline：ファイアウォールによるアウトバウンドネットワーク遮断の対象となるユーザー
CodexSandboxOnline：ファイアウォールルール非適用のユーザー（インターネットアクセスが必要な操作向け）

　セットアップ処理は専用バイナリ codex-windows-sandbox-setup.exe が担い、合成SIDの作成・専用ユーザーの作成と認証情報のDPAPI（Windows Data Protection API）暗号化保存・ファイアウォールルールの設定・読み取りACLの付与などを実行します。読み取りACLの付与は非同期で行われるため、セットアップ全体の待機時間を最小限に抑えています。

　コマンド実行には新たなバイナリ codex-command-runner.exe が介在します。codex.exe から直接サンドボックスユーザーとして制限トークン付きのプロセスを起動しようとすると、Windowsの CreateProcessAsUserW（別ユーザーとしてプロセスを起動するAPI）の権限壁に阻まれるためです。そこでまず codex.exe が CreateProcessWithLogonW でサンドボックスユーザーとして codex-command-runner.exe を起動し、そのランナーが自身のトークンから制限トークンを生成して実際のコマンドを起動する2段構成を採用しています。

　最終的なアーキテクチャは次の4層からなります。