Claude Fable 5が使えなくなったら?AI司令塔三つ巴の結末

高さの違う3つの台座と、その上に浮かぶ小さな円の線画

AI導入 · 2026-07-30 · 8分

3つの司令塔が出そろいました。9本の成果物を並べて、どの組み合わせが良さそうかを見比べます。

前回: Claude Opusは司令塔になれるか — FableとOpusの差を実測

連載「Claude vs Codex アリーナ」、今回が最終回です。

ここまで、Claude Code(モデル: Fable 5)と Codex(モデル: GPT-5.6-Sol、reasoning effort: ultra)の司令塔比較、そして前回は第3の司令塔候補 Opus 4.8 との差の実測まで進みました。

最終回は、この三つ巴の顛末を時系列で振り返りながら、実験全体の学びを協調開発エンジン「ModelOrcs」へ引き継ぐまでを書きます。

本記事は1つの課題・各体制1回の観測(n=1)の記録であり、モデル一般の優劣を示すものではありません。

三つ巴に至る道のり(おさらい)

経緯の詳細は前回(第4.5回)に書いたので、ここでは要点だけ振り返ります。

そもそもの動機は、Fable 5 が定額プランから外れる可能性——実験当時「7月19日以降は使えなくなるかもしれない」という状況——でした。

乗り換え先の下見として、Opus 4.8 を司令塔に試すことにしたのです。

その途中には、レビュー用の新規 Fable セッションがターンの途中から Opus に切り替わっていた「替え玉レビュー事件」もありました。

Anthropic の公式サポート記事の説明によれば、Fable には安全機構(safeguards)があり、特定の内容ではターンの途中でも自動的に Opus へ切り替わる仕様とされています(2026年7月確認時点)。

fail-closed 検証器がモデルの混在を検出してレビューを無効化し、safeguards も検証器も設計どおりに働いた——そして期せずして「Opus が Fable の代わりを務める」予告編になった出来事です。

比較は2段階で行いました。

完成済み2案の融合工程だけを替えた replay では、Opus 融合版 63.63点 vs Fable 融合版 47.84点(+15.79)。

ただしこれは融合担当限定の比較で、司令塔の仕事の大部分を測っていません。

そこで Round 4 では、公開ベースからレーン全体を Opus に任せ、sandbox 不成立の修正と2回の capacity 中断・自動再開を経て、レーンは完走しました。

こうして3司令塔×3成果物=9本が出そろいました。

3レーンの経過を1枚にすると、次のようになります。

Fable・Codex・Opus 3司令塔レーンの経過タイムライン 観測wall windowはFable約6時間10分、Codex約3時間30分、Opus約14時間21分。Opusレーンにはsandbox不成立と修正、2回のcapacity中断と自動再開のイベントを含む。バーの長さは待ち時間込みの観測窓であり、モデルの思考速度ではない。 3司令塔レーンの観測 wall window(中断・待ち時間を含む) 0h 3h 6h 9h 12h 15h Fable 約6時間10分(pause / resume 含む) Codex 約3時間30分(recovery 含む) Opus sandbox不成立→修正 capacity中断(1)→自動再開 capacity中断(2)→自動再開 完走 約14時間21分(sandbox修正・人間承認待ち・capacity待ちを含む。worker/Mixプロセスの実働合計は約2時間04分) ※ バーの長さは観測 wall window。Opusレーン上のイベント位置は発生順を示す模式配置であり、正確な時刻ではありません。
3司令塔レーンの観測経過。停止・待機を含む wall window と、モデルが処理していた時間は分けて読みます。

時間の読み方だけ注意してください。

Opus レーンの約14時間21分の大半は障害・承認・供給待ちで、プロセスの実働は合計約2時間04分です。

wall time の差をモデルの思考速度と解釈することはできません。

一方で、障害から安全に復旧して完走できるかは、長い工程を預ける際の立派な評価項目です。

全9パターンを見比べる — どの組み合わせが良さそうか

3レーン×3成果物=9本が出揃った後、9本を凍結し、新しい seed で生成した同一の新規データで全候補を採点し直しました(評価実行 eval4-20260718-r3)。

順位は次のとおりです。

順位司令塔レーン成果物
1FableCodex solo65.07
2CodexCodex Mix58.32
3CodexCodex solo57.07
4OpusCodex solo55.89
5OpusOpus Mix48.15
6FableFable Mix47.84
7CodexClaude/Fable solo45.36
8FableClaude/Fable solo44.30
9OpusClaude/Fable solo42.92

