Claude CodeでFable 5.1とOpus 5.5をどう選ぶか──実測・利用者の声・effortから作る判断表【2026年】

1. 結論：Opusから始め、失敗の種類でeffortかFableを選ぶ

Claude CodeでFable 5.1とOpus 5.5のどちらを選ぶか。2026年10月29日時点で、最も再現しやすい出発点はOpus 5.5の既定effort（medium）で作業し、結果の不足を観察してから設定を変えることだ。Anthropicのモデル選択ガイドも「ほとんどの作業はOpus 5.5から」と明記し、Fable 5.1は高度な推論、長時間のエージェント作業、またはOpusの高いeffortでも要件を満たさない場合に勧めている。これは提供元の推奨であり、あらゆるコードベースに対する実測済みの勝者という意味ではない。^[1][2]

判断は二つの問いに分けると簡単になる。必要なファイルを読まず、テストもせず、作業を途中で切り上げたなら、まず文脈・指示とeffortを点検する。関連情報を渡し、十分に調べたのに設計や原因の判断が外れたなら、Fableを試す。AnthropicのClaude Code解説も「試し方が足りなかったか、知識・判断力が足りなかったか」で分けている。^[6]

この表は公開資料を組み合わせた筆者の運用提案である。ファイル数や工程数だけでFableへ切り替える規則ではない。10ファイルの修正でも難しいのは「正しい直し方」の判断かもしれず、数十ファイルでも手順が明確ならOpusやSonnetで完了する。作業の規模と、推論の難しさを混同しないことが肝心だ。

2. 新旧と上下は別の軸──2026年のモデル配置

Fable 5.1は2026年9月1日、Opus 5.5は同月22日の公開で、版の新しさはOpusが上だ。現在のClaude APIの主な系列にはFable 5.1、Opus 5.5、Sonnet 5.5、Haiku 5.5があり、Fableは公開利用できる最上位の能力枠、Opusは複雑なエージェント開発や知識労働の主力として案内されている。両者のコンテキスト窓はともに100万トークン、最大出力もともに12万8000トークン。巨大なリポジトリを読める窓がFableだけにあるわけではない。^[3][4][1]

Claude Codeの公式文書は、Fableについて長い自律実行、行動前の調査、自己検証に向くと説明する。一方で、Fableはどのプランでもアカウントの初期モデルではなく、明示して選ぶ必要がある。/model fable と claude --model fable が基本で、接続先によって別バージョンへ解決される場合はモデルIDを確かめる。opusも接続先で解決先が変わり得るため、実験では表示された実モデル名を記録したい。^[5]

ここで「発売が新しいからOpusが必ず上」「最上位系列だからFableが必ず上」とは決められない。性能は課題と設定で交差する。さらにClaude Codeという道具の指示ファイル、利用可能なツール、許可設定、テスト環境でも完成度は変わる。モデル比較に見える差が、実は渡した文脈の差であることを避けたい。^[6]

モデルの選択は「どの能力を呼ぶか」、effortの選択は「どこまで調べて確かめるか」。同じつまみではない。

3. ベンチマークは何を示し、何を示さないか

AnthropicがOpus 5.5公開時に掲載した評価では、Terminal-Bench 4.0がOpus 66.4%対Fable 55.8%、FrontierCode v1.1が54.4%対50.3%、CursorBench 4.0が57.8%対51.8%だった。複雑な推論のHumanity's Last Exam（ツールあり）も67.7%対65.6%である。これはOpusを試す有力な根拠になる。ただし提供元の評価であり、特定のハーネス、effort、採点方法を使う。数字をそのまま自分のPRの品質差へ移すことはできない。^[7]

独立したArtificial Analysisの2026年9月22日の評価では、最大effortの総合指数がOpus 5.5で58、Fable 5.1で53と報告された。Opusのmedium・high・xhigh・maxの4設定が同社の品質対費用の効率的な境界に載るという分析もある。一方、この指数は複数評価の合成であり、長い開発仕事をそのまま一件採点したものではない。また同社はフォールバックを許したモデル設定で測定している。設定名と測定条件を揃えずに「常に5点強い」と読むべきではない。^[8]

長時間の難問については、METRの公開前評価が参考になる。同団体はAI研究開発に関係する長期課題を調べ、Opus 5.5をFable 5.1より小幅に改善したと評価した。同時に、専門家が要る判断力にはなお弱点があり、大幅な飛躍とまでは見ていない。これは「長い仕事は必ずFable」という単純化に歯止めをかける。ただしAI研究の評価であり、あらゆる業務への一般化はできない。^[9]

