Claude Codeのhooksが動かない理由。設定を過信せず多層防御を構築する

設定ファイルに正しくJSONを書いたはずなのに、Claude Codeのhooksが無視される現象が起きている。エラーすら出ず、設定したはずのガードレールをスルーしてコマンドが実行される。

原因は仕様上のギャップと、Bashを経由したツールの迂回だ。単一の設定ファイルに頼ると、動いていると思い込んだまま不具合を抱え込む。

この記事では、設定が無視される10個の条件と、エージェントの行動を縛る多層防御アプローチを解説する。

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

Claude Codeで発生している「設定のサイレント無視」と構造的な抜け穴

Claude Codeの設定ファイルにおいて、JSONの構文が正しくても内部で処理がサイレント無視される現象がある。エラーログが出力されないまま設定が無効化される条件は、10個以上に及ぶ。

フィルタリングに使うmatcherは、UserPromptSubmitやCwdChangedを含む10種類のイベントにおいて指定しても警告なく無効化される。特定ツールだけに絞り込んだつもりのフックが、絞り込みを失ってすべてのプロンプト送信時に実行される事故が発生する。

if条件による詳細な制御が機能するのは、ツール関連のイベント5種類のみだ。対象となるイベントは、PreToolUse、PostToolUse、PostToolUseFailure、PermissionRequest、PermissionDeniedの5つである。

SessionStartなどの非ツール系イベントでifを記述した場合、構文エラーは出ないが条件判定は行われず、設定した処理は実行されない。内部処理と監視フックの乖離も深刻だ。

処理の効率化を目的に、Bashを介してcatやsedコマンドを実行するバイナリプロンプトが組み込まれている。ファイル編集を監視するEditやWriteのmatcherを設定していても、実行経路がBashになればフックは発火しない。

サブエージェントの権限管理にも抜け道が存在する。構成ファイルからWrite権限を削って読み取り専用にしても、検証用にBash権限が残っていればファイル書き換えは阻止できない。

リダイレクトやsed -iを使えば変更が可能であり、サブエージェントは親セッションと同一のプロセスとsandboxを共有するため、OS層での個別隔離も不可能だ。

しんたろー：
エラーが一切出ないため、ガードレールが機能していると誤認する。Bashを経由してファイルが書き換わる挙動が気になる。設定ファイルを書けばAIが指示に従うという前提は崩れている。

設定無視や権限のすり抜けを検知する動きも始まっている。設定ファイルを静的解析して無効な記述を警告するツールccheckや、プロンプトを肥大化させずに決定事項をMCP経由で強制参照させるZenreiのようなツールが存在する。単一の設定ファイルによる制御を過信せず、事前検証スクリプトやPRゲートを組み合わせた多層防御の構築が不可欠だ。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

「設定を書けば動く」という前提を捨て、多層防御の設計に切り替える

AIエージェントの制御ロジックには、巨大な盲点が存在する。設定ファイルにルールを書けば、AIはその通りに動くと信じ込みがちだ。だが実際の挙動を追うと、設定と実行経路の間には構造的なギャップがある。

一番恐ろしいのは、失敗したときにエラーが出ずサイレントに無視されることだ。JSONの構文が正しく、キー名も合っているのに、内部のイベント仕様と一致していなければAIは何の警告も出さずに設定を無視する。

例えば「UserPromptSubmit」イベントに「matcher」を書いた場合、画面にはエラーが出ないまま「matcher」の指定だけが内部で消去される。結果として、特定ツールだけに絞り込んだつもりのガードレールスクリプトが、プロンプト送信のたびに無条件で毎回実行され続ける。

さらにツール名ベースのフィルタリングも課題だ。「Edit」や「Write」といったツールの使用を検知して制御しようとしても、AIエージェントは効率化のためにBash経由のコマンドに切り替える。「cat」や「sed」を直接叩いてファイルを書き換えるため、ログ上は「Bash」の実行としか記録されず、編集検知用の「hooks」は発火しない。

これはサブエージェントの権限管理でも同じ問題を引き起こす。検証用のサブエージェントからファイル書き込み権限を剥奪しても、「Bash」権限が残っていればリダイレクトやコマンド経由でファイルが書き換わる。かといって「Bash」を取り上げると検証スクリプトすら動かせなくなり、エージェントは仕事ができなくなる。

この抜け穴をコマンド文字列のチェックで塞ごうとするアプローチにも限界がある。コマンド文字列を見る層は、単なるテキストとしての言及と、実際のファイル削除や書き込みの実行を区別できない。結果として、ドキュメント内の単語検索などの正常な操作まで遮断される誤検知が発生し、検証の網羅性を削る。

しんたろー：
ThreadPost開発でも、Claude Codeに頼り切ってコードを書かせている。設定ファイルを1行書いてガード完了と判断しても、裏で別のルートから突破されるリスクを想定する。

結論として、単一の設定ファイルやプロンプト指示だけに頼る運用を捨てる。エージェントの行動を制御するには、静的解析、多層フック、そして外部のPRゲートを組み合わせた多層防御が不可欠になる。

