Fable 5・Sonnet 5・Opus 4.8 の使い分けと golden set 実測 —「買うか、組むか」【クロスファミリー検証 第6回・最終回】

📖 はじめに — 「どの家族か」の次は「家族の中のどのモデルか」

シリーズここまでで、Codex（finder）× Claude（verifier）という家族の分担を固めた。最終回は Claude 家族の内側の話 — Fable 5 / Sonnet 5 / Opus 4.8 / Haiku 4.5 をパイプラインのどこに置くか、コストとどう折り合うか、そして効果をどう実測して標準運用に昇格させたか。最後に、総論で提起した「オーケストレーションを買うか、組むか」に答えを出す。

🗺️ 2026 年央の Claude ラインナップを整理する

まず前提知識として、本パイプラインに関係するモデルを整理する（価格は 2026 年 6 月時点の公表値・100 万トークンあたり入力/出力）。

重要なのは、Fable 5 は「Opus の置き換え」ではなく「Opus の上の別ティア」 だということ。単価は Opus 4.8 の 2 倍。全部を最上位に寄せる戦略は、パイプラインのように反復適用される仕組みでは即座に破綻する。

🎚️ ティア割当 — パイプラインのどこに、どのモデルか

CTS-EC の割当はこうなった。

原則 1: Fable 5 をサブエージェントに常用しない

Fable 5 は魅力的だが、2 倍の単価 × サブエージェントの頭数で消費が爆発する。fan-out する段に最上位モデルを置くのは、全席ファーストクラスで通勤するようなものだ。Fable 5 の出番は「Lead が難所と判断したときに、単発で選択的に」に限定する。

原則 2: effort 下限は「設定」でなく「構造」で保証する

運用ルールに「verifier は xhigh」と書くだけでは、モデル切替やセッション再作成のタイミングで既定値（high）に静かにリセットされる穴がある。CTS-EC では verifier を担う 2 つの agent 定義の frontmatter に effort: xhigh を明示し、この穴を構造的に閉じた（agent frontmatter の effort 指定は公式サポートされており、未指定だと親セッションを継承する — 継承任せが穴になる）。

第4回のレビュー漏れゲートと同じ思想だ: 人が覚えておくべきことを、設定ファイルが覚えている状態にする。

原則 3: 昇格はモデルごとに個別判断する

標準運用昇格の際、verifier 段の 2 agent のうち implementation-validator は Sonnet から Opus 4.8 へ昇格させたが、Red テストの相互レビューを担う agent は Sonnet 据え置きにした。Red フェーズは最大 2 周と回数が読め、コスト対効果が合わないからだ。「verifier 系はぜんぶ最上位」ではなく、段ごとの反復回数と品質感度で個別に決める。

📊 golden set 実測 — 外部の数値で運用を変えない

このシリーズで最も伝えたい規律がこれだ。+18.1pt は外部の統制実験値であり、CTS-EC の実測ではない。この区別を、採用判断の全工程で保った。

承認と実証の分離

1. 原則の承認: finder/verifier 分業・逆順禁止という設計原則は、外部実験の構造仮説（第2回）を根拠にオーナーが承認する
2. 効果の実証: 「自環境で効く」は golden set の実測で確認するまで主張しない。ADR にも「外部統制実験値であり自環境実測ではない」と明記した

golden set v1 の設計と結果

実際の仕様書ペアに既知の矛盾を埋め込み、Claude / Codex 両 verifier に検出させる（各 2 試行・正解メタは隔離・ファイル名も種別が漏れない中立名）。v0 は「矛盾が明示的すぎて全問正解」「対照ケースが本当に clean でない」という測定設計の不備があり、v1 で難化させた。

• recall は両者 100%。算術・遠距離・推移という難化ケースでも、この難易度では「一方だけが拾う」ダイバーシティ利得は観測されなかった
• 差は precision に出た。Codex は clean 対照に「実在しない矛盾」を両試行で報告（over-flag）。Claude は 0 件
• 含意: この precision 差は、論文由来の役割分担 — Codex = high-recall な finder、Claude = 精密な verifier — と方向が一致する自環境の実測だ。「finder が拾いすぎ、verifier が採否を確定する」二段構成が意味を持つことを、自分のデータで支持できた

