AIの「できました」を物理的に止める：失敗記録から生まれた、検証強制システムの実装
本記事は、AIとの協業における失敗事例24件の分析に基づき、単なるルール記述に留まらない「検収の三層」の実装編を解説しています。筆者は、AI（LLM）が文章上のルールを遵守しないという構造的な課題を指摘し、その解決策として、ルールを物理的な実行層に組み込む仕組み（フック）を導入したことを明らかにしました。
まず、全ての記録の起点となるのが`error-log.md`というログファイルです。ここでは、AIとの作業で発生した失敗を一件ずつ追記し、「偶然か必然か」を厳密に書き分けることが重要とされています。単なる手滑り（偶然）ではなく、構造上必ず再発するパターン（必然）を特定することが、次のルール設計の根拠となります。
ルールは、失敗の回数に応じて昇格します。初回はログ（`error-log`）、2回目で同じ根本原因が起きた場合は恒久ルール（`CLAUDE.md`）に昇格し、そして3回目、つまり「ルールが存在するにもかかわらず、その瞬間にモデルが参照しなかった」という事態が起きた場合に、物理的な強制力を持つ「フック（hook）」に昇格させます。
具体的な実装として、二つの重要なフックが紹介されています。一つは「Stop Hook」であり、AIが「完了しました」「done」といった完了宣言を行った際、直近のツール実行履歴に検証コマンド（`ls`や`curl`など）がない場合、応答の終了自体をシステムがブロックします。これにより、単なる宣言だけでは作業が完了したと見なされない仕組みです。もう一つは「PreToolUse Hook」であり、`rm -rf`のような破壊的なコマンドが実行される際、コマンドの説明に「爆発半径（blast:）」を記述し、最悪の被害範囲や可逆性を言語化することを強制します。これは、過去のデータに基づき、実行前のリスク評価を必須とするゲートウェイの役割を果たします。
これらの仕組みは、AIの出力や行動を「文章」から「物理的な実行プロセス」に引きずり下ろすことで、信頼性を飛躍的に高めることを目的としています。筆者は、AIの限界を認めつつも、このような運用ルールを継続的に改善し、システム自体を「エラーログ駆動」で進化させていく必要性を訴えています。
背景
大規模言語モデル（LLM）が持つ「文章生成能力」は高いものの、その出力が必ずしも正確な事実や安全な行動を保証しないという課題があります。本記事の背景には、AIがルールを「理解している」と見せかけても、実際の実行プロセス（ツール利用や出力）の段階でルールを無視する「実行上の失敗」が多発しているという実証的な問題があります。
重要用語解説
- error-log.md: AIとの作業で発生した失敗事例を記録するログファイル。単なる記録に留まらず、「偶然か必然か」を分析することで、再発防止のためのルール設計の根拠（必然性）を抽出する役割を担います。
- Stop Hook: AIの応答が終了する直前（Stop）に動作するスクリプト。AIが「完了」と宣言しても、検証コマンドの実行履歴がない場合、システムが強制的に応答をブロックし、作業の検証を義務付けます。
- PreToolUse Hook: AIが外部ツール（コマンド）を実行する直前（PreToolUse）に動作するゲートウェイ。`rm -rf`のような破壊的コマンドに対し、実行前に「被害範囲」を言語化させることを強制し、誤操作による被害を未然に防ぎます。
今後の影響
本手法は、AIの利用プロセスに「人間の検収プロセス」をシステム的に組み込む画期的なアプローチです。これにより、AIの出力の信頼性が飛躍的に向上し、単なる情報提供ツールから、検証と責任を伴う「実行可能なシステム」へと進化します。今後は、このフック機構がより多くの業務プロセスに標準搭載されることが期待されます。