"thinking.type.disabled"エラー — Fable5/Mythos5で止められない理由

"thinking.type.disabled" is not supportedは何が起きているのか

Claude Fable 5.1・Mythos 5.1・Fable 5・Mythos 5・Mythos Previewにthinking: {"type": "disabled"}を送ると、400 invalid_request_errorが返ります。エラーメッセージは次の内容です。

"thinking.type.disabled" is not supported for this model. Thinking defaults to adaptive mode when not specified; use "thinking.type.enabled" with "budget_tokens" for extended thinking.

このエラーメッセージには罠があります。文面は「thinking.type.enabledとbudget_tokensを使え」と提案していますが、Fable 5.1・Mythos 5.1・Fable 5・Mythos 5の4モデルではその"enabled"も同様に拒否されます(Mythos Previewだけは例外で、こちらは"disabled"だけを拒否し"enabled"は通ります)。エラーメッセージの指示どおりに書き換えても、また400が返ってくるということです。

なぜこれらのモデルはthinkingを止められないのか

Claude Fable 5.1・Mythos 5.1・Fable 5・Mythos 5は、thinkingが常時オンのモデルです。公式のモデル対応表では「Adaptive only / Always on」と分類されており、"enabled"(extended thinking)も"disabled"(無効化)もどちらも拒否対象になっています。設定できる余地がそもそもないという設計です。Claude Fable 5.1の仕様やClaude Fable 5の仕様整理でも、常時思考が主要な変更点として挙げられています。

Mythos Previewだけは"adaptive"と"enabled"の両方に対応し、常時オンである点は共通していますが、拒否されるのは"disabled"だけです。この1モデルだけ挙動が違う点は見落としやすいので、複数のFable/Mythos系モデルを併用する実装では区別して扱う必要があります。

正しい対処 — thinkingパラメータを省略する

このエラーへの対処は、公式ドキュメントでは「thinkingパラメータを省略する」の一択です。省略すればモデルはadaptive thinkingで動作します。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-fable-5-1",
    "max_tokens": 2048,
    "messages": [
      {"role": "user", "content": "この関数のバグを調べてください"}
    ]
  }'

thinkingキー自体をリクエストから外すのがポイントです。{"type": "disabled"}を送らないのはもちろん、その代わりとしてエラーメッセージが提案する{"type": "enabled", "budget_tokens": N}も送りません。リクエストにthinkingを含めないこと自体が対処になります。

thinkingを止めたかった本当の目的は何か

このエラーに遭遇する開発者の多くは、「thinkingを完全に無効化したい」のではなく、「thinkingの内容をレスポンスに含めたくない」だけのケースが大半です。トークン消費を抑えたい、UIにthinkingブロックを表示したくない、といった動機です。

Fable 5系・Mythos 5系ではthinking自体を止めることはできませんが、表示だけを隠す方法が用意されています。thinking設定にdisplay: "omitted"を指定する方法です。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-fable-5-1",
    "max_tokens": 2048,
    "thinking": {
      "type": "adaptive",
      "display": "omitted"
    },
    "messages": [
      {"role": "user", "content": "この関数のバグを調べてください"}
    ]
  }'

これは「thinkingをしない」のではなく「thinkingはするが、その内容をレスポンスに出さない」設定です。モデルは裏側で思考した上で最終回答だけを返します。「無効化したい」という要求の実態が「見せたくない」であるなら、こちらが正しい代替策になります。

実は、Fable 5.1などの新しいモデルではdisplayの既定値がすでに"omitted"です。thinkingパラメータを何も指定しなければ、thinkingブロック自体はレスポンスに含まれますが、本文(思考のテキスト)は空文字列で返ります。つまり「thinkingを無効化したい」という要求の大半は、thinkingパラメータに一切触れずリクエストを送るだけで、実質的にはすでに満たされています。

思考の中身を確認したい場合は、逆にdisplay: "summarized"を指定します。これで生の思考過程ではなく、要約されたthinkingテキストが返ります。ツール呼び出しの合間に挟まる短い進捗ステータスだけが欲しい場合はdisplay: "updates"(ベータ)を使い分けます。ストリーミングで受け取る場合、display: "omitted"ではthinking_deltaイベント自体が送られず、thinkingブロックが開いて1件のsignature_deltaを受け取ってすぐ閉じる、という挙動になります。

モデル別の挙動早見表

Claude Opus 5は別枠として扱う必要があります。thinking: {"type": "disabled"}自体は受け付けますが、effortがxhighまたはmaxの場合はこの組み合わせが拒否されます。Fable/Mythos系のように「常に拒否」ではなく、「effort次第で拒否される」という条件付きの制約です。

Opus 5でthinkingを無効化するとどんな副作用が出るか

