AIが危険なコードを書く前に止める｜PreToolUseフックの実力と2つの落とし穴【AI活用検証vol.100】

AIがコードを書く速度に、人間のセキュリティレビューは追いつきません。「書かれた後に人が確認する」モデルでは間に合わない——これがAI駆動開発の構造的な課題です。

この検証では、コードが書かれる直前にパターン警告を出すフックを導入し、実際にどう動くかを8ケースで確認しました。そして分かった仕様の落とし穴に対処するため、フック自体を改造しています。

この検証の概要

結論：三層防御のうち、実装中の層が埋まった

この検証の狙いは、既存の防御体制に欠けていた層を埋めることです。

「リアルタイム × オンデマンド × CI」の三層防御という構成です。それぞれ検知できるタイミングと粒度が違います。

ブロックの仕組み

動作確認で判明した実装仕様です。

ブロック方式はexit code 2 + stderr出力。Claude Codeがstderrを「ガイダンス」として読み、ツール実行を中断する設計になっています。

検証した8ケースの結果は次のとおりです。

ケース6が興味深い挙動です。ファイルパスベースの検出が機能し、CIワークフローの配置先では内容に依らず警告が出ます。「このディレクトリに書くこと自体がリスク」という判断です。

落とし穴①：2回目以降が静かに通る

ケース7で判明した仕様です。

警告はセッション内・ファイル内・ルール内で1回だけ表示されます。同じ警告を連続して見せないUX配慮ですが、裏を返すと問題になります。

連続編集中は、2回目以降の同種違反が素通りします。

AIが同じパターンのコードを複数箇所に書いた場合、最初の1箇所しか警告されません。「警告が出ていない＝安全」ではないという状態になります。

落とし穴②：ログファイルが警告ログではない

もう1つの発見です。

出力先として指定されているログファイルは、警告ログではありませんでした。ログ書き込み関数はJSONパース失敗時にしか呼ばれない実装で、通常運用ではファイルが作られません。

警告履歴を残したいなら、フック側にログ出力を1行追加するカスタマイズが必要です。

ファイル名から役割を推測すると、誤った理解のまま運用することになります。実装を読んで確認する価値がある部分でした。

改造：監査ログを残す

2つの落とし穴への対処として、フックスクリプトを改造しました。

設計判断

• 記録するのはメタ情報1行のみ（警告本文ではなく セッション / ツール / ファイル / ルール）——grepしやすく、肥大化しない
• 重複抑制のチェックより前にログ書き込み——stderr警告は抑制されてもファイルには全件残る
• 書き込み失敗は握りつぶす——ログ周りのトラブルで開発を止めない
• 一時ディレクトリではなくプロジェクト同梱——チームに配布したとき、clone直後から監査証跡が同じ場所に出る

2つ目が本質的な対処です。「画面では1回・ログには全件」の二段運用にすることで、UX配慮を保ちながら見落としを防げます。

ログの出力先は .gitignore 済みのため、リポジトリは汚れません。

誤検知：この検証ログ自体がブロックされた

実運用上の重要な注意点です。

この検証ログ自体が、フックに2回ブロックされました。

原因は明確です。危険なAPIの「解説目的の文字列」にもパターンマッチが反応するためです。セキュリティについて文章を書こうとすると、危険な関数名を書くことになります。

対処はドキュメント用途では識別子をバッククォート等で分断することです。

パターンマッチによる検知は、コードと文章を区別できません。ドキュメントやテストフィクスチャ内の文字列にも反応する前提で運用する必要があります。

責務分担を明確にする

この検証で整理された役割分担です。

3つ目が重要です。フックの対象はファイル編集系ツールのみで、コマンド実行系はカバーしません。そちらは別の仕組みで止める必要があります。

1つの仕組みで全部を防ごうとすると、穴に気づけません。何がどこまでを担当するのかを明文化しておくことが重要です。

配布性：cloneするだけで同じガードが効く

この構成のもう1つの利点です。

フックスクリプトをプロジェクトに同梱し、設定から参照する形にしました。チームメンバーがcloneするだけで、同じガードレールが効きます。

個人環境にインストールする方式だと、「誰がどの設定を入れているか」がばらつきます。プロジェクトに含めれば、全員が同じ基準になります。

残っている検証項目

• パターン拡張（日本語コメントの禁止表現、チェックリスト準拠）
• 実セッションでのフック表示確認
• フック実行による編集の体感的な遅延（レイテンシ）
• 誤検知率の定量評価

よくある質問

なぜ事後レビューでは足りないのですか？

AIがコードを生成する速度に、人間のレビューが追いつかないためです。実装中に検知できれば、危険なコードが書かれた時点で止められます。

警告が出なければ安全ですか？

そうとは限りません。警告はセッション内・ファイル内・ルール内で1回だけ表示される仕様のため、連続編集中は2回目以降の同種違反が素通りします。ログを全件記録する改造で対処できます。

ドキュメントを書くときに邪魔になりませんか？

実際にブロックされます。危険なAPIの解説文字列にもパターンマッチが反応するためです。識別子をバッククォート等で分断する対処が必要です。

これだけで十分ですか？

不十分です。フックの対象はファイル編集系ツールのみで、コマンド実行系はカバーしません。オンデマンド監査とCIゲートを含めた三層で構成する必要があります。

まとめ

• AI駆動開発では事後レビューが間に合わない。実装中の検知層が必要
• ブロックはexit code 2 + stderr出力で実現されている
• 警告はセッション・ファイル・ルールごとに1回だけ。2回目以降の同種違反は素通りする
• 指定されたログファイルは警告ログではなくエラーログ専用だった。実装を読んで確認する価値がある
• 対処は「画面では1回・ログには全件」の二段運用
• 解説目的の文字列にも反応する。ドキュメント執筆時は識別子を分断する
• フック・監査エージェント・denyルールの責務分担を明文化する。1つで全部は防げない
• プロジェクト同梱にするとcloneするだけで全員に同じガードが効く

ガードレールは、入れただけでは機能しません。どこまで検知し、どこを見逃すのかを実際に試して確認すると、必要な補強が見えてきます。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。