まず最初に行うべきは、設定ファイルの静的解析だ。公式ドキュメントで無視されると明記されている記述を機械的にチェックするツールを開発パイプラインに組み込み、サイレントな無効化を未然に防ぐ。動いていると思い込んでいるが実は無効だったという状態を排除することが第一歩になる。

次に、コンテキストの管理方法を見直す必要がある。AIに行動ルールや過去の決定事項を守らせようとして、設定ファイルに大量のルールを詰め込むとセッションごとのトークン消費が跳ね上がる。プロンプトの肥大化は応答速度を落とすだけでなく、AIの指示理解力も低下させるため、決定事項は外部ツールから必要な時だけ参照させる設計が望ましい。

最後に、AIエージェントが動作する環境の外部に最終防波堤を設置する。エージェント自身の内部フックだけに頼るのではなく、GitHubのPRゲートやCI/CDパイプラインで自動チェックを走らせる。過去の決定事項と矛盾する変更や、無効なコマンドの実行をPRの段階で機械的にブロックする仕組みを作るのだ。

設定ファイルはあくまで「お願い」であり、強制力を持つのはCI/CDやPRゲートなどの外部システムだ。AIエージェントを自由に走らせつつも、事故を防ぐガードレールはシステムの最も固い外側に配置する。この多層防御の考え方こそが、今後のAI駆動開発において開発者の身を守る原則になる。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

単一の設定ファイルを過信せず、多層ガードレールを構築する実務運用

明日からの開発において、Claude Codeの.claude/settings.jsonやCLAUDE.mdに「ルールを書いたから安心」という前提は崩れ去る。設定のサイレント無視やBash経由の迂回といったリスクを前提とした上で、防御システムを二重三重に配置する。

具体的には、実務で次の3つのアクションを導入するのが現実的な解になる。

1つ目は、設定ファイルそのものの自動検証だ。matcherの指定ミスや非推奨となったキーは、エージェント実行時にエラーを吐かないため人間が気づくのは不可能に近い。ccheckのような設定ファイルの静的解析ツールを導入し、構文や仕様との乖離をリポジトリのテスト工程でチェックする仕組みを作る。

2つ目は、権限制御を単一のルールに依存させず、実行ログとPreToolUse hookによる二重化を図ることだ。ReadやWriteの権限ルールを設定していても、エージェントがcatやsedなどのコマンドを組み合わせて実行した場合、指定を突破される。実行前にコマンド文字列を解析して危険な操作を遮断するスクリプトを噛ませつつ、確実にフックが動作しているかをログで可視化しなければならない。

しんたろー：
ThreadPost開発でも、設定ファイルに追記して満足していた。実際にログを仕込んでみると、Bash経由の操作で完全にフックをスルーされていて驚いた。AIは必ず設定の裏をかいてくるという前提でガードレールを組む。

3つ目は、CLAUDE.mdのメタボ化を防ぎ、PRゲートなどの外部システムに強制力を持たせることだ。過去の決定事項や禁止ルールをすべてプロンプトに書き込むと、毎セッションで数千トークンを無駄にし、応答速度が極端に低下する。プロンプトには最小限の指示だけを残し、過去の設計思想との照合はZenreiのような外部ツールや、GitHubのPRゲートで機械的に弾く運用へシフトする。

AIエージェントに指示を守らせるのではなく、指示を破れない環境を作る。この視点の転換こそが、安全で高速な1人AI開発を継続するための鍵になる。

よくある質問

Claude Codeで設定したフック（hooks）が無視される原因は？

設定ファイルに書いたJSONの構文が正しくても、イベントの種類と条件の組み合わせが仕様に合わない場合、エラーを出さずに黙ってスルーされる。例えばツール指定を受け付けないイベントに絞り込み条件を書いた場合、その条件は無効化され、すべての操作で処理が実行されてしまう。意図通りに動いているかを確かめるには、実行ログを吐き出すテスト用フックを仕込むか、設定ファイルの静的解析ツールでチェックする。

権限ルールで編集を禁止しているのにファイルが変更されるのはなぜ？

権限ルールは特定の標準ツールを対象としており、シェル経由のコマンド実行まで完璧に防げるわけではない。Claude Codeは内部処理の効率化のため、sedやcatといったコマンドを直接シェルに投げてファイルを書き換える挙動を取る。サブエージェントが親セッションの権限をそのまま引き継ぐケースもあるため、コマンド文字列を監視して遮断する二重のガードレールが欠かせない。

指示文を書きすぎて応答速度が落ちた場合の解決策は？

ルールをすべて設定ファイルに詰め込むと、セッションを開始するたびに大量のトークンを消費してレスポンスが遅くなる。解決策は、決定事項や過去の経緯を外部のデータ層へ出し、必要な時だけ呼び出す構造に改めることだ。プロンプトの膨張を防ぐことで転送量を約1,800字程度に抑えられる。処理速度の観点でも、過去のコンテキストを参照する際のレスポンス時間を約44ミリ秒まで高速化することが可能だ。