Feel Physics Backyard

HoloLensの出張授業をする会社で、教材を開発しています

トップ > Fable5と他のモデルの相対的比較・大学受験に例えた特性・上手な運用法

Fable5と他のモデルの相対的比較・大学受験に例えた特性・上手な運用法

素のPerplexityの結果

モデル 陸上での向き不向き（ざっくり種目） 持久力（1turn長さ） 速さ ツール使用 コスト相対値
Fable 5 マラソン〜ウルトラの戦略ランナー 100 40 80 100
Sonnet 4.6 1500m〜5000mの中距離総合選手 70 70 70 30
GPT‑5.5 Codex 400m〜1500mのスピード持久型 75 85 100 45
Codex 5.3‑Spark 100m〜200mスプリンター 35 100 60 25
Composer 2（Std/Fast平均） 200m〜800mトラック専門選手 60 90 75 10
ローカル Qwen Coder 3000m障害〜駅伝のローカル長距離 80 60 50 （マシン実費 30万円）
ローカル Gemma 4（31B想定） 1500m〜ハーフの汎用ローカル選手 65 55 45 （マシン実費 30万円）

Redditの評判を加味

モデル 陸上での主戦種目イメージ 1ターンの深さ / 長さ (Fable=100) スピード (Spark=100) ツール使用 (Codex5.5=100) 相対コスト (Fable=100, ローカルはマシン代)
Fable 5 マラソン〜ウルトラの戦略ランナー 100 60（どうでもいい会話は飛ばすので体感70くらい） 85（ツール少なめだが精度高い） 100（10/50ドルクラスで最上位帯）anthropic+2
Sonnet 4.6 1500m〜5000mの中距離総合選手 75 80 80（PC操作・web・functionなど十分）anthropic+1 30（3/15ドルでFableの約1/3）anthropic+2
GPT‑5.5 Codex 400m〜1500m＋障害物のスピード持久ランナー 85 90〜95（5.4比で2〜3倍速）mindstudio+1 100（ツール連携・並列CLIが最強クラス）developers.openai+3 50（5/30ドルでFableの約半額ゾーン）framia.converge+3
Codex 5.3‑Spark 100m・200mのスプリンター 40 100（超低レイテンシ設計）custom.typingmind+2 70（ツールは使えるが、深い連鎖には向かない）m-assets+1 20（約1.75/14ドルでかなり安い）custom.typingmind
Composer 2 (Cursor) 100m〜800mトラック専業のコーディング選手 70（コードタスクで深さ十分）cursor+2 90（Fast版はSpark寄りの体感速度）cursor+2 60（Cursor IDE内ツールに特化）cursor+2 10〜15（0.5/2.5ドルでFable比1/8〜1/10）cursor+3
ローカル Qwen Coder 5000m＋駅伝を走るローカル長距離ランナー 90（長コンテキスト・thinkingで深め）mindstudio+4 70〜80（VRAM次第、最適化すれば十分速い）reddit+1 75（ローカルツール連携は工夫次第）mindstudio+2 初期マシン代 30万を「Fable API月額換算で60〜80」くらいの感覚（長期利用なら割安）kdnuggets+2
ローカル Gemma 4 1500m〜10000mの万能ローカル選手 80（汎用＋コードでバランス良い）towardsdatascience+3 75〜85（量子化＋GGUF最適化でかなり速い）lmstudio+1 80（ツール使用機能あり、ローカルで拡張しやすい）lmstudio+2 初期マシン代 30万を「Fable API月額換算で60〜80」くらいの感覚（推論コスト0）kdnuggets+5

補足説明

結論からいうと、
ご指定の軸でざっくりスコアを付けると「長距離・深さ＝Fable／Qwen」「スピード＝Spark／Composer」「ツール＆実務＝Codex5.5」「総合力＆コスパ＝Sonnet／Gemma」というイメージになります。 reddit

PREPで、先に表を出してから簡単に補足します。

P（Point）比較表（陸上アナロジー＋相対スコア）

