Claude Fable 5.2 のプレフィックスチェック：前のターンでコードが何をしたかで決まる 400

Claude Fable 5.2 は 11 月 9 日にリリースされました。価格は 100 万トークンあたり入力 $8、出力 $40 です。Fable 5.1 の $10 と $50 からは下がりましたが、Opus 5.5 の基本料金の 2 倍のままです。切り替えで壊れるもののほとんどは、該当する変更に触れる最初のリクエストで失敗します。ひとつだけ、会話を編集したあとのリクエストでしか失敗しない変更があります。

それがプレフィックスチェックです。9 月に書いたとおり、400 は良い種類の破損です。最初の時点で拒否され、直し方がメッセージに書いてあります。今回も直し方はメッセージにありますが、新しい会話で 1 回だけ送るテストはすべて通ってしまいます。これはリクエストではなく、会話の性質だからです。

Claude Fable 5.2 のどの変更が最初のリクエストで失敗するか

3 つあります。古い computer_20251124 ツールを宣言すると、Amazon Bedrock 以外では 400 が返ります。代わりは computer_toolset_20260801 ツールセットで、独自のエージェントループを持ちます。Fable 5.2 の executor に付ける advisor ツールは、それ自体が Fable 5.2 か Mythos 5.2 でなければならず、その助言は暗号化されて返ってきます。ゼロデータ保持で Opus 5.5 を使っていた場合、Claude API ではすべてのリクエストが失敗します。Fable 5.2 は、Anthropic が例外を承認していない限り 30 日間の保持を必要とするからです。エラーとして文書化されていない損失もひとつあります。顧客管理の暗号鍵を使う組織では Fable 5.2 に structured outputs がありません。ドキュメントによれば、strict: true と output_config.format を外し、出力は自分で検証することになります。

Claude Fable 5.2 のプレフィックスチェックはいつ発動するか

コードが system プロンプト、tools、または以前のメッセージを変更し、そのあとで、変更箇所より後に生成された thinking ブロックを送り返したときです。各ブロックは、それが生成されたときのプレフィックスに対してだけ有効です。Opus 5.5 と Fable 5.1 がデフォルトでこのエラーを返すのは、2026 年 8 月 31 日以降に作られたアカウントだけでした。それより古いアカウントでは、合わないブロックがそのまま黙ってモデルに届いていました。Fable 5.2 はすべてのアカウントでエラーを返します。ドキュメントに載っているエラーは次のとおりです。

messages.5.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block".

同じ本文でリトライしても同じように失敗します。例外がひとつあり、Message Batches API では、この設定を指定していない項目には 400 が返りません。

Claude Code、Agent SDK、Managed Agents がリクエストを組み立てているなら、何も変わりません。自前で組み立てるコードでも、会話のあいだ system と tools を固定し、messages には追記だけを行い、アシスタントのターンを受け取ったとおりに送り返し、ドキュメントに挙がっているほかの編集を避けていれば安全です。effort、max_tokens、cache_control マーカーの変更は編集に当たりません。

編集に当たるのは、トークンを節約するために書かれがちなものです。毎ターン system に差し込むメモリと、クライアント側で古いターンを削ることです。ツールの出し入れも当たります。それぞれにサポートされた代替手段があります。指示やツールには会話途中の system メッセージ、削減にはサーバー側のコンパクションです。切り替えの時点で現れる、もっと目立たない編集が 2 つあります。ツール一覧をピン留めしていない MCP コネクタのサーバーで、その一覧がリクエスト間で変わると、Fable 5.2 のブロックにとっては編集になります（Opus 5.5 のブロックにとってはなりません）。また、組み合わせのルールで避けられない advisor の model の変更は tools の編集です。この変更は新しい会話で行ってください。

切り替え前に Claude Fable 5.2 のプレフィックスチェックをテストする方法

実際の会話を再生し、チェックを「失敗」ではなく「報告」に設定します。drop_block を指定すると、どのアカウントでもそのリクエストはチェックの対象になります。つまり、いま使っている Opus 5.5 に対して実行できます。

resp = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    system=system,
    tools=tools,
    messages=history,
    thinking={"type": "adaptive",
              "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
)
for t in getattr(resp, "input_transformations", None) or []:
    if t.reason == "prefix_binding_mismatch":
        log.error("invalidated thinking at %s", t.path)

prefix_binding_mismatch のエントリーは、コードが無効にしたブロックを 1 つずつ示します。編集はそのうち最も早いものより前のどこかにあります。エントリーがゼロであることに意味があるのは、コードがターンの合間に行う処理をまたいで、history が実際に thinking ブロックを運んでいた場合だけです。メモリの更新や削減が実際に動くまで、本物のループを十分に回してください。ピン留めしていない MCP コネクタを使っているなら、同じ実行を claude-fable-5-2 に対して繰り返します。Opus 5.5 では見えない唯一のケースです。

Opus 5.5 の記事で紹介した骨組みのような、新しい会話で動かす canary では、このチェックは試せません。編集できる前のターンが存在しないからです。あの記事では 2 ターン目に 1 文しか割いていませんでした。Fable 5.2 では、それがテストのすべてです。

本番では、つなぎとして drop_block が必要な場合を除き、デフォルトの error のままにしてください。ドキュメントは、破棄されたブロックによって出力トークンが増えることがあると注意しています。

Claude Fable 5.2 がエラーなしで変えるもの

主にコストです。Messages API では、Fable 5.2 のデフォルト effort は high で、Opus 5.5 のデフォルトは medium です。effort を一度も設定していないリクエストは、1 段高い effort で、しかも 2 倍の基本トークン単価で動きます。Fable 5.1 と違い、medium 以上ではプロンプトが「考えずにそのまま答えて」と指示しても thinking を続けます。そのため max_tokens が小さいと、テキストのない thinking ブロックだけで終わることがあります。Anthropic 自身のドキュメントは、ほとんどのワークロードは Opus 5.5 で始め、高い effort でも評価が足りないときにだけ上のモデルに移るよう勧めています。

会話を Fable 5.2 から Opus 5.5 や Fable 5.1 に移すルーターやフォールバックは、Fable 5.2 の thinking ブロックを、エラーにせず（200 のまま）破棄します。Sonnet 5.5 が導入したのと同じ紐付けです。

Claude Fable 5.2 のプレフィックスチェックは正しいルールか

ルール自体は正しく、痛いのは導入のしかただと考えています。別の履歴に対して再生された thinking ブロックは、起きていない会話についての推論です。それに 400 を返すのは誠実な対応です。ただ、アカウントの作成時期で区切ったため、古い自前の履歴処理コードを動かしている可能性が最も高い古いアカウントほど、知るのが最後になります。しかも知るのはモデルを切り替えたときです。

いずれにしても、この修正はしておきたいはずです。追記だけの履歴は、プロンプトキャッシュがターンごとに一致し続ける条件でもあります。