保持された思考

Claude Fable 5.1 では、会話内の以前のターン（system プロンプト、tools、またはそれ以前のメッセージ）を変更すると、API のレスポンスに影響します。デフォルトでは、API はリクエストをエラーで拒否します。ただし、代わりに影響を受ける思考ブロックをモデルが見る内容から削除するよう選択した場合（prefix_mismatch_behavior: "drop_block"）は除きます。このチェックは、2026年8月31日 00:00 UTC 以降に作成された新規アカウントに対してデフォルトで適用されます。詳細は 仕組み および 影響を受ける対象 を参照してください。

ブロックを送り返すと、API はその signature を使用して、以前の会話が変更されていないこと、および現在のモデルがそのブロックを読み取れることを確認します。このチェックは、ある指示セットのもとで生成された推論が、別の（潜在的に敵対的な）指示セットのもとで再生されないようにするために存在します。

API は、会話の進行に合わせて会話を変更するためのファーストクラスの代替手段を提供しており、トランスクリプト編集のほとんどのユースケースをカバーしています。新しい指示には会話途中のシステムメッセージ、ターンごとのリマインダーにはターンスコープのシステムメッセージ、ツールの追加と削除には会話途中のツール変更、ターンごとの思考の深さの調整にはメッセージごとの effort があります。このページの残りの部分では、お使いのインテグレーションが影響を受けるかどうかを判断する方法と、一般的なハーネスパターンをこれらの機能に移行する方法について説明します。追加の利点として、各思考ブロックより前のすべてをバイト単位で変更せずに保つことで、「prompt caching」（プロンプトキャッシング）のためのプレフィックスも安定した状態に保たれます。詳しくはプロンプトキャッシングを参照してください。

何か対応が必要かどうかは、会話履歴を何が管理しているかによって異なります。

• 公式の Claude 製品または SDK を使用している場合: Claude Code、claude.ai、Claude Managed Agents、または Claude Agent SDK。これらはプレフィックスをそのまま維持してくれます。
• Messages API を直接呼び出している場合（独自のエージェントループやその他の環境から）。コードを確認し、messages 配列が追記専用として扱われていることを確認してください。以下の一般的なパターンはプレフィックスを編集し、編集箇所以降の思考を無効にします。
  • 古いターンのトリミングまたは削除
  • クライアント側で古いターンを要約し、最近のターンを保持する
  • 以前のターンにリマインダーを挿入し、次のリクエストで削除する
  • リクエストごとに system プロンプトを再構築する（現在時刻、トークン予算、モードフラグ）
  • セッション途中で tools のエントリを追加または削除する

仕組み

新しいリクエストに対して、API は以下をチェックします。

• モデルが同じか、より新しいこと。 ブロックは、それを生成したモデルおよびそれ以降のモデルによって読み取り可能であり、それ以前のモデルでは読み取れません。より新しいモデルに移行した会話は、その推論を保持します。より古いモデルに移行した会話は、それらのブロックのモデルチェックに失敗し、API はそのリクエストに対してそれらを削除します。モデルごとの正確なリストについては、保持された思考を参照してください。
• ブロックより前の内容が何も変更されていないこと。 トップレベルの system プロンプト、tools 内のツールセット、およびブロックより前のすべてのメッセージです。サーバー側のコンパクションを使用している場合、チェック対象のプレフィックスは最新のコンパクションブロックから始まります。
• 以前の思考ブロックのチェーンが途切れていないこと。 以前の thinking および redacted_thinking ブロックはプレフィックスの一部ではありませんが、各思考ブロックはターンをまたいでその直前のブロックを記録しています。履歴の先頭から思考ブロックを削除することはできます。途中から1つ削除すると、それ以降のすべての思考ブロックが無効になります。

モデルチェックに失敗したブロックは常に削除されます。プレフィックスの不一致については、thinking.block_binding.prefix_mismatch_behavior で何が起こるかを選択します。これには thinking-binding-controls-2026-08-01 ベータヘッダーが必要です。