前提ルール：

  • 向き不向き（陸上）：主戦種目（長距離／中距離／短距離／障害物／駅伝）。
  • 相対的能力
    • 1ターンの「実質的な長さ／深さ」：Fable 5 を 100。
    • スピード：Codex 5.3‑Spark を 100。Fable が「どうでもいい会話を飛ばす」ぶん、体感速度は少し補正。
    • ツール使用：Codex 5.5 を 100（CLI・ブラウザ・DBなど総合的ツール能力）。
  • 相対コスト
    • Fable 5 のAPIコスト感を 100 としてざっくり（入出力まとめ）。
    • 他クラウドは公式単価から比率を推定。
    • ローカルは「初期ハード代30万円＋運用」を、Fable 5＝100に対しての相対感覚としてざっくり。

R（Reason）スコアの読み方（ごく簡単に）

  • 深さ / 長さ

    • Fable 5 とローカル Qwen Coder が「長距離・長タスク」に強い枠。
    • Sonnet・Gemma 4 は「日常の中距離タスクをほぼ全部こなす」枠。
    • Codex‑Sparkは「超短距離専業」。

  • スピード

    • Spark が「一瞬で返ってくる」基準。
    • Codex5.5・Composer2 Fast がそれに近い体感。
    • Fable は深く考えるぶん遅いが、「どうでもいい会話を削る」ので同じ深さならそこまで体感差は大きくない。

  • ツール使用

    • Codex5.5 が CLI・ブラウザ・DB・ファイル操作・並列ツール呼び出しで頭一つ抜けている。 developers.openai
    • Fable はツール回数が少ない代わりに、失敗を読んで自己修正する「慎重な使い方」が得意。 mindstudio
    • ローカル勢は、環境の作り込み次第で伸びる部分が大きい（Qwen/GemmaはClaude CodeやPi/OpenCodeと組み合わせる事例が増えている）。 towardsdatascience

  • コスト

    • Fable 5 を 100とすると、
      • Sonnet ≒ 30
      • Codex5.5 ≒ 50
      • Spark ≒ 20
      • Composer2 ≒ 10〜15
        と、クラウド側は「Fable が一番高く、Composer2 が異常に安い」絵になります。 anthropic
    • ローカル Qwen / Gemma は「初期投資30万＋電気代」なので、長期的には「Fable を毎日ヘビーに使う」より安くなりうる一方、短期・ライトユースならクラウドの方が楽、というバランスです。 patloeber

E（Example）陸上チームとしての起用イメージ

ざっくり言えば：

  • マラソン・駅伝のアンカー：Fable 5 or ローカル Qwen Coder
  • 1500m〜5000mの日常レースの主力：Sonnet 4.6 or Gemma 4
  • 400m〜1500m障害＋実務リレー：Codex5.5
  • 100m〜200mの予選ラッシュ：Codex‑Spark / Composer 2
  • 練習トラック（ローカル開発環境）：Gemma 4 / Qwen Coder

という感じで「種目ごとに誰を出すか」を決めると、MCPやルーティング設計もかなりクリアになると思います。 recruit.group

受験に例えると

結論からいうと、大学受験の例でざっくり言えば、

  • Fable 5：東大・京大・早慶のトップ層。最難関の記述・思考問題と長期計画が得意。
  • Codex 5.5（GPT‑5.5/Codex）：難関理系私大／東工大タイプの「理系・実技特化」。道具の使い方（ツール・コード）と演習量で押す。
  • Sonnet 4.6：難関国公立・上位私大の「万能エース」。コスパ良く共通テスト〜二次試験をこなす。
  • Codex 5.3‑Spark：共通テストや私大の「小問処理を高速連打する補助エース」。とにかく手数と速度が武器。

というイメージになります。 anthropic

R（Reason）各モデルの「受験スタイル」

1. Fable 5：東大・京大・早慶トップ層（最難関二次・総合問題に強い）

