まとめと残課題

この連載が記述する時点

本連載は執筆時点のハーネス実環境 (設定ファイルの内容、実行記録、ファイル数) を素材にした記録です。ハーネス本体は公開後も改修が続いているため、引用したファイル内容や個数、手順は現在の実体と異なる場合があります。本連載の主眼は個々の値ではなく設計の考え方 (5 関心分離、検証ゲート、成長規律) にあります。

本連載の最終章として、ここまで扱ってきた内容を 3 段で要約し、4 Quality metrics の現状、未着手項目、これからの道筋を整理します。

9.1. 3 段要約

本連載の核を 3 段でまとめます。

現ハーネスは何か

nrslib/takt の Faceted Prompting (5 関心分離) + 8 design principles を Claude Code 上に独自移植した orchestrator (takt 思想) で組み直され、ゼロ再構築の後 usage-driven 追加で規律を保ったまま成長を続けている構成です。

• 5 関心 = Persona (agents/) / Policy (rules/) / Instruction (skills/) / Knowledge (knowledge/ + repos/<repo>/) / Output Contract (output-contracts/)
• hooks は facet ではなく enforcement 層 (Computational Sensor)
• 数百ファイル規模まで膨張した「追加容易・削除困難」の非対称性を、入口に摩擦 + 出口に引力で逆向きに付け替えた
• ゼロ再構築で大きく圧縮した後、usage-driven 追加で再び増えていくが、hook は他の facet より先行して増える傾向がある (Inferential Guide の deterministic 補強)

どう動くか

/spec-design で仕様を凍結し、/autodev で subagent 連鎖を回す自律開発フローです。

• /spec-design: 人間 + AI 協働で受入基準 (pass 条件 = テストオラクル) を共同確定、承認時に state.md に SHA 凍結
• /autodev: orchestrator (= main agent) が ⓪'-⑤ の検証ゲートループを駆動
  • ① architect → ①' plan-reviewer → ② 人間承認 → ②' story 合成 → ③ developer (worktree 内実装) → ④ auditor → ⑤ ff merge
• 各 review phase は VERDICT: PASS|FAIL 出力契約 + grep '^VERDICT:' で fail-closed 分岐
• 理解ゲート版は /smi-auto-dev (品質ゲート保持の上に G1/G2/G3 を重ねる学習用フロー)

なぜそう動くか

Claude Code に composer が無いからです。

• 全 facet を Read 経路で繋ぐと確率的に silent drop する
• 重要度 (criticality) で配信方式を 3 段に分ける: gating facet は inline + hooks / Instruction は preload / Knowledge は索引 + on-demand
• subagent への規範到達は paths-scoped 禁止 (= 常時ロード) + 絶対パス明示注入で構造的に保証
• 重要規範は Inferential Guide + Computational Sensor (hook) の組で deterministic に強制

9.2. 4 Quality metrics の現状

本連載で参照する 4 Quality metrics (Task Resolution Rate / Code Churn Rate / Verification Tax / Defect Escape Rate) について、現状を整理します。

metric	現状	未着手項目
Task Resolution Rate	定性: autodev フローで palindrome-check / anagram-check / fizzbuzz-cli など複数 task が完走 (VERDICT FAIL 経由含む)	月次計測の母数定義 (= 完走数 / 中断数 / 差し戻し数の集計) は未実装
Code Churn Rate	定性: 完走 task の rework は最小 (= done.md 確定後の修正なし)	autodev 完走後の post-merge churn (= merge 後の修正コミット率) は未測定
Verification Tax	定性: grep '^VERDICT:' のみで review.md 全文を読まない設計で context cost を圧縮	1 task あたりの平均 token / 平均 phase 数 / 人間 attention budget の実測なし
Defect Escape Rate	定性: spec の 10 ケース表 (anagram-check) など、テストオラクルを spec から verbatim 転記する経路で内部漏れを防止	月次の "merge 後に発覚した defect" 件数の集計なし

総じて、定性的には改善している実感はあるが、定量的な月次計測は未着手です。

実装する場合の優先順位:

1. Task Resolution Rate が最も基礎的で、母数定義 (autodev 完走数 / 差し戻し数 / 停滞検出回数) が明確
2. Verification Tax は context cost (token 使用量) の実測ができれば、subagent ごとの cost breakdown が出せる
3. Code Churn Rate と Defect Escape Rate は post-merge 期間 (= 1 週間 / 1 ヶ月) 観察が必要で、scratch repo (autodev-smoke) では検証しにくい

業務 repo への展開時 (9.3 節) に、計測経路を組み込むのが現実的です。

9.3. これからの道筋

本連載執筆時点で認識している残課題と道筋を整理します。

道筋 1: 4 Quality metrics の月次計測自動化

前節で扱った metrics を、/harness-prune 月次 (= 同じ月次サイクル) で集計する経路を組みます。実装上の要件:

• handoff dir 内の state.md / done.md / review.md を集計対象にする
• VERDICT FAIL カウント / 差し戻し回数 / error_signature の停滞検出フラグを集計
• 母数を「完走数」「中断数」で分け、各 metric を比率で出す
• 自己肥大化を避けるため、計測 skill は /harness-prune とは別に切る (= /harness-metrics または /harness-prune --metrics)

