AIエージェント

AIのスキャフォールドとは？自動最適化の効果とプロンプト過適合

2026/8/2 （更新: 2026/11/3）

🤖 AIを使用して執筆

前提として、性能はモデルの外側でも決まる

モデルを替える方法のうち「もっと考えさせる」は、実測では半数を超える設定で精度を上げなかった。プリンストン主導の多機関チームが約4万ドルをかけ、9モデルと9ベンチマークにまたがる2万1730回のエージェントロールアウト（エージェントが一つの課題を最初から最後まで解く1回の実行）を記録した研究 HAL¹がある（81通りの全組み合わせを埋めたのではなく、比較として意味のある構成を優先したと原典は書く）。その実測で、推論に使う計算量を増やしても、36設定中21で精度は改善しなかった（同点を含む）。ただしこの36設定は推論設定の対を持つ4モデルに限られ、同論文は大半の評価を統計的検証のない単発ランで走らせたと自ら断っている。

同じ研究は、モデルの外側に大きな変数があることも量化している: スキャフォールドの選択は、精度とコストに劇的な差を生む。同じモデルでスキャフォールドだけを替えた比較では、課題専用のスキャフォールドが汎用のものを CORE-Bench Hard で12回中9回、SWE-bench Verified Mini で12回中11回上回った。ただし効き方は一様ではなく、同じスキャフォールドでもモデルとの相性で向きが変わる、と同論文は但し書きをつけ、モデルとスキャフォールドを慎重に組み合わせる設計を求めている¹。

HALが示したとおり、性能を左右する変数はモデルの外側にもある。その外側の中身を、部品ごとに見ておく。

スキャフォールドとは、モデルを働かせる外側の一式である

背景で定義したスキャフォールドは、英語の scaffold（建築の足場）から来た呼び名で、モデルを繰り返し呼び出してエージェントとして動かす、モデルの外側のプログラム一式を指す。部品を並べると:

• 何を見せるかは、プロンプトとコンテキストの与え方である
• 何を使わせるかは、ツールの定義と呼び出しの形である
• どうつなぐかは、出力を解釈し、次の呼び出しへ渡す制御の流れである
• 何を残すかは、途中で得た情報の記憶と管理である

前節のHALが「スキャフォールドの選択」として比べたのは、この一式を丸ごと替える単位だ¹。具体的には、同じモデルを差し替えて載せられる BrowserUse や SeeAct といったエージェントの枠組みを指す。エージェントが何を見て、どんな順序で動き、どう記憶を管理するかというこの設計全体を、ハーネスとも呼ぶ。本稿は、引用する研究の用語に合わせてスキャフォールドで通す。

プロンプトは、この一式の部品の一つだ。以降で見る手法は、プロンプトだけを磨くものから、部品どうしの接続構造ごと探索するもの、エージェントのコードごと書き換えるものまで、どの部品をどこまで動かすかが違うだけで、同じ「外側の最適化」である。そこで問いはこうなる。この外側の設計を、人手でなく自動で最適化できるのか。

外側の最適化が効く根拠は、強化学習を上回る実測にある

外側を自動で最適化する研究の出発点は DSPy（2023年、スタンフォード）だ。言語モデル（LM、Language Model）の呼び出しを並べた処理（LMパイプライン）を宣言的な「テキスト変換グラフ」としてコンパイルし、コンパイラがプロンプトや示例を指標に向けて最適化する²。一回の指示文を磨くのではなく、パイプライン全体のモジュールをまとめて最適化するという枠組みで、手書きのプロンプトテンプレートを置き換えた。構造そのものは書き手が if や for で宣言するが、コンパイラの守備範囲は指示文・フィールド説明・示例から、必要なら重みのファインチューニング、さらにプログラムの制御フローを組み替える段にまで届く。その最も単純な形である多数決アンサンブルは同論文の事例研究でも使われている。ただし初版が実際に力を入れたのは示例を自動で集めるブートストラップで、指示文そのものを書き換える側を主役に据えるのは後続の仕事になる。

