この記事の結論（先に3つだけ）
結論から書きます。AIに「これはやってはいけない」と止めさせる見張り役（フック）が、Windows のパソコンでは一度も効いていませんでした。原因は2つありました。1つは python3 というコマンドが中身の無い偽物だったこと。もう1つは、日本語のファイル名が文字化けして、見張りの判定をすり抜けていたことです。直すのに5日かかりました。
- 穴その1：Windows の python3 は、中身が空の偽物だった。 本物の Python は別の場所にあり、並び順を入れ替えて直した
- 穴その2：日本語のファイル名が、見張りを素通りしていた。 画面では正しく見えるのに、中身の文字が壊れていた
- 直したあとも、パソコンで Claude Code を起動し直すまで効かなかった。 起動し直せるのは私だけだった
50代・非エンジニアです。プログラミングはできません。
前回は、動画を速くする部品を「ライセンスが商用不可」で入れなかった話でした。今回は、もう少し地味で、もう少し怖い話です。
私の保管庫（AIたちが共有するメモの置き場所）には、「絶対に守らせたい決まり」を、AIの気持ちに任せず仕組みで止める見張り役がいます。保管庫では「門番」と呼んでいます。ルールのファイルを勝手に書き換えようとしたり、過去の記録を上書きしようとしたりすると、門番が止めます。
その門番が、Windows では一度も働いていなかったのです。
同じ Windows で動画を作っていた話は、第12回 で書きました。今回はその裏で起きていたことです。
Claude Code のフックとは：AIの手を止める見張り役
フックとは、AIが何かをする直前や直後に、決まったプログラムを自動で走らせる仕組みです。 Claude Code（AIが実際にパソコンを操作して作業する道具）に備わっています。
たとえば私の保管庫では、次の見張り役を置いていました。
- 門番：ルールのファイルの書き換えや、過去の記録・資料の上書きを止める
- 締めの点検：記録に決まった見出しが無いまま作業を終えようとすると止める
ルールを文章で書くだけだと、AIは読んでも守らないことがあります。これは第8回で書いたとおりです。だから本当に守らせたいものだけは、フックで物理的に止めるようにしていました。
フックの中身は、Python というプログラム言語で書いてあります。AIが何かをしようとするたびに、Claude Code が python3 というコマンドで、その見張りのプログラムを呼び出します。
この「python3 で呼び出す」ところに、1つ目の穴がありました。
Windows でフックが動かなかった：「hook error」が延々と出ていた
最初の手がかりは、Windows の画面に延々と出ていた英語のエラーでした。 「PreToolUse:Bash hook error」「Failed with non-blocking status code: Python」という表示です。
「non-blocking（止めない）」という言葉のとおり、エラーが出ても作業そのものは続いていました。つまり見張りは失敗しているのに、AIは何事もなかったように作業を進めていたわけです。
保管庫の取りまとめをしているクラウドのAIは、この報告を見てこう書きました。
この保管庫の「絶対に守らせたい決まり」は全部フックで止めている。Windows で1つも効いていないなら、Windows だけ無法地帯。
クラウドのAIの見立ては「Windows に python3 というコマンドが無いのでは」でした。ただし、【推測】の印付きです。
ここでクラウドのAIは、すぐには直しませんでした。先に直して壊すより、確かめる1コマンドを待つほうが速いと判断して、Windows のAIに「3つのコマンドを打って結果を見せて」とだけ頼んでいます。
python3 --versionpython --versionpy --version
どれも「Python が入っているか、どの版か」を表示させるコマンドです。
穴その1：Windows の python3 は中身が空の偽物だった
結果は、3つとも使えませんでした。 python3 と python は「Python」とだけ表示して終わり、py は「認識されません」でした。
調べると、python3 と python の正体は、Microsoft Store の「アプリ実行エイリアス」でした。Windows が用意している入口のようなもので、ファイルの大きさは0、中身がありません。
クラウドのAIは前に「python3 が無くても、python か py はあるはず」と書いていました。これは外れでした。 ただ、それも【推測】として書いていたので、断定はしていません。
本物の Python 3.12.10 は、ユーザーのフォルダの奥（.local\bin）に入っていました。そこで Windows のAIは、次の手を打ちました。
- 本物の Python を
python3.exeという名前でコピーする - それでも偽物が先に見つかったので、探す順番（PATH）を入れ替える
PATH とは、コマンドを打ったときに Windows が「どのフォルダから探すか」の順番表です。偽物のフォルダが先頭にいたので、本物のフォルダを先頭に動かしました。
| 探す順番 | |
|---|---|
| 変更前 | 偽物のフォルダ → 本物のフォルダ |
| 変更後 | 本物のフォルダ → 偽物のフォルダ |
この「コピーしても偽物が先に出たら、順番を入れ替える」という分かれ道は、クラウドのAIが依頼書に先に書いておいたものでした。実際にその分かれ道に入りました。
戻し方も記録に残っています。順番を元に戻して、作った python3.exe を消すだけです。
穴その2：日本語のファイル名が見張りを素通りしていた（独自）
1つ目の穴を調べている途中で、もっと怖い2つ目の穴が見つかりました。 日本語のファイル名だと、門番の「既存のファイルの書き換えを止める」判定が、毎回すり抜けていたのです。
Windows のAIは、動く Python で門番のプログラムを直接動かし、3件の試験をしました。
| 試したこと | 期待 | 結果 |
|---|---|---|
| 英数字の名前のルールのファイルを書き換える | 止まる | 止まった |
| 新しい記録を作る | 通る | 通った |
| 日本語の名前の、すでにある記録を書き換える | 止まる | 止まらなかった |
なぜすり抜けたのか
原因は、文字コードでした。文字コードとは、文字をコンピューターの中の数字に置きかえるときの「対応表」のことです。
Claude Code は、門番に「いまからこのファイルを書き換えます」という知らせを、UTF-8 という対応表で渡します。ところが Windows の Python は、受け取るときに cp932 という別の対応表で読んでいました。cp932 は、昔からの日本語 Windows の対応表です。
違う対応表で読むと、日本語の文字が壊れます。厄介なのは、その壊れ方でした。
- エラーにならない
- 画面に表示すると、正しいファイル名に見える
- でも中身の数字が違うので、「そのファイルはありますか」と聞くと「ありません」と返ってくる
門番は「すでにあるファイルなら止める」という判定をしていました。ファイルが「無い」と判定されるので、日本語の名前のファイルは、毎回「新しく作るだけ」と見なされて通っていたのです。
私の保管庫のファイルは、ほとんどが日本語の名前です。 つまり Windows では、事実上ほぼ無防備でした。
直し方の選び方
直し方の候補は2つありました。
- 案B：設定ファイルで、Python に「UTF-8 で読め」という指定を付けて呼び出す
- 案C：門番のプログラム自体を、受け取った中身を必ず UTF-8 として読む形に書き直す
クラウドのAIは、案Cを選びました。理由は、公式の説明書にありました※1。
sh -c on macOS and Linux, Git Bash on Windows, or PowerShell when Git Bash isn’t installed.
Windows では、フックは Git Bash という道具で動くのが基本です。ところが Git Bash が入っていないパソコンでは PowerShell で動く、と書いてあります。案Bの書き方は PowerShell では使えません。設定ファイルは全部のパソコンで共有しているので、そこに賭けられない、という判断でした。
Windows のAIが先に調べたときは、「Windows は Git Bash が基本」のところまでしか引いていませんでした。クラウドのAIが同じページを開き直したら、続きがあったわけです。
試験は合格、それでも「本番」で効いたかは別だった
門番のプログラムを直したあと、Windows で試験を走らせると、合格でした。不合格は0件です。 日本語の名前の資料を書き換えようとすると、ちゃんと「門番が止めました」と出ました。
ただし、ここで話は終わりませんでした。
残りの見張り役2本にも、別の穴があった
門番以外の見張り役2件（締めの点検など）にも、Windows でだけ起きる穴が見つかりました。
- Windows には存在しない
/tmpというフォルダを使っていた - Windows では使えない
grepという道具を呼び出していた - 受け取った文字を cp932 で読もうとして落ちていた
grep を使っていた見張り役は、落ちたことを内側で飲み込んで、「必要以上に止める」側に倒れていました。クラウドのAIはこれらを直し、試験を1本増やしています。
PATH の変更は、起動し直すまで効かない
もう1つ、思わぬ壁がありました。PATH の並び替えは、新しく起動したプログラムからしか効かないのです。
Windows で動いていた Claude Code は、直す前に起動したものでした。だから、その中で何を試しても、まだ偽物の python3 を見ていました。直っているのに、このセッションにはまだ効いていない、という状態です。
Claude Code を起動し直せるのは、パソコンの前にいる私だけでした。
手で試すときの落とし穴
試す途中で、Windows のAIはもう1つ落とし穴を見つけています。PowerShell で、ファイルの中身を「|（パイプ）」でつないで門番に流すと、門番が素通りしたように見えるのです。パイプが途中で cp932 に書き直してしまうためでした。
AIは最初これで「素通りした」と誤判定しかけ、<（リダイレクト）でそのまま流すのが正しいと記録に残しました。フックの問題ではなく、試す側の問題だったわけです。
起動し直したら、Windows でも門番が止めた
私が「再起動終わりました」と伝えたあと、Windows のAIが確かめると、門番は実物で止めました。 2026年9月15日のことです。
| 確かめたこと | 結果 |
|---|---|
python3 --version |
Python 3.12.10（本物） |
| 日本語の名前の資料を書き換えようとする | 「門番が止めました」と出た |
| 最初の症状「hook error」 | 6回作業して、一度も出なかった |
| 締めの点検 | 前の作業の終わりに、エラー無しで動いていた |
最初に症状が出てから、ここまでで5日かかりました。
1つ、AIの失敗もありました。私が「再起動終わりました」と伝えたとき、Windows のAIは最初「何の再起動か分からない」と聞き返してきたのです。自分が頼んだことなのに、記録に「再起動待ち」と書いたきり、どこを探せば分かるかを決めていませんでした。
AIはその場で、次からのやり方を決めています。「何のため？」と聞き返す前に、そのパソコンの会話の履歴を「再起動」で検索する。
おわりに：Claude Code のフックを Windows で使うなら
今回の区切りで分かったことは、次の5件です。
- エラーが出ても作業が止まらない見張りは、効いていないのと同じ。 画面のエラーは無視しない
- Windows の python3 は、中身が空の偽物のことがある。 本物の場所を探して、探す順番を入れ替える
- 日本語のファイル名は、文字コードの違いで判定をすり抜けることがある。 エラーにならないので気づきにくい
- 設定ファイルは全部のパソコンで共有される。 1台の事情に合わせた書き方は、別のパソコンで壊れる
- PATH を変えたら、起動し直すまで効かない。 起動し直せるのは人だけ
かかった費用は0円です。
仕組みで止めているつもりでも、その仕組み自体が動いているかは、別に確かめる必要がありました。 しかも、試験に合格することと、本番で止まることも別でした。
最後に、まだ確かめていないことが1つあります。締めの点検は、本番で「エラー無しで動いた」ことまでは確かめました。でも、本番で実際に「見出しの無い記録」を止めた場面は、まだありません。
出典
- ※1 Hooks reference（Claude Code Docs）
