
OpenAI・Claude・Gemini の推論量制御パラメータを比較する — reasoning_effort / budget_tokens / thinkingLevel の設計思想
はじめに
LLM の「考える量」を制御したい場面は多い。簡単な質問にはサッと答えてほしいし、複雑な推論にはじっくり考えてほしい。
OpenAI の o-series で reasoning_effort を使っていたとき、ふと疑問が浮かんだ。「同じことを Claude や Gemini でやるにはどうすればいい?パラメータ名は?粒度は?」
調べてみると、3社それぞれ異なる設計思想で推論量制御を実装していることがわかった。
3社の推論量制御パラメータ
OpenAI o-series: reasoning_effort
{
"model": "o4-mini",
"reasoning_effort": "high"
}
- 指定値:
low/medium/highの3段階 - シンプルで迷いが少ない
- 内部のトークン数はモデル任せ
Claude (extended thinking): budget_tokens
{
"model": "claude-opus-4-6",
"thinking": {
"type": "enabled",
"budget_tokens": 8192
}
}
- 指定値: トークン数(最低1024)
- 上限は
max_tokens以下 - 開発者が推論コストを精密に管理できる
Gemini 3.0+: thinkingLevel
{
"model": "gemini-3.0-pro",
"generationConfig": {
"thinkingConfig": {
"thinkingLevel": "high"
}
}
}
- 指定値:
none/low/medium/highなどのレベル - Gemini 2.5 時代の
thinkingBudget(トークン数指定)からレベル指定に移行 - 内部でモデルが適切なトークン数に変換
比較表
| 観点 | OpenAI o-series | Claude (extended thinking) | Gemini 3.0+ |
|---|---|---|---|
| パラメータ名 | reasoning_effort |
thinking.budget_tokens |
thinkingConfig.thinkingLevel |
| 指定方式 | レベル(3段階) | トークン数 | レベル |
| 最小値 | low |
1024 tokens | none(思考OFF) |
| 最大値 | high |
max_tokens まで |
high |
| コスト予測 | 粗い | 精密 | 粗い |
| 開発者の制御度 | 低い | 高い | 低い |
設計思想のスペクトラム
3社を「制御の粒度」で並べると、明確なスペクトラムが見える。

OpenAI: 「開発者は考えなくていい」派
3段階だけ。迷う余地がない。モデルを信頼して「どれくらい考えるか」はモデルに任せる設計。
向いている場面: プロトタイピング、推論コストの厳密な管理が不要なケース
Gemini: 「レベルで十分」派
OpenAI に近いが、none(思考完全OFF)を含むためスペクトラム上では少し中間に位置する。さらに Gemini 2.5 で一度トークン数指定(thinkingBudget)を実装したが、3.0 でレベル指定に戻した点が興味深い。細かい制御を試した上で「レベルで十分」と判断した経緯がある。
向いている場面: 思考の ON/OFF を切り替えたいケース、レベルベースで十分なケース
Claude: 「開発者が精密に管理する」派
トークン数で直接指定。推論に使うトークン数の上限を開発者がコントロールできるため、コスト予測が最も正確。
向いている場面: 本番環境でのコスト管理、推論量とレイテンシのトレードオフを細かく調整したいケース
実務での使い分け
| ユースケース | 推奨設定 |
|---|---|
| チャットボット(簡単な質問応答) | OpenAI: low / Claude: 1024-2048 / Gemini: low |
| コード生成・分析 | OpenAI: medium / Claude: 4096-8192 / Gemini: medium |
| 複雑な推論・数学・論理問題 | OpenAI: high / Claude: 16384+ / Gemini: high |
| 推論不要(単純な変換・抽出) | Gemini: none / Claude: thinking 無効 / OpenAI: N/A |
まとめ
- 3社とも「推論量の制御」を提供しているが、設計アプローチが異なる
- コストを精密に管理したい → Claude の
budget_tokensが最適 - シンプルに使いたい → OpenAI の
reasoning_effortか Gemini のthinkingLevel - 思考自体を OFF にしたい → Gemini の
noneが明示的
マルチモデル対応のアプリケーションを作る場合、この3つのパラメータの違いを抽象化するラッパーを設計すると、モデル切り替えが楽になる。








