3行でいうと
- 推論時の計算を増やす方法は、「1回の答えの中で長く考える」「何度も答えさせて集計する」「答えを検証して選ぶ・探索する」の3つに分けると整理しやすくなります。これは論文の分類そのものではなく、僕らの整理です。
- 3社の公式文書で、パラメータとして用意されているのは主に「長く考える」の強さ（
reasoning.effort、thinking_level、effort、budget_tokens）でした。何度も答えさせて選ぶ部分は、読んだ範囲では、アプリ側で組む前提に見えます。 - 何度も答えさせる方法は、答え合わせができる分野（プログラムのテストなど）で強く、できない分野では、多数決や報酬モデルによる選び方が数百回で頭打ちになると、論文のアブストラクトに書かれています。
この記事は、実際に使って確かめた記録ではありません。この記事は、公式の文書と論文の公式ページ（arXiv）を読んでまとめたものです。論文は、アブストラクトのページだけを読んでいます。数字と仕様は2026年10月16日に確認しました。変わることがあります。
先に結論
- 「推論時の計算」とは、AIが答えを出す段階で使う計算量です。AIを作る段階（訓練）の計算量と区別して、そう呼びます。
- 方法は、僕らの整理では3つです。(1) 1回の答えの中で長く考えさせる（直列）。(2) 同じ問いに何度も答えさせて、集計する（並列）。(3) 答えを検証する仕組みを足して、選ぶ、または探索する（検証）。
- どの方法が合うかは、問いの難しさと、答え合わせができるかで変わります。Snellらの論文は、最適な方法は問いの難しさに強く左右される、と書いています。
- 費用は、方法を重ねるほど掛け算で増えます。公式文書は、考えた分のトークンも出力として課金される、と書いています。
前提：何を「増やす」のか
「推論時の計算を増やす」は、AIの本体（重み）を変えずに、答えを出す段階で使う計算を増やして、品質を上げようとする考え方です。論文の用語では、test-time computeやinference computeと呼ばれます。
ここでは、3つの方法を同じ軸で比べます。
| (1) 長く考える（直列） | (2) 何度も答えさせて集計（並列） | (3) 検証して選ぶ・探索（検証） | |
|---|---|---|---|
| やること | 1回の答えの中で、考える文章を長くする | 同じ問いに複数回答えさせ、答えを集計する | 答えの良し悪しを判定する仕組みで、候補を選ぶ・絞る |
| 論文での例 | s1（Muennighoffら） | 自己一貫性（Wangら）、Large Language Monkeys（Brownら） | Snellら（過程を見る検証器での探索） |
| APIの設定 | あり（各社の思考の強さの設定） | 読んだ範囲では見つからず | 読んだ範囲では見つからず |
| 論文に数字がある課題 | 数学の競技問題（AIME24） | 算数・常識推論、プログラムの課題 | アブストラクトに課題名の記載なし |
| 主な限界 | 長ければよいとは限らず、効果は逓減する | 回数に比例して費用が増え、集計の方法が頭打ちになる | 検証器そのものの質に左右される |
表の「APIの設定」は、僕らが読んだ思考・推論のページに限った話で、「ない」とは断定できません。
(1) 長く考える：まず公式の設定を読む
論文：s1の「Wait」
s1の論文のページによると、著者らは、1,000問に推論の過程をつけたデータ（s1K）で学習させたモデルに、「予算の強制（budget forcing）」を組み合わせました。これは、思考を強制的に打ち切るか、モデルが止まろうとしたときに「Wait」を何度も付け足して、思考を延ばす方法です。結果として、AIME24（数学の競技問題）の正解率が、介入なしの50%から57%に上がった、とあります。
この数字は、特定のモデルと問題での値です。
公式のAPI：3社とも「強さ」を選ぶ形
3社の公式文書を読むと、どれも「思考の強さ」を段階で選ぶ設定を持っています。
| 社 | 設定 | 読んだ文書に書かれていた段階・値 |
|---|---|---|
| OpenAI | reasoning.effort |
none、minimal、low、medium、high、xhigh、max（モデルごとに使える範囲が違う） |
| Anthropic | output_config.effort（適応的思考と併用）、または手動のbudget_tokens |
effortはmax、xhigh、high、medium、low |
| Google（Gemini） | thinking_level |
minimal、low、medium、high（モデルごとに使える範囲が違う） |
Anthropicの文書には、手動の方式（thinking: {"type": "enabled", "budget_tokens": ...}）と、適応的な方式（thinking: {"type": "adaptive"}）の2つが載っています。新しいモデル（Claude 4.7以降）では、手動の方式を使うと400エラーになり、適応的な方式を使うよう書かれています。適応的な方式では、AIが、リクエストごとに「考えるか、どれだけ考えるか」を決めます。単純な質問では、考えずに答えることもあります。主な操作はeffortです。
長く考えるときの注意
- 上限と費用： 3社とも、考えたトークンも課金される、と書いています（OpenAIとAnthropicは出力トークンとして）。OpenAIは、出力の上限（
max_output_tokens）に達すると、見える答えが出る前に打ち切られて、考えた分だけ課金されることがある、と書いています。 - 強さは「目安」： Anthropicの文書は、effortを、厳密なトークンの予算ではなく、行動の目安だと書いています。
budget_tokensも、上限ではなく目標だと書かれています。 - 逓減する： Anthropicの文書は、予算を上げるほど深く考えられるが、効果は課題によって逓減し、遅延も増える、と書いています。
- 高い段階は、評価で確かめてから： OpenAIの文書は、
xhighは、評価で明確な利点が示せるときだけ使うように書いています。Anthropicの文書は、プロンプトで考える量を操作するときは、考えが出る頻度、出力トークン、遅延、品質を、実際の利用に近いリクエストで測ってから本番に出すように書いています。
(2) 何度も答えさせて集計する
自己一貫性：多数決
Wangらの論文のページによると、自己一貫性（self-consistency）は、1つの答えだけを取る貪欲な（最も確率の高い語を選ぶ）生成の代わりに、多様な推論の筋道を複数サンプリングして、最も一貫して出る答えを選ぶ方法です。思考の連鎖（CoT）のプロンプトに比べて、GSM8Kで+17.9%、SVAMPで+11.0%、AQuAで+12.2%、StrategyQAで+6.4%、ARC-challengeで+3.9%の改善が、アブストラクトに書かれています。ページには、この改善が絶対値の差か相対値かまでは書かれていません。
Large Language Monkeys：カバレッジと選別
Brownらの論文のページは、「カバレッジ（少なくとも1回は正解したサンプルがある問題の割合）」を指標にしています。サンプル数を増やすと、4桁にわたって、カバレッジが上がり続けた、とあります。プログラムの課題（SWE-bench Lite、DeepSeek-Coder-V2-Instruct）では、解けた割合が、1回の15.9%から、250回の56%に上がり、当時の1回あたりの最良の記録43%を上回った、と書かれています。
大事なのは、そのあとの限界の部分です。アブストラクトによると、プログラムのように、答えを自動で確かめられる分野では、カバレッジの向上が、そのまま性能の向上になります。一方、自動で確かめる手段がない分野では、多数決も報酬モデルも、数百サンプルを超えると頭打ちになり、サンプル数に見合って伸びません。
(3) 検証して選ぶ・探索する
Snellらの論文のページは、推論時の計算を増やす2つの仕組みを分析しています。(a) 密な（途中の段階ごとに点を付ける）、過程ベースの検証器である報酬モデルを使って、探索する。(b) プロンプトを与えられた状態で、答えの分布を、その場で適応的に更新する。どちらも、最適な方法は、問いの難しさに強く依存する、と書かれています。そこで、問いごとに計算を割り当てる「計算最適」な戦略を提案し、ベスト・オブ・N（N個作って、点が最も高いものを選ぶ）の基準に比べて、推論時の計算の効率が4倍より大きく改善した、と書かれています。さらに、計算量を揃えた比較で、小さなモデルが、ある程度は解ける問題では、14倍大きなモデルを上回る場合がある、とあります。
この論文のアブストラクトは、「改訂」（答えを書き直す方法）を独立した仕組みとして書いてはいません。(b)の言い換えで、そう読める、というのが僕らの理解です。詳しい中身は、本文を読んでいません。
実務では、検証器を自分で用意する場面が多いと思います。ただし、検証器の作り方は、僕らが読んだ3社の思考・推論のページには書かれていませんでした。
公式の設定と数値（2026年10月16日に確認）
OpenAIの推論ガイドによると、次のとおりです。
- 強さ：
reasoning.effort。値はnone、minimal、low、medium、high、xhigh、maxで、モデルごとに使える範囲が違います。GPT-6 Astraはnoneを設定すると400になる、GPT-6.1 Solはnoneとminimalを使えず、既定はmedium、と書かれています。 - モード：GPT-5.6などのモデルは、
reasoning.modeでstandardとproを選べます。proの中身（何をどれだけ増やすか）や課金の扱いは、読んだ範囲では確認できていません。 - トークン：考えたトークンは出力として課金されます。API経由では見えません。数百から数万トークンまでありうる、とあります。
max_output_tokensは、考えた分と見える出力の合計を抑えます。始めるときは、考えと出力のために、少なくとも25,000トークンの余裕を取ることが勧められています。
Anthropicの文書によると、次のとおりです。
- 手動の方式：
budget_tokensの最小は1,024。max_tokensより小さくする必要があります。目標であって厳密な上限ではありません。簡単な課題は1,024付近から始めて段階的に上げ、複雑な課題は16,000以上から始める、という目安が書かれています。32kを超える予算では、バッチ処理を使うことが勧められています。 - 適応的な方式：
thinking: {"type": "adaptive"}とoutput_config.effort。適応的な方式には、思考トークンの予算はありません。max_tokensが合計の出力の硬い上限で、effortは、出力のうち、どれだけを考えに回すかの、やわらかい指針です。 - 既定のeffort：多くのモデルで
high。Claude Opus 5.5とClaude Haiku 5.5はmedium。 - 課金：考えたトークンは出力として課金され、内訳は
usage.output_tokens_details.thinking_tokensで見られます。表示される思考の要約は、全体の考えの要約で、課金は全体に対して行われます。
Googleの文書によると、次のとおりです。
- 強さ：生成設定の
thinking_level。minimal、low、medium、high。モデルごとに使える段階と既定が違い、たとえばgemini-3.1-pro-previewは、既定がhighで、low、medium、highを使えます。動的な思考が既定で、リクエストの複雑さに応じて調整されます。 - 課金：出力トークンに、考えたトークンを加えた分です。課金は、返ってくる要約ではなく、全体の考えに対して行われます。
- 上限：
max_output_tokensは、考えと出力の合計の硬い上限で、考えている途中で達すると、incompleteになり、出力が途中切れや空になることがあり、考えた分は課金されます。費用や遅延を下げるときは、小さいmax_output_tokensではなく、thinking_levelを下げることが勧められています。
ここに書いたのは、公式ページに載っていた値です。この記事では、実行していません。
3つを、どう組み合わせるか
ここからは僕らの見立てです。公式が勧めている手順ではありません。
- 答え合わせが機械的にできるか、を最初に考える。 プログラムのテスト、計算の検算、決まった形式の判定など、正誤を自動で確かめられるなら、並列に何度も作らせて、確かめて選ぶ形が、論文の面でも有利に見えます。確かめられない問い（文章の質、方針の判断）では、多数決や報酬モデルで選んでも、頭打ちになる、とBrownらのアブストラクトが書いています。
- まず「長く考える」の強さを、評価で決める。 OpenAIとAnthropicの公式文書は、強い段階や考える量の操作を、評価や実測で確かめてから使うように書いています。最初から最強の段階にしないことが、費用と遅延を抑える近道だと思います。
- 何度も作らせるのは、最後に足す。 回数が増えるぶん、費用は単純に増えます。1回あたりの考えるトークンがN倍になるのではなく、N回分の出力トークンが、それぞれの考える分つきで課金されます。具体的な単価は、各社の料金ページで確認してください。この記事では、金額は扱いません。
よくある失敗
- 「長いほど良い」と思う。 Anthropicの文書は、効果が逓減すること、遅延も増えることを書いています。また、
max_tokensに達したときは、考えが必要だったなら上限を上げ、考え過ぎだったならeffortを下げる、と書いています。 - 上限が小さくて、考えているうちに切れる。 OpenAIもGoogleも、考えた分が上限に当たると、見える答えが出ないまま課金される場合がある、と書いています。
- 多数決を万能だと思う。 自己一貫性は、答えが1つに定まる問いに向いた方法です。自由な文章の問いでは、「最も多い答え」が、そもそも決まりません（これは見立てです）。
- 設定を途中で変えてキャッシュを壊す。 Anthropicの文書は、
budget_tokensやeffortを途中で変えると、プロンプトキャッシュが無効になると書いています。
気をつけること
- この記事は、実際に使って確かめた記録ではありません。内容は、公式の文書と論文のページの記載です。
- 論文は4本とも、arXivのアブストラクトのページだけを読みました。本文の実験の条件、ほかのモデルでの結果、失敗した場合の記述は確認していません。
- 公式ページは、WebFetchという取得の仕組みを通して読みました。この仕組みはページを要約して返すため、原文のままの引用ではなく、僕らが言い換えています。細部を取りこぼしている可能性があります。
- 3つの分類（直列・並列・検証）は、僕らの整理です。論文や公式文書が使っている分類ではありません。「APIの設定がない」と書いた部分は、読んだ思考・推論のページに見つからなかった、という意味で、ほかのページや別の機能にあるかは確認していません。
- モデル名、設定の値、既定、上限は、2026年10月16日に読んだ時点のものです。モデルごとに使える段階が違い、新しいモデルで古い設定が使えなくなることもあります。自分の使うモデルのページで確認してください。
- Googleの文書には、並列や検証に当たる機能の記述は見つかりませんでした。OpenAIのproモードの中身も、読んだ範囲では書かれていませんでした。
- 推論モデルの訓練の仕組みや、思考の課金の詳細は、別の記事で扱っています。
出典
- Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters（arXiv 2408.03314、Snellら、10月16日確認）
- Self-Consistency Improves Chain of Thought Reasoning in Language Models（arXiv 2203.11171、Wangら、10月16日確認）
- Large Language Monkeys: Scaling Inference Compute with Repeated Sampling（arXiv 2407.21787、Brownら、10月16日確認）
- s1: Simple test-time scaling（arXiv 2501.19393、Muennighoffら、10月16日確認）
- Reasoning models（OpenAI API、OpenAI、10月16日確認）
- Extended thinking（Claude Platform Docs、Anthropic、10月16日確認）
- Adaptive thinking（Claude Platform Docs、Anthropic、10月16日確認）
- Gemini thinking（Gemini API、Google AI for Developers、Google、10月16日確認）
更新履歴
- 2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した