「最高品質ですか？」に Yes と答えないハーネス — v0.14.0 から v0.15.2、足す設計から測って捨てる設計へ【現在地】

📖 はじめに — 問いは「最高か」ではなく「何を根拠に、どこまで言えるか」

共通ハーネス cts-harness は v0.15.2 に到達した。Codex と Claude の役割分離、決定論ゲート、レビュー証跡、複数プロジェクトへの配布、Dynamic Workflow、finding 台帳、モデルドリフト検知まで揃っている。

では、このハーネスはクロスファミリー検証の最高品質といえるのか。

答えは No である。ただし、低いからではない。最高という比較級を支える母集団を測っていないからだ。比較していないものを一位とは呼べない。このハーネス自身が掲げる evidence over claims を適用すれば、他の答えは出せない。

一方で、何も評価できないわけでもない。公開ガイダンスが推奨する「実行可能な検証を与える」「作業者と採点者を分ける」「決定論的な hook を使う」「成功の主張ではなく証拠を示す」は、Claude Code の公式ベストプラクティスにも明記されている。クロスモデルの向きについても、116 タスクの統制実験では Codex 実装 → Claude レビューが 71.6% → 89.7% と改善し、逆方向は 91.4% → 82.8% に悪化した。論文の検証で数値と限界を照合済みである。

cts-harness が公開ガイダンスより先へ進んでいるのは、品質順位ではなく機械強制の範囲だ。本稿は v0.14.0 から v0.15.2 の版履歴を、その現在地を裏づける証拠として読む。

🎯 先に定義する — 本稿でいう「理想形」

理想形を「機能が多いこと」と定義すると、ゲートを足し続けるハーネスが永遠に勝つ。v0.15.0 が示したのは、それが誤りだということだった。本稿では理想形を、次の 4 条件で定義する。

条件	問うこと	v0.15.2 の状態
役割の独立	生成者が自分の成果を採点していないか	実装・設計起草は Codex、採否は Claude。逆順は構造拒否
決定論優先	LLM の自己申告より、テスト・hook・CI を優先するか	checksum、marker、証跡、diff 突合を先に通す
fail-closed	検証不能を成功として流さないか	欠測・未記録・矛盾・証跡不一致は PASS に補正しない
自己修正可能	効かない指標や有害な機構を測って捨てられるか	ADR-019/020/021 と v0.15.0 で実証

ここで「役割の独立」とは、異なるモデル家族へ実装と検証を分離した構造を指す。エラー相関を統計的に測った、という意味ではない。この区別は後半の未検証領域で効いてくる。

🧭 4つの転機 — 版履歴を現在地の証拠として読む

v0.14.0 — Lead の自己申告と自己採点を外へ出す

v0.14.0 は、tdd-team 後半の Phase 3a / 3b を Dynamic Workflow へ移した。旧構成では Lead が verifier を起動し、結果を集約し、証跡を書き、marker を解消していた。環境の健全性も「このバッチは軽いからレビュー不要」も Lead が申告でき、採否と証跡の生産者まで同一だった。

新構成では、Lead が渡すのは識別子だけになる。2 層 preflight、一次レビュー、条件付き adversarial verify、hard gate、証跡 finalizer、統合検査が別コンテキストで走る。通常 final は 10 agent、測定アームを含む pilot は 12 agent。さらに次を決定論 helper へ移した。

3a を実行するか割愛するか
verifier 証跡と実際の agent-id・本文 hash が一致するか
review-pending marker を解消してよいか
同一 steering の run が多重起動していないか

これは「AI を増やした」変更ではない。自己申告できる余地を、判断主体から切り離した変更である。

v0.14.1〜v0.14.13 — 実 run が「書いた契約」と「動く契約」の差を暴く

v0.14.0 は設計レビューとセルフテストを通って出荷された。それでも cts-pos と cts-ec の実 run は、v0.14.13 まで連続して穴を見つけた。重要なのは件数より、欠陥の型である。

欠陥の型	実際に起きたこと	吸収先
壊れた入力の自力補修	agent が不足値を推測し、検証不能を正常化した	schema と層2検査
証跡とゲートの対象差	レビュー済み集合と CI が見る集合がずれた	単一の変更集合生産者
禁止だけで代替なし	テストを変えられない圧力が production 契約の弱化へ逃げた	停止・報告という正規経路
skip と PASS の混同	実行されていないゲートが緑に見えた	明示的な SKIPPED と転記契約
語彙・関係の未定義	`severity=info`、must 4 件なのに judgement PASS	値域と列間整合の parser
測定の交絡	A/B が走らなかった、共有 brief が検出を説明した	requested/measured 分離と出所記録

