CodexをWindowsで使う方法｜PowerShellとサンドボックス設定の手順

本記事を読めば、Windows版CodexアプリとPowerShell/WSL2の使い分けがわかり、Windows開発環境でも安全にCodexを使えるようになります。

CodexはWindowsネイティブのPowerShell環境でも、WSL2のLinux系環境でも利用できます。ただし、Git認識、パス、サンドボックス、実行ポリシーを混同すると導入時に止まりやすくなります。

AIzen株式会社は、AI開発支援と業務アプリ開発の現場で、Windows導入は「どの環境でエージェントを動かすか」を先に決めることが重要だと考えています。本記事では、公式情報をもとに実務手順を整理します。

CodexをWindowsで使う方法

WindowsでCodexを使う方法は、大きく分けてCodexアプリ、CLI、IDE拡張です。公式マニュアルでは、WindowsアプリはPowerShell上のWindows sandbox、またはWSL2上のLinux sandboxを利用できると説明されています。

CodexアプリとCLIの違い

Codexアプリは、複数プロジェクトやスレッドを扱い、作業結果や差分を画面で確認しやすい入口です。Windows版はMicrosoft Storeから導入でき、wingetによるインストールも案内されています。プロジェクト管理、並列作業、レビュー結果の確認をまとめて扱いたい場合に向いています。

Codex CLIは、ターミナルで既存リポジトリを開き、短い依頼で調査、修正、テストを進める入口です。エンジニアがPowerShellやWSL2のターミナルで作業している場合、CLIのほうが自然です。アプリは管理しやすさ、CLIは手元作業の速さで選ぶと判断しやすくなります。

PowerShellとIDE拡張の使い分け

PowerShellは、Windowsネイティブの環境でCodexにコマンドを実行させる場合に使います。.NET、Windowsアプリ、Windows上のNode.jsプロジェクトなどはPowerShell中心で整えやすいです。

IDE拡張は、VS Codeや対応エディタ内でコードを見ながらCodexに相談したい場合に向きます。開いているファイルや差分を見ながら局所修正を進められるため、既存コードの保守では便利です。Windowsでの導入では、IDE、PowerShell、WSL2のどれを主な作業場所にするかをチームで統一します。

WSL2を使うべき開発環境

WSL2は、Linux前提のツールチェーンを使うプロジェクトに向いています。Docker、Linux向けシェルスクリプト、Ubuntu上の依存関係、Linux CIに近い検証が必要な場合は、WSL2でCodexを動かすほうが環境差を減らせます。

一方で、Windowsネイティブのツールや社内端末管理を重視する場合はPowerShellが扱いやすいです。WSL2を使う場合も、プロジェクト配置場所、Git、認証情報、サンドボックスの違いを明確にします。

Windows版の導入手順

Windows版の導入は、アプリのインストール、CLI起動と認証、開発ツール確認の順に進めます。いきなり本番リポジトリで試すのではなく、まず検証用リポジトリでCodexがファイルを読めるか、コマンドを実行できるかを確認します。

Windowsアプリのインストール

公式マニュアルでは、Codex app for WindowsはMicrosoft Storeからダウンロードでき、コマンドラインでは winget install Codex -s msstore の導入方法も案内されています。企業では、Microsoft Storeアプリ配布をMDMや端末管理ツールで扱えるかを確認します。

インストール後は、Codexを開き、ChatGPTアカウントまたはAPIキーでサインインします。ChatGPTサインインではChatGPTワークスペースの権限や利用枠が関係し、APIキーではOpenAI Platform側の課金と管理が関係します。法人では、どちらを許可するかを情シスと開発責任者で決めます。

CLI起動とChatGPT認証

CLIを使う場合は、公式手順に従ってCodex CLIをインストールし、ターミナルで codex を起動します。公式のOpenAI Codexリポジトリでは、Windows向けのPowerShellインストーラー、npm、Homebrew、GitHub Releaseからの取得などが案内されています。

初回起動では、ChatGPTサインインが標準的な流れです。ブラウザで認証し、CLIに戻るとセッションが保存されます。ヘッドレス環境やリモート環境では、device code認証や認証キャッシュの扱いも検討します。認証ファイルやトークンは機密情報として扱い、チケットやチャットに貼り付けないようにします。

