Claude Fable 5（フェイブル5）のアダプティブシンキングとは：思考モードが1つになった理由とeffort（エフォート）low〜maxの使い分け

Claude Fable 5（フェイブル5）では、これまでモデルごとに違っていた「思考の設定」が、アダプティブシンキング1本に整理された。手動で思考トークン量を指定する budget_tokens は廃止され、代わりに effort（エフォート）パラメータで深さを調整する形になっている。

この記事では、アダプティブシンキングという考え方そのものと、low / medium / high / xhigh / max という5段階の effort をどう使い分けるかを、ユースケース別に整理する。なぜ手動の思考予算が消えたのか、その背景も合わせて見ていく。

Fable 5 は Opus / Sonnet / Haiku の上に新設された「Mythos クラス」という新ティアに属する、Anthropic の最も高性能なモデルとして 2026年6月9日に一般提供が始まった。思考まわりの設計は、その位置づけと深く結びついている。

アダプティブシンキングとは何か

アダプティブシンキング（adaptive thinking）は、モデル自身がタスクごとに「どれくらい考えるか」を動的に決める仕組みだ。利用者が事前に思考量を数値で指定するのではなく、問題の難しさに応じてモデルが内部で配分する。

「考える深さ」を人間が固定しない設計

従来のモデルでは、拡張思考（extended thinking）を使うとき、思考に割り当てるトークン上限を budget_tokens として人間が指定していた。簡単な質問には少なく、難しい問題には多く、という調整を呼び出し側が手作業で行う必要があった。アダプティブシンキングでは、この配分の判断をモデル側に委ねる。リクエストごとに思考の深さが変わり、ツール呼び出しの合間にも思考が挟み込まれる形になる。Fable 5 ではこのアダプティブシンキングが唯一の思考モードになっている。

Fable 5 ではアダプティブが唯一の思考モード

Fable 5 において、思考モードはアダプティブシンキングだけだ。手動で budget_tokens を指定する従来のやり方は廃止されており、その値を渡すと 400 エラーになる。手動で思考量を刻む発想そのものが、このモデルでは前提から外れている。利用者側が意識するのは「どれくらい本気で考えさせるか」という方向性だけで、その方向性を表すのが次に説明する effort パラメータになる。手動の予算指定からアダプティブへの移行については、後述する公式の移行ガイドにまとまっている。

サンプリング設定も同時に整理された

思考まわりだけでなく、出力のばらつきを調整する temperature / top_p / top_k といったサンプリング設定も、Fable 5 では既定値以外を指定すると 400 エラーを返す。これは Opus 4.7 / 4.8 から引き継がれた制限で、挙動の調整は数値パラメータではなくプロンプトで行う、という設計思想がモデル全体で一貫している。Claude の思考機能の流れを押さえたい人は、Claudeのthinking機能を扱った記事と合わせて読むと、設計の変化が掴みやすい。

なぜ手動の思考予算が消えたのか

budget_tokens の廃止は、単なる機能削減ではなく、思考の制御を「人間が数値で刻む」から「モデルが自律的に配分する」へ移すための整理だ。

数値での予算指定は最適解とは限らない

思考トークンの上限を固定すると、簡単なタスクで過剰に考えさせたり、逆に難しいタスクで思考が足りなくなったりという、ミスマッチが起きやすい。タスクの難易度はリクエストごとに変わるため、一律の数値では合わせ込みが難しい。アダプティブシンキングは、この配分の判断をモデルに寄せることで、リクエスト単位で深さが変わるようにしている。固定値で運用していたときに感じやすかった「軽い処理にトークンを使いすぎる」「重い処理で考えが浅い」という両極端のずれを、モデル側で吸収する狙いがある。

予算の代わりに「努力量」を指定する