ここで得た原則は、散文を増やすことではなかった。agent に選ばせない、推測させない、自己申告させない。値域だけでなく値の関係も機械で読む。 v0.14.13 はその到達点だった。

v0.15.0 — 追加したゲートを撤去する

転機は次の版だった。v0.14.9 で追加した「宣言されたゲートの網羅性検査」は、宣言漏れを silent にしないための正しい問題設定から始まった。しかし実装は次の欠陥連鎖を生んだ。

母集団を数える
  → 母集団が狭い
  → 重みがない
  → 重みを表す語彙がない
  → judgement との整合がない
  → must の根拠が実態と合わない

その間、この検査は CI を一度も赤くしていない。一方で利用側は短期間に繰り返し plugin 更新・sync・再 run を求められ、1 run 1.0〜1.7M tokens の工程が止まった。

v0.15.0 はこの機能を撤去した。問題自体を否定したのではない。「母集団を agent に列挙させる」という解き方を捨て、再導入条件を「helper が母集団を固定し、agent は結果を転記するだけ」に限定した。

この撤去が、現在地を理想形に近づけた最大の根拠である。成熟したハーネスはゲートの本数でなく、実害と検出実績を見て、自分が作った機構を捨てられるかで測るべきだからだ。

v0.15.1〜v0.15.2 — 散文を足さず、改善候補も選別する

v0.15.1 では、指摘 0 件の reviewer が Findings 表へ （なし） 行を書き、run が落ちた。0 件時の書式は agent 定義に既に書かれていた。つまり「もう一面に同じ注意を書く」は、効かなかった介入の反復になる。

修正は parser 側だった。0 件マーカーかつ残り列が空の行だけを受理し、実在 ID の空欄や値域外 severity は従来どおり拒否した。モデルが合理的に取りうる表記揺れを機械が吸収し、検出強度は下げない形である。

v0.15.2 の発端は、クロスファミリー設計の改善候補 5 件だった。すべては実装しなかった。実害基準、ADR-019/020、v0.15.0 の教訓で敵対的に選別し、生き残ったのは 2 件だけである。

Codex の要求モデルではなく exec banner の実効モデルを監査記録へ残す
既に配布済みの「生成は Codex・判断は Claude」という事実へ、共通ルールの文言を揃える

仕様層で同じファミリーが共有しうる盲点と、3a 観点間の重複率は、予防工程を増やさず backlog #7 / #8 に残した。改善案があることと、今それを実装すべきことを分けたのが v0.15.2 である。

🔒 現在、機械が止めるもの

v0.15.2 の強さは「Claude と Codex を使っています」では説明できない。次の順序が、散文ではなく実行物になっている。

Claude が仕様・Red テストを確定
  → Codex が実装（逆順は exit 2）
  → --tests の checksum 不一致は exit 3
  → 決定論ゲート
  → Claude verifier
  → run-id / verdict / must / diff / 証跡を突合
  → review-pending 解消
  → pre-push
  → CI が最終強制

特に深いのはテストの配置だ。Red テストは verifier 家族が書き、実装役 Codex へは変更禁止の契約として渡す。これは「別モデルにレビューさせる」より一段手前で、評価オラクルを実装者の資産にしない設計である。実装エージェントがテストハーネスを欺く reward hacking は研究上も確認されており、checksum は抽象的な不信ではなく具体的な故障モードへの防御になっている。

レビュー証跡も「ファイルがある」だけでは通らない。SubagentStop hook が捕捉した agent-type、相異なる agent-id 数、本文 hash を workflow の戻り値と突合し、同じ証跡の使い回しや手書きを拒否する。ローカル marker は削除できても、コード変更と verifier 証跡の対応は CI が再検査する。

📏 「効果がある」と言える範囲

Dynamic Workflow の採用判断では、測れる指標だけを残した。消費と壁時計は分母に進捗がなく、「何も完了しなければ最良」という逆向きの最適化を生むため ADR-019 で判定から外した。承認回数も、番号を消費しない裁定が実在して原理的に取得できず、ADR-021 で外した。DW が置き換えていない前半の不調を後半の採否条件へ混ぜないことは ADR-020 で固定した。

最後に残った判定材料は次のとおりである。

比較可能な cts-pos では、差し戻し周回が 1.70 → 1.20 周/バッチ（29% 改善）
DW が置き換えた検証段だけなら 1.00 → 0.00
手動 LOOP 3 周が見逃した production の confirmed must を検出し、是正後は再検出なし
既存ゲート・model・証跡の欠落なし。skip と PASS、未観測と差なしを区別

