CodexをWindowsで動かす方法｜インストール手順とWSL2の要否、動かないときの対処【2026年8月版】

WindowsでCodexを使おうとして、最初に迷うのは「WSL2を入れるべきかどうか」ではないでしょうか。検索して出てくる日本語の解説記事の多くは「業務で使うならWSL2」と書いています。

しかし、2026年8月時点のOpenAI公式ドキュメントは、その逆を推奨しています。 既定ではネイティブWindowsサンドボックスを使い、WSLは条件に当てはまる場合に選ぶもの、という位置づけです。

この転換は、単なる好みの問題ではありません。どちらでエージェントを動かすかによって、プロジェクトファイルを置くべき場所の結論まで逆転します。 ここを取り違えたまま環境を作ると、Gitが検出されない、ビルドが異常に遅い、設定が共有されないといった不具合が後から効いてきます。

本記事は、Windowsという環境がCodexに持ち込む差分だけを扱います。Codexそのものの説明はCodexとは何かを整理した記事に、OSを問わない使い方はCodex CLIの使い方をまとめたガイドに譲り、ここではWindows固有の判断と手順、そしてつまずきの解決に集中します（Windows環境に関する記述は本記事の内容が最新です）。

まず結論：WindowsでCodexを動かす4つの経路と選び方

WindowsでCodexを動かす経路は4つあります。迷ったらネイティブのCLIインストーラから始めるのが、つまずきが最も少ない選び方です。

公式ドキュメントは、経路選択の原則をこう書いています。

Use the native Windows sandbox by default. Choose WSL when you need Linux-native tooling, your workflow already lives in WSL2, or neither native Windows sandbox mode meets your needs. （既定ではネイティブWindowsサンドボックスを使ってください。WSLを選ぶのは、Linuxネイティブのツールが必要なとき、開発の流れがすでにWSL2にあるとき、あるいはネイティブサンドボックスのどちらのモードも要件を満たさないときです）

— OpenAI Developers「Windows sandbox」

4つの経路の比較

①〜③はいずれもネイティブWindowsサンドボックスで動き、④だけがLinuxのサンドボックスで動きます。

判断フロー

上から順に当てはめてください。

1. すでにWSL2上にリポジトリと開発環境がある → ④ WSL2。無理にネイティブへ移す必要はありません
2. Linuxでしか動かないツールチェーンを使う（Linuxネイティブのビルド、特定のコンテナ運用など） → ④ WSL2
3. .NETやWindows向けGUIなど、Windowsネイティブの開発をしている → ① 公式インストーラ、またはGUIが欲しければ ② アプリ
4. 複数の作業を並行させたい／差分レビューをGUIでやりたい → ② デスクトップアプリ
5. 上のどれでもない（まず触ってみたい） → ① 公式インストーラ
6. ①〜③を試したがサンドボックスがどうしても設定できない → ④ WSL2を検討（※管理端末が原因のことが多いので、先に「会社の管理端末で設定が完了しないときの対処」を確認してください）

なぜ「WindowsならWSL2」という情報が多いのか

検索すると「業務利用ならWSL2」と書かれた記事が多く見つかります。これらが間違っていたわけではなく、前提が変わりました。

エージェントに任意のコマンドを実行させるツールでは、暴走や事故を防ぐためにコマンドを隔離する仕組みが要ります。以下は筆者の整理ですが、以前のWindowsにはこの仕組みが十分になく、Linux側の成熟したサンドボックス機構を借りるためにWSL2を使う、というのが合理的な回避策でした。「WindowsネイティブのPowerShellではサンドボックスが期待どおりに動かない」という説明は、この時期の実情を反映したものと考えられます。

現在は、Windows上でOSレベルの隔離を行うネイティブサンドボックスが用意され、この回避策が不要になりました。つまりWSL2は「サンドボックスを得るための迂回路」から「Linux環境が必要な人のための選択肢」に役割が変わったわけです。

情報の新旧を見分ける目安は、記事がelevated／unelevatedというネイティブサンドボックスの2モードに触れているかどうかです。触れていなければ、この転換より前の情報である可能性が高くなります。

