23 知識の保存先の使い分け — どこに何を書くか
💡 章の核: memory/rules/hookClaude Codeの特定のタイミング（ツール実行前後・セッション開始時等）で自動処理を差し込む仕組み。「保存前にチェック」「終了時に記録」等を機械的に強制できるsの3層は強度とコストが比例する。事故の頻度と被害で選ぶ。
Claude Codeを使い込むと「この知識、どこに保存すればいいのか？」という問題に必ずぶつかる。保存先を誤ると、知識は埋もれるか、あるいは毎回の読み込みコストとして払い続けることになる。本章では代表的な保存先を3層に整理し、判断フローを示す。
この章は Claude Code 機能ベースの3層（memory / rules / hooks）を扱う。プロジェクト知識ベース（SSOT）側の保存先（決定記録・タスク管理）は ssot-guide「知識の保存先の使い分け（SSOT層）」 に分離している。
3層の全体像
| 層 | 正体 | 読まれるタイミング | 向いている知識 | コスト |
|---|---|---|---|---|
| memory | Claude Code公式のauto-memory（~/.claude/projects/<path>/memory/） |
セッションClaude Codeの1回の対話単位。起動から終了までの会話と作業状態のこと。長く使うと内容が混ざるため、トピックの区切りで新セッションに引き継ぐ運用をする開始時に自動読込 | 個人の失敗の直し方・教訓・好み | 最小（ファイル1個=1事実） |
| rules / CLAUDE.md | CLAUDE.mdが@includeする共有ルールファイル |
毎レスポンスに毎回読込 | 行動方針・判断ゲート（「〜する時は〜せよ」型） | 高（行数ぶん毎回課金・全タブで読まれる） |
| hooks | PreToolUse等の設定で登録するスクリプト自動実行できる小さなプログラム。手順を書いたテキストファイルの形をしている | 該当ツール実行のその瞬間に機械実行 | LLMが忘れても防ぎたい事故の機械的防御 | 最大（実装設計や仕様を、実際に動くコードに作り込むこと。「実装済み」＝コードとして完成している状態+テスト+設定登録） |
それぞれの層の性質
memory — 「私的失敗の直し方」を置く
- 1ファイル=1事実・frontmatterの
descriptionで回収時に判定される - セッション開始時に毎回読まれるため、軽く・具体的であるべき
- 向いている例: 「commit前にstagedの差分変更前後の違い。git diffのように「何がどう変わったか」を示すもの行数を確認する」「bashバッシュ。Linux等で使われる標準的なシェル（コマンド入力を受け付ける程序）の名前。シェルスクリプトを書く時の定番の
$HOMEはWindows側に化ける」 - 向いていない例: 恒久的な方針（→rulesへ）・「なぜそう決めたか」の経緯（→プロジェクトの決定記録へ）
rules / CLAUDE.md — 「毎回の方針」を置く（ただし肥大化に注意）
- ここに書いたことは毎セッション・全タブが読む。1行追加=全セッションのコンテキストコスト増
- 書くべきは判断ゲート型の短い方針:「検索結果の件数を根拠に結論を出す前に中身を目視せよ」等
- 防衛力の限界にも注意: ルールが存在してもLLMが読み飛ばす事故は起こる（実例: 「git add時のdiff確認」ルールがあったのに巻き込み事故が2回発生）。方針を強制したいならhooksとの二重防御を検討する
hooks — 「機械的に止めたい」を置く
- LLMが知識を読んでいなくても、該当操作の瞬間に機械が介入できる唯一の層
- block（阻止）/ ask（人間に確認を求める）/ warn（警告表示）の3段階から選べる
- 向いているのは「頻度は低いが、一度起きると被害が大きい」型の事故
- 実例: サブディレクトリフォルダのこと。ファイルを階層的に整理する入れ物。Linux系ではフォルダをディレクトリと呼ぶのが普通で
git initすると上位リポジトリに静かに吸着する事故 → 吸着検知時にaskで確認を強制するhook+層1ルール1行の二重防御で対処 - 注意: 全コマンドターミナルに入力してコンピュータに与える一行の指示。lsやcdのように『プログラム名+補足指定』で構成されるを監視すると正常な作業まで誤爆する。発火条件は「危険が高まる特定の操作」に絞る
判断フロー（書き込む前に自問する順）
- LLMが忘れても機械的に防ぎたい事故か？ → はい: hooks（頻度低×被害大なら特に）
- 毎回の行動方針として全セッションに読ませたいか？ → はい: rules / CLAUDE.md（1〜2行に凝縮）
- 個人の失敗の直し方・環境固有の教訓か？ → はい: memory
- 「なぜそう決めたか」の経緯や、生きているタスクか？ → プロジェクト知識ベース側（→ ssot-guide参照）
読み出すとき（事故調査・疑問解消）
- 「なぜこうなった」を探す → 決定記録の検索（ssot-guide側）
- 「この操作を間違えやすい」を探す → memory
- 「機械的に何が防がれているか」を探す → hook一覧・設定ファイルプログラムの動作を決める設定値を書いたファイル。コード本体を書き換えずに、設定だけ変えられるようにする
💡 一言でいうと: 「忘れないでほしいこと」はmemory、「毎回の方針」はrules、「忘れても機械が止める」はhooks。この3層は強度とコストが比例するので、事故の頻度と被害で選ぶ。
💡 一言: memoryは「守る気があれば守るLLM用の覚え書き」。機械で止めたい事故だけがhooks。
💡 章の落とし所: 「忘れないで」はmemory・「毎回の方針」はrules・「忘れても機械が止める」はhooks。