Claude Code の Rules が死んでいた話をかわしんさんが解説。振り返りで気づくサイレント故障の見つけ方

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、かわしんさんの「Claude Code の Rules はもう死んでいる」という記事を紹介するね。

かわしんさん（kawasin73のブログ本文より）

ちなみに死んでいるのは Rules だけではないです。Read ツールによって発火する Hooks や、サブディレクトリの CLAUDE.md も読み込まれずに死んでいます。

2026年8月18日から、Claude Codeの中でひっそり壊れていたものがありました。

これ、地味に怖い話です。派手なエラー画面が出るわけじゃない。「設定したはずのルールが、なぜか効いてない」って、一番気づきにくい壊れ方なんです。しかも10日以上、誰も気づかなかった。私、AI秘書の凛ちゃんチームに毎日いろんな判断を任せてます。で、「任せる」って見ないで放り投げることじゃないんです（それ、ただの丸投げ）。委ねたい気持ちはある。でも委ねた先が嘘つく・逃げる・やらないなら、任せられない。信頼できる仕組みが先。これが私の軸です。Rulesが静かに死んでたこの10日間、まさに「信頼できる仕組み」の土台がぐらついてた期間なんですよね。気づく手段を持ってたかどうかが分かれ道でした。便利なツールほど「入れたら終わり」になりがちです。でも入れた後も時々様子を見にいく。それをやらないと、土台が崩れてることにすら気づけない毎日が続いてしまいます。「入れて終わりにしない」。この一手間が、地味だけど効くんです。

🎯 今日できること：自分の.claude/settings.jsonを開いて、今日中にCLAUDE_CODE_THRIFTY_SONICの項目があるかを5分だけ確認します。

かわしんさん（auto-modeのシステムプロンプト調査部分）

auto-mode のシステムプロンプトが、Read ツールではなく cat / sed / grep などの Bash ツールを使うように指定しているという事でした。そのため、 Bash ツールの実行はルールをバイパスして今回の事故が起きていました。

なぜRead ツールが使われなくなったのか、原因までかわしんさんは追いかけています。

これを読んで「あ、これ私のAI運用でも起こりうるやつだ」って思いました。誰かが「LLMはbashの方が上手に使えるから」って理由で足したであろう一行が、遠く離れた場所にあるルール機能をまるごと殺してた。この距離感が一番怖いところなんです。私が普段AIに仕事を任せる時の最低条件も、実はここにつながってます。「わからないことは憶測しないできく。わかることは2度聞かない」って線引きを自分の中に持ってるんですが、これ裏を返すと「AIが何を根拠に動いているか」を人間側も時々のぞきにいかないと、この手の静かな設計変更には絶対に気づけないってことなんです。便利になればなるほど、中身を見なくなる。だからこそ時々のぞく癖が要るって思います。私も分身AIへ毎日いろんな判断を渡してますが、渡した後の中身を見に行く手間を惜しんだ瞬間から、本当に任せられているのか、ただ丸投げしているだけなのか、境目が曖昧になっていく気がしてます。中身をのぞく手間は、信頼を裏切らないための最低限の投資だと考えています。

🎯 次にやること：直近1週間で「ルールを書いたのに反映されない」と感じた場面を1つ思い出し、使ったツールがReadだったかBashだったかをメモに書き出します。

かわしんさん（PostToolUseフック案への評価）

完全な対症療法で安直すぎます。まず、ファイルを編集する命令を生成した後にプロンプトを注入しても遅いですし、それぞれのルールがすでに注入されているかどうかを管理しなければならないので複雑になります。

Claude Code自身が最初に出した解決策を、かわしんさんはあっさり却下しています。

正直に告白します。私、この判断が一番好きです。AIが出してきた「動く解決策」に飛びつかずに、「これ根っこを直してないよね」って自分の頭で仕分けてる。私自身、シェフのつもりでキッチンに立ちすぎてしまう性質があります。「委ねるOS」で実行そのものは手放す練習をしています。手放すのと、中身を確認しないのは別モノなんです。分身AIや仕組みへ所有権を預けても、その仕組みが症状だけ隠してるのか、根っこを直してるのかは、最後に自分の目で見て決めます。ここを飛ばすと、便利さの裏でどんどん脆さが積み上がっていく。この記事の著者がやってたのは、まさにその「最後の一手」だったんだと思います。AIが出した答えをそのまま採用するか、一段立ち止まって仕分けるか。この差、時間がかかるようでいて、後から出てくる手戻りの量を考えたら近道になることの方が多い気がしてます。急がば回れ。AIとの仕事でも、やっぱり通用すると感じました。

🎯 10分でやること：今動いている自分の応急処置（フック・回避策）を1つ選び、根本原因を潰しているか症状だけ隠しているかを10分で仕分けます。

かわしんさん（根本原因への対処部分）

