ステアリング駆動開発（応用編）
実践編で整えた文書・テスト・品質ゲートを前提に、Codex と Claude のクロスファミリー分業、fail-closed な検証パイプライン、共通ハーネスへの展開、モデル更新への追従、検証装置自身の評価と剪定、実測知を要件プロファイルと機械検収へ広げる事業構想、さらに停止条件層によるループエンジニアリングへの到達までを実録で解説する。
全 15 回（公開済み 15 本）
マルチ LLM オーケストレーションの台頭とクロスファミリー検証 — Sakana Fugu から Codex×Claude まで【シリーズ総論】
複数の AI モデルを束ねる動きが 2026 年に一気に加速した。Sakana Fugu のような「学習されたオーケストレーション」製品の登場と、Codex×Claude のクロスファミリー検証運用。マルチ LLM の 2 つの系統（オーケストラ型とチェック・アンド・バランス型)を整理し、実プロジェクトで標準運用に至った全 6 回シリーズの見取り図を示す。
「Codex 実装 → Claude レビュー」+18.1pt 論文を裏取りする — 両者のレビューは何が違うのか【クロスファミリー検証 第2回】
「Codex 実装 → Claude レビューが最良（+18.1pt）、逆方向は有害（−8.6pt）」という KDD '26 論文の数値を一次ソースで照合し、桁まで一致することを確認した記録。Claude と Codex のレビュー観の違い（自己検証の重さ・high-recall と precision・自己レビューの非対称）を、論文と自環境実測の両面から整理する。
指示書からパイプラインへ — finder/verifier 分業・二層の網・逆順の構造的禁止【クロスファミリー検証 第3回】
「Codex 実装 → Claude レビュー」を実運用に落とす設計編。4 つの原則、役割分担、TDD+DDD ワークフロー、コンテキストエンジニアリング規約、決定論ゲート＋特性化テスト＋golden set の防御網、Definition of Done、そして汎用指示書を自プロジェクトに翻案するときに変えた点・変えなかった点を全て記す。
Red テストは verifier 家族の資産 — テスト改ざんガード・レビュー漏れの機械クローズ・自己評価遮蔽【クロスファミリー検証 第4回】
クロスファミリー検証の威力を底上げする、見落とされがちな層 — ハーネスとステアリング。TDD の Red テストを Claude（verifier 家族）の資産として Codex から checksum で機械保護し、レビュー漏れを三層ゲートで構造的に塞ぎ、handoff から実装者の自己評価を遮蔽する設計を詳解する。
Claude Code の中から Codex を動かす — MCP を使わない判断と sandbox の地雷【クロスファミリー検証 第5回】
クロスファミリー検証で最も泥臭かった実装の記録。MCP でなく codex exec + シェルを選んだ積極的理由、Dev Container で bwrap sandbox を成立させる 3 条件、「sandbox 全滅でも exit 0」という最大の地雷、sudo で逆に壊れる罠、そして運用判断を埋め込んだ exit code 意味論まで。
Fable 5・Sonnet 5・Opus 4.8 の使い分けと golden set 実測 —「買うか、組むか」【クロスファミリー検証 第6回・最終回】
クロスファミリー検証パイプラインのモデル戦略編。Claude 5 ファミリー（Fable 5 / Sonnet 5）と Opus 4.8 のティア割当、effort 運用（xhigh 下限の構造的保証）、Fable 5 をサブエージェントに使わない理由、golden set v1 の自環境実測、承認と実証の分離、Sakana Fugu 時代の「買うか組むか」の判断軸で締める。
クロスファミリー検証の最終型 —「正しく作る」から「自分で正しさを測り直す」へ【終章】
ステアリング駆動開発（応用編）の本編終章。検証を強制するハーネスに欠けていた「計測」の層を、独立に同じ思想へ到達していた個人開発ハーネスとの相互レビューから取り込む。finding-level 台帳・モデルドリフト検知・実痛駆動の剪定 —「完成」とは終わることではなく、自分の劣化を自分のデータで検出するループが閉じることである。
CI テスト 29 分 → 5.6 分 — 実測が「有力仮説」を殺し、退行前より速くなった日【番外編】
ステアリング駆動開発（応用編）の運用実録。検証エンジンが「平時の 1 タスク」をどう流すかを、CI のテストジョブが数日で 14 分 → 29 分に倍増した性能退行の是正で追う。起票から実測・オーナー承認・Codex 実装・CI 実測までを 1 日で完了し、最後は退行前の 11.5 分すら「健全ではなかった」ことが判明するまで。
GPT-5.6 sol に 2 日で準拠する — CLI 更新が黙って替えるモデルと、当日中の golden set 再計測【番外編】
ステアリング駆動開発（応用編）の運用実録第 2 弾。GPT-5.6 sol GA の 2 日後、Codex CLI の更新が finder の実効モデルを gpt-5.5 から gpt-5.6-sol へ黙って切り替えた。サーバー側で替わる Claude のエイリアスと、CLI バイナリ側で替わる Codex の既定 —「もう一つのデフォルト追従」を実測で特定し、台帳への明文化・v1 較正チェック・難化 golden set v2 の本測までを記録する。
遊休 90% の枠に仕事を振る — Codex 上流調査・段別モデル・verifier バッチ化【番外編】
ステアリング駆動開発（応用編）の運用実録第 3 弾。Claude 側のサブスク枠がタイトな一方、Codex Pro は遊休 90% 超 — この非対称を、逆順禁止の骨格を崩さずに解消する。「read-only 調査は逆順か」を ADR で確定し、調査に偽装した逆順・欠落バイアスという残余経路まで塞ぎ、verifier バッチ化をスクリプト変更ゼロで成立させるまで。
ハーネスが単一プロジェクトを卒業する — cts-harness プラグイン化・二層配布・バージョンピン【番外編】
ステアリング駆動開発（応用編）の運用実録第 4 弾。CTS-EC で 3 か月運用したハーネスを、CTS-POS / CTS-LOGI / CTS-AD への展開に向けて共通プラグイン cts-harness へ切り出した記録。プラグイン層と dist 層の分割、ホストリポジトリ契約、共有禁止の線引き、version + SHA のプロジェクト別ピン、更新サイクルの実走までを扱う。
69分で5リリース — Claude Opus 5 当日対応が暴いた共通ハーネスの死角【番外編】
Claude Code 共通ハーネスを Opus 5 へ当日移行。69 分で 5 回のリリースを重ね、公開後も v0.13.2 まで model 指定、teammate の定義本文欠落、hook スキーマの無言回帰を修正した実録。
「最高品質ですか？」に Yes と答えないハーネス — v0.14.0 から v0.15.2、足す設計から測って捨てる設計へ【現在地】
ステアリング駆動開発（応用編）第13回。tdd-team 後半を Dynamic Workflow 化した v0.14.0、実 run が出力契約と測定の穴を暴いた v0.14.13、誤った網羅性検査を撤去した v0.15.0、改善候補を実害基準で選別した v0.15.2。その版履歴を変更一覧ではなく証拠として使い、クロスファミリーハーネスが理想形に近いと言える範囲と、なお「最高品質」と言えない未検証領域を切り分ける。