• "drop_block": API はそのブロックと、会話内でそれ以降のすべての思考ブロックを削除し、リクエストは成功します。削除されたブロックは課金されません。レスポンスはトップレベルの input_transformations 配列にそれらをリストします（ストリーミング時は message_start イベント上）。
• "error": API は、最初に失敗したブロックを示す 400 invalid_request_error でリクエストを拒否します。

デフォルトは "error" です。このヘッダーにより、フィールドを設定できるようになり、レスポンスに input_transformations が追加されます。

影響を受ける対象

Claude Fable 5.1 です。モデルリストについては保持された思考を参照してください。

Claude Fable 5.1 では、API は新規アカウントに対してこのチェックを適用します。新規アカウントとは、2026年8月31日 00:00 UTC 以降に作成されたアカウントです。同じ定義が Claude API とクラウドプラットフォームの両方に適用されます。以降のモデルでは、すべてのユーザーに対してこのチェックが適用されます。

prefix_mismatch_behavior を設定したリクエストは、アカウントの作成時期に関係なく適用対象にオプトインします。これが古いアカウントからテストする方法です。お使いのアカウントがデフォルトで適用対象かどうかを確認するには、ベータヘッダーなしで履歴を編集するリクエストを送信してください。ヘッダー名を示す 400 が返れば、適用対象であることを意味します。

インテグレーションが影響を受けるかどうかを判断する方法

通常の数ターンにわたって、インテグレーションが送信する正確なリクエストボディをキャプチャしてください。製品がコンパクションやツール変更を行う場合は、それらも含めます。連続するリクエストの各ペアについて、system、tools、および messages の共通部分を比較します。新しく追記されたターンまでは、バイト単位で同一であるべきです。

次に、API に対して確認します。thinking-binding-controls-2026-08-01 ベータヘッダーと claude-fable-5-1 を使用し、thinking.block_binding.prefix_mismatch_behavior を "drop_block" に設定して、インテグレーションを通じて通常のマルチターンセッションを実行します。このリクエストはそのようなセッションの2ターン目であり、最初のレスポンスのアシスタントターンを受信したとおりに正確に送り返しています。

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: thinking-binding-controls-2026-08-01" \
  -d '{
    "model": "claude-fable-5-1",
    "max_tokens": 16000,
    "thinking": {
      "type": "adaptive",
      "block_binding": { "prefix_mismatch_behavior": "drop_block" }
    },
    "system": "You are a coding agent.",
    "messages": [
      { "role": "user", "content": "Fix the failing test." },
      {
        "role": "assistant",
        "content": [
          { "type": "thinking", "thinking": "", "signature": "EqQBCkYIBxgCKkD..." },
          { "type": "text", "text": "I need to see the test first. Which file is it in?" }
        ]
      },
      { "role": "user", "content": "tests/test_auth.py" }
    ]
  }'

すると、すべてのレスポンスにトップレベルの input_transformations 配列が含まれます。各ターンでこれをログに記録してください。

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

• すべてのターンで空: インテグレーションは履歴をそのまま維持しています。
• reason: "prefix_binding_mismatch": path にあるブロックより前の何かが、このリクエストと前のリクエストの間で変更されました。そのターンまでの system、tools、messages の差分を取って見つけてください。
• reason: "model_binding_mismatch": 会話が、以前のモデルのブロックを読み取れないモデルに移行しました（ルーター、フォールバック）。インテグレーションのバグではありません。ブロックを送信し続け、現在のモデルが読み取れないものは API に削除させてください。

フィールドを設定するとリクエストが適用対象にオプトインされるため、これはどのアカウントからでも機能します。代わりに CI で明示的に失敗させるには、"error" を設定します。400 は次のように始まります。

messages.1.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. メッセージは通常、何が変更されたかを示す文で終わります。たとえば、system プロンプトや tools リストがブロック作成時と異なる、といった内容です。

このエラーのすべてのバリエーションについては、思考のトラブルシューティングを参照してください。

何が編集とみなされるか

連続する2つのリクエストの間で:

インテグレーションを更新する

各パターンは、ある種類の履歴編集を、以前のバイトを変更せずにモデルに同じ効果をもたらす API 機能に置き換えます。

