配布資料 32構築年表 第3章 — 規律の共進化

全数値は題材プロジェクトの git 履歴（origin/master・2026-07-17 時点）の実測。

CLAUDE.md も rules も hooks も、最初に設計されたものではありません。

開発と並走しながら、事故のたびに AI 自身に実装させて溜まっていきました。 そしてこの「規律の機械化」が、後の開発・テスト・運用の自動化を可能にした前提条件になっています。

規律が機械で守られているから、人間が見ていない時間帯にも AI に仕事を任せられます。 逆に言えば、そこができていない状態で自律度だけ上げると、上げた分だけ事故が増えます。

この章は、その4ヶ月分の実測です。

1. 数値で見る成長曲線

CLAUDE.md は増えて、減って、また増えた

一番大事なのは「増やした日」ではなく「減らした日」だと思っています。

フックは3.5ヶ月で24本、全て稼働中

削除された hook はゼロで、累積がそのまま現存しています。 一度入れた規律を、後から外す必要がなかったということでもあります。

統治コードは製品コード41万行の0.9%

製品コードは約41万行です。統治コードはその約0.9%にあたります。

そしてその約4割が「散文のルール」ではなく「実行可能なシェルによる強制」になっています。 この 0.9% の投資が、9ヶ月・5,850コミットの生産を支えました。

2. 五つの時代

第1期: 散文の時代（3月）

CLAUDE.md 15行から始まり、指示を書き足すたびに膨らんで月末に477行になりました。

hooks はゼロです。

ルールは散文で、守られるかどうかは AI の読解と記憶に依存していました。 書けば守られると思っていた時代です。

第2期: アーキテクチャ転換（4月2日）

504行の単一ファイルを47行に凝縮し、詳細を .claude/rules/ 7本に分散する「規律のリファクタリング」を実施しました。

CLAUDE.md は毎セッション必ず読まれる唯一の文書だから、絶対遵守事項と入口だけに絞ります。

ルール自体にアーキテクチャ——正本の階層——が導入された転換点になります。

第3期: 最初の hook（4月6日）

最初の hook は、ブラウザテスト完了フラグがなければコミットをブロックするものでした。

これは独立した「hook 整備プロジェクト」で作られたのではありません。 マージ事故で消失したコード468行を復元する、まさにその PR の中で再発防止として同梱されました。

翌日にはスカッシュマージ禁止が明文化されます。

「事故 → 復元 → 同じ PR で再発防止の機械化」。 以後3.5ヶ月続くパターンの初回がここにあります。

第4期: 介入タイミングの多層化（4〜6月）

hook の配線イベントは、次の順で増えました。

PreToolUse（4月・コミット前ゲート）→ PostToolUse（4月・直後リマインド）→ Stop（5月・ターン終了の事後検知＝「やります」と言って止まる AI を差し戻す）→ SessionStart（5月・冒頭の規律注入）→ UserPromptSubmit（6月・毎ターン再注入）

「行動の直前で止める」から始まり、「終わり際に検知する」「始まりに教え込む」「毎ターン思い出させる」へ。

同じ規律を複数のタイミングで守る多層防御に進化していきました。 出力書式の問題は、初発から27日で三層化が完成しています。

第5期: 契約と統治（7月）

タスクモード契約（「確認して」と「実行して」の分離を hook 3本で強制）、本番デプロイの絶対ガードと時間帯制限、staging デプロイの頻度ガード。

もはや個別の作業規律ではありません。 人間と AI の権限関係そのものを機械化する段階になっています。

新しい指示から当日中にルールと hook 一式が実装されています。

3. 規律のコードを書いたのも AI 自身だった

規律の実装者は AI 自身です。git 履歴上の証拠を4つ挙げます。

1. 機能と同じフローで実装されています。 hook 追加はすべて番号付き・PR 経由で、しばしば製品コードと同一コミットに入ります。事故修正 PR に再発防止 hook が同梱されます（コード復元468行 + hook 2本が1つの PR）。規律の実装が feat プレフィックスでコミットされます。規律は機能と同格の成果物として扱われていました
2. リードタイムが極端に短いです。 事故から enforcement 化は同日〜翌日が標準でした。書式ミス事故は当日中に2段階（検知 hook → 5時間後に根本治療 hook）。新しい指示（タスクモード契約・本番時間帯）も当日中にルールと hook になりました。AI に実装させるからこの速度が出ます
3. 規律自身が規律に従っています。 デプロイ頻度ガードの hook 追加コミットは、CLAUDE.md・rules・運用文書を同時更新しています。「doc は同一コミットで」という規律を、規律の実装自身が守っている自己言及の構造です
4. 人間の役割は変わりません。 指示（原則）を与え、事故を認定し、承認します。シェルを書くのは AI です。第2章の「人間の振る舞い8型」がここでも成立します

ついでに書いておくと、この教材の再現環境（Keihi）自体も同じ手法で作られています。 AI に hooks 込みで構築させ、動作テストまでさせました。再現手順は「もう一度」やってみせているだけです。

4. 自動化の上限は、規律の機械化の水準で決まる

「開発・テスト・運用の自動化に大きく貢献した」という実感の因果を分解します。

一般化すると、こうなります。

自動化の上限は、規律の機械化の水準で決まります。

散文のルールしかない状態で AI の自律度を上げると、上げた分だけ事故が増えます。 hook で「破れない」状態を作ってから自律度を上げると、人間の監視コストが固定費になり、生産量だけがスケールします。

これが「統治コード0.9%で41万行」の構造です。

5. 自分のプロジェクトでどう育てるか

軌跡から抽出した、規律インフラの育成順序を置いておきます。

1. CLAUDE.md 1枚から始めます。 15行でいいです。最初から作り込まないでください。ここも作り込んでいません
2. 肥大したら分割します。 目安は数百行です。「毎回必ず読ませたい原則」と「該当作業時だけ読ませたい詳細」を分けます
3. 事故が起きたら、その修正 PR の中で再発防止を機械化します。 独立した「hook 整備プロジェクト」を立てません。事故の記憶が新しいうちに、同日から翌日で
4. 介入タイミングは段階的に増やします。 まずコミット前ゲート1本。破られ方を観察して、事後検知・冒頭注入・毎ターン注入を足します
5. バイパスは必ず「明示トークン + 理由の記録」付きで作ります。 例外を許さない hook は現実に負けて無効化されます。黙って通れる抜け道だけを塞ぎます
6. 規律の実装も AI にやらせます。 人間は原則と事故認定だけです。速度と網羅性が段違いになりますし、AI が自分の失敗パターンを自分で条文化するので再現精度も上がります

手を動かすなら

• この章のフック誕生表から3本を選び、「事故 → ルール → hook」の因果を事例カードと突き合わせて説明してみてください
• Keihi の hooks 無効ブランチで事故を再現し、その場で hook を通しで実装して、有効化したら同じ操作がブロックされることを確認してみてください
• 自分のプロジェクトで「最初に機械化すべき規律」を1つ選び、hook の疑似コード（検知条件・ブロック/警告の別・バイパストークン）を書いてみてください