思考

1回のパスで回答するモデルは、最初の試行ですべてを正しく行わなければなりません。下書きも、確認も、途中での方針変更もできません。証明、厄介なバグ、長いエージェントタスクでは、最初のアプローチが最良であるとは限りません。

思考はその制約を取り除きます。思考が有効な場合、Claudeは回答する前に自分の言葉で問題に取り組みます。何が求められているかを言い直し、アプローチを試し、中間結果を確認し、成り立たない道筋を放棄します。その推論はレスポンスに先立って thinking コンテンツブロックとして届き、Claudeはそれを活用して最終的な回答を生成します。これが、数学、コーディング、分析、長時間のエージェント作業といった複雑なタスクで思考がパフォーマンスを向上させる理由です。こうしたタスクでは、回答の質は、思考がなければレスポンス自体に圧縮されるか省略されてしまう中間作業に依存します。

思考にはコストがあります。Claudeが推論に費やすトークンは、思考テキストが返されない場合でも出力トークンとして課金され、レスポンステキストとともに max_tokens にカウントされます。このページでは、API全体で思考がどのように動作するかを説明します。思考の有効化、出力の読み取り、そしてツール、ストリーミング、キャッシング、コンテキストウィンドウとの相互作用の管理について扱います。

思考の仕組み

特定のリクエストでClaudeが思考するかどうか、またどの程度深く思考するかは、思考の設定とリクエストの複雑さによって決まります。

レスポンスにおける思考は次のようになります。1つ以上の thinking コンテンツブロックが text ブロックの前に届きます。思考ブロックも、その後に続く text ブロックと同様に生成されたコンテンツですが、正規のレスポンスからは分離されています。各思考ブロックには signature フィールドも含まれます。これは完全な推論の暗号化されたコピーであり、マルチターンやツール使用の会話では変更せずにそのまま渡し返します（思考の暗号化を参照）。

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me break this down. The question has two parts, so I'll start with the simpler one and use its result to constrain the second...",
      "signature": "WaUjzkypQ2mUEVM36O2Txu...."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

このテキストは常に表示されるわけではなく、表示されるものも生の思考の連鎖ではありません。思考ブロック内のテキストはClaudeの推論の要約です。思考設定の display フィールドは、その要約を返すかどうかを制御します。"summarized" は要約を返し、多くのモデルでデフォルトとなっている "omitted" は空の thinking フィールドを持つ思考ブロックを返します。いずれの場合も、ブロックは同じように課金され、マルチターン会話では同じように渡し返されます。モデルごとのデフォルトと詳細については、思考の表示の制御を参照してください。

Claudeがツールを使用する場合、思考はツール呼び出しの間にも現れることがあります。ツール使用と思考を参照してください。完全なレスポンス形式については、Messages APIリファレンスを参照してください。

思考の設定

ほとんどのモデルでは、思考はデフォルトで有効になっているか、パラメータ1つで有効にできます。各モデルがどの設定を受け付け、何がデフォルトであるかは、トラブルシューティングページのモデル別設定表に記載されています。

Claude Opus 5、Claude Sonnet 5、Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5、Claude Mythos Previewでは、思考はすでに有効になっており、設定は不要です。これらのモデルでは display のデフォルトは "omitted" であるため、オプトインするまで思考テキストは非表示です。thinking: {"type": "adaptive", "display": "summarized"} でオプトインします。これは、以下のリクエストのモデル文字列を入れ替えたものとまったく同じです。

Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 4.6では、thinking: {type: "adaptive"} を設定するまで思考は無効です。この設定により、Claudeはリクエストに基づいていつ、どの程度深く思考するかを判断します。以下の例ではこれを設定し、思考テキストが表示されるように display: "summarized" を設定し、余裕のある max_tokens を使用しています。

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
)

for block in response.content:
    if block.type == "thinking":
        print(f"\nThinking: {block.thinking}")
    elif block.type == "text":
        print(f"\nResponse: {block.text}")

この例を実行すると、要約された思考が出力され、その後に回答が出力されます。

Thinking: Use Euclidean algorithm.
1071 = 2*462 + 147
462 = 3*147 + 21
147 = 7*21 + 0
GCD = 21

Response: ## Finding GCD of 1071 and 462

I'll use the **Euclidean algorithm**, repeatedly dividing and taking remainders...

思考トークンは max_tokens にカウントされるため、思考とレスポンステキストの両方に十分な余地を残せるよう高めに設定してください。調整ページのコスト管理および思考とコンテキストウィンドウを参照してください。

思考を無効にする

思考がデフォルトで有効になっているClaude Sonnet 5では、思考を無効にできます。

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    thinking={"type": "disabled"},
    messages=[{"role": "user", "content": "Summarize this article in one sentence."}],
)

Claude Opus 5も思考がデフォルトで有効であり、effort が high 以下の場合に thinking: {type: "disabled"} を受け付けます。effortが xhigh または max の場合、思考を無効にすることはできません。thinking: {type: "disabled"} とこれらのeffortレベルを組み合わせたリクエストは400エラーを返します。この制限はClaude Opus 5以降のモデルに適用され、リクエストごとに適用されます。思考を無効にすると、Claude Opus 5はまれにツール呼び出しをプレーンテキストとして出力したり、表示される出力に内部XMLタグを含めたりすることがあります。プロンプトによる緩和策については、思考を無効にして実行するを参照してください。

Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5、Claude Mythos Previewは thinking: {type: "disabled"} を拒否します。これらのモデルでは思考を無効にできません。

お使いのモデルが「extended thinking」（拡張思考）のみをサポートしている場合（モデル別設定表を参照）、代わりに type: "enabled" と budget_tokens の値で設定してください。その設定については拡張思考ページで説明しています。また、思考設定で400エラーが返された場合は、思考のトラブルシューティングで各エラーメッセージとその修正方法を対応付けています。

思考出力の読み取り

思考の表示の制御

思考設定の display フィールドは、APIレスポンスで思考コンテンツがどのように返されるかを制御します。display は両方のモードで機能します。type: "adaptive" または type: "enabled" と併せて設定してください。次の値を受け付けます。