なお、ここで扱うのはローカル環境の話です。ブラウザ上で動くCodex cloudとの役割分担についてはCodex CloudとCLIの使い分けを整理した記事を参照してください。

導入前に確認するWindowsの前提（対応バージョンと必要なツール）

インストールに進む前に、環境が要件を満たしているかを確認します。ここでの不一致は、後段のわかりにくいエラーとして表面化します。

対応するWindowsバージョン

公式ドキュメントは、Windowsのバージョンごとにサポートレベルを明示しています。

出典: OpenAI Developers「Windows sandbox」

Windows 10で「表示が崩れる」「ターミナルの挙動がおかしい」といった症状が出る場合、まず疑うべきはバージョンです。ConPTYはWindows 10 バージョン1809で導入されたコンソール基盤で、公式ドキュメントはこれより古いビルドについて「必要なコンソール構成要素を欠いている可能性が高い」としています。

環境に関するその他の前提

公式は、OSバージョン以外にも次の前提を挙げています。

• winget（Windowsパッケージマネージャー）が使えること。 見つからない場合は、Windowsを更新するか、Windowsパッケージマネージャーを先に導入します
• 推奨されるネイティブサンドボックスは、管理者が承認する設定に依存します
• 企業が管理する端末では、OSバージョンが条件を満たしていても必要な設定手順がブロックされることがあります

3つ目は日本の法人開発現場では特に重要です。詳しくは後半で扱います。

揃えておきたい開発ツール

公式は、いくつかの一般的な開発ツールが入っているとCodexがうまく動くとしています。

wingetでまとめて導入できます。

winget install --id Git.Git
winget install --id OpenJS.NodeJS.LTS
winget install --id Python.Python.3.14
winget install --id Microsoft.DotNet.SDK.10
winget install --id GitHub.cli

GitHub CLIを入れたあとは gh auth login を実行しておくと、GitHub連携機能が有効になります。Pythonや.NETのバージョンを変えたい場合は、パッケージIDを目的のバージョンに置き換えてください。

WindowsでのCodexインストール手順（経路別）

ここからは経路ごとの導入手順です。すべて公式ドキュメント記載のコマンドです。

① 公式インストーラでCodex CLIを入れる（推奨）

Windows向けにはスタンドアロンのインストーラが用意されています。PowerShellで次を実行します。

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

更新も同じコマンドです。

コマンド中の -ExecutionPolicy ByPass は、この実行に限って実行ポリシーを回避するための指定です。PowerShellの実行ポリシーが既定のままでもコピー＆ペーストで動くよう配慮されています。

導入後は、プロジェクトのディレクトリを開いて codex を実行し、初回は Sign in with ChatGPT などのサインイン方法を選びます。料金プランごとの使用枠についてはCodexの料金プランを比較した記事を参照してください。

この経路を推す理由は、つまずきの総量が少ないからです。 Node.jsもnpmも介さないため、後述する「PATHが通らずcodexが見つからない」系の問題が構造的に起きにくくなります。

② デスクトップアプリを入れる

GUIで使いたい場合はデスクトップアプリを導入します。公式ドキュメント上の名称は「ChatGPT desktop app for Windows」です。

コマンドラインから入れる場合は次のとおりです。

winget install --id 9PLM9XGG6VKS -s msstore

アプリはStore署名済みですが、インストールや更新のためにユーザーがMicrosoft Storeを開く必要はありません。

ここで重要な注意があります。 公式ドキュメントは、ネイティブとWSLのどちらのモードでも、サンドボックスの保護を適用するにはCodexにメッセージを送る前に入力欄の下にある「Ask for approval」を選ぶ必要があるとしています。この選択をしないまま使うと、後述する隔離の仕組みが効いていない状態で動くことになります。導入したら最初に確認してください。

あわせてデスクトップアプリの初期設定（エディタ・統合ターミナル・セットアップスクリプト）も確認してください。

③ npmで入れる

すでにNode.js環境がある場合はnpmでも導入できます。

npm install -g @openai/codex

ただし、この経路は「codexが見つからない」というつまずきが起きやすいため、特に理由がなければ①をおすすめします。原因と対処は後述の専用節にまとめました。

