推論モデルの比較
推論モデルは、答える前に考えることに追加の計算を費やします — 私的な中間ステップの連鎖を生成し、その後に最終的な応答を出します。これは今日のあらゆる主要 AI において、難問の精度を左右する単一で最大のレバーです。落とし穴は、すべてのプロバイダーが同じ発想を異なるつまみで公開していること、そして使いすぎが何の利得もないままお金とレイテンシを浪費することです。このレッスンは、Claude、GPT、Gemini、DeepSeek、Qwen にまたがってスキルが転移するよう、それらのつまみを横並びにマッピングします。
- テスト時計算(思考)が何をもたらし、何をもたらさないかを説明する
- 各プロバイダーの推論制御をマッピングする:Claude の effort、OpenAI の reasoning.effort、Gemini の thinkingBudget/thinkingLevel、DeepSeek の reasoner、Qwen の enable_thinking
- すべてを最大に既定するのではなく、タスクに応じて思考の深さを選ぶ
- 各 API で推論トレースを正しく読み戻し、それを入力として戻さない
- よくある罠を避ける:考えすぎ、無効化できないモデル、エフォートを品質の修正と勘違いすること
一つの発想:思考はスイッチではなくダイヤル
すべての推論モデルは同じトレードオフの上に乗っています:
- 思考が少ない → 速く、安い。抽出、整形、単純な Q&A に適する。
- 思考が多い → 本当に難しい問題(多段の数学、厄介なデバッグ、慎重な証明)でより良い、ただしレイテンシとコストは高い。
人々をつまずかせる罠:もともと簡単だったタスクには、追加の思考は何もしません — レイテンシとコストを払うだけです。スキルは、答えを変えるところに深さを使うことです。その真実は以下のすべてのモデルで同一であり、変わるのはダイヤルの名前だけです。
これは Claude 固有の 拡張思考とエフォート レッスンの、AI を横断する兄弟分です — Claude Messages API の詳細はそちらを読んでください。
ステップ 1 — つまみに触れる前にタスクを分類する
- 抽出、再整形、分類、短い事実の照会 → 最小限、または思考なし。思考は役立たず、レイテンシを増やすだけ。
- 通常のコーディング、下書き、複数段落の分析 → 中/ダイナミック。あらゆるプロバイダーでのバランスのとれた既定値。
- 競技数学、微妙な競合状態のデバッグ、長い証明、難しいエージェント的計画 → 高/大きなバジェット。ここで思考がそのコストに見合う。
- プロバイダーの中/ダイナミックの既定値から始め、品質が目に見えて要求するところでだけエフォートを上げる。
- 高いエフォートは曖昧なプロンプトの修正ではない — より明確な仕様の方が、たいてい多くの思考に勝る。
ステップ 2 — つまみ、プロバイダーごとに
同じダイヤル、5つの異なる制御面。ワークロードをモデル間で移すときに開いておくべき表です。
| プロバイダー/モデル | 制御 | 値 | 思考を無効化できる? |
|---|---|---|---|
| Claude(拡張思考) | effort ティア(新しいモデルは深さを適応;古いものは budget_tokens を公開) | Low / Medium / High | はい、ほとんどで — 低いティアを使うか思考を省く |
| OpenAI GPT‑5.5 / o シリーズ | reasoning.effort | minimal、low、medium(既定)、high、xhigh(GPT‑5.5 / Codex‑Max) | minimal は推論トークンをほとんど/まったく出さない |
| Google Gemini 2.5 | thinkingBudget | トークン数;0 で無効化;-1 = ダイナミック(上限約 8,192);2.5 Pro は 128–32768 または -1 が必要 | ほとんどの 2.5 モデルで 0 |
| Google Gemini 3 | thinkingLevel(thinkingBudget と併用しない) | 段階的なレベル | いいえ — Gemini 3.1 Pro は無効化できない |
DeepSeek R1(deepseek-reasoner) | 専用 reasoner — 常に考える | n/a(オープンウェイト、ローカルで動く) | いいえ — 思考専用モデル |
| Qwen3 | enable_thinking(ハイブリッド)+ /think · /no_think ソフトスイッチ | オン/オフ、ターンごとに切替 | はい — enable_thinking=False または /no_think |
- 一部のモデルはオフスイッチを取り除く:Gemini 3.1 Pro と DeepSeek R1 は常に考える。そのレイテンシ/コストを織り込むこと — ゼロにはダイヤルできない。
- Gemini 3 では、1つのリクエストで thinkingLevel と thinkingBudget の両方を設定するとエラーになる。どちらか一方を選ぶ。
- Gemini のダイナミックモード(-1)は思考を約 8,192 トークンで上限する — ほとんどの作業には十分だが、最も難しい問題では硬い天井になる。
2つの系統
表を上から下へ読むと、モデルは2種類に分かれます — どちらを手にしているかを知れば、何を期待できるかが分かります:
- ハイブリッド/切替式(Claude、OpenAI、Gemini 2.5、Qwen3):1つのモデルで、リクエストごとに思考を上げ下げ — またはオフに — できる。一部の呼び出しが些末で一部が難しい混合トラフィックに最適。
- 専用 reasoner(DeepSeek R1;実運用上は Gemini 3.1 Pro):モデルは常に推論する。整形や抽出をここにルーティングしない — すべての呼び出しで思考税を払うことになる。簡単なトラフィック用に安価な非思考モデルをローテーションに残しておくこと。
ステップ 3 — 推論トレースを正しく読む
すべてのプロバイダーは思考を答えとは別に返します — そして普遍的なルールは、次のターンで推論をそのまま入力として貼り戻さないことです。戻すのは最終的な答えだけ(加えて、Claude ではツールループのために API が手渡す署名付き思考ブロック)。
- 応答は思考ブロックに続いてテキストブロックとして届く。message.content を反復し、block.type で分岐する。
- 推論は reasoning items / summary に存在する;全文は見えないが推論トークンに課金される。生の推論を再送するのではなく、response の状態を永続化する。
- includeThoughts を設定して思考の要約を取得する;思考トークンは課金され、usage メタデータに報告される。
- トレースは content とは別に reasoning_content フィールド(旧ビルド)または reasoning として返る。生のウェイトでは <think> と </think> タグの間のテキスト。
Same task, three dials — pseudo-config you can adapt
# Claude — balanced
thinking = {"type": "enabled", "budget_tokens": 8000} # keep < max_tokens
# OpenAI — balanced
reasoning = {"effort": "medium"}
# Gemini 2.5 — let the model decide
thinking_config = {"thinking_budget": -1} # dynamic; 0 to disable
# Qwen3 (local) — turn thinking OFF for a trivial call
chat_template_kwargs = {"enable_thinking": False}ステップ 4 — 思考を使うべきでないとき
高くつく間違いは、すべてを最大に既定することです。次のときは思考をスキップまたは最小化します:
- タスクが機械的(抽出、再整形、分類、既知の文字列の翻訳)。
- 厳しいレイテンシ予算のもとにある(チャット UI、オートコンプリート) —
minimal/0//no_thinkを使う。 - プロンプトが仕様不足 — 曖昧なタスクでの思考の増加は、より良い答えではなく自信ありげな彷徨を生む。まず仕様を直す。
- 大量バッチの作業で、数ポイントの精度が何百万回もの呼び出しにわたってトークン代を倍増させるほどの価値がない。
- 経験則:思考が報われるのは、問題に検証可能な正解があり、それが互いに依存する複数のステップを要するとき。単一の正しい道がない自由生成にはほとんど報われない。