2026-08-03

WindowsでClaude Codeを使うと踏む、3つの地雷とその回避法

執筆： hybs02

Claude Codeの解説は、なぜかMacを前提にしたものばかりです。私はWindowsで使っていて、Mac記事には出てこない問題に何度もぶつかりました。

どれも「知っていれば1分、知らないと30分」の類です。実際に踏んだ3つを、直し方つきで書き残します。

地雷1：日本語が化ける（cp932の壁）

最初にぶつかったのがこれです。自分で書いた小さなツールを動かしたら、日本語の出力がこうなりました。


=== �����f�W�^�����i�J�e�S��� ===

原因は、Windowsのコンソールが標準では日本語を「cp932」という古い文字コードで扱うのに対し、プログラム側はUTF-8で出力していたことです。噛み合っていないので、そのまま文字化けする。

対処は、プログラムの先頭で出力をUTF-8に固定することでした。


import sys
try:
    sys.stdout.reconfigure(encoding="utf-8")
except Exception:
    pass

この数行を入れるだけで、化けは止まりました。

厄介なのは、この問題がWindowsでしか起きないことです。Macの解説記事を読んでも一切出てこない。だから「自分の書き方が悪いのか」と見当違いの場所を疑って時間を溶かします。

もっと厄介だったのがこれです。定期実行のために小さな起動用ファイル（.cmd）を作ったら、動いたり動かなかったりする。

原因は改行コードでした。文字が見えないので、開いても異常に気づけません。

Windowsのバッチファイルは、行の終わりが「CR+LF」であることを前提にしています。ところがツールによっては「LF」だけで保存されることがある。するとWindowsは行の切れ目を認識できず、次の行と繋がったものとして読んでしまう。

結果、こんなエラーが出ます。


'""' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

"" ——空っぽを実行しようとしている。設定を読み込む行が前の行とくっついて、丸ごと無視されていたわけです。

これに気づかず、私は1ヶ月間、自動化が止まっていることに気づきませんでした。その話は 1ヶ月まるごと止まっていた件に書いています。

対処は単純で、バッチファイルはCR+LFで保存すること。それだけです。日本語のコメントも化ける原因になるので、.cmdの中身は英数字だけにしておくと安全でした。

Windowsには、いつの間にか複数のPythonが入っていることがあります。ストア版、公式インストーラー版、そして「見せかけだけの実行ファイル」。

私の環境では、python と打つと WindowsApps の下にあるものが反応しましたが、実際に動いていたのは別の場所にある本体でした。手で動かす分には問題なくても、定期実行のように環境が変わる場面では、違う方を掴んで失敗します。

対処は、どれが本体かを確認して、自動化ではフルパスで指定することです。


python -c "import sys; print(sys.executable)"

これで表示された道筋を、そのまま設定に書く。曖昧さがなくなります。

ここまで書くと不利に見えますが、慣れれば普通に使えます。地雷はどれも一度踏めば二度と踏まない種類のものでした。

むしろ、日本のPC利用者の多くはWindowsです。Mac前提の情報しかない状況は、裏を返せば同じところで困っている人が大勢いるということでもあります。私が時間を溶かした分は、この記事で回収してもらえればと思います。

道具そのものの評価は非エンジニアの正直レビューに、何ができるかは Claude Codeとは？に書きました。