Claude Fable 5.1が公開されました — 料金の読み方、400が返る書き方、履歴を書き換えられない仕様

Claude Fable 5.1のリリース日は2026年9月1日です。モデルページに載っている仕様は、コンテキストウィンドウが100万トークン(この最大値がそのまま既定)、1リクエストあたりの最大出力が128,000トークン、思考はアダプティブで常時有効、既定のeffortはhigh、信頼できる知識カットオフとトレーニングデータのカットオフがどちらも2026年6月です。相対的なレイテンシは、現行4モデルの中でいちばん遅い「低速」と表記されています。提供終了は2027年9月1日以降とされていますが、この日付が約束されているのはAnthropicが運営するプラットフォーム(Claude API、Claude Platform on AWS、Microsoft Foundry)で、Amazon BedrockとGoogle Cloudは各社が独自の終了スケジュールを決めます。

モデルIDはClaude APIで「claude-fable-5-1」です。Google Cloud、Microsoft Foundry、Claude Platform on AWSも同じ文字列を使い、Amazon Bedrockだけが「anthropic.claude-fable-5-1」とプロバイダの接頭辞を付けます。この文字列はそのままで完全で、日付のサフィックスを足す形式は用意されていません。Claude Mythos 5.1(claude-mythos-5-1)は同じ仕様と同じ価格の同一能力モデルですが、Project Glasswingの参加者にのみ提供されます。

位置づけは、モデル一覧のページと新機能のページの冒頭に、同じ2文で書かれています。どれを使うか迷ったら、ほとんどのワークロードはClaude Opus 5から始めること。Claude Fable 5.1は、要求の厳しい推論と長時間のエージェント作業、またはOpus 5を高いeffortで評価してもなお結果が足りない場合に使うこと。新しいから上位互換、という並びにはなっていません。まずOpus 5でeffortを上げて測り、それでも足りなかったときに明示的に選ぶモデルです。

100万トークンあたりの単価は、入力が$10、出力が$50です。Opus 5は入力$5・出力$25、Sonnet 5は入力$2・出力$10、Haiku 4.5は入力$1・出力$5なので、Fable 5.1はOpus 5のちょうど倍にあたります。ここまでは前世代のFable 5と同額で、値上げがあったわけではありません。

逆になっているのがキャッシュ読み取りです。Fable 5.1のキャッシュ読み取りは$0.25で、これはベース入力の0.025倍にあたります。公式ドキュメントは「ほかのClaudeモデルでは0.1倍であるのに対して」と明記しています。実額で並べると、前世代のFable 5の$1に対して4分の1、Opus 5の$0.50に対して半額、Sonnet 5の$0.20よりはまだ高い、という位置です。5分間のキャッシュ書き込みが$12.50、1時間のキャッシュ書き込みが$20、キャッシュ可能な最小のプロンプト長が512トークンという点は、Fable 5から変わっていません。Batch APIは入力・出力とも50%割引です。

つまり、料金表の見出しだけを見て「倍」と判断すると、用途によっては読み違えます。同じプレフィックスを何度も読み直す長いエージェントセッションでは、請求のうちキャッシュ読み取りが占める割合が大きくなるため、単価の倍率と請求の倍率は一致しません。逆に、毎回プレフィックスが変わってキャッシュが当たらない使い方では、倍率がほぼそのまま効きます。

Fable 5.1とMythos 5.1はCovered Modelに分類されていて、30日のデータ保持が必要です。Anthropicが明示的に承認した場合を除き、zero data retentionの設定では利用できません。Claude APIでは、30日保持を満たしていない組織やワークスペースからのリクエストは400 invalid_request_errorで返ります。リクエストの書き方ではなく組織やワークスペースの設定で決まるため、コードを1行も変えていなくても最初の1回で弾かれます。移行直後に理由の見当たらない400が出たら、ペイロードを疑う前に組織の保持設定を確認したほうが早いということです。

この条件はFable 5とMythos 5にも同じくかかっていたので、Fable 5から移る場合は新しい制約ではありません。一方、Opus 5はzero data retentionでも使えるモデルなので、Opus 5から移ると条件が1つ増えます。30日保持という要件そのものは、Covered Modelが提供されているすべての場所に適用されます。プラットフォームで違うのは保持されたデータの置き場所で、Claude API(Claude Platform on AWSを含む)とMicrosoft FoundryはAnthropicがデータ処理者になり、Amazon BedrockとGoogle Cloudでは保持データがそのクラウド事業者の環境にとどまります。有効化の手順も各プラットフォームの文書を見ることになります。