GitとNode.jsの確認

公式マニュアルでは、WindowsでCodexを使ううえでGit、Node.js、Python、.NET SDK、GitHub CLIなどが役立つ開発ツールとして挙げられています。これらはCodex本体のすべてに必須というより、対象プロジェクトを動かすために必要になるものです。

確認すべき項目は、GitがPATHに入っているか、対象リポジトリで git status が動くか、Node.jsやPythonのバージョンがプロジェクト要件に合うか、GitHub CLIを使う場合は gh auth login が済んでいるかです。Codexにテスト実行を任せたいなら、先に人間が同じコマンドを実行できる状態にします。

PowerShellとWSL2の使い分け

PowerShellとWSL2は優劣ではなく、対象プロジェクトとチーム運用で選びます。Windowsネイティブの作業をPowerShell、Linux系の開発をWSL2に分けると、パスや権限の混乱を減らせます。

比較軸	PowerShell中心	WSL2中心
向く開発	Windowsアプリ、.NET、社内端末上の作業	Linux系ツール、Docker、Linux CIに近い検証
ファイル配置	Windows側のプロジェクト	WSL内のホーム配下
注意点	実行ポリシー、PATH、管理者権限	WSL2設定、bubblewrap、Windows側とのパス差
チーム運用	端末管理と合わせやすい	Linux前提の開発手順を統一しやすい

PowerShellに向く作業

PowerShellに向くのは、Windowsファイルシステム上のプロジェクト、.NETやWindowsアプリ、社内端末上で完結するツール、Windows向けNode.jsプロジェクトです。CodexはPowerShell上でWindows sandboxを使えるため、Windowsネイティブの作業をそのまま扱いやすいです。

また、企業端末ではPowerShellの実行ポリシー、管理者権限、社内プロキシ、ウイルス対策ソフトの制約が関係します。npm.ps1 cannot be loaded のようなエラーが出る場合は、PowerShell実行ポリシーを確認します。変更が必要な場合でも、社内ポリシーに沿って対応します。

WSL2に向くLinux系開発

WSL2に向くのは、Linux前提の依存関係を使うプロジェクトです。Ubuntu上で動くNode.js、Python、Ruby、Go、Rust、Docker連携、Linux用シェルスクリプトなどは、WSL2で実行したほうがCIに近い条件を作りやすくなります。

公式マニュアルでは、CodexのLinux sandboxはWSL2で利用でき、WSL1は現行のLinux sandbox前提では対応しない扱いです。WSL2で使う場合は、bubblewrap などサンドボックスに必要な構成を確認します。WSL環境の設定がチームでばらつく場合は、セットアップ手順を文書化します。

プロジェクト配置場所の決め方

Windowsでの混乱は、プロジェクト配置場所から起きることが多いです。WindowsネイティブのCodexで作業するなら、プロジェクトはWindows側のファイルシステムに置くのが扱いやすいです。WSL2のLinux環境で作業するなら、WSL内のホーム配下に置くほうが自然です。

公式マニュアルでは、Windowsネイティブエージェントを使いながらWSLからアクセスする場合、Windows側にプロジェクトを置き、WSLでは /mnt/… 経由で扱う構成が信頼しやすいと説明されています。チームでは、PowerShell中心かWSL2中心かを決め、配置場所を合わせます。

Windows環境の確認ポイント

WindowsでCodexを安全に使うには、サンドボックス、パス、Git、権限、PowerShell実行ポリシーを確認します。導入時の問題は、Codexの使い方というより、Windows開発環境の前提差から起きることが多いです。

Windows sandboxの設定

公式マニュアルでは、WindowsネイティブのPowerShell実行ではWindows sandbox、WSL2ではLinux sandboxを使うと説明されています。サンドボックスは、Codexが自律的に動く範囲を制限する重要な設定です。

通常は、ワークスペース内で読み書きと通常コマンドを許可し、ネットワークや範囲外の変更は承認する設定から始めます。Full Access相当の広い権限は、信頼できる検証環境でのみ使います。社内PCでは、秘密情報や本番設定ファイルに触らせないルールを先に決めます。