この表が、連載全体の答え合わせです。

全パターンを見比べて言えることを、順に挙げます。

  • 最も良さそうなのは、Fable 司令塔 + Codex ワーカー(65.07)。頂点はこの組み合わせでした。
  • 次点は Codex 司令塔のレーン。Codex Mix 58.32 と Codex solo 57.07 が全体の2位・3位に入りました。
  • Opus 司令塔のレーンは中位。最高点はやはり Codex ワーカーの成果物(55.89)で、Fable 主導には届かなかったものの、レーンとして完走する運用力は示しました。
  • そして、どの司令塔の下でも成果の軸は Codex ワーカーでした。Claude/Fable ワーカーの solo は、3レーンとも下位に沈んでいます。

私たちが見たかったのは「Opus が優位かどうか」の証明ではなく、司令塔を替えると何がどう変わるかでした。

答えはこうです。

順位の入れ替わりは起きず、成果を左右するのは司令塔単体でもワーカー単体でもなく、組み合わせだった。

これは「Opus は Fable より劣る」という一般論ではありません。

1課題・1組の評価データ・各レーン1回の観測で、指示条件にも完全にはそろっていない部分が開示付きで残っています。

加えて、どのレーンもワーカーは Fable と Codex に固定しており、「Opus 司令塔 × Opus ワーカー」のような構成は試していません。

言えるのは、今回は司令塔の交代よりも、司令塔とワーカーの組み合わせ方が結果を左右した、という範囲までです。

また、9本の precision は 5.75〜11.32%(合成 oracle=機械生成した正解データとの一致率であり、本番の精度ではありません)。

1位の成果物でも 11.32% です。

順位が付いたことと、メール送信・値下げ・発注を無人で任せられることは別問題で、どの成果物も人間レビューを挟む候補抽出アシスタントという位置づけが妥当です。

実験全体で私たちが学んだこと

連載を通じた教訓を絞ると、次の5点です。

  1. AIの成果には来歴の検証が要る。 替え玉レビュー事件は、fail-closed 検証器があったから発見できました。モデル・入力・停止と再開を記録し、前提が崩れたら疑わしきは止める。止まることは失敗ではなく、比較条件を壊したまま進まないための機能です。
  2. 便利な短縮実験は、問いをすり替えやすい。 +15.79 は正しい数字でしたが、答えていた問いは当初と別物でした。単体ワーカーの生成力・2案を融合する力・レーン全体を障害込みで完遂する力は別の能力であり、測定範囲より大きな名札を付けないことが要ります。
  3. 時間とスコアは別の帳簿に付ける。 wall time には障害・待ち・承認が混ざります。分けなければ、速いモデルと運の良いレーンを取り違えます。
  4. 融合は土台選びで決まり、融合物は第三の成果物として再検査する。 2案の長所を足せば必ず良くなるわけではなく、元の候補がテストに通ったからといって融合物の検査は省略できません。
  5. 中断を例外ではなく通常運転として設計する。 再開できる状態保存、再試行する条件、止める条件、人間へ戻す条件があって初めて、AIに長い工程を預けられます。そして今回の全構成が、人間レビュー前提の品質でした。

7月20日以降どうする? — 司令塔の組み方3つの選択肢

この実験を進めていた時点では、Fable 5 が定額プランから外れる可能性があり、連載で司令塔の主役だった構成が使えなくなるかもしれない状況でした。

結果としてプランによって扱いが分かれることになりましたが(下記)、「特定のモデルが使えなくなったらどうするか」という問い自体は残ります。

今回の実験から言える範囲で、選択肢を整理します。

その後の続報: 本連載の実験を行った時点では先行きが不明でしたが、Anthropic の公式ヘルプセンターの説明によれば、2026年7月20日以降、Fable 5 は Max プランおよび Team のプレミアム席ではプランに含まれ、週次の利用上限の最大50%までを追加費用なしで Fable 5 に充てられる形になりました(加算ではなく、他モデルの利用も同じ上限を共有します)。一方 Pro プランや Team の標準席では従量課金のクレジット扱いです。また Fable 5 は他モデルより上限の消費が速いとされています。つまり「Fable がまったく使えなくなる」という前提は、プランによっては外れたことになります。本記事の実験は、この結論が出る前の状況判断のもとで行われたものです。提供条件は変わり得るため、最新の条件は必ず公式情報で確認してください(2026年7月20日時点)。