④ WSL2で入れる

WSL2を使う場合は、まず管理者権限のPowerShellまたはWindows TerminalでWSLを導入します。

wsl --install
wsl

続いて、WSLのシェルの中でCodexを導入します。Windows側ではなくWSL側で実行する点が重要です。

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex

WSL内ではLinux向けのインストーラを使います。Windows用の install.ps1 ではありません。

デスクトップアプリの初期設定（エディタ・統合ターミナル・セットアップスクリプト）

経路②を選んだ場合、アプリは入れたままの状態だとWindowsの開発フローと噛み合わないことがあります。設定すべきは3点です。

1. 既定のエディタ — Open で開くアプリを、Visual Studio、VS Code、その他のエディタから選びます。プロジェクトごとに上書きもでき、あるプロジェクトで一度 Open メニューから別のアプリを選んでいる場合はその選択が優先されます。

2. 統合ターミナル — 導入済みのものに応じて、PowerShell / コマンドプロンプト / Git Bash / WSL から選べます。この選択は、後述するエージェントの動作環境とは独立です。 変更は新しいターミナルセッションにのみ適用されるため、すでに開いている場合はアプリを再起動するか新しいチャットを開始してください。

統合ターミナルは各チャットに紐づき、そのプロジェクトまたはworktree（作業用に切り出した独立したチェックアウト）にスコープされます。右上のターミナルアイコン、または Ctrl + バッククォートで開き、Ctrl + L でクリアします。

3. セットアップスクリプト — worktreeはローカルのチャットとは別のディレクトリで動くため、依存関係やリポジトリに含まれていないファイルが欠けた状態から始まります。これを補うため、worktree作成時に自動実行されるスクリプトを定義できます。

npm install
npm run build

Windowsで重要なのは、セットアップがプラットフォーム固有になる場合にmacOS・Windows・Linuxそれぞれのスクリプトを定義して既定を上書きできる点です。 npm スクリプトのようにクロスプラットフォームで動くコマンドなら共通のもの1つで足り、Windows固有の挙動が必要なときだけWindows向けを用意します。この設定はプロジェクトルートの .codex フォルダに保存されるため、Gitリポジトリにコミットしてチームで共有できます。

導入直後に確認しておくこと

Windowsでは「入ったつもりだが、想定と違う環境で動いている」という状態が起こりやすいため、次の3点は最初に確認しておくと後の切り分けが楽になります。

1. コマンドが通るか — 新しいPowerShellウィンドウを開いて codex --version を実行します。インストール前から開いていたウィンドウではPATHの変更が反映されていないため、必ず開き直してください
2. どのサンドボックスが効いているか — /permissions コマンドで、有効なサンドボックスモードと書き込み可能なルートを確認できます
3. WSLを使う場合、Linux側で動いているか — WSLのシェルで echo $WSL_DISTRO_NAME がディストリビューション名を返し、パスが /home/... になっていることを確認します

ネイティブWindowsサンドボックスの2モード（elevated / unelevated）

ネイティブWindowsサンドボックスとは、Codexのエージェントが実行するコマンドを、OSの機能でWindows上に隔離する仕組みです。 WSLや仮想マシンを使わずに、作業フォルダの外への書き込みと、明示的な承認のないネットワークアクセスを遮断します。

これがWindowsでWSL2が必須でなくなった技術的な理由です。先述のとおり筆者の整理ですが、以前は「Linuxのサンドボックス機構がないとエージェントを安全に走らせられない」という制約があり、Windows側にその仕組みが用意されたことで前提が変わったと考えられます。

ネイティブサンドボックスには2つのモードがあり、config.toml で選択します。

[windows]
sandbox = "elevated" # or "unelevated"

公式は「両方のモードが使えるならelevatedを使い、既定のネイティブサンドボックスが環境で動かない場合は、原因を調べる間unelevatedをフォールバックとして使う」としています。

なお、いま自分がどちらで動いているかは config.toml の [windows] sandbox で決まります。/permissions が表示するサンドボックスモードとは別軸の設定なので混同しないでください。elevated の設定に失敗した場合は、Codex側から unelevated に切り替わった旨が通知されます。