同じハーネスで cts-pos は 6 バッチ連続 BATCH_PASS、cts-ec は 14 ラウンドで RUN_PASS 0 回だった。これはハーネスの成否を二分した結果ではない。cts-ec では前半の準備不足を DW が毎回正しく止め、cts-pos では準備済みの入力が後半を通った。評価対象が置き換えていない段の指標を混ぜないとは、この差を都合よく平均しないことでもある。

🔭 それでも「最高品質」と言えない4つの残余

1. 仕様層は同じファミリーに寄っている

実装と検証は Codex / Claude に分かれたが、仕様の解釈、Red テスト、最終レビューは Claude 家族に寄っている。Claude が requirements を同じ方向に誤読すれば、test-writer と reviewer が揃って通す可能性がある。

backlog #7 は、この穴へいきなり工程を足さない。次の golden set 起票時に、既知の仕様誤読を含む fixture から Codex が期待挙動を独立再導出し、Claude AT の欠落を実際に検出できるかを先に測る。確認済み実害はまだ 0 件である。

2. レビュー結果の再現性が未確立

effort は workflow の宣言には存在するが、実 run の metadata に記録されない。g25k では xhigh が挙げず high だけが挙げた finding があった。しかし両アームが本当に別 effort で動いた証拠がなく、effort 差と同一条件の非決定性を分離できない。

これは harness 側が宣言値を書き写しても解決しない。実行主体である Claude Code が実効 effort を記録するまで上流待ちである。

3. 自環境で測れたのは precision 差まで

外部論文の +18.1pt / −8.6pt は、特定モデルペア・116 問の統制実験値である。CTS の難化 golden set v2 は、矛盾ゼロ対照への誤検出が Codex 15 件 / Claude 0 件という precision 差を示した。一方、recall は難化反復でも両家族 100% の天井に張り付き、ダイバーシティによる見逃し削減量は測れていない。

つまり、finder / verifier 分業の向きは自環境データでも支持されたが、三役構成全体の効果量までは出ていない。

4. すべてを強制すること自体が正解ではない

Codex へ上流の生成作業を移す規則の一部は、観測点を増やすコストと実害を比較して、機械強制を作らないと裁定した。v0.15.2 の仕様層アームも同じで、まず測定し、効くと分かってから工程化する。

これは弱点を放置したのではない。意図的に残した残余を、残余として識別できる状態である。ただし、意図的でも未検証は未検証であり、「最高」の根拠には使えない。

🧾 正確な現在地 — 品質順位ではなく、検証境界を言う

v0.15.2 を一文で表すなら、こうなる。

実装層のクロスファミリー検証については、公開ガイダンスが推奨する独立検証・決定論ゲート・証跡による完了判定を、fail-closed の運用契約まで具体化している。公開ガイダンスより機械強制の範囲は広い。一方、異なるモデル家族への分離が誤りの相関をどの程度下げたか、仕様層の共有盲点、run 間の再現性、他ハーネスとの比較は未測定である。したがって「最高品質」とは言えないが、検証済み範囲と未検証範囲を区別できる、成熟度の高い実装である。

理想形に近づいた最大の根拠は、ゲートが多いことではない。v0.14.0 で自己採点を外へ出し、v0.14.13 まで実 run の失敗を機械契約へ吸収し、v0.15.0 で自分が追加した機能を撤去し、v0.15.2 で 5 つの改善候補から 3 つを実装しなかったことだ。

足せることではなく、測って捨てられること。分からないことを、分からないまま正しく残せること。 それが現時点で確認できる、このハーネスの最も強い品質である。

📚 シリーズ記事（ステアリング駆動開発・応用編）

第I部: クロスファミリー検証（全 6 回）

本編終章

クロスファミリー検証の最終型 — 自分で正しさを測り直す

運用実録

現在地と事業展開

「最高品質ですか？」に Yes と答えないハーネス（本記事）
二度の「1か月」を繰り返さない — 技術的負債から育てる AI 駆動開発ハーネス【サービス化への現在地】
ステアリング駆動開発を、ループエンジニアリングで包む — 人の注意力で止めるから、機械の停止条件で止めるへ【v0.32.0】

ステアリング駆動開発（実践編） — 応用編の前提となる、技術的負債の返済と機械ガードの実録
クロスファミリー検証の最終型 — finding 台帳と自己修正ループを導入した本編終章
GPT-5.6 sol 切替の当日実録 — 難化 golden set v2 と precision 差の自環境実測

参考リンク（2026-08-02 時点で確認）

Best practices for Claude Code（Anthropic 公式） — 決定論 hook、別コンテキストの検証、Writer/Reviewer・test/code 分離、証拠による完了判定
Cross-Model LLM Code Review（arXiv:2607.21656） — Codex / Claude のレビュー順序を比較した 116 タスクの統制実験
From shortcuts to sabotage（Anthropic Research） — テストハーネスを欺く reward hacking の故障モード