Claude Code のフックに空いた穴が、どれだけテストしても出ず公式ドキュメントに書いてあった

Claude Codeには、コマンド実行の直前に割り込んで条件次第で実行そのものを止められる「フック」という拡張機能がある。自分も以前、危険なコマンドを検知するフックを作り、24項目の敵対的なテストケースで全部合格させたため、「これで安全だ」と思い込んでいた。ところが公式ドキュメントを読み直していて、その安心を土台から揺さぶる記述に出会った。どれだけロジックを鍛えても、テストでは絶対に見つからない種類の穴が、そもそもの仕組みの側に空いていたのだ。

その穴の正体は「応答時間」だった。フックにはtimeout（応答を待つ上限の秒数）があり、command / http / mcp_tool タイプのフックがこの上限に達すると、フックはキャンセルされ、何も判定を下さない。ここからが重要だ。「判定できなかったから、実行をブロックする」のではなく、「何も言わずに通常の権限フローを通して、そのまま実行が進む」という形で失敗する。つまり、危険なコマンドを検知して止めるはずのフックが、ネットワークが遅い、ディスクI/Oが重い、たまたま一回重かったというだけで、何ごともなかったかのように素通りさせてしまう。これはバグではなく仕様として明記されている。マッチ条件の側（ifフィルタ）にも同じ性質がある。Bashコマンドの構文解析に失敗すると、パターンマッチに関係なくフック自体が実行されてしまう。「わからなければ通す」という設計思想が、フックの土台のあちこちに埋め込まれているのだ。

この発見は、自動化やセキュリティ対策を考える上で一つの教訓を与える。ロジックがどれだけ正しくても、それを取り巻く土台が「わかりません、では通します」という設計だと、自作の検知ロジックでは絶対に埋められない穴が存在する。公式の代替案は明確だ。「絶対に止めたい」なら、フックのような気づきの層ではなく、権限管理システムの根本レベルで拒否するべきだということだ。テストで見つかるバグと、テストでは絶対に見つからない穴は別のものなのだ。