CTS-KB
AI駆動開発📚 シリーズ 13/22

指示書からパイプラインへ — finder/verifier 分業・二層の網・逆順の構造的禁止【クロスファミリー検証 第3回】

⏱ 約 9 分で読めます
#クロスファミリーレビュー#Claude Code#Codex#ステアリング駆動開発#コンテキストエンジニアリング#TDD#DDD#リグレッション対策
「Codex 実装 → Claude レビュー」+18.1pt 論文を裏取りする — 両者のレビューは何が違うのか【クロスファミリー検証 第2回】Red テストは verifier 家族の資産 — テスト改ざんガード・レビュー漏れの機械クローズ・自己評価遮蔽【クロスファミリー検証 第4回】

📖 はじめに — 原則を「運用に耐える形」に落とす

前回で裏取りした構造仮説 — finder と verifier の役割は非対称 — を、実プロジェクトの毎日の開発フローに落とすのが本記事だ。出発点は 1 枚の汎用指示書（「大規模修正 指示書 — Codex 実装 / Claude レビュー 二刀流」）で、これを CTS-EC（.NET + フロントエンドのモノレポ）へ翻案し、ADR として恒久化した。

先に本質を言ってしまうと、この設計の合言葉は次の 1 行に集約される。

Codex が広く拾い、hook が機械的に固め、Claude が仕様と突合して確定する。

🧱 4 つの原則

パイプラインは「体感」ではなく、次の 4 原則の上に立つ。

  1. 順序性は非対称 — 統制実験で「Codex 実装 → Claude レビュー」= +18.1pt、逆方向 = −8.6pt（裏取り済み。外部統制実験値であり自環境値は別途実測）。実装は必ず Codex 起点、レビューは必ず Claude を後段に置き、逆順を禁止する
  2. 指摘数の多寡は優劣ではない — Codex は high-recall（疑わしきも広く拾う）。だから Codex = finder（広く拾う）、Claude = verifier（仕様と突合して確定する） と役割を固定する
  3. 相関盲点は周回では消えない — 同一ファミリーを何周回しても、そのファミリーが構造的に見落とす欠陥は残る。レビュー回数の増設ではなく、異なるファミリーによる直列検証でのみ盲点を潰す
  4. 防御の本質は「決定論ゲート + クロスファミリー検証」の二層 — hook（機械的・exit code）で不変条件を強制し、その上に AI レビューを重ねる。AI は機械の代替にならない

👥 役割分担

ロールツール / モデル責務禁止事項
finder / 実装Codex CLI実装、high-recall で疑義箇所を広く列挙自分の指摘を自分で最終確定しない
verifier / レビューClaude Code（Opus 4.8、難所は Fable 5）実装と指摘を仕様（ユビキタス言語・集約境界・受入基準）と突合し採否を確定実装の起点にならない（逆順禁止）
決定論ゲートhook（テスト実走・アーキテクチャテスト）テスト緑・レイヤ不変条件を exit code で強制AI 判断に代替させない

3 行目が見落とされがちだが、一番硬い。Codex も Claude も「完了しました」と主張できるが、テストが赤なら hook が物理的に前進を止める。AI の申告を信じる必要がない構造にしておく。

🔄 ワークフロー — 1 変更単位あたり

TDD + DDD の順序を厳守する。実装コードから入らない。

🔄 ワークフロー — 1 変更単位あたり

exit ≠ 0

exit 0

差し戻し（修正も Codex）

採否確定

設計フェーズ（Claude）ドメインモデリング・ユビキタス言語受入基準 → Red テスト作成

実装フェーズ（Codex）Red を満たす実装（Green）+ 疑義箇所の列挙（finder 出力）

決定論ゲート（hook）テスト全緑 + レイヤ不変条件

検証フェーズ（Claude verifier）差分 + finder 出力を仕様書・ADR・受入基準と突合

反映進捗更新・ADR 追記golden set にケース登録

同じ工程を「誰の領分で起きるか」の軸に組み替えると、レーンの境界がそのまま禁止事項の配置になる。

クロスファミリー検証ワークフロー — 役割スイムレーン（レーン = 責務の境界、⛔ = 各ロールの禁止事項）

運用上の要点は 2 つ。

  • 差し戻しの修正も Codex に戻す。「軽微だから Claude が直す」をやると、その瞬間に逆順（Claude 実装物を Codex 系フローが触る/その逆）が混入する。緊急時でも順序を崩さない
  • Codex の指摘ゼロを目指して周回しない。原則 3 のとおり、周回で相関盲点は消えない。ゴールは「Claude の検証ゲートを通ること」であり、finder の静粛ではない

逆順の「構造的」禁止

ルール文書に「逆順禁止」と書くだけでは、緊急時に破られる。CTS-EC では実装ハンドオフ用スクリプト（implement.sh・詳細は第5回）が、Codex にレビューさせる経路そのものを提供しない。

# 逆順禁止ガード: Codex にレビューさせる経路は提供しない
--reverse|--codex-review|--review)
    echo "❌ 逆順禁止: 本スクリプトは Codex 実装 → Claude レビューの一方向のみ。" >&2
    echo "   Claude 実装 → Codex レビュー（−8.6pt）は運用に入れない。" >&2
    exit 2 ;;

皮肉なことに、OpenAI 公式プラグインや巷の SKILL.md の多くは「Claude 実装 → Codex レビュー」— つまり実証上の有害方向を自動化している。有名ツールが向いている方向を、根拠を持って物理的に塞ぐ。これがこのパイプラインの一番の逆説だ。

適用範囲と例外 — 例外にも逆順禁止を貫く