Fableの価値が消えたという話でもない。AnthropicのFable 5.1紹介は、長時間のエージェント開発や多段階の調査、資料作成における強さを示し、現在の選択ガイドも最も高い能力が要る場合の候補に残している。重要なのは、公開ベンチマークがOpus優勢でも、自分の難問でFableが合格する可能性は残るという順序だ。先にFableを常用する理由にも、Fableを候補から外す理由にもならない。^[10][2]

4. 世界の利用者はどう使っているか──証言は地図、人口調査ではない

公開されたClaude Code利用者の報告には、Opusを普段の実装に使い、Fableを着手時の設計や行き詰まりの解消に回す例がある。ある投稿者は、日常のコーディングでは差を感じにくく、Opusをほぼ常用し、Fableは新規プロジェクト開始時かOpusが止まったときに使うと述べた。別の議論では、複数リポジトリにまたがる設計とレビューをFable、仕様が決まった実装をOpusへ分ける声がある。^[11][12]

逆の体験もある。Opusへ移した後に既存コードから逸脱する修正が増えたと報告し、Fableの方が長い作業で方向を保てると感じた利用者もいる。逆にOpusの方が直接的で、Fableの過剰な検討を避けられるという声もある。個々の投稿は作業、プラン、プロンプト、実行時期、評価者が揃っていない。意見が割れること自体が、用途別の確認を促す材料になる。^[13][11]

「世界中で何割がFableをやめたか」を示す公開統計は、今回確認した資料からは得られなかった。 Redditのスレッド数、賛成票、モデル選択欄に専用の使用量表示があることは、利用率の分母にならない。Fableの使用量を別扱いするプラン上の表示や利用クレジット条件も、同モデルを技術的に常に優先すべきだという証拠ではない。公式文書は、プランや席種によってFableが含有枠ではなく追加の使用クレジットを消費する場合があると説明している。^[5]

読むべき共通点は「Fable派かOpus派か」ではなく、普段の実装、曖昧な設計、長時間の調査、最終レビューを別の仕事として扱うことだ。ただし「Fableに必ずレビューさせればよい」も万能ではない。レビュー指摘は再現やテストで確かめ、どのモデルが書き、どのモデルが見つけたかを記録する方が判断に役立つ。

同じプロジェクトでも、実装と設計とレビューは要求する能力が違う。仕事単位で選び直す。

5. 費用は「トークン単価」より「合格した仕事一件」で見る

APIの公表単価は100万トークン当たり、Fable 5.1が入力10ドル・出力50ドル、Opus 5.5が入力4ドル・出力20ドル。通常の入出力はFableが2.5倍だ。ただしキャッシュ読込はFable 0.25ドル、Opus 0.20ドルで、差は1.25倍。長いClaude Codeセッションでは既存文脈の再読込が多く、単純に「全作業2.5倍」とは言えない。キャッシュ作成、外れた読込、出力、再試行まで含めて比較する。^[3][4][14]

例えばキャッシュを使わない一件で、入力20万・出力5万トークンが同じ量だったと仮定すると、Opusは1.8ドル、Fableは4.5ドルになる。これは定価を使った筆者の固定量試算で、現実のClaude Code作業の予測ではない。Fableが少ない試行で完了したり、Opusが何度もやり直したりすれば差は変わる。逆にFableが長く考えれば差は広がる。AnthropicのコストガイドはSWE-bench Proの一部で、Opus 5.5の既定effortがFable 5.1の既定effortと試行ごとの揺れの範囲で同水準、解決した課題当たりの費用は約5分の1だったと報告する。これは同社測定の特定課題であり、自分の請求額の予報ではない。^[14]

サブスクリプション利用者には別の問題がある。APIのドル単価と、Pro・Maxなどの残り使用枠や追加クレジットは同じ尺度ではない。Fableを頻繁に使って週の枠が先に尽きるなら、その機会費用も含める。反対にFableで一件が通り、人の手戻りを大きく減らすなら、安いトークンだけを買うのは得策でない。完了率、所要時間、人のレビュー時間、利用枠消費をセットで見るのが実務的だ。

6. effortとUltracodeはどう組み合わせるか

effortは「考える秒数」だけではない。Anthropicの説明では、読むファイル、ツール呼び出し、検証の深さ、途中で人に戻るまでの進行に影響する。Opus 5.5の既定はmedium、Fable 5.1の既定はhighなので、初期設定のままの体験談は同一effortの比較ではない。同じhighという名称でもモデル間で同じ計算量を意味しない。^[15][5]