• "summarized"：思考ブロックには要約された思考テキスト、つまりClaudeの推論の読みやすい要約が含まれます。これはClaude Opus 4.6、Claude Sonnet 4.6、およびそれ以前のモデルのデフォルトです。
• "omitted"：思考ブロックは空の thinking フィールドで返されます。signature フィールドには、マルチターンの継続性のために暗号化された完全な思考が引き続き含まれます（思考の暗号化を参照）。これはClaude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5、Claude Opus 5、Claude Sonnet 5、Claude Opus 4.8、Claude Opus 4.7、およびClaude Mythos Previewのデフォルトです。
• "updates"（ベータ）：推論ブロックは "omitted" と同様に空の thinking フィールドで返され、一部のモデルがツール呼び出しの間に書く短い進捗更新が読み取り可能なテキストとして返されます。ベータヘッダー thinking-display-updates-2026-08-18 が必要です。

アプリケーションが思考コンテンツをユーザーに表示しない場合は、display: "omitted" を設定してください。主な利点は、ストリーミング時の最初のテキストトークンまでの時間が短縮されることです。サーバーは思考トークンのストリーミングを完全にスキップして署名のみを配信するため、最終的なテキストレスポンスのストリーミングがより早く開始されます。

display: "omitted" を使用すると、レスポンスには空の thinking フィールドを持つ thinking ブロックが含まれます。

{
  "content": [
    {
      "type": "thinking",
      "thinking": "",
      "signature": "EosnCkYICxIMMb3LzNrMu..."
    },
    {
      "type": "text",
      "text": "The answer is 12,231."
    }
  ]
}

省略された思考を扱う際は、次の点に留意してください。

• 完全な思考トークンに対して引き続き課金されます。省略はレイテンシを削減しますが、コストは削減しません。
• マルチターン会話で思考ブロックを渡し返す場合は、変更せずに渡してください。サーバーは signature を復号してプロンプト構築のために元の思考を再構築します（思考ブロックの保持を参照）。ラウンドトリップされた省略ブロックの thinking フィールドに配置したテキストは無視されます。
• display は thinking.type: "disabled" とは併用できません（表示するものがないため）。
• thinking.type: "adaptive" を使用していて、モデルが単純なリクエストに対して思考をスキップした場合、display に関係なく思考ブロックは生成されません。
• display: "omitted" でストリーミングする場合、thinking_delta イベントは発行されません。display: "updates" では、進捗更新ブロックのみが thinking_delta イベントをストリーミングします。イベントシーケンスについては思考のストリーミングを参照してください。

Ruby SDKでは、例に示すようにプレーンなハッシュは display: を受け取ります。型付きの ThinkingConfigAdaptive クラスでは、パラメータ名は display_（Rubyの Kernel#display をシャドウイングしないよう末尾にアンダースコア）です。いずれの場合も、ワイヤ上のフィールドは display のままです。

要約された思考

display が "summarized" の場合、受け取る思考テキストは生の思考の連鎖ではなく、Claudeの完全な思考プロセスの要約です。要約された思考は、悪用を防ぎながら思考の知能面での利点を完全に提供します。生の思考の連鎖を返す display 設定はありません。

要約された思考を扱う際は、次の点に留意してください。

• 要約トークンではなく、元のリクエストで生成された完全な思考トークンに対して課金されます。課金される出力トークン数は、レスポンスに表示されるトークン数と一致しません。
• Claude Opus 4.6、Claude Sonnet 4.6、およびそれ以前のモデルでは、思考出力の最初の数行はより詳細で、特にプロンプトエンジニアリングの目的に役立つ詳しい推論を提供します。Claude Mythos Previewは最初のトークンから要約するため、その思考ブロックにはこの詳細な前置きは表示されません。
• 要約はClaudeの思考プロセスの主要なアイデアを最小限の追加レイテンシで保持するため、要約は到着するたびにストリーミングできます。
• 要約は、リクエストで対象とするモデルとは異なるモデルによって処理されます。思考モデルは要約された出力を見ません。
• Anthropicは思考機能の改善に努めているため、要約の動作は変更される可能性があります。

モデルの推論を確認するには、レスポンステキストで推論を求めるプロンプトを出すのではなく、thinking ブロックを読んでください。Claude Fable 5.1およびClaude Fable 5では、レスポンステキストの一部としてモデルの内部推論を引き出そうとするリクエストは、stop_details.category: "reasoning_extraction" で拒否されることがあります。フィールドのリファレンスと処理のガイダンスについては、拒否カテゴリを参照してください。

思考のストリーミング

思考はストリーミングと連携します。思考ブロックは content_block_delta イベント内の thinking_delta イベントとしてストリーミングされ、ブロックの content_block_stop の直前に単一の signature_delta イベントが続きます。テキストブロックはその後、通常どおりストリーミングされます。

以下の例では、アダプティブ思考でレスポンスをストリーミングし、思考デルタとテキストデルタを到着するたびに出力します。

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
) as stream:
    for event in stream:
        if event.type == "content_block_start":
            print(f"\nStarting {event.content_block.type} block...")
        elif event.type == "content_block_delta":
            if event.delta.type == "thinking_delta":
                print(event.delta.thinking, end="", flush=True)
            elif event.delta.type == "text_delta":
                print(event.delta.text, end="", flush=True)

ストリーミング後に署名付きの完全な思考ブロックを再構築するには、デルタを自分で連結するのではなく、SDKにメッセージ蓄積ヘルパーがある場合はそれを使用してください（例：Pythonの stream.get_final_message() やTypeScriptの stream.finalMessage()）。

event: message_start
data: {"type": "message_start", "message": {"id": "msg_01...", "type": "message", "role": "assistant", "content": [], "model": "claude-opus-4-8", "stop_reason": null, "stop_sequence": null}}

event: content_block_start
data: {"type": "content_block_start", "index": 0, "content_block": {"type": "thinking", "thinking": "", "signature": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "I need to find the GCD of 1071 and 462 using the Euclidean algorithm.\n\n1071 = 2 × 462 + 147"}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "\n462 = 3 × 147 + 21\n147 = 7 × 21 + 0\n\nSo GCD(1071, 462) = 21"}}

// Additional thinking deltas...

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "signature_delta", "signature": "EqQBCgIYAhIM1gbcDa9GJwZA2b..."}}

event: content_block_stop
data: {"type": "content_block_stop", "index": 0}

