クロード・フェーブル 5.1: 「ブロックは別の会話にバインドされています」の解決

エージェントハーネスをClaude Fable 5.1に移行し、思考ブロックが「別の会話にバインドされている」というメッセージの400エラーが表示され始めた場合、それはコードがリクエスト間で会話履歴を編集しており、Fable 5.1がそれに異議を唱える最初のClaudeモデルだからです。このガイドでは、このチェックが何であるか、誰に適用されるか、何がトリガーとなるか、緊急回避策、そしてエラーを解消しつつプロンプトキャッシュをウォームに保つための追記専用パターンについて説明します。

このチェックは、思考の保持（preserved thinking）およびClaude Fable 5.1の新機能で文書化されています。これはFable 5.1の3つの破壊的変更の3番目であり、ハーネスをサイレントに劣化させる可能性がある唯一のものです。他の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". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

これは、いかなる出力の前に決定される400 invalid_request_errorです。同じボディで再試行しても、同様に失敗します。パス（messages.5.content.0）は、もはや一致しない最初の思考ブロックを指しており、メッセージの最後には変更された最初のメッセージを示す追加の文が表示されることがあり、それが求める診断結果です。トークンカウントエンドポイントも同じチェックを実行します。

異なる失敗も似ていますが、これとは異なります。「別の会話にバインドされている」という文がない同じ先行句は、シグネチャ自体が改ざんされているか復号不能であることを意味し、その場合prefix_mismatch_behaviorは適用されません。

チェックの内容

すべてのFable 5.1思考ブロックには、2つの情報を記録する署名が含まれています。それは、どのモデルがそれを生成したか、そしてその前にあった正確な会話プレフィックス（トップレベルのsystemプロンプト、tools配列、およびブロックより前のすべてのメッセージを意味します）です。各ブロックは前の思考ブロックにも連鎖しています。トランスクリプトを送信し直すと、APIはそのプレフィックスがブロックを生成したものとバイト単位で同一であることを検証します。

Anthropicは2つの理由を挙げています。明示されている理由はアンチ蒸留（anti-distillation）です。ローンチ投稿によると、新しいAPIアカウントでは、マルチターンの会話でClaudeの以前のコンテキストを手動で編集しながら、以前の思考のトランスクリプトを保持することができなくなり、これにより文書化された蒸留技術が閉じられます。実用的な理由は、チェックを破るのと同じ編集がプロンプトキャッシュも再起動するため、チェックをパスするコードは、すべてのターンで100万回あたり0.25ドルのキャッシュ読み取りを得るコードでもあるからです。

対象者

デフォルトで適用されるもの: 2026年8月31日以降に作成されたアカウント。これにはClaude API組織、Amazon Bedrockアカウント、Google Cloudプロジェクト、Microsoft Foundryリソースが含まれます。
記録されるが適用されないもの: それ以前に作成されたアカウント。APIは不一致を記録しますが、リクエストがthinking.block_binding.prefix_mismatch_behaviorを"error"を含む任意の値に設定した場合にのみそれに基づいて動作します。Anthropicは将来のモデルではすべてのアカウントにこれを適用すると述べています。
影響を受けないもの: Claude Code、claude.ai、Claude Managed Agents、およびClaude Agent SDK。これらはプレフィックスを自動的に保持します。Claude Mythos 5.1はまったくこのチェックを実行しませんが、履歴の編集は依然としてキャッシュを再起動します。
影響を受けるもの: messages配列自体を構築するすべてのコード。つまり、すべてのカスタムエージェントループ、すべてのチャットバックエンド、およびMessages APIをラップするすべてのフレームワークです。

ツール開発者への注意点：もしユーザーが自身のAPIキーで実行するものを出荷する場合、あなたのキーは古いアカウントにあり、ユーザーのキーはそうではない可能性があります。ユーザーがチェックに遭遇する前に、フィールドを設定してテストしてください。自身のアカウントが適用対象であるかどうかを確認するには、ベータヘッダーなしで履歴を編集するリクエストを送信してください。ヘッダー名を示す400エラーが発生した場合、それは適用対象であることを意味します。