この対比が、管理端末で詰まる理由の核心です。 elevatedは新しいユーザーを作るため管理者権限が要り、unelevatedは既存ユーザーの権限を削るだけなので作らずに済みます。だから会社が管理する端末では、ローカルユーザーの作成やファイアウォールルールの変更がポリシーで禁止されていることが多く、elevatedの設定が完走しません。そのとき作業を止めないための現実解がunelevatedです。ただし公式も明言しているとおり、これは長期的に望ましい企業向け構成ではありません。

なお、両モードとも既定ではUI分離を強めるためにプライベートデスクトップを使います。互換性の都合で従来の Winsta0\Default の挙動が必要な場合に限り、windows.sandbox_private_desktop = false を設定します。

サンドボックスに読み取りを許可する

サンドボックスがディレクトリを読めずにコマンドが失敗する場合は、読み取りを許可します。

/sandbox-add-read-dir C:\absolute\directory\path

指定するのは実在する絶対パスです。成功すると、そのセッションの間、サンドボックス内で実行される以降のコマンドがそのディレクトリを読めるようになります。

なお、サンドボックスの境界を外すフルアクセスモードでは、Codexがプロジェクトディレクトリの外にも及び、意図しない破壊的な操作でデータを失う可能性があると公式が警告しています。この危険性と承認ポリシーの設計はOSを問わない論点のため、詳細はCodex CLIの使い方をまとめたガイドに譲ります（Windows環境の記述は本記事が最新です）。

WSL2を選んだ場合の環境づくりと注意点

WSL2は「劣った選択肢」ではありません。判断フローの1・2に当てはまるなら、これが正解です。導入コマンドは④ WSL2で入れるにまとめてあるので、ここではWSL2を選んだあとに効いてくる前提と運用を扱います。

WSL1は使えません

重要な前提です。WSL1はCodex 0.114 までのサポートで、0.115 からLinuxのサンドボックスが bubblewrap に移行したため、WSL1は非対応になりました。 執筆時点のCodex CLIの最新版は 0.151.0（npm レジストリで2026年8月29日に確認）であり、現行版を使う限りWSL1という選択肢はありません。

古い環境から移行する場合は、WSL2になっているかを先に確認してください。

WSL2の更新とリセット

大きなリポジトリでWSLの動作が重いときは、更新と再起動で改善することがあります。

wsl --update
wsl --shutdown

必要に応じてWSLに割り当てるメモリとCPUを増やすことも公式が挙げている対処です。

VS CodeをWSLの中から起動する

WSLで開発する場合、VS CodeはWSL側から起動します。

cd ~/code/your-project
code .

これでWSLリモートのウィンドウが開き、必要ならVS Code Serverが導入され、統合ターミナルがLinux側で動くようになります。

接続できているかは次の3点で確認します。

• ステータスバーに WSL: <ディストリビューション名> が表示されている
• 統合ターミナルのパスが C:\ ではなく /home/... になっている
• echo $WSL_DISTRO_NAME でディストリビューション名が表示される

表示されない場合は Ctrl+Shift+P から WSL: Reopen Folder in WSL を選びます。

エクスプローラーからWSL側のファイルを見る

Windows側からWSLのファイルにアクセスする必要がある場合は、エクスプローラーやファイル選択ダイアログに \\wsl$ と入力すると、ディストリビューションのホームディレクトリ（\\wsl$\Ubuntu\home\<user>）にたどり着けます。

WindowsとWSLを混在させたときの事故：プロジェクト配置の原則

ここが本記事で最も取り違えやすく、最も影響が大きい論点です。

「リポジトリは/mnt/cに置くな、Linuxのホームに置け」という助言をよく見かけます。これは正しいのですが、成立するのはWSL側でエージェントを動かしている場合だけです。 ネイティブエージェントを使うなら結論は逆になります。

エージェントの動作環境で結論が逆転する

出典: OpenAI Developers「WSL」 および「ChatGPT desktop app for Windows」

