Claude Fable 5（フェイブル5）移行ガイド：budget_tokens（バジェットトークン）廃止とeffort（エフォート）パラメータ・400エラー回避

Anthropicが2026年6月9日に一般提供を始めたClaude Fable 5（フェイブル5）は、Opus / Sonnet / Haiku の上に新設された「Mythos クラス」に属する最上位モデルです。能力は魅力的ですが、Opus 4.8 からコードをそのまま流用すると400エラーで止まる箇所がいくつかあります。

つまずきやすいのは大きく3点。budget_tokens（バジェットトークン）が廃止されたこと、thinking を明示的に無効化すると400になること、そしてtemperature / top_p / top_k を既定値以外にすると400になることです。本記事ではこの3点を、effort（エフォート）パラメータを中心に実装目線で整理します。

Opus 4.8 / 4.7 とAPIの作法はほぼ同じなので、変更点だけ押さえれば移行は短時間で済みます。どこを消し、どこを置き換えるかを順番に見ていきます。

Fable 5 とはどんなモデルか

移行作業に入る前に、対象モデルの基本スペックを押さえておきます。Fable 5 は claude-fable-5 というモデルIDで呼び出します。Anthropicの公開資料では、これが一般提供される最上位ティアのモデルと位置づけられています。

モデルIDと基本スペック

モデルIDは claude-fable-5 です。コンテキストウィンドウは既定で100万（1M）トークンに対応し、1リクエストあたり最大12.8万（128K）トークンの出力に対応します。1Mコンテキストは標準価格の範囲内の既定値で、長文専用の別料金ティアではありません。姉妹モデルの Claude Mythos 5 は限定提供のみで、一般提供はされません。

料金とスペックは上の早見表で把握しておくと、移行時の見積もりがぶれません。実装側で気にすべきは出力上限が128Kである点です。これは1リクエストあたりのハードリミットで、ストリーミングを使っても128Kを超える出力は得られません。そのうえで、128K級の大きな出力を扱う際にはストリーミングが必要になり、SDKもおおむね16Kを超える出力ではストリーミングの利用を推奨しています。Anthropicの発表では、コーディングやビジョンなどの軸で従来モデルを上回るとされています。

価格はOpus 4.8のちょうど2倍

Fable 5 の価格は入力が100万トークンあたり10ドル、出力が100万トークンあたり50ドルです。これは Opus 4.8 の5ドル / 25ドルのちょうど2倍にあたります。プロンプトキャッシュのキャッシュヒットは入力を最大90%割引（1ドル / 100万トークン相当）、Batch API は入力・出力ともに50%割引です。

価格が2倍である点と、後述するトークン消費の増加が重なるため、コスト試算は早めにやり直しておくのが無難です。難しい課題だけ Fable 5、それ以外は Opus 4.8 という使い分けも実務では検討されています。Claudeの料金体系を整理したい場合は、Claudeの料金体系をまとめた記事もあわせて確認してください。

budget_tokens の廃止とeffortへの置き換え

移行で最初に当たる変更がここです。Fable 5 の思考モードはアダプティブシンキング（adaptive thinking）のみで、手動でトークン数を指定する budget_tokens は削除されました。

budget_tokens を送ると400になる

これまで thinking: {type: "enabled", budget_tokens: N} のように固定の思考トークン量を指定していたコードは、Fable 5 では400エラーになります。これは Opus 4.7 / 4.8 から引き継がれた挙動で、Fable 5 でも budget_tokens は完全に削除されています。代わりに思考の深さは effort パラメータで制御します。

effort パラメータの使い方

effort は思考の深さと全体のトークン消費を制御するパラメータで、トップレベルではなく output_config の中に置きます。値は low / medium / high / xhigh / max で、Fable 5 では max と xhigh の両方が使えます。既定値は high（省略時と同等）です。これらの値の構成は Opus 4.7 / 4.8 と共通で、Fable 5 で新しい段階が増えたわけではありません。

実装の目安として、コーディングやエージェント用途では xhigh、知性が問われる作業では最低でも high を使う、というのが推奨される運用です。サブエージェントや単純なタスクには low を使い、正確さがコストより重要な場面では max を選びます。effort の使い分けはモデルの挙動を大きく変えるため、移行時に再調整しておく価値があります。

上の図に effort の段階を並べました。budget_tokens の数値と1対1で対応するわけではないので、移行直後は代表的なプロンプトで挙動を確認しながら値を決めるのが安全です。Claudeのthinking機能そのものの背景を知りたい場合は、thinking機能の解説記事が参考になります。

thinking を明示的に無効化すると400

Fable 5 固有のクセがここです。Opus 4.8 / 4.7 では受け付けられていた書き方が、Fable 5 では400を返します。

disabled が許容されない

Fable 5 はアダプティブシンキングのみを思考モードとして持つため、thinking: {type: "disabled"} のように思考を明示的に「無効化」するとエラーになります。Opus 4.8 / 4.7 はこの指定を許容していたので、両モデル向けに分岐していたコードは要修正です。

回避はthinkingパラメータを省略するだけ