さらに続報: 2026年7月24日、Anthropic は Opus 4.8 の後継となる「Claude Opus 5」を発表しました。公式発表によれば、Fable 5 に迫る性能を約半額の料金で提供するとされています。本連載の実験と数値はすべて Opus 4.8 によるものです。最新のモデル構成と提供条件は必ず公式情報で確認してください(2026年7月27日時点)。

  1. Fable を使い続ける — 今回の1課題では、最良の成果物を引き出したのは Fable 司令塔レーンでした。Max プランなら週次上限の枠内で、Pro なら従量課金のクレジットで。いずれも品質最優先で、消費と費用を実測しながら使う選択肢です。
  2. 司令塔を Opus や Codex に交代する — Opus は障害からの安全な停止・再開と完走を実証し、Codex は最も点の高い Mix を作りました。ただし今回の結果は1課題の観測であり、交代すれば同じ品質が出る保証はありません。
  3. 司令塔を交換可能にする — 特定モデルへの依存自体をやめ、司令塔もワーカーも差し替えられる体制を組む。実際、本記事の公開直前にも後継の Opus 5 という新しい候補が現れており、モデルの顔ぶれはこれからも変わり続けます。私たちが選んだのはこの道で、それが次の ModelOrcs です。

そして ModelOrcs v0.1 へ

この連載はもともと、「Claude と Codex を並列で走らせ、機械採点と判定で良い方を採用・融合しながら開発を進めるエンジン」を作るための助走でした。

上の教訓を反映した協調開発エンジン ModelOrcs v0.1 が形になりました。

リポジトリは現在非公開ですが、公開準備(コード・履歴の監査や整備)が整えば、OSSとして公開することも検討しています。

設計には、今回痛い目を見た箇所がそのまま境界線として入っています。

worktree 分離・並列実行・タイムアウト・再試行・状態保存・採点集計といった決定論的な制御はプログラムが担い、LLM には生成・批評・融合だけを任せる。

1工程の流れは次のとおりです。

  1. 同じ Base SHA から Claude 用と Codex 用の worktree を分け、候補を並列生成する
  2. 共通テストと機械採点を先に行い、候補名を伏せた構造化判定へ渡す
  3. 候補Aの採用・候補Bの採用・融合・人間への停止のいずれかを、エンジンが判定結果どおりに機械的に実行し、判定理由を必ずログに残す
  4. 採用物または融合物で全テストを再実行し、懸念があれば人間へ戻す。マージは人間が行う

なお、候補名を伏せる匿名判定は公平の保証ではなく、判定の偏りを減らすための一策です(LLMによる判定には位置などのバイアスが残り得ます)。

採点式や判定条件などの詳細は、ここでは書きません。

v0.1 は生まれたばかりで、性能について語れることはまだありません。

この連載の結果が協調方式の性能を証明したわけでもありません。

確かめる実験は、この連載と同じく証跡を残しながら別途行います。

連載を締めるにあたって

同じ質問から提案がまったく違った第1回から、審査員が入れ替わった最終回まで、一貫していたのは「AIの出力を信じる前に、確認の仕組みを作る」ことでした。

AIを増やすだけでは協調にはなりません。

誰に何を任せ、どの物差しで比べ、どこで止め、人間が何を引き受けるか。

モデルはどれも優秀で、どれも単独では信頼の根拠にならない。

体制と検証こそが品質を決める——n=1 ながら、それが私たち MIF の実感です。

AIをどちらか選ぶ時代から、AIの使い方を設計する時代へ。

この連載がその参考になれば幸いです。

お読みいただきありがとうございました。

この連載(全6回)

  1. 同じ質問から始めたら、提案がまったく違った
  2. コネクトフォー100番勝負 — ボット同士が盤上で決着をつける
  3. 同じECデータから売上機会を探すAI — 設計思想はどう分かれるか
  4. 融合は単体を超えるか — 2つの成果物を混ぜた「Mix」の実力
  5. Claude Opusは司令塔になれるか — FableとOpusの差を実測
  6. 司令塔三つ巴のまとめとModelOrcs誕生(本記事)
記事一覧へ戻る