Claude Code を Windows で動かしている方なら、一度はこの環境変数の存在に気づいたことがあるかと思います。CLAUDE_CODE_USE_POWERSHELL_TOOL=1 を立てると、Claude Code は内部のシェル実行で PowerShell を優先的に呼ぶようになります。ただ、有効にすべきかどうかは「何を作っているか」「どのターミナルで動かしているか」に強く依存します。
私自身、Windows 11 上の WSL2 と素の PowerShell の両方で開発する機会があり、最近この環境変数の挙動を改めて検証しました。結論から言うと「全員が立てるべき」ものではなく、立てるべき場面と立てるべきでない場面が割とはっきり分かれます。今回はその判断軸を共有します。
そもそも何が変わるのか
この環境変数は、Claude Code がシェルコマンドを実行するときの「デフォルトのシェル選択」に関わります。何も設定していない Windows ホスト環境では、Claude Code は cmd.exe 経由でコマンドを実行することがあり、これが原因で UTF-8 周りのトラブルや、PowerShell スクリプト（.ps1）の実行で意図しない挙動が出ることがあります。
CLAUDE_CODE_USE_POWERSHELL_TOOL=1 を立てると、Claude Code は PowerShell（powershell.exe または pwsh.exe）を優先的に使うようになります。Windows 固有のコマンドや、Get-ChildItem のような PowerShell コマンドレットが自然に動くようになるのが大きな違いです。
ここまではドキュメントに書いてあることですが、実際に開発していると「期待した動作と違う」局面が出てきます。
立てるべき場面
私の経験上、次のような場面では迷わず有効化しています。
第一に、Windows 専用ツールを使うプロジェクトです。たとえば WPF や WinForms、UWP の開発で、dotnet コマンドや MSBuild を呼ぶような場合、PowerShell から実行した方が環境変数や PATH の引継ぎが安定します。
第二に、Windows 上で動く CI スクリプト（.ps1）を Claude Code に書かせたいときです。cmd.exe モードだと PowerShell スクリプトの構文を Claude Code が直接実行できず、Claude が「どう実行すべきか迷う」場面が増えます。
第三に、PowerShell 7（pwsh）を主要シェルとして使っているチームです。Set-PSReadlineOption などのプロファイル設定を読ませたい場合は、PowerShell 経由で実行された方が一貫した環境で動きます。
立てるべきでない場面
逆に、有効化しない方が混乱が少ないケースもあります。
第一に、開発を主に WSL2 上で行っている場合です。WSL の中で動く Claude Code に対して CLAUDE_CODE_USE_POWERSHELL_TOOL=1 を渡しても意味はありません。WSL の中はそもそも Linux なので bash や zsh が使われます。混乱の元になるので、WSL 内の .bashrc には書かない方が良いです。
第二に、Node.js や Python のような「クロスプラットフォームのツールチェーン」だけを使っているときです。npm, pip, pytest などはどのシェルから呼んでも変わりません。この場合、PowerShell に切り替えるとむしろ起動オーバーヘッド（PowerShell の起動は cmd より遅い）でレスポンスが体感で重くなることがあります。
第三に、WSL と Windows ホストを混在させて使う複雑な構成です。Claude Code が起動された時点でのプロセス親（cmd か pwsh か bash か）によって挙動が変わるため、USE_POWERSHELL_TOOL だけ立てると逆に何が起きているのか追えなくなります。
私が試した検証ケース
3つのプロジェクトで両モードを比較してみました。
ケース1: Next.js のフロントエンドプロジェクト（クロスプラットフォーム）。USE_POWERSHELL_TOOL=1 を立てるとコマンド実行のたびに PowerShell が起動するため、ファイル探索や npm run dev の起動でわずかに体感が遅くなりました。立てない方が快適でした。
ケース2: .NET 9 の WPF プロジェクト（Windows 固有）。USE_POWERSHELL_TOOL=1 を立てた状態の方が、dotnet build の出力が UTF-8 で正しく表示され、ビルドエラーの解析がスムーズになりました。これは立てるべきパターン。
ケース3: WSL2 内の Python プロジェクト。USE_POWERSHELL_TOOL の設定は無関係でした。WSL 内は bash で動くので、Windows 側の環境変数は効きません。一応 PowerShell から WSL を呼ぶ場合の挙動を確認しましたが、特に変化はありませんでした。
設定方法と確認手順
有効化するには、ユーザー環境変数として設定するのが一般的です。
# 永続的に設定（PowerShell）
[Environment]::SetEnvironmentVariable("CLAUDE_CODE_USE_POWERSHELL_TOOL", "1", "User")
# 確認
[Environment]::GetEnvironmentVariable("CLAUDE_CODE_USE_POWERSHELL_TOOL", "User")設定後、PowerShell を一度閉じて開き直す必要があります。Claude Code を起動して、簡単なコマンド（Get-ChildItem など）が PowerShell コマンドレットとして実行されるか確認してください。
無効化したい場合は、
[Environment]::SetEnvironmentVariable("CLAUDE_CODE_USE_POWERSHELL_TOOL", $null, "User")または値を 0 に設定するだけでも一時的に無効化できます。
切り替え時の落とし穴
有効化後、一部のプロジェクトで npm run 系のスクリプトが動かなくなったことがありました。原因は、package.json の scripts 内で && を使った連結コマンドを書いていたためです。
{
"scripts": {
"build": "tsc && next build"
}
}PowerShell では古いバージョン（PowerShell 5.1 以前）で && がサポートされておらず、エラーになります。PowerShell 7 以降では問題ありません。チーム内に Windows PowerShell ユーザーが混ざっている場合は、npm-run-all などのツールに置き換えると安全です。
もう一つは、パスのクオート問題です。PowerShell でスペースを含むパスを扱うとき、cmd.exe とは異なるエスケープルールがあります。Claude Code が自動でクオートしてくれることが多いのですが、たまに失敗します。困ったら & "path with space\app.exe" のように明示的にクオートする方が安全です。
判断のチェックリスト
最後に、有効化すべきかの判断を簡単なリストにまとめます。
PowerShell 中心で開発している、.ps1 スクリプトを Claude に書かせる、Windows 固有の SDK や dotnet を使う、Windows ターミナルから直接 Claude Code を立ち上げる、こうした条件のうち2つ以上当てはまるなら、有効化を試す価値があります。
逆に、WSL2 が主戦場、Node.js や Python の単発スクリプトしか書かない、起動オーバーヘッドが気になる、こうしたケースでは無効のままで問題ありません。
私の場合、メインの開発は WSL2 ですが、Windows 専用の小さなツールを書くときだけ、ターミナルセッションごとに $env:CLAUDE_CODE_USE_POWERSHELL_TOOL=1 を立てて作業しています。永続的に立てるよりも、必要なときだけ切り替える運用の方が混乱が少なかったです。
迷ったら、まず1日だけ有効化して使い心地を試してみてください。違和感があればすぐ戻せる、軽い設定です。