クロスファミリー検証の最終型 —「正しく作る」から「自分で正しさを測り直す」へ【終章】

📖 はじめに — 最終回の後に残っていた宿題

モデル戦略編で、クロスファミリー検証パイプラインは標準運用に昇格した。finder と verifier の分業、逆順の構造的禁止、テスト改ざんガード、レビュー漏れの三層機械クローズ — 「検証を必ず実施させる」構造は組み上がった。

先に用語を揃えておく。本稿では、この「変更を検証する仕組み」（クロスファミリー分業 + 決定論ゲート + 証跡）を検証エンジン、それを含む運用基盤の全体 — ルール・hook・エージェント定義・CI、そして本稿で加わる計測 — をハーネスと呼ぶ。エンジンはハーネスの中核部品である。

しかし、昇格した時点のエンジンには、分かっていながらまだ埋めていない欠落が残っていた。

• golden set は n が一桁で、recall は 100% で飽和したまま。クロスファミリーの recall 利得は未実証
• fallback（Codex 不可時に Claude が実装する縮退運転）がどの頻度で起きているかを計測していない
• verifier の見逃し率が不明 —「レビューは必ず走る」が「レビューが効いている」を意味しない

つまり「検証を強制する」構造はあるのに、「その検証が効いているかを測る」層がない。ルール → 強制（hook・マーカー・CI）と来て、ループはそこで途切れていた。

本稿はシリーズの終章として、この最後の層がどう埋まったかを記録する。きっかけは社内の知見でも新しい論文でもなく、筆者の友人が個人開発で運用しているハーネスとの相互レビューだった。

🪞 鏡像 — 独立に同じ思想へ収束していた、もう 1 つのハーネス

友人は、複数の個人プロジェクトを横断するメタ運用フレームワークを 1 人で構築・運用している（本稿では仮に ops-fw と呼ぶ。本人の了解を得て、設計思想の概要のみを紹介する）。互いのハーネスを精査し、改善提案書を書き合う形の相互レビューを行った。

精査して最初に驚いたのは、規模ではなく規律だった。

• 運用原則のすべてに、実事故・実測を根拠として付記している。「べき論」由来の原則が 1 つもない
• 完成形ドキュメントは 1 日に複数回の改訂履歴を刻む living document で、全項目に【収束】【推奨】【決定】のタグが付く
• 「採用見送り表」がある —「漏れ」と「意図して落とした」を区別する明示表。AI が過去の非採用を知らずに同じ提案を蒸し返すコストを、文書 1 枚で構造的に潰している
• 自分の環境制約（実行環境が 1 台、など）を恒久前提として明文化し、条件分岐を捨てて単純化している

そして思想の核が、CTS-EC のハーネスと独立に一致していた。異種モデルによる相互レビューの必須化。決定論的な検証を LLM の前に置く。暗黙のドリフトを禁止する。実証主義 — 「AI の判断ミスを散文でなく構造で塞ぐ」「evidence over claims」という、本シリーズが 16 回かけて積んできた DNA そのものに、別の場所で独力で到達していたのだ。

だが本当に重要な発見は、その先にあった。両者は互いの弱点を、互いの強みで正確に埋め合う鏡像関係にあった。

図式化するとこうなる。

CTS-EC:  ルール → 強制（hook・marker・CI） → [ここで途切れる]
ops-fw:  ルール → 計測（台帳・検知） → 剪定 → [強制が薄い]

補完後:  ルール → 強制 → 計測 → 剪定・改版 → ルール …（ループが閉じる）

CTS-EC は「検証を強制する」までは完成していた。欠けていたのは「その検証が効いているかを測る」層。ops-fw は「測って剪定する」までは完成していた。欠けていたのは「測る対象の行為を確実に発生させる」層。どちらも新しい思想は要らず、相手が既に実装済みの層をはめ込むだけ — だから、これは転換ではなく完成だった。

📦 取り込んだ 5 つ — そして、丸呑みしなかったもの

相互レビューから CTS-EC 側に取り込んだのは次の 5 点である。

1 のモデル台帳は、モデル ID・料金・実測挙動を一元化し、各エージェント定義は役割 × ID のマッピングだけを持つ。statusline 経由で初見のモデル ID を自動検知して一定期間フラグ表示し、エイリアスの解決先は月 1 回・1 ドル未満の実 API プローブで確認する — サブエージェントが暗黙に受ける解決先変更を、人間の注意力でなく機械で捕まえる。