公式に近い特徴

  • 「長期エージェント」「長期 reasoning」向きの最上位モデル。 anthropic
  • FrontierBench や金融・ソフトウェアの難度高いベンチマークで最高水準。 vellum
  • 100万トークン級の長文・複数文書・コードベースを横断して扱える。 eigent
  • アダプティブ思考常時オンで、タスク難度に応じて思考量を変える。 japan-ai.co

受験のたとえ

  • 共通テスト：
    • ほぼ無双だが、「パワーを出し過ぎなくても満点近く取れる」ので、わざわざここ専任にする必要は薄い。
  • 知識問題：
    • 教科書〜発展参考書レベルまで幅広く押さえており、「なぜそうなるか」の背景説明まで得意。
  • 私大の膨大な問題量：
    • 過去問研究や傾向分析、出題パターン抽出などのメタ分析が得意。
  • 真価が出るのは：
    • 東大・京大の理系数学、難関大の融合問題、医学部の総合問題のような
      • 長く
      • 分野横断で
      • 方針立案＋検証が必要な問題群。

LLM的には：

  • 大規模リファクタリング・長期リサーチ・複数システム横断の設計など、「二次試験最難関＋志望校対策計画」を同時にやるような場面が Fable 5 の本領です。 platform.claude

2. GPT‑5.5 / Codex 5.5：理系難関私大・東工大タイプ（実技・ツール利用の鬼）

ここは OpenAI 側なのでざっくり「GPT‑5.5（Codex 5.5）」としてまとめます。

公式・レビュー的な特徴

  • GPT‑5.5 は「エージェントタスクに最適化されたモデル」であり、
    • ツール呼び出し精度
    • マルチステップ reasoning
    • コード生成・デバッグ
      に強いとされます。 mindstudio
  • Codex では、ドキュメント・スプレッドシート・スライド生成など、「Office 系実務+コード」に特に強い。 openai
  • 特に TypeScript・Python など実務的な言語＋ツールアクセスで高評価。 mindstudio

受験のたとえ

  • 共通テスト：
    • パターン化された計算・情報処理・データ解釈系はかなり強い。
    • 一方で、「深い読解ベースの国語・小論文」のような素の言語芸は、Fable 5/Opus級と比べると目的外、という位置づけに近い。
  • 知識問題：
    • 理科・情報・数学系の「ツールを使って解く問題」にはめちゃくちゃ強い。
    • いわば「グラフ電卓・CAS をフル活用する理系ガチ勢」。
  • 私大の膨大な問題量：
    • 特に理系・情報系私大の
      • 設計問題
      • コーディング試験
      • 実験データ処理
        のような、「手で計算・実装する系」の問題を演習でゴリゴリ回すのに向く。
  • 役割としては：
    • 「道具をフル活用することで、難関理系私大の点数を底上げするタイプ」。
    • 東大型の純理論・抽象思考問題では Fable 5 に分がある場面もあるが、「ツール＋コード」が絡めば最強クラス。

LLM的には：

  • 外部ツール・API・実コードと組み合わせた「実務的エージェント（システム構築・テスト生成・データ処理）」に特化した受験生、というイメージです。 oneusefulthing

3. Sonnet 4.6：難関国公立・上位私大に強い「コスパ最強エース」

公式に近い特徴

  • 「これまでの Sonnet の中で最も有能」「Opus に近い性能を中価格帯で」という位置づけ。 datacamp
  • 100万トークンコンテキスト、アダプティブ思考、文書処理・PC操作・coding がフルアップグレード。 ntt
  • SWE-bench や OSWorld などのベンチでコスパが良いスコア。 caylent

受験のたとえ

  • 共通テスト：
    • 9割前後安定で取れるタイプ。
    • マークミスや時間配分ミスも少ない。
  • 知識問題（社会・理科・現代文の知識系）：
    • 標準〜やや発展まで高水準で網羅。
  • 私大の膨大な問題量：
    • MARCH〜難関私大レベルの問題を大量にこなす「演習マシン」として優秀。
    • ただ、超難問特化では Fable 5 や GPT‑5.5 のエースより一歩下がる場面もある。
  • 役割としては：
    • 「日常の勉強・演習はほぼこの子に任せて、受験本番の最終仕上げだけ東大トップ層を呼ぶ」ポジション。