budget_tokens がなくなった代わりに導入されたのが effort パラメータだ。これは思考の深さと、全体のトークン消費の傾向をまとめて調整するもので、トークン数という細かい単位ではなく「どの程度の努力量で取り組むか」という粒度で制御する。Fable 5 では low / medium / high / xhigh / max の5段階が利用でき、xhigh と max も指定できる。1対1の厳密な置き換えではないが、考え方としては budget_tokens の役割を effort が引き受けている、と捉えると分かりやすい。

「無効化」だけは特別扱い

Fable 5 には固有のクセがある。思考を明示的に「無効化」する指定を渡すと 400 エラーになる、という点だ。これは Opus 4.8 / 4.7 では許容されていた挙動で、Fable 5 だけが異なる。思考を抑えたい場合は無効化を指定するのではなく、思考に関する指定そのものを省略する、という対応になる。最上位モデルでは「思考しない」という選択肢が前提から外れている、と捉えると整理しやすい。

effort の5段階を整理する

effort は low / medium / high / xhigh / max の5段階で、Fable 5 では xhigh と max も利用できる。下に行くほど思考が浅くなり、上に行くほど深くなる、という並びで捉えると見通しが立つ。

各レベルの位置づけ

大まかには、レベルを上げるほど思考が深くなり、ツール呼び出しも丁寧になる一方で、トークン消費と応答時間が増える。逆にレベルを下げると、ツール呼び出しがまとまり、前置きが減り、確認も簡潔になる。下の表は各レベルの傾向を整理したものだ。

effort	傾向	向いている場面
low	最小限の思考・短い応答	軽いタスク、サブエージェント、レイテンシ重視
medium	コストを抑えつつ妥当な品質	トークン消費を絞りたい場面
high	品質と効率のバランス	知性が問われる作業全般の起点
xhigh	high と max の中間	コーディング・自律的なエージェント作業
max	正確性をコスト以上に優先	難問・正確性が最優先のケース

high を起点にして上下に振る

知性が問われる作業では、まず high あたりを起点にすると扱いやすい。そのうえで、コーディングや長時間の自律タスクなら xhigh、特に難しく正確性を最優先したいケースでは max、という形で上に振る。逆にレイテンシやコストを優先したい軽いタスクでは low や medium に下げる。max は常に最良とは限らず、過剰に考え込んでしまうこともあるため、まずは扱いやすいレベルから試して必要に応じて調整するのが現実的だ。

アダプティブと組み合わせて効かせる

effort はアダプティブシンキングと組み合わせて使うことで、コストと品質のバランスを取りやすくなる。思考の「いつ・どれだけ」をモデルが判断し、その全体の努力量の傾向を effort で枠付けする、という二段構えだ。Claude の料金体系を踏まえてトークン消費を見積もりたい場合は、Claudeの料金体系を整理した記事も参考になる。

ユースケース別の effort 使い分け

ここでは、よくある作業のタイプごとに、どの effort を起点にすると扱いやすいかを整理する。あくまで出発点であり、実際のワークロードで計測しながら調整するのが前提だ。

コーディングと自律的なエージェント

コードを書かせる作業や、複数ステップを自律的に進めるエージェント的なタスクでは、xhigh が起点になりやすい。Fable 5 はコーディングや知識作業のベンチマークで高いスコアが報告されており、こうした作業に向く設計とされる。最初のリクエストでタスクの仕様をしっかり伝えたうえで、高めの effort で走らせると噛み合いやすい。ベンチマークの値はベンダーやアグリゲータの報告であり、独立した第三者監査ではない点は押さえておきたい。

知識作業・分析・文章作成

調査や分析、文章作成といった知性が問われる作業では、high あたりを確保しておくと安定しやすい。トークン消費を抑えたい場合は medium に下げる選択肢もあるが、その分、踏み込みが浅くなる傾向とのトレードオフになる。Fable 5 は分析系のベンチマークで高いスコアが示されているものの、これらもベンダーやアグリゲータの報告値であって、独立した第三者監査の結果ではない。数値そのものは複数ソースで一致しているが、出どころの性質は理解したうえで参考にしたい。

軽いタスクとサブエージェント

