推論と thinking

モデルに「考えてから答えさせる」——推論時に計算資源をより多く費やし、分解、試行錯誤、自己検証を行い、事前学習で重みに圧縮された直感だけに頼らない。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 と task budget

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

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

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

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

ベストプラクティス

• adaptive thinking を使用し、予算を手動で入力しない。 最新の Claude は思考の深さを適応的に調整する; Opus 4.7/4.8/Fable 5 で手動の budget_tokens を設定すると直接 400 エラーになる。
• effort は high で始め、評価に基づいて段階をスキャンして決定する。 関係は非単調——agentic タスクでは高い effort が往々にしてターン数を減らし結果として節約になり、特定のタスクでは medium でも同等に良好で高速である。
• タスクに応じて effort の開始点を与える。 分類/抽出→low; 数学/計画→high; 長時間 agentic/コーディング→high~xhigh、大きな max_tokens とストリーミングを併用; 正確性がコストより優先→max(空回りを警戒)。
• ユーザーに推論を表示する場合は display:"summarized" を設定する。 デフォルトの omitted ではストリーミングが「長時間の停止の後に突然文字が表示される」ように見える。
• 複数ターンでは thinking block をそのまま返す。 同一モデルの継続では署名付きでそのまま; モデル変更時は API に任せて削除させ、手動で strip しない。
• 過度な思考/探索の場合はまず 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