Fable/Mythos系は無効化そのものができませんが、無効化できるClaude Opus 5には別の落とし穴があります。thinkingを無効化した状態でツール中心のワークロード(検索など)を回すと、ツール呼び出しがテキスト内に書かれてしまい実行されない、あるいは<thinking>のような内部タグが可視テキストに漏れるという不具合が報告されています。エージェント的なループでは、この漏れたテキストが会話履歴に残り続け、以降のターンにも影響します。「thinkingで考えるな」とsystem prompt側で指示するとこの漏れが増える傾向もあります。

対処は、thinkingを既定どおり再度有効にした上でeffortを下げてトークンコストを抑える方向です。どうしても無効のまま運用する必要がある場合は、プロンプト側での緩和策を追加で当てる必要があります。

Fable/Mythos系のように無効化そのものができないモデルでは、この種の漏れは起きません。thinkingが常時オンである設計は、遠回りに見えて「無効化に伴う副作用」を最初から踏まない設計でもあります。無効化できるモデルと常時オンのモデルのどちらを選ぶかは、コスト制御の自由度と安定性のどちらを優先するかのトレードオフになります。ツール呼び出しの多いエージェント的なワークロードほど、後者の安定性が効いてくる場面が多くなります。

thinking設定を変えるとキャッシュが効かなくなる

thinkingの型(adaptive / enabled / disabled)やeffortの値は、キャッシュされるプロンプトの一部として扱われます。会話の途中でこれらを変更すると、それ以降のリクエストでcache_read_input_tokensが0に落ち、メッセージレベルのキャッシュブレークポイントが無効になります。ツール・system prompt側のブレークポイントも、モデルが設定値をどこに描画するかによっては同様に無効化されます。

同じ会話の中ではthinkingの設定とeffortの値を固定するのが安全です。パラメータを既定値と同じ値に明示的に設定するのは「省略した場合」と等価に扱われ、キャッシュを壊しません。値そのものを変えたときだけ影響が出ます。

Claude Codeで発生した場合の切り分け

Claude CodeなどのSDK経由でこのエラーに遭遇した場合、まず確認すべきは使用中のモデルIDです。Fable 5系・Mythos 5系にモデルを固定した状態で「thinkingを消したい」という設定を試みると、このエラーが起きやすい典型的なパターンです。設定ファイルやフラグでthinkingを明示的に無効化する記述がないか確認し、あれば削除するのが最初のステップです。それでもthinkingの表示だけを消したいなら、display: "omitted"に対応した呼び出し経路があるかをSDKのドキュメントで確認します。設定ファイルやCLIフラグの名前だけでは対応するAPIパラメータが分かりにくいこともあるため、最終的にはリクエストボディに実際に載るthinkingオブジェクトの中身をログで確認するのが最も確実です。

まとめ

Fable 5.1・Mythos 5.1・Fable 5・Mythos 5の4モデルは、thinkingを常時オンで固定しており、"disabled"はもちろん、エラーメッセージが提案する"enabled"も拒否します。正しい対処はthinkingパラメータそのものを省略することです。目的が「thinkingを消す」ではなく「thinkingを見せない」ことなら、display: "omitted"が正しい代替策になります。Mythos PreviewとOpus 5はこの4モデルとは挙動が異なるため、複数モデルを併用する実装ではモデルIDごとに対応表を作っておくと事故を防げます。

よくある質問

display: "omitted"にするとthinkingのトークン消費も減るか

いいえ、消費トークン自体は変わりません。モデルは通常どおりthinkingを行い、そのトークン分は課金対象になります。変わるのはレスポンスに含まれて見えるかどうかだけです。トークン消費を抑えたい場合は、effortを下げてthinkingの分量自体をコントロールする方向で対応します。

Claude Opus 5でも常にdisplay: "omitted"を使ってよいか

使えます。effortの値にかかわらず動作するため、"disabled"のeffort制約を気にしたくない場合は、disabledではなくdisplay: "omitted"に統一しておくと分岐を減らせます。

effortを上げてもFable 5系のthinkingが深くならない場合はどうすればよいか

Fable 5系・Mythos 5系はadaptive thinkingのみに対応するため、effortは思考の頻度・深さを左右する主要なレバーとして機能します。もしeffortを変えても挙動が変わらないように見えるなら、リクエストのどこかでthinkingパラメータにbudget_tokensを指定していないか確認してください。budget_tokensはextended thinking専用の設定であり、adaptive thinkingのモデルに送っても効果を持ちません。extended thinking専用モデル(Opus 4.5・Haiku 4.5・Sonnet 4.5)では逆に、思考の深さを決めるのはbudget_tokensで、effortは基本的に効きません(Opus 4.5だけ両方を併用します)。