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

エージェントハーネスをClaude Fable 5.1に移行した後、思考ブロックが「別の会話にバインドされている」という400エラーを返すようになった場合、リクエスト間で会話履歴を編集している可能性があります。Fable 5.1は、この問題を検出して拒否する最初のClaudeモデルです。本稿では、チェックの仕組み、対象アカウント、発生条件、緊急回避策、そしてプロンプトキャッシュを維持する追記専用パターンを解説します。

今すぐApidogを試す

このチェックは、思考の保持（preserved thinking）およびClaude Fable 5.1の新機能で説明されています。Fable 5.1における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の思考ブロックには、次の情報を記録する署名が含まれます。

• どのモデルがブロックを生成したか
• その前に存在した正確な会話プレフィックス

プレフィックスには、トップレベルのsystemプロンプト、tools配列、ブロックより前にあるすべてのメッセージが含まれます。また、各思考ブロックは直前の思考ブロックにも連鎖しています。

履歴を再送すると、APIはプレフィックスが思考ブロック生成時の内容とバイト単位で一致するか検証します。

Anthropicが挙げる主な理由はアンチ蒸留（anti-distillation）です。ローンチ投稿によると、新しいAPIアカウントでは、マルチターン会話中にClaudeの過去コンテキストを手動編集しながら、以前の思考トランスクリプトを保持することができなくなります。

実装上の利点もあります。チェックを破る履歴編集は、通常プロンプトキャッシュも再起動します。つまり、チェックを通過する追記専用ハーネスは、思考を保持しながら、毎ターンのキャッシュ読み取りを100万トークンあたり0.25ドルで利用できます。

対象となるアカウントと実装

デフォルトで適用されるアカウント

2026年8月31日以降に作成された、次のアカウントが対象です。

• Claude API組織
• Amazon Bedrockアカウント
• Google Cloudプロジェクト
• Microsoft Foundryリソース

記録されるが、デフォルトでは適用されないアカウント

それ以前に作成されたアカウントでは、不一致が記録されます。ただし、リクエストで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キーで動作するツールを提供している場合は注意してください。ツール提供者のキーが古いアカウントでも、ユーザーのキーは適用対象である可能性があります。ユーザーがエラーに遭遇する前に、設定を有効にしてテストしましょう。

自分のアカウントが適用対象か確認するには、ベータヘッダーなしで履歴を編集したリクエストを送信します。エラーにthinking-binding-controls-2026-08-01のヘッダー名が表示されれば、そのアカウントは適用対象です。

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

次の操作は、以降の思考ブロックを無効にします。

• 過去のターンを編集、並べ替え、削除する
  • 古いツール結果の削除
  • トランスクリプト途中からのターン削除
  • 最新ターンを保持したまま行うクライアント側圧縮
• 永続化されないコンテンツを挿入する
  • 次のリクエストで削除するターンごとのリマインダー
  • ステータス行
  • ターンごとに変化する残りトークン数
• リクエスト間でsystemまたはtoolsを再構築する
  • システムプロンプトの日付を更新する
  • セッション途中でツールを追加・削除する
• 後続リクエストで異なるバイトになる画像やドキュメントのURLを使用する
• 実行開始時以外の場所から思考ブロックを削除する

先頭にある思考ブロックは、最も古いものから連続して削除できます。途中のブロックだけを削除することはできません。

チェックを壊さない操作

次の操作はプレフィックスを変更しません。

• 追記専用の履歴
• role: "system"メッセージの追記
• clear_atでクリアされるターンごとのメッセージを残す
• 先頭の思考ブロックを最も古いものから連続して削除する
• system、tools、messages以外のパラメーターを変更する
  • max_tokens
  • output_config内のeffort
  • tool_choice
  • metadata
• cache_controlマーカーを追加、移動、削除する
• サーバー側の圧縮やコンテキスト編集を利用する

サーバー側の圧縮やコンテキスト編集は、送信した会話とサーバー側の編集後コピーを比較するものではありません。そのため、このチェックでは履歴編集として扱われません。圧縮後は、圧縮ブロックからチェックが開始されます。

緊急回避策：drop_block

まず、thinking-binding-controls-2026-08-01ベータヘッダーを送信し、prefix_mismatch_behaviorを明示的に"drop_block"に設定します。

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"
  }
]

設定時の注意点

1. 設定はそのリクエストにのみ適用されます。セッションの残りでも毎回送信してください。
2. ヘッダーなしでは、適用対象アカウントはエラーになります。
3. ヘッダーだけを送ると、ベータ版のデフォルトであるdrop_blockに切り替わります。

デフォルトに依存せず、必ず値を明示してください。逆に、ヘッダーなしでblock_bindingを送ると、次の400エラーになります。

block_binding: Extra inputs are not permitted

reasonの読み方

• prefix_binding_mismatch：履歴が変更された
• model_binding_mismatch：ルーター、再試行、拒否時のフォールバックなどでモデルが切り替わり、ターゲットモデルがFable 5.1の思考ブロックを読み取れなかった

後者は必ずしもコードのバグではありません。

ベータヘッダーを使用すると、すべてのレスポンスにinput_transformationsが含まれます。何も削除されなかった場合は空配列です。

圧縮境界で一度だけブロックを削除するなら、コストへの影響は小さいでしょう。しかし、リクエストごとに履歴を無効化するハーネスでは、毎ターン推論が失われ、プロンプトキャッシュも再起動されます。drop_blockは診断または安全策として使い、定常運用にはしないでください。

ベータ版なしで復旧する方法

