Claude Fable 5.1（claude-fable-5-1）は米国時間2026年9月1日リリース。入力$10 / 出力$50（100万トークンあたり）はFable 5と同額のまま、キャッシュ読み取りだけが$0.25 / MTokへ下がりました。ただしMessages APIを自前で組んでいる実装は、モデルIDを差し替えるだけでは動きません。400を返す破壊的変更が3点あります。2026年9月時点でAnthropicの発表と公式ドキュメントで告知されている変更は、破壊的3点と追加5点。この記事はその8点を、公式の記述と実際のリクエストボディで一つずつ潰していく移行手順です。
結論：先に潰すのは「400を返す3点」だけ
Anthropicの移行ガイドは「移行はほぼドロップイン」と書いていますが、それはAPIサーフェス・上限・トークナイザ・常時オンのadaptive thinking・拒否処理が同じという意味です。壊れるのは次の3点で、いずれもリクエストが400で落ちるか、思考の連続性が黙って切れます。
| 破壊的変更 | 症状 | 対処 |
|---|---|---|
| forced tool useが非対応 | tool_choiceをany / toolにすると400 invalid_request_error |
auto＋明示指示＋strict: trueへ書き換え |
| thinkingブロックが生成モデル紐付き | 旧モデルへ切り戻すと推論が黙って落ちる | ルーター/フォールバックの向きを片方向に固定する |
| 過去ターン編集でthinkingが無効化 | 次リクエストが400 The block is bound to a different conversation |
会話履歴をappend-onlyにする |
追加された5点（メッセージ単位のeffort・ターン限定システムメッセージ・進捗更新の可読化・キャッシュ読み取り1/4・コンテンツ来歴）は、いずれも入れなくても動きます。移行当日は上の3点だけを潰し、追加5点は次のスプリントで拾うのが安全です。
破壊的変更①：forced tool use（tool_choice: any / tool）が400になる
Fable 5ではauto / none / any / tool の4つが使えました。Fable 5.1では後ろ2つが落ちます。返るエラーメッセージは公式ドキュメントに明記されています。
tool_choice: type "tool" and "any" are not supported for this model.この検証はMessages APIだけでなく、Message Batches APIとトークンカウントのエンドポイントでも同じように走ります。バッチ側だけ古い書き方が残っていて夜間ジョブで落ちる、という壊れ方が起きやすいので、リポジトリ全体をtool_choiceで検索してください。
理由も公式に説明されています。これらのモデルは思考が常時オンで、ツール呼び出しを強制すると思考を飛ばしてしまう。結果としてモデルは考えた内容をツール引数に書き込むことになり、引数の質が落ちる。だから塞いだ、という設計判断です。
移行前（Fable 5）
curl -sS https://api.anthropic.com/v1/messages
-H "content-type: application/json"
-H "x-api-key: $ANTHROPIC_API_KEY"
-H "anthropic-version: 2023-06-01"
-d '{
"model": "claude-fable-5",
"max_tokens": 16000,
"tools": [{
"name": "record_summary",
"description": "Record the structured summary of the document.",
"input_schema": {
"type": "object",
"properties": {"summary": {"type": "string"}},
"required": ["summary"]
}
}],
"tool_choice": {"type": "tool", "name": "record_summary"},
"messages": [{"role": "user", "content": "Summarize: The meeting moved to Thursday."}]
}'移行後（Fable 5.1）
公式が示す置き換えは3点セットです。tool_choiceはautoのまま、ツール名をユーザー指示の中で名指しし、ツール側にstrict: trueとadditionalProperties: falseを付けてスキーマ適合を担保します。
client = anthropic.Anthropic()
record_summary_tool = {
"name": "record_summary",
"description": "Record the structured summary of the document.",
"strict": True,
"input_schema": {
"type": "object",
"properties": {"summary": {"type": "string"}},
"required": ["summary"],
"additionalProperties": False,
},
}
response = client.messages.create(
model="claude-fable-5-1",
max_tokens=16000,
tools=[record_summary_tool],
tool_choice={"type": "auto"},
messages=[{
"role": "user",
"content": "Summarize: The meeting moved to Thursday. Call the record_summary tool with your result.",
}],
)注意点が2つあります。ひとつはCMEK組織で、Fableモデルではstrict: trueを含む構造化出力が使えないため、指示文だけに頼ることになります。もうひとつは「そのターンで必ずツールを呼ばせたい」ケースで、この場合は指示をユーザーターンではなく会話途中のシステムメッセージに載せるのが公式の推奨です。tool_choiceの設計パターンを強制前提で組んでいた場合は、この機会に指示ベースへ寄せてください。スキーマ適合そのものを厳密にしたいならStructured Outputsへ逃がす手もあります。
破壊的変更②：thinkingブロックは生成したモデルに紐づく
すべてのthinkingブロックは、どのモデルが生成したかを記録するようになりました。そして保持は一方向です。Fable 5.1はOpus 5・Fable 5・Mythos 5・それ以前のモデルのthinkingブロックを読めますが、その逆はできません。
実務で効くのは、モデルを跨いで切り替えるルーターやフォールバックです。会話をFable 5.1へ寄せる方向なら推論は引き継がれます。Fable 5.1から旧モデルへ戻す方向では、そこで走ったターンの推論が失われます。しかも読めないブロックはAPI側がモデルに渡す前に落とすので、デフォルトでは何も知らせずに消えます。落ちたブロックはinput_tokensにも計上されず課金もされません。
この「黙って消える」を可視化するには、thinkingの公式ドキュメントにあるthinking-binding-controls-2026-08-01ベータヘッダを付けます。トップレベルのinput_transformations配列にドロップが報告され、モデル切替が原因ならreason: "model_binding_mismatch"が入ります。これはコードのバグではなく想定内の値なので、ログ上で後述のprefix_binding_mismatchと区別できるようにしておくと運用が楽になります。
拒否時の自動リトライを使っている場合も同じ話です。拒否とフォールバックのfallbacks: "default"（ベータヘッダserver-side-fallback-2026-07-01）でFable 5.1が許容するフォールバック先はClaude Opus 4.8とClaude Opus 5の2つですが、フォールバック先のモデルはFable 5.1のthinkingブロックを受け取りません。モデル非依存のフォールバック構成を組んでいるなら、切り戻し方向のときだけ推論が消える前提で状態を持たせる必要があります。
破壊的変更③：過去ターンを編集するとthinkingが無効化される
3点目がいちばん静かに刺さります。Fable 5.1のthinkingブロックより前にあるもの（systemプロンプト、tools配列、それ以前のメッセージ）を変更すると、次のリクエストがエラーになります。返る400のメッセージはこうです。
The block is bound to a different conversationClaude Code、claude.ai、Claude Managed Agents、Claude Agent SDKを使っている場合は、これらが前方部分を保ってくれるので気にしなくて構いません。問題になるのはmessages配列を自前で組み立てているコードです。公式は「新規アカウント（2026年8月31日以降に作成）ではこの検証が有効。それ以前のアカウントでは不一致を記録するだけで、リクエストがthinking.block_binding.prefix_mismatch_behaviorを指定したときにだけ作動する」と書いています。つまり既存アカウントで動いているからといって安全とは限らず、自分のツールを他人のAPIキーで動かしてもらう場合は先に壊れます。
無効化するパターンと、その代わりにやること
| 無効化するパターン | 代わりにやること |
|---|---|
| 過去ターンの編集・並べ替え・削除（古いtool_resultの削除、途中のターンの切り抜きを含む） | サーバー側のcompactionまたはcontext editingへ移す |
| 毎リクエスト注入して次で消すリマインダー（ステータス行など） | ターン限定システムメッセージとして送り、履歴に残したままにする |
同一会話中にsystemプロンプトやtools配列を組み直す（日付更新やツール追加） |
会話途中のシステムメッセージ、tool_addition / tool_removalブロックを追加する |
| 後のリクエストで異なるバイト列を返す画像・ドキュメントURL | Files APIで一度アップロードしfile_idで参照する（署名URLの回転自体は問題なし） |
逆に、後続ブロックを無効化しないものも明示されています。append-onlyの履歴、thinkingブロックを古い方から先頭側だけ削ること、effortやmax_tokensなどsystem / tools / messagesの外側のパラメータ変更、cache_controlマーカーの移動、サーバー側のcompactionとcontext editing。検証は「送信したままの会話」を比較するので、サーバー側で消えたものは編集として数えません。
自分の実装が壊れるかを確かめる3ステップ
公式移行ガイドの検査手順はそのまま実行できます。移行前にこれを回してください。
- 通常のターンを数回流し、送信したリクエストボディをそのまま記録する。連続する2つのリクエストで
system・tools・messagesの共通前方部分がバイト単位で一致していれば履歴は無傷です。compactionやツール変更がある製品なら、その回も必ず含めます。 thinking-binding-controls-2026-08-01ベータヘッダとprefix_mismatch_behavior: "drop_block"を付けてマルチターンのセッションを流し、毎レスポンスのinput_transformationsをログに出す。全ターンで空配列なら合格。reason: "prefix_binding_mismatch"が出たら、そのpathより前が前回リクエストから変わっています。このフィールドを指定した時点で検証が有効になるので、どのアカウントからでもテストできます。- 本番の設定値を決める。前方不一致がコードのバグ以外にありえないなら既定の
"error"のまま、落として続行したいなら"drop_block"。CIでは"error"にして、編集が入ったらビルドを落とすのが公式の推奨です。
response = client.beta.messages.create(
model="claude-fable-5-1",
max_tokens=16000,
thinking={
"type": "adaptive",
"block_binding": {"prefix_mismatch_behavior": "drop_block"},
},
messages=messages,
betas=["thinking-binding-controls-2026-08-01"],
)
print("input_transformations:", len(response.input_transformations or []))クライアント側で履歴を要約している場合は、compactionの形を3つのどれかに寄せます。単純圧縮（履歴全体を要約1件と新しいユーザーターンに置き換え、他は再送しない）が公式の推奨で、thinkingブロックを引き継がないので何も壊れません。末尾保持型（直近ターンをそのまま残す）なら、残すターンからthinkingとredacted_thinkingブロックを剥がすかdrop_blockを指定します。バックグラウンド圧縮（要約を後から差し替える）なら、差し替え前に生成されたthinkingを含むリクエストすべてでdrop_blockを送るか、同期的に圧縮します。なお、transcriptの途中からターンだけを切り抜く操作は、どのクライアント側の形でも回避できません。
1回だけドロップする分にはほぼ影響ありません。問題は毎リクエスト無効化してしまう実装で、その場合プロンプトキャッシュが都度リスタートし、タスクあたりのコストが上がります。プロンプトキャッシュの実装を詰めているチームほど、ここの取りこぼしは金額に直結します。
追加された5点は、どこで使うと効くか
メッセージ単位のeffort（ベータ）。 Fable 5ではoutput_config.effortがリクエスト単位で、リクエスト間で変えると前のターンのキャッシュ済み前方部分が落ちていました。Fable 5.1ではoutput_configだけを持つrole: "system"メッセージを差し込むことで、キャッシュを壊さずに難所だけeffortを上げられます。ベータヘッダはmid-conversation-output-config-2026-07-01。effortパラメータが受け付けるのはlow / medium / high / xhigh / maxの5段階で、指定は次のユーザーターンから効きます。
response = client.beta.messages.create(
model="claude-fable-5-1",
max_tokens=4096,
output_config={"effort": "high"},
messages=[
{"role": "user", "content": "Plan a migration from SQLite to PostgreSQL in three short steps."},
{"role": "assistant", "content": "1. Export the SQLite data. 2. Create the PostgreSQL schema. 3. Import the data and verify row counts."},
# effortのみのシステムメッセージ。次のユーザーターンから低いeffortに切り替わる
{"role": "system", "content": [], "output_config": {"effort": "low"}},
{"role": "user", "content": "Summarize the plan in one sentence."},
],
betas=["mid-conversation-output-config-2026-07-01"],
)ターン限定システムメッセージ（ベータ）。 会話途中のシステムメッセージのうち、role: "system"のメッセージにclear_at: "next_user_message"を付けると、そのターンだけシステムプロンプト相当の重みを持ち、次のユーザーメッセージ以降は描画されなくなります。メッセージ自体はmessagesに残したまま毎回そのまま送り返すので、履歴は変わらずキャッシュも一致し、消えた後は入力トークンを消費しません。ベータヘッダはmid-conversation-system-clear-at-2026-08-21。破壊的変更③で挙げた「注入して次で消すリマインダー」の正式な置き換え先がこれです。
{
"role": "system",
"clear_at": "next_user_message",
"content": "Results have landed in your inbox. Check it before running more code."
}ツール呼び出しの間の進捗更新（ベータ）。 Fable 5.1もツール呼び出しの合間に短い進捗テキストを書きますが、Fable 5より数が減りました。しかも進捗は独立したthinkingブロックとして返り、既定のthinking.displayは"omitted"なので中身が空です。長いエージェントターンがユーザーには無言に見える、という体験の劣化はここから来ます。thinking-display-updates-2026-08-18ベータヘッダでdisplay: "updates"を指定すると、推論は隠したまま進捗更新だけをテキストで受け取れます。テキストが空でないthinkingブロックがそのままステータス行になる、という読み方です。
キャッシュ読み取りの値下げ。 プロンプトキャッシュの読み取り（ヒットとリフレッシュ）は基本入力価格の0.025倍で、他のClaudeモデルの0.1倍と比べて1/4です。Anthropicの発表では一般的なワークロードで約25%、コンテキストとツールが重い高度にエージェント的なワークロードでは最大約45%のコスト削減としています。キャッシュ書き込みと512トークンの最小キャッシュ長は据え置きです。
| 項目 | Claude Fable 5.1 |
|---|---|
| 入力 | $10 / MTok |
| 出力 | $50 / MTok |
| 5分キャッシュ書き込み | $12.50 / MTok |
| 1時間キャッシュ書き込み | $20 / MTok |
| キャッシュ読み取り | $0.25 / MTok |
| Batch API | 入力$5 / 出力$25 / MTok（50%割引） |
出典：Claude Fable 5.1モデル概要およびClaude Pricing（いずれも2026年9月時点）
コンテンツ来歴。 Fable 5.1が生成したテキストには、提供されている全プラットフォームでAnthropicの統計的テキスト透かしが入ります。コード実行ツール経由などで生成した画像・動画ファイルは、Claude APIのFiles API経由で取得すると署名済みのC2PA Content Credentialsを持ちます。公式は「出力の意味・品質・可読性は変わらず、トークンも隠し文字も増えず、利用者や組織の情報は含まれない」と明記しています。リクエスト・レスポンス側の変更は不要です。
モデルIDとプラットフォーム別の移行
IDの形が違うのはAmazon Bedrockだけです。Bedrock向けクライアントを共通ラッパーで抽象化している場合、ここのプレフィックス付与を忘れると本番だけ落ちます。
| プラットフォーム | モデルID |
|---|---|
| Claude API | claude-fable-5-1 |
| Amazon Bedrock | anthropic.claude-fable-5-1 |
| Google Cloud | claude-fable-5-1 |
| Microsoft Foundry | claude-fable-5-1 |
| Claude Platform on AWS | claude-fable-5-1 |
コードの外側にも確認事項が3つあります。ひとつはデータ保持で、Fable 5.1とMythos 5.1は30日保持が必須、明示的な許可がない限りゼロデータ保持（ZDR）では使えず、Covered Modelに指定されています。Claude APIでは30日保持がない組織・ワークスペースからのリクエストは400 invalid_request_errorになります。ふたつめはPriority Tierで、Fable 5は対応していますがFable 5.1とMythos 5.1は非対応です。3つめはリタイア時期で、公式には「2027年9月1日より前にはしない」とだけ告知されています。無日付モデルIDのピン留めで運用している場合は、この保持要件とTier要件も合わせて棚卸ししてください。
なお移行作業そのものは、Claude Codeに同梱されたClaude API skillに任せる手もあります。/claude-api migrate this project to claude-fable-5-1と打つと、モデルIDの置換と破壊的パラメータの修正をコードベース全体に当て、手動確認が必要な項目のチェックリストを出します。編集前に対象範囲（作業ディレクトリ全体／サブディレクトリ／ファイル指定）を確認してくるので、いきなり全面書き換えにはなりません。
コードを変えなくても変わる挙動
API仕様ではないが移行後に体感が変わる、と公式が挙げている差分のうち、実装に効くのは3つです。
長いエージェントループで並列ツール呼び出しが減る。 Fable 5が複数まとめて投げていた場面で、Fable 5.1は1ターン1呼び出しになることがあります。出るのは、次に読むべき独立した対象がタスクから暗黙にしか示されないループ（自作コーディングエージェント、bashとエディタのハーネス、コンピュータ使用）です。回答の質は落ちませんが、余分なターンの分だけトークン・往復・実時間を食います。公式の対処は、各ユーザーメッセージの後ろに1文のバッチ指示をターン限定システムメッセージとして足すこと。ベータを使わない場合はtool_resultブロックの後ろのテキストブロックに置き、後続リクエストでも履歴に残したままにします。
進捗メッセージが減る。 特にeffortが高いほどユーザー向けテキストが減ります。thinking.displayを"updates"か"summarized"にしたうえで、「最初に一言、途中で定期的に、最後に要約」と明示的に頼む形に切り替えます。旧モデル向けに書いた「発見は最終応答までまとめて出すな」系のプロンプト行は、逆効果になるので外してください。
low effortで検索・取得ツールを呼ぶ回数が減る。 最も低いeffortでは記憶から答える頻度が上がります。最新情報が要るターンだけeffortを上げるか、いつ検索すべきかを明示します。会話途中でeffortを上げられるようになったのは、まさにこの用途です。
移行チェックリスト
Fable 5からの移行で最低限やることは次のとおりです。
- モデル名を
claude-fable-5からclaude-fable-5-1へ更新する。 - 強制
tool_choice（any/tool）を全廃し、auto＋明示指示＋strict: true、または構造化出力へ置き換える。 - thinkingブロックは空のものも含めて毎ターンそのまま返す。
messagesを自前で組んでいるなら、前述の3ステップ検査を回してprefix_binding_mismatchをゼロにする。- 本番の
prefix_mismatch_behavior（既定は"error"、または"drop_block"）を決めて監視する。 - エージェントループの1ターン1呼び出しを確認し、バッチ指示を足す。
- 進捗テキストを描画しているなら
displayを"updates"か"summarized"にする。 stop_reason: "refusal"を処理し、stop_details.categoryを読む。- effortを既定の
highから改めてスイープし直し、自分のワークロードでコストとレイテンシを取り直す。
Opus 5から移る場合は、上に加えて4点が増えます。thinking: {"type": "disabled"}はどのeffortでも400になるので削除し（トークン量はeffortを下げて制御し、max_tokensを見直す）、ツール呼び出しの間のテキストがtextブロックではなく進捗更新のthinkingブロックで返るようになるため描画側を直し、価格が$5 / $25から$10 / $50へ上がる前提で試算をやり直し、ZDR運用ならそもそも利用可否を先に確認します。Opus 5前提で組んだモデル振り分けをそのまま持ち込むと、この4点で足を取られます。
よくある質問
Claude Fable 5.1の料金はいくらですか？
入力$10 / 出力$50（100万トークンあたり）で、Fable 5と同額です。変わったのはキャッシュ読み取りで$0.25 / MTok。Anthropicは一般的なワークロードで約25%、高度にエージェント的なワークロードで最大約45%のコスト削減としています。
forced tool useの代わりに何を使えばいいですか？
tool_choice: {"type": "auto"}のまま、ユーザーターンか会話途中のシステムメッセージでツール名を名指しし、ツールにstrict: trueを付けます。スキーマ適合を厳密にしたい場合は構造化出力へ移します。公式は「Fable 5.1は明示的なツール指示に確実に従う」としています。
移行しないと既存コードは動かなくなりますか？
Fable 5を呼び続けている限り、そのコードは影響を受けません。壊れるのはモデルIDをFable 5.1に差し替えた瞬間です。逆に言えば、上の3点を潰す前にIDだけ先に差し替えるのがいちばん危険な進め方です。
thinkingを無効化して安く回すことはできますか？
できません。adaptive thinkingは常時オンで、thinking: {"type": "disabled"}もbudget_tokens付きの手動extended thinkingも400を返します。thinkingフィールドを省略するか{"type": "adaptive"}を送り、コストはeffortで制御します。
Claude CodeやClaude Agent SDKを使っていても対応は必要ですか？
履歴編集の検査については不要です。Claude Code、claude.ai、Claude Managed Agents、Claude Agent SDKは前方部分を保つように作られています。messages配列を自前で組んでいる実装だけが対象です。
移行そのものより、エージェントの設計とコスト設計のほうで詰まっているなら。
UravationではAIエージェント導入の研修・コンサルティングを行っています。
関連（2026年9月）: 移行が終わったら、次はβ新機能3種（effort変更・ターン限定system・進捗テキスト）の実装です。 「Claude Fable 5.1新機能β3種の実装ガイド【2026年9月】」で公式βヘッダー名とコード例つきで解説しています。