分類や短い要約のような軽い処理、あるいは大きなタスクの一部を担うサブエージェントでは、low が向いている。思考とトークンを節約でき、レイテンシも下げられる。下げすぎると複雑な問題で思考不足になりかねないため、対象が本当に軽量かどうかを見極めて選ぶ。Claude のプラン別の料金感を把握しておくと、こうした使い分けの判断材料になる。料金まわりはClaudeのプラン別料金の記事で確認できる。

Fable 5 のスペックと位置づけ

思考設計の背景を理解するうえで、Fable 5 そのもののスペックと立ち位置も押さえておきたい。

新ティア「Mythos クラス」の一般提供モデル

Fable 5 は、Opus / Sonnet / Haiku の上に新設された Mythos クラスに属する。Anthropic の最も高性能・最も賢いモデルと位置づけられ、一般提供される Mythos クラスのモデルがこの Fable 5 だ。コンテキストウィンドウは標準で100万（1M）トークン、1リクエストあたりの出力は最大12.8万（128K）トークンに対応する。1M は標準価格内の既定値で、別料金ティアではない。

価格とトークン消費の注意点

価格は入力が100万トークンあたり $10、出力が100万トークンあたり $50。これは Opus 4.8 の $5 / $25 のちょうど2倍にあたる。さらに、Fable 5 は Opus 4.7 で導入されたトークナイザを使うため、同じテキストでも以前のモデルより約30%多くトークンを消費する（ワークロード依存の概算値）。effort を上げるほどトークン消費は増えるので、価格とトークナイザの両面を踏まえて effort を選ぶと、コストの見通しが立てやすい。

対応機能とデータ保持の前提

Fable 5 はローンチ時点で、effort パラメータ、構造化出力、高解像度ビジョン、サーバ側コンパクション、Web検索の動的フィルタリングなどに対応している。一方で、Mythos クラスのトラフィックにはゼロデータ保持ではなく30日間のデータ保持ポリシーが適用される点には注意が必要だ。金融・医療・セキュリティ用途では、この前提を事前に確認しておきたい。API の作法は Opus 4.8 / 4.7 とほぼ同一なので、既存の使い方に近い感覚で扱える。最新のアップデート全体を追いたい場合は、Claudeの最新アップデート情報をまとめた記事も合わせて確認するとよい。

公式情報での確認の仕方

仕様は更新されることがあるため、最終的には一次情報で確認するのが確実だ。

effort と移行ガイドを押さえる

effort の各レベルや、budget_tokens からの移行については、Anthropic の Effort パラメータのドキュメントと 移行ガイドが出発点になる。アダプティブシンキングへの切り替えや、廃止されたパラメータの扱いがまとまっている。Fable 5 と Mythos 5 の全体像については、Claude API のモデル紹介ドキュメントを参照したい。

数値は一次情報を優先する

ベンチマークのスコアや無料利用ウィンドウの締切など、変動しうる数値については、本記事では断定を避けている。たとえば無料で含まれる期間には「容量が許せば延長され得る」という注記があり、確定した締切ではない。最新の正確な値は、必ず公式ドキュメントや発表で確かめてほしい。

まとめ

「数値で刻む」から「努力量で枠付ける」へ

Claude Fable 5（フェイブル5）の思考設計は、アダプティブシンキングへの統一と budget_tokens の廃止によって、「思考量を人間が数値で刻む」発想から「モデルが配分し、利用者は努力量で枠付ける」発想へと移った。利用者が意識するのは、low / medium / high / xhigh / max のどこを起点にするか、という一点になる。

使い分けの目安は、知識作業には high あたり、コーディングや自律的なエージェントには xhigh、難問で正確性を最優先したいときは max、軽量タスクやサブエージェントには low。そのうえで、Fable 5 はトークン消費が増えやすく価格も Opus 4.8 の2倍であることを踏まえ、実際のワークロードで計測しながら effort を調整していくのが、無理のない進め方になる。