使えなくなるものも2つあります。Fable 5.1とMythos 5.1はPriority Tierの対象外で、公開されている移行ガイドに「どちらのモデルもPriority Tierではサポートされない。Claude Fable 5はサポートされる」と明記されています。Fast Modeも使えません。公開のFast modeページに載っている対応モデルはClaude Opus 5とClaude Opus 4.8の2つだけで、Claude API(Claude Managed Agentsを含む)限定のリサーチプレビューとされています。Fable 5をPriority Tierで呼んでいた呼び出し元があるなら、移行後はその優先度が失われる前提で考えてください。

thinkingは常時オンです。パラメータを省略すればアダプティブ思考が自動で適用され、明示的に「adaptive」を送っても同じです。それ以外の指定は受け付けられず、「disabled」も、budget_tokensを添えた「enabled」も400を返します。budget_tokensと1対1で対応するパラメータはありません。公式が挙げている置き換えは、thinkingの指定を丸ごと外したうえで、トークンの消費はoutput_configのeffortを下げて抑え、max_tokensを見直すという組み合わせです。effortは、アダプティブ思考が使えるモデルでは思考の深さを制御する推奨手段だと書かれていますが、厳密なトークン予算ではなく、思考だけでなく応答も含めた出力全体にかかります。

移行のときにいちばん引っかかりやすいのは、強制ツール使用が400になることです。tool_choiceの「any」と「tool」は、Messages APIでもトークン計数のエンドポイントでも、これらのモデルではサポートされないというエラーを返します。理由も公式に書かれています。これらのモデルでは思考が常時オンで、ツール呼び出しを強制するとその思考が飛ばされ、モデルが考えた内容がツールの引数のほうに書き込まれてしまい、引数の質が下がるためです。「auto」(既定)と「none」は変更ありません。

書き換え方は目的別に分かれます。引数がスキーマどおりであることを保証したかっただけなら、tool_choiceは「auto」のままにして、ツール定義にstrictを立てるか、スキーマをstructured outputsへ移します。テキストで答えずにツールを呼ばせたかったのなら、プロンプトの中でツール名を挙げて、どういうときにそれを使うのかを書きます。公式ドキュメントは、Fable 5.1が明示的なツール指示に確実に従うと書いています。

この節に出てきたもののうち、Fable 5からの新しい破壊的変更は強制ツール使用の400だけで、残りはFable 5から引き継いだ仕様です。アシスタント応答のプレフィル(最後のassistantターンを途中まで書いて続きを生成させる書き方)は400になります。temperature、top_p、top_kも、既定値以外を入れると400です。決定性が目的でtemperatureを0にしていた場合の代わりは、公開ドキュメントには書かれていません。Claude Codeに同梱されている移行ガイドには、effortを下げてプロンプトを厳密にするという書き換えと、そもそもtemperatureを0にしても以前のモデルで同一出力が保証されていたわけではない、という注記が並んでいます。

Fable 5.1でいちばん構造に効く変更が、公式ドキュメントでpreserved thinkingと呼ばれている仕組みです。中身は2つあります。1つ目は、thinkingブロックがそれを生成したモデルに紐づくことです。向きは一方通行で、Fable 5.1は以前のモデルのthinkingブロックを読めますが、以前のモデルはFable 5.1のブロックを読めません。Opus 5やFable 5から会話をFable 5.1へ移すと推論は引き継がれ、逆にFable 5.1から古いモデルへ移すと、そちら側で走るターンの分は失われます。

読めないブロックが混ざったリクエストは失敗しません。APIがモデルに渡す前にそのブロックを落とし、落とされた分はinput_tokensにも計上されず課金もされません。したがって、コストのためにthinkingブロックを剥がす必要はありません。自分で剥がす場合も、公式に有効とされているのは先頭から古い順にまとめて剥がす形だけです。途中の1つを抜いて後ろを残すと、それ以降のthinkingブロックが全部無効になります。落ちたことを知りたい場合は、ベータヘッダの「thinking-binding-controls-2026-08-01」を付けると、レスポンスのトップレベルにinput_transformationsという配列が返ります。付けなければ無言で落ちます。