後続のすべての思考ブロックを無効にするもの

以前のターンを編集、並べ替え、または削除すること。 これには、古いツール結果の削除、トランスクリプトの途中からのターンの削除、要約の後に最近のターンをそのまま保持するクライアント側での圧縮が含まれます。
永続化しないコンテンツを挿入すること。 ツール結果の後に追加され、次のリクエストで削除されるターンごとのリマインダー。ステータス行。ターンごとに変化する残りのトークン数。
リクエスト間でsystemまたはtoolsを再構築すること。 システムプロンプト内の現在の日付の更新。セッション中にツールを追加または削除すること。
後に異なるバイトを提供する画像またはドキュメントのURL。 バイトがバインドされ、URL文字列ではないため、同じファイルに対する回転する署名付きURLは問題ありません。
実行の開始以外の場所から思考ブロックを削除すること。 先頭のブロックは、最も古いものから削除できます。途中からのブロックは削除できません。

有効性を保つもの

追記専用の履歴。これには、追記されたrole: "system"メッセージや、クリアされて残っているターンごとのメッセージが含まれます。
思考ブロックの先頭の連続部分を、最も古いものから削除すること。
system、tools、messages以外の任意のパラメーターの変更：max_tokens、effortを含むoutput_config、tool_choice、metadata。
cache_controlマーカーの追加、移動、または削除。
サーバー側の圧縮およびコンテキスト編集。これには思考ブロックのクリアも含まれます。これらは、チェックが送信された会話を比較するため、編集とは見なされません（サーバーの編集済みコピーと比較しないため）。圧縮後、チェックされるプレフィックスは圧縮ブロックから開始されます。

緊急回避策：drop_block

thinking-binding-controls-2026-08-01ベータヘッダーを送信し、フィールドを明示的に設定します。

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={"type": "adaptive", "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
    messages=history,
)
for t in response.input_transformations or []:
    print(t.type, t.path, t.reason)

"drop_block"を使用すると、APIは最初の一致しないブロックとそれ以降のすべての思考ブロックを削除し、リクエストを続行し、各削除をトップレベルのinput_transformations配列で報告します。

"input_transformations": [
  {"type": "thinking_dropped", "path": "messages.1.content.0", "reason": "prefix_binding_mismatch"}
]

このフィールドについて知っておくべき3つのことがあります。それはそのリクエストのみに適用されるため、セッションの残りの間も送信し続ける必要があります。デフォルトは利用面によって異なります。ヘッダーがない場合、適用されるアカウントはエラーを発生させます。ヘッダーのみを送信すると、ベータ独自のデフォルトであるdrop_blockに切り替わります。したがって、明示的に設定し、どちらのデフォルトにも決して依存しないでください。そして、ヘッダーなしでblock_bindingを送信すると、block_binding: Extra inputs are not permittedで終わる400エラーが発生します。

reasonフィールドは2つのケースを区別します。prefix_binding_mismatchは、履歴が変更されたことを意味します。model_binding_mismatchは、会話がモデルを切り替えた（ルーター、再試行、拒否時のフォールバックなど）ために、ターゲットがFable 5.1ブロックを読み取れなかったことを意味します。後者はコードのバグではありません。ヘッダーを使用すると、すべてのレスポンスに配列が含まれ、何もドロップされなかった場合は空になります。

圧縮境界で一度ブロックをドロップしても、コストはほとんどかかりません。しかし、リクエストごとに自身の履歴を無効にするハーネスは、ターンごとにモデルの推論を失い、ターンごとにプロンプトキャッシュを再起動します。Anthropicは、これがタスクあたりのコストを上げると警告しています。drop_blockは診断ツールやセーフティネットとして扱い、定常状態とは見なさないでください。

ベータ版なしでの復旧

