AutoTTS 解説 - 人間は「環境」を設計し、LLM が「戦略」を発見するテスト時スケーリングの新パラダイム

「LLM の性能を上げたいなら、戦略を手で設計するのをやめて、LLM 自身に戦略を発見させればいい」。そんな発想を真面目にやってみた論文が、2026 年 5 月に arXiv に出ました。

論文: LLMs Improving LLMs: Agentic Discovery for Test-Time Scaling (arXiv:2605.08083v2)
著者: Tong Zheng ほか（UMD / UVA / WUSTL / UNC / Google / Meta の共著）
コード: zhengkid/AutoTTS（公開予定）

提案手法の名前は AutoTTS。Test-Time Scaling 戦略の発見を、人手の試行錯誤から「環境設計 + LLM エージェントによる探索」に置き換える、というアイデアです。本記事はこの論文の要点と意義を、実務エンジニア寄りの視点で解説します。

前提: そもそも Test-Time Scaling (TTS) とは

LLM の精度を上げる方法には大きく 2 つの軸があります。

学習時に投資: モデルを大きくする、データを増やす、ファインチューニングや RLHF を行う
推論時に投資: 同じモデルに対し、推論時に追加の計算リソースを割り当てる

後者が Test-Time Scaling (TTS)。代表例として、

手法	概要
Self-Consistency (SC@64)	同じ問題に対し 64 本の推論を並列実行し、多数決で答えを決める
Best-of-N	N 本生成して報酬モデルで最良を選ぶ
ASC	1 本ずつ推論して、合意率が閾値（例: 0.95）を超えたら止める
ESC	チャンク単位で生成し、答えの安定が見えたら早期終了
Parallel-Probe	複数ブランチを並列に展開しつつ、ブランチ間の情報で枝刈り（prune）や継続を動的に判断
Tree of Thoughts / 木探索系	思考を木構造で探索し、verifier で枝を評価しながら進める

OpenAI の o1 / Anthropic の Claude の Extended Thinking、DeepSeek-R1 など、「長く考えるほど賢くなる」系の流れは、すべて TTS の文脈にあります。

問題提起: TTS 戦略は「手で」設計されている

論文の問題意識はシンプルです。

既存の TTS 戦略は研究者が直感で設計し、ヒューリスティックを手でチューニングしているため、計算割り当て空間の大部分が未探索のままになっている。

「いつブランチを増やすか」「いつ枝刈りするか」「いつ深く考え続けるか」「いつ止めるか」——これらはすべて人間が論文で 1 つずつ提案・チューニング・ベンチマークしている、というのが現状。

鍵となる視点: width-depth 制御空間

論文の最初の重要な洞察は、既存の TTS 手法を統一的な「制御空間」上の点として捉え直すことです。最も単純な例として、論文では width-depth 空間が示されています。

width: 同時に展開する推論ブランチの数
depth: 各ブランチをどこまで深く展開するか

この 2 軸の空間上に既存手法をマップすると、

手法	width-depth 空間上の挙動
SC@64	固定で最大幅・最大深さ（角に止まる）
ASC / ESC	最大深さで、width 方向だけ適応的に切り上げる
Answer Consistency	単一チェーンで depth 方向だけ適応
ST-BoN	広く始めて 1 本に絞り、深く伸ばす
Parallel-Probe	広く始めて深めつつ徐々に枝刈り

…と、それぞれが同じ空間上の異なる軌跡として表現できる、というのが論文の主張。

つまり「個別ヒューリスティックの発明合戦」は、本質的には同じ空間上のどの軌跡を選ぶかの問題に過ぎなかった。だとすれば、軌跡そのものを探索できるはず。

AutoTTS の中心アイデア: 設計対象を「戦略」から「環境」へ

ここから論文の核心。AutoTTS は、人間の役割を次のように再定義します。

従来の TTS 研究	AutoTTS
人間が戦略（branch / prune / stop の規則）を設計	人間は環境（state / action / feedback / objective）を設計
人間がコードを書きベンチマークを回す	LLM エージェントがコードを書き、リプレイ環境で評価
失敗したら別のヒューリスティックを試す	履歴をもとに次の controller を改善する反復探索

「研究者は環境を作る人になり、LLM が戦略を発見する人になる」というロール反転です。

5 つのアクション

具体的に、AutoTTS の探索エージェントは、各時点で次の 5 つから 1 つを選びます。

アクション	意味
BRANCH	新しい推論ブランチを 1 本作って 1 区間進める
CONTINUE(i)	ブランチ i を固定長 1 区間だけ伸ばす
PROBE(i)	ブランチ i の現時点での中間回答（probe signal）を覗き見る
PRUNE(i)	ブランチ i を非アクティブにする（枝刈り）
ANSWER	推論を終了し、aggregation で最終回答を出す

state は「問題 q / インスタンス化済みブランチ数 / アクティブブランチ集合 / 各ブランチの depth / 生成済み prefix / 公開済み probe 出力」のタプル。これは要するに POMDP（部分観測 MDP）の問題設定で、目的関数は「精度 − γ × 計算コスト」のトレードオフ最大化です。