2 は fallback 設計の核心で、「クロスファミリーは失っても、独立コンテキストの verifier ゲートは絶対に落とさない」を明文化 + 機械強制する。縮退の発生率そのものも計測対象にする（後述）。

3 が本稿の主役だ。レビュー指摘を 1 件単位の固定スキーマで蓄積し、「どの指摘クラスが、どこで、何度再発しているか」から次にどこへ投資するかを導く。ops-fw はこの台帳から「特定クラス（同期漏れ系）が全指摘の 4 割超を占める」という支配構造を割り出し、投資判断につなげていた。1 つの数字が、感覚論を終わらせる。

4 と 5 は文書パターンで、コストはほぼゼロ。特に 5 は「運用メタ改善は実痛が観測された項目のみ着手し、効果が実感できない既存機構は削除候補として同じ基準で刈る」という運用だ。積むだけだったハーネスに、初めて引き算の規律が入る。

丸呑みしなかったもの

対等なレビューの証は、選別にある。ops-fw の実装をそのまま移植しなかった判断が 3 つある。

• 証跡の内容拘束（diff のハッシュ）は全ファイルでなくコードに限定 — ステアリング運用ではレビュー後にタスクリストや決定ログの更新が必ず発生する。全ツリー対象だと、コード無変更でも「差分が変わった」と誤検知して再レビューを強制してしまう
• 台帳からエージェント定義を生成する方式は不採用 — 生成パイプラインはツーリング過剰。台帳と定義の不整合を決定論スクリプトで検知する方が、「散文で準拠を謳う」より強く「生成」より単純
• メモリ機構の無効化（ops-fw 方式）は見送り — 得たいもの（SSoT の一本化）は「台帳 = 事実の正本、メモリ = 蒸留知見のキャッシュ」という規律の移植で大半が手に入る。無効化で失うものの代替層が CTS-EC にはない。そして何より、実痛が観測されていない機構を反転させるのは ops-fw 自身の実痛駆動原則に反する

最後の 1 つは象徴的だ。相手の設計を、相手の原則を根拠に断る — 思想が本当に共有されているとき、移植は模倣ではなく翻訳になる。

🔧 実装 — 2 本のステアリングで「完成」の域へ

取り込みはステアリング駆動開発の手順どおり、規模判定で 2 本に分割して実施した。

1 本目: 証跡の拘束とモデルドリフト検知

CTS-EC 側に元からあった残余ギャップ（証跡の内容・時間拘束）と、取り込み 1・2 をまとめて実装した。

• 内容拘束: verifier 証跡にコード差分のハッシュを埋め、「証跡が今の変更を見て書かれたこと」を機械検証する
• 時間拘束: CI で「レビュー後にコードが変わっていないか」を検査する。証跡が指すコミットは実在チェックだけでなくHEAD の祖先であることまで検証し、無関係コミットの sha を使った偽造証跡を弾く

この時間拘束では、設計レビューを通過した後の実装フェーズで設計の自己矛盾が見つかった。当初案の stale 判定は「レビュー時点のコミット以降にコード変更があれば fail」だったが、通常フロー（実装 → レビュー → 証跡作成 → コミット）では、レビュー対象のコード変更自身が常に「レビュー時点より後のコミット」に含まれる — つまり正常な MR が全部 fail する。判定のアンカーを「証跡ファイル自身の最終コミット」に変えて解決したが、教訓は設計の中身よりプロセスにある。文書レビューを 2 ラウンド通した設計でも、実装ゲートは別の穴を見つける。多層の網は、自分たちの改修に対しても機能した。

• モデル台帳と検知: ops-fw は複数リポジトリ横断のためグローバル配置だが、CTS-EC は「リポジトリが正本」の思想なので台帳・検知スクリプトともリポジトリ内に置き、hook・CI・他の開発者から参照可能にした
• effort の二層ピン: verifier 段・worker 段それぞれの推論努力量を現状の実効値で明示的に固定した。狙いは最適化でなく暗黙ドリフトの排除 — 挙動を変えずに、変更が「台帳と定義の同時更新」としてしか通らない形に構造化する

モデルマスタ台帳の運用 — 三経路の検知と「記憶で答えない」

出来上がったモデルマスタ台帳（model-master）は、現行モデルの ID・料金・コンテキスト長・検証済みの実測挙動、そして「どのエージェント役割に・どのモデルを・どの effort で」の roster を 1 枚に持つ単一正本だ。roster はエージェント定義の frontmatter と決定論スクリプトで機械突合され、食い違いは改定漏れの一覧つきで fail する。モデル割当の変更が「台帳と定義の同時更新」という意図した変更としてしか通らない、という構造はここで閉じる。

