GPT-5.6 SolとClaude Fable 5を比較：用途・検証・総コストで選ぶ

2026年7月21日時点の実務的な結論は、ターミナル実行や仕様どおりの実装ではGPT-5.6 SolをCodexで先に試し、長い設計や大規模な文脈ではClaude Fable 5をClaude Codeで先に試す、です。ただし、これは採用結果ではなく試行順です。推論設定、ハーネス、実効モデル、課金経路を分け、両方を同じ受け入れテストへ通すまで既定ルートは変えません。

重要なのは、ローカルチェック通過と「受け入れ可能な成果」は同じではないことです。テストが緑でも、重要な不変条件を確認していなければ false success（見かけの成功）です。本稿は新しいSol対Fableの実測値を捏造しません。Fableを同じ環境で実行した監査可能な自社データがないため、本稿の独自成果は勝敗表ではなく、公開された方向性のある証拠と公式契約を分け、false successを採用前に落とすための評価票、判定式、停止条件です。この道具を使って自社結果を作るまでは、標準ルートを変えないでください。

“

三つの判断: 最初の試行はタスク形状で選ぶ。既定値は受け入れ済み成果で選ぶ。帰属または契約を説明できない実行は、ベンチマークが高くても停止する。

なぜGPT-5.6 SolとFable 5の比較結果は割れるのか

「どちらのモデルが強いか」という一行だけでは、実務結果を説明できません。最低でも次の四層を別々に記録します。

OpenAIの公式モデルガイドはSolを複雑なコーディング、computer use、research、cybersecurity向けの旗艦モデルと位置付け、Codex Powerの既定をSolのmedium reasoningとしています。一方、AnthropicはFableを長時間のコーディングや知識作業に向く最上位の一般提供モデルとして説明しています。どちらも「あなたのリポジトリで必ず勝つ」という証拠ではありません。

日本の検索結果でも検証条件の重要性が見えます。DevelopersIOのProject Euler比較では、同じモデルでも推論設定と最終検算の有無で正誤が変わりました。ここから安全に得られる教訓は特定問題の勝敗ではなく、部分チェックが通っても最終不変条件を確認しなければ採用できないという評価原則です。数学二問の結果を、ソフトウェア開発や日本語資料の万能順位へ外挿してはいけません。

公式ベンチマークは「試す仕事」を決める材料にする

OpenAIが2026年7月9日のGPT-5.6発表に掲載したコーディング関連の四行では、先頭が入れ替わります。

これはOpenAIが公開した比較表であり、中立なCodex対Claude Codeの同一ハーネス試験ではありません。尺度、課題、推論設定が異なる行を平均して独自の「総合点」を作ると、差の理由が消えます。SWE-Bench ProでFableが先行することはrepo試験の候補理由、Terminal-BenchでSolが先行することはterminal試験の候補理由です。どちらも本番既定値の自動決定ではありません。

false successを落とす「受け入れ可能な成果」ゲート

コードが生成された、コマンドが終了した、目に見えるテストが通った――ここで評価を終えると、両モデルの自信ある誤りを成功として数えます。日本チーム向けの評価では、成果を次の順に通します。

1. 局所チェック: lint、公開テスト、ビルドなど、実行者にも見えている確認。
2. 隠れた受け入れ条件: 事前に評価側だけが保持したhidden testや失敗ケース。
3. 仕様の不変条件: 互換性、権限、データ境界、既存挙動など、変更後も守る条件。
4. 匿名レビュー: モデル名と実行順を隠し、修正量・説明の正しさ・運用可能性を判定。
5. 受け入れ: 人が中核解決を作り直さず、マージまたは納品できる成果だけを集計。

局所チェックで合格しても、2または3で落ちれば不合格です。一回の修復を許すなら両経路に同じ失敗情報を渡し、二回目も落ちたらkeep currentまたはstopにします。高い推論設定へ自動で上げ続けるのではなく、失敗コストに応じて検証を厚くします。

そのまま使える日本語評価票

比較前に一枚の評価票を作り、結果を見る前に昇格条件を書きます。次の列が最小構成です。

二番目の経路へ一番目のdiff、テスト失敗、レビューコメントを見せません。タスクごとに実行順を入れ替え、新しいworktreeまたは同等のクリーン状態から開始します。CodexとClaude Codeのツールを完全に同じにできない場合は、差を隠すのではなくハーネス差として記録します。

評価タスクA：hidden testがあるリポジトリ修正

題材は、複数ファイルにまたがる小さなバグ修正を一件選びます。入力には症状と公開仕様だけを渡し、評価者は事前に次を固定します。

• 変更してよいファイルと、守るべき互換性。
• 通常のテストに現れない境界値または回帰ケース。
• 一回目の自律実行と、一回だけ許す修復の時間枠。
• 危険なコマンド、無関係な書き換え、依存追加の拒否条件。
• マージ可能かを判断するreviewerと、許容する人手修正量。

結果欄には「テスト数」ではなく、初回受け入れ、修復後受け入れ、人間介入、review分、実効モデル、rollback可否を書きます。hidden testが落ちたのに公開テスト合格だけを成功として数えないことが、このタスクの価値です。

評価タスクB：日本語の一ページ意思決定資料

もう一件は、同じrepositoryと公式資料から、経営・運用担当が読める一ページの日本語メモを作らせます。英語coding benchmarkでは測りにくい日本語の納品品質を、次の受け入れ条件で判定します。

