AIエージェント
スキャフォールドの自動最適化は効くが、分布の外で崩れうる
目次
この記事の主張は二段だ。モデルの重みを変えずにスキャフォールド(足場)やプロンプトを自動で最適化するレバーは、実測に裏づけられた本物である。 そして、プロンプト最適化の側では「最適化に使ったサンプルへ過適合する」という見えにくい天井を実測した研究があり、最適化が向かう先を問わずに引けば、そのサンプルの外で壊れうる。 以下、レバーが本物である根拠、天井の根拠、の順に見る。
前提として、性能はモデルの外側でも決まる
AIエージェントの性能を上げる、いちばん直感的な方法はモデルを替えることだ。より賢いモデルに切り替えるか、もっと考えさせるか、タスクに合わせてファインチューニングする。このうち「もっと考えさせる」には、実測が正面から反例を突きつけている。
プリンストン主導の多機関チームが約4万ドルをかけ、9モデルと9ベンチマークにまたがる2万1730回のエージェントロールアウトを記録した研究1がある(81通りの全組み合わせを埋めたのではなく、比較として意味のある構成を優先したと原典は書く)。一つ目の実測: 推論に使う計算量を増やしても、36設定中21で精度は改善しなかった(同点を含む。原文の言い回しは脚注に)。「モデルにもっと考えさせればいい」への反例だ。加えて、モデルの外側に大きな変数があることも同じ研究が量化している: スキャフォールドの選択は、精度とコストに劇的な差を生む。ただし効き方は一様ではなく、同じスキャフォールドでもモデルとの相性で向きが変わる、と同論文は但し書きをつけている。
推論計算を積むという投資が過半で報われないとき、性能変数として残るのは、モデルの外側だ。その外側の正体を、先に定義しておく。
スキャフォールドとは、モデルを働かせる外側の一式である
この外側を、引用する研究群はスキャフォールド(scaffold=建築の足場)と呼ぶ。モデルという部品そのものではなく、それを働かせるために周囲へ組む構造物、という比喩だ。実体は、モデルを繰り返し呼び出してエージェントとして動かす、モデルの外側のプログラム一式である。部品を並べると:
- 何を見せるかは、プロンプトと文脈の与え方である
- 何を使わせるかは、ツールの定義と呼び出しの形である
- どうつなぐかは、出力を解釈し、次の呼び出しへ渡す制御の流れである
- 何を残すかは、途中で得た情報の記憶と管理である
前節のHALが「スキャフォールドの選択」として比べたのは、この一式を丸ごと替える単位だ1。具体的には、同じモデルを差し替えて載せられる BrowserUse や SeeAct といったエージェントの枠組みを指す。エージェントが何を見て、どんな順序で動き、どう記憶を管理するかというこの設計全体を、ハーネスとも呼ぶ。本稿は、引用する研究の用語に合わせてスキャフォールドで通す。
プロンプトは、この一式の部品の一つだ。以降で見る手法は、プロンプトだけを磨くものから、部品どうしの接続構造ごと探索するものまで、どの部品をどこまで動かすかが違うだけで、同じ「外側の最適化」である。そこで問いはこうなる。この外側の設計を、人手でなく自動で最適化できるのか。
レバーが本物である根拠は、強化学習を上回る実測にある
この潮流の基点は DSPy(2023年、スタンフォード)だ。LMパイプラインを宣言的な「テキスト変換グラフ」としてコンパイルし、コンパイラがプロンプトや示例を指標に向けて最適化する2。一回の指示文を磨くのではなく、パイプライン全体のモジュールをまとめて最適化するという枠組みで、手書きのプロンプトテンプレートを置き換えた。骨格そのものは書き手が if や for で宣言するが、コンパイラの守備範囲は指示文・フィールド説明・示例から、必要なら重みのファインチューニング、さらにプログラムの制御フローを組み替える段にまで届く。その最も単純な形である多数決アンサンブルは同論文の事例研究でも使われている。ただし初版が実際に力を入れたのは示例のブートストラップで、指示文そのものを書き換える側を主役に据えるのは後続の仕事になる。
実測として最も強いのは、その後継にあたる二つだ。GEPAは、エージェントが自分の実行軌跡に対して自然言語で内省し、遺伝的・パレート的にプロンプトを進化させる3。6タスク平均で強化学習(GRPO)を6ポイント上回り、最大19ポイント差。しかも必要なロールアウト数は最大35分の1しか要らない。強化学習のコストを払わずに改善を得る、という主張だ。ただし6タスクのうち AIME-2025 だけは逆で、GRPO の38.00に対しGEPAは32.00と6ポイント下回る。同論文も表のキャプションに on all benchmarks except AIME と明記している。勝てていないのが競技数学=実務家が最も強化学習に手を伸ばしたくなる場面である点は、割り引いて読む値打ちがある3。ACE(スタンフォード/SambaNova)は、エージェントの文脈を「進化するプレイブック」として扱い、Generator/Reflector/Curatorのループで磨く4。重みを一切更新せず、エージェント側の唯一のベンチである AppWorld で、ベースライン比の平均 +10.6%。GPT-4.1 より小さいとはいえ 671B のオープンソースモデル(DeepSeek-V3.1)のまま、AppWorldリーダーボードで公開中の最上位プロダクション・エージェントと全体平均で並んだ。これは2025年9月時点・ACE 論文の自己報告という条件つきの数字である。
その AppWorld は、アプリ9種・457のAPIを横断するコードでタスク750問を解かせ、状態ベースのユニットテストで機械採点するベンチだ5。採点は、正しく終えたかに加えて、余計な副作用を出していないかを検査する。公開当時(2024年7月)は GPT-4o でも通常タスク約49%・challenge 分割約30%にとどまった難関で、「並んだ」の重みはこの採点方式の上で測るべきものになる。ただしこの約49%を現在の水準と読んではいけない。ACE 論文の同じ表で、最適化を何も当てていない素の ReAct(DeepSeek-V3.1-671B)が通常タスクのタスク単位達成率 63.7 を出しており、2024年の GPT-4o の同じ指標(48.8)を15ポイント上回っている。ACE 論文が並んだとする 59.4% のほうも通常/challenge × タスク単位/シナリオ単位の4値の平均で、GPT-4o の約49%(通常タスク・タスク単位の単独値)とは物差しが違う4。この challenge 分割は難易度で切ったものではなく、未見のアプリ(Amazon と Gmail)のAPIを要するタスクを集めた汎化分割で、原典はこちらを主標的に据えている。
同じ発想は独立に増殖している。MASS(Google/Cambridge)は多エージェントの設計空間を系統的に分析し、プロンプトと接続トポロジーが決定的な最適化因子だと結論づけた6。ただしこの結論は MASS を提案する論文自身のものなので、他と同じく割り引く。Training-Free GRPO(Tencent)は、強化学習が学んでいる「経験知」を重みでなくトークンの事前分布として蒸留し、重み更新なしで、RL訓練済みの32Bモデル(ReTool・AFM)を上回る成績を報告する7。ただしこの逆転の大半はモデル規模差である。手法を当てていない素の DeepSeek-V3.1-Terminus + ReAct が既に AIME24 80.0 / AIME25 67.9 で ReTool(67.0 / 49.3)を上回っており、Training-Free GRPO 自身の寄与は +2.7 / +5.4ポイントにとどまる。勝った側が凍結した671Bモデルである点も同じで、「訓練しない」ぶんのコストは大きなモデルを呼ぶ側へ移っている。これは ACE 側にも等しく当てはまる(どちらも DeepSeek-V3.1 系の671Bを凍結して使う)。
天井は、最適化が評価データの外で崩れる点にある
このレバーの見えにくい天井を、まず TextReg8が記述する。反復的なLLMベースのプロンプト最適化は「プロンプト分布過適合」を起こす。最適化を繰り返すほどプロンプトは長くなり、最適化に使ったサンプルに特化した細かいルールを積み重ね、訓練分布の外(OOD)では性能が崩れる。評価ベンチマークに向けて磨くほど、そのベンチマークの外では逆効果になりうる、という報告だ(単一の査読前研究。測定条件と数値は脚注に)。同論文が提案する正則化を加えると、OOD評価で TextGrad 比・最大 +11.8ポイント、REVOLVE 比・最大 +16.5ポイント改善した。これは比較対象の違う、それぞれ単一の最良セルの値だ。裏返せば正則化なしの既存手法がそれだけ評価の外で劣化していたということでもある。決定打は、その数字が載る表の第1行にある。プロンプト最適化を一切していない素のChain-of-Thoughtが、24セル中14セルで TextGrad を上回っている(同点3・下回り7)。看板の +11.8 が出たセルでも、そのうち 10.9 ポイントは「最適化しない」だけで得られる分だった。評価の外では、磨くこと自体が裏目に出うる。
ただし TextReg が測ったのは単発の推論プロンプト(Logical Deduction・Tracking Shuffled Objects・GSM8K 系の6データセット)であり、同論文は結論節でエージェント指示と多ターンのプロンプトを明示的に射程外とし、future work へ送っている8。本稿の主題であるスキャフォールドまで一般化するのは、原典が自分で引いた線の外への外挿になる。
二つ目の天井は、最適化が受け取るフィードバックそのものの質だ。レバーの根拠として引いた ACE 自身が、信頼できる実行フィードバックや正解ラベルが無い場面では、誤った信号が蓄積中の文脈を汚染し、性能が劣化しうると報告している4。AppWorld のように状態ベースのユニットテストで機械採点できる環境は、この手法にとって最良の条件だった、ということでもある。
三つ目は、自己改良ループそのものの飽和だ。こちらはスキャフォールドではなく重みを更新するタイプの自己進化を測った研究9だが、ベースモデルからは改善するものの、計算を使いすぎると頭打ちになり、実世界の推論ベンチでの利得は「modest(小幅)」だったと報告する。10回反復すれば10回分伸び続けるわけではない。もっとも、頭打ちの高さのほうは固定ではない。その高さはモデル規模で割れる。Gemma 3 4B は 31.0% から 44.8% までしか伸びず、理想的な教師監督の 53.3% に届かない。だが 12B に多ターンの critic-revision を当てると 52.8% で、oracle の 53.6% にほぼ並ぶ(そのぶん監督を作る計算コストは高い)9。しかも同論文の題名自体が『自己進化における一般化ギャップ』である。閉ループの自己進化は安定した利得を出すが、分布の外への一般化を改善する力は限られたままで、下流の推論ベンチでは「かえって劣化することもある」と結んでいる9。手法の系統は違うが、伸びが分布の内側に閉じやすいという向きは、プロンプト最適化と重み更新の両側から出ている。
結論として、レバーは本物だが分布の外では信頼できない
「重みを変えずにスキャフォールドを最適化する」は、本物の性能変数だ。HALの2万1730ロールアウトがスキャフォールド差の大きさを量化し、GEPAとACEが自動最適化の効き目を実証した。モデルを替えるコストをかける前に、スキャフォールドの設計に投資する余地がある。この主張は今では根拠を持つ(ただしHALはスキャフォールド由来のばらつきとモデル由来のばらつきを突き合わせてはいないので、「どちらが大きいか」まではまだ測られていない)。
だが、その最適化は「何に向かって最適化するか」に強く依存する。評価データに向けて磨いたプロンプトは、評価データの外では壊れやすい(TextRegの報告)。受け取るフィードバックが当てにならなければ、誤った信号が蓄積中の文脈そのものを汚染する(ACEの報告)。続ければ続けるほど良くなるわけでもない。ただし飽和の高さは構成しだいで動く(飽和の報告)。だから問いは、「モデルかスキャフォールドか」ではない。今、実践者が答えを持つべき問いは、「このスキャフォールドの最適化が向かっている先は、分布の外でも成立するか」である。
出典9件
-
Kapoor, Stroebl ら「Holistic Agent Leaderboard: The Missing Infrastructure for AI Agent Evaluation」arXiv:2510.11977(Princeton 主導の多機関共同、2025-10)。9モデルと9ベンチマークにまたがる 2万1730回のエージェントロールアウト、約4万ドル・25億トークンのログを公開。全組み合わせの格子を埋めた設計ではない(原典 §3 は
We conduct 21,730 rollouts across these dimensions, prioritizing configurations that reveal meaningful comparisonsと書く)。スキャフォールド選択が精度とコストに劇的な差を生むことを量化(Agent scaffolds create drastic differences in cost and accuracy)。モデル相性の但し書きも同論文(Claude models perform better with BrowserUse, while OpenAI models achieve higher accuracy with SeeAct)。なお同論文はスキャフォールド由来のばらつきをモデル由来のばらつきと突き合わせる比較は走らせていないので、「モデル選択と並ぶ」かどうかは本稿の読みである。推論計算量を増やしても過半数のラン(36設定中21)で精度は改善しないという反直感的所見も記録(同一モデルの reasoning 設定違いの比較。原典 Finding 5 はequal or lower=低下と同点の合計で、図の見出しはdoes not improve、抄録だけがreducing accuracyと書く)。ただしこの36設定の対象は推論設定の対を持つ4モデルのみ(Claude-3.7 Sonnet / Claude Sonnet 4 / Claude Opus 4.1 の「なし対 high」と o4-mini の「low 対 high」)で、9モデル全体の集計ではない。原典は付録で、これらの設定が計算量として何を意味するかは公開仕様がなく解釈が難しいとも断っている(don't have publicly documented specifications)ので、「計算量を増やす」は設定ラベルを上げることの言い換えである。さらに同論文は付録で、評価コストのため大半の評価を単発ランで走らせ、統計的検証を行っていないと自ら断っている(For HAL, we were forced to rely on single runs without statistical validation for most evaluations.)。36設定中21は信頼区間なしの単発ラン同士の向きを数えた数である。同論文は ICLR 2026 採択(ICLR 2026 の公式プログラムに Poster として掲載。arXiv 側は v1 のままで掲載先の記載がない)。 https://arxiv.org/abs/2510.11977 ↩ ↩2 -
Khattab ら「DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines」arXiv:2310.03714(Stanford、2023-10。ICLR 2024 採択。会議版の表題は
DSPy: Compiling Declarative Language Model Calls into State-of-the-Art Pipelinesで、arXiv 側は初版の表題のまま)。LMパイプラインを宣言的なテキスト変換グラフとしてコンパイルし、“teleprompter” がプロンプト/示例を指標に向けて自動最適化。teleprompter が候補を作る対象は「指示文・フィールド説明・示例」だが、原典は「この版では示例に焦点を絞る」と明記しており(In this iteration of DSPy, we focus on demonstrations)、初版の実体は示例のブートストラップである。コンパイラは加えてプログラムの制御フローの書き換えも扱い(modifying the control flow of the program)、その最も単純な形であるアンサンブルは同論文の事例研究で使われている(GSM8K の CoT は GPT-3.5 dev で bootstrap 80.3 → +ensemble 88.3)。「プログラムの構造ごと最適化する」という枠組みの基点(DSPy 自体は teleprompter を通じてプロンプト・示例だけでなく重みのファインチューニングも扱うので、「重みでなく」は後続の潮流に対する本稿の見出しであって DSPy の主張ではない)。 https://arxiv.org/abs/2310.03714 ↩ -
Agrawal ら「GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning」arXiv:2507.19457(初版 2025-07 はプレプリント、v2 = 2026-02-14 で ICLR 2026 Oral 採択)。実行軌跡への自然言語内省でプロンプトを遺伝的・パレート的に進化。ロールアウト数は最大35分の1。単位はポイント差である。抄録は
by 6% on average and by up to 20%としか書かないが、本文 Observation 1 が挙げる個別値(19.0 / 2.73 / 13.66 / 5.19 / 0.7)は Table 1 の精度差そのもの(HotpotQA 62.33−43.33=19.00、IFBench 38.61−35.88=2.73 …)で、集計スコアの差も 54.85−48.91=5.94≒6。相対差で読むと集計は+12.1%となり看板の数字に合わない。なお本文は最大値をby up to 19%と書いており、抄録の20%とは食い違う(表の最大は19.00)。GRPO との比較は Qwen3-8B に限られる(Table 2 の GPT-4.1 Mini 側に GRPO 行は無い)。主表の GRPO は LoRA 版だが、同論文は脚注でフルパラメータ微調整も走らせ、Figure 11 で「フルパラメータ版・パラメータ効率版のどちらの GRPO に対しても同程度の差が出る」と報告している。LoRA だから勝てた、という読みは原典が潰している。数値は 2026-07 閲覧時点の改訂版(初版は「平均+10%」と記載)。 https://arxiv.org/abs/2507.19457 ↩ ↩2 -
Zhang ら「Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models」arXiv:2510.04618(Stanford/SambaNova、2025-10。ICLR 2026 採択。PDF 1頁目のヘッダに
Published as a conference paper at ICLR 2026と記載)。コンテキストを「進化するプレイブック」として Generate/Reflect/Curate ループで磨く。エージェント側(同論文のエージェント区分は AppWorld のみ)+10.6%・金融 +8.6%、重み更新なし。この +10.6% は Table 1 の選択されたベースライン群に対する平均である(ReAct + ACE outperforms selected baselines by an average of 10.6%)。AppWorld で最上位プロダクション・エージェントと同等(総合)〜上回る(難課題)。ただし比較の基準時は 2025年9月20日のリーダーボード(as of September 20, 2025、ACE 59.4% 対 IBM CUGA 60.3%)=公開順位は動くので、本稿の「並んだ」はその時点の話。その 59.4% は Test-Normal / Test-Challenge × TGC(タスク単位)/ SGC(シナリオ単位)の4値の平均で、同じ表の無最適化ベースライン(素の ReAct、DeepSeek-V3.1-671B)は 63.7 / 42.9 / 41.5 / 21.6・平均 42.4。この 42.4 → 59.4(+17.0ポイント)は最適化を当てていない素の ReAct に対する差であり、上の +10.6% とは分母が違う(そちらはベースライン群に対する平均)。さらに同論文自身がWe mention IBM CUGA as a rough contextual referenceIt is not used as a methodological baseline, and we do not make direct comparisonsと、直接比較ではないと断っている。同論文は §4.4 で、フィードバックが痩せた場面での劣化も自ら報告している(when ground-truth supervision or reliable execution signals are absent, both ACE and DC may degrade in performance. In such cases, the constructed context can be polluted by spurious or misleading signals/its effectiveness depends on the availability of signals that allow the Reflector and Curator to make sound judgments)。 https://arxiv.org/abs/2510.04618 ↩ ↩2 ↩3 -
Harsh Trivedi, Tushar Khot, Mareike Hartmann ほか「AppWorld: A Controllable World of Apps and People for Benchmarking Interactive Coding Agents」(arXiv:2407.18901, ACL 2024)。9つのアプリ・457のAPI・約100の架空ユーザからなる制御可能な環境で、多アプリ横断のコードを書いて解く対話型コーディングエージェント向けの750タスク(250シナリオ×3タスク)からなり、内訳は Train 105 / Dev 60 / Test-N 168 / Test-C 417。下の GPT-4o の数字はそれぞれ Test-N と Test-C に対するもの。採点は状態ベースのユニットテスト(正解の達成+想定外の副作用の不在を検査)。公開当時(2024年7月)は GPT-4o でも通常約49%・challenge 分割約30%にとどまった難関で、対話型エージェントの標準的なベンチの一つ。Test-C(challenge)の定義は難易度ではなく未見アプリの API を要する汎化分割で(
Test-C ("challenge" set) consists of all tasks that need an API from at least one designated unseen app, Amazon and Gmail.)、記憶したアクションの再利用を封じる狙いがある。原典はwe consider Test-C as the main target for AppWorld, with Test-N serving as an intermediate targetと、Test-C を主標的・Test-N を中間目標に置いている。ACE の「最上位と並んだ」はこのベンチ上での話。 https://arxiv.org/abs/2407.18901 ↩ -
Zhou, Wan, Sun ら「Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies」arXiv:2502.02533(Google/Cambridge、2025-02。ICLR 2026 採択。PDF に
Published in the fourteenth International Conference on Learning Representations (ICLR 2026).と記載)。多エージェント設計空間を系統的に分析し、プロンプトとトポロジーが決定的最適化因子と結論。MASS フレームワークはブロックレベル(局所)→トポロジー→ワークフロー(大域)の三段の最適化で、手作り・自動生成の既存代替を大幅に上回ると報告する。 https://arxiv.org/abs/2502.02533 ↩ -
Cai ら「Training-Free Group Relative Policy Optimization」arXiv:2510.08191(Tencent Youtu Lab、2025-10。2026-08-20 時点で会議・誌への掲載記録は確認できていない)。GRPOが学習する経験知をトークンの事前分布として蒸留しAPI呼び出し時に注入、パラメータ更新なし。100件の領域外サンプル(約18ドル)で、32B級をRL訓練した手法(ReTool・AFM 等)を上回ると報告。ベースは凍結した DeepSeek-V3.1-Terminus(671B)。AIME24 82.7%/AIME25 73.3%、WebWalkerQA pass@1 67.8%(ベースライン 63.2%)。 https://arxiv.org/abs/2510.08191 ↩
-
Fu ら「TextReg: Mitigating Prompt Distributional Overfitting via Regularized Text-Space Optimization」arXiv:2605.21318(2026-05-20)。反復的LLMベースのプロンプト最適化が引き起こす「プロンプト分布過適合」を分析している。プロンプトは長くなり最適化に使ったサンプルに特化したルールを積み重ね、OODで性能が崩れる(
optimized prompts often suffer from poor generalization beyond the training data)。TextReg の正則化を加えると OOD 推論ベンチで最大 TextGrad 比 +11.8pt、REVOLVE 比 +16.5pt(Qwen2-7B / Phi-3.5-Mini / Llama-3-8B / Llama-3.1-8B。全9データセットのうち、OOD評価に用いる6データセットでの値である。原典は易しい変種と GSM8K で最適化しevaluated for cross-dataset generalization on the remaining datasetsとしている。いずれも単一の最良セルの値。易しい変種で最適化し、難しい変種へ転移させた設定)。同じ Table 1 の第1行は最適化を一切しない Zero-shot Chain-of-Thought で、24セル中14セルで TextGrad を上回る(同点3・下回り7)。射程は同論文が自ら限定している。§6 Conclusion 逐語:A current limitation is scope: TextReg targets single-turn reasoning with well-defined behavioral rules, and we leave open-ended generation, multi-turn prompts, and agent instructions—where rule structure blurs and capacity cost is shared across turns—to future work.査読状態は、2026-08-20 時点で ICLR 2026・ICML 2026 の公式プログラムにも DBLP の会議項目にも記録が無く、査読を経た形跡を確認できていない。 https://arxiv.org/abs/2605.21318 ↩ ↩2 -
Qi ら「On the Generalization Gap in Self-Evolving Language Model Reasoning」arXiv:2606.01075(Harvard/Google、2026-05。ICML 2026 採択。ICML 2026 の公式プログラムに Poster として掲載)。自己進化はベースモデルを超えるが、過剰な計算の後で頭打ちになる。ただし理想的な教師監督との差は規模で割れる。Gemma 3 4B は 44.8%(oracle 53.3%)にとどまるが、12B に多ターンの critic-revision を当てると 52.8% で oracle の 53.6% にほぼ並ぶ(
multi-turn critic-revision with large models could reach strong self-evolution performance, where Gemma 12B nearly matches oracle-supervised training)。抄録の締めもOverall, our results characterize when closed-loop SE can helpで、無条件の飽和ではなく条件づけである。分布外についてはclosed-loop SE can produce consistent gains, but its ability to improve out-of-distribution generalization remains limitedと結び、下流の推論ベンチではmight even degrade sometimesとも書く。主実験は Knights and Knaves(KK)の論理パズルで、実世界の推論ベンチはその外での追加評価(Beyond KK, we also evaluate SE on real-world reasoning benchmarks, where gains are also modest.)。スキャフォールド自動最適化のループも、条件次第で同様の飽和に陥りやすいと考えられる。 https://arxiv.org/abs/2606.01075 ↩ ↩2 ↩3
この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。