思考のステアリング

Claudeの思考は適応的です。モデルは各リクエストを評価し、思考するかどうか、どの程度思考するかを自ら決定します。あなたは意図を設定し、必要に応じてeffortを指定し、モデルは推論が役立つと判断した箇所に推論を割り当てます。

これにより、思考は、単純なリクエストと複雑なリクエストが混在するワークロードや、ステップごとに適切な推論量が変化する長期的なエージェントワークフローに非常に適したものになります。

思考を有効にする方法、思考出力の読み方、およびClaude Fable 5とClaude Mythos 5での思考出力については、思考の概要を参照してください。このページでは、Claudeがいつ思考するかをどのように決定するか、その決定をどのようにステアリングするか、そしてそれに伴うキャッシング、コスト、料金の仕組みについて説明します。



Claudeが思考するタイミングをどのように決定するか

思考はモデルにとって任意です。各リクエストにおいて、Claudeは入力の複雑さを評価し、より深い推論が回答を改善するかどうかを判断します。単純な事実に関する質問には思考ブロックなしで直接応答する場合があります。複数ステップの数学問題や難しいデバッグタスクは、より深い推論を引き起こします。

この決定はリクエストごとに行われます。同じ会話に思考ありのターンと思考なしのターンが混在する可能性があり、Claudeが思考しないことを選択したターンには思考ブロックが含まれません。すべてのアシスタントターンが思考ブロックで始まることを前提としたアプリケーションロジックを構築しないでください。

この決定に対する主要な制御はeffortパラメータであり、Claudeがどの程度積極的に思考すべきか、どの程度深く思考すべきかについてのソフトなガイダンスとして機能します。各レベルの動作については、このページのEffortレベルを参照してください。

Claudeに思考の頻度を減らしてほしい場合は、プロンプトベースのステアリングに頼る前に、effortレベルを下げてください。

思考はツール使用とも自動的にインターリーブされます。Claudeはツール呼び出しの間に思考し、各ツール結果を振り返ってから次に何をするかを決定できます（インターリーブ思考）。これにはベータヘッダーや追加の設定は必要ありません。

思考の設定とeffortパラメータがどのように相互作用するかの全体像については、思考とeffortを参照してください。



Claudeが思考する頻度のステアリング

Claudeが特定のターンで思考するかどうかは、プロンプトで制御できます。effortが全体的な姿勢を設定しますが、システムプロンプトでグローバルに、またはユーザーターンからメッセージごとに、自然言語のガイダンスで決定を直接形作ることもできます。

この2つのレバーを次の順序で併用してください。

1. ワークロードのデフォルトの品質とレイテンシのバランスに合ったeffortレベルを設定します。
2. そのレベルでもClaudeの思考のトリガーがニーズに合わない場合にのみ、プロンプトによるガイダンスを追加します。

思考に関するより広範なプロンプトのガイダンスについては、思考とインターリーブ思考の機能を活用するを参照してください。



Effortレベル

effortは思考に対する主要なステアリングレバーです。各レベルは、Claudeが思考する頻度と深さについて異なるデフォルトを設定します。

この表は、各レベルが思考の動作をどのように変えるかを説明しています。モデルごとの推奨事項を含め、特定のワークロードに対してどのレベルを選択すべきかのガイダンスについては、effortページのeffortパラメータを調整するタイミングを参照してください。

effortはthinkingオブジェクト内ではなく、output_config.effortで設定します。言語ごとの完全な例については、Effortを参照してください。

{
  "model": "claude-opus-4-8",
  "max_tokens": 4096,
  "output_config": { "effort": "medium" },
  "messages": [{ "role": "user", "content": "..." }]
}

レベルの利用可否はモデルによって異なります。各モデルがサポートするレベルについては、effortページのeffort利用可否テーブルが正式な情報源です。



システムプロンプトによるガイダンス

システムプロンプトによるガイダンスは、会話内のすべてのリクエストに対してClaudeの思考のしきい値を変化させます。Claudeがワークロードに必要な頻度よりも多く思考している場合は、次のようなガイダンスをシステムプロンプトに追加してください。

Extended thinking adds latency and should only be used when it
will meaningfully improve answer quality, typically for problems
that require multistep reasoning. When in doubt, respond directly.

逆に思考を促すには、次のようなフレーズを使用します。

This task involves multistep reasoning. Think carefully before responding.

ステアリングの効果は、正確な言い回しに敏感な場合があります。ある言い回しで望む動作が得られない場合は、より直接的なバリエーションを試してください。



メッセージごとのステアリング

システムプロンプトとは独立して、ユーザーターンからメッセージごとに思考をステアリングすることもできます。ユーザーメッセージに"Please think hard before responding."を追加すると、そのターンでClaudeが思考するよう促されます。"Answer directly without deliberating."は思考を抑制します。

メッセージごとのステアリングは、会話内の一部のリクエストのみが拡張された推論を必要とする場合に便利です。たとえば、エージェントハーネスは、システムプロンプトに触れたりターン間でリクエストパラメータを変更したりすることなく、計画ステップでは思考を促すフレーズを、定型的な確認では思考を抑制するフレーズを追加できます。



ワークロードでステアリングを検証する

