📖 はじめに — 「その日」は、網を張っていない側から来た
終章はモデルマスタ台帳についてこう書いていた —「この台帳が本領を発揮するのは、次のモデル世代が来た日である」。その日は公開の 5 日後、2026 年 7 月 11 日に来た。ただし予想と違ったのが 1 点。台帳が検知網（statusline の初見 ID 検知・roster 突合・エイリアスプローブの三経路）を張っていたのは verifier の Claude 側で、世代交代が来たのは網の外にいた finder の Codex 側だった。
もう 1 つ、この日はモデル戦略編が置いた伏線の回収日でもある。「+18.1pt / −8.6pt という順序効果は特定モデルペアの実測であり、モデル世代更新のたびに golden set で再測して更新する運用パラメータとして扱う」— その再測トリガーの、初の実地発動だ。
結果だけ先に書くと、GPT-5.6 GA（7/9）から 2 日、以下がすべて同じ 1 日に流れた。
| 順序 | 出来事 |
|---|---|
| 1 | Codex CLI 更新（0.142.5 → 0.144.1）で実効モデルの切替点を実測特定（gpt-5.5 → gpt-5.6-sol） |
| 2 | モデルマスタ台帳に Codex 節を新設 —「未ピン＝CLI 既定追従」を意図した方針として明文化 |
| 3 | 較正チェック: 旧 golden set v1 を新世代で再実行（recall 100%・FP 同水準 = finder 特性維持） |
| 4 | 難化 golden set v2 を設計（設計レビュー 2 ラウンド）→ 2 家族 × 2 ラウンド・計 96 実行の本測 |
| 5 | 判定: recall は天井のまま動かず、precision に家族差（対照 FP: Codex 15 vs Claude 0）を実測 |
| 6 | 運用判定: 止める・変える項目はゼロ。監視を続ける注意点が 3 つ（過検出の増勢・effort 対応表の不在・サブスク枠の消費レート） |
「新モデルが出たので入れ替えました」ではない。入れ替わっていたことを特定し、劣化していないことを確かめ、分担の根拠を新世代で測り直すところまでが、この日の仕事である。
🕵️ 事件 — CLI 更新の「瞬間」がモデルを替える
まず実測ログから。cts-ec の開発コンテナで CLI を更新した、その前後だ。
$ codex --version
codex-cli 0.142.5
$ npm install -g @openai/codex@latest
...
added 1 package in 4.821s
$ codex --version
codex-cli 0.144.1
$ codex exec "which model are you?" --json | jq '.model'
"gpt-5.6-sol"更新前の同じ問いはこうだった。
$ codex exec "which model are you?" --json | jq '.model'
"gpt-5.5"このプロジェクトの Codex 呼び出しは、設定ファイルにも実行スクリプトにもモデル指定を持たない（config.toml に model= なし・codex exec に -m なし）。つまり実効モデルは CLI の既定に自動追従しており、その既定は CLI バイナリの内部で解決される。帰結はシンプルで強烈だ — 切替点は「CLI を更新した瞬間」であり、同一バージョンのままなら黙って変わらない。しかも CLI バージョンと既定モデルの対応表は公式 changelog に記載がなく、実測でしか確認できない。
罠 — TUI の表示と exec の実効は一致しない
切替点が「予測どおり」だったのには根拠がある。更新前の 0.142.5 の時点で、対話 UI（TUI）のモデルピッカーには既に gpt-5.6-sol が現れていた。しかし同じバージョンの codex exec は gpt-5.5 のままだった。対話 UI の表示は非対話実行の実効モデルを保証しない。ハーネスが使うのは codex exec なのだから、正とすべきは exec が返す実効モデル（バナーの model: 行）ただ 1 つ — この確認をワンライナー化して台帳に常備した。
🔀 二つのデフォルト追従 — サーバー側とバイナリ側
終章の検知三経路がなぜ効かなかったのかは、追従の機構を並べると一目でわかる。
| Claude（エイリアス追従） | Codex（CLI 既定追従） | |
|---|---|---|
| 既定の解決場所 | サーバー側（sonnet 等のエイリアスが最新版へ自動追従） | CLI バイナリ内部（バージョンごとに既定が固定） |
| 切替のタイミング | プロバイダ側の任意のタイミング（仕様非公開） | CLI を更新した瞬間のみ |
| 何もしないと | ある日突然変わり得る | 永遠に変わらない |
| 検知手段 | statusline の初見 ID 検知・定期プローブが有効 | サーバー側監視は無意味。更新直後の実測が唯一の網 |
同じ「デフォルトモデル追従」でも、リスクの形が正反対なのだ。Claude 側は「いつ変わるかわからない」リスクなので常時監視が効く。Codex 側は「変えたときにしか変わらない」ので、変えた瞬間（CLI 更新・そして CLI を導入し直す Dev Container の完全 Rebuild）を更新トリガとして手順に組み込むのが正しい防御になる。実際、台帳の更新チェックリストには「CLI 更新・Rebuild 後は exec バナーで実効モデルを再実測する」の 1 行が加わった。
ピン留めしない、という設計判断
なお「モデルをピン留めすれば済む話では」という選択肢は検討の上で不採用にした。ピン留めは切替タイミングを統制できる代わりに、世代リリースのたびに手動追従のコストを払い続けることになる。finder 側は（verifier と違い）新世代へ素早く乗ることの利得が大きく、切替点が「CLI 更新の瞬間」に限定されると特定できた以上、未ピン＝既定追従を「意図した選択」として台帳に明文化し、更新の瞬間だけ必ず疑う運用のほうが軽い。「暗黙のデフォルト」と「明文化された追従方針」は、同じ挙動でもリスクがまったく違う。
🧪 較正チェック — まず「劣化していないか」を安く確定する
モデルが替わったとわかったら、次の問いは「入れ替わった finder は大丈夫か」だ。ここで効いたのが、モデル戦略編で常設資産にしていた golden set である。矛盾を埋め込んだ仕様書セット（v1: 3 難化ケース + 対照 1）を、旧世代と同一プロトコル（中立化コピー・シャッフル・正解メタは repo 外）で新世代に流すだけ — Codex 側だけの再測なので追加実行は 8 回、即日で終わる。
| 指標 | gpt-5.6-sol（今回） | gpt-5.5（旧・参考） |
|---|---|---|
| recall | 6/6 = 100% | 6/6 = 100% |
| 対照（矛盾 0）への FP | 5 件 | 4 件 |
算術・遠距離参照・3 文の推移的連鎖のいずれも全試行で安定検出。FP の性質も旧世代と同カテゴリ（受入条件の欠落系の過検出）で、「high-recall・過検出気味の finder」という特性は世代を跨いで維持 — finder/verifier の役割分担を変える理由はない、とまず確定した。
ただしこの結果は同時に、v1 の限界も確定させた。両世代とも満点なら、v1 は世代間の能力差を何も測れていない（天井効果）。「劣化していないか」には答えたが、「新世代は何が変わったか」には答えられない。だから同じ日のうちに、難化版 v2 へ進む。
🎯 本測 — 難化 golden set v2 と、それでも動かなかった recall
v2 は 6 つの検出次元（複数ファイルへの矛盾分散・ドメイン暗黙前提・5 ホップの推移連鎖・多段算術・状態遷移表の 1 セル欠陥・境界値オフバイワン）に難化ケースを 1 件ずつ、加えて矛盾ゼロの対照を 2 件混ぜた 8 ケース構成。C1 = Codex（gpt-5.6-sol）と C2 = Claude を各ケース 3 試行ずつ実測し、C3（両者の和集合）は実測データから事後算出する。
測定設計そのものがレビューを通る
このシリーズの流儀どおり、測定プロトコルも文書レビューにかけた。初回レビューは条件付き承認で、MUST 指摘 3 件 — いずれも「測定の漏洩経路」だった。対照ケースの位置を設計書自身が記載していて被測定側が読めば特定できる（正解メタは repo 外へ）、難化判定の分岐条件に包含関係があり片方が死んでいる（排他 3 分岐へ書き換え）、read-only sandbox は読み取り全域可なので「到達できないから安全」は成り立たない（全試行のアクセスログ事後監査を必須化）。ベンチマークは作る側も盛大に間違える。測る前にレビューで殺せた誤りの分だけ、数字が信用できるようになる。
結果 — recall は 2 ラウンド連続の天井
| 指標 | C1（Codex / gpt-5.6-sol） | C2（Claude） |
|---|---|---|
| recall（初回 r1） | 18/18 = 100% | 18/18 = 100% |
| recall（難化反復 r2） | 18/18 = 100% | 18/18 = 100% |
| 対照への FP（r1+r2・12 試行） | 15 件 | 0 件 |
r1 が全問正解だったため、ケースを 80〜120 行に長文化し、矛盾両端の語彙を非対称にし、計算結果を文中から消して生パラメータの合成を要求する難化反復（r2）まで実施した。それでも両家族 72/72。たとえば「240,000 SKU ÷ 40 件/コール ÷ 3 コール/秒 ≒ 33 分 > 30 分の処理窓」という、文中のどこにも合計時間が書かれていない 3 パラメータ合成を、両家族とも全試行で自力再構成してくる。自己完結した 120 行以下の文書に矛盾を 1 件埋める形式では、もはや現行世代の recall は判別できない — これが 2 ラウンド連続で確定し、天井を結果として記録して終了した。
動いたのは precision — 家族差は「指摘しない力」に出る
recall が測れなくても、この本測は無駄ではなかった。矛盾ゼロの対照 2 件・計 12 試行への誤検出が、Codex 15 件 vs Claude 0 件。Codex の FP はすべて「文面に書かれていない仮説シナリオ」型（イベントの重複再送・並行競合・境界外テストの欠落など）で、ケースが長文化した r2 でむしろ増えた。一方 Claude は 12 試行で誤検出ゼロ。さらに Codex が検出した矛盾は Claude もすべて独立に検出していた（独立重複率 100%）。
つまり設計編以来の「Codex = 疑い深く網を広げる finder / Claude = 採否を確定する verifier」という分担が、今回初めて precision の側から実測で支持された。役割分担・パイプラインの向きとも変更不要。世代は替わったが、エンジンの設計は替える必要がない — それを「気がする」ではなく数字で言えるのが、再測をドクトリンにしておいた利得だ。
測定の限界も一緒に記録する
数字を独り歩きさせないため、限界も同じ文書に固定した。分解能は 1 検出 ≒ 5.6pt で微差は非決定性と不可分。裏取り編の +18.1pt は「実装 → レビューの順序効果」という別指標の外部実験値であり、本測の recall / precision と直接比較してはならない。全ケースの作成者が Claude 家族である以上、authorship バイアスは否定できない。そして recall<100% を測るには、自己完結文書という形式そのものを捨てて実文書規模（数百〜数千行・複数文書・リポジトリ横断）へ行くしかない — これは v3 の課題として起票候補に残した。
🧭 運用判定 — 止めるものはゼロ、見張るものが 3 つ
測定と並行して、ハーネスの配管も新世代で一巡確認した。exec の実効モデル、read-only / workspace-write 両モードの sandbox（実装編で確立した成立条件）、実装ヘルパの契約層（exit code の意味論・テスト改ざんガード）はいずれも正常動作。別セッションで流れていた実タスクの実装も gpt-5.6-sol のままふつうに完走した。世代交代の運用判定は「止める・変えるべき項目はゼロ」である。
ただし「監視を続ける」注意点が 3 つ残った。いずれも新しい仕組みは要らず、既存運用の徹底で足りる。
- 過検出（FP）は増勢にある。 同一条件の較正チェックで旧世代 4 件 → 新世代 5 件、v2 本測の中でも長文化ラウンドで 5 件 → 10 件と、世代でも文書長でも増える方向に動いた。gpt-5.6-sol は「文面に無い仮説シナリオ」を積極的に指摘する性格が強まっており、finder の指摘を verifier を挟まずに直接採用しないという分担の規律（設計編）が従来以上に効いてくる
- reasoning effort の対応表が存在しない。 旧世代との effort マッピングは公式に「存在しない」と明言されており、ハーネスは effort 未指定のまま既定に任せている。今後、実装品質に体感変化があれば第一容疑はここ — という 1 行を台帳に書いた
- 最上位ティアはサブスクリプション枠の消費が最速。 この日は測定 96 実行と実タスクの実装が並走しても問題なかったが、実装委譲を連投する日は消費状況を見る習慣だけ持っておく — 実はこの習慣が同日中に見つけたのは逆側の偏り（Claude 枠がタイトで Codex 枠が遊休 90% 超）で、その是正はもう 1 本の番外編「遊休 90% の枠に仕事を振る」に記録した
「問題なし」を宣言して終わりではなく、次に何が起きたら・どこを疑うかまで台帳に書いて閉じる — 較正チェックの数字が「安心」ではなく「監視項目」に変換されるのが、この運用の要点だ。
🧾 まとめ — 世代交代を「いつもの 1 日」にする
初代番外編は「平凡な CI 退行が検証エンジンの上をどう流れるか」の記録だった。本稿はその姉妹編 — モデルの世代交代という定期イベントが、同じエンジンの上をどう流れるかの記録である。学びを 3 行に圧縮する。
- デフォルト追従は家族ごとに機構が違う。 サーバー側で替わる Claude のエイリアスと、CLI 更新の瞬間にだけ替わる Codex の既定。片方に張った検知網はもう片方に効かない。追従を使うなら「暗黙のデフォルト」のままにせず、切替点と検知手段ごと明文化する
- 較正チェックは安いから先に打つ。 旧 golden set の再実行 8 回で「劣化していない・分担変更不要」がその日のうちに確定した。「新世代で何が変わったか」の前に「何も壊れていないか」を安く確定する順序が、世代交代を平時作業にする
- 天井も成果として記録する。 2 ラウンド難化しても動かない recall は「差がない」ではなく「この形式ではもう測れない」の確定であり、それが次のベンチ（v3）の要件定義になる。モデルが進化する以上、測る側も世代ごとに進化を強いられる
終章の言葉を借りれば、台帳は確かに本領を発揮した。ただしそれは「台帳に答えが書いてあった」からではない。知らないことが起きたときに、何を実測し・どこに記録し・どの数字で意思決定するかの手順が先に決まっていたからだ。次の世代交代 — それが Claude 側でも Codex 側でも — は、もう少しだけ静かな 1 日になるはずである。
📚 シリーズ記事（ステアリング駆動開発・実践編）
序章
第I部: 技術的負債ドメイン別の実録（総点検ガイド + 8 ドメイン・全 9 回）
- リファクタリング総点検ガイド — 7 つの観点と進め方
- DDD/SOLID/BC 編 — god class 一掃と境界の機械ガード
- SAGA 編 — 新アーキテクチャ挑戦と再発ゲート
- Atomic Design リファクタ編 — 47 page 新規移植
- Storybook × a11y 実機編
- テスト品質・網羅性編
- Python ジョブ群編
- パフォーマンス編
- セキュリティ編
第II部: 検証エンジン（クロスファミリー検証・全 6 回）
- 総論 — マルチ LLM の 2 系統と見取り図
- 裏取り編 — +18.1pt 論文の検証
- 設計編 — finder/verifier 分業と逆順禁止
- TDD×ハーネス編 — テスト保護と三層ゲート
- 実装編 — Claude Code の中から Codex を動かす
- モデル戦略編 — ティア割当と「買うか組むか」
終章
- クロスファミリー検証の最終型 —「正しく作る」から「自分で正しさを測り直す」へ — 検証エンジンに「計測」の層をはめ、自己修正ループを閉じる
番外編
- CI テスト 29 分 → 5.6 分 — 検証エンジンの平時運用実録 — 実測が有力仮説を殺し、退行前より速くなった 1 日
- GPT-5.6 sol 切替の当日実録 — もう一つのデフォルト追従（本記事）
- 遊休 90% の枠に仕事を振る — Codex 上流調査と verifier バッチ化 — 逆順禁止の境界を ADR で確定し、読む仕事を遊休枠へ移した 1 日
- ハーネスが単一プロジェクトを卒業する — プラグイン化と二層配布 — 4 プロジェクト展開への切り出しと、version + SHA ピンによる非強制追従
- 69分で5リリース — Opus 5 当日対応が暴いた共通ハーネスの死角 — 新モデル対応を起点に、配布・文書・CI の回帰を二消費者で検出した 69 分