このフレーミングが綺麗で、SC / Best-of-N / ESC / Parallel-Probe など既存手法すべてがこの空間上の特殊解として書き下せる、という点が論文の出発点と整合します。

AutoTTS を成立させる 3 つの設計判断

「LLM に戦略を発見させる」と言うのは簡単ですが、実際にやろうとすると普通は破綻します。AutoTTS が機能している理由は、次の 3 つの設計判断にあります。

1. オフラインリプレイ環境（評価コストの圧縮）

最大の問題は、controller を 1 つ評価するごとに LLM を何度も呼び出していたら、探索コストが青天井になること。

AutoTTS の解法は単純で強力です。

事前に、各問題に対して N 本（論文では 128 本）の推論トラジェクトリを LLM で生成し、固定長 Δ トークン（論文では 500 トークン）で区切って保存
各区間の終わりで「もし今ここで答えたら何になる？」という probe signal も事前収集
controller はこのプール上で「もし BRANCH したら / もし PROBE したら」をリプレイするだけ

つまり探索フェーズでは LLM を呼ばない。データを 1 回作っておけば、後は決定論的にゼロコストで何千回でも候補 controller を評価できます。

これは「強化学習を実環境ではなく事前収集したデータで回す（offline RL / replay）」のと同じ発想で、TTS 探索の実行可能性をひとりで決めている設計です。

2. β パラメタリゼーション（探索空間の崩壊防止）

予備実験で、エージェントに自由にコードを書かせると10 個近いハイパーパラメータを持つ controllerを提案してきて、5 ラウンドの探索ではまったく空間を覆い切れず、しかも「探索セット上で偶然うまくいく極端な閾値（攻めすぎた pruning など）」に collapse してしまう、という現象が観察されました。

そこで導入されたのが β パラメタリゼーション。

各 controller はたった 1 個のスカラー βだけを外に出す
内部のすべてのハイパーパラメータはβ からの決定論的な単調マップで導出する（β が大きいほどトークン予算も大きい、というモノトニシティ）
β からの map 関数自体もエージェントが書く

これにより探索空間は1 次元の β スイープに圧縮され、探索セットへの過剰フィットも抑制されます。10 次元の自由探索ではなく、「滑らかなトレードオフ曲線を 1 本作れ」という制約を課したのが効いた、という話です。

3. 実行トレース・フィードバック（失敗診断の解像度）

3 つ目は、エージェントへのフィードバックの設計。

「accuracy = 0.51、tokens = 12000」のようなスカラー結果だけを渡しても、エージェントは「何が悪かったのか」が分かりません。次にどう直せばいいかが見えないので、改善が空回りする。

AutoTTS では、各ラウンドの履歴にcontroller の実行トラジェクトリ（どのブランチを、いつ、どのくらい伸ばし、いつ枝刈りしたかの逐次ログ）を含めて渡します。エージェントは「あ、難しい問題で BRANCH を増やしすぎて、肝心の深さを伸ばしきれずに止まっている」「probe で見えた信号を無視して prune している」といった失敗モードを診断でき、次の提案で具体的に改善を狙えるようになります。

これは Lee らの「meta-harness 発見でも fine-grained execution feedback が効く」という最近の知見と整合する設計、と論文中で触れられています。

発見ループの全体像

3 つの設計を組み合わせたうえで、AutoTTS の探索ループはこう動きます。

環境構築（人間）: state / action / reward / aggregation を実装。事前に N 本のトラジェクトリと probe signal をオフライン収集
初期 controller（人間 or エージェント）: シンプルな初期戦略を 1 本用意
探索ラウンド（R 回繰り返し）:
1. Explorer LLM（論文では Claude Code）が、これまでの履歴 H（過去の controller コード、β スイープの精度-コスト曲線、実行トレース）を読む
2. 「前回どこで失敗したか」を分析し、改善版 controller のコードを編集
3. リプレイ環境で β をスイープ評価し、結果と実行トレースを H に追記
controller 選択: R ラウンド後、探索セットで最も accuracy が高い (controller, β) を採用
汎化評価: 探索に使わなかった held-out ベンチマーク / 別モデルサイズで性能を確認

エージェントが書くのは実行可能な Python コードで、人間が用意したリプレイ環境の API を呼びながら controller のロジックを構築します。

実験結果のサマリ

論文の主な実験設定はこんな感じ。

項目	設定
ベースモデル	Qwen3 (0.6B / 1.7B / 4B / 8B)、4 サイズで検証
探索セット	AIME24（数学コンテストベンチマーク）
Held-out 評価	AIME25 / HMMT25（探索・選択では一度も使わない）
事前収集	(model, problem) ごとに 128 本のトラジェクトリ、500 トークン区切り
探索ラウンド	5 ラウンド
Explorer	Claude Code
探索総コスト	$39.9 / 160 分

比較対象は、SC@64 / ASC / ESC / Parallel-Probe といった最先端の手作り TTS 手法。結果として、