デスクトップアプリは既定でWindowsネイティブのエージェントを使います。つまりアプリを入れたままの状態で「リポジトリはLinuxホームに置くのが定石」という助言に従うと、推奨と逆の構成になります。 \\wsl$ 経由で開いたプロジェクトでGitが検出されない、という症状はこの構成で起きます。

エージェント自体をWSL2で動かしたい場合は、設定でエージェントをWindowsネイティブからWSLに切り替え、アプリを再起動します。再起動するまで変更は反映されません。

エージェントと統合ターミナルは別設定

もう一つの混乱の元がこれです。エージェントの動作環境と、統合ターミナルの種類は独立して設定します。 エージェントはWSLで動かしつつ、ターミナルはPowerShellを使う、という組み合わせも成立します。

「.shスクリプトを実行しようとしたら意図せずWSLのbashが呼ばれた」といった混乱は、この2つを同一視していると原因にたどり着けません。

同じ「スクリプト」でも動く環境が異なる点にも注意してください。アクションとは、開発サーバーの起動やテスト実行のような定型作業をアプリ上部のショートカットとして登録したものです。

出典: OpenAI Developers「ChatGPT desktop app for Windows」

統合ターミナルをGit Bash、エージェントをWindowsネイティブにしている場合、アクションはGit Bashで、セットアップスクリプトはPowerShellで動きます。「同じコマンドなのに片方だけ失敗する」という現象は、たいていここが原因です。

設定・認証・履歴は自動では共有されない

WindowsアプリとWSL内のCLIを併用する場合、設定と認証情報は共有されません。 Windowsアプリが使うCodexホームは %USERPROFILE%\.codex ですが、WSL内のCLIは既定でLinux側のホームディレクトリを使うためです。

共有したい場合の方法は2つあります。

1. WSLの ~/.codex と %USERPROFILE%\.codex をファイルシステム上で同期する
2. WSL側で CODEX_HOME にWindows側のCodexホームを指定する

export CODEX_HOME=/mnt/c/Users/<windows-user>/.codex

すべてのシェルで有効にするには ~/.bashrc や ~/.zshrc に追記します。

「動かない」逆引き：症状から原因と対処を引く

この表は、公式ドキュメントに記載がある事象だけで構成しています。 再現条件が曖昧な「噂レベル」の情報は除き、各行の根拠を原典列に示しました（windows = Windows sandbox / windows-app = ChatGPT desktop app for Windows / wsl = WSL）。

公式には記載がないが頻出するもの：codex が見つからない

上の表とは区別して扱います。npmで導入したときに codex コマンドが見つからない問題は、公式ドキュメントに記載がありません（原典で確認できるPATH関連の記述は、WSL内でVS Codeがバイナリを見つけられないケースのみです）。ただし日本語圏の解説記事では頻繁に報告されています。

原因はPATHの未反映です。npmのグローバルインストール先がWindowsのPATHに反映されていないか、インストール前から開いていたターミナルに変更が反映されていないかのいずれかであることが多く、対処は次の順です。

1. 新しいPowerShellウィンドウを開き直して codex --version を試す
2. それでも解決しないなら、① 公式インストーラで導入し直す

この問題を根本的に避けたいなら、そもそもnpm経路を使わないのが確実です。

実行ポリシーの解除

Node.jsやnpmをPowerShellで初めて使う場合、実行ポリシーのエラーに当たることがあります。Codexがスクリプトを生成した場合にも起こりえます。よくある対処は次のとおりです。

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

実行ポリシーはセキュリティに関わる設定です。変更前にMicrosoftの実行ポリシーのガイドで内容を確認してください。

C++ビルドツールの導入

IDE拡張をインストールしたのに反応しない場合、公式はC++の開発ツールの不足を原因として挙げています。必要なのは Visual Studio Build Tools（C++ワークロード）と Microsoft Visual C++ 再頒布可能パッケージ（x64）で、winget なら次のコマンドです。

winget install --id Microsoft.VisualStudio.2022.BuildTools -e

導入後はVS Codeを完全に再起動してください。

管理者権限でコマンドを実行したい場合