道筋 2: 業務 repo への展開

本連載で扱った autodev フローは、scratch repo (autodev-smoke) で完成度を上げました。次のステップは 業務で扱う実 repo (会社 / 顧客 repo) への適用です。

慎重期にしている理由:

• 業務 repo は multi-repo (frontend / backend / shared-lib) の構造が一般的で、autodev SKILL の single-repo 設計 (執筆時点) を multi-repo に拡張する必要がある (= immutable-popping-planet plan の Phase 4-6)
• 業務 repo は team 共有 で、project-init の personal overlay variant (team 資産無改変) で適用するルートを確立する必要がある
• per-repo Policy が業務 repo の constraint (= 既存 CI / lint / merge rule) と整合するか実証が必要

道筋:

1. project-init の personal overlay variant で業務 repo に ~/.claude/repos/<repo>/ 層を作成
2. 小さい単発 task (= single-repo で完結する Bug fix 等) を /autodev で試行
3. multi-repo task は immutable-popping-planet plan Phase 4-6 の実装後に着手

道筋 3: harness-prune の拡張検討

執筆時点の /harness-prune は 4 項目検出 (30 日参照ゼロ / サイズ超過 / orphan hook / 参照切れ) ですが、第 8 章 で扱った verbatim diverge 検知は意図的に追加していません。

将来的に追加を検討する可能性のある項目:

• 同種 facet の文字列共通度検査 (= 1 ファイル 1 関心違反の自動検出)
• subagent ごとの 30 日 spawn 回数の集計 (= 役割使用度の可視化)
• handoff dir の orphan 検出 (= state.md が merged / aborted でない handoff の検出)

ただし、/harness-prune の規律 (= 検出項目を固定、自己肥大化を防ぐ) を保持するため、追加項目は 独立 skill に切り出す可能性が高いです。

9.4. 本連載で扱わなかったこと

本連載のスコープ外として、明示しておく項目があります。

• multi-repo autodev: immutable-popping-planet plan Phase 4-6 (task-centric 再設計、cross-repo pass 条件) は本連載に含めず。実装着手時に別連載または ADR 化を想定
• autodev フローの具体的 transcript (subagent 発話の全行): 紙幅と context 節約のため要約を本文に置き、フル transcript は handoff dir に保全 (本連載読者は ~/.claude/repos/autodev-smoke/handoff/anagram-check/ を直接 Read できる前提)
• 業務 repo の per-repo Policy の具体例: 未着手のため例示なし
• モデル (Opus / Sonnet / Haiku 等) ごとの harness 振る舞いの差: 本連載は特定の 1 モデルで実証しており、他モデルでの再現性は未検証

9.5. 最後に: なぜこれを書いたか

本連載執筆の動機を最後に書きます。

第 1 章 で扱ったとおり、再構築前のハーネスは 4 症状のフィードバックループで膨張していました。ゼロ再構築で大きく圧縮したうえで、そこから usage-driven 追加で規律を保ったまま成長を続けている、というのが本連載の現在地です (詳細は 第 7 章)。

ゼロ再構築は、構造を変えるためには既存の累積を一度全部退避する判断が要る、という教訓を示しています。部分修正で根を抜けない症状は、新ハーネスのどこかで再発する可能性が常にあります。本連載を bootstrap 直後でなく、ある程度運用期間を経てから書いたのは、

• 圧縮して終わりにせずusage-driven 追加で動き続けた事実を実例として記述したかった (= 「bootstrap で完璧な数で平衡する」幻想を退ける)
• bootstrap 直後の改修サイクル (第 8 章 で扱った実例) を経て、構造の弱点が表面化してから書きたかった
• 再構築のスナップショットを筆者自身が後でセルフレビューで参照する一次資料として残したかった

という 3 つが理由です。

本連載は 業界共通の標準ではなく、筆者の独自運用を整理した文書です。Faceted Prompting の語自体は既存の整理軸を採用していますが、何をどの facet に置くか・autodev フローの組み方・各規律の運用方針はいずれも筆者の判断です。再現性を期待する記事というより、ハーネスエンジニアリングを実際に走らせるとどんな姿になり得るかの一例として参照してください。

連載全体の要点

• nrslib/takt 由来の Faceted Prompting (5 関心分離) + 8 design principles を Claude Code 上に独自移植し、ゼロ再構築での圧縮後も usage-driven 追加で成長を続けている (量的増加と質的肥大は分離されている)
• subagent context loss を paths なし常時ロード + 絶対パス注入 で構造解決
• 規範は Inferential Guide + Computational Sensor の組で deterministic 補強
• 入口に摩擦・出口に引力 の 5 規律で再肥大化を構造防止 (反転承認で削除 default 化)
• bootstrap で完璧は無理。ratchet サイクル (問題発見 → 分析 → 修正 → 検証) を回し続ける

ハーネスを走らせ続けると、必ず新しい失敗が出てきます。それを 1 件ずつ ratchet で構造解消していくのが、ハーネスエンジニアリングの本質です。次に新ハーネスを再構築するときは、本連載をスナップショットとして対比軸にする予定です。

---

最後まで読んでくださってありがとうございます。質問や指摘は GitHub Issues 等でお寄せください。