アシスタントターンは返されたとおりに正確に追記する

各レスポンスの content 配列を保存し、アシスタントターンとして変更せずに送り返してください。すべてのブロックタイプを受信した順序で、thinking フィールドが空の thinking ブロックも含めます。未知のブロックタイプや空のフィールドを削除する中間型を介して再シリアライズしないでください。

指示の追加は system の編集ではなく、会話途中のシステムメッセージで行う

コードがリクエストごとにトップレベルの system プロンプトを再構築している場合（現在時刻、トークン予算、モードフラグ、新たに発見されたプロジェクトコンテキスト）、会話内のすべての思考ブロックがチェックに失敗します。セッション開始時に system を固定し、何かが変わったときは、それが真になる messages 内の位置に role: "system" メッセージを追記してください。

{
  "role": "system",
  "content": "The user switched the workspace to read-only mode. Do not write files until told otherwise."
}

モデルはこれをシステムプロンプトの権限で扱い、それより前のすべては変更されません。Claude Fable 5.1 ではベータヘッダーは不要です。ツールループでは、tool_result ユーザーメッセージの後に配置し、アシスタントの tool_use とその tool_result の間には決して配置しないでください（制限事項を参照）。

ターンごとのリマインダーはターンスコープのシステムメッセージとして送信する

最も一般的な履歴編集は、ターンごとのナッジです。ツール結果の各バッチの後に追記される1行（「独立した読み取りはまとめてリクエストしてください」「しばらくユーザーに進捗を伝えていません」）で、リマインダーが積み重ならないように次のリクエストで削除されます。この削除が編集にあたります。

代わりに、ナッジを clear_at: "next_user_message" を付けた会話途中のシステムメッセージとして、tool_result ユーザーメッセージの後に送信してください（ベータヘッダー mid-conversation-system-clear-at-2026-08-21）。この messages 配列は、2回のツールラウンド後のリクエストです。messages[3] は前のリクエストのナッジでそのまま残されており、messages[6] はこのリクエストのコピーです。

[
  { "role": "user", "content": "Fix the failing test." },
  {
    "role": "assistant",
    "content": [
      { "type": "thinking", "thinking": "", "signature": "..." },
      {
        "type": "tool_use",
        "id": "toolu_01",
        "name": "read_file",
        "input": { "path": "tests/test_auth.py" }
      }
    ]
  },
  {
    "role": "user",
    "content": [{ "type": "tool_result", "tool_use_id": "toolu_01", "content": "..." }]
  },
  {
    "role": "system",
    "clear_at": "next_user_message",
    "content": "Request every independent read in one turn."
  },
  {
    "role": "assistant",
    "content": [
      { "type": "thinking", "thinking": "", "signature": "..." },
      {
        "type": "tool_use",
        "id": "toolu_02",
        "name": "read_file",
        "input": { "path": "src/auth.py" }
      }
    ]
  },
  {
    "role": "user",
    "content": [{ "type": "tool_result", "tool_use_id": "toolu_02", "content": "..." }]
  },
  {
    "role": "system",
    "clear_at": "next_user_message",
    "content": "Request every independent read in one turn."
  }
]

tool_result のみのユーザーメッセージは「次のユーザーメッセージ」としてカウントされるため、messages[3] はすでにクリアされています。何もレンダリングされず、入力トークンもかかりませんが、配列内にはまだ存在するため、messages[4] の思考は有効なままです。messages[6] がこのターンでモデルが見るものです。以降のリクエストでは両方をそのままの位置に保ち、次の tool_result メッセージの後に次のコピーを追記してください。ターンスコープのメッセージは text のみを持ち、cache_control は受け付けません。キャッシュブレークポイントは直前のユーザーターンに置いてください。ターンスコープのシステムメッセージを参照してください。

ベータを使用しない場合は、同じユーザーメッセージ内の tool_result ブロックの後に text ブロックとしてナッジを追記し、以前のコピーはそのまま残してください。モデルは最新のものに基づいて動作します。

