推論と思考

モデルに「まず考え、次に答えよ」と指示する——推論時に、事前学習で重みに圧縮された直感に頼るだけでなく、分解、試行錯誤、自己検証のために多くの計算リソースを費やす。adaptive thinking と effort は、思考の深さを手動で指定するトークン数から、セマンティックな段階へと変化させる。

概要

モデルに「まず考え、次に答えよ」と指示する——つまり、⁠推論時(test-time)⁠に、事前学習で重みに圧縮された直感に頼るだけでなく、分解、試行錯誤、自己検証のために多くの計算リソースを費やす。このアプローチは、Chain-of-Thought(2022年、モデルに推論過程を記述させることで数学や推論の精度が大幅に向上)から推論モデル(reasoning models)⁠へ、さらに Claude の adaptive thinking へと進化してきた。モデルが自ら「いつ、どの深さまで考えるか」を決定する。これを理解することは、「速くて安い」と「正確で安定した」のバランスを適切に調整する鍵であり、これは コンテキストエンジニアリング において、トークン予算の変動が最も大きくなる変数でもある。

直感的な理解：⁠計算リソースは訓練時にも、推論時にも費やすことができる⁠。同じモデルであっても、回答前に「考える」時間を許容することは、推論時に検索や検証のためにより多くの計算を投入することに等しい。多段階の推論や agentic な長時間タスクにおいては、これは明確な精度向上をもたらすが、単純なクエリでは純粋な無駄となる。したがって、現代のアプローチは「常に深く考える」または「全く考えない」のではなく、⁠タスクの難易度に応じて思考量を動的に割り当て⁠、全体を制御するマスタースイッチを残すことである。

メカニズム: thinking block とその有用性

思考を有効にすると、レスポンスの最初に thinking block(モデルの内部推論) が現れ、その後に text(ユーザーへの回答) が続く:

flowchart LR
    Q["入力"] --> TH["thinking block<br/>分解 → 試行錯誤 → 自己検証"]
    TH --> A["text block<br/>最終回答"]

「考える」ことが品質を向上させる理由は、以下の3つのアクションに分解できる:

• 分解⁠: 難問を一つずつ解決可能な小さなステップに分解し、単一ステップでのエラー発生率を低下させる。
• 検索/試行錯誤⁠: 思考の中で複数の経路を試して比較し、一発で正解を出そうとしない。
• 自己検証/確認⁠: 制約条件と照らし合わせて中間結論を再確認する(特にコードや数学において)。

具体的な例として、「27 × 453」を解く場合、直接回答すると桁ずれを起こしやすい。しかし、thinking ブロック内では、⁠分解して 27×400 + 27×53 に分け、⁠試行錯誤的に 27×53 をさらに 27×50+27×3 に分解し、最後に自己検証として 10800+1431=12231 を掛け合わせて確認する。同じ3つのステップが、コード記述(まず境界条件を列挙し、いくつかの実装を試してから要件と照合して再確認する)や多段階計画でも行われる。これが、Chain-of-Thought が推論を「明示的に書き出す」だけで大幅なスコア向上をもたらす理由である: 一発で正解を出す確率に賭けるのではなく、各ステップで高い確実性を持つ小さな賭けに置き換えるのである。

代償も現実的である:⁠トークン数を多く消費し、レイテンシが増加する⁠。したがって、「どの程度考えるか」は制御可能でなければならず、それが effort と thinking 制御が存在する理由である。

Claude の思考制御(現在の API 動作)

最新の Claude(Opus 4.6+)は adaptive thinking を使用し、手動で思考予算を入力する必要がなくなった:

thinking = {"type": "adaptive", "display": "summarized"}   # アダプティブ + 要約表示
output_config = {"effort": "high"}                         # マスタースイッチ

effort: 深さを制御するマスタースイッチ

effort ∈ {low, medium, high, xhigh, max} (xhigh は Opus 4.7 で追加され、high と max の間)、デフォルトは high:

effort が高いほど、モデルはより多く考え、より多く探索し、より多くのツールを呼び出す傾向がある——これにより、「思考の深さ」はトークン数からセマンティックな段階へと変化する。

thinking の可視性: デフォルトでは原文は表示されない

• display デフォルトは omitted(Opus 4.7/4.8、Fable 5): thinking block はレスポンスに含まれるが、thinking フィールドは空文字列である。ユーザーに推論を表示するには、display: "summarized" を設定して要約を取得する必要がある。
• 生思考チェーン(raw CoT)は返されない⁠——取得できるのは最大でも要約であり、逐語的な推論ではない。
• ストリーミング UX の落とし穴⁠: omitted の場合、ストリーミングは「長時間の停止の後に突然文字が表示される」ように見える(実際は思考中)。進行状況を表示するには、明示的に summarized を設定する。

複数ターンでの処理: thinking block はそのまま返す

これは最も陥りやすいエンジニアリングの落とし穴である。複数ターン対話やエージェントループにおいて、前回の thinking block をフィードバックする際は:

