Claude Fable 5の復活以降、X（旧Twitter）では「計画はFable 5に、実装はSonnet 5にやらせるのが最強」という使い分け術が話題になっています。最上位モデルの頭脳と中位モデルのコスパを組み合わせる、いわば「ハイブリッド戦略」です。

本当にそんなにうまくいくのでしょうか？本記事では、公式ドキュメントの裏付け・ベンチマークデータ・実際のコスト試算の3つの観点からこの主張を検証し、具体的なやり方3パターンと落とし穴まで解説します。

スポンサーリンク

結論：条件付きで「本当」

検証①：主張に根拠はあるか

計画フェーズ＝知能の差が最も出る場所

コーディングタスクの成否は、実は「書き始める前」にほぼ決まります。要件の解釈、影響範囲の調査、実装手順の設計──ここで間違えると、どれだけ綺麗なコードを書いても手戻りが発生します。

この「計画力」に直結するベンチマークで、Fable 5は圧倒的です。

※スコアは各モデル発表時の公式資料に基づきます（測定条件は完全一致ではありません）。

注目すべきはTerminal-Bench 2.1です。「決まった作業を確実に実行する」系のタスクではSonnet 5がFable 5に肉薄しており、詳細な計画さえあれば実装役はSonnet 5で十分であることを示唆しています。

実装フェーズ＝出力トークンの大量消費地帯

API価格を見ると、この戦略の経済合理性がはっきりします。

計画フェーズの出力は「計画書」だけなので数千〜数万トークンで済みますが、実装フェーズはコード・テスト・修正の繰り返しで出力トークンが桁違いに膨らみます。つまり、単価の高いモデルを実装に使うほど損をする構造です。

検証②：Anthropic公式はどう考えているか

「計画と実装でモデルを分ける」は公式公認の設計

実はClaude Codeには、opusplanという公式のハイブリッドモードが昔から存在します。

つまり「賢いモデルで計画し、効率的なモデルで実装する」という発想自体は、Anthropic自身が製品に組み込んでいる公認パターンです。Xの主張は、これをOpusからFable 5に格上げした発展形といえます。

ただし「fableplan」は存在しない

ここが重要なポイントです。公式ドキュメントを確認すると、Fable 5版の自動ハイブリッドモード（fableplanのようなもの）は提供されていません。Fable 5で計画してSonnet 5で実装するには、次章のいずれかの方法で自分でオーケストレーションする必要があります。

また公式ドキュメントは、Fable 5の活かし方として「手順ではなく成果を渡す」「曖昧な問題を任せる」「複数セッション級の大きなタスクを任せる」ことを挙げています。これはまさに計画・調査フェーズの仕事であり、Fable 5を計画側に置く発想は公式の推奨方向とも一致しています。

実践：3つのやり方

/model fable      # ① Fable 5に切替（調査・計画フェーズ）
# Shift+Tabでプランモードに入り、計画を作らせる
# ② 計画をレビューして承認
/model sonnet     # ③ Sonnet 5に切替（実装フェーズ）
# 承認済みの計画に沿って実装させる

---
name: implementer
description: 承認済みの計画ステップを実装する。対象ファイルが明確なタスク向け
model: sonnet
---
計画に忠実に実装してください。計画にない変更は行わないこと。

---
name: codebase-search
description: コードベースの広範な検索・調査。結論だけを返す
model: haiku
---

コスト試算：どれくらい安くなる？

中規模の機能実装タスクを想定して概算してみます（計画フェーズ：入力5万/出力1万トークン、実装フェーズ：入力20万/出力10万トークン）。

※プロンプトキャッシュ・モデル切替時の再読み込みコストは含まない概算です。実装フェーズの比重が大きいタスクほど削減率は上がります。

Fable 5級の計画品質を維持したまま、トータルコストを6〜7割削減できる計算です。サブスクプランの場合も、上限消費の速いFable 5の使用量を計画フェーズだけに抑えられるため、同じ理屈で恩恵があります。

落とし穴：この戦略が向かないケース

よくある質問

まとめ

モデルの使い分けは「どれが最強か」ではなく「どこに何を置くか」の問題になってきました。まずは方法1の手動切替から試して、効果を実感したらサブエージェント構成に進むのがおすすめです。