Codexに管理者権限が必要なコマンドを実行させたい場合は、デスクトップアプリ自体を管理者として起動します。スタートメニューからアプリを探し、「管理者として実行」を選ぶと、Codexのエージェントがその権限レベルを引き継ぎます。

切り分けが進まないときに集める情報

問題が解決しない場合、公式は CODEX_HOME/.sandbox/sandbox.log の送付を求めています。あわせて、何をしようとしていたか、elevatedが失敗したのかunelevatedを使ったのか、表示されたエラーメッセージ、1385などのエラーコードの有無、Windows 11か10かを添えると切り分けが早くなります。

なお、CODEX_HOME/.sandbox-secrets/ の中身は送ってはいけません。 公式が明示的に禁じています。

Windows環境のつまずきは、AIコーディングツール全般で共通する部分もあります。Claude CodeのWindows環境構築でも同種の落とし穴を扱っているので、あわせて参照すると切り分けが早くなります。

会社の管理端末（グループポリシー・Intune）で設定が完了しないときの対処

日本の法人開発現場でCodexの導入が止まる最大の理由は、Codexの問題ではなく端末管理ポリシーです。 公式も「企業が管理する端末では、OSバージョンが条件を満たしていても必要な設定手順がブロックされることがある」と明記しています。

推奨されるelevatedサンドボックスは、ローカルユーザーとグループの作成、ファイアウォールの構成、サンドボックスユーザーへのログオン権限付与といった、管理者が承認する設定に依存します。 一般ユーザー権限で運用される管理端末では、ここで止まります。

elevatedの設定が完了しない5つの原因

公式が挙げている原因は次のとおりです。

1. WindowsのUAC（管理者プロンプト）が拒否された
2. 端末がローカルユーザーまたはグループの作成を許可していない
3. 端末がファイアウォールルールの変更を許可していない
4. 端末がサンドボックスユーザーに必要なログオン権限をブロックしている
5. その他の企業ポリシーが設定フローの一部をブロックしている

公式が示す対処の順序は、①elevatedの設定を再試行して管理者プロンプトを承認する（環境が許す場合）、②会社の端末でブロックされるならIT部門に可否を確認する、③それでも駄目ならunelevatedで作業を継続しながら調査する、というものです。

情シス・IT部門への確認テンプレート

②のステップで使えるよう、確認事項をそのまま送れる形にまとめました。コピーして社内の問い合わせに貼り付けてください。

【件名】開発端末でのAIコーディングツール（OpenAI Codex）の実行環境について確認のお願い

お世話になっております。開発業務で利用するOpenAI Codexについて、
管理端末上でセキュリティ機能（サンドボックス）の初期設定が完了しないため、
下記についてポリシー上の可否をご確認いただけますでしょうか。

■ 対象端末
・端末名／資産番号: [                    ]
・OS: [Windows 11 24H2 など]

■ 背景
Codexはエージェントが実行するコマンドをOSレベルで隔離する仕組みを持ち、
作業フォルダ外への書き込みと、承認のないネットワークアクセスを遮断します。
推奨構成（elevated）はこの隔離のために管理者承認を伴う初期設定を必要とします。
設定が通らない場合、より分離の弱い代替構成（unelevated）での運用となります。

■ ご確認いただきたい点
1. 当該端末で、ローカルユーザーおよびローカルグループの作成は許可されていますか
2. 当該端末で、ファイアウォールルールの追加は許可されていますか
3. 上記で作成されるサンドボックス用ユーザーに対し、
   コマンド起動に必要なログオン権限は付与可能ですか
   （権限が不足する場合、Windowsエラー1385で失敗します）
4. 初期設定時のUAC（管理者昇格）の承認は可能ですか
5. 上記のほか、社内ポリシー上の制約があればご教示ください

■ 補足
・全社展開を想定する場合、管理者側で使用可能な構成を
  requirements.toml により elevated のみに制限することも可能です
・アプリ本体はMicrosoft Store署名済みで、Intune等のMDMからの配布に対応しています
  （Microsoft Store 製品ID: 9PLM9XGG6VKS）

以上、ご確認のほどよろしくお願いいたします。