プロンプトベースのステアリングはモデルの動作を変えるため、他のプロンプト変更と同様に扱ってください。つまり、リリース前に測定します。ガイダンスありとなしでトラフィックの代表的なサンプルを実行し、思考がトリガーされる頻度（レスポンス内の思考ブロックの有無）、出力トークンの使用量、レイテンシ、そして重要なケースでの回答品質を比較してください。



仕組み

Claudeが自身の思考を管理することから、3つの仕組みが生じます。ターンの検証、プロンプトキャッシング、そしてコストの制限方法です。



ターンの検証

アシスタントターンは思考ブロックで始まる必要はありません。（レガシーの手動思考バジェットを使用するモデルでは、思考が有効なリクエストの最後のアシスタントターンが思考ブロックで始まることが強制されます。手動モードでのターン構造を参照してください。）

マルチターンアプリケーションの場合、これは会話履歴を手元にある形のまま渡せることを意味します。

• Claudeが思考しないことを選択したアシスタントターンは、そのままで有効な履歴です。
• 思考なしで始まった会話や、異なる思考設定を使用していた会話を、履歴を書き換えることなく再開できます。
• 複数のソースから組み立てられた履歴は、検証を通過するために各アシスタントターンの先頭に思考ブロックを再挿入する必要はありません。

この緩和は検証に関するものであり、何を送信すべきかに関するものではありません。思考ブロックがある場合は、変更せずにそのまま渡してください。特にツール使用中は、思考ブロックがClaudeのツール呼び出しの背後にある推論を保持しています。完全なルールについては、思考の概要を参照してください。



プロンプトキャッシング

同じ思考設定とeffortレベルを維持する連続したリクエストは、プロンプトキャッシングを保持します。完全なルールについては、思考とプロンプトキャッシングを参照してください。解決されたeffort値はプロンプトにレンダリングされるため、リクエスト間でそれを変更するとキャッシュブレークポイントが無効になります。これは、レガシーのbudget_tokensパラメータを使用するモデルでそれを変更した場合と同様です。effortをモデルのデフォルトに明示的に設定することは、省略することと同等であり、キャッシュを破壊しません。

実用上の帰結は次のとおりです。会話ごとに思考設定とeffortレベルを選択し、それを維持してください。一部のターンでより多くの、またはより少ない思考が必要な場合は、メッセージごとのプロンプトでステアリングしてください。最新のユーザーメッセージに追加されたガイダンスは、それ以前のキャッシュブレークポイントをそのまま維持しますが、設定やeffortの変更はそうではありません。

次の例は、自分で実行できるマルチターンスクリプトで無効化を実演します。



コスト制御

思考トークンのバジェットを設定することはありません。2つの制御がコストを制限します。

• max_tokensは、思考とレスポンステキストを合わせた、リクエストの総出力に対するハードキャップです。Claudeがこれを超えて生成することはありません。ツール使用ループでは、ターン内の各リクエストがそれぞれ独自のmax_tokensを持つため、ターン全体の支出を制限するものではありません。
• effortは、その出力のうちどれだけをClaudeが思考に割り当てるかについてのソフトなガイダンスです。動作を形作りますが、トークン数を保証するものではありません。

思考はmax_tokensにカウントされるため、推論と回答の両方に十分な余地を残せるよう、十分に高く設定してください。思考なしのレスポンス向けにサイズ設定されたmax_tokensは、Claudeが難しいリクエストで思考を始めると、小さすぎることがよくあります。

high以上のeffortでは、Claudeは広範囲に思考する可能性があり、バジェットを使い切る可能性が高くなります。レスポンスにstop_reason: "max_tokens"が表示される場合、2つの対処法があります。

• max_tokensを引き上げて、思考と回答のためにモデルにより多くの余地を与える。
• effortレベルを下げて、Claudeの思考を減らし、バジェットのより多くをレスポンステキストに残す。

どちらが正しいかは、切り詰められたレスポンスがその推論を必要としていたかどうかによります。それらのリクエストの品質が重要な場合は、上限を引き上げてください。過剰に思考していた場合は、effortを下げてください。



料金

思考では以下に対して料金が発生します。

• Claudeが思考中に使用するトークン（出力トークンとして課金）
• 保持のデフォルトに従ってコンテキストに残る、以前のアシスタントターンの思考ブロック。すべて保持するモデルではデフォルトですべてのターン、それ以外では最後のターンのみ（入力トークンとして課金）
• 標準のテキスト出力トークン

課金対象はdisplay設定に関係なく同じです。変わるのは表示される内容だけです。

内部推論に費やされた課金対象の出力トークン数を確認するには、レスポンスのusage.output_tokens_details.thinking_tokensを読み取ってください。この値は、モデルが生成した生の推論（本文で返される要約テキストではありません）を反映しており、常にoutput_tokens以下です。output_tokensからこれを引くと、出力のうち推論以外の部分を概算できます。ストリーミング時には、この内訳は最後のmessage_deltaイベントにのみ表示されます。

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 348,
    "output_tokens_details": {
      "thinking_tokens": 312
    }
  }
}

output_tokensは、課金に使用される包括的で正式な合計のままです。output_tokens_detailsは可観測性のための読み取り専用の内訳です。基本料金、キャッシュ書き込み、キャッシュヒット、出力トークンを含む完全な料金情報については、料金を参照してください。



次のステップ