ツールの変更は tools の編集ではなく、tool_addition と tool_removal で行う

セッション途中でツールセットが変わる場合（認証後にツールがアンロックされる、モード切り替え後に危険なツールが取り下げられる）、tools を編集しないでください。セッション開始時に完全なセットを宣言し、会話途中のツール変更を使用して、その時点以降ツールを提供または取り下げてください（ベータヘッダー mid-conversation-tool-changes-2026-07-01）。まだ利用できないツールには defer_loading: true を付け、後で tool_addition ブロックを送ります。形式はこの tool_removal と同じです。

{
  "role": "system",
  "content": [
    { "type": "tool_removal", "tool": { "type": "tool_reference", "name": "delete_branch" } },
    { "type": "text", "text": "Branch deletion is disabled for the rest of this session." }
  ]
}

セッション途中でスキーマが判明するツール（実行時に発見される MCP サーバー）は、defer_loading: true を付けて tools に追記し、tool_addition で提供できます。参照されていない遅延ツールはプレフィックスの一部ではないため、追記しても安全です。通常のツールの追記は安全ではありません。

可能な場合はサーバー側でコンテキストをトリミングする

クライアント側の切り捨てと要約は、2番目に一般的な編集です。最も古いターンを削除または要約し、最近のターンをそのまま保持します。最近のターンの思考ブロックは、削除した履歴がまだ存在していた間に生成されたものなので、チェックに失敗します。サーバー側の同等機能は編集としてカウントされません。チェックは送信したとおりの会話を比較するためです。

• コンパクションは、コンテキストが設定したしきい値に近づくと、古いターンをコンパクションブロックに要約し、チェック対象のプレフィックスはそのブロックから再開されます。その instructions パラメータは、独自の要約プロンプトを受け取ります（「すべてのティッカー、ポジションサイズ、明示された前提を保持してください」）。
• コンテキスト編集は、ルールに従って古いツール結果（clear_tool_uses_20250919）または古い思考ブロックを古い順に（clear_thinking_20251015）クリアします。

クライアント側でのカスタムコンパクション

このチェックはクライアント側のコンパクションを禁止するものではありません。ルールはより限定的です。書き換えたプレフィックスの後ろに思考ブロックを残さないでください。

シンプルなコンパクションが推奨される形式であり、変更は不要です。会話が長くなりすぎたら、それを1つのメッセージに要約し、次のリクエストをその要約と新しいユーザーターンで開始します。以前のターンや思考ブロックは再送しません。messages は [{"role": "user", "content": "<summary of the session so far>\n\n<the next instruction>"}] になります。以前の思考は残らないため何も失敗せず、モデルはコンパクションされた会話について新たに思考します。Claude モデルはこの方式で長期タスクについて訓練されており、ほとんどのワークロードでより精巧な方式と同等のパフォーマンスを発揮します。あらゆるコンパクションと同様に、コンパクション時点でプロンプトキャッシュはリセットされます。

他の2つの一般的な形式は、そのままでは失敗し、それぞれ1つの変更が必要です。

• 末尾保持コンパクションは、古いターンを要約し、最新のターンをそのまま保持します。保持されたターンの思考ブロックは完全な履歴に対して生成されたものなので、要約の後ろでは失敗します。修正方法: 引き継ぐすべてのアシスタントターンから thinking と redacted_thinking を取り除き、text と tool_use を保持するか、prefix_mismatch_behavior: "drop_block" を送信して API に取り除かせます。
• バックグラウンドコンパクションは、クリティカルパスの外で要約を構築し、会話が続いている間にそれを差し替えるため、その間に生成されたすべてのターンには差し替え前の思考が含まれます。修正方法: 差し替え前に生成された思考ブロックをまだ含むすべてのリクエストで "drop_block" を送信する（または自分でそれらのブロックを取り除く。差し替え後の最初のレスポンスの input_transformations に、どのブロックかが正確にリストされます）か、同期的にコンパクションします。

トランスクリプトの途中から個々のターンを切り取ると、それ以降のすべてが無効になり、これを回避できるクライアント側の形式はありません。行おうとしていた指示変更には会話途中のシステムメッセージを、選択的な削除にはサーバー側のコンテキスト編集を使用してください。