制御機能がないプラットフォーム（Microsoft Foundryはリリース時には提供していませんでしたが、BedrockとGoogle Cloudはモデルごとにそれらを追加していました）では、履歴からすべてのthinkingおよびredacted_thinkingブロックを削除し、各ターンのtextおよびtool_useブロックを保持して、一度再試行します。モデルは、それらのブロックが持っていた推論なしでそのターンに回答します。これは一度限りの復旧であり、パターンではありません。

3ステップ監査

トラフィックを切り替える前に実行し、後ではありません。

ハーネスが送信する正確なリクエストボディを捕捉します。製品に圧縮やツール変更がある場合は、それらを含む数回の通常のターンで捕捉します。連続するリクエストのペアごとに、systemプロンプト、tools配列、およびmessagesの共有プレフィックスを比較します。これらは新しく追加されたターンまでバイト単位で同一である必要があります。
ベータヘッダーとprefix_mismatch_behavior: "drop_block"を使用して、claude-fable-5-1に対して**通常のマルチターンセッションを実行**し、すべての応答でinput_transformationsをログに記録します。ターンごとに空の配列が表示される場合、履歴はそのままです。prefix_binding_mismatchエントリがある場合、pathのブロックの前の何かが変更されています。この設定は、フィールドを設定するとリクエストが強制適用されるようになるため、どのアカウントからでも機能します。CIでは、編集が実行を失敗させるように代わりに"error"を設定してください。
ヘッダーの下で**本番環境の設定を選択し、明示的に設定**します。不一致がバグのみを意味する場合は"error"、失敗する代わりに劣化する場合は"drop_block"です。いずれの場合も、400エラーまたはinput_transformationsエントリを監視してください。古いアカウントでフィールドを設定しないままにしないでください。そうすると、チェックはサーバー側で記録されるだけで、監視するものが何も得られません。

Apidogでは、ステップ2は2つのリクエストテストです。ターンを送信し、システムプロンプトを編集し、ヘッダーを設定して次のターンを送信し、input_transformationsでアサートします。これをコレクションに保持して、ハーネスの変更があるたびに再実行されるようにします。Apidogをダウンロードして構築してください。

ハーネスを追記専用にする

各行は、履歴編集を、プレフィックスをそのままに保ち、キャッシュをウォームに保つものに置き換えます。

あなたがしていたこと	代わりにこれを行う
セッション中にシステムプロンプトを編集（新しい日付、新しいモード）	セッション開始時に`system`を固定します。変更が有効になる時点で`{"role": "system", "content": "The current date is 2026-09-14."}`を追記します（会話途中のシステムメッセージ）。ベータヘッダーは不要です。これはシステムプロンプトの権限を持ち、後のブロックがバインドされるプレフィックスの一部となります。
セッション中に`tools`配列を編集	セッション開始時に完全なセットを宣言します（非表示で始まるツールには`defer_loading: true`）。`tool_addition`および`tool_removal`ブロックを`role: "system"`メッセージで送信します（ベータ`mid-conversation-tool-changes-2026-07-01`）。
ターンごとのリマインダーを挿入し、次のリクエストで削除	ツール結果メッセージの後に、ターンごとのシステムメッセージとして送信します：`{"role": "system", "clear_at": "next_user_message", "content": "..."}`（ベータ`mid-conversation-system-clear-at-2026-08-21`）。以前のコピーはすべてそのまま残します。クリアされたコピーは何もレンダリングせず、コストもかかりません。ベータ版なしの場合、リマインダーを同じユーザーメッセージ内の`tool_result`ブロックの後のテキストブロックに入れ、以前のコピーはそのまま保持します。
古いツール結果をクライアント側で削除	ツール結果クリアを伴うサーバー側のコンテキスト編集。
クライアントでの圧縮	サーバー側圧縮を優先します（ベータ`compact-2026-01-12`；その`instructions`パラメーターは独自の要約プロンプトを受け取ります）。クライアント側で行う場合、単純な圧縮を使用します：履歴全体を1つの要約メッセージと新しいユーザーターンに置き換え、それ以外は何も再生しません。
ターンをまたいで画像やドキュメントをURLで参照	Files APIに一度アップロードして`file_id`を送信するか、base64で送信します。