[所属] [氏名]

管理者側で構成を強制する

情シス側でCodexの構成を統制したい場合、requirements.toml で使用可能なネイティブサンドボックスの実装を制限できます。

[windows]
allowed_sandbox_implementations = ["elevated"]

この例はelevatedを必須とし、ユーザーがunelevatedにフォールバックすることを禁止します。両方を許可したい場合は両方の値を含めます。モードが選択されていない場合、Codexはelevatedを優先します。

出典: OpenAI Developers「Windows sandbox」 / 「Managed configuration」

全社配布（Intune / MECM / MSIX）

デスクトップアプリの配布方法は、端末管理の状況に応じて選べます。

初回インストール後、persistent.oaistatic.com に到達できる端末は自動的に更新を取得できます（管理構成でアプリ内更新を無効化していない場合）。アプリ内更新を無効にする場合は、新しいパッケージをMDMから配布します。

なお、このMSIX経由の配布経路はスタンドアロンのMSIや非Store形式のEXEを提供するものではない点に注意してください。

出典: OpenAI Developers「Deploy the Windows app」

ネットワーク要件を管理者側で定義する場合の注意

サンドボックス内で動くローカルコマンドの通信先を、管理者が中央で定義することもできます。requirements.toml の [experimental_network] を使い、許可ドメインと拒否ドメインを指定する形です。

experimental_network.enabled = true
experimental_network.allowed_domains = [
  "api.openai.com",
  "*.example.com",
]
experimental_network.denied_domains = [
  "blocked.example.com",
]

まず前提として、[experimental_network] は公式が「実験的機能であり変更されうる」と位置づけているものです。 そのうえで、誤解しやすい点が3つあります。

1. 許可リストを書くだけではプロキシは有効になりません。 experimental_network.enabled = true を設定して初めて管理対象のプロキシが有効化されます
2. アクティブなサンドボックスがネットワークを無効にしている場合、この要件はコマンドにネットワークアクセスを与えません。 許可リストは「通信を許す設定」ではなく「通信先を絞る設定」です
3. この要件が効く範囲はサンドボックス内のローカルコマンドだけです。 Web検索、アプリやコネクタ、MCPサーバー、ブラウザやComputer Useの操作、Codexのサービス通信、Codex cloudの通信は対象外で、それぞれ別の制御を使います

そして、Windowsで全社展開を検討している場合に最も重要な注意点があります。公式ドキュメントは、この機能についてWindowsのサポートはまだ限定的であり、自社環境で検証していないならWindowsユーザーにこのポリシーを適用しないよう警告しています。 ネットワーク要件を先に決めてから配布計画を立てると手戻りになりかねないため、検証端末での確認を挟んでください。

出典: OpenAI Developers「Managed configuration」

FAQ

まとめ

WindowsでCodexを動かすときの判断は、次の3点に集約されます。

1. 経路は「まずネイティブ」。 公式は既定でネイティブWindowsサンドボックスを推奨しており、WSL2は条件に当てはまる場合の選択肢です。導入は公式のPowerShellインストーラが最もつまずきが少なくなります
2. 配置の原則は、エージェントの動作環境で決める。 ネイティブならWindowsドライブ側、WSLならLinuxホーム。ここを取り違えるとGit検出や速度の問題として後から表面化します
3. 管理端末では、詰まる場所が技術ではなくポリシーになる。 elevatedの設定は管理者承認を要するため、情シスへの確認を早い段階で始めるのが結果的に近道です

そして、うまく動かないときに最初にやるべきことは、バージョンの確認です。Windows周りの挙動はCodexの更新で変わっており、WSL1のサポート終了のようにバージョン境界がはっきりしている変更もあります。ネット上の情報を試す前に、自分が使っているバージョンと、その情報がいつ時点のものかを突き合わせてください。それだけで解決する問題は少なくありません。

Windows環境へのAIコーディングツールの導入は、ツールの選定よりも「既存の端末管理と開発フローにどう馴染ませるか」が本番です。衣株式会社では、受託開発と内製化支援の両面から、こうした環境整備を含めた導入をご支援しています。