LLM的には：

  • ふつうの業務・開発・社内文書処理・PC操作など、「毎日の学習・演習・作業」をほぼ全部 Sonnet に任せ、
  • 本当に重い設計・リファクタ・長期リサーチだけ Fable 5 / GPT‑5.5 に渡す構図が、コスパの良い使い方です。 note

4. Codex 5.3‑Spark：共通テスト高得点の「小問処理マシン」

公式・解説的特徴

  • GPT‑5.3‑Codex の小型版で、「リアルタイムコーディングのための超高速モデル」。 openai
  • SWE-Bench Pro や Terminal-Bench などで、フル版より短時間でタスクを解き切ることに重点。 openai
  • 解説では、「深く長く考えることよりも、応答速度と反復のしやすさに特徴がある」とされています。 m-assets

受験のたとえ

  • 共通テスト：
    • 計算小問・穴埋め・短文読解のような、一問あたり1〜2分で解ける問題を高速にさばくのが得意。
    • 「多少のミスはあるが、とにかく手数で押す」タイプ。
  • 知識問題：
    • 暗記系の確認テストや、短い用語説明など、「パッと聞いてパッと返す」用途がメイン。
  • 私大の膨大な問題量：
    • 過去問演習で、「答え合わせ＋解説のたたき台生成」を高速に繰り返す相棒、みたいな位置。
    • 1問1問の完成度は Fable 5 や Sonnet に劣っても、人間がレビューしながらガンガン回す前提なら効率が高い。

LLM的には：

  • VS Code での小さなリファクタ
  • 1ファイル内のバグ取り
  • 「この関数の引数チェックだけ変えて」みたいなピンポイント修正

を人間が見張りながら連打する用途に向いている、とされます。 reddit これはまさに「共通テストの計算小問を、横で教師が採点しつつ、30秒ペースで解かせ続ける高校生」と同じポジションです。

E（Example）「共通テスト／知識／私大大量問題」で比べてみる

受験観点で3つの軸を立てて、ざっくりマッピングしてみます。

1. 共通テスト（スピードと正確さ）

  • Fable 5
    • 余裕で高得点は取れるが、ここは過剰スペック。
    • 共通テスト専任なら Sonnet や Spark で十分なことが多い。 anthropic
  • GPT‑5.5/Codex 5.5
    • 情報・数学・理科で、「ツール利用やシミュレーションを絡めた問題」が出る想定なら強い。
  • Sonnet 4.6
    • 共通テスト〜二次試験のメイン担当。
    • 速度・正確さ・コストのバランスが良く、日々の演習用最適モデル。
  • Codex 5.3‑Spark
    • マークの計算小問を高速にさばく補助担当。
    • 人間の監督込みなら「答えの候補＋部分解説」を高速量産できる。

2. 知識問題（暗記・教科書理解・背景解説）

  • Fable 5
    • 解説授業もできる講師タイプ。
    • 「なぜその結論になるのか」「関連分野とのつながり」まで語れる。
  • GPT‑5.5/Codex 5.5
    • 純粋な説明もできるが、真価は「説明＋実装＋検証」を組み合わせる場面。
  • Sonnet 4.6
    • 学校の先生〜予備校講師レベルの説明力。
    • 教科書・資料の読み込みと整理が得意。 ntt
  • Codex 5.3‑Spark
    • 単語テスト・用語確認・穴埋め問題の答え合わせレベルに向く。