ドリフトの検知は三経路で回る。

台帳にはもう 1 つの役割がある。「実在しないモデル ID は即エラーで課金ゼロ」「エイリアスは公式に最新版へ自動追従する（切替タイミングの仕様は非公開）」「1M コンテキスト変種の ID（[1m] サフィックス）が存在し、角括弧は正規表現のメタ文字なので ID 比較は完全一致で行う」— こうした調べて確かめた挙動を出典・確認日つきで台帳に固定する。次に調べ直すコストと、「記憶で答える」事故を同時に消すためだ。

次のモデルが来た日 — 更新はチェックリストで流れる

この台帳が本領を発揮するのは、次のモデル世代が来た日である。statusline の 🆕（またはプローブの警告・リリース情報）を起点に、更新チェックリストが流れる。

1. 新モデルの料金・トークナイザ・コンテキスト長を公式ソースで確認する（記憶で答えない）
2. 台帳のカタログを更新し、実効コストを試算する — 名目価格が同じでも、トークナイザが変われば実効コストは変わる（例: Sonnet 5 は同一テキストのトークン数が旧世代比で約 3 割増えることが公式に明記されており、導入価格の期限も含めて試算する）
3. 割当を変えるなら、roster とエージェント定義を同時に更新し、突合スクリプトの green を確認する
4. そしてモデル戦略編の宿題 — 「向き」の再測。finder/verifier の分担が新世代でも成立するかを golden set で測り直す。向きは恒久の真理ではなく、世代ごとに測り直す運用パラメータだからだ

「その日」は本稿公開の 5 日後、実際に来た — しかも検知三経路が見ていない finder（Codex）の側から。このチェックリストと golden set 再測が同日中にフル稼働した顛末は、番外編第 2 弾に記録した。

残余も台帳に明記してある。モデル切替時に main loop の effort がそのモデルの既定値へ上書きされる公式挙動は、二層ピン + roster 突合でも塞ぎきれない — 「切替直後だけは人が確認する」という注意書きが 1 行だけ残る。どこまで機械化できて、どこからが人の仕事か。その境界線ごと文書化しておくのが、このハーネスの流儀だ。

2 本目: finding-level 台帳 — 検証エンジンの出力を資産化する

主役の台帳は、設計判断が濃い。

• append-only を崩さずライフサイクルを表現する — 既存行の書き換えを一切禁止し、ルーティング確定・解消・取り消しは新しい行で表現するイベントソーシング型。改ざん検証が「既存行の変更・削除の検出」という単純な決定論チェックで済む
• fallback 率は run 単位で集計 — 「縮退運転が何 % あるか」がついに数字になる。ただし台帳に現れるのは指摘を伴った run だけ、という到達限界も出力に明示する（真の率は証跡ファイル数との突合で補正できる）。測定値には、測定の限界を添える
• 学習ルータは提案のみ — 同じクラスの指摘が 2 回再発したら「この知見をどこに還元するか（規約か、チェックリストか、hook か）」を提案する。ただし反映は人間の採否確定後。誤った蒸留知見が無審査でエージェントの行動を変えることを防ぐ
• 分類は自環境準拠 — ops-fw の分類体系は直輸入せず、CTS-EC のレビュー実態に合わせた 9 クラスに再設計した。分類は還元先ルーティングの主キーであり、現場の様式と合っていなければ転記コストで形骸化する。ops-fw で支配的だった同期漏れ（横展開漏れ）は独立クラスとして観測する

台帳の日常運用 — 収穫は毎回、剪定は四半期

運用は 2 周期に分けた。収穫は日常に埋め込む — ステアリングの完了処理にレビュー指摘の記帳ステップを組み込み、実装フロー中は verifier の must 指摘をその場で記帳し、セッション終了時には hook が本番 fix コミットを検出して記帳コマンド案を提示する（提示のみ・実行は人）。追記は検証つきの単一スクリプト経由に限定して手書きを禁止 — 列数・値域・ID の採番を機械が守る。剪定は四半期に 1 度だけ: 分布・再発カウント・fallback 率を集計し、蒸留知見を finding 参照で台帳と突合して「根拠クラスがその後も再発している（= 効いていない）」知見を削除候補に挙げる。毎回フル棚卸しをしないのは意図的だ — 剪定のコスト自体も、実痛駆動で払う。

