CodexをWindowsで使う方法｜WSL設定と注意点

Q: WSL2とネイティブWindows、どちらのほうが速いですか?

一般的なコーディング作業であれば大きな差はありませんが、プロジェクトを/mnt/c配下(Windows側のドライブ)に置いたままWSL2から操作すると、ファイルI/Oが遅くなります。WSL2を使う場合は、プロジェクトをWSLのファイルシステム側に置くことで、ネイティブLinuxに近い速度が出ます。

公開: 2026年8月3日 / 更新: 2026年8月11日・読了目安8分

#Windows #WSL

先に結論: Codexは2026年8月時点でWindows 11・Windows 10にネイティブ対応しており、通常利用ならPowerShellからそのまま導入できます。Linux前提のツールを使う場合はWSL2(WSL1は非対応)が選択肢になります。

CodexはWindows上でもネイティブに動作しますが、Linux前提のツールチェーンを使う場合や、サンドボックスの制約に当たる場合はWSL2(Windows Subsystem for Linux 2)上での利用が案内されています。

この記事では、2026年8月時点の公式情報をもとに、WindowsでのCodexの対応状況、WSL2のセットアップからCodexのインストール・サインインまでの手順、Windows側ファイルへのアクセスやVS Code連携、つまずきやすいポイントを解説します。

この記事の要点

Codexは2026年8月時点でWindows 11(推奨)・Windows 10バージョン1809以降(ベストエフォート対応)でネイティブに動作します。

ネイティブWindowsには「Elevated Sandbox」と「Unelevated Sandbox(フォールバック)」の2種類のサンドボックスが用意されています。

サンドボックスの実装がbubblewrapベースのLinux版に切り替わって以降、WSL1は非対応でWSL上ではWSL2が必須です。

WSL2利用時はプロジェクトをWindows側(/mnt/c配下)ではなく、WSLのホームディレクトリに置くのが基本です。

WSL2上ではNode.js 22以降を導入したうえで、npm install -g @openai/codexでCodex CLIをインストールします。

前提・動作環境

対応OS: Windows 11(推奨)、Windows 10 バージョン1809以降(ベストエフォート対応)
Codex CLI: @openai/codex(npm経由でインストール)
アカウント: ChatGPT Plus以上のプラン、またはOpenAIのAPIキー
WSL2を使う場合: WSL2上のLinux(Ubuntuなど)にNode.js 22以降を別途インストールする必要があります
ネイティブWindowsの場合: wingetパッケージマネージャーが利用できる状態であることが前提になります

Codex自体の概要をまだ把握していない方は「Codexの使い方完全ガイド」を先に読んでおくと、この記事の位置づけがつかみやすくなります。

Windowsでの対応状況(結論)

Codexは、ChatGPTデスクトップアプリ・CLI・IDE拡張のいずれもWindows上でのネイティブ動作が公式にサポートされています。

ネイティブWindowsには、管理者権限のもとで専用の低権限ユーザーとファイアウォールルールを使う「Elevated Sandbox」と、現在のユーザーの制限付きトークンとACLでファイルシステムを保護する「Unelevated Sandbox(フォールバック)」の2種類のサンドボックスが用意されています。

通常の利用であればネイティブWindows環境で問題なく動作します。

Windowsで使う2つの方法の比較図。ネイティブWindowsは通常利用ならこれで十分でElevated・Unelevated Sandboxの2種を持つ。WSL2はLinux前提のツールを使う場合の選択肢で、WSL1は非対応でWSL2が必須、プロジェクトはWSL側のホームディレクトリに置く

一方でWSL2は、Linux前提のビルドツールやスクリプトに依存するプロジェクトを扱う場合や、Windowsネイティブの2つのサンドボックスモードのどちらも要件に合わない場合の選択肢として案内されています。

なお、以前はWSL1でも動作していましたが、サンドボックスの実装がbubblewrapベースのLinux版に切り替わったバージョン以降、WSL1は非対応になっています。WSL上で使う場合は必ずWSL2を使ってください。

WSL2のセットアップ

WSL2をまだ導入していない場合は、PowerShellを管理者権限で開き、次のコマンドを実行するだけでインストールできます。

wsl --install

インストール中: 仮想マシン プラットフォーム
仮想マシン プラットフォーム がインストールされました。
インストール中: Ubuntu
Ubuntu がインストールされました。

コマンド実行後にPCを再起動すると、自動的にUbuntuが起動し、初回のみLinux側のユーザー名とパスワードの設定を求められます。設定が終わればWSL2上のUbuntuにログインした状態になります。

WSL2セットアップ3ステップ: wsl --installを実行、PCを再起動、初期設定(ユーザー名・パスワード)という流れを示す図解

既にWSL1でLinuxディストリビューションを使っている場合は、次のコマンドでバージョンを確認・変更できます。

wsl -l -v
wsl --set-version Ubuntu 2

WSL内でのNode.js・Codexインストールとサインイン

WSL2上のUbuntuで作業する場合も、CodexのインストールはMac・Linuxと同じ手順です。まずパッケージを最新化し、Node.js 22以降を導入します。