AutoTTS が発見した controller は、探索セット（AIME24）で精度-コストのパレートフロンティアを更新
同じ controller が、AIME25 / HMMT25 でも、さらにQwen3 の異なるサイズに切り替えても、ベースラインを上回るトレードオフを維持
探索コストは $40 / 3 時間弱。1 度走らせれば再利用可能

つまり「1 回 $40 払えば、その後はずっと使い回せる賢い TTS 戦略」が手に入る、という構図です。

なぜこの論文は面白いのか（解釈）

純粋に「AutoML が TTS にも来た」という以上に、論文の主張のうち 意義のある含意を 3 つ挙げます。

1. 「Explorer に Claude Code を使った」という選択

AutoTTS の Explorer は汎用コーディングエージェント（Claude Code）です。専用に強化学習した meta-controller でも、特別な探索アルゴリズムでもありません。

「賢いコーディングエージェントが手に入った今、研究プロセス自体を agentic にできる」というメッセージで、これは TTS だけでなく、ハイパーパラメータ探索・カーネル設計・データ前処理・損失関数探索などに広く展開可能な思想です。実際、論文中でも meta-harness 発見の先行研究（Lee 2026）を参照しています。

2. 「環境設計」というスキルの価値が再評価される

人間の役割は「自分が良い戦略を考える」ことから、「LLM が良い戦略を発見しやすい環境を設計する」ことに移ります。

state / action / reward の選び方
探索コストを下げるためのオフラインリプレイ化
β パラメタリゼーションのような探索空間の構造化
失敗診断のためのフィードバック粒度

これらは強化学習の研究者・実務家が長く経験的に積んできたスキルで、LLM が研究プロセスに入ってきた時に逆に光が当たる領域です。

3. パレートフロンティアという尺度の浸透

論文の評価軸は「accuracy × cost のパレートフロンティアを上に押し上げたか」であって、単純な accuracy 比較ではありません。

TTS の文脈では「精度を上げるためにいくらでもトークンを使う」ことが許される空気が一部にありますが、本番運用では推論コストが直接 P/L を決めます。「精度はちょい上、コストは大幅減」も価値ある勝ち方として認める評価設計が、TTS 研究全体の健全化に寄与する余地があります。

実務で「真似できる」エッセンス

論文の手法をそのままプロダクション LLM サービスに持ち込むのは（少なくとも現時点では）すぐには難しいですが、発想だけ抽出して自分の問題に持ち込めるかを考えると、次のような場面で応用余地があります。

自分の問題	AutoTTS の発想を借りる
プロンプトチューニング	プロンプトを直接探索する代わりに、「プロンプト評価環境」を作って LLM に書き換えさせる
推論パイプライン最適化	RAG / verify / rerank の順序と打ち切り条件を、オフラインデータで replay 探索
バッチ推論コスト削減	リクエスト群を「事前収集トラジェクトリ」とみなして適応的早期終了ロジックをエージェントに発見させる
ハイパーパラメータ探索	高次元自由探索ではなく β 1 本に集約するパラメタリゼーションを設計する

特に最後の「β パラメタリゼーション」は、ハイパーパラメータが多い ML 系で探索が破綻する経験がある人なら、明日から効く考え方だと思います。

限界と今後の方向

論文も率直に書いていますが、AutoTTS にはいくつか限界があります。

現状の実装はwidth-depth 空間に限定。tree search や verifier-guided refinement のようなより豊かな構造はカバーしていない
探索は事前収集されたトラジェクトリの範囲に依存。トラジェクトリ生成時の温度 / モデル設定が固定されているため、controller がそこから外れた挙動を取れない
探索セット（AIME24）と評価セットの分布が近いタスク領域（数学コンテスト）で評価されており、より遠い分布（コーディング・対話・要約など）への汎化はこれから

論文の最後では「環境設計こそが投資すべき場所」と締めくくっていて、今後は state / action 空間の拡張、verifier 統合、別タスクへの環境構築が研究のフロンティアになりそうです。

まとめ

AutoTTS は、Test-Time Scaling 戦略を「人間がヒューリスティックを書く」から「人間が環境を設計し LLM がコードを発見する」へとパラダイムシフトする提案
既存の TTS 手法は width-depth 制御空間上の特殊解として統一的に表現でき、その空間を明示的に探索できる
成立を支える 3 つの設計判断は、オフラインリプレイ環境（評価コスト圧縮） / β パラメタリゼーション（1 次元探索） / 実行トレース・フィードバック（失敗診断）
Explorer に Claude Code を使い、5 ラウンド / $39.9 / 160 分で手作り SOTA を上回る controller を発見
発見した controller は探索ベンチマーク・モデルサイズの両方で汎化
「環境設計」「パラメタリゼーション設計」「実行トレースの設計」は、TTS 以外のあらゆる agentic discovery にも展開可能な思想

「LLM の性能向上を、もう一段抽象度の高いレイヤーで自動化する」という意味で、研究 / 開発プロセスそのものへの LLM 投入の好例だと思います。Claude Code を「コーディング作業の補助」ではなく「研究ループの中核探索エージェント」として使ったのが象徴的。