event: content_block_start
data: {"type": "content_block_start", "index": 1, "content_block": {"type": "text", "text": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 1, "delta": {"type": "text_delta", "text": "The greatest common divisor of 1071 and 462 is **21**."}}

// Additional text deltas...

event: content_block_stop
data: {"type": "content_block_stop", "index": 1}

event: message_delta
data: {"type": "message_delta", "delta": {"stop_reason": "end_turn", "stop_sequence": null}}

event: message_stop
data: {"type": "message_stop"}

display: "omitted" が設定されている場合、思考ブロックが開き、単一の signature_delta が到着し、thinking_delta イベントなしでブロックが閉じます。テキストのストリーミングはその直後に開始されます。

event: content_block_start
data: {"type":"content_block_start","index":0,"content_block":{"type":"thinking","thinking":"","signature":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":0,"delta":{"type":"signature_delta","signature":"EosnCkYICxIMMb3LzNrMu..."}}

event: content_block_stop
data: {"type":"content_block_stop","index":0}

event: content_block_start
data: {"type":"content_block_start","index":1,"content_block":{"type":"text","text":""}}

display: "updates"（ベータ）では、推論ブロックは "omitted" の場合と同様にストリーミングされます。各進捗更新ブロックは、それが導入する tool_use ブロックの前に、そのテキストを thinking_delta イベントとしてストリーミングします。進捗更新ブロックが開く前に数秒間の一時停止があるのは正常です。

event: content_block_start
data: {"type":"content_block_start","index":1,"content_block":{"type":"thinking","thinking":"","signature":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"thinking_delta","thinking":"Confirmed the retry path never refreshes the expired token. Editing auth.py to add the refresh call."}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"signature_delta","signature":"Es8CCkYICxIM..."}}

event: content_block_stop
data: {"type":"content_block_stop","index":1}

event: content_block_start
data: {"type":"content_block_start","index":2,"content_block":{"type":"tool_use","id":"toolu_01D7FLrfh4GYq7yT1ULFeyMV","name":"edit_file","input":{}}}

"updates" では、ブロックの thinking_delta イベントのいずれかが空でないテキストを含んだ時点で、そのブロックを進捗更新として扱ってください。

一般的なストリーミングの仕組みについては、メッセージのストリーミングを参照してください。

思考とeffort

thinking パラメータは、Claudeが回答する前に思考ブロックで思考するかどうかを制御します。effort パラメータは、Claudeが応答全体にどれだけの労力を費やすかを制御し、アダプティブモードではどのくらいの頻度で、どのくらい深く思考するかも含まれます。effort の値として adaptive を渡さないでください。adaptive は思考モードであり、effortレベルではありません。

各effortレベルが思考の動作にどのような影響を与えるかについては、思考の調整ページのレベル別思考動作表を参照してください。Effortページでは、各モデルがどのレベルをサポートするかを含め、パラメータ自体について説明しています。effortをサポートする唯一の拡張思考専用モデルであるClaude Opus 4.5では、effortは budget_tokens と組み合わされます。予算のルールと調整を参照してください。

2つの制御がこのように分離されているため、目的に合ったものを選んでください。

• 思考が有効なワークロードでコストやレイテンシを下げたい場合： まず effort を下げてください。思考を含むレスポンス全体が縮小されます。
• Claudeの思考の頻度が低すぎる、または浅すぎる場合： effort を上げるか、調整ページのClaudeが思考する頻度の調整を参照してください。
• 思考を完全に無効にする必要がある場合： 許可されているモデルで thinking: {type: "disabled"} を使用してください（モデル別設定表を参照）。
• 支出に厳格な上限が必要な場合： max_tokens を使用してください。effortはソフトなガイダンスです。max_tokens は厳格な制限です。

ツール使用と思考

思考はツール使用と連携し、Claudeがツールの選択を推論し、ツール結果を処理できるようにします。2つの制約が適用されます。

1. ツール選択の制限（手動モード）： 手動の拡張思考（thinking: {type: "enabled"}）でのツール使用は、tool_choice: {"type": "auto"}（デフォルト）または tool_choice: {"type": "none"} のみをサポートします。tool_choice: {"type": "any"} または tool_choice: {"type": "tool", "name": "..."} を使用するとエラーになります。これらのオプションはツール使用を強制するものであり、手動の拡張思考と互換性がないためです。アダプティブ思考は、思考がデフォルトで有効なモデルを含め、強制的なツール使用をサポートします。ただし、Claude Fable 5.1とClaude Mythos 5.1は例外です（レスポンスのプリフィルと強制的なツール使用を参照）。
2. 思考ブロックの保持： ツール結果を返す際は、アシスタントメッセージの思考ブロックを完全かつ変更せずにAPIに渡し返す必要があります。思考ブロックの保持を参照してください。

ツール使用ループは1つのアシスタントターンです。 モデルの観点からは、アシスタントターンはClaudeが完全なレスポンスを終えるまで完了しません。これには複数のツール呼び出しと結果が含まれる場合があります。このシーケンス全体が単一のアシスタントターンです。

User: "What's the weather in Paris?"
Assistant: [thinking] + [tool_use: get_weather]
User: [tool_result: "20°C, sunny"]
Assistant: [text: "The weather in Paris is 20°C and sunny"]

ターン全体は単一の思考モードで実行されます。ツール使用ループ中を含め、ターンの途中で思考を切り替えることはできません。拡張（手動）モードでは、APIはさらに、思考が有効なリクエストの最後のアシスタントターンが思考ブロックで始まることを強制します。アダプティブモードではこれが緩和され、どのアシスタントターンも思考ブロックで始まる必要はありません。

ターン途中の競合は適切に処理されます。 ターンの途中で思考を切り替えた場合（例えば、ツール呼び出しの送信とその結果の返却の間）、APIはエラーを返しません。代わりに、そのリクエストの思考を暗黙的に無効にします。モデルの品質を維持するため、APIは無効なターン構造を作り出す思考ブロックを削除したり、会話履歴が思考の有効化と互換性がない場合に思考を無効にしたりすることがあります。思考が有効だったかどうかを確認するには、レスポンスに thinking ブロックが存在するかどうかを確認してください。

ターン内ではなく、ターン間で切り替えてください。 各ターンの開始時に思考戦略を計画してください。アシスタントターンを完了してから、次のターンの思考設定を変更します。

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
Assistant: [text: "It's sunny"]
User: "What about tomorrow?"
Assistant: [thinking] + [text: "..."] (thinking enabled - new turn)

思考モードの切り替えはプロンプトキャッシングも無効にします。思考とプロンプトキャッシングを参照してください。

思考ブロックの保持

Claudeがツールを呼び出すと、外部情報を待つためにレスポンスの構築を一時停止します。ツール結果を返すと、Claudeは同じレスポンスの構築を続けるため、以前の推論がまだ存在している必要があります。すべての thinking ブロックを、それに付随していた tool_use ブロックとともに、完全かつ変更せずにAPIに渡し返してください。これは2つの理由で重要です。

1. 推論の継続性： 思考ブロックは、ツールリクエストに至った段階的な推論を記録しています。これらを含めることで、Claudeは中断したところから推論を続けることができます。
2. コンテキストの維持： ツール結果はAPI構造上はユーザーメッセージとして現れますが、1つの連続した推論フローの一部です。思考ブロックを保持することで、API呼び出しをまたいでそのフローが維持されます。

要約すると：

• 必須： ツール使用ターン内では、思考ブロックを渡し返してください。
• 推奨： ターンをまたいで、すべてを渡し返してください。
• 許可： ツール使用以外では、以前のターンの思考を省略できます。

古い思考を自分で削除する必要はありません。マルチターン会話ではすべての思考ブロックを渡し返してください。APIが自動的にフィルタリングし、モデルの推論を保持するために必要なブロックを残し、実際にClaudeに表示されたブロックに対してのみ入力トークンを課金します。以前のターンのどのブロックが保持されるかはモデルごとに異なります。モデル別の思考ブロックの保持を参照してください。デフォルトを上書きするには、clear_thinking_20251015 コンテキスト編集戦略を使用してください。

最新のアシスタントメッセージ内では、連続する thinking ブロックのシーケンスは、元のリクエストでモデルが生成したものと一致している必要があります。並べ替え、編集、部分的な削除はできません。これにはredacted_thinking ブロックも含まれます。

すべてのSDKのコードを含む完全な2ターンのウォークスルーについては、ツールおよびマルチターンワークフローにおける思考を参照してください。ツールを定義し、思考とツール使用を含むレスポンスを受け取り、ツール結果とともにアシスタントターンをそのまま返します。

インターリーブ思考

「interleaved thinking」（インターリーブ思考）により、Claudeはツール呼び出しの間に思考し、各ツール結果に基づいて行動する前にそれについて推論できます。インターリーブ思考により、Claudeは次のことができます。

• 次に何をするかを決定する前に、ツール呼び出しの結果について推論する
• 間に推論ステップを挟んで複数のツール呼び出しを連鎖させる
• 中間結果に基づいてより繊細な判断を下す

アダプティブ思考では、アダプティブ思考をサポートするすべてのモデルでインターリーブ思考が自動的に有効になります。ベータヘッダーは不要です。Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5、Claude Mythos Preview、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7では、ツール呼び出し間の推論は常に思考ブロックに現れます。Claude Haiku 4.5はインターリーブ思考をサポートしていません。手動の拡張思考を使用するモデルでは、インターリーブにはベータヘッダーが必要であり、思考予算のカウント方法が変わります。手動モードでのインターリーブ思考で、モデルごとのルールとプラットフォーム固有のヘッダーの動作について説明しています。

インターリーブ思考では、思考の割り当ては単一のレスポンスではなくアシスタントターン全体にまたがることができます。インターリーブ思考はMessages APIを通じて使用されるツールでのみサポートされています。

2つのツールを使うワークフローでインターリーブ思考が何を変えるかを示す具体的な比較については、インターリーブ思考がフローをどう変えるかを参照してください。

ツール呼び出し間の進捗更新

Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5では、モデルはツール呼び出しの間に進捗更新を書くことができます。進捗更新とは、モデルが今見つけたことと次に何をしようとしているかについての1〜2文であり、推論としてではなく、エージェントを見ている人のために書かれます。それぞれが独自の signature を持つ独自の thinking ブロックとして返され、同じ位置にある推論ブロックとは別になります。進捗更新は、それが導入する tool_use または server_tool_use ブロックの直前に置かれます。各ツール呼び出しの前には最大1つの進捗更新があり、モデルはいずれもスキップできます。進捗更新はインターリーブ思考ではありません。ツール呼び出しの間に推論ブロックが現れるかどうかにかかわらず現れ、1つのレスポンスに両方が含まれることもあります。

進捗更新ブロックに何が含まれるかはdisplayによって決まります。

推論を非表示にしたまま、各ステップでユーザーにステータス行を表示するエージェントインターフェースには display: "updates" を使用してください。この設定では、空でないテキストを持つ thinking ブロックはすべて進捗更新であるため、それらだけをレンダリングしてください。これはベータ版であり、ベータヘッダー thinking-display-updates-2026-08-18 が必要です（Amazon Bedrock、Google Cloud、Microsoft Foundryでは、ベータヘッダーで説明されているようにベータ値を渡してください）。ヘッダーがない場合、この値は不明な display 値と同じ400 invalid_request_error で拒否されます。

{
  "model": "claude-fable-5-1",
  "max_tokens": 16000,
  "thinking": { "type": "adaptive", "display": "updates" },
  "tools": [
    {
      "name": "edit_file",
      "description": "Replace the contents of a file in the repository.",
      "input_schema": {
        "type": "object",
        "properties": {
          "path": { "type": "string" },
          "content": { "type": "string" }
        },
        "required": ["path", "content"]
      }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "The login test fails after an hour of uptime. Find out why and fix it."
    }
  ]
}

"updates" では、tool_result に続くレスポンスの冒頭は次のようになります。最初のブロックは推論であり、"omitted" の場合と同様に空のままです。2番目のブロックはテキストを含むため、進捗更新です。"summarized" では両方のブロックがテキストを含み、"omitted" では両方が空になります。

{
  "content": [
    {
      "type": "thinking",
      "thinking": "",
      "signature": "EqMBCkYICxIM..."
    },
    {
      "type": "thinking",
      "thinking": "Confirmed the retry path never refreshes the expired token. Editing auth.py to add the refresh call.",
      "signature": "Es8CCkYICxIM..."
    },
    {
      "type": "tool_use",
      "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
      "name": "edit_file",
      "input": { "path": "auth.py", "content": "..." }
    }
  ]
}

進捗更新を扱う際は、次の点に留意してください。

• 進捗更新ブロックは、他の thinking ブロックと同様に、アシスタントターンの残りとともに変更せずに渡し返してください。
• 受け取るテキストは進捗更新の要約であり、通常は1〜2文です。その長さに依存しないでください。進捗更新は、要約の長さではなく完全な長さで usage.output_tokens にカウントされます。
• 進捗更新ブロックは、どの display 値でも空の thinking フィールドで返されることがあります。空のブロックには何もレンダリングしないでください。"updates" では空の推論ブロックと同じに見えるため、別途の処理は不要です。
• レスポンスがツール呼び出しまたはツール結果の直後に max_tokens、model_context_window_exceeded、または stop_sequence で停止した場合、その最後のブロックは、モデルが完了していなかった作業の代わりとなる進捗更新ブロックである可能性があります。"updates" と "summarized" では、そのテキストは正確に This part of the response was interrupted before it finished. であり、他の更新と同様に表示できます。"omitted" では空です。続行するには、アシスタントターンを変更せずに渡し返し、新しい user メッセージを追加してください（そのターンの各 tool_use ブロックに対する tool_result を含めます）。
• ストリーミング時には、進捗更新ブロックが開く前に数秒間の一時停止が予想されます。思考のストリーミングの "updates" トレースを参照してください。
• これらのモデルは、effortが高い場合や長いツールチェーンでは、進捗更新を書く頻度が低くなります。インターフェースが進捗更新に依存している場合は、ユーザー向けの進捗更新を求めるを参照してください。

モデル別の思考ブロックの保持

以前のアシスタントターンの思考ブロックがデフォルトでコンテキストに残るかどうかは、モデルによって異なります。

• 以前のすべてのターンを保持： Claude Opus 4.5以降のOpusモデル、Claude Sonnet 4.6以降のSonnetモデル、Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5、Claude Mythos Preview。
• 最後のターンのみを保持： それ以前のOpusおよびSonnetモデル、およびClaude Haiku 4.5までのすべてのHaikuモデル。古い思考ブロックを渡し返すと、APIが自動的に削除します。自分で削除する必要はありません。

保持には2つの利点があります。

• キャッシュの最適化： 保持された思考ブロックはツール結果とともに渡し返され、アシスタントターン全体で段階的にキャッシュされるため、ツール使用中のキャッシュヒットが可能になり、マルチステップワークフローでトークンを節約できます。
• 知能への影響なし： 思考ブロックの保持はモデルのパフォーマンスに悪影響を与えません。

トレードオフはコンテキストの使用量です。すべてを保持するモデルでは、保持された思考ブロックが他の会話履歴と同様に入力としてカウントされるため、長い会話はより多くのコンテキスト領域を消費します（思考とコンテキストウィンドウを参照）。この動作はどちらの方式でも自動です。コードの変更やベータヘッダーは不要であり、思考ブロックの保持で説明したように、完全で変更されていない思考ブロックを引き続き渡し返してください。いずれかの方向にデフォルトを上書きするには、思考ブロックのクリアを使用してください。

会話の途中でモデルを切り替える場合。 例えば分類器による拒否のフォールバックの後など、モデルを切り替える際も思考ブロックを変更せずに渡し返し続けてください。思考ブロックは、それを生成したモデルまたはより新しいモデルでのみ読み取り可能であり、APIは対象モデルが読み取れないブロックを無視または削除します。Claude Fable 5.1とClaude Mythos 5.1では方向が重要です。これらはそれ以前のすべてのモデルの思考ブロックを読み取りますが、それ以前のモデルはこれらのブロックを読み取れません。そのため、これらのモデルへ切り上げると会話の推論が保持され、切り下げると失われます（正確なリストと、削除されたブロックの課金および報告方法については保持される思考を参照）。以前の thinking および redacted_thinking ブロックを自分で削除するのは、ブロックを削除するのではなく無視するモデルで入力トークンを節約する場合に限ってください。また、本文を変更しないことが求められるフォールバッククレジットを利用する際には決して削除しないでください。

保持される思考

Claudeは、思考ブロックが作成された条件の下でのみ、そのブロックを保持し、後のターンで使用可能な状態に保ちます。Claude Fable 5.1およびClaude Mythos 5.1以降、thinking または redacted_thinking ブロックは次の場合にのみ保持されます。

• それを生成したモデル、またはより新しいモデルに対して。 それ以前のモデルはブロックを使用できず、APIはそのリクエストからブロックを削除します。それを生成したモデル、またはより新しいモデルに対してのみを参照してください。
• それを生成した会話の中で（Claude Fable 5.1のみ）。 system プロンプト、tools、またはそれ以前のメッセージのいずれかが変更されると、ブロックは無効になり、APIはリクエストを拒否するかブロックを削除します。それを生成した会話の中でのみを参照してください。

ブロックの signature は、両方のモデルで両方の条件を記録します。APIは、別のモデルへのリクエストを含め、後のリクエストでブロックが戻ってくるたびにこれを確認します。Claude Mythos 5.1はモデルの条件のみを確認します。

ブロックは変更せずに渡し返してください。 すべてのアシスタントターンを、思考ブロックを含めて受け取ったとおりに送信し、モデルがどのブロックを使用できるかはAPIに判断させてください。

それを生成したモデル、またはより新しいモデルに対してのみ

この条件は一方向です。Claude Fable 5.1とClaude Mythos 5.1はそれ以前のモデルの思考ブロックを読み取りますが、それ以前のモデルはこれらのブロックを読み取れません。

• Claude Fable 5.1またはClaude Mythos 5.1に移行した会話は推論を保持します。 それ以前のモデルの思考ブロックは読み取り可能なままであるため、モデルは切り替え後の最初のターンから通常どおり思考します。
• これらのモデルからそれ以前のモデルに移行した会話は推論を失います。 それ以前のモデルはこれらのブロックを読み取れず、APIはそのリクエストでブロックを削除し、それ以前のモデルは表示されているメッセージから再び推論します。会話が後で同じ履歴でClaude Fable 5.1に戻った場合、自身のブロックは再び読み取り可能になります。

詳しく言うと、Claude Fable 5.1とClaude Mythos 5.1は、互いが生成した思考ブロック、Claude Opus 5、Claude Fable 5、Claude Mythos 5が生成した思考ブロック、およびClaude Opus 4.8以前のOpusモデル、Claude Sonnetモデル、Claude Haiku 4.5が生成した思考ブロックを読み取ります。これら2つ以外のモデルは、Claude Fable 5.1またはClaude Mythos 5.1が生成したブロックを読み取れません。

受信側のモデルが読み取れないブロックは削除されます。 APIはプロンプトがモデルに到達する前にそれを削除します。input_tokens にはカウントされず、課金もされません。例えば分類器による拒否のフォールバックの後など、会話の途中でClaude Fable 5.1から古いモデルにフォールバックすると、古いモデルは表示されている会話から再び推論します。制御用ベータヘッダーを使用すると、削除は input_transformations に model_binding_mismatch として報告されます。ヘッダーがない場合、削除は通知されません。サーバー側フォールバックも、読み取れないブロックを同じ方法で削除します。

それを生成した会話内でのみ

Claude Fable 5.1 の thinking ブロックは、それが生成された会話プレフィックスが変更されない間のみ保持されます。その signature は、system プロンプト、tools、およびそのブロックより前のメッセージをカバーします。Claude Mythos 5.1 は同じ signature を記録しますが、このチェックは実行しません。

このチェックは、2026年8月31日以降に作成された新規アカウントに対して適用されます。それ以前に作成されたアカウントでは、API は署名に条件を記録しますが、リクエストが thinking.block_binding.prefix_mismatch_behavior を設定して適用をオプトインしない限り、不一致に対して何も行いません。Anthropic は将来のモデルで、すべての組織に対してこの条件を適用する予定です。アカウントがそれ以前に作成されたものである場合は、今のうちにアプリケーションを互換性のあるものにしてください。同じ追記専用パターンによってプロンプトキャッシュがウォームな状態に保たれ、prefix_mismatch_behavior: "error" を送信することでこのチェックに対してテストできます。ユーザーが自身のAPIキーで実行するツールやフレームワークを提供している場合は、その方法でテストしてください。新規アカウントのユーザーには、あなたより先に適用されます。保持された思考には統合チェックリストがあります。コードが履歴を編集しているかどうかを判断する方法と、各種の編集を置き換える API 機能について説明しています。

チェックが適用される場合、変更されたプレフィックスに対してブロックを再送するリクエストは、400 invalid_request_error で拒否されます。

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.

最後の文は、リクエストがベータヘッダーを送信しなかった場合にのみ表示されます。メッセージの末尾には、変更された最初のメッセージを示す文がもう1つ付くことがあります。同じリクエストボディを再試行しても同じように失敗します。代わりに無効化された推論なしで続行するには、thinking-binding-controls-2026-08-01 ベータヘッダーを送信し、prefix_mismatch_behavior を "drop_block" に設定します。すると API は失敗したブロックと、会話内でそれ以降のすべての thinking ブロックを削除し、それぞれを input_transformations に prefix_binding_mismatch として報告します。トークンカウントエンドポイントも同じチェックを実行し、同じ 400 を返します。

後続の thinking ブロックを無効化するもの：

• 以前のメッセージの編集、並べ替え、または削除。以前のユーザーターンに挿入したターンごとのリマインダーを削除することも含まれます。
• リクエスト間で、トップレベルの system プロンプトの内容を変更すること、または tools 配列内のツールを追加、削除、編集すること。
• 直近のアシスタントターンを thinking を含めてそのまま保持しつつ、それより前のターンを書き換えるクライアント側のコンパクションまたは切り詰め。
• 以前のターンにある画像またはドキュメントの URL が、後のリクエストで異なるバイトを返す場合。チェックは URL 文字列ではなくバイトを対象とするため、同じファイルに対するローテーションする署名付き URL は問題ありません。ターンをまたいで参照するコンテンツについては、Files API で一度アップロードして file_id を送信するか、base64 で送信してください。

無効化しないもの：

• 先頭から連続する thinking ブロックを古い順に削除すること。会話内の最初の thinking ブロック（または直近のコンパクションブロック以降の最初のもの）、次にその次、という順序です。それ以外の場所から thinking ブロックを削除すると、そのターンおよび以降のすべてのターンにおいて、それより後のすべての thinking ブロックが無効化されます。
• リクエスト間で output_config.effort、max_tokens、またはその他のサンプリング設定を変更すること。
• cache_control マーカー。どこに配置または移動しても問題ありません。
• サーバー側のコンパクションおよびコンテキスト編集。チェックはサーバーが編集したコピーではなく、あなたが送信したとおりの会話を比較するため、これらは編集としてカウントされません。コンパクション後、チェック対象のプレフィックスはコンパクションブロックから始まります。

thinking ブロックを有効に保つパターン：

• 追記のみ。 新しいメッセージは messages の末尾に追加し、以前のターンはバイト単位で変更しないでください。
• 会話途中のシステムメッセージ と会話途中のツール変更を使用して、トップレベルの system フィールドや tools 配列を編集する代わりに、途中で指示を追加したりツールの利用可否を変更したりします。1つのターンにのみ適用すべきリマインダーについては、ターンスコープのシステムメッセージとして送信し、後で削除するのではなく履歴に残してください。これによりプロンプトキャッシュも保持されます。
• サーバー側のコンテキスト管理を使用し、自分で履歴を切り詰めないでください。
• リクエストがプレフィックス不一致で拒否され、履歴を修復できない場合は、 ベータヘッダーと prefix_mismatch_behavior: "drop_block" を付けて再送信するか、履歴からすべての thinking および redacted_thinking ブロックを取り除いて一度だけ再試行してください。

以前の thinking が削除された場合、モデルはそれらのブロックなしでそのターンに回答します。自身の履歴を繰り返し無効化するクライアントは、そのたびにプロンプトキャッシュを最初からやり直すことになり、コストが増加します。

クライアント側のコンパクション。 このチェックはクライアントでのコンパクションを排除するものではありません。ルールはより限定的です。書き換えたプレフィックスの後ろに thinking ブロックを残さないでください。サーバー側のコンパクションがこれを満たす最も簡単な方法です。クライアントでコンパクションを行う場合は、次のいずれかの形を使用してください。

• シンプルなコンパクション（推奨）： 会話を1つのメッセージに要約し、次のリクエストをその要約と新しいユーザーターンで開始します。以前のターンや以前の thinking ブロックは再送しません。以前の thinking が残らないため何も失敗せず、モデルはコンパクションされた会話に対して新たに思考します。Claude モデルはこの方式で長期タスクについて訓練されており、ほとんどのワークロードにおいて、より複雑な方式と同等のパフォーマンスを発揮します。あらゆるコンパクションと同様に、プロンプトキャッシュはリセットされます。
• 末尾保持コンパクション： 古いターンを要約し、直近のターンはそのまま保持します。保持されたターンの thinking ブロックは完全な履歴に対して生成されたものであり、要約の後ろでは失敗します。引き継ぐすべてのターンから thinking と redacted_thinking を取り除く（テキストとツール呼び出しは残せます）か、prefix_mismatch_behavior: "drop_block" を設定して API に破棄させてください。
• バックグラウンドコンパクション： クリティカルパスの外で要約を構築し、会話を続けながらそれを差し替えます。その間に生成されたすべてのターンには、差し替え前の thinking が含まれます。差し替え前に生成された thinking ブロックをまだ含むすべてのリクエストで "drop_block" を送信する（または自分でそれらのブロックを取り除く。差し替え後の最初のレスポンスの input_transformations に、どのブロックかが正確に列挙されます）か、同期的にコンパクションしてください。

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

保持されないブロックの制御（ベータ）

ベータヘッダー thinking-binding-controls-2026-08-01 を送信すると、2つのものが得られます。API が削除した thinking ブロックを列挙する、すべてのレスポンスに含まれる input_transformations 配列と、1つのフィールドを持つ thinking 設定上の block_binding オブジェクトです。

block_binding は thinking.type: "adaptive" および thinking.type: "enabled" と併用できます。ベータヘッダーなしで送信すると 400 エラーが返されます。会話チェックを実行しないモデルはこのオブジェクトを受け入れ、モデルチェックによる削除のみを報告するため、1つのリクエストボディがモデル間で機能します。Amazon Bedrock および Google Cloud では、ベータヘッダーで説明されているとおりにベータ名を渡してください。

次のリクエストは、拒否ではなく削除をオプトインします。最初のターンでは再送するものがないため、input_transformations は空で返されます。

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "block_binding": {"prefix_mismatch_behavior": "drop_block"},
    },
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
    betas=["thinking-binding-controls-2026-08-01"],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

print(f"Input transformations: {len(response.input_transformations or [])}")

The greatest common divisor of 1071 and 462 is 21.
Input transformations: 0

削除されたブロックは input_transformations に報告されます。 ベータヘッダーのもとでは、思考対応モデルからのすべてのレスポンスにこのトップレベル配列が含まれます。何も削除されなかった場合は空であり、null になることはありません。各エントリは、削除されたブロックの位置と失敗したチェックを示します。

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

reason フィールドは model_binding_mismatch または prefix_binding_mismatch です。後のチェックで値が追加されるため、認識できない type または reason を持つエントリは無視してください。ストリーミング時には、input_transformations は message_start イベント内の message オブジェクトに含まれて届きます。ストリーム途中のサーバー側フォールバックの後は、最後の message_delta イベントが、提供モデルのエントリを含む配列を再度運びます。ベータヘッダーがない場合、このフィールドは存在しません。

改ざんされた、または復号できない署名は別の失敗です。常に 400（Invalid `signature` in `thinking` block、理由句なし）を返し、prefix_mismatch_behavior は適用されません。メッセージバッチでは、"error" のもとでブロックが会話チェックに失敗したアイテムは errored として解決されます。

思考とプロンプトキャッシング

プロンプトキャッシングは、いくつかの特定の方法で思考と相互作用します。以下のルールは両方の思考モードに適用されます。

設定の変更はキャッシュを無効化します。 thinking 設定と解決された effort レベルはプロンプト自体にレンダリングされるため、いずれかを変更すると新しいキャッシュプレフィックスが開始されます。adaptive、enabled、disabled 間の切り替え、budget_tokens の変更、effort 値の変更はすべてキャッシュブレークポイントを無効化します。メッセージレベルのブレークポイントは常にミスし、ツールおよびシステムプロンプトのブレークポイントも、モデルが設定をどこにレンダリングするかによってミスする可能性があります。thinking またはトップレベルの effort の変更は、キャッシュを最初からやり直すものとして扱ってください。メッセージごとの effort をサポートするモデルでは、messages 内の role: "system" メッセージで運ばれる effort の変更は、キャッシュされたプレフィックスをそのまま維持します。同じ設定を維持する連続したリクエストはキャッシュを保持し、パラメータを明示的にデフォルト値に設定することは省略することと同等です。いずれかの保持された思考の条件のもとで API が削除した thinking ブロックは、そのブロックの位置以降のキャッシュされたプレフィックスを変更します。変更せずに渡し返されたブロックはキャッシュをそのまま維持します。使用量出力を伴う実例は、思考のステアリングページにあります。

thinking ブロックはツール結果とともにキャッシュされます。 ツール使用ループ中、ツール結果を含むフォローアップリクエストを行うとキャッシュが発生します。その時点で、thinking ブロックを含む以前の会話履歴がキャッシュされる可能性があり、キャッシュされた thinking ブロックはキャッシュから読み取られる際に使用量メトリクスで入力トークンとしてカウントされます。これは明示的な cache_control マーカーがなくても自動的に発生し、通常の思考とインターリーブ思考で同じように動作します。トレードオフとして、レスポンスで二度と目にすることのない thinking ブロックも、キャッシュから読み取られる際には入力トークン使用量に寄与します。

以前のブロックがそもそもコンテキストに含まれるかどうかはモデルごとに異なります。 これは保持のデフォルトによって決まります。全保持モデルでは、以前のターンの thinking ブロックはキャッシュされコンテキストに残ります。最終ターンのみのモデルでは、ツール結果ではないユーザーメッセージを送信すると、以前のすべての thinking ブロックがコンテキストから取り除かれます。それらのモデルでは、次のような会話は：

User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]