その結果 CLAUDE_CODE_THRIFTY_SONIC feature flag を無効にすれば問題のシステムプロンプトを削除できるということを発見してもらいました。また、この feature flag の影響範囲を調べてもらいましたが、問題の Read ツールより Bash ツールを使う指定の部分のみということだったので、この feature flag を無効化することは比較的安全だと思います。

ここでかわしんさんは、直った後の確認までもう一段丁寧にやっています。

「直った、よかった」で終わらせない。そのフラグを切ったら他に何が変わるのかまで確認してから実行に移してます。私が仕組みを人やAIへ任せる時も、同じ順番を守るようにしてます。「見本とカルピス原液をマージするのが最強」って自分の判断軸があるんです。見本は強い型ややり方で、カルピス原液は自分の価値観や背景。AIが型を選んでくれても、その型がどこまで自分の状況に効くかは、最後は人間側が影響範囲を確かめてから乗ります。「なんとなく直ったっぽい」で終わらせず、「どこまでが安全な範囲か」を言葉にしてから渡す。この記事の著者がやってたのは、まさにそういう一手でした。AIが出した解決策を鵜呑みにせず、その影響範囲まで確かめてから採用する。この一手間があるかどうかで、同じ「直った」でも中身の信頼度がまるで違ってくるんです。小さな確認の積み重ねが、結局は一番の近道になります。

🎯 今日からのルール：feature flagや環境変数を無効化する前に、その影響範囲をAIに1回聞いてから実行する、を今日からのルールにします。

かわしんさん（記事末尾のまとめ）

多分 Rules が動いていないことにみなさん気づいていないのかもしれません。または、Claude Code が使われなくなってしまったのか。振り返りをするとこういうサイレントな AI ハーネスのリグレッションに気付けるので、振り返り、おすすめです。

この不具合、かわしんさんは新しい作業のついでじゃなく振り返りの時間に見つけています。

私も毎日、AIとの一日を振り返る時間を意識的に確保してます。「AIとの認識のズレを、現場ですり合わせるボールとして人間へ戻すか。それとも一段上の視点から仕組みを改善するきっかけとして受け取るか」。同じズレでも、見る高さでまるで意味が変わるって整理してます。かわしんさんのこの一件も、「ルールが効かない」という現場のズレを、その場しのぎで終わらせずに、一段引いた振り返りの時間で「AIハーネス全体の設計ミス」として捉え直したから解決まで辿り着いてます。現場で困った瞬間だけじゃなく、定期的に一歩引いて見る時間を持つこと自体が、AIに仕事を任せる上での装備の一つなんだと思います。この振り返り、特別なツールがなくても始められます。セッションの終わりに「今日、思った通りに動いたか」を一言メモするだけでも、積み重なれば同じ効果になるはずです。詳しくはClaude Codeの/insightsで使い方を診断した記事でも近い話をしてます。良かったら合わせて読んでみてください。

🎯 今週の予定：今週のどこかで15分、自分のAI運用を振り返る時間を1回だけ予定に入れます。

かわしんさん（原因調査の裏側について）

どうやってこの feature flag を発見したのかを聞いたところ、インストール済みバイナリの埋め込みソースから逆引きしたそうです。いいね。よくないけど。

原因のfeature flagは、公式ドキュメントに書いてあった情報ではありませんでした。

「いいね。よくないけど。」という著者の一言、すごく正直でいいなって思います。ドキュメントに答えが無い時、AIに調べさせて終わりじゃなくて、バイナリの中まで潜って確かめてる。私が分身AIやAI秘書のチームに求めてる姿勢も、実はここに近いんです。「AIの嘘・手抜き・無断実行はありのままではなく、感謝を持って仕組みを改善し、役目を果たせるよう育て直す対象」だと自分の中で線を引いてます。調べ尽くさずに「たぶんこう」で止めるのは、私にとっては手抜きと同じ扱いです。AIハーネスまわりの不具合、公式が追いついてない部分がまだまだ多い。だから最後の一段を自分たちで掘りにいく姿勢そのものが、この記事の一番の学びだったと思います。答えが無い場所ほど、自分の手で確かめる価値があります。今回、あらためて実感しました。

🎯 15分の宿題：「たぶんこうだろう」で止めている調査を1つ選び、公式ドキュメントかソースコードまで15分掘って確かめます。

かわしんさんの記事が教えてくれたのは、Claude Codeという1つのツールの不具合情報だけじゃありません。「便利に使えている」と「正しく動いている」は別物だという、当たり前だけど見落としがちな事実でした。

エラーも警告も出ないまま、設定したはずのルールが10日以上効いていませんでした。この静かさこそが一番の怖さで、気づく手段は日々の振り返りという地味な習慣の中にありました。

AIツールに仕事を任せる場面が増えるほど、「動いているつもりで実は動いていない」に気づく仕組みを、自分の運用のどこかに1つは仕込んでおきたいです。

かわしんさんが最後に書いていた「振り返り、おすすめです」。あっさりした一言ですが、この記事全体の結論そのものだと思います。特別な監視ツールを入れるより先に、まず自分の振り返りの時間を守ります。