実測として最も強いのは、その後継にあたる GEPA と ACE の二つだ。GEPAは、エージェントの実行の記録をモデルに自然言語で振り返らせてプロンプトの改訂案を作り、候補を増やしながら（遺伝的）、どれかの問題で最良の候補を残して（パレート的）プロンプトを進化させる³。6タスク平均で強化学習の一手法 GRPO（Group Relative Policy Optimization）を6ポイント上回り、最大19ポイント差。しかも必要なロールアウト数は最大で35分の1になる。強化学習のコストを払わずに改善を得る、という主張だ。GRPO との比較は Qwen3-8B に限られる。主表の GRPO は LoRA（Low-Rank Adaptation、重みの更新を低ランクの行列に限る方式）版で、フルパラメータの GRPO と比べたのは HoVer の2ホップ版という1課題だけだが、そこでも同程度の差が出ると同論文は報告している。ただし6タスクのうち AIME-2025 だけは逆で、GRPO の38.00に対しGEPAは32.00と6ポイント下回る。同論文も表のキャプションに on all benchmarks except AIME と明記している³。勝てていない課題が競技数学である点は、割り引いて読んでおくとよい。

ACE（スタンフォード/SambaNova）は、エージェントのコンテキストを「進化するプレイブック」として扱い、解く役（Generator）・振り返る役（Reflector）・プレイブックへ書き足す役（Curator）のループで磨く⁴。重みを一切更新せず、エージェント側の唯一のベンチである AppWorld で、選ばれたベースライン群に対して平均 +10.6%。ACE 論文が GPT-4.1 ベースの相手より「はるかに小さい」と呼ぶ 671B のオープンソースモデル（DeepSeek-V3.1）のまま、AppWorldリーダーボードで公開中の最上位プロダクション・エージェントと全体平均で並んだ。これは2025年9月時点・ACE 論文の自己報告という条件つきの数字で、同論文はこの比較を直接比較ではない大まかな目安だと断っている。

その AppWorld は、アプリ9種・457のAPIを横断するコードでタスク750問を解かせ、状態ベースのユニットテストで機械採点するベンチだ⁵。採点は、正しく終えたかに加えて、余計な副作用を出していないかを検査する。公開当時（2024年7月）は GPT-4o でも通常タスク約49%・challenge 分割約30%にとどまった難関で、ACE の「並んだ」はこの採点方式の上での結果である。ただしこの約49%を現在の水準と読んではいけない。ACE 論文の同じ表で、最適化を何も当てていない素の ReAct（考えとツール呼び出しを交互に出させる標準的なスキャフォールド。モデルは DeepSeek-V3.1-671B）が通常タスクのタスク単位達成率 63.7 を出しており、2024年の GPT-4o の同じ指標（48.8）を15ポイント上回っている。ACE 論文が並んだとする 59.4% のほうも通常／challenge × タスク単位／シナリオ単位の4値の平均で、GPT-4o の約49%（通常タスク・タスク単位の単独値）とは値の取り方が違う⁴。この challenge 分割は難易度で切ったものではなく、未見のアプリ（Amazon と Gmail）のAPIを要するタスクを集めた汎化分割で、原典はこちらを主標的に据えている。

同じ発想の研究は、ほかにも独立に出ている。MASS（Google/Cambridge)は多エージェントの設計空間を系統的に分析し、プロンプトと接続トポロジーが決定的な最適化因子だと結論づけた⁶。ただしこの結論は MASS を提案する論文自身のものなので、他と同じく割り引く。

エージェントの設計をコードとして書き換える系統もある。ADAS（Automated Design of Agentic Systems）は、メタエージェントが新しいエージェントを繰り返しコードで書き、見つけた設計は別の領域やモデルへ移しても優位が保たれたと報告する⁷。これも提案論文自身の報告である。

Training-Free GRPO（Tencent）は、強化学習が学んでいる「経験知」を重みでなくトークンの事前分布として蒸留し、重み更新なしで、強化学習で訓練した32Bモデル（ReTool・AFM）を上回る成績を報告する⁸。ただしこの逆転の大半はモデル規模差である。手法を当てていない素の DeepSeek-V3.1-Terminus + ReAct が既に AIME24 80.0 / AIME25 67.9 で ReTool（67.0 / 49.3）を上回っており、Training-Free GRPO 自身の寄与は +2.7 / +5.4ポイントにとどまる。原典の表には 32B の Qwen3-32B に手法を当てた行もあり、AIME24 33.5 / AIME25 25.4 と、32B の Qwen2.5-32B を強化学習で訓練した ReTool の半分前後である。勝った側が重みを凍結した（更新しない）671Bモデルである点も同じで、「訓練しない」ぶんのコストは大きなモデルを呼ぶ側へ移っている。これは ACE 側にも等しく当てはまる（どちらも DeepSeek-V3.1 系の671Bを凍結して使う）。

限界は、最適化に使ったデータの外で崩れる点にある