thinking ブロックが最初から存在しなかったかのように処理されます：

User: ["What's the weather in Paris?"],
Assistant: [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [text block 2],
User: [Text response, cache=True]

全保持モデルでは、同じリクエストで thinking_block_1 と thinking_block_2 がコンテキストとキャッシュに保持されます。

デグラデーションはキャッシュ可能な履歴から thinking を取り除きます。 ターンの途中で thinking が無効になり、現在のツール使用ターンで thinking コンテンツを渡した場合、thinking コンテンツは取り除かれ、そのリクエストでは thinking は無効のままになります（グレースフルデグラデーションを参照）。インターリーブ思考は、thinking ブロックが複数のツール呼び出しの間に発生し得るため、キャッシュ無効化の影響を増幅します。

思考とコンテキストウィンドウ

max_tokens は、現在のターンで Claude が生成するすべての thinking を含み、厳密な制限として適用されます。Claude 4.5 以降のモデルでは、入力トークンと max_tokens の合計が「context window」（コンテキストウィンドウ）のサイズを超えても、API はリクエストを受け入れます。その後、生成がコンテキストウィンドウの上限に達した場合、エラーを返す代わりに stop_reason: "model_context_window_exceeded" で停止します。それ以前のモデルでは、API は代わりにバリデーションエラーを返します。停止理由の処理を参照してください。

thinking がウィンドウに対してどのようにカウントされるかは、いつ生成されたかによって異なります。

• 現在のターンの thinking は常に max_tokens にカウントされ、出力トークンとして課金され、それを生成したターンのコンテキストウィンドウ領域を占有します。
• 以前のターンの thinking は保持のデフォルトに依存します。以前のすべてのターンを保持するモデルでは、以前の thinking ブロックはコンテキストに残り、ウィンドウにカウントされ、会話履歴の他の部分と同様に入力トークンとして課金されます。最終ターンのみを保持するモデルでは、渡し返した古い thinking ブロックを API が自動的に取り除くため、ウィンドウ領域や入力トークンを消費しません。

実際には：

• 全保持モデルでは、thinking を通常の会話履歴であるかのようにコンテキストウィンドウの予算を立ててください。実際にそうだからです。長いエージェントセッションではコンテキストに thinking が蓄積されます。領域を取り戻す必要がある場合は、thinking ブロックのクリアを使用してください。
• 最終ターンのみのモデルでは、thinking はターンごとのコストにすぎません。各ターンの thinking はそのターンの max_tokens にカウントされ、その後ウィンドウから外れます。

以下の図は、最終ターンのみ（取り除き）の方式を示しています。1つ目は複数ターンの会話を示しています。各ターンの thinking ブロックは出力で生成されますが、後のターンの入力には引き継がれません。

2つ目は、ツール使用を伴う同じ方式を示しています。thinking はアシスタントターンの間、そのツール結果とともにコンテキストに残り、次のユーザーターンで外れます。

特に thinking を含む複数ターンの会話については、トークンカウント API を使用して、特定のユースケースに対する正確なカウントを取得してください。

思考の暗号化

完全な thinking コンテンツは暗号化され、各 thinking ブロックの signature フィールドで返されます。API は、thinking ブロックが渡し返された際に、それが Claude によって生成されたものであることを検証するために署名を使用します。

署名を扱う際は、次の点に留意してください。

• thinking ブロックを送り返すことが厳密に必要なのは、思考とともにツールを使用する場合のみです。それ以外の場合は、以前のターンの thinking ブロックを省略できます。渡し返した場合、API がそれらを保持するか取り除くかはモデルによって異なります（モデルごとの thinking ブロックの保持を参照）。これを設定するにはコンテキスト編集を使用してください。
• thinking ブロックを送り返す際は、一貫性のため、また潜在的な問題を避けるために、受け取ったとおりにすべてを渡し返してください。
• レスポンスをストリーミングする場合、署名は content_block_stop イベントの直前に、content_block_delta イベント内の signature_delta として届きます。
• signature の値は、Claude 4 以降のモデルでは以前のモデルよりも大幅に長くなっています。
• signature フィールドは不透明です。解釈したり解析したりしないでください。
• signature の値はプラットフォーム間（Claude API、Amazon Bedrock、Google Cloud）で互換性があります。あるプラットフォームで生成された値は別のプラットフォームでも機能します。

編集済み thinking ブロック

通常の thinking ブロックに加えて、Claude の推論の一部が安全上の理由で編集された場合、API は redacted_thinking ブロックを返すことがあります。redacted_thinking ブロックは、data フィールドに暗号化された thinking コンテンツを含み、読み取り可能なテキストはありません。

{
  "type": "redacted_thinking",
  "data": "..."
}

data フィールドは不透明で暗号化されています。通常の thinking ブロックの signature フィールドと同様に、ツールを使用した複数ターンの会話を続ける際は、redacted_thinking ブロックを変更せずに API に渡し返してください。

制限と機能の互換性

サンプリングパラメータ

Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5、Claude Mythos Preview、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、および Claude Sonnet 5 では、thinking が使用されているかどうかに関係なく、デフォルト以外の temperature、top_p、または top_k の値はすべてのリクエストで 400 エラーを返します。古いモデルでは、この制限は thinking がオンの間のみ適用されます。temperature と top_k は thinking と互換性がなく、top_p は 0.95 から 1 の間の値で許可されます。

レスポンスのプリフィルと強制ツール使用

thinking がオンの間は、アシスタントのレスポンスをプリフィルできません。強制ツール使用（tool_choice: {"type": "any"} または {"type": "tool", ...}）は手動の拡張思考とは互換性がありませんが、アダプティブ思考では機能します。例外は Claude Fable 5.1 と Claude Mythos 5.1 で、これらはすべてのリクエストで強制ツール使用を 400 エラーで拒否します。これらのモデルでは、代わりに tool_choice: {"type": "auto"} を厳密なツール使用または構造化出力とともに使用してください。ツール使用を伴う思考を参照してください。

出力制限

各モデルは、ここに記載された上限までの max_tokens を受け入れます。Message Batches API では、output-300k-2026-03-24 ベータヘッダーにより、バッチの上限が記載されているモデルについてその上限が引き上げられます。

レガシーモデルの制限については、モデル概要を参照してください。

長時間のリクエスト

SDK は、長時間実行されるリクエストでの HTTP タイムアウトを避けるため、max_tokens が 21,333 を超える場合にストリーミングを必須とします。これはクライアント側のバリデーションであり、API の制限ではありません。イベントを逐次処理する必要がない場合は、.stream() を .get_final_message()（Python）または .finalMessage()（TypeScript）とともに使用して、個々のイベントを処理せずに完全な Message オブジェクトを取得してください。メッセージのストリーミングを参照してください。thinking ブロックの生成には処理時間が追加されるため、thinking が有効な場合はレスポンス時間が長くなることを想定してください。リクエストあたりの thinking がおよそ 32k トークンを超えるワークロードでは、ネットワークの問題を避けるためにバッチ処理を使用してください。そのようなリクエストは、システムタイムアウトやオープン接続数の制限に達するほど長時間実行される可能性があります。

次のステップ