ツールラウンドの途中でコンパクションしないでください。tool_use がまだ tool_result を待っているアシスタントターンは、思考をそのまま付けて送り返すべきです。そうすることで、モデルは自身の推論とともにラウンドを完了できます（思考ブロックの保持を参照）。

ファイルはコンテンツが変わる URL ではなく ID で参照する

url ソースを持つ image または document ブロックの場合、取得されたバイトはチェック対象のプレフィックスの一部であり、URL 文字列はそうではありません。「最新のスクリーンショット」エンドポイントや編集されたドキュメントは、以降の思考を無効にします。同じファイルに対するローテーションする署名付き URL は無効にしません。ターンをまたいで参照するコンテンツは、Files API で一度アップロードして file_id を使用するか、base64 で送信してください。

不一致時に何が起こるかを決める

インテグレーションが追記専用になったら、本番用の prefix_mismatch_behavior を選択してください。これはプレフィックスの不一致のみを制御します。現在のモデルが読み取れないブロック（ルーター切り替えやサーバー側フォールバックの後）は常に削除され、ベータヘッダーが送信されている場合は input_transformations で報告されます。

• "error"（デフォルト）: プレフィックスの不一致がコードのバグしか意味しない場合。ブロックが黙って削除されるのではなく、テスト中の 400 で気づくことができます。Message Batches API では、未設定のデフォルトはバッチアイテムを失敗させる代わりに失敗したブロックを削除します。アイテムをエラーにしたい場合は、明示的に "error" を設定してください。
• "drop_block": 失敗するよりも影響を受けるブロックを削除したい場合。input_transformations をログに記録してください。

本番で 400 をキャッチした場合、同じリクエストを再試行しても解消されません。prefix_mismatch_behavior: "drop_block"（およびベータヘッダー）を付けて再試行してください。これにより、失敗するブロックだけが正確に削除されます。tool_use がまだ tool_result を待っているアシスタントターン内のものも含まれます。削除はそのリクエストにのみ適用されるため、セッションの残りの間は "drop_block"（およびベータヘッダー）を送信し続けてください。ベータを使用しない場合は、履歴からすべての thinking および redacted_thinking ブロックを取り除き、各ターンの text および tool_use ブロックはそのまま残して、一度再試行してください。その後、原因となった編集を修正してください。

このページで使用されている API 機能

1つのリクエストでヘッダーを組み合わせるには:

anthropic-beta: thinking-binding-controls-2026-08-01,mid-conversation-system-clear-at-2026-08-21,mid-conversation-tool-changes-2026-07-01

同じベータ名が Amazon Bedrock と Google Cloud でも適用されます。各 SDK での送信方法については、ベータヘッダーを参照してください。

チェックリスト

• 公式の Claude 製品または SDK（Claude Code、claude.ai、Claude Managed Agents、Claude Agent SDK）が会話履歴を管理している場合は、ここで終了です。
• 連続するリクエストボディが、system、tools、および共通の messages プレフィックスにおいてバイト単位で同一である。
• prefix_mismatch_behavior: "drop_block" のもとでの完全なセッションで、prefix_binding_mismatch エントリがログに記録されない。
• アシスタントターンが、すべてのブロックタイプを含め、返されたとおりにバイト単位で送り返されている。
• トップレベルの system と tools がセッション中固定されている。変更は role: "system" メッセージと tool_addition / tool_removal ブロックで行う。
• ターンごとのリマインダーが、新たに追記され決して削除されないターンスコープのシステムメッセージ（または末尾のテキストブロック）である。
• コンテキストが、コンパクションまたはコンテキスト編集、あるいは書き換えたプレフィックスの後ろに思考ブロックを残さずツールラウンドを決して分割しないクライアント側コンパクションによってトリミングされている。
• ターンをまたぐファイルが、変更可能な URL ではなく file_id または base64 である。
• 本番用の prefix_mismatch_behavior が設定され、その 400 または削除エントリが監視されている。

次のステップ