パス・Git・権限の確認

CodexがGitを認識できない場合、Gitがインストールされていない、PATHに入っていない、リポジトリの場所がWindows/WSLでずれている、権限が足りないなどが原因になります。

確認手順は、PowerShellまたはWSLで git –version、git status、対象ディレクトリのパス、現在のユーザー権限を見ることです。CodexアプリでGit機能を使う場合は、Windowsネイティブ側にもGitが必要になるケースがあります。WSL側だけにGitがある状態では、Windowsアプリが期待通りに認識できないことがあります。

PowerShell実行ポリシーの確認

PowerShellでは、スクリプト実行ポリシーによってnpmやCodexが作成したスクリプトが止まることがあります。公式マニュアルでは、必要に応じて Set-ExecutionPolicy -ExecutionPolicy RemoteSigned を検討する例が示されています。

ただし、これは全社端末で自由に変更すべき設定ではありません。社内のセキュリティ基準、管理者権限、端末管理ポリシーを確認します。個人PCでは問題なくても、会社PCではスクリプト実行が制限されることがあります。

弊社エンジニアからのコメント：

WindowsでCodex導入が止まるケースは、Codexそのものより「PowerShellでnpmが動かない」「WSL側のリポジトリをWindowsアプリがうまく扱えない」「Gitが片方の環境にしか入っていない」といった環境差分が原因になりやすいです。最初にPowerShell中心かWSL2中心かを決め、Gitとプロジェクト配置場所を統一すると、導入後の問い合わせが減ります。

チーム導入時の運用ルール

Windows環境は、メンバーごとの差分が出やすい領域です。個人ごとにPowerShell、Git Bash、WSL2、IDE拡張を自由に使うと、Codexの実行結果やテスト結果が揃いにくくなります。

WSL利用ルールの統一

WSL2を使う場合は、対象ディストリビューション、プロジェクト配置場所、利用するNode.jsやPythonのバージョン、サンドボックス確認、Git認証を統一します。

「フロントエンドはWSL2のUbuntuで実行」「Windowsアプリ開発はPowerShellで実行」のように、プロジェクト単位で方針を決めます。Codexに依頼するときも、「このリポジトリはWSL2側で作業する」と明記すると、コマンドやパスの誤解を減らせます。

環境差分の記録方法

環境差分は、README、AGENTS.md、社内Wikiに残します。記録する項目は、OS、Codexの利用入口、ターミナル、Git、Node.js、Python、テストコマンド、インストール手順、実行ポリシーです。

Codexに作業させる場合は、実行してよいコマンド、触ってよいディレクトリ、触ってはいけないファイルも書きます。これにより、AIへの依頼文を毎回細かく書かなくても、チーム共通の前提を読み込ませやすくなります。

導入時の技術支援の範囲

AIzen株式会社では、CodexのWindows導入支援として、PowerShell/WSL2の選定、Gitと開発ツールの確認、AGENTS.md作成、サンドボックスと承認ルールの設計、チーム向け操作手順の整備まで支援できます。

Windows環境は、端末管理や社内セキュリティと関わるため、エンジニアだけでなく情シスも巻き込むと導入が安定します。PoC段階で環境差分を洗い出し、全社展開前に標準手順を作ることが重要です。

まとめ

CodexをWindowsで使うには、アプリ、CLI、IDE拡張の違いを理解し、PowerShellとWSL2のどちらで作業するかを先に決める必要があります。要点は次の3つです。

• WindowsアプリはMicrosoft Storeまたはwingetで導入でき、PowerShellとWSL2の実行環境を選べる
• PowerShellはWindowsネイティブ開発、WSL2はLinux系開発に向き、プロジェクト配置場所を統一する
• サンドボックス、Git、パス、実行ポリシーを確認し、チーム共通ルールとして記録する

AIzen株式会社では、CodexのWindows導入、PowerShell/WSL2環境設計、既存リポジトリへのAI開発フロー導入まで支援しています。Windows環境で安全にCodexを使いたい場合は、無料相談で現状の開発環境から整理できます。