Claude Codeが同じミスを繰り返すとき、ルールを「止められる形」に変える

開発者がClaude Codeに指示を与え、やってはいけない操作を禁止し、失敗するたびに指示書へ注意書きを足す。それでもClaude Codeは、与えた指示を忘れ、禁止したはずの操作をまた実行する。ルールは増える一方なのに、再発だけが止まらない。

この詰まりは、Claude Codeの賢さの問題ではない。ルールの置き場所と、効かせ方の問題だ。本稿では、再発を止める仕組みを、文章で頼む方式から、操作を物理的に止める方式へ作り替える手順を示す。

文章のルールがなぜ効かないのか

Claude Codeに渡すルールの多くは、文章として書かれている。プロジェクトの指示書に「これはするな」と並べ、起動時にまとめて読ませる。だが作業が進むと、その文章は目の前のタスクに押しのけられ、参照されなくなる。

この性質は、運用ルールの書き方を論じた記事でも指摘されている。 Claude Codeを暴走させない運用術は、指示書を便利なお願い集ではなく、事故を減らす運用境界として書くべきだとした。作者のCLAUDE.mdは2行だけという話は、ルールを長さではなく、失敗したときに本当に止められるかで評価せよと述べている。

ここから一つの帰結が出る。止められないルールは、書いても守られない。文章は読み手が従う前提に立つが、再発するのはその前提が崩れる場面だからだ。

三つの症状を切り分ける

「また同じことをした」という不満は、よく見ると三つの異なる症状を含んでいる。原因が違うので、対処も分かれる。

指示を忘れる：渡したルールが、作業中の文脈に埋もれて参照されない。
禁止した操作を繰り返す：やってはいけない操作を、止める仕組みがないまま実行できてしまう。
同じミスを繰り返す：一度起きた失敗が、次に同じ操作を物理的に防ぐ形に変換されない。

この三つを一括りに「AIが言うことを聞かない」とまとめると、対策も曖昧になる。それぞれに別の止血点がいる。

禁止は、実行前に止める

禁止した操作を繰り返すなら、文章で禁じるのをやめ、操作の実行前に止める。 Claude Codeには、ツールが動く直前に外部のスクリプトを走らせ、その終了コードで実行を拒否できる仕組みがある。コマンドの中身を検査し、禁じた文字列に一致したら拒否する。これで、禁止は読み手の記憶ではなく、機械の判定になる。

問題は、禁止を一件増やすたびに専用のスクリプトを書く運用だと、手間が重すぎる点にある。重いと、人はまた文章のほうへ逃げる。逃げた先のルールは、前節のとおり守られない。

そこで、禁止のルールをコードではなくデータに置く。一行が一つの禁止ルールになるファイルを用意し、それを読む汎用のスクリプトを一本だけ用意する。各行には、対象とする操作の種類、検査する場所、一致させたいパターン、拒否したときに出す理由を書く。

{"tool":"Bash","field":"command","pattern":"--no-verify","reason":"フックのスキップは禁止","scope":""}

禁止を増やすのは、このファイルに一行足すだけになる。スクリプトには手を入れない。追加の手間が一行まで下がると、ミスのたびに禁止を増やす運用が、実際に続けられるようになる。

同じミスを、禁止へ自動で橋渡しする

再発防止が続かない最大の原因は、ミスから禁止への変換が手作業に頼っている点にある。失敗を記録する習慣があっても、それを「次は実行前に止まる形」へ直す一歩は、本人が覚えていないと抜ける。

この一歩を仕組みに肩代わりさせる。作業の区切りで失敗を示す表現を検出したら、その直前に実行された操作を拾い、禁止ファイルに足せる候補の一行を組み立てて提示する。人は理由を書き足し、不要なら捨てる。ミスを物理ブロックに変える作業が、ゼロから書く作業ではなく、提示された一行を確認する作業になる。

ここでも、止めるかどうかの最終判断は人が持つ。検出は機械的に積み上げ、採否は人が決める。この切り分けは、知識ベースを育てる運用で積み上げはAI、事実確認は人間とした線引きと同じだ。

忘れるなら、その場でもう一度見せる

指示を忘れる症状には、ルールを全文で読ませ直しても効かない。全文は、また文脈に埋もれるからだ。効くのは、いま受け取った依頼に関係するルールだけを、依頼のたびに先頭へ短く再掲することだ。

依頼の文からキーワードを取り、禁止ファイルと失敗記録のうち重なるものだけを数件選んで差し込む。関係のない大量のルールは出さない。読み手が今まさに踏みそうな一線だけが、毎回目の前に出る状態を作る。

自動化はするが、無人化はしない

操作を実行前に止める仕組みには、一つ注意がいる。コマンドの文字列にパターンが一致したら止めるので、パターンを広く書くと、正当な操作まで巻き込む。実際、禁止語を含む文字列を検査するコマンドそのものが、その禁止に引っかかって止まることがある。

だからパターンは具体的に書き、巻き込みが起きたら人が調整する。止める範囲を決めるのは人で、止める実行は機械が担う。仕組みに任せきれるのは判定の実行までで、何を禁じるかの線引きは任せきれない。

入れた仕組みが、すぐ全部は効くわけではない

三つの仕組みを設定し終えても、その場で全部が動き出すとは限らない。フックは、いつ実行されるかの種類ごとに、設定の読み込まれ方が違うからだ。

ツールの実行前に操作を止める判定は、操作が走るたびに設定を読み直す。だから足したその場から効く。実際、禁止を一行足した直後に、その禁止に当たるコマンドはもう止まる。

一方、依頼のたびに関係するルールを再掲する仕組みと、作業の区切りで失敗を検出する仕組みは、起動時に一度だけ読み込まれる。セッションの途中で足しても、そのセッションのあいだは眠ったままになる。止めるほうは即座に効くのに、再掲と検出だけが効いていない、という食い違いが起きる。

対処は単純で、設定を一通り入れたらセッションを開き直す。開き直すと、三つとも設定から読み込まれて動き出す。再掲が効いているかは、禁止語を含む依頼を一つ投げ、冒頭にそのルールが再掲されるかで確かめられる。

一度の設定ではなく、続く習慣

この仕組みは、入れて終わりではない。新しい失敗が出るたびに禁止を一行足し、巻き込みが出るたびにパターンを直す。ノートを引き出せるVaultの作り方が、引き出せる設計は一度やれば終わる設定ではなく続けるあいだだけ効く習慣だと述べたのと、構造は同じだ。

続ける手間に見合うのは、同じミスが実際に繰り返し起きているときに限る。一度きりの失敗まで禁止に変えると、禁止ファイルが巻き込みの温床になる。繰り返し踏む一線だけを、止められる形に移していく。

まとめ

再発はAIの賢さではなく、ルールの置き場所と効かせ方の問題として扱う。
「忘れる」「禁止を繰り返す」「同じミスを繰り返す」は別の症状で、止血点も別になる。
禁止は文章ではなく、実行前に操作を止める判定に変える。
禁止をコードではなくデータの一行に置くと、追加の手間が下がり、運用が続く。
ミスから禁止への変換を仕組みが橋渡しし、採否の判断だけ人が持つ。
忘れる症状には、依頼に関係するルールだけをその場で再掲する。
パターンの巻き込みは人が調整する。止める実行は機械、線引きは人。
止める判定はその場で効くが、再掲と検出は起動時に読み込む。設定後はセッションを開き直す。