成長規律と逆 ratchet
本連載は執筆時点のハーネス実環境 (設定ファイルの内容、実行記録、ファイル数) を素材にした記録です。ハーネス本体は公開後も改修が続いているため、引用したファイル内容や個数、手順は現在の実体と異なる場合があります。本連載の主眼は個々の値ではなく設計の考え方 (5 関心分離、検証ゲート、成長規律) にあります。
本章は、ハーネスの再肥大化を防ぎ、成長を規律の範囲内に収め続ける 成長規律 を扱います。
第 1 章 で扱ったように、再構築前のハーネスは「追加が容易、削除が困難」という非対称性で数百ファイル規模まで膨張しました。本章で扱うのは、この非対称性を逆向きに付け替える規律群です。
新ハーネスでは 5 つの規律を運用しています。
| 規律 | 効くタイミング | 担当 |
|---|---|---|
| usage-driven 追加 | 新規 facet 追加検討時 | 人間 (筆者) + AI |
| サイズ上限 | 既存 facet 改修時 | 1 ファイル ≤ 上限 |
| 1 ファイル 1 関心 | 全 facet 設計時 | 関心境界 |
| 逆 ratchet | 月次 /harness-prune | 30 日参照ゼロ等を反転承認で削除 |
| hooks は実証後 | hook 追加検討時 | orphan hook 禁止 |
それぞれを掘り下げ、実運用での発火例を併せて紹介します。
7.1. 規律 1: usage-driven 追加
規律: 同じ指示を人間が手で 2 回 出して初めて facet 化を検討する。予防的追加は禁止。
再構築前の追加プロセスは「失敗が観測されたら即 facet 追加」でした。これだと:
- 1 度の失敗で 1 ファイル追加 → 累積で膨張
- 「いつか役立つかも」を根拠にした予防的追加が止められない
- facet を追加した後で「実は不要だった」と気づいても削除動機が薄い
新ハーネスでは、追加の条件を 2 回ルール に絞ります。
- 1 回目の指示: 人間 (筆者) が直接書く / AI が個別対応する (facet 化しない)
- 2 回目の指示: 同型の指示が再度発生したら、facet 化を検討
- 検討時の判定: 「3 回目以降も発生する見込みがあるか」「他の facet で吸収できないか」
これにより、累積膨張を構造的に抑えます。実例として、2 回ルールを発火させ追加した facet の一部を紹介します (網羅的な一覧ではなく、追加パターンの多様性が伝わる代表例です)。
| 追加された facet | 観測パターン | 採否 |
|---|---|---|
hooks/check-git-commit-gate.sh | 並行セッションが明示指示なしに git commit した事例 | 採用 (例外条項「Computational Sensor は bootstrap 同時許容可」) |
rules/search-before-coding.md + hooks/check-pre-edit-search.sh | replace_all で意図外箇所まで置換した事例が 2 度。同時に「コード書き込み前の grep 接地」規範を 2 度指示 | 採用 (規範 + log-only Computational Sensor のペア追加) |
rules/adversarial-review.md + agents/devil-advocate.md | 提示前に main agent が事前 critique を入れ忘れた事例 2 度 | 採用 (規範 + agent ペア追加) |
knowledge/coding-accuracy-2026.md (Kuro 裁量) | best practice 参照プールを 2 度組み立てた | 採用 (Knowledge は AI 裁量で追加可、規範本文化前に context7 で再裏取り) |
重要なのは、これらが予防的追加でなく後追い的追加である点です。一見「最初から入れておけば良かった」と思えるような規範でも、bootstrap 時点では入れず、実際に同型の事例を 2 度観測してから facet 化しています。先回りで規範を作ると再び同じ肥大化に突入するためです。
予防的追加 (= 「将来こういう失敗があるかも」で先に書く) は禁止です。失敗が 1 回でも観測されない facet は、想像上のリスクであって実害ではないためです。
規範級 vs Knowledge の承認境界
usage-driven 追加には承認境界があります。
- 規範級 (CLAUDE.md / rules / agents): 人間 (筆者) 承認必須
- Knowledge: AI 裁量で追加可
これは、規範級は走行時の挙動を変える破壊力があるためです (= silent に挙動が変わると、人間側がデバッグできない)。Knowledge は記述的事実で挙動を変えないため、人間承認なしで追加できます。
実例: ~/.claude/repos/<repo>/CONTEXT.md に新しい用語を追加するのは AI 裁量で OK。一方、rules/<新 Policy>.md を追加する場合は AskUserQuestion で人間承認を取ります。
7.2. 規律 2: サイズ上限
規律: ファイル種別ごとにサイズ上限を設定し、超過した場合は分割でなく削減する。
サイズ上限 (行数) は次の通りです。
| ファイル種別 | 上限 | 例外 |
|---|---|---|
CLAUDE.md | ≤100 | — |
rules/*.md (Policy) | ≤30 | — |
agents/*.md (Persona) | ≤40 | gating agent (plan-reviewer / auditor) は ≤60 |
skills/*/SKILL.md (Instruction) | ≤80 | autodev は ≤100 |
output-contracts/*.md | ≤30 | — |
運用してみると、rules/ agents/ skills/ の各ファイルはこの上限内に収まり続けています。usage-driven 追加で rules は増えましたが、各 facet が「1 ファイル 1 関心」に絞られているため、新規追加分もすべて上限内に収まりました。「Policy が増える = 各ファイルが膨れる」関係が断ち切れているのが、サイズ上限と usage-driven 追加が両立できている根拠です。
超過時は分割でなく削減
サイズ上限を超えたとき、「分割」(= 2 ファイルに割る) が直感的に思える対応です。しかし新ハーネスでは削減(= 中身を減らす) を選びます。理由は次のとおりです。
- 分割はファイル数を増やすため、規律 1 (usage-driven 追加) と矛盾する
- 分割すると参照が散り、subagent が両方を読み忘れるリスクが上がる
- 「30 行に収まらない」のは、関心が複数混じっている (1 ファイル 1 関心違反) か、冗長 (削れる) かのいずれか
実例: 再構築前の rules/git-workflow.md はそれなりの分量がありました。再構築時に、
- commit 規律と worktree 規律と branch 規律が混在している (1 ファイル 1 関心違反) と判定
- ただし全て git 関連なので分割せず統合 (=
rules/git.md1 ファイルに統合) - 各 section を section ヘッダで内部分割し、冗長な「常識的注意書き」(= 別 Policy で書かれている内容) を削除
- 結果として半分以下の分量まで圧縮
7.3. 規律 3: 1 ファイル 1 関心
規律: Policy に手順を書かない / Instruction に規範を書かない / Knowledge は記述のみ。
これは 第 2 章 (Faceted Prompting) で扱った関心境界の運用版です。
新ハーネス運用上の指針として、次の判定を都度行います。
- Policy ファイル (
rules/*.md) を改修するとき: 手順を書きそうになったら、それは Instruction (skills/) へ - Instruction ファイル (
skills/*/SKILL.md) を改修するとき: 規範を書きそうになったら、それは Policy (rules/) へ - Knowledge ファイル (
knowledge/orrepos/<repo>/) を改修するとき: 手順や規範が混入しそうになったら、別 facet へ移す
実例: 本連載執筆中に rules/git.md 改修を検討した際、「git add <file> で個別指定する」は規範 (= 「混入を防ぐ」目的) だが、「Bash 直接 commit では 🤖 Generated with [Claude Code] を HEREDOC 末尾に明示する」は手順とも規範ともとれます。整理した結果:
- 「個別指定する」「個人名を入れない」「明示トリガー語要件」 → 規範 (Policy)
- 「🤖 Generated with [Claude Code] を HEREDOC 末尾に明示」 → 規範 (= attribution.commit が Bash 経路で効かない故の代替手段) + 手順 (= HEREDOC で書け) のハイブリッド
これは判断境界に位置するため、git.md に書きつつ、根拠 (なぜ HEREDOC で書く必要があるか) も併記しました。1 ファイル 1 関心は厳格運用しつつ、ハイブリッド事項は根拠付きで Policy 側に置く運用です。
7.4. 規律 4: 逆 ratchet (反転承認)
規律: 月次 /harness-prune で 30 日参照ゼロ / サイズ超過 / orphan hook / 参照切れを検出し、反転承認 (残す理由を問う) で削除する。
通常の削除確認は「これ消していい?」と問う形ですが、それだと「念のため残す」が default になり、再構築前と同じ肥大化を再現します。
反転承認は、問いを反転させます。
- 普通: 「Aを消していい?」 → default: 残す
- 反転: 「Aを残す理由は?」 → default: 消す
「残す」側に挙証責任を置くため、「いつか使うかも」「念のため」では残せません。「現に過去 30 日で X 回参照された」「これがないと Y が成立しない」のような 実証的根拠 が必要です。
/harness-prune の検出 4 項目
/harness-prune skill は執筆時点で次の 4 項目を検出します (検出項目自体も usage-driven で増えうる設計です)。
- 30 日参照ゼロの facet: rules / agents / skills / knowledge / output-contracts で、他ファイル・git 履歴から 30 日参照されていないもの
- サイズ上限超過: CLAUDE.md >100 / policy >30 / persona >40 (gating >60) / skill >80 (autodev >100)
- orphan hook: 対応する facet ファイルが無い hook (= 規範本体が無い enforcement)
- 参照切れ: rules / skills / agents 内の
~/.claude/<path>で実在しないもの (glob・末尾/のディレクトリ参照は除外)
実装規律も特徴的です。
## 規律
- 本 skill 自体も ≤80 行 + 検出は上記 4 項目に固定 (metrics 集計を内包させず
自己肥大化を防ぐ)
- 起動は段階導入: 当面は AI (アシスタント) が「前回 prune から時間経過」に気づいて promote
- 削除候補を復元するときは新サイズ上限に書き直してから再配置 (丸写し復元禁止)
/harness-prune 自体が肥大化しないようサイズ上限と検出項目を固定しているのが重要です。「過去 90 日の trend」「facet 種別ごとの集計」など metrics を追加したくなりますが、それを内包すると prune skill が新たな肥大化源になります。検出は 4 項目に固定し、それ以外は人間判断に任せます。
起動忘れ対策
/harness-prune は人間が忘れがちです。当面の対策として:
- AI (アシスタント) が「前回 prune から時間経過したな」と気づいて promote する半自動運用
- 起動忘れが 2 回起きたら SessionStart hook (前回 prune から 30 日経過で promote) を足す
「起動忘れが 2 回」は規律 1 (usage-driven 追加) と整合する閾値です。2 回ルールで hook 追加検討に上がります。
7.5. 規律 5: hooks は実証後
規律: hook 追加は 同型の失敗 2 回観測 + 対応 facet の存在 が前提。orphan hook (対応 facet が無い hook) を禁止する。
再構築前は「失敗が観測されたら即 hook 化」していました。これだと:
- 1 回の失敗で hook が増える → hook の数が累積
- false positive が後から発覚しても削除動機が薄い
- 「とりあえず hook で止めておく」が癖になり、Inferential Guide (rule) が育たない
新ハーネスでは:
- 失敗 1 回目: Inferential Guide (rule) に文字で書く (= main agent / subagent が読んで自律遵守する経路)
- 失敗 2 回目: 同型の失敗が再発したら hook 化を検討
- 検討時の判定: 対応する Policy facet があるか (= 規範本体が rule に書かれているか)
- 採否決定: 採用なら hook 化 + Policy 側に hook 参照を追記
例外条項
例外として、ループ制御・安全ゲートに不可欠な Computational Sensor は bootstrap と同時許容可としています。
実例: check-git-commit-gate.sh は bootstrap (= 新ハーネス投入) と同時に hook 化しました。理由:
git commitは破壊的かつ blast radius が大きい (他セッションの staged 変更混入リスク)- Inferential Guide だけだと並行セッションでの確率的違反を防げない
- 安全ゲートに不可欠 → 例外条項該当
例外条項の運用も反転承認で問います。「例外を残す理由は?」と問い、現に安全ゲートとして機能していることを示せれば残します。
orphan hook の検出
/harness-prune の検出 3 項目目「orphan hook」は、hook ファイルが存在するが対応する Policy facet が無い状態を指します。例えば:
hooks/check-foo.shがある- しかし
rules/*.mdのどこにもfoo規範が書かれていない
この状態は、hook が「規範本体なしで挙動を強制している」ことを意味し、人間 (筆者) が後から「なぜこの hook があるのか」が分からなくなります。orphan hook は削除候補です。
実例として、hooks/check-fact-source-nullresult.sh は対応 Policy が rules/fact-check.md の「一次ソースの null-result を memory で埋めない」section に存在するため、orphan ではありません。一方、もし rules/fact-check.md を改修してこの section を削除したら、check-fact-source-nullresult.sh は即座に orphan 化し、/harness-prune で検出されます。
7.6. 入口の摩擦 × 出口の引力
5 規律を 1 つにまとめると、入口に摩擦・出口に引力になります。
再構築前は「入口に引力 (= 追加が default)・出口に摩擦 (= 削除が困難)」で数百ファイル規模まで増えました。再構築後は「入口に摩擦 (= 2 回ルール / サイズ上限 / 1 ファイル 1 関心 / orphan 禁止)・出口に引力 (= 反転承認)」に転換し、bootstrap 後も usage-driven 追加でファイルは増え続けていますが、各 facet はサイズ上限内に収まっています (= 量的増加と質的肥大が分離されている)。
非対称性を逆向きに付け替えたことが新ハーネスの構造的新規性です。これは 1 つの規律ではなく、5 規律の合成で達成されます。
7.7. 規律違反の検出経路
成長規律が機械的に強制されるのが理想ですが、現状は半自動です。
| 規律 | 強制度 | 検出経路 |
|---|---|---|
| usage-driven 追加 | 人間承認必須 (規範級) | AskUserQuestion 経由で人間判断 |
| サイズ上限 | 自動検出 | /harness-prune の項目 2 |
| 1 ファイル 1 関心 | 人間判断 | 改修レビュー時 (AI が指摘 → 人間承認) |
| 逆 ratchet | 自動検出 | /harness-prune の項目 1, 4 |
| hooks は実証後 | 自動検出 (orphan) | /harness-prune の項目 3 |
サイズ上限と orphan hook と参照切れの 3 項目は機械的に検出できますが、1 ファイル 1 関心とサイズ上限超過時の「分割か削減か」は人間判断 (= AI 提案 + 人間承認) になります。
将来的に「facet 中の動詞/名詞の分布」「ファイル間の文字列共通度」を機械検出して 1 ファイル 1 関心違反を sense する経路は考えられますが、現時点では実装していません (= 人間判断で十分機能している)。
7.8. 本章のまとめ
- 5 規律で 入口に摩擦・出口に引力 を構造的に作る: usage-driven 追加 / サイズ上限 / 1 ファイル 1 関心 / 逆 ratchet / hooks は実証後
- 「2 回ルール」: 同じ指示を 2 回手で出してから facet 化検討、予防的追加は禁止
- サイズ上限超過時は 分割でなく削減 (分割はファイル数を増やすため規律 1 と矛盾)
- 逆 ratchet は 反転承認 で運用 (「消していい?」でなく「残す理由は?」)
- hooks は対応 Policy facet が rules/ に存在することを前提 (orphan hook 禁止)
- 検出経路は半自動: サイズ上限 / orphan hook / 参照切れ / 30 日参照ゼロは
/harness-pruneで自動、1 ファイル 1 関心と分割判断は人間ゲート
次章では、bootstrap 後に表面化した改修サイクル (silent drop / 二重 worktree / 文言ズレ等) の実例を、問題発見 → 分析 → 修正 → 検証で walkthrough します。