• 同じモデルでの継続⁠: そのまま返す⁠(署名 signature を含み、空のテキストブロックであってもそのまま)。API は変更されたブロックを拒否するが、読まれたブロックは拒否しない——要約の表示は問題ないが、ブロックの編集や再構築は 400 エラーとなる。
• モデルの切り替え⁠: 他のモデルを使用する場合、API は自動的に前世代(例: Fable 5)の thinking block をプロンプトから削除する⁠(通常、非表示で行われ、課金前に削除されるため課金されない)——通常の thinking ブロックを手動で削除しないでください。そうしないと、順序や署名に関する 400 エラーが発生する可能性がある。

交互型思考とタスク予算

• interleaved thinking: adaptive モードでは、⁠ツール呼び出しの間にも思考が行われる(実行しながら考える)。追加のヘッダーは不要——これはエージェントループにとって特に重要である(各 tool_result の取得後に再思考するため)。
• task budget(beta task-budgets-2026-03-13): 全体のエージェントループにトークン予算を割り当て、⁠モデルは残り時間を確認し、自ら終了できる⁠。これは max_tokens とは異なる:

考えるべきか、考えるべきでないか: effort をスキャンすべき次元として扱う

反射的に xhigh/max に引き上げないこと。より強力なモデルはより高い知能の上限を持つため、high で始め、自前の評価セットで medium/high/xhigh をスキャンして決定する⁠——関係は単調ではない: エージェントタスクでは、高い effort がターン数を減少させ、結果としてより節約になる場合が多い。一方、特定のタスクでは medium でも同様の品質が得られ、より高速である(評価については 評価と観測 を参照)。

移行時のヒント: 旧モデルでは temperature で「創造性」を調整していた考え方を、新モデルでは effort で「思考の深さ」を調整するように変更する——サンプリングパラメータは削除された(「トークンとサンプリング」参照)。

ベストプラクティス

• 手動で予算を入力せず、adaptive thinking を使用する。 最新の Claude は適応的に思考の深さを調整する。Opus 4.7/4.8/Fable 5 で手動の budget_tokens を指定すると、直接 400 エラーとなる。
• effort は high で始め、評価に基づいて段階を決定する。 関係は非単調——エージェントタスクでは高い effort がターン数を減らし、結果として節約になる場合が多く、特定のタスクでは medium でも同様の品質が得られ、より高速である。
• タスクに応じて effort の開始点を設定する。 分類/抽出→low; 数学/計画→high; 長時間のエージェント/コーディング→high~xhigh、大きな max_tokens とストリーミングを併用; 正確性がコストより優先→max(空回りに注意)。
• ユーザーに推論を表示するには display:"summarized" を設定する。 デフォルトの omitted では、ストリーミングが「長時間の停止の後に突然文字が表示される」ように見える。
• 複数ターンでは thinking block をそのまま返す。 同じモデルでの継続では署名を含めてそのまま返す、モデルの切り替えでは API に自動削除を任せる、手動で削除しない。
• 過度な思考/探索の場合は、まず effort を下げ、プロンプト制約を追加しない。 medium が多くの場合、スイートスポットである。

トレードオフと失敗パターン(プロンプト修正付き)

• overthinking(過剰思考): 単純なタスクで高い effort を使用すると、空回りでトークンを消費する → まず effort を下げる⁠( medium が多くの場合、スイートスポット)、プロンプト制約を追加しようとするな。必要に応じて抑制するには追加する: "思考はレイテンシを増加させるため、多段階推論が本当に必要な場合にのみ深く考え、確実な場合は直接回答すること。"
• 過度な探索 / 過度な委任⁠(エージェントシナリオ): 高い effort では、探索やサブエージェントの作成を好む傾向がある → effort を下げるか、明確な境界を設ける。
• 思考がフリーズしたと認識される⁠: omitted の場合、フロントエンドは応答がないように見える → display: "summarized"。
• 複数ターンでブロック消失⁠: thinking block を手動で変更/削除すると 400 エラーが発生する → 同じモデルでは署名を含めてそのまま返し、モデルの切り替えでは API に自動削除を任せる。
• thinking:{type:"disabled"} で冗長になる⁠: 思考を無効化すると、モデルが推論を可視本文に書き込む可能性がある → adaptive を残すか、"最終回答のみを出力し、中間推論は含めないこと。" を追加する。

参考

• Anthropic 公式ドキュメント⁠: Extended Thinking、Adaptive Thinking、Effort、Task Budgets、Migration Guide(platform.claude.com)
• 論文⁠: "Chain-of-Thought Prompting Elicits Reasoning in LLMs"(Wei 2022)

Keywords: chain-of-thought, CoT, reasoning model, test-time compute, extended thinking, adaptive thinking, effort, low, medium, high, xhigh, max, thinking block, signature, display, summarized, omitted, raw CoT, interleaved thinking, task budget, max_tokens, multi-turn echo-back, budget_tokens deprecated, overthinking