• 主要な事実の直後に正しい一次資料があり、日付と適用条件が明記されている。
• 製品名、モデル名、API、プラン、推論設定を混同していない。
• 敬体または常体、用語、数字、単位が一貫している。
• 推奨、事実、推測が読み分けられ、未確認事項を断定していない。
• 読者が次に確認する画面、停止する条件、承認者が具体的である。

このタスクも文字数や流暢さだけで採点しません。引用の誤帰属、重要条件の欠落、自然だが実行不能な提案は不合格です。本稿ではこの二タスクの新しいSol対Fable実行結果は提示していないため、上の表は評価設計であって実測結果ではありません。実際の標準変更には、各社が自分の環境で埋めた結果が必要です。

2026年7月21日時点の提供経路とAPI契約

アクセスできる製品と、課金されるAPIを同じ「利用可能」にまとめないでください。

OpenAIの提供範囲はGPT-5.6発表、API価格と272K超の全リクエスト倍率はSolモデルページと公式pricing、モデル選択はCodexモデルガイドで確認できます。Anthropic側はFable公式ページとFable API文書が一次資料です。

プラン、地域、workspace管理者、rolloutにより表示は変わり得ます。第三者のplaygroundやgatewayにモデル名が表示されても、公式の無料API権利やfirst-party contractの証明にはなりません。提供者、鍵の所有者、quota、保持、実効モデル、試用終了後の課金を確認できなければ機密コードを送らないでください。

Fableにはもう一つ費用上の注意があります。Anthropicのtoken counting文書は、Fable 5がOpus 4.7で導入されたtokenizerを使い、旧モデルより同じ文章でおよそ30%多いtokenを生成すると説明しています。これは各requestの固定倍率ではありません。移行時はclaude-fable-5で実payloadを数え、旧モデルのtoken数をそのまま掛けないでください。

API単価ではなく、採用できた仕事の総コストを比べる

標準API定価で入力20万・出力4万tokenの一回を単純計算すると、Solは0.2 × $5 + 0.04 × $30 = $2.20、Fableは0.2 × $10 + 0.04 × $50 = $4.00です。この例はSolの入力272Kしきい値より下です。入力が272Kを超えるSolリクエストは、現在リクエスト全体が入力2倍・出力1.5倍、つまり標準表で入力$10/M・出力$45/Mになるため、$2.20の例を大文脈へ外挿しないでください。cache、tier、retry、tool、地域条件、subscription credit、人間のreviewは含みません。

実務では次を使います。

受け入れ済み成果あたりのコスト =(全試行のモデル料金 + 外部tool／CI料金 + review人件費)÷ 受け入れ済み成果数

受け入れ済み成果が0件なら割り算をせず、そのbatchを失敗として停止します。subscriptionで一件あたりの金額を合理的に割れない場合も0円にせず、credit消費、制限到達、待機、review時間を別欄に残します。

判断を速くする補助線として、reviewerのloaded costを時給$120と仮定すると、追加のモデル費用$1はreviewを30秒以上短縮して初めて損益分岐です。式は$1 ÷ $120 × 3600秒 = 30秒です。これはプロバイダーの価格主張ではなく、自社の人件費に置き換えるための例です。品質、安全、契約違反は時間短縮で相殺しません。

default、specialist、fallback、stopを結果前に決める

15%改善などの閾値を置くなら、結果を見る前に決めます。その数字は各社の推奨値ではありません。自社の通常ばらつきより大きく、説明可能な値にしてください。一件の印象的な成功を全社defaultへ広げず、terminalだけで勝ったSol、長い設計だけで勝ったFableをspecialistとして残す判断も有効です。

Opus 4.8を比較から完全に消してはいけない理由

このページの主役はSolとFableですが、canonical slugに残るOpus 4.8には運用上の意味があります。Anthropicによると、多くのClaudeアプリケーションでは安全策に該当したFableリクエストがOpus 4.8へ自動的にrouteされる場合があります。そこで得た成果はFableの点数に加えず、Opus 4.8を含む実際の製品経路へ帰属させます。

Claude APIは別です。claude-fable-5を指定しただけで自動fallbackが有効になるわけではなく、API利用者がFallback APIを明示的に構成する必要があります。選択画面のモデル名、requested model、effective modelを分けるのは、この違いを追跡するためです。

製品全体のプラン、権限、速度、使用量上限を比較したい場合はClaude CodeとCodexの総合比較、GPT-5.6ファミリー内の使い分けはSol・Terra・Luna比較、API料金の契約単位はClaude APIとOpenAI APIの料金比較へ進んでください。

導入前チェックリスト

• 同じcommit、入力、添付、権限、時間枠、受け入れ条件を使った。
• medium／high／max／ultraを別の試行として記録した。
• requested model、effective model、harness版、fallbackを保存した。
• 二番目の経路へ一番目のdiffや失敗情報を渡していない。
• 公開テストだけでなくhidden testと仕様の不変条件を通した。
• 日本語資料では引用、用語、条件、例外、次の行動を確認した。
• API料金、subscription credit、retry、CI、review分を混同していない。
• 保持・安全・データ境界をコスト平均とは別の拒否条件にした。
• defaultとspecialistを分け、既存fallbackの動作を試した。
• 受け入れ0件、実効モデル不明、rollback不能なら停止した。

GPT-5.6 SolかClaude Fable 5かを決める最短ルートは、より大きな表を探すことではありません。二つの代表タスクを同じ条件で走らせ、false successを受け入れゲートで落とし、採用できた成果の総コストを比べることです。その証拠がそろうまでは、Solはterminal／仕様実装の先行候補、Fableは長文脈／設計の先行候補、現行経路はfallbackとして扱うのが安全です。