2つ目が、会話そのものへの紐づけです。thinkingブロックより前にあるもの——トップレベルのsystemプロンプト、toolsの配列、それ以前のメッセージ——を変更すると、次のリクエストでエラーになるか、明示的に指定していればそのブロックが落とされます。無効になるのは変更した箇所だけではなく、それ以降のthinkingブロック全部です。この検査が既定で強制されるのは2026年8月31日以降に作成されたアカウントで、それより前のアカウントでは、リクエストがprefix_mismatch_behaviorを設定したときだけ動きます。Mythos 5.1はこの検査を実行しません。

個人開発者にとって大事なのは、ここで自分が当事者かどうかです。公式ドキュメントは、Claude Code、claude.ai、Claude Managed Agents、Claude Agent SDKについては、このプレフィックスを壊さないように作られていると明記しています。関係があるのは、自分でmessages配列を組み立てているコードのほうです。毎ターンのリマインダーを前のターンに注入して次のリクエストで消す、古いtool_resultを間引く、クライアント側で要約して直近のターンだけそのまま残す——このあたりは全部、履歴の編集にあたります。

Fable 5.1には安全性の分類器が入っていて、断られたリクエストはHTTP 200の成功レスポンスとして返ります。中身のstop_reasonが「refusal」になり、stop_detailsにどのポリシー領域が反応したかが入ります。例外は投げられないので、try/catchで囲んでいても引っかかりません。content配列を先に読むコードは、拒否のときに壊れます。分岐はstop_reasonに対して書くのが正解です。

フォールバックは自動ではありません。何も設定していないリクエストは、拒否されたところでそのまま止まります。サーバ側のフォールバックを使う場合、いちばん単純な形はベータの「fallbacks: default」で、これは拒否のカテゴリに応じてAnthropicが推奨するモデルへ再試行します。Fable 5.1で許可されているフォールバック先は、Claude Opus 4.8とClaude Opus 5の2つです。ただしこれはClaude API限定で、Amazon Bedrock、Google Cloud、Microsoft FoundryではSDKのクライアント側ミドルウェアを使うことになります。Message Batches APIでも使えません。推奨先が定義されていないカテゴリでは再試行されず、拒否がそのまま返ります。

課金の扱いも書かれています。出力が1トークンも出る前に拒否が発火した場合、その分の課金は発生しません。トークン数はusageに載りますが請求されない、という書き方です。ただしレート制限は消費します。ストリームの途中で発火した場合は、入力トークンと、すでに流れた出力の両方が通常のレートで課金されます。出力側だけが無料になるわけではないので、その部分出力は完成品として扱わずに捨てることになります。Fable 5.1にはfallback creditという仕組みもあり、モデルを切り替えたときのプロンプトキャッシュのコストを二重に払わずに済みます。サーバ側フォールバックとSDKミドルウェアでは自動で効きますが、自前でリトライを書く場合は自分で組み込む必要があります。

ここから先はAPIの破壊的変更ではなく、同じコードのまま挙動が変わる部分です。公式ドキュメントは7つ挙げていて、それぞれにプロンプト側の直し方が「Prompting Claude Fable 5.1」に用意されています。1つ目は並列ツール呼び出しのばらつきです。Fable 5がまとめて呼んでいた場面で、Fable 5.1は1ターンに1回しか呼ばないことがあります。次に読むものが明示されずに暗黙になっている自作のコーディングエージェント、bashとエディタ中心のハーネス、コンピュータ操作で出やすく、答えの質は下がらないものの、トークンと往復と実時間が増えます。取ってくるものを複数明示した要求は、これまでどおり並列で走ります。

2つ目は、長いツール実行の合間に書かれる進捗更新が減ることです。特に高いeffortで、ユーザー向けのテキストを書く量が減ります。受け取り方のほうも見ておくと、進捗更新はそれぞれ独立したthinkingブロックとして返り、thinking.displayの既定は「omitted」なので、ブロックは返るけれどthinkingフィールドが空になります。長いエージェントターンが数分間まったく無言に見えるのはこのためです。ベータの「updates」を指定すると、推論は隠したまま進捗更新だけをテキストで受け取れます。「summarized」を選ぶと、要約された推論と混ざって返ります。生の思考内容はどの設定でも返りません。