回避策はシンプルで、thinking パラメータ自体を渡さないことです。disabled を明示する代わりに省略すれば、エラーは出ません。思考を活かしたい場合は {type: "adaptive"} を明示的に指定します。Opus 4.8 と同様に、thinking を完全に切ると可視レスポンス側に長めの推論が書き込まれることがあるため、最終回答だけ返してほしい場合はアダプティブを有効にしておくか、出力を最終回答のみに絞る指示を添えると整います。

サンプリングパラメータも既定値外で400

3つ目のつまずきが temperature / top_p / top_k です。これらは Opus 4.7 / 4.8 から引き継がれた制限で、Fable 5 でも既定値以外を指定すると400を返します。

temperature・top_p・top_k は削除する

リクエストから temperature、top_p、top_k のフィールドを削除します。出力の傾向を調整したい場合は、これらの数値ではなくプロンプトで誘導するのが Fable 5 での推奨アプローチです。temperature を0にして決定的な出力を狙っていた場合でも、もともと以前のモデルでも完全に同一の出力を保証するものではありませんでした。

決定性を重視していたなら effort を low にしてプロンプトを締める、創造的なばらつきが欲しかったなら表現や構成を変えるよう指示する、といった置き換えが実務的です。

移行前後で消えるパラメータ一覧

下表は Opus 4.8 から Fable 5 へ移行する際に「消すもの・置き換えるもの」を整理したものです。コードレビューのチェックリストとして使えます。

項目	Opus 4.8 まで	Fable 5 での扱い
budget_tokens	Opus 4.7/4.8で既に廃止	送ると400。adaptive + effort に置換
thinking: disabled	許容される	送ると400。パラメータごと省略
temperature / top_p / top_k	既定値外で400	同じく400。削除してプロンプトで誘導
effort の値	low / medium / high / xhigh / max	同じ値が使える（変更なし）

effort の段階は Opus 4.8 から変わりません。xhigh は Opus 4.7 の時点で追加された値で、Fable 5 で新設されたものではない点に注意してください。これら3系統の400は、いずれも「不要になったパラメータを消す」か「adaptive + effort に置き換える」だけで解消します。API全体の作法は Opus 4.8 / 4.7 とほぼ同一なので、変更箇所は限定的です。

移行で見落としやすい周辺の注意点

400エラー以外にも、Fable 5 では挙動が静かに変わる箇所があります。エラーにはならないため気づきにくく、移行後のコストや表示に影響します。

トークン消費は約30%増える前提で見積もる

Fable 5 と Mythos 5 は Opus 4.7 で導入されたトークナイザを使用します。同じテキストでも Opus 4.7 以前のモデルより約30%多くトークンを消費する（ワークロード依存の概算値）とされています。価格が2倍であることと合わせると、実効コストは単純な2倍では収まらない可能性があります。

クライアント側のトークン推定や、レート制限の閾値をトークン数に紐づけている箇所は再確認が必要です。max_tokens やコンパクションのトリガにも余裕を持たせ、一律の倍率ではなく代表的なプロンプトで実測して再ベースライン化するのが堅実です。

対応機能とデータ保持ポリシー

Fable 5 はローンチ時点で、effort パラメータ、Task Budgets（ベータ）、構造化出力、高解像度ビジョン、Web検索の動的フィルタ、サーバ側コンパクションなどに対応します。memory tool や context editing 経由の tool-result クリア（ベータ）も利用できます。

運用面で注意したいのがデータ保持です。Mythos クラス（Fable 5 を含む）のトラフィックはゼロデータ保持ではなく、30日間のデータ保持ポリシーが適用されます。これは既存のZDR契約をこのモデルクラスに限り上書きするため、金融・医療・セキュリティ用途では事前確認が要ります。なお安全分類器の働きで、サイバーセキュリティや生物・化学に関わる一部のリクエストは Opus 4.8 へ回されることがあります。提供チャネルや最新情報は、最新アップデート情報の記事も随時参照してください。

一次情報を確認したい場合は、公式の移行ガイド、effortパラメータのドキュメント、そしてAnthropicの発表を起点にすると確実です。

まとめ

Fable 5 への移行で詰まる点は、突き詰めると「不要になったパラメータを消す」か「adaptive thinking + effort に置き換える」かのどちらかに収束します。

移行チェックの要点

第一に budget_tokens を削除し、思考は thinking: {type: "adaptive"} に切り替えて深さは effort（low / medium / high / xhigh / max）で制御します。effort の段階は Opus 4.8 と同じで、xhigh も従来どおり利用できます。第二に thinking の disabled を明示せず、無効化したいときはパラメータごと省きます。第三に temperature / top_p / top_k を削除し、出力の傾向はプロンプトで誘導します。

そのうえで、トークン消費が約30%増える前提でコストと max_tokens を見直し、30日間のデータ保持ポリシーを用途に照らして確認しておけば、移行は実装上ほぼ問題なく進みます。API の作法自体は Opus 4.8 / 4.7 とほぼ同一なので、変更点さえ押さえれば短時間で乗り換えられます。