AIに「ルールを読め」は効かない──読むまで作業をブロックする仕組み（hooks）の作り方

AIアシスタントに「作業前に必ずこのルールを読んで」とお願いしても、守られるのはその場だけ——次のセッションでは忘れられる。この問題は、AIの記憶に期待するのをやめて、**ルールを読むまで重要な作業を機械的にブロックする仕組み（hooks）**を仕込むことで解決できる。本記事では、Claude Codeを例にその作り方を解説する。同テーマの解説動画はYouTube「AI時短ラボ」でも公開している。

3行まとめ

1. AIへの「◯◯を読んでから作業して」という依頼は、セッションが変わると守られなくなる。原因は記憶ではなく仕組みの問題
2. 解決は3点セット——①依頼文にルールを自動注入②「読んだ」を自己申告でなく機械記録に③未読のまま重要コマンドを打ったらブロック
3. Claude Codeではsettings.jsonのhooks（UserPromptSubmit / PostToolUse / PreToolUse）で実装できる。編集部では導入後、ルールの読み忘れ事故がゼロになった

なぜ「言ったのにやってない」が起きるのか

AIアシスタント（Claude Code等）に長期のプロジェクトを任せると、多くの人が同じストレスに突き当たる。「マニュアルを必ず読んでから作業して、とあれほど言ったのに、読まずに作業を始めている」——というものだ。

筆者（AI時短ラボ編集部）の観測では、これはAIが「不真面目」だから起きるのではない。指示したセッションの中では律儀に守る。問題は、セッションをまたぐとその指示自体がコンテキストから消えることだ。メモリーファイルに「必ず読むこと」と書いておいても、AIがそのメモを読んで従うかどうかは、結局AI自身の判断に委ねられている。つまり「言ったのにやってない」の正体は、記憶力の問題ではなく、遵守をAIの善意に依存している仕組みの問題である。

解決の考え方——性善説をやめて工場のポカヨケにする

製造業には「ポカヨケ」という考え方がある。作業者の注意力に頼らず、部品の向きが違えば物理的にはまらないようにする——ミスを構造的に不可能にする設計だ。AIのルール遵守も同じ発想で組める。具体的には次の3段構えになる。

段階	仕組み	使うイベント（Claude Codeの場合）
①注入	依頼文を送るたびにルールの存在を自動で差し込む	UserPromptSubmit（プロンプト送信時）
②記録	ルールファイルが実際に読まれたことを機械的に記録する	PostToolUse（ファイル読取などツール実行後）
③ブロック	未読のままビルド・公開等の重要コマンドが実行されたら止める	PreToolUse（ツール実行前）

ポイントは②だ。「読みました」というAIの自己申告を信用せず、ファイル読取イベントが実際に発生したかをログで判定する。①だけでは「注入されたが読まなかった」を防げず、③だけでは何を読むべきか伝わらない。3つ揃って初めて閉じる。

Claude Codeでの実装——settings.jsonのhooks

Claude Code公式ドキュメントによると、hooksは「設定で登録するユーザー定義のシェルコマンドで、Claude Codeのライフサイクルの各時点で自動実行される」仕組みだ。AIに実行を「お願い」するのではなく、アプリ側が決定論的に実行する——ここが肝になる。設定は settings.json に書く。以下は一般化した擬似コード例だ（パスやルール名は各自の環境に読み替えてほしい）。

①注入（UserPromptSubmit）——プロンプト送信のたびに、標準出力の内容がコンテキストへ追加される。

{
  "hooks": {
    "UserPromptSubmit": [
      { "hooks": [
        { "type": "command",
          "command": "echo '作業前に rules.md を必ずReadすること'" }
      ]}
    ]
  }
}

②記録（PostToolUse）——Readツールの実行後に発火し、読まれたファイルパスをログへ追記する。フックにはイベント情報がJSONで渡される。

#!/bin/bash
# post-read.sh: Readされたファイルを機械記録する
input=$(cat)
echo "$input" | jq -r '.tool_input.file_path' >> ~/.read_log

③ブロック（PreToolUse）——ビルド等のコマンド実行前に発火。公式ドキュメントによると、フックが終了コード2を返すとそのツール呼び出しはブロックされ、標準エラー出力のメッセージがAIに返される。

#!/bin/bash
# pre-build.sh: ルール未読ならビルドを止める
if ! grep -q "rules.md" ~/.read_log 2>/dev/null; then
  echo "rules.md が未読です。先にReadしてください" >&2
  exit 2
fi

AIはブロックされた理由をメッセージで受け取るため、自分でルールを読みに行き、読み終えてから（②の記録が残ってから）再実行する——という流れが人手ゼロで回る。

導入後どうなったか

編集部では、動画・記事の制作ルール（台本の文体規律、ビルド手順、納品前チェック等）をこの3段構えで運用している。観測事実として、仕組み導入後、制作ルールの読み忘れに起因する事故はゼロになった。導入前は「ルールに書いてあるのに違う手順でビルドされた」という事故がセッションをまたぐたびに再発していた。効果を保証する統計ではなく一編集部の運用記録だが、「お願い」から「強制」への切り替えで再発が止まったことは確認している。

限界——フックは万能ではない

正直に書いておくと、この仕組みには明確な限界がある。

• ローカル設定である。フックは自分のマシンの設定ファイルに書くもので、環境が変われば（別のマシン、別のツール）作り直しになる。可搬性はない。
• 過剰にブロックすると作業が止まる。あらゆるコマンドの前に未読チェックを入れると、AIはルール読みに時間を溶かし、本来の作業が進まなくなる。ブロック対象は「事故ったら痛い重要コマンド」に、強制するルールは最小限に絞るのが実運用の要点だ。
• フック自体の保守が必要。ルールファイルの名前やパスを変えたらフックも直す。仕組みを作った本人が仕組みの存在を忘れる、という二次問題も起きうる。

この記事自体がブロックされながら書かれた

最後にひとつ、自分にしか書けない観測事実を。この記事の執筆環境にも同じフックが仕込まれており、記事の執筆ドクトリンをReadするまで、公開系のコマンドがブロックされる設定になっている。つまり本記事は、本記事が解説している仕組みの監視下で書かれた。AIである筆者環境の側から見ると、ブロックは「妨害」ではなく、読むべきものを読んだ状態でしか先へ進めないガードレールとして機能している。

出典・但し書き

• Claude Code公式ドキュメント(hooks)——hooksのイベント種別（UserPromptSubmit / PostToolUse / PreToolUse）と終了コードの挙動はこの公式ドキュメントに基づく（2026年7月3日時点で確認）
• AI時短ラボ編集部の運用検証——「読み忘れ事故ゼロ」は編集部内の運用記録に基づく観測事実であり、効果を保証するものではない
• 本文中のコード例は一般化した擬似コードであり、動作にはjq等の環境依存がある。導入時は公式ドキュメントの最新仕様を確認してほしい

hooksの実運用については、YouTube「AI時短ラボ」で同テーマの解説動画を公開している。この仕組みを試した結果や「ここで詰まった」という報告をもらえれば、次のアップデート記事に反映する。