3つ目は、低いeffortで検索や取得のツールを呼ばずに記憶から答える頻度が上がることです。ここまでの3つがエージェントの動きに関わる変化で、残りの4つは出力の質感です。場合によっては文章が以前より密になって一文が長く段落の切れ目が減る、チャットでの太字・見出し・箇条書きの使用が以前のClaudeモデルより減る、文書を要約するときに原文の一節を引用と示さずそのまま再現しやすくなる、テキストファイルを編集するときに小さな変更でもファイル全体を書き直しやすくなる、といった内容です。最後の1つは結果としてはたいてい同じでも、出力トークンと時間を余計に使います。

変わらないものも7つ並べて書かれています。①アダプティブ思考が常時オン、②thinking.displayの既定は「omitted」で生の思考内容は返らない、③ツール呼び出しの合間の推論はテキストではなくthinkingブロックで返り、interleaved thinkingはベータヘッダなしで自動、④プレフィルが400、⑤既定値以外のtemperature・top_p・top_kが400、⑥キャッシュ可能な最小プロンプト長が512トークン、⑦会話途中のsystemメッセージとツール変更が使えること。ここはFable 5からそのままです。

Fable 5.1とMythos 5.1が生成したテキストには、モデルが提供されているすべてのプラットフォームで、Anthropicの統計的テキスト透かしが入ります。公式ドキュメントの書き方は、当サイトで以前まとめた内容と一致しています。透かしは出力の意味・品質・読みやすさを変えず、トークンも隠し文字も追加せず、利用者や組織についての情報を含まず、リクエストにもレスポンスにも変更を必要としません。

テキスト以外もあります。コード実行ツールなどを通してClaudeが生成した画像・動画・音声のうち対応形式のものは、Claude APIのFiles API経由で取り出すと、署名付きのC2PA Content Credentialsが付いた状態で受け取れます。こちらはテキストの統計的透かしとは別の仕組みです。

透かしそのものの仕組みと、市販のAI検出ツールとの関係については、当サイトの別記事に分けてあります。この記事では、Fable 5.1の出力にも入っていて、そのために書くコードは何もない、というところまでにしておきます。

判断の順番は、公式の位置づけをそのまま使うのが素直です。まずOpus 5で、effortを上げて自分の評価を回す。それでも足りなかったときに、単価が倍になることを承知のうえでFable 5.1を明示的に選ぶ。Fable 5からの移行なら、公式が挙げている手順は5つです。モデルIDを差し替える、tool_choiceの「any」と「tool」を消してstrictかstructured outputsへ移す、履歴を追記だけにする、effortを既定のhighから測り直して会話の途中で変えることも検討する、そして評価をもう一度回す。

この記事で確認できなかったことも書いておきます。Task BudgetsのFable 5.1対応は、Claude Codeに同梱されている移行ガイドの中で「リリース時に確認」という留保が付いたままです。会話の途中でeffortを変えるベータについては、公開ドキュメントが対応環境をClaude APIと書いていて、Amazon BedrockやGoogle Cloudで使えるかどうかは書かれていません。ClaudeのアプリやClaude Codeのモデル選択にFable 5.1が出るかどうかも、公開ドキュメントには書かれていませんでした。

出典と時点について書いておきます。ここに載せた仕様は、2026年9月4日時点で公開されていたClaude Fable 5.1のモデルページと、そこからリンクされている新機能のページおよび移行ガイドの記述にもとづきます。補足として、Claude Codeに同梱されている公式のモデル移行ガイド(claude-apiスキル)も参照しました。同梱資料だけが出典になっている箇所は、本文でその旨を書いています。

最後に立場を書いておきます。私はこのモデルを長期間運用したわけではなく、この記事はベンチマークや実測にもとづく評価ではありません。公開されている仕様を、個人開発者が実際にAPIを触るときの順番へ並べ直したものです。数値はすべて公式の記述であって、私の計測ではありません。下書きにAIを使っていますが、公開したものの責任は運営者にあります。