Test-Time Scalingとは？

Test-Time Scalingとは、モデルを再学習するのではなく、回答時の計算予算・候補数・探索や検証を増やし、その使い方を工夫して問題解決性能を伸ばす考え方です。

Test-Time Scalingとは何か

Test-Time Scaling（テスト時スケーリング）とは、学習済みモデルをそのまま使いながら、回答を作る時点で投入する計算や推論手順を増やし、性能向上を狙う考え方です。ここでいうtest timeは、機械学習で訓練後のモデルを評価・利用する段階を指します。実サービスの「推論時」とほぼ同じ文脈で使われるため、inference-time scalingと呼ばれることもあります。

大きなモデルを新しく訓練する代わりに、難しい問題だけ長く考えさせる、複数の解答候補を作る、候補を探索して評価する、といった方法で性能を引き出せる点が注目されています。

ただし、「test-time scaling」という1語の中にはかなり異なる仕組みが含まれます。論文を読むときは、何を増やしているのかを必ず確認する必要があります。

何をスケールするのか

一つ目は、1本の推論trajectoryを長くする方法です。モデルがすぐ答えを確定せず、追加のステップで検算や再考を行います。s1の研究で使われたbudget forcingは、モデルが思考を終えようとしたときに続きを促すなどして、テスト時に使う推論予算を制御する例です。

二つ目は、完成した候補を複数生成する方法です。同じ質問にN回回答させ、多数決を取る、最も高得点の候補をverifierで選ぶ、といったBest-of-N系の方法です。1本を長くするのではなく、独立または半独立な試行を増やして成功確率を上げます。

三つ目は、途中状態を枝分かれさせて探索する方法です。Tree of Thoughtsのように複数の途中案を生成し、有望な枝を残しながら先へ進めます。最終回答だけを比べる方式より、途中で悪い経路を捨てられる可能性があります。

2026年の整理では、これらは単一trajectoryの逐次スケーリング、完成候補を増やして最後に集約するleaf-level scaling、途中のprefixを評価しながら探索するprefix-level scalingのように区別できます。重要なのは、同じ「8倍の計算予算」でも、8倍長い1本の推論と8本の並列候補では意味が違うことです。

Inference-Time Computeとの違い

Inference-Time Computeは、推論時に使う計算資源そのものに焦点を当てる言葉です。Test-Time Scalingは、その資源を増やしたとき、あるいは配分を変えたときに、性能をどう伸ばすかに焦点を当てます。

たとえば「この回答は通常より多くの推論トークンを使った」はInference-Time Computeの説明です。「推論予算を2倍、4倍、8倍にしたとき数学ベンチマークの正答率がどう変化したか」はTest-Time Scalingの実験です。

モデルのパラメータ数を増やすmodel scaling、学習データや学習FLOPsを増やすpretraining scalingとも区別します。Test-Time Scalingでは原則として、評価する基礎モデルを固定したうえで、推論時の手順や予算を変化させます。

「計算を増やせば性能が上がる」という単純な法則ではない

Test-Time Scalingのグラフは、右肩上がりに見えることがあります。しかし、増やせば必ず同じ割合で性能が上がるわけではありません。

第一に、問題が簡単すぎれば追加計算はほとんど不要です。第二に、基礎モデルに必要な知識や能力が欠けていれば、候補を何十個作っても正解が現れないことがあります。第三に、正しい候補が生成されても、verifierや投票法が選び損ねる場合があります。

Snellらは、どのtest-time compute手法が効くかは問題難度に強く依存すると報告しました。つまり、一定の計算をすべての問題へ均等に割り当てるより、難しさに応じて予算を配る方が効率的な場合があります。

この点は実サービスにもそのまま当てはまります。簡単な要約で常に最高reasoning effortを使うのは無駄かもしれません。一方、検証が必要な数学・コード・複雑な調査では、追加計算が価値を持つ場合があります。

単一路線と複数サンプルは何が違うのか

1本の推論を長くする方式では、前半の誤りを後半で検出して修正できる可能性がありますが、逆に誤った前提を延々と引き継ぐこともあります。

複数サンプル方式では、一つの誤りに全候補が引きずられないよう多様性を得られる可能性があります。しかし、候補同士が似すぎていればNを増やしても利益は小さくなります。また、多数決は「多数派が正しい」という条件に依存します。

探索方式では、途中の状態を評価して枝を選べますが、探索アルゴリズムと評価器の設計が必要です。探索幅を広げれば計算量は急増します。

したがって、Test-Time Scalingを「thinking tokensを増やすこと」とだけ覚えると、論文間の差を見失います。

評価グラフを読むときの注意

Test-Time Scalingの評価では、x軸に「compute」「tokens」「samples」「reasoning effort」などが置かれます。これらは同じ単位ではありません。さらに、並列実行なら総計算量は増えても壁時計時間はあまり増えないことがあります。逆に逐次探索ではレイテンシが直接伸びます。

また、temperature、最大生成長、候補選択法、verifierの有無が違えば、同じ候補数でも結果は変わります。最近の研究では、test-time scalingの再現性を高めるには、単に「予算8」と書くだけでなく、推論プロトコル全体を記録する必要があると指摘されています。

元の文脈へ戻るためのチェックリスト

Test-Time Scalingという言葉を見たら、次を確認してください。

• 何を増やしているか。推論長、サンプル数、探索幅、探索深さ、verifier計算のどれか。
• 基礎モデルは固定されているか。
• 追加計算は逐次か並列か。
• 候補の集約は多数決、Best-of-N、verifier、searchのどれか。
• x軸のcompute budgetは具体的に何を数えているか。
• 問題ごとに同じ予算か、適応的に配分しているか。
• 精度だけでなく、コストとレイテンシも報告されているか。
• 比較方法が同じ推論プロトコルになっているか。

Test-Time Scalingは、モデルの「知識量そのもの」を増やす技術ではありません。学習済みモデルが持つ能力を、回答時の追加計算でどこまで引き出せるかを扱う設計・評価の考え方として読むのが適切です。

関連するAI用語

• Inference-Time Compute
• Tree of Thoughts
• Verifier Model
• Self-Consistency
• Sampling

注・出典

本記事の主要な出典: ^{[1] [2] [3]}

1. Snell et al., Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters — CORE: test-time compute scaling、適応的配分、best-of-Nとの比較 ↩
2. Muennighoff et al., s1: Simple test-time scaling — MECHANISM: budget forcingによる単一trajectoryの推論長制御 ↩
3. Hariri et al., Test-Time Scaling in Reasoning LLMs: Inference Regimes, Evaluation, and Reproducibility — BOUNDARY/FRESHNESS: 2026時点のレジーム分類、評価プロトコルと再現性 ↩

AI協働制作について