ここまで揃え、さらに実パイプラインの試走（設計 → Codex 実装 → ゲート → Claude verifier → 差し戻し → 再ゲート → マージ）を 1 件完走させてから、標準運用に昇格させた。残課題も正直に書いておく — recall が 100% で飽和したため、クロスファミリーの recall 利得そのものはまだ実証できていない。recall < 100% になる難化版 v2（暗黙前提・複数ファイル分散・ドメイン知識依存）が次の宿題だ。

「向き」は恒久の真理ではなく、世代ごとに測り直す運用パラメータ

もう 1 つ、golden set を常設資産にする理由がある。+18.1pt / −8.6pt の非対称は Opus 4.7 × GPT-5.5 という特定モデルペアの実測であり、どちらかの世代が上がれば「レビューの利得 = 書き手が残す欠陥 × レビュアーの精密さ」の積は組み替わる — 向きが逆転する可能性すらある。だから「Codex 実装 → Claude レビュー」は一度決めたら終わりの原則ではなく、モデル世代更新のたびに golden set で再測して更新する運用パラメータとして扱う。

この再測トリガーは本稿公開の 8 日後、GPT-5.6 sol への世代交代で実際に発動した。当日中の較正チェックと難化版 v2 本測の実録は番外編第 2 弾を参照。

逆順禁止を運用ルールの文章でなくスクリプトのガードとして実装した（実装編）ことが、ここで効いてくる。将来の再測で向きが変われば、変えるのはガードの向きと ADR の 1 節だけでいい。原則を疑えない形で埋め込むのではなく、測り直せて、反転できる形で固定する — それが「承認と実証の分離」の完成形だ。

運用の細部: 偽仕様の汚染防止

golden set は「偽の仕様書」を含むため、通常のドキュメントツリーに置くと、後続セッションの AI が本物の仕様として拾う。隔離ディレクトリ + fixture マーキング（警告ヘッダ・専用命名・正解メタの別配置） で汚染を防ぐ。測定資産が本番の文脈を汚す事故は、やってみないと気づきにくい。

⚖️ 買うか、組むか — Sakana Fugu 時代の判断軸

総論で見たとおり、Sakana Fugu の登場で「マルチ LLM オーケストレーションを買う」選択肢が現実になった。Fugu Ultra は一部ベンチマークで Fable 5 に匹敵すると主張し、OpenAI 互換 API 1 本で裏の協調をすべて隠蔽してくれる。では自前のクロスファミリーは不要になるのか。

判断軸は「マルチ LLM に何を求めるか」だ。

つまり Fugu 型とクロスファミリー検証は競合ではなく、解いている問題が違う。「賢い答えが欲しい」なら買えばいい。「リグレッションを止める独立した網が欲しい」なら、束ねられた知能では代替できない — 網の価値は賢さではなく相関しないことにあり、相関しないことはワークフローの構造でしか保証できないからだ。

興味深いことに、Fugu のベータ検証ユースケースには code review が含まれる。オーケストラ型がレビュー市場に入ってくるのは時間の問題で、そのとき評価すべき問いは「レビューの質は高いか」ではなく「そのレビューは、実装と独立か」になるだろう。本シリーズで組んだ判断軸は、製品を買う場合の評価軸としてもそのまま使える。

🧾 シリーズ全体のまとめ

一連の設計を貫くのは、結局 1 つの姿勢だ — AI の申告でも外部の数値でもなく、自分で検証できる構造と実測で判断する。クロスファミリーは、その姿勢をモデル選定にまで適用した結果にすぎない。

ただし、このエンジンには、分かっていながらまだ埋めていない欠落が残っている。検証を強制する構造は完成したが、その検証が効いているか — 見逃し率・fallback 率・指摘の分布 — を測る層がまだない。この最後のピースが、独立に同じ思想へ到達していたもう 1 つのハーネスとの出会いによってどう埋まったかは、シリーズ終章「クロスファミリー検証の最終型」で描く。

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

序章

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 を Opus 4.7 → 4.8 に移行する — Opus 4.8 のハーネス調整
• ベクター検索の落とし穴 — 「実測で確かめる」姿勢の別事例

参考リンク（2026-07-03 時点で確認）

• Sakana Fugu: One Model to Command Them All（Sakana AI 公式）
• Sakana Fugu — Multi-agent System as A Model（製品ページ）
• Cross-Model LLM Code Review（ResearchGate）