コード実装（バックエンド・フロントエンド・スクリプト群)は Codex 実装 + Claude verifier が既定。例外として Claude 直実装を許すのは、ドキュメント・設定のみの変更、typo や 1〜2 行の自明修正、Codex 停止時の fallback に限る。そしていずれの例外でも Codex レビューは入れない。「Codex が使えないなら、せめてレビューだけでも」は善意に見えて −8.6pt の方向そのものである。

🧠 コンテキストエンジニアリング規約

リグレッションの多くは、コードの巧拙より「古い・曖昧な文脈が実装を誤誘導する」ことに起因する。パイプラインと同じ重みで、文脈の規約を敷く。

  1. SSoT 構造の維持 — 薄い索引（CLAUDE.md）/ 恒久ルール / 仕様・進捗文書 / ADR に階層化し、参照経路を一意化する
  2. ブリーフの最小化 — Codex / Claude に渡す文脈は「対象テストクラス 1 つ + 実装対象のシグネチャ + 関連 ADR」に絞る。ドメイン全体を丸ごと積まない（コンテキスト肥大は compact を誘発し、消費増と品質劣化の主因になる）
  3. タスク切替で /clear、肥大時に /compact。同一コードベースを回すならプロンプトキャッシュが効く構成にする
  4. 分割ファイルは明示 import で取り込む — 「なぜか古いファイルが読まれる」を構造的に排除する

ステアリング駆動開発（設計文書を先に固める）が敷かれているからこそ、規約 2 の「最小ブリーフ」が成立する点は強調しておきたい。文書化されていないプロジェクトで同じことをやると、ブリーフを絞った分だけ AI が推測で補い、逆効果になる。詳細はステアリング駆動開発シリーズへ。

翻案で変えた点 — auto memory は全廃しなかった

元の汎用指示書は「auto memory 無効化（stale recall の構造的排除）」を推奨していた。CTS-EC はこれを採用しなかった数少ない項目だ。現行の auto memory 運用（セッション開始時の記憶読込）を維持し、陳腐化リスクは「参照前に実在検証する」運用ルールと evidence 重視の規律で受けた。汎用指示書をそのまま飲むのではなく、自プロジェクトの既存運用と突合して採否を 1 項目ずつ決める — この翻案プロセス自体が、ADR に「採用しなかった代替案」として残っている。

🕸️ リグレッション防止の三点セット

1. 決定論ゲート（必須・機械的）

  • テスト緑: hook がテストスイートを実走し、exit ≠ 0 なら停止をブロック。「AI ができたと言った」では通らない
  • レイヤ不変条件: アーキテクチャテスト（依存方向の検証。.NET なら NetArchTest / ArchUnitNET、CTS-EC は手書き Reflection テスト）を同じ hook で実走

2. 特性化テスト（Characterization Tests）

大規模修正の前に、現行の挙動を固定するテストを敷く。リファクタで既存挙動が変わったら即 Red になる網だ。修正対象の周辺 I/O・境界値を最優先で固定する。「安全網なしにコードへ触れない状態」を作ってから初めて、Codex に実装を渡す。

3. golden set — 体感の実測化

ドキュメント整合性検証に公開ベンチマークは存在しない。だから自環境で作る。実際の仕様書ペアに既知の矛盾（用語ゆれ・集約境界の齟齬・受入条件の欠落・前提矛盾）を意図的に埋め込み、Codex / Claude それぞれの recall（見逃さない率・最優先）と precision（誤検出率）を実測する。リグレッション対策では recall を最優先指標に置く。実測結果と、その結果が役割分担仮説をどう支持したかは第6回で詳述する。

✅ Definition of Done

以下をすべて満たして初めて Done。1 つでも欠けたら未完了として扱う。

  • ビルド: エラー・警告ゼロ
  • テスト: 全緑（exit 0）
  • レイヤ不変条件: アーキテクチャテスト全緑
  • TODO / NotImplementedException の残置なし
  • 特性化テストで既存挙動の非破壊を確認
  • Claude verifier が Codex 指摘の採否を確定し、未解決の仕様矛盾なし
  • 進捗文書の更新、設計判断があれば ADR 追記
  • 新たに見つかった欠陥クラスを golden set に登録

最後の項目が地味に効く。見つけた欠陥はその場で直して終わりではなく、測定資産に変換する。次の大規模修正で verifier の性能を測る問題集が、運用するほど厚くなる。

🚫 アンチパターン集

  • ❌ 逆順（Claude 実装 → Codex レビュー）。−8.6pt
  • ❌ finder の指摘ゼロを目指した周回（相関盲点は消えない → 検証ゲートを増やす方向へ）
  • ❌ 最上位モデルのサブエージェント常用・常時最大 effort（消費爆発。第6回）
  • ❌ 実装コードから着手（TDD + DDD の順序違反）
  • ❌ hook を通さず AI の「完了」宣言で Done 扱い
  • ❌ 陳腐化した文脈ファイルの放置・検証なき記憶参照
  • ❌ ドキュメント未更新のまま次の変更へ進む

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

序章

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

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

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

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

  1. 総論 — マルチ LLM の 2 系統と見取り図
  2. 裏取り編 — +18.1pt 論文の検証
  3. 設計編（本記事）
  4. TDD×ハーネス編 — テスト保護と三層ゲート
  5. 実装編 — Claude Code の中から Codex を動かす
  6. モデル戦略編 — ティア割当と「買うか組むか」

終章

  1. クロスファミリー検証の最終型 —「正しく作る」から「自分で正しさを測り直す」へ — 検証エンジンに「計測」の層をはめ、自己修正ループを閉じる

番外編

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

関連記事