3. 私大の膨大な問題量（演習量と処理能力）

  • Fable 5
    • 「どの問題集をいつまでに、どの順番でやるか」の学習計画・弱点分析に最適。
    • 全部の演習問題をこの子に解かせるのは、コスト的にオーバーキル。
  • GPT‑5.5/Codex 5.5
    • コーディング試験やシステム設計試験（情報工学系私大など）の演習相手として最強。
  • Sonnet 4.6
    • 実際に私大過去問演習をまわす主力。
    • 難関国公立〜上位私大の問題を「とにかく大量に」処理させるならここ。
  • Codex 5.3‑Spark
    • 演習の「1問目〜3問目の類題」を高速で量産したり、
    • 小さなバリエーション違い問題を作る相棒として良い。

P（Point 再掲）どう使い分けると“合格しやすい”か（開発者視点）

開発者視点でまとめると：

  • Fable 5（東大トップ層）
    • 本番の東大二次・京大二次・難関総合問題担当。
    • 実務では「大規模リファクタ」「長期エージェント」「超難度設計・リサーチ」専用にする。
  • GPT‑5.5 / Codex 5.5（理系・実技特化の猛者）
    • ツール・コード・データ処理が絡む実技試験担当。
    • 「実コード＋外部API＋テスト生成」を伴うエージェント系に向ける。
  • Sonnet 4.6（難関国公立・上位私大エース）
    • 日常の勉強（業務・開発・資料処理）のメインワークホース。
    • 共通テスト〜二次レベルのほとんどをここでカバー。
  • Codex 5.3‑Spark（共通テスト小問マシン）
    • 高速反復・軽微な修正・小タスクの連打要員。
    • 人間が隣でチェックしながら「とにかく回数をこなす」場面で使う。

という「4人の受験生」を手元に置いておくイメージで設計すると、
エージェントやMCPのモデルルーティング設計もかなり整理しやすくなると思います。 openai

Fable 5 を使い過ぎないための残りトークン確認

  1. Claude本体の「Usage画面」で月間・全体の残量を見る。
  2. Claude Code／CLIの/usageや/statsなどのスラッシュコマンドで、今のセッション単位の消費を見る。
  3. 必要なら、ccusage や claude-monitor などの外部ツールで、日別・モデル別の詳細をダッシュボードで見る。

の3段構えでやるのが現実的です。 shipyard

PREPでもう少し具体的に整理します。

P（Point）いちばん簡単な「残りトークンの確かめ方」

  • ClaudeのWeb UIなら：Settings → Usage のページで、自分のプランごとの使用量・残り枠がまとまって見られます。 claude
  • Claude Code（CLI）なら：セッション内で /usage や /stats を叩くと、現在セッションのトークン消費と、期間全体の使用状況が見られます。 youtube

まずは、この2つを「日常の残量チェック」として覚えておくのが一番楽です。

E（Example）「Fable 5 を使い過ぎない」ための実務的な運用例

Reddit の「Fable を燃やしすぎないコツ」スレで出ていたやり方を、少し整理するとこうなります。 reddit

  1. 月間上限の「目標値」を決める

    • 例：月間トークン上限の 50％以上を Fable 5 に使わない。
    • これを Usage 画面と ccusage で毎週確認する。

  2. Fable は「マラソンだけ」に使うルールを決める

    • 「短い質問・雑談・小さな修正」は Sonnet / Spark / Composer2 にルーティング。
    • 「長期タスク・設計・大規模リファクタ」だけ Fable 5 を起動。

  3. セッションを短く区切る

    • /contextでコンテキスト使用率が20〜30％になったら、一度セッションを切る。
    • 重要な状態は README的な手動ノートにまとめて、次セッションはそれだけを読み込ませる（チャットログ全部は渡さない）。 reddit

  4. ccusage / claude-monitor に「モデル別しきい値」を決める

    • 例：
      • Fable 5：週あたり X トークンを超えたら警告。
      • Sonnet 4.6：上限 Y トークン。
    • ある程度超えたら、自動でモデル選択ロジックを変える（MCPのルーティング側で）という設計も可能。 mcpmarket

こうしておくと、「気づいたらFable 5で月間上限ギリギリまで燃えてた」という事故をかなり減らせます。 reddit

ソース

www.perplexity.ai