株式会社Good Labでエンジニアをしている コータロー です。
日々、Java・SQL・Gitなどの技術情報や、新人エンジニア向けの学習ノウハウ、
AI活用についての情報を発信しています。
Good Labについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト
はじめに
Anthropic から新モデル Claude Fable 5（claude-fable-5） が登場しました。
これまで Claude のモデルラインナップは「Opus（最上位）> Sonnet（バランス）> Haiku（軽量）」の3ティア構成でしたが、Fable 5 は Opus ティアのさらに上に位置する新ティア です。つまり、Anthropic のモデル史上「最も高性能・最も知能の高いモデル」がOpusの上に新設された形になります。
本記事では、公式の Models / Migration ドキュメントで確定している情報のみに基づいて、
- Fable 5 の位置づけとスペック・料金
- API面での他モデルとの違い（実は破壊的変更は1つだけ）
- thinking・サンプリングパラメータ・prefill まわりの実装上の注意
- プロンプトキャッシュの最小プレフィックスというマニアックな挙動差
- Opus 4.8 との使い分け
を整理します。Messages API を直接叩いている方、Agent SDK でエージェントを組んでいる方向けの内容です。
1. Claude Fable 5 とは — Opus の上に立つ新ティア
| 観点 | 内容 |
|---|---|
| 位置づけ | Anthropic の 最上位・最高性能・最高知能 モデル。Opus ティアの上の新ティア |
| モデルID |
claude-fable-5（エイリアス。日付サフィックスは付けない） |
| デフォルト推奨との関係 | AIアプリ構築のデフォルト推奨は引き続き最新の高性能 Claude（Opus 4.8 など）。Fable 5 は「その上の最高峰」として用意 |
ポイントは、Fable 5 が「Opus の置き換え」ではないことです。公式ドキュメント上も、一般的なAIアプリ構築のデフォルトは Opus 4.8 などの高性能モデルのままで、Fable 5 は「最高精度が必要な場面のための最上位の選択肢」という整理になっています。
モデルIDがエイリアスのみ（日付サフィックスなし）という点も、従来の claude-opus-4-8 等と同じ命名スタイルです。
2. スペック・料金 — Opus 4.8 のちょうど2倍
Fable 5 のスペック
| 項目 | 値 |
|---|---|
| コンテキストウィンドウ | 1M トークン |
| 最大出力 | 128K トークン（大きな出力はストリーミング必須） |
| 入力料金 | $10.00 / 1M tokens |
| 出力料金 | $50.00 / 1M tokens |
他モデルとの比較
| モデル | モデルID | 入力 / 出力（per 1M tokens） | コンテキスト | 最大出力 |
|---|---|---|---|---|
| Fable 5 | claude-fable-5 |
$10 / $50 | 1M | 128K |
| Opus 4.8 | claude-opus-4-8 |
$5 / $25 | 1M | 128K |
| Opus 4.7 | claude-opus-4-7 |
$5 / $25 | 1M | 128K |
| Sonnet 4.6 | claude-sonnet-4-6 |
$3 / $15 | 1M | 64K |
| Haiku 4.5 | claude-haiku-4-5 |
$1 / $5 | 200K | 64K |
価格は Opus 4.8 の入力2倍・出力2倍 です。コンテキストウィンドウ（1M）と最大出力（128K）は Opus 4.8 と同じなので、「同じ器で、より高い知能を、2倍の価格で」というポジショニングだと理解できます。
注: 128K の最大出力をフルに使う場合はストリーミングが必須です。非ストリーミングの場合は
max_tokensを 16,000 程度までに抑えるのが目安です（後述のコード例参照）。
3. API面での違い — Opus 4.7/4.8 と同一サーフェス＋破壊的変更は1つだけ
Fable 5 の API は、基本的に Opus 4.7 / 4.8 と同一のリクエストサーフェス です。移行作業は「モデルIDの差し替え＋プロンプトの再調整」が中心で、Opus 4.7 → 4.8 のときと同様、新規の破壊的変更はほぼありません。
ただし、Fable 5 固有の破壊的変更が1つだけ あります。
thinking: {type: "disabled"} の明示が 400 エラーになる
Opus 4.7 / 4.8 : thinking: {type: "disabled"} → 許容される
Fable 5 : thinking: {type: "disabled"} → 400 エラー
Fable 5 では thinking を無効化したい場合でも disabled を明示してはいけません。thinking パラメータ自体を省略する のが正解です。
Opus 4.7/4.8 への移行時に「とりあえず disabled を明示しておく」コードを書いていた場合、Fable 5 に差し替えた瞬間に 400 で落ちるので、移行前に grep しておきましょう。
Opus 4.7/4.8 から引き継がれる制約（Fable 5 でも同様）
以下は Fable 5 固有ではなく、Opus 4.7/4.8 ですでに導入済みの制約です。旧モデル（Sonnet 4.5 以前など）から一気に Fable 5 へ移行する場合は、これらすべてに該当します。
| 制約 | 内容 | 代替手段 |
|---|---|---|
| thinking は adaptive のみ |
thinking: {type: "enabled", budget_tokens: N} は 400（budget_tokens は完全削除） |
thinking: {type: "adaptive"} を使う |
| サンプリングパラメータ削除 |
temperature / top_p / top_k を送ると 400 |
挙動の制御はプロンプトで行う |
| 末尾アシスタントターンの prefill 廃止 | 末尾に assistant ターンを置くと 400 | 構造化出力 output_config.format またはシステムプロンプト指示 |
| thinking 内容はデフォルト非表示 |
display: "omitted"（空）がデフォルト |
見せたい場合は thinking: {type: "adaptive", display: "summarized"}
|
| effort パラメータ対応 |
output_config.effort: low / medium / high / xhigh / max
|
推論の深さとコストのバランス調整に使う |
4. thinking 設定のモデル別早見表
「どのモデルにどの thinking 設定を送ってよいか」は世代によって異なり、移行時にいちばん踏みやすい地雷です。早見表にまとめます。
| モデル | adaptive |
disabled 明示 |
enabled + budget_tokens
|
|---|---|---|---|
| Fable 5 | ◯（唯一の指定方法） | ✕ 400エラー → 省略する | ✕ 400エラー |
| Opus 4.8 / 4.7 | ◯ | ◯（許容。省略も可） | ✕ 400エラー |
| Opus 4.6 / Sonnet 4.6 | ◯（推奨） | ◯ | △ 非推奨だが当面機能（移行用エスケープ） |
| Sonnet 4.5 等の旧モデル | ✕ | ◯ | ◯（budget_tokens < max_tokens、最小1024） |
複数モデルを切り替えて使うアプリでは、「thinking を付けるかどうか」「どの形式で付けるか」をモデルごとに分岐する必要があります。実装方針としては、
-
Fable 5 / Opus 4.8 / 4.7:
thinking: {type: "adaptive"}を付けるか、不要なら丸ごと省略 -
旧モデル: 従来どおり
enabled+budget_tokens
の2系統に分けるのがシンプルです。
5. コード例 — Fable 5 を正しく呼び出す
Python（公式 anthropic SDK）
import anthropic
# APIキーは環境変数 ANTHROPIC_API_KEY から読み込まれる（ハードコードしない）
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-fable-5",
max_tokens=16000, # 非ストリーミングの目安。128K出力はストリーミング必須
thinking={"type": "adaptive"}, # disabled の明示は400。不要なら省略する
messages=[
{
"role": "user",
"content": "このマイクロサービス分割案のリスクを、運用コストの観点で評価してください。",
}
],
)
# thinking ブロックが混ざる可能性があるため、text ブロックのみ出力
for block in response.content:
if block.type == "text":
print(block.text)
Python（128K出力を使う場合 — ストリーミング必須）
import anthropic
client = anthropic.Anthropic()
with client.messages.stream(
model="claude-fable-5",
max_tokens=128000, # 大きな出力はストリーミングが必須
thinking={"type": "adaptive"},
messages=[
{
"role": "user",
"content": "このOpenAPI仕様全体に対する統合テストコードを生成してください。",
}
],
) as stream:
for text in stream.text_stream:
print(text, end="", flush=True)
TypeScript（公式 @anthropic-ai/sdk）
import Anthropic from "@anthropic-ai/sdk";
// APIキーは環境変数 ANTHROPIC_API_KEY から読み込まれる
const client = new Anthropic();
async function main(): Promise<void> {
const response = await client.messages.create({
model: "claude-fable-5",
max_tokens: 16000,
thinking: { type: "adaptive" }, // disabled の明示は400。不要なら省略する
messages: [
{
role: "user",
content: "この認証フローの設計レビューをお願いします。",
},
],
});
for (const block of response.content) {
if (block.type === "text") {
console.log(block.text);
}
}
}
main();
やってはいけない例（400エラーになる）
# ✕ Fable 5 固有のNG: disabled の明示
thinking={"type": "disabled"}
# ✕ budget_tokens は完全削除（Opus 4.7以降と共通）
thinking={"type": "enabled", "budget_tokens": 8000}
# ✕ サンプリングパラメータも削除済み（Opus 4.7以降と共通）
temperature=0.7
6. プロンプトキャッシュの最小プレフィックスが Opus より「短い」
地味ですが面白いモデル差がプロンプトキャッシュにあります。キャッシュが効き始める 最小プレフィックス長 がモデルごとに異なります。
| 最小プレフィックス | 対象モデル |
|---|---|
| 1024 トークン | Sonnet 4.5 / 4.1 / 4 / 3.7 |
| 2048 トークン | Fable 5・Sonnet 4.6・Haiku 3.5 / 3 |
| 4096 トークン | Opus 4.8 / 4.7 / 4.6 / 4.5・Haiku 4.5 |
つまり、同じ約3000トークンのシステムプロンプトでも、Opus 4.8 ではキャッシュされず（4096未満）、Fable 5 ではキャッシュされる（2048以上） という挙動差が生まれます。
Fable 5 は単価が高いぶん、キャッシュヒットのしきい値が低いのはコスト面でありがたい仕様です。Opus 系から移行する場合、「Opus ではキャッシュが効いていなかった中規模プロンプトが、Fable 5 では効くようになる」ケースがあるため、コスト試算は単純な「2倍」では済まないことがあります。
7. いつ Fable 5 を使うべきか — Opus 4.8 との使い分け
入力・出力ともに Opus 4.8 の2倍の価格（$10/$50 対 $5/$25）なので、「全部 Fable 5」は明らかに過剰投資です。公式の整理どおり、デフォルトは Opus 4.8 などの高性能モデルに置き、Fable 5 はピンポイントで使うのが現実的です。
問題は「どこがそのピンポイントか」です。判断軸から整理します。
判断軸 — 2倍の課金が回収できる3条件
Fable 5 を選ぶ価値があるのは、次の3条件のどれかが効くときです。
| 条件 | 内容 | 2倍課金が回収できる理屈 |
|---|---|---|
| (a) 後戻りコストが大きい | 間違えると数日〜数週間の手戻り。一度公開・確定すると変更しづらい | 手戻り1回の人件費 ≫ API料金差 |
| (b) 1発の精度差が成果を左右する | やり直しが効かない、または人間のレビュー・検証コストが高い | 人間の検証時間 ≫ API料金差 |
| (c) 入力が極端に大きく複雑 | 1Mコンテキストをフル活用する整合性チェック等。わずかな見落としが致命傷 | 見落とし1件の損害 ≫ API料金差 |
逆に言えば、「回数が多い・やり直しが効く・人間が安く検証できる」タスクは Opus 4.8 以下で十分 です。失敗してもリトライすればよく、出力の正否がすぐ判定できるタスクに最高単価モデルを当てる理由はありません。
なお、Fable 5 と Opus 4.8 の精度差をベンチマーク数値で語れる確定情報はまだ手元にないため、本節は「最高精度が要る場面で最上位モデルを使う」という相対的な整理に留めます。
Fable 5 が効く具体的な場面
1. モノリス分割のサービス境界の最終決定（条件a）
状況: 数年運用したモノリスをサービス分割したい。境界の候補が複数あり、どれもそれなりに筋が通って見える。
なぜ Fable 5 か: 境界を切ってDBを分離し、チーム編成まで紐づいた後に「切る場所を間違えた」と気づくと、戻すのに数ヶ月単位のコストがかかります。候補出し・依存分析は Opus 4.8 で回し、依存関係グラフ・トランザクション境界・チーム構成まで読ませた最終ジャッジの1回だけ Fable 5 に出させる使い方が割に合います。
2. 課金・認証などコア設計のレビュー（条件a＋b）
状況: サブスクリプションの状態管理や認証フローなど、リリース後に作り直しの効かない部分の設計を確定させたい。
なぜ Fable 5 か: 課金のバグは返金対応・ストアレビュー荒れに直結し（条件a）、「正常系では動くが期限切れ・復元・オフラインの組み合わせで壊れる」類いの欠陥は人間のレビューでも見落としやすい（条件b）。設計書とコードを揃えて「壊れるシナリオを列挙して」と最高精度で1回レビューさせる価値があります。
3. リポジトリ全体＋仕様書＋障害レポートを読ませた仕様矛盾の洗い出し（条件c）
状況: 長期運用プロダクトで、コード・仕様書・過去の障害報告の間にズレが溜まっている疑いがある。
なぜ Fable 5 か: 1Mコンテキストに全部を載せて突き合わせるタスクは、入力が大きいほど「どこか1箇所の見落とし」が起きやすく、その見落としこそが次の障害の種になります。入力トークンが支配的なこの手のタスクは、もともと1回あたりの絶対額が大きいぶん、「やり直しの再実行費用＋見逃しの損害」と比べれば2倍差は誤差になりやすい場面です。
4. 再現性の低いバグの根本原因の仮説出し（条件b）
状況: 月に数回しか起きないデータ不整合。ログ・スレッドダンプ・該当コードは揃っているが、人間が数日張り付いても原因が絞れない。
なぜ Fable 5 か: ここでの比較対象はAPI料金ではなくエンジニアのデバッグ時間です。仮説の質が1段上がって調査が1日短縮されるなら、数ドルの差は問題になりません。「ありうる原因を確度順に、検証方法つきで列挙して」という一発の仮説出しに使います。
5. 公開APIのインターフェース確定（条件a）
状況: 外部公開するREST APIのv1を切る。エンドポイント設計・ページネーション・エラー形式をこれから確定する。
なぜ Fable 5 か: 公開後の破壊的変更はバージョニング・移行期間・利用者対応のコストが極めて高く、「リリース前の最後のレビュー1回」が最も投資効率の高いタイミングです。ドラフトのOpenAPI仕様を読ませ、将来の拡張で詰む箇所・一貫性の欠けを指摘させます。
6. 重要な技術選定のトレードオフ比較の最終ジャッジ（条件a）
状況: 例えば「SwiftData か Core Data＋CloudKit か」のように、後から乗り換えるとデータ移行ごと作り直しになる選定。比較表は Opus 4.8 で作成済み。
なぜ Fable 5 か: 選定そのものより「比較表に漏れている観点（マイグレーション制約、OSバージョン要件、撤退コスト）の指摘」に最上位モデルの価値が出ます。比較表＋自分たちの制約条件を渡して、結論と見落とし観点を1回で出させます。
Opus 4.8 で十分な場面（対比）
| 場面 | Opus 4.8 で十分な理由 |
|---|---|
| 日常のコード生成・修正・小規模リファクタ | やり直しが効く。ビルド・テストで正否が機械的に検証できる |
| テスト作成・ドキュメント生成・定型調査 | 出力の正否を人間が安く検証できる |
| エージェントループの実行役 | 呼び出し回数が多く、単価差がそのまま膨らむ |
| PRレビューの一次パス | 人間の二次レビューが控えており、見逃しても網にかかる |
Fable 5 にしても意味が薄い／むしろ損な例
- 高頻度のバッチ分類・ラベリング: タスクが単純で精度が Opus / Sonnet で頭打ちになりがちなうえ、件数が多いので2倍課金がそのまま2倍の請求になる。回収の見込みがない典型例
- 単純な要約・抽出: 同上。むしろ Sonnet 4.6 / Haiku 4.5 へ落とす方向を検討すべき場面で、上位モデルに上げるのは逆方向
実務的な落とし所 — パイプラインの1〜2箇所だけ差し替える
「実行は Opus 4.8、最終ジャッジだけ Fable 5」が、コスト2倍に最も見合う構成です。サブエージェント構成のイメージはこうなります。
[調査エージェント]──┐
claude-opus-4-8 │ 候補案・分析結果を集約
[分析エージェント]──┼──→ [最終ジャッジ]──→ 人間が承認
claude-opus-4-8 │ claude-fable-5
[実装エージェント]──┘ （1回だけ呼ぶ）
claude-opus-4-8
コードにするなら、モデル選択を1関数に寄せておくと差し替えが楽です。
def select_model(task_type: str) -> str:
"""後戻りコストの大きい最終判断のみ Fable 5 に振り分ける"""
if task_type in ("final_judgement", "core_design_review"):
return "claude-fable-5"
return "claude-opus-4-8"
ポイントは、Fable 5 の呼び出しを**回数の増えない位置（パイプラインの終端・ループの外）**に置くことです。ループの中に入れた瞬間、単価差が回数倍で効いてきます。
判断チェックリスト — 2つ以上YESなら Fable 5
- 間違えると数日以上の手戻り、または公開後に変更しづらい判断か？
- やり直しが効かない、または人間による検証・デバッグのコストが高いか？
- 入力が大規模・複雑で、わずかな見落としが致命的になるか？
まとめ
| ポイント | 内容 |
|---|---|
| 位置づけ | Opus ティアの上に新設された最上位ティア。Opus の置き換えではない |
| スペック | 1M コンテキスト・128K 出力（Opus 4.8 と同じ器） |
| 料金 | $10 / $50（Opus 4.8 のちょうど2倍） |
| API | Opus 4.7/4.8 と同一サーフェス。固有の破壊的変更は disabled 明示が400 の1点のみ |
| thinking | adaptive のみ。無効化したいならパラメータごと省略 |
| キャッシュ | 最小プレフィックス 2048 トークン（Opus 系の 4096 より短い） |
| 使い分け | デフォルトは Opus 4.8。後戻りコスト大・一発精度勝負・超大規模入力の1〜2箇所だけ Fable 5 |
移行自体はモデルIDの差し替えでほぼ完了しますが、thinking: {type: "disabled"} を明示しているコードだけは事前に潰しておきましょう。
参考
- Models overview - Anthropic
- Extended thinking - Anthropic
- Prompt caching - Anthropic
- Messages API - Anthropic
@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！