sudo apt update && sudo apt upgrade -y
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

Node.jsが入ったら、npm経由でCodex CLIをインストールします。

npm install -g @openai/codex

インストール後は作業ディレクトリでcodexを実行し、初回起動時に表示されるサインイン画面で「Sign in with ChatGPT」またはAPIキーを選びます。

WSL2にはデフォルトでGUIブラウザが入っていないため、認証用URLが自動で開かない場合は、表示されたURLをコピーしてWindows側のブラウザに貼り付けてアクセスしてください。

インストールの詳しい流れは「Codex CLIのインストール手順」でも解説しています。

Windows側ファイルへのアクセスとVS Code連携

WSL2からは/mnt/c/Users/...のようなパスでWindows側のドライブにアクセスできます。

ただし、この経路は9Pプロトコル越しのファイルアクセスになるため、/mnt/c配下の大量ファイルに対するgit操作やビルドは著しく遅くなることがあります。

作業するプロジェクトはWindows側ではなくWSLのホームディレクトリ(~/projectsなど)に置くのが基本です。

プロジェクトの置き場所による比較図。Windows側の/mnt/c配下は9Pプロトコル経由で大量ファイルのgit操作やビルドが低速になりやすく、WSLホームディレクトリに置けばネイティブLinuxに近い速度が出ることを示す図

エディタはVS CodeのRemote - WSL拡張機能を使うと、WSL2上のUbuntuでcode .を実行するだけでWindows側のVS CodeがWSL環境に接続し、ファイルもターミナルもLinux側のものをそのまま扱えます。

Codex用のIDE拡張もWSL側で動作するため、CLIとエディタを同じ環境でシームレスに使えます。

ネイティブ(PowerShell)で動かす場合の制限

WSL2を経由せず、PowerShellから直接Codexを使う方法もシンプルでよく使われています。Node.js 22以降をインストールしたうえで、PowerShellからnpm install -g @openai/codexを実行するだけで導入できます。

ネイティブWindowsでは、より強固なElevated Sandboxを使うために管理者による初回セットアップが必要で、社内ポリシーによってユーザー・グループの作成やファイアウォール設定の変更がブロックされる企業PCでは、権限の弱いUnelevated Sandboxにフォールバックする形になります。

また、UACの確認画面を拒否してしまう、ConPTYなどコンソール関連のコンポーネントが不足しているといった環境要因でエラーになるケースも報告されています。こうした制約に頻繁に当たる場合は、前述のWSL2への切り替えを検討してください。

つまずきポイント/よくあるエラー

サンドボックス関連のヘルパープロセスが起動できない: ネイティブWindowsのElevated Sandbox設定が完了していない、または企業ポリシーで権限が制限されていることが原因です。Unelevated Sandboxへの切り替えや、WSL2上での実行を試してください。
パスの指定でエラーになる: Windows形式のパス(C:\Users\...)とWSL形式のパス(/mnt/c/Users/...)を混同すると、ファイルが見つからないエラーになります。WSL2上で作業している場合は常にLinux形式のパスを使いましょう。
サインイン用のブラウザが自動で開かない: WSL2環境やリモート接続環境では、認証URLが自動で開かないことがあります。表示されたURLを手動でコピーし、ブラウザに貼り付けてアクセスすれば認証を完了できます。
WSL1のまま使おうとしてエラーになる: 現在のCodexはWSL1に対応していません。wsl -l -vでバージョンを確認し、WSL1のままであればwsl --set-versionでWSL2に変更してください。

より広い症状別の対処法は「Codexが動かない時の対処法」にまとめています。

よくある質問

WindowsでCodexを使うのにWSLは必須ですか?

必須ではありません。CodexはWindowsにネイティブ対応しており、通常の利用であればPowerShellから直接インストールして問題なく使えます。Linux前提のツールチェーンを使う場合や、ネイティブのサンドボックスが要件に合わない場合にWSL2が選択肢になります。

WSL1でもCodexは動きますか?

動きません。サンドボックスの実装がLinux版のbubblewrapベースに切り替わって以降、WSL1は非対応になっています。WSL上で使う場合は必ずWSL2にしてください。

WSL2とネイティブWindows、どちらのほうが速いですか?

一般的なコーディング作業であれば大きな差はありませんが、プロジェクトを/mnt/c配下(Windows側のドライブ)に置いたままWSL2から操作すると、ファイルI/Oが遅くなります。WSL2を使う場合は、プロジェクトをWSLのファイルシステム側に置くことで、ネイティブLinuxに近い速度が出ます。

まとめ

Codexは2026年8月時点でWindowsにネイティブ対応しており、通常の利用であればPowerShellからそのまま導入して問題ありません。

Linux前提のツールを使う場合やサンドボックスの制約に当たる場合はWSL2が選択肢になりますが、WSL1は非対応な点と、プロジェクトを/mnt/c配下ではなくWSL側に置くべき点には注意してください。

インストールの基本手順は「Codex CLIのインストール手順」、Codex全体の使い方は「Codexの使い方完全ガイド」、それでも問題が解決しない場合は「Codexが動かない時の対処法」もあわせてご確認ください。