AIにチェック用のスクリプトを走らせてもろたら、返ってきたのは「Python」の一語だけ。エラーの文も無し。スクリプトが壊れとるように見えるのに、中身はどこもおかしくない。8月8日、WindowsでClaude Codeを使っとって出くわした場面です。
WindowsのままでもClaude Codeは使えます。うちはWindows 11のデスクトップ機で、WSL（Windowsの中でLinuxを動かす仕組み）を使わずに毎日動かしてます。そのうえで詰まったのは4か所でした。pythonと打つとストアのダミーに当たる。Pythonに書かせたファイルの改行がCRLFに化ける。パイプを挟むと失敗が exit 0 に見える。コマンドの中のバッククォートが実行される。直し方は順に、アプリ実行エイリアスをオフにする、newline=” を付ける、出力をファイルに落としてから見る、長い文はファイル経由で渡す、です。
始める前に何をそろえるかは、前にClaude Code 使い方入門で書きました。この記事は、動かし始めてから詰まった所の話です。
うちのWindowsのClaude Codeは、コマンドの窓口が2つ
先に、うちの環境の前提を書いときます。AIがコマンドを打てる窓口は2つ。Windowsに最初から入っとるPowerShellと、Git Bashです。Git BashはGitと一緒に入る道具で、Windowsの上でLinuxと同じ書き方（bash）のコマンドが打てます。
自動で回しとる仕組みのコマンドは、Git Bashの書き方が中心です。なので、Windowsならではの罠と、bashならではの罠の両方を踏む。下の4つのうち、1と2はWindowsの話、3と4はbashの話です。
罠1｜Microsoft Storeのダミーが先に呼ばれて終了コード49
冒頭の場面の正体は、Microsoft Storeのダミーでした。Windowsには、pythonと打つとストアへ案内するための小さなプログラムが最初から入ってます。これが、本物のPythonより先に見つかる場所に居座っとった。
症状が分かりにくいんです。エラーの文は出ず、「Python」の一語を出して、終了コード49で終わる。終了コードは、プログラムが「うまくいったか」を数字で返すもので、0なら成功、それ以外は失敗です。
確かめ方は where.exe python。2行出てきて、1行目が WindowsApps のフォルダなら、それがダミーです。
しばらくは、pythonの代わりに py -3 と打って逃げてました。ちゃんと直したのは8月29日。手は2つです。
- Windowsの設定→「アプリ」→「アプリの詳細設定」→「アプリ実行エイリアス」で、python.exe と python3.exe をオフにする
- 本物のPythonのフォルダで python.exe をコピーして、python3.exe という名前で置く
2つ目が要ったのは、エイリアスを切った直後に python3 だけ「command not found」になったから。ダミーが消えたら、本物の側に python3.exe がそもそも無かったことが見えた、という順番です。直したあとは、python も python3 も py -3 も、同じ Python 3.11.9 を指すようになりました。
このダミーがスクリプトの中から呼ばれた時の怖さは、前にWindows自動化で黙って壊れる罠3つで書きました。
罠2｜Pythonに書かせたファイルの改行がCRLFに化ける
改行には種類があって、LinuxやMacはLF、Windowsは昔からCRLF（CRとLFの2文字）を使います。画面で見たら同じ改行でも、中の文字の数が違う。
WindowsでPythonにファイルを書かせると、何も指定せんかったら、LFをCRLFに変えて書き込みます。AIが書いたスクリプトも、ここは同じです。
8月25日に気づいたきっかけは、字数のズレでした。同じ文章を、AIのファイル書き込み機能で書いた版と、Pythonで書いた版で比べたら、Python版だけ字数が多い。うちは、送る前の文章が「手元の正本と1文字も違わんか」を照合する仕組みを使ってます。この照合は、CRが1つ混ざるだけで合わんくなる。
9月の末にも、手順書のファイルやスクリプトが、Pythonで書き直した拍子に丸ごとCRLFに化けました。
直し方は、ファイルを開く時に newline='' を付けるだけ。open(path, 'w', encoding='utf-8', newline='') の形です。直ったかどうかは見た目では分からんので、ファイルの中の \r の数を数えて、0なのを確かめてます。
罠3｜パイプを挟むと、失敗が「exit 0」に化ける
8月15日、チェック用のスクリプトをAIに走らせた時の話です。出力が長いので、最後の45行だけ見る形にしてました。py -3 チェック.py | tail -45 みたいな書き方です。
結果は「exited with code 0」。成功です。ところが出力を読んだら、判定の行に赤い印が1本立っとった。スクリプト自身は「失敗」を返しとったんです。
原因はパイプ（|）の性質でした。パイプでつないだ時の終了コードは、最後のコマンド（ここではtail）のものになる。tailは行を切り出すだけなので、まず失敗しません。つまり、前で何が起きても成功に見える。
気づけたのは、判定の行を目で見とったから。終了コードだけ見とったら、赤を緑として扱っとったところでした。今は、合否を返すスクリプトはパイプを通さず、出力を丸ごとファイルに落としてから読ませてます。set -o pipefail を先に打つ手もあるけど、ファイルに残すほうが、あとで全文を見返せる。
罠4｜コマンドの中のバッククォートが実行されて、文字が消える
8月19日は、AIにメモの台帳へ追記してもろた時。根拠の場所を `ファイル名:行番号` のようにバッククォートで囲んで、py -3 -c にそのまま文章を渡してました。
bashでは、二重引用符の中でも、バッククォートは「この中をコマンドとして実行して、結果に置き換えろ」という意味になります。囲んだ部分はコマンドとして走って、当然失敗して、空っぽに置き換わった。
厄介なのは、画面には「command not found」が1行出るだけで、書き込み自体は成功扱いになること。根拠の場所だけがきれいに抜けたメモが、台帳に残りました。
対策は、文章をシェルに通さんこと。先にファイルへ書き出して、スクリプトにはそのファイルを読ませる。バッククォートやドル記号（$）、バックスラッシュが1文字でも入る文は、この形にしてます。
WindowsでClaude Codeを使い始める時に、先にやっとくこと
4つとも、先に知っとれば踏まんで済んだ罠でした。うちは全部、踏んでから知った。これから始めるなら、この4つだけ先に済ませとくと楽です。
where.exe pythonを打って、1行目がストアのダミーやないか見る- AIが書くPythonのファイル書き込みには
newline=''を付けてもらう - 合否を見たいコマンドは、パイプでつながず、出力をファイルに残す
- 長い文章や記号の多い文は、コマンドに直接書かず、ファイル経由で渡す
2から4はAIがやる作業の話なので、AIが毎回読むメモに書いとくのが早い。うちは4つとも、そのメモに書いてあります。
よくある質問
Claude CodeはWindowsでも動く？
動きます。うちはWindows 11のデスクトップ機で、WSLを使わずに毎日使ってます。うちはGit Bashも入れてあって、AIが出すbashの書き方のコマンドはそこで動いてます。導入に何が要るかは公式のドキュメントで確かめてください。うちが最初にそろえた物は使い方入門に書いてます。
pythonと打っても本物のPythonが動かないのはなぜ？
Windowsでよくあるのは、最初から入っとるストアへ案内するダミーが、本物より先に呼ばれとる形です。設定の「アプリ実行エイリアス」でpython.exeとpython3.exeをオフにすると、本物が呼ばれるようになります。うちの場合は「Python」と一語出して終わる形でした。
Windowsで改行がCRLFになるのを防ぐには？
Pythonなら、ファイルを開く時に newline=” を付けます。付けんと、Windowsでは書き込む時にLFがCRLFへ変わる。見た目では区別がつかんので、直したあとは \r の数が0かどうかで確かめるのが確実です。
あわせて読みたい
- Windows自動化で黙って壊れる罠3つ｜エラーが出ない
- Claude Codeの許可設定｜名指しで足すと翌日また止まる｜止まる原因がWindowsやなく許可の時はこっち
- Claude Code 使い方入門｜副業未経験が最初の1週間でやったこと