Shuichiro Ogawa

Notes ・ updated 2026-07-05

Fable のモデル使い分けパターン

Claude Fable 5 は Claude ファミリーの最上位モデルであり、トークンあたりのコストが高い。 frontier-model-premium-history-debate で論じたとおり、フロンティアモデルへの課金は先行アクセス、学習機会、時間の3つを買っている。 全タスクにフロンティアを投入する必然性はない。 実際のワークロードでは 60-80% のリクエストが Haiku や Sonnet で十分処理でき、Fable の投入を複雑な推論と最終判断に絞れば、品質を維持したまま大幅なコスト削減が見込める。

1. ルーターベースのモデル選択

モデルルーティングとは、タスクの難易度や種類に応じてリクエストを自動的に適切なモデルへ振り分ける手法である。 分類器が各リクエストを解析し、安価なモデルで十分か上位モデルが必要かを判定する。

RouteLLM は Chatbot Arena の選好データで訓練した複数のルーター手法を実装し、ICLR 2025 に採択された（Ong et al., 2025）。 行列分解ルーターが最良の性能を示し、CPT 80%（呼び出しの80%を安価モデルに回す閾値）で最大 3.66倍のコスト削減を達成した。 学習に含まれないモデルペア（Claude 3 Opus と Sonnet 等）にも汎化する。 OpenRouter の Auto Router は NotDiamond ベースの分類器を採用し、cost_quality_tradeoff パラメータ（0-10）で品質とコストの比重を連続的に調整できる。

Claude ファミリーでは、分類器の判定に応じて4層に振り分ける。 簡単なタスク（分類、抽出、定型応答）は Haiku、標準的なタスク（要約、コード生成、質問応答）は Sonnet、複雑な推論やエージェントワークフローは Opus、最高品質が求められる計画立案や最終判断は Fable に割り当てる。

「ルーティング」単体で 40-70% のコスト削減が見込める。 RouteLLM の最大 3.66倍というコスト削減はモデル間の価格差が大きい組み合わせでの上限であり、Claude ファミリー内での実効値は価格比に依存する。

ルーターの分類精度がシステム全体の品質上限を決める。 誤分類で安価なモデルに回ったタスクの品質劣化はユーザーに直接見える。 分類器の訓練にはタスクと最適モデルの対応データが必要であり、冷起動時の初期投資がかかる。

2026年6月の学術研究は「ルーティング」の構造的限界を示した。 LLMRouterBench による体系的評価では、ルーティングは単一最良モデル比で最大 31.7% のコスト削減を達成する一方、精度向上は最大 4% にとどまる（Zhao et al., 2025）。 商用ルーター OpenRouter は単一最良モデルに対して -24.7% の性能低下を記録した。 トップ15ルーターの精度差は 0.23pp に収束する現象が確認され、ルーティングプラトーと名づけられた（Chari et al., 2026）。 モデルプールを拡大しても改善は収穫逓減に陥る。 RouteLLM の汎化能力もこの天井の内側で作用するため、ルーティング単体での品質改善には上限がある。

2. カスケード型

まず安価なモデルで処理を試み、出力の品質が不十分な場合にのみ上位モデルへエスカレートするのがカスケード（cascade / fallback）である。 FrugalGPT（Chen et al., 2023）がこの手法を先駆的に定式化し、AutoMix や EcoAssistant など複数の独立実装が続いた。

「カスケード」の成否を分けるのは品質推定器（post-hoc quality estimator）の精度である。 下位モデルの出力が十分かどうかを正確に判定できなければ、不必要なエスカレーションでコストが膨らむか、品質不足の出力をそのまま通してしまう。 SWE-Bench での評価では、ルーティングとカスケードを組み合わせた手法が AUC 54.12 を達成し、ルーティングのみの 40.47、カスケードのみの 38.52 を一貫して上回った。

Claude ファミリーでは Haiku → Sonnet → Opus → Fable の順にエスカレートする。 大半のリクエストが Haiku か Sonnet で処理を完了するため、Fable に到達するリクエストは全体のごく一部にとどまる。

「カスケード」は「ルーティング」単体より SWE-Bench で 34% 優れた結果を示した（AUC 54.12 vs 40.47）。 ただしエスカレーションのたびにレイテンシが加算されるため、リアルタイム応答が求められる用途では遅延が問題になる。

3. オーケストレーター＋ワーカー型

フロンティアモデルを計画と判断に、下位モデルを実行と作業に使い分けるパターンである。 agentic-coding-orchestration-patterns で整理した階層型オーケストレーションの一形態にあたる。

Anthropic 自身がこの構成を検証している。 Opus をリードエージェント、Sonnet をサブエージェントとしたマルチエージェントシステムは、単一の Opus を 90.2% の場合で上回った。