2つのクライアント側圧縮形式は、このチェックの下で機能せず、保持されたターンではdrop_blockまたは思考ブロックの削除が必要になります。Keep-tail圧縮（古いターンを要約し、最新のターンをそのまま保持する）は、保持されたターンで失敗します。なぜなら、その思考は完全な履歴に対して生成されたものだからです。Background圧縮（クリティカルパスとは別に要約を構築し、後で入れ替える）は、要約の開始から入れ替えまでの間に生成されたすべてのターンで失敗します。トランスクリプトの途中から個々のターンを削除すると、それ以降のすべてのブロックが無効になり、いかなるクライアント側形式でもこれを回避できません。行っていた指示変更には会話途中のシステムメッセージを使用するか、選択的な削除にはサーバー側のコンテキスト編集を使用してください。

もう一つのコストに関する考慮事項：キャッシュ読み取りが100万回あたり0.25ドルになったため、Fable 5.1では節約のために早期に圧縮することが必ずしも正しいトレードオフではなくなるかもしれません。Anthropicは、より遅い圧縮ポイントを試すことを推奨しています。

これがキャッシュの話でもある理由

上記の表にあるすべては、プロンプトキャッシュを再起動するもののリストでもあります。Fable 5.1では、キャッシュヒットがFable 5よりも4倍安価になり、ミスはそれに応じてより痛手となりました。そのため、追記専用のハーネスは二重の恩恵を受けます。思考が保持され、毎ターンプレフィックスを12.50ドルで書き換える代わりに0.25ドルで読み取ります。料金の内訳に具体的な数字があります。APIウォークスルーでは、ターンごとにスコープされるリクエスト形状とメッセージごとの努力に関するリクエスト形状が文脈の中で示され、プロンプトガイドでは、どのターンごとの指示がその方法で送信する価値があるかが説明されており、Claude Codeガイドでは、Claude Codeユーザーがこのエラーを目にすることがない理由が説明されています。

よくある質問

「ブロックが別の会話にバインドされている」とはどういう意味ですか？ Claude Fable 5.1の思考ブロックが、その前にあった何かが変更された後（システムプロンプト、ツール配列、または以前のメッセージ）に再利用されたことを意味します。APIは、適用対象のアカウントでこのリクエストを400エラーで拒否します。

Fable 5.1の履歴チェックはどのアカウントで適用されますか？ 2026年8月31日以降に作成されたすべてのアカウント（すべてのプラットフォーム）。それ以前のアカウントでは、リクエストでthinking.block_binding.prefix_mismatch_behaviorが設定された場合にのみ適用されます。Anthropicは、将来のモデルではすべてのアカウントにこれを適用する予定です。

エラーを素早く解消するにはどうすればよいですか？ thinking-binding-controls-2026-08-01ベータヘッダーをprefix_mismatch_behavior: "drop_block"と共に送信します。APIは影響を受けるブロックを削除し、処理を続行します。その後、履歴の編集を修正してください。なぜなら、毎ターンブロックをドロップすると推論が失われ、キャッシュが再起動するからです。

effortやmax_tokensを変更すると思考ブロックは無効になりますか？ いいえ。system、tools、messages以外のどのパラメーターも自由に E変更できます。cache_controlマーカーも同様です。

サーバー側の圧縮はチェックを破りますか？ いいえ。圧縮とコンテキスト編集はチェックの後に行われます。チェックはあなたが送信した会話を比較します。最近のターンをそのまま保持するクライアント側圧縮はこれを破ります。

Claude Mythos 5.1も同じチェックがありますか？ いいえ。Mythos 5.1は会話チェックを実行しませんが、思考ブロックを生成モデルにバインドし、履歴編集は依然としてそのキャッシュを再起動します。