そして計測を始める前に、「数字が出たら何を決めるか」を先に文書化した。

• コード由来の must+should 指摘が数十件規模に達するか、四半期経過の早い方 → verifier 見逃し率のメタ検証に着手する
• fallback 率が出たら: 数 % なら「許容リスク」として明文化し、2〜3 割なら fallback 経路へ設計投資する。中間域は原因の内訳を見て判断
• golden set が実失敗由来で数十件・recall < 100% に育ったら → 逆順禁止（−8.6pt は今も外部実験値のままだ）を自環境で再検証する。そのときの観察フレームは ops-fw から借りる — 優劣の判定ではなく、強み・弱みのプロファイリングとして測る

数字が出てから解釈を考えると、解釈は必ず数字に迎合する。トリガーと意思決定を先に固定しておくのは、golden set の正解メタを隔離したのと同じ理屈である。

台帳の初回転 — 初期データは「自分を作ったステアリングの指摘」

この台帳の初期データには、出来すぎた事実がある。投入した最初の 21 件は、計測層を作った 1 本目のステアリング自身が受けたレビュー指摘なのだ（文書レビュー 15 件 + 実装検証 6 件）。検証エンジンは、自分に計測層を取り付ける改修に対してもいつもどおり差し戻しを繰り返し、その指摘がそのまま計測層の最初の観測対象になった。

初回転の分布は、docs 系 8 件・同期漏れ系 4 件・correctness 系 4 件・テストギャップ系 3 件（ほか 2 件）。再発閾値に達したのは 4 クラスで、ops-fw の環境で最大勢力だった同期漏れ系は、CTS-EC の初期データでも早速その中にいる。「どの負債ドメインに次のステアリングを向けるべきか」— 第I部で 8 つのドメインを勘と実痛で選んだ判断が、ここから先は自分の運用データで下せるようになっていく。ただし、ここにも計測の規律を 1 つ添えてある。この初期分布は「ハーネス整備期」のもの（対象はほぼ運用スクリプトと文書）なので、メタ検証の着手判断など後続のトリガーはコード由来の指摘を 0 件から数え直す。母集団を代表しない時期のデータで、次の装置の建設を判断しない。

🔁 「完成」の再定義 — 終わることではなく、ループが閉じること

2 本のステアリングを終えて、ハーネスは冒頭の欠落を埋めた。だがここで言う「完成」は、「もう変更が要らない」という意味ではない。システムが自分の劣化・見逃し・ドリフトを、自分の運用データで検出し修正できる状態 — 自己修正ループの閉合である。

なお、この状態には近年名前がついた。Google の Addy Osmani 氏が 2026 年 6 月に命名したループエンジニアリング — 「エージェントに都度プロンプトを打つ人」から「エージェントを回すループを設計する人」への転換 — であり、本シリーズの検証エンジンはその一実装にあたる。

この区別が重要な理由は 3 つある。

1. 最後の層は証明ではなく推定である。 「verifier が diff を読んだが、浅くしか読んでいない」は永遠に機械検証できない。見逃し率のメタ検証は統計的な推定であって、ゼロの保証ではない。完成後も残余リスクは残る — だからこそ測り続ける
2. 完成するのは、マージした時点ではなくデータが溜まった時点である。 台帳も fallback 率も、運用数ヶ月でようやく意味のある n になる。それまで「逆順禁止（−8.6pt）」は外部実験値への依拠のままだ。見逃し率のメタ検証も、台帳の指摘が数十件規模に溜まってから着手する — 分布を代表しないデータの上に検証装置を建てても、装置ごと信用できない
3. 環境は非定常である。 モデルは更新され続ける。モデル戦略編で「向きは世代ごとに golden set で再測する運用パラメータ」と書いたのと同じ理由で、完成形は静止状態ではあり得ない。友人の言葉を借りれば living document、CTS-EC の言葉なら再構築が続けられる状態 — ホメオスタシスとしての完成だ

🧾 シリーズ全体の結び — 増幅の物語として

このシリーズは序章の一文から始まった —「LLM コーディングは増幅である。放置すれば技術的負債が増幅される」。全 17 本は、この一文への応答として 4 幕で進んできた。

終章で起きたことを一言で言えば、エンジンが自分自身を観測対象にしたということだ。

• 📒 レビュー指摘は、流れ去らず → 台帳に溜まり、再発が数えられる
• 📉 縮退運転は、体感でなく → 率として出てくる
• 🆕 モデルのドリフトは、人の注意力でなく → 機械が検知する
• ✂️ 効かない機構は、積まれたままでなく → 実痛の基準で削除候補に挙がる