制御機能を利用できないプラットフォームでは、次の手順で一度だけ復旧します。

1. 履歴からthinkingとredacted_thinkingブロックをすべて削除する
2. 各ターンのtextとtool_useブロックは保持する
3. リクエストを再送する

この場合、モデルは過去の思考ブロックに含まれていた推論なしで応答します。Microsoft Foundryではリリース時点で制御機能が提供されていませんでした。一方、BedrockとGoogle Cloudではモデルごとに追加されています。

本番切り替え前の3ステップ監査

1. 実際のリクエストボディを取得する

ハーネスが送信する正確なリクエストボディを記録します。圧縮やツール変更を実装している場合は、それらを含む通常のターンを複数回取得してください。

連続するリクエストの各ペアで、次を比較します。

• systemプロンプト
• tools配列
• messagesの共有プレフィックス

新しく追加されたターンより前の内容は、バイト単位で同一でなければなりません。

2. input_transformationsを監視する

ベータヘッダーとprefix_mismatch_behavior: "drop_block"を指定し、claude-fable-5-1で通常のマルチターンセッションを実行します。

各レスポンスでinput_transformationsをログに記録してください。

• 空配列：履歴は変更されていない
• prefix_binding_mismatch：指定されたパスより前の何かが変更されている
• model_binding_mismatch：セッション中にモデルが切り替わった

CIでは、劣化させる代わりに"error"を指定すると、履歴編集で実行を失敗させられます。この設定を使えば、古いアカウントでも監査できます。

3. 本番設定を明示する

ベータヘッダーの下で、本番運用に適した値を選択します。

• 不一致をバグとして扱う："error"
• 失敗させずに劣化させる："drop_block"

いずれの場合も、400エラーまたはinput_transformationsエントリを監視します。古いアカウントでフィールドを未設定のままにすると、サーバー側では不一致が記録されても、アプリケーション側で監視できません。

Apidogでは、ステップ2を2つのリクエストテストとして実装できます。

1. 最初のターンを送信する
2. システムプロンプトを編集する
3. ヘッダーを設定して次のターンを送信する
4. 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
古いツール結果をクライアント側で削除する	ツール結果クリアを伴うサーバー側コンテキスト編集を使う。
クライアント側で圧縮する	サーバー側圧縮を優先する。ベータ：compact-2026-01-12。クライアント側で圧縮する場合は、履歴全体を1つの要約メッセージと新しいユーザーターンに置き換え、ほかのターンを再生しない。
ターンをまたいで画像やドキュメントをURL参照する	Files APIに一度アップロードしてfile_idを送るか、base64で送信する。

ベータ版を使わない場合、ターンごとのリマインダーは同じユーザーメッセージ内で、tool_resultブロックの後にテキストブロックとして追加します。過去のコピーは削除せず保持してください。クリアされたコピーはレンダリングされず、コストも発生しません。

避けるべきクライアント側圧縮

次の2つは、保持されたターンの思考ブロックを無効にします。

• Keep-tail圧縮：古いターンを要約し、最新ターンをそのまま保持する方式。保持された思考は完全な履歴に対して生成されているため失敗します。
• Background圧縮：クリティカルパスの外で要約を作り、後から履歴を置き換える方式。要約開始から置き換えまでに生成されたターンが失敗します。

トランスクリプト途中のターンを削除すると、それ以降のブロックがすべて無効になります。指示を変更する場合は会話途中のシステムメッセージを、選択的な削除にはサーバー側コンテキスト編集を使ってください。

また、Fable 5.1ではキャッシュ読み取りが100万トークンあたり0.25ドルになりました。コスト削減のために早い段階で圧縮することが、必ずしも最適とは限りません。より遅い圧縮ポイントも検討してください。

なぜキャッシュの問題でもあるのか

上記の履歴編集操作は、プロンプトキャッシュを再起動する操作でもあります。

Fable 5.1では、キャッシュヒットがFable 5より4倍安価になり、キャッシュミスの影響は相対的に大きくなりました。追記専用ハーネスには、次の2つのメリットがあります。

• 過去の思考ブロックを保持できる
• 毎ターンプレフィックスを書き換える代わりに、100万トークンあたり0.25ドルでキャッシュを読み取れる

具体的な数値は料金の内訳を参照してください。APIウォークスルーでは、ターン単位のリクエスト形状と、メッセージごとのeffort設定を解説しています。プロンプトガイドでは、ターン単位の指示をこの方法で送るべきケースを説明しています。Claude Codeガイドでは、Claude Codeユーザーがこのエラーを目にしない理由を解説しています。

よくある質問

「ブロックが別の会話にバインドされている」とは？

Claude Fable 5.1の思考ブロックを、その前にあるシステムプロンプト、ツール配列、またはメッセージを変更した後に再利用したことを意味します。適用対象アカウントでは、APIが400エラーでリクエストを拒否します。

どのアカウントで履歴チェックが適用されますか？

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以外のパラメーターは変更できます。cache_controlマーカーの変更も問題ありません。

サーバー側の圧縮はチェックを壊しますか？

いいえ。チェックは送信した会話を比較し、その後にサーバー側の圧縮やコンテキスト編集が実行されます。ただし、最新ターンをそのまま保持するクライアント側圧縮はチェックを壊します。

Claude Mythos 5.1にも同じチェックがありますか？

いいえ。Mythos 5.1は会話チェックを実行しません。ただし、思考ブロックは生成モデルにバインドされるため、履歴編集を行うとプロンプトキャッシュは再起動されます。