Claude Code のサブエージェント機構はこのパターンを直接支援する。 サブエージェント定義の model frontmatter で haiku、sonnet、opus、fable のいずれかを指定でき、モデルの解決は4段階の階層に従う。 (1) CLAUDE_CODE_SUBAGENT_MODEL 環境変数、(2) 呼び出しごとの model パラメータ、(3) サブエージェント定義の frontmatter、(4) メイン会話のモデル、の順で優先される。 フォークサブエージェントは親のプロンプトキャッシュを再利用するため、新規サブエージェントより安価に動作する。

14M トークンのビルドで計画をフロンティアモデル、実行を安価なモデルに分けたところ、57% のコスト削減を達成した。 このプロジェクトでも 27体のサブエージェントを Opus 11体（討議リード、学術 critic）と Sonnet 16体（収集系リサーチャー、ユーティリティ）に分類し、同様の構成を採用している。

マルチエージェント構成は単一チャットの約 15倍のトークンを消費する。 コスト削減はモデル単価の差から生まれるが、エージェント間通信のオーバーヘッドが総トークン量を押し上げる。 タスクの価値がこのオーバーヘッドを上回る場合にのみ採用が正当化される。

4. タスク分類型

タスクの種類ごとにモデルを固定的に割り当てるパターンである。 「ルーター」がリクエストごとに動的判定するのに対し、「タスク分類型」は設計時に割り当てを決める。

Anthropic の推奨する配分はこうである。 Haiku は分類、ルーティング、抽出、大量の単純クエリに割り当てる。 Sonnet はほとんどの本番タスクに割り当てる。 Opus は複雑な推論とエージェントワークフローに割り当てる。

Claude Code の組み込みエージェントもこの方式を採用している。 statusline-setup には Sonnet、claude-code-guide には Haiku が割り当てられている。 このプロジェクトの 27体のサブエージェントも、タスクの性質に基づいて Opus 11体（討議の中核）と Sonnet 16体（収集とユーティリティ）に分類している。

配分の目安は3段階で、全リクエストの 40-60% を最安値（Haiku）、30-40% を中間（Sonnet）、10-20% を最高額（Opus や Fable）に振る。 Sonnet がリクエスト量の 60-70% を処理する workhorse になる構成が典型的である。

動的な判定を行わないため実装が単純で予測可能だが、タスクの実際の複雑さが事前分類と合わない場合に品質の過剰投資かコスト節約の取りこぼしが生じる。

5. プロンプトキャッシュとバッチ処理の併用

モデル選択（パターン 1-4）にキャッシュとバッチ処理を重ねて、さらにコストを圧縮するパターンである。

プロンプトキャッシュのヒットは標準入力トークンより 90% 安い。 Sonnet 4.6 ではキャッシュヒットが $0.30/MTok、通常の入力が $3.00/MTok であり 10分の1 になる。 ProjectDiscovery はプロンプトキャッシュの導入で 59% のコスト削減を達成し、キャッシュ率を 7% から 74%、さらに 85% へ段階的に引き上げた。 67.5M 入力トークンのタスクでは 91.8% のキャッシュ率を実現し、約 60倍のコスト差が生じた。

セマンティックキャッシュを「ルーティング」に重ねると、類似リクエストのキャッシュヒットで 40-60% の API コール自体を削減できる。

5つの最適化レバー（モデルルーティング、コンテキスト圧縮、プロンプトキャッシュ、プロンプト最適化、バッチ処理）を組み合わせると 70-85% の総コスト削減が見込める。 API 費用で言えば $22.50 の支出を $2-3.50 に圧縮できる計算になる。

キャッシュ効率はプロンプト構造の安定性に依存する。 システムプロンプトを頻繁に変更する運用ではキャッシュヒット率が上がらない。 バッチ処理はレイテンシを許容する非同期用途に限られ、リアルタイム応答には適用できない。

コスト削減の全体像

レバー削減率備考
ルーティング単体40-70%RouteLLM は CPT 80% で最大 3.66倍だがモデル価格差が大きい構成での上限。ルーティングプラトーにより精度向上は最大 4%
カスケードrouting-only 比 +34%SWE-Bench AUC: 組合せ 54.12 vs routing-only 40.47
オーケストレーター＋ワーカー57%14M トークンビルドでの実測値
全レバー組み合わせ70-85%5つの最適化を積層した場合（$22.50 → $2-3.50）

留意点

  • ベンチマーク上の改善（コスト削減率、精度維持率）が実務上の意味ある品質差異に直結するかは検証されていない。
  • 「カスケード」における品質判定の信頼性と段階的エスカレーションの体系的研究は限定的である。
  • 商用ルーター（OpenRouter 等）の性能主張は独立した第三者検証が不足している。
  • プロンプトキャッシュの効果はマルチエージェント構成や長大なシステムプロンプトという条件に依存し、短いプロンプトの逐次処理では効果が薄い。

参照文献

← Notes 一覧 ・ ホーム