外側の最適化の見えにくい限界を、まず TextReg⁹が記述する。反復的なLLMベースのプロンプト最適化は「プロンプト分布過適合」を起こす。最適化を繰り返すとプロンプトは長くなりやすく、最適化に使ったサンプルに特化した細かいルールを積み重ね、訓練分布の外（OOD、out-of-distribution）では性能が崩れることが多い。評価ベンチマークに向けて磨くほど、そのベンチマークの外では逆効果になりうる、という報告だ（本会議の査読は経ていない）。測定は、易しい変種と GSM8K を訓練に使って Qwen2.5-7B でプロンプトを磨き（訓練サンプルは3件ずつ12反復の計36件）、残りのデータセット（難しい変種など）を別の4モデルで解かせる設定である。データとモデルの両方が、最適化のときと違う。

最適化に使ったデータの外では、磨くこと自体が裏目に出うる。原典自身も、比較に使ったプロンプト最適化手法は分布外の評価で、最適化前の Chain-of-Thought（CoT。段階を追って考えるよう指示するプロンプト）より精度を下げることが多いと書いている。その数字が載る表の第1行を見ると、プロンプト最適化を一切していない素のChain-of-Thoughtが、24セル中14セルで TextGrad を上回っている（同点3・下回り7）。差の大きさで見ると両向きに散らばり、平均の差は1ポイントに満たない。Llama 系の Tracking Shuffled では、逆に TextGrad が10〜18ポイント上回るセルもある。

同論文が提案する正則化を加えると、OOD評価で TextGrad 比・最大 +11.8ポイント、REVOLVE 比・最大 +16.5ポイント改善した。これは比較対象の違う、それぞれ単一の最良セルの値だ。最大の +11.8 が出たセルでも、そのうち 10.9 ポイントは「最適化しない」だけで得られる分だった。

ただし TextReg が主に測ったのは単発の推論プロンプト（Logical Deduction・Tracking Shuffled Objects・GSM8K 系の6データセット）である。2026年10月の改訂版は付録で知識問答（GPQA）と文生成（CommonGen）にも同じ手順を当て、文生成では TextGrad と REVOLVE が最適化前のプロンプトを下回ったという予備結果を足した。それでも同論文は結論節でエージェント指示と多ターンのプロンプトを明示的に射程外とし、future work へ送っている⁹。本稿の主題であるスキャフォールドまで一般化するのは、原典が自分で引いた線の外への外挿になる。

二つ目の限界は、最適化が受け取るフィードバックそのものの質だ。外側の最適化が効く根拠として引いた ACE 自身が、信頼できる実行フィードバックや正解ラベルが無い場面では、誤った信号が蓄積中のコンテキストに書き込まれ、性能が劣化しうると報告している⁴。AppWorld のように状態ベースのユニットテストで機械採点できる環境は、この手法にとって最良の条件だった、ということでもある。

三つ目は、自己改良ループそのものの飽和だ。こちらはスキャフォールドではなく重みを更新するタイプの自己進化を測った研究¹⁰だが、ベースモデルからは改善するものの、計算を使いすぎると頭打ちになり、実世界の推論ベンチでの利得は「modest（小幅）」だったと報告する。10回反復すれば10回分伸び続けるわけではない。

もっとも、頭打ちの高さのほうは固定ではない。その高さはモデル規模で割れる。同じ多ターンの critic-revision で比べると、Gemma 3 4B は 42.2% で、正解ラベルで選別する oracle の 46.6% に届かない。だが 12B では 52.8% で、oracle の 53.6% にほぼ並ぶ（そのぶん監督を作る計算コストは高い）。原典は、oracle との差が小さかったのはこの組だけだと書いている¹⁰。

同論文は分布の外への伸びも測っており、題名自体が『自己進化における一般化ギャップ』である。その序論は、閉ループの自己進化は安定した利得を出すが、分布の外（易しい問題から難しい問題へ）への一般化を改善する力は限られたままで、下流の推論ベンチでは「かえって劣化することもある」とまとめている¹⁰。ただし序論は同じ箇所の直前で、反復訓練とカリキュラム学習によって難しい問題も解けるようになると書いており、分布の外へまったく伸びないという意味ではない。手法の系統は違うが、分布の外での伸びが限られるという向きは、プロンプト最適化と重み更新の両側から出ている。

TextReg がデータとモデルの両方を変えて測ったときに、最適化前のプロンプトを下回るセルが出た。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。