「安い Sonnet 5 を、最上位 Fable 5 並みの品質に引き上げられないか」——手法は大きく 2 つあります。
- 手法 A(Fable 5 を使う):advisor tool で Fable 5 を助言役に据え、実行は Sonnet 5 のまま計画だけ借りる
- 手法 B(Fable 5 を使わない):Sonnet 5 を 検証器つきで多数回サンプリングし、最良を選ぶ
どちらが効くかは タスクの形で決まります。本記事では実価格でコストを検証し、「検証可能か / 計画が効くか」で手法を選ぶ基準まで整理します。
到達点
- 2 手法のコスト基準線(Sonnet 5 は Fable 5 の 1/5)を押さえる
- 手法 A(advisor):要所だけ相談すれば Fable 単独の約 4 割、毎ターンだと超過する損益分岐
- 手法 B(多数回):効くかは検証器(verifier)の信頼性で決まる
- generator–verifier ギャップと能力の天井という手法 B の限界
- タスク形状ごとの使い分け表
前提:コスト基準線
per 1M トークン、Sonnet 5 は導入価格です。
| 入力 | 出力 | |
|---|---|---|
| Sonnet 5 | $2 | $10 |
| Fable 5 | $10 | $50 |
単位を 入力 8,000 / 出力 2,000 トークンとすると、1 回あたり:
- Sonnet 5:(8,000×$2 + 2,000×$10)/1M = $0.036
- Fable 5:(8,000×$10 + 2,000×$50)/1M = $0.18
つまり Fable 5 一発 ≒ Sonnet 5 五発。この「5 倍」がすべての損益計算の土台になります。
手法 A:advisor tool で Fable 5 を助言役にする
advisor tool は server-side tool で、速い executor が賢い advisor に途中で相談し、その計画・軌道修正が executor の文脈に注入されます。現行の対応ペアに Sonnet 5(executor)+ Fable 5(advisor) が含まれます(beta ヘッダ advisor-tool-2026-03-01)。仕組みの詳細は advisor tool の記事 を参照。
課金は分かれます——executor のトークンは Sonnet 5 レート、advisor のトークンは Fable 5 レートで別立て。最終出力は executor が生成し、advisor は計画だけ返します(出力 400〜700、思考込み 1,400〜1,800、推奨キャップ max_tokens: 2048)。
コスト検証(10 ターンのエージェント作業)
advisor を max_tokens: 2048 でキャップした場合:
| 構成 | 概算(10 ターン) | 対 Fable 単独 |
|---|---|---|
| Sonnet 5 単独 | $0.36 | 20% |
| Sonnet 5 + Fable 5 助言(2 回だけ) | $0.72 | 40% |
| Fable 5 単独 | $1.80 | 100% |
| Sonnet 5 + Fable 5 助言(毎ターン) | $2.18 | 121% ⚠️ |
要所だけ相談すれば Fable 単独の約 4 割で計画品質を引き上げられます。ただし 毎ターン相談すると executor と advisor の両方を払い、Fable 単独を超えます。損益は「どれだけ相談を絞れるか」で決まる。
何が引き上がるのか
advisor は Sonnet 5 を Fable 5 に変えません。Fable 5 の計画・戦略を注入するだけです。だから引き上がるのは 「良いプランが効くタスク」——長期のエージェント作業で、多くのターンは機械的だが方針がボトルネックになる場合。逆に 全トークンでフロンティア生成が必要なタスクは、実行が Sonnet 5 である以上届きません。
手法 B:Sonnet 5 を検証器つきで多数回回す(Fable 5 不使用)
Fable 5 を一切使わず、Sonnet 5 の複数回実行で質を上げる方法です。代表的な手筋:
- Best-of-N:N 個生成して最良を選ぶ
- 自己整合性 / 多数決:N 個サンプルして多数派の答えを採る
- 生成→検証→再試行:テストやチェックに通るまで回す
効くかは「検証器」で決まる
N 回回すと 「どれかが正解の確率(coverage / pass@k)」は上がります。しかし **「その正解をどう選ぶか(selection)」**が別の問題です。ここを担うのが 検証器(verifier)。
| タスク種別 | 検証器 | 判定 |
|---|---|---|
| 検証可能(テストが通るコード・数学・チェック可能な抽出) | プログラム的(テスト実行・照合)= 安価で信頼できる | ✅ 効く |
| 開かれた判断(文章の質・設計の筋・微妙な推論) | 信頼できる安価な検証器がない | ⚠️ 頭打ち |
開かれた判断が頭打ちになる理由:
- generator–verifier ギャップ:モデルは自分の出力を「生成する能力」以上に「正しく評価する能力」を持たない。Sonnet 5 が Sonnet 5 を審査しても同じ盲点を共有する。
- 誤りが相関している:再サンプルは運・ばらつきは均せても、能力の天井は超えられない。Sonnet 5 が構造的に取り違える問題は、何回回しても同じ方向に外れます。
コストの分岐点
Fable 5 一発の予算で、Sonnet 5 は約 5 回回せます(前掲 $0.18 ÷ $0.036 ≈ 5)。
- 検証器がプログラム的(テスト実行など)でほぼ無料なら、Best-of-5 ≈ Fable 5 と同コスト。検証が信頼できるタスクでは互角以上を狙える。
- 検証を Sonnet 5 の審査で代替すると審査分が乗り、分岐点は N≈2〜3 に低下。しかも審査の信頼性は前述のギャップで落ちる。
- N を増やすほどレイテンシも直線的に増加(並列化しても集約段が残る)。
つまり手法 B は、「安価で信頼できる検証器があるか」が実用性のすべてです。コードやデータ処理のように機械的に正誤を判定できる領域でこそ、Fable 5 を使わずに同等ラインへ乗せられます。
使い分け
2 手法は排他ではなく、タスク形状で選ぶものです。
| タスク形状 | 推奨手法 | Fable 5 |
|---|---|---|
| 検証可能(コード+テスト・数学・構造化出力) | 手法 B(多数回 + プログラム検証) | 不要 |
| 計画が効く長期エージェント作業(相談を絞れる) | 手法 A(advisor に Fable 5) | 使う(要所) |
| 単発 Q&A・計画の余地なし | どちらも不向き(素直に単一呼び出し) | — |
| 毎トークン frontier 生成が必要 | Fable 5 単独 | 使う |
| 開かれた判断で検証器が作れない | 手法 B は頭打ち → 手法 A か Fable 単独 | 場合による |
組み合わせも有効です。たとえば「advisor で計画を Fable 5 に立てさせ、実装は Sonnet 5、生成物はテストで検証(手法 B)して再試行」——計画は A、正誤は B で担保する、という二段構え。両者は補完します。
共通の限界
どちらの手法も Sonnet 5 の能力の天井そのものは動かしません。
- 手法 A が上げるのは計画の質。実行の生成品質は Sonnet 5 のまま。
- 手法 B が上げるのは**「解ける問題を取りこぼさない確率」**。そもそも解けない問題は N を増やしても解けない。
「回数」や「助言」は、引きの悪さ・計画の弱さを救いますが、能力の欠如は救いません。ここを超える品質が本当に必要なら、素直に Fable 5(または Opus 4.8)を実行モデルに据えるのが正解です。
まとめ
Sonnet 5 を frontier 級に近づける道は 2 つ。手法 A(advisor に Fable 5)は計画が効く長期エージェント作業向きで、要所だけ相談すれば Fable 単独の約 4 割——ただし相談を絞れないと逆に高くつく。**手法 B(検証器つき多数回)**は Fable 5 を使わずに済み、検証可能なタスクでこそ効く——Fable 一発の予算で 5 回回せる一方、開かれた判断では generator–verifier ギャップで頭打ちになる。
選択の軸はシンプルです — 正誤を機械的に検証できるなら手法 B、計画がボトルネックなら手法 A、どちらも能力の天井は超えないと理解する。「安いモデルを主体に、足りない部分だけ補う」——この設計判断ができると、Sonnet 5 は多くのタスクで、実用的なコストのまま一段上の仕事をこなせます。