「正しく作った（correct by construction）」から「自分で正しさを測り直せる（self-correcting by measurement）」へ。振り返れば、序章からの 17 本はすべて、この終点への道のりだったことになる。AI の申告を信じない。外部の数値を鵜呑みにしない。構造で塞ぎ、自分のデータで測る — その姿勢を検証システム自身に再帰適用したものが、この最終型だ。

そして最後のピースが、論文でもベンダーのベストプラクティスでもなく、1 人の友人との対話からもたらされたことを、書き残しておきたい。

この 17 本の裏側は、正直に言えば泥臭い道のりだった。デグレの続発を数字で突きつけられ、5 日間で 134 タスクを消化し、sandbox の地雷を実測で潰し、レビューを通したはずの設計が実装ゲートに自己矛盾を暴かれる — そのたびにルールを書き、ゲートを敷き、測り直してきた。AI と向き合う開発は、突き詰めるほど孤独な作業だ。ゲートをいくら積み上げても、最後の 1 つ — 自分の設計思想そのものが正しい方向を向いているのか — だけは、自分では検証できない。

その検証を果たしてくれたのが、別の場所で、同じ孤独の中、独力で同じ終点を目指していたもう 1 人の設計者だった。互いのハーネスを見せ合ったとき、そこには同じ原則が — 別の言葉で、別の実装で — 既に書かれていた。そして互いに欠けていた層は、相手が作り終えていた層と、図ったように噛み合った。同じ思想に独立に到達した 2 つのハーネスが、互いの欠けた層を交換して完成する — クロスファミリー検証の物語の結末として、これ以上の脚本はちょっと書けない。

相関しない検証者こそが、自分では見えない盲点を埋める。 モデルだけでなく、設計思想にも — そして、それを設計した人間にも — 同じことが言えたのだ。

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

序章

1. AI 駆動開発が積み上げる技術的負債

第I部: 技術的負債ドメイン別の実録（総点検ガイド + 8 ドメイン・全 9 回）

2. リファクタリング総点検ガイド — 7 つの観点と進め方
3. DDD/SOLID/BC 編 — god class 一掃と境界の機械ガード
4. SAGA 編 — 新アーキテクチャ挑戦と再発ゲート
5. Atomic Design リファクタ編 — 47 page 新規移植
6. Storybook × a11y 実機編
7. テスト品質・網羅性編
8. Python ジョブ群編
9. パフォーマンス編
10. セキュリティ編

第II部: 検証エンジン（クロスファミリー検証・全 6 回）

11. 総論 — マルチ LLM の 2 系統と見取り図
12. 裏取り編 — +18.1pt 論文の検証
13. 設計編 — finder/verifier 分業と逆順禁止
14. TDD×ハーネス編 — テスト保護と三層ゲート
15. 実装編 — Claude Code の中から Codex を動かす
16. モデル戦略編 — ティア割当と「買うか組むか」

終章

17. クロスファミリー検証の最終型（本記事）

番外編

18. CI テスト 29 分 → 5.6 分 — 検証エンジンの平時運用実録 — 実測が有力仮説を殺し、退行前より速くなった 1 日
19. GPT-5.6 sol 切替の当日実録 — もう一つのデフォルト追従 — CLI 更新が黙って替える finder と、当日中の再計測
20. 遊休 90% の枠に仕事を振る — Codex 上流調査と verifier バッチ化 — 逆順禁止の境界を ADR で確定し、読む仕事を遊休枠へ移した 1 日
21. ハーネスが単一プロジェクトを卒業する — プラグイン化と二層配布 — 4 プロジェクト展開への切り出しと、version + SHA ピンによる非強制追従
22. 69分で5リリース — Opus 5 当日対応が暴いた共通ハーネスの死角 — 新モデル対応を起点に、配布・文書・CI の回帰を二消費者で検出した 69 分

関連記事

• Claude Code 7層ハーネスエンジニアリング — 「強制」層（決定論ゲート）の設計
• Claude Code を Opus 4.7 → 4.8 に移行する — モデル更新が effort 設定を暗黙リセットする実例。モデル台帳 + 検知が守る対象そのもの
• ステアリング駆動開発とは — 本シリーズの土台となる文書駆動開発の全体像

関連用語

• ADR — 設計判断の永続記録。本稿の「ルール」層の正本
• コンテキストエンジニアリング — 台帳とメモリの責務分離が属する設計領域