lowはすぐ人が確認できる軽い処理、mediumは範囲が明確な通常作業、highは既存コードのバグや境界条件が多い仕事、xhighは長時間の作業の候補にする。maxは最難関で試す設定であり、公式文書も過剰な検討と費用対効果の逓減に注意している。Opusのmediumで漏れた検証がhighで補えるなら、モデル変更より安く済む場合がある。反対に十分調べても設計判断が外れるなら、effortを際限なく上げるよりFableとの比較に進む。^[5][15]

名称が似た機能を混同しない。Ultracodeはeffortの第6段階ではなく、Claude Codeが実質的な仕事を動的ワークフローとして組み立てる設定だ。/effort ultracodeの切替自体は現在のeffortを保つ。一方、起動時のclaude --effort ultracodeはUltracodeをオンにし、effortをxhighに設定する。機能と深さの両方が変わるので、モデルの比較実験では別々に記録する。ultrathinkはその一回の入力で深い検討を求めるキーワードで、環境によってそのターンをxhighへ上げられるが、セッションのeffort設定そのものとは区別する。^[5]

モデル、effort、Ultracodeは独立した選択。難しい仕事でも最初から全て最大にする必要はない。

7. 「自動判定Skill」を作るなら、推奨と実行を分ける

Claude CodeのSkillにはfrontmatterのmodelとeffortを指定できる。指定モデルはSkillが動く現在のターンに適用され、次のユーザー入力でセッションのモデルへ戻る。これはモデルを固定した/deep-auditのような用途には便利だ。ただし一つのSkill内で作業を見て動的にmodel欄を書き換え、今走っている親セッションを永続的に切り替える仕組みとしては設計しない方がよい。公式文書は別途、/model、--model、subagentのモデル指定などを案内している。^[16][5]

自動判定の最小設計は、実行前に五つだけ問うものにする。①合格条件をテスト等で確認できるか、②問題の曖昧さはどれほどか、③複数の領域やリポジトリをまたぐか、④作業時間は長いか、⑤失敗時の人の手戻りは大きいか。そして「モデル・effort・理由・上げる条件」を短く出す。次の擬似ルールはAnthropicの公式機能ではなく、資料を基にした設計例だ。

if routine && verifiable:
  recommend Sonnet 5.5 / medium, or Opus 5.5 / low
else:
  recommend Opus 5.5 / medium
if missed-files-or-tests:
  improve context and acceptance checks; retry Opus / high
if deep-work-and-uncertain-root-cause:
  compare Opus / high with Fable 5.1 / high on the same rubric
if Opus-high-clearly-tried-but-failed:
  try Fable / high; reserve xhigh or max for measured need

出力は例えば「Opus 5.5・high。既存の認証経路をまたぎ、回帰テストが必要です。テストまで通しても原因の説明が合わなければFable 5.1・highで再調査します」という程度でよい。複雑な点数表を作るより、なぜその設定にしたか、何が起きたら上げるかを残す。Claude CodeのSkillにはmodel: opus、effort: highのように書けるが、選択が変わる仕事は起動時にclaude --model ... --effort ...を渡すラッパー、またはタスク別のSkillを使う。組織の制限や環境変数が優先する場合もあるので、実際の稼働モデルとeffortをログで確認する。^[16][5]

評価するときは、自分の過去の仕事から「小さな修正」「既存コードのバグ」「横断変更」「長時間の調査」を数件ずつ選び、同じ指示、同じ環境、同じ合格基準で比較する。再現した不具合、通過テスト、差分の不要変更、人のレビュー時間、所要時間、トークンまたはプラン使用量を記録する。失敗したものだけ高いeffortやFableへ再試行する方式も、Anthropicのコストガイドが評価している。成功例だけを集めると、どの設定でも「十分」に見えてしまう。^[14]

8. 実務の答え：Fableを使う理由を「難しそう」より具体的にする

普段のClaude Code開発はOpus 5.5のmediumから始める。早く人が確認できる作業はSonnetやlowを含めて比べる。結果が浅いときは、読んだファイルと確認したテストを見て、effortや文脈の不足を先に直す。十分に調べても判断が難しい原因究明、長い自律作業、複数領域の設計ではFable 5.1を候補に加える。どちらも万能ではなく、最終的な採用条件は自分の仕事が合格したかに置く。

公開された利用者の声は、その使い分けを始めるヒントになる。しかしFableを使う人が減った割合も、十数ファイルの修正にFableが不要という閾値も、公開データからは断定できない。2026年10月時点で最も誠実なのは、Opusを既定の出発点とし、Fableには追加コストに見合う具体的な改善を求めることだ。複雑な調査や重要なPRなら、両者に同じ合格条件を渡し、一度比べればよい。^[2][14]