LayerXPublicationへの投稿
🔁

自己改善エージェントはなぜ前提を覆せないのか ― 局所最適とハーネスでの脱出

223
に公開
workflow
Agent
llm
Agent
tech

Ai Workforce事業部FDE部エンジニアの堤(@ozro_223)です。
本記事では、AgentにAI Workflowを自己改善させるときに起きる「最初の前提を覆せない」問題について考えます。

入力データと正解データを用意し、Agentに実行結果を改善させていくと、途中までは順調に精度が伸びます。一方で、改善の中身を見ると、プロンプトの加筆やコードでの出力正規化（単なる文字列置換や正規表現）の追加に留まり、処理の順序や設計そのものを変える提案はあまり出てきません。

この記事では、この現象を整理したうえで、既存の研究でどのような解決策が取られているのかを紹介し、どのように実務に応用すべきかを考えます。

Ai Workforce事業部のFDE部では、従来は人間が手作業で構築していたAI Workflow（以降、WFと呼びます）を、Coding Agent（以降、Agentと呼びます）を用いて構築しています。

また、初期構築だけで終わらせず、現場で得られた実例や事前に定義したGround Truth（GT）を使って、AgentにWFを自己改善させています。


図1: FDE部におけるWF構築と自己改善の流れ。出典: LayerX FDE Practices（スライド15）

私の進め方は次の3ステップです。

  1. 要件定義書や設計書をAgentと一緒に書く
  2. AgentがそのドキュメントをもとにWFを構築する
  3. 構築したWFを実行し、GTとの差分を分析して改善する

この流れを回すと、序盤は順調に精度が上がります。特に、LLMのプロンプトを加筆・修正する、LLM出力を正規化するコードを追加するといった改善は、Agentが比較的うまく実行できます。

ただし、最後の数%、ラストワンマイルの改善には手が届きません。最近扱ったあるWFでは、私が失敗の分析と設計の見直しまで実施すればAccuracy 99%を狙える簡易的なタスクでしたが、Agentの自己改善は90%前後で停滞しました。何度サイクルを回しても、改善案はプロンプトの加筆と出力正規化しか実施しませんでした。

このとき、Agentからは「そもそもこの設計が違うのではないか」「別の処理順にしたほうがよいのではないか」「このタスクはプロンプトではなくコードで固定したほうがよいのではないか」といった、最初の前提を覆す仮説があまり出てきませんでした。

私が同様にWFの改善を実施する場合、改めて入力と出力を目視し、失敗原因の分析を実施し、既存の設計では拾えないパターンを探します。そのうえで、「そもそもこの要件は正しくないのでは？」「このコンポーネントはLLMではなくてコードで決定的に処理したほうが良いかも」と、プロンプトの修正に留まらず、要件や設計の見直しまで実施します。

しかしAgentは、既存の設計の中で改善しようとしがちです。最後には「これ以上の改善は難しいです」と言って止まってしまいます。体感としては、Agent/LLMの能力が足りないというより、探索している範囲が狭いように見えます。

本記事で考えたいのは、この現象です。

Agentはなぜ最初の前提を覆せないのか。なぜ、プロンプトを少しずつ足す改善に寄ってしまうのか。

この問いを、まずは局所最適化問題として捉えてみます。そのうえで、関連する既存研究を手がかりにしながら、ハーネス層でどう改善の糸口を作れるのかを考えていきます。

局所最適化問題として考える

局所最適化問題自体は、機械学習に関わる人であれば馴染みのある話だと思います。

単一の目的関数を少しずつ改善していくと、近傍では良い解に到達できる一方で、その解が大域的に良いとは限りません。現在の解から一時的には悪く見える方向でも、その方向に進まないと、より良い解にたどり着けないことがあります。人生と同じですね。

目的関数を素直に登る探索が行き止まりに陥りうることは、進化計算の分野でも古くから指摘されています[1]。そして、これと同じ構図の問題は、LLMやAgentの研究でも見られます。

1つ目は、アンカリング効果による初期情報への固定です。Lou and Sunの Anchoring Bias in Large Language Models: An Experimental Study では、LLMが初期情報の影響を受けやすいことが示されています。同実験では、Chain-of-ThoughtやReflection、「アンカーを無視せよ」という指示だけでは、アンカーの影響を十分に緩和できませんでした。

これは、最初に書いた要件定義書や設計書が、その後の改善案を固定してしまう可能性を示唆しています。もちろん、論文の実験は数値回答を中心にしたものであり、WF設計にそのまま一般化できるわけではありませんが、「最初に与えた情報が、その後の探索範囲を狭める」という点では、私が見ている現象とかなり近いものがあります。

2つ目は、自己反省だけでは発散しにくいという問題です。Liangらの Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate では、LLMが一度自分の解に自信を持つと、初期の立場が誤っていても自己反省だけでは新しい考えを出しにくくなる現象をDegeneration-of-Thoughtとして説明しています。

この論文では、複数のAgentに異なる立場から議論させるMulti-Agent Debateによって、単一の自己反省よりも異なる推論経路を引き出せる可能性を示しています。ここでも重要なのは、「もう一度考えて/改善して」と同じAgentに依頼するだけでは、同じ推論経路をなぞりやすいという点です。


図2: 自己反省では初期回答を確認する方向に進みやすい一方で、Multi-Agent Debateでは異なる立場の議論を通じて別の推論経路を引き出す例。出典: Liang et al., "Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate"

ここまで見てきた研究を踏まえると、WF改善のAgentも、最初に与えた要件定義書や設計書に引っ張られている可能性が高いです。初期情報が探索範囲を狭め、自己反省だけでは同じ推論経路から抜けにくくなっている状態です。

既存研究はこの局所最適をどう整理しているか

こうした局所最適への陥り方は、2026年の研究では失敗モードとして構造的に整理され始めています。本記事では2つの整理を取り上げます。

1つ目の PACEvolve は、LLMを使った長期の進化的探索が失敗するモードを3つに分類しています。

  • Context Pollution（コンテキスト汚染）: 失敗した試行がコンテキストに蓄積し、その履歴が次の候補生成を偏らせる。誤った仮説が自己強化されてしまう
  • Mode Collapse（モード崩壊）: 既知のアイデアの活用に寄りすぎて新しい探索が不足し、局所最適で停滞する
  • Weak Collaboration（連携不足）: 並列に探索しているのに交叉のやり方が固定的で、別の探索で得た発見を活かせない

2つ目の Controlled Self-Evolution（CSE） は、生成→検証→改良を繰り返す自己進化の問題点を3つ挙げています。

  • Initialization Bias（初期化バイアス）: 単一または少数の初期解から進化を始めると、それが悪い解領域にあった場合に抜け出しにくい
  • Uncontrolled Stochastic Operations（非制御確率的演算）: 候補の変更がフィードバックに導かれておらず、当てずっぽうの変異になっている
  • Insufficient Experience Utilization（経験の活用不足）: 過去の試行やタスクで得た成功・失敗の経験が、次の探索に使われない

（どちらも日本語訳はnani.now）

私の体験は、この分類にそのまま当てはまります。最初に書いた要件定義書が以降の改善案を縛るのは、Context PollutionとInitialization Biasの構図です。プロンプトの加筆に改善が限定されて90%で停滞するのは、Mode Collapseそのものです。私のAgentが前提を覆せない問題は、単一の候補を単一の履歴の上で磨き続ける探索に共通する問題なのだと整理できます。

次章では、これらの問題にどう対処するかを考えます。両論文が提案する対処も、対応する観点の中で順に触れていきます。

探索の仕組みを変える

既存研究を見ると、前章の問題に対処するための観点は、大きく3つに整理できます。

  1. 複数の候補を並行して改善する
  2. 過去の候補をアーカイブして再利用する
  3. 候補の多様性を評価に入れる

3つの観点はいずれも、単一候補の近傍に収束していくMode Collapseを構造で止めるためのものです。加えて、観点2は過去の候補と経験を捨てないという点でInsufficient Experience Utilizationに、観点3は初期候補から多様性を確保するという点でInitialization Biasにも対応します。残るContext Pollution・Uncontrolled Stochastic Operations・Weak Collaborationは、観点そのものというより個別の工夫が対応する話なので、それぞれ観点2の改善履歴の管理、観点1の候補生成の仕方、観点3の教訓の共有の中で触れます。

1. 複数の候補を並行して改善する

1つのWF候補だけを残して改善を続けると、その候補の近傍に探索が寄っていきます。これは分かりやすい一方で、最初の設計が外れていた場合に抜け出しにくいです。Mode Collapseに最短距離で向かう構造といえます。

この点で参考になるのが、Agrawalらの GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning です。GEPAは、WF（論文ではCompound AI System）の各LLMモジュールに入っているプロンプトを、モデルの重みを変えずに最適化する手法です。

簡単に流れを書くと、次のようになります。

  1. 初期プロンプトを持つWFを、最初の候補としてCandidate Poolに挿入（図3: Initialize / Candidate Pool P）。
  2. その候補を複数の入力で実行し、LLMの推論、ツール呼び出し、ツール出力、評価結果をトレースとして保存（図3: Rollouts / Obtain text feedbacks）。
  3. 各候補について「どの入力でどれくらい良かったか」をScores Matrixとして保持（図3: Scores Matrix）。
  4. 平均スコアが高い候補だけでなく、特定の入力で強い候補も残す（図3: Best candidate per task / Pareto-based Candidate Filtering）。
  5. その候補集合から親を選び、実行トレースを読んでプロンプトを修正するか、別々の候補で学んだモジュール単位の改善を組み合わせて、新しい候補を作成（図3: Propose New Candidate / Reflective Prompt Mutation / System Aware Merge）。
  6. 新候補が親より良ければCandidate Poolに追加し、このサイクルをrollout予算が尽きるまで回す（図3: Performance improved? / Eval on all tasks + Add Pnew to Pool / While Budget > 0）。


図3: GEPAの最適化ループ。出典: Agrawal et al., "GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning"

新しい候補の作り方は大きく2つあります。1つはReflective Prompt Mutationです。既存候補をミニバッチで実行し、得られたトレースとフィードバックを使って、特定モジュールのプロンプトを改善します。もう1つはSystem Aware Mergeです。複数候補のうち、あるモジュールでは候補Aのプロンプトを使い、別のモジュールでは候補Bのプロンプトを使う、という形でシステム単位の組み合わせを作ります。

主な候補生成ではReflective Prompt Mutationを使ってプロンプトの改善を実施します。一方で、System Aware MergeはCandidate Poolを定期的に見に行き、以下の条件が揃ったときに実施されます。

  1. 2つの候補が共通の祖先を持つ
  2. 直接の親子関係ではない
  3. どちらの候補も、その共通祖先より性能が良い
  4. それぞれが別々のモジュールの改善をしている
  5. まだ同じ組み合わせでMergeしていない

また、System Aware Mergeのアルゴリズム自体はかなり素直です。数式での定義は折りたたんでおくので、興味のある方は開いてみてください。

System Aware Merge の選択ルール（数式での定義）

共通祖先を a、Merge対象の2候補を i, j とします。各モジュール m について、祖先・候補i・候補j のプロンプトをそれぞれ次のように置きます。

\pi_a^m,\ \pi_i^m,\ \pi_j^m

新しい候補 new のモジュール m のプロンプト \pi_{new}^m は、以下のルールで決まります。

\pi_{new}^m = \begin{cases} \pi_j^m & \text{if } \pi_a^m = \pi_i^m \text{ and } \pi_j^m \ne \pi_i^m \\ \pi_i^m & \text{if } \pi_a^m = \pi_j^m \text{ and } \pi_i^m \ne \pi_j^m \\ \pi_{d^*}^m & \text{if } \pi_i^m,\ \pi_j^m,\ \pi_a^m \text{ are all different} \\ \pi_i^m & \text{otherwise} \end{cases}

ここで d^* は、候補 i, j のうちスコアが高い候補です。

d^* = \arg\max_{d \in \{i,j\}} S[d]

要するに、片方の候補だけが祖先から変わっているモジュールでは、その変更を採用します。両方の候補が同じモジュールを別々に変えている場合は、スコアが高い候補のプロンプトを採用します。どちらも変わっていない場合は、そのまま維持します。

MutationもMergeも、実行トレースと評価フィードバックを読んでから候補を変える点が重要です。CSEが問題視した「フィードバックに導かれない無制御な確率的操作」とは逆に、何がどう失敗したかに基づいた変更になっています。

論文では、GEPAが既存のプロンプト最適化手法を上回る結果が報告されています。

WF改善でも、全データで平均スコアが一番高いWFだけを残し、そのWFを改善し続けるサイクルを回してしまうと探索が固定されてしまいます。一方で、契約書Aに強いWF、契約書Bに強いWF、例外ケースCに強いWFに関する情報をそれぞれ残しておけば、後から「どのWFがどの入力に効いたのか」を比較し、後続の改善に活かすことができます。

この比較ができると、単に平均点の高いWFを磨くだけでなく、ケースごとに強い設計要素を持ち寄って新しいWFを作る余地が生まれます。GEPAをそのままWF改善に使うというより、グローバルベスト1本に集約しすぎず、ケース別・モジュール別に強い候補を残すという設計思想が参考になります。

WF改善に応用するなら、重要なのはトレースの残し方だと思います。WF実行ごとに入力、各ノードの入出力、LLMプロンプト、ツール呼び出し、コード実行結果、最終出力、GTとの差分を保存する。単に最終スコアだけを見るのではなく、「どのノードで、どの入力に対して、何が失敗したのか」を後から読める形にするイメージです。

そのうえで、論文のように候補WFの木構造、Score Matrix、トレースを蓄積していきます。候補WFごとに、どの親候補から派生したのか、どのノードを変更したのか、どの入力では改善し、どの入力では悪化したのかを記録します。全体平均だけでなく、入力タイプごとのScore Matrixも持つべきでしょう。たとえば「条項抽出では候補Aが強い」「金額正規化では候補Bが強い」と分かるようにしておくことで、後段のMergeに役立ちます。
私のWF改善でも実行ログ自体はかなり残していますが、各モジュールの結果を詳細に残すこと、候補の木構造、Score Matrixという観点は考慮していなかったため、非常に参考になります。

ここまで記録できると、GEPAと同じようにReflective Prompt Mutationでモジュール単位の改善を回しつつ、System Aware Mergeに近いMerge手法もWFに持ち込めます。

ただし、ここにはGEPAとは違う難しさもあります。GEPAの主な改善対象はプロンプトですが、WF改善ではプロンプトだけでなく、プログラミングコード（主にPython）、ノード構成、処理順も改善対象になります。そのため、どこまでをトレースとして残すのか、どの単位なら安全にMergeできるのか、プロンプト変更とコード変更を同じ候補木で扱ってよいのかは、別途設計が必要です。

つまり、GEPAから得られる仮説は「WF改善Agentには、トレースを蓄積し、Score Matrixで候補の得意不得意を見えるようにし、候補木の上でMutationとMergeを回す仕組みが必要ではないか」ということです。これができれば、Agentは単一の最新WFをいじるのではなく、複数の設計案を比較しながら次の候補を作れるようになります。

2. 過去の候補をアーカイブして再利用する

GEPAの話では、候補ごとのトレースとScore Matrixを残し、グローバルベスト1本に寄せすぎないことを見ました。次に問題になるのは、過去の候補をどう扱うかです。

Agentに改善を任せると、最新の候補だけが正として扱われがちです。しかし、一度はスコアで劣った候補が、別の変更と組み合わさると有効になることがあります。局所最適から抜けるには、「いま一番良い候補」だけでなく、「後で別の枝の起点になり得る候補」を残す必要があります。これはMode Collapseを止める仕組みであると同時に、CSEのいうInsufficient Experience Utilizationへの対処でもあります。

この観点で参考になるのが、Zhangらの Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents（DGM） です。DGMは、Coding Agentが自身のコードベースを編集して新しいCoding Agentを作り、その候補をSWE-benchやPolyglotで評価する手法です。

オリジナルの Goedel Machinesは、自己改善の過程を数学的に証明し続けるというアプローチですが、DGMはそれと異なります。改善した候補を形式証明ではなく実測で評価し、有効な候補をアーカイブに入れていく手法です。


図4: DGMの自己改変ループ。出典: Zhang et al., "Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents"

簡単に流れを書くと、次のようになります。

  1. 初期Coding Agentをbenchmarkで評価し、最初の候補としてアーカイブに入れます。
  2. アーカイブから親Agentを選びます。親選択は、性能スコアに概ね比例し、コードベース編集能力を持つ子候補の数に概ね反比例します。つまり、高性能で、まだあまり探索されていない候補が選ばれやすくなります。
  3. 選ばれた親Agentは、自身の評価ログを見ながら次に実装する改善を決め、自分のコードベースを編集して子Agentを作ります。
  4. 子Agentをbenchmarkで評価します。コンパイルできない候補や、コードベース編集能力を失った候補はアーカイブに入れません。
  5. 有効な子Agentを、スコア、親子関係、変更内容、評価ログとともにアーカイブへ追加します。
  6. このサイクルを繰り返し、候補Agentの木を育てます。

ここで重要なのは、DGMがプロンプト最適化だけをしているわけではないことです。論文で示されている改善には、細かいファイル閲覧、精密な編集ツール、コンテキスト長に達したときの自動要約、複数パッチ生成とランキング、過去の試行を踏まえたパッチ生成、peer-review的な選別手順が含まれます。改善対象は、Agentの実装とWFそのものに近いです。

結果として、論文ではDGMがSWE-benchで20.0%から50.0%、Polyglot full benchmarkで14.2%から30.7%へ改善したと報告されています。ただし、ここで確認したいのは性能値そのものではありません。重要なのは、最新候補だけを更新するのではなく、過去候補をアーカイブし、そこから親を選んで別の枝を伸ばす探索構造です。

WF改善に置き換えるなら、各WF案を候補としてアーカイブに保存します。保存するのは最終スコアだけではありません。プロンプト、Pythonコード、ノード構成、処理順、ツール設定、親に関する情報、変更ログ（diff）、実行トレース、Score Matrix、失敗理由をまとめて残します。

次に改善する親WFも、最新ベストだけから選ばないようにします。平均スコアが高い候補、特定の入力タイプに強い候補、まだあまり派生候補を作っていない候補、構造が別系統の候補を親として選べるようにします。

これはGEPAの話ともつながります。GEPAでは、トレースとScore Matrixを使って「どの候補がどの入力に強いか」を見ます。DGMでは、その候補を上書きせず、アーカイブとして残し、親選択の対象にします。この2つは組み合わせることで更に良くなりそうです。つまり、候補WFの実行トレースを残し、Score Matrixで得意不得意を見えるようにし、その候補を木としてアーカイブし、次に伸ばす親を選ぶ仕組みです。

この「どの親から次の枝を伸ばすか」という選択基準自体も、研究が進んでいます。DGMの後継として提案されたWangらの Huxley-Gödel Machine（HGM）は、ベンチマークのスコアが高い候補が良い子孫を生むとは限らない、という指摘しました。論文ではこれをMetaproductivity-Performance Mismatchと呼んでいます。

HGMが親選択に使うのは、候補自身のスコアではなく、その候補から派生した子孫たちの成績を集約した指標（CMP: Clade Metaproductivity）です。子孫の成功と失敗の件数から「この系統はまだ伸びるか」を推定し、Thompson samplingで次に展開する候補を選びます。論文では、SWE-bench Verifiedの60件サブセットでHGMが56.7%に到達し、同条件のDGM（53.3%）を上回りつつ、必要なCPU時間はDGMの1231時間に対して517時間だったと報告されています。

WF改善に持ち込むなら、候補WFごとに「この候補から派生した改善案のうち、何件が親を上回ったか」を記録するイメージです。現在のスコアが高くても派生案がことごとく失敗している候補より、スコアは2番手でも派生案の成功率が高い候補のほうが、次の親として有望かもしれません。アーカイブを設計するなら、スコアと一緒にこの「派生の成功率」も持っておく価値があります。

アーカイブは、行き詰まったときの退避先にもなります。PACEvolveは、改善の勢い（momentum）が閾値を下回ったら、有望だった過去の反復に戻ってコンテキストをリセットするmomentum-based backtrackingを提案しています。失敗の履歴を引きずったまま同じ枝を掘り続けるのではなく、過去の地点からやり直す。これは前章のContext Pollution（失敗履歴が次の候補生成を偏らせる）への対処でもあり、戻る先としての候補アーカイブがあって初めて成立する仕組みです。改善の履歴をすべてコンテキストに積むのではなく、何を見せて何を見せないかをハーネス側で管理する必要がある、と言い換えてもよいでしょう。

3. 候補の多様性を評価に入れる

複数候補を作っても、同じプロンプトを少し言い換えただけなら探索範囲は広がっていません。必要なのは、構造の違う候補を残すこと、そして「どれくらい違うか」を測れるようにすることです。

この発想を形にした手法として、進化計算にはMAP-Elitesがあります。解を性能だけで競わせるのではなく、解の特徴を軸にした表（マップ）を用意し、マスごとに最良の解を保持する手法です。全体で1位を1つ決めるのではなく、特徴の組み合わせごとのチャンピオンを残します。

Santosらの Diverse Prompts: Illuminating the Prompt Space of Large Language Models with MAP-Elites は、これをプロンプト探索に適用した研究です。プロンプトの構造を定義し、few-shotのshot数と推論深度を特徴軸として、MAP-Elitesでプロンプト空間を探索します。評価は7つのBigBench Liteタスクで行われ、プロンプトの構造の違いがLLMの性能にどう影響するかを分析しています。

この手法の面白いところは、最適化の成果物が「最強の1本のプロンプト」ではなく、「構造ごとのベストを並べた表（マップ）」になることです。shot数が多く推論指示が浅いマスのベスト、shot数ゼロで推論指示が深いマスのベスト、という形で残るため、どの構造がどのタスクに効くのかを比較できます。観点1や観点2で見た「単一のベストに収束させない」という方針を、多様性の軸を明示することで実現しているわけです。

ただし、多様性の測り方には注意が必要です。Quality-Diversity Red-Teaming: Automated Generation of High-Quality and Diverse Attackers for Large Language Models は、攻撃的プロンプト生成（red-teaming）の文脈の研究ですが、単語頻度や文埋め込みの類似度のような単純な指標では、攻撃戦略の意味のある違いを捉えられないと指摘しています。言い回しだけが違う候補を「多様」と数えてしまうと、地図は埋まっているように見えるのに、探索は実質的に広がっていない状態になります。

WF改善に置き換えるなら、多様性軸はプロンプトの言い回しではなく、設計の違いで持つべきです。たとえば、LLMを使うステップ数、コードで固定する範囲、失敗時のリトライ方針、入力を分割する粒度等です。こうした軸で候補を分類すると、「LLM呼び出し3回以内でコード正規化中心の案はまだ試していない」「分類を先に実施してタイプ別に処理を分ける案が空いている」のように、まだ探索していない設計領域が見えるようになります。

これはハーネスの作り方として、具体的な指示の形に落とせます。ハーネスが候補生成のAgentに出す指示を「このWFをもっと良くして」ではなく、「LLMステップ2以下、正規化はコード固定、という制約で案を作って」のように、地図の空いているマスを指定した依頼に変えるのです。記事の前半で見たアンカリングへの対策にもなります。初期設計と同じ構造の中で改善させるのではなく、違う構造を明示的に要求するからです。

多様性が必要になるのは、改善の途中だけではありません。CSEは、初期解が1つであること自体が局所最適の入口になると指摘し、最初から構造的に異なる複数のアルゴリズム戦略を生成するDiversified Planning Initializationを提案しています。貪欲法と動的計画法のように、言い回しではなく方針のレベルで異なる候補を初期集団として用意する方法です。WF改善でいえば、要件定義の段階から設計の異なるWF案を複数作るところまで含めて、探索の一部だと考えるべきなのだと思います。

多様性を残した、その先の話もあります。Wengらの Group-Evolving Agents: Open-Ended Self-Improvement via Experience Sharing（GEA） は、DGMのような「親1つから子1つを作る」木構造の進化を、グループ単位の進化に拡張した手法です。親グループの選択では性能を主基準にしつつ、新規性（既存候補との違い）を軽い補正として掛け合わせます。そして特徴的なのがexperience sharingです。各Agentが進化の過程で得たコード修正パッチ、実行ログ、失敗を含む評価結果をグループ内で共有し、別の枝で得られた発見を再利用します。論文では、SWE-bench Verifiedで71.0%に到達し、同じ数の候補Agentを進化させた条件のDGMベースライン（56.7%）を上回ったと報告されています。Polyglotでも88.3%で、DGMベースライン（68.3%）を上回っています。

GEAから持ち帰りたいのは、候補を分けて残すだけでは足りない、という視点です。枝Aの失敗分析で「日付の正規化はLLMではなくコードで固定すべき」と分かったなら、その教訓は別系統の枝Bにも使えるはずです。候補を分離して多様性を守りつつ、学んだことは枝をまたいで流す。アーカイブに過去の「候補」だけでなく過去の「教訓」も入れる設計です。これはPACEvolveが指摘したWeak Collaborationへの対処そのものです。CSEも、ステップごとの成功洞察と失敗教訓を記録して次の候補生成に注入するHierarchical Evolution Memoryを提案しており、同じような方針で改善を実施しています。

このような過去の失敗や何度も遭遇する出来事はskillsなどで我々は残していたりしますが、同じような仕組みがAgent改善サイクルでも必要ですね。

探索を変えても、頭打ちとコストは残る

最後に、探索構造を整えれば解決するのか、という点には留保が必要です。

1つ目は、モデルがフィードバックを取り込む能力そのものに限界があることです。Feedback Friction: LLMs Struggle to Fully Incorporate External Feedback は、正解と解法ステップを見ながら誤りをピンポイントで指摘する採点者役のLLMを用意し、回答役のLLMに最大10回まで再挑戦させる実験です。修正すべき内容を教えてもらえる理想的な設定にもかかわらず、正答率は理論上届くはずの水準の手前で頭打ちになりました。論文はこの現象をFeedback Frictionと名付け、確信度の高い誤答ほどフィードバックに抵抗しやすいことも報告しています。

この設定は、私が見ている停滞とよく似ていますが、重要な違いがあります。この実験では修正内容そのものが与えられており、探索の要素がありません。それでも頭打ちが残るということは、停滞には、探索構造で解ける部分と、モデルがフィードバックを取り込みきれない摩擦として残る部分の両方があるということです。本記事の観点が効くのは前者だけです。GTとの差分を見せ続ければいつかは前提を覆してくれる、という期待は持たないほうがよさそうです。

2つ目は、コストです。複数候補を残す探索は、その分だけ実行回数と評価回数が増えます。DGMやHGMの実験では、1回の探索に数百〜1000時間超のCPU時間が使われています。WF改善で同じ構造を作るなら、評価データのサブセット化や、見込みのない候補の早期打ち切り（プロンプト最適化手法の CAPO は、racingと呼ばれる仕組みでこれを実施しています）と、探索全体の予算設計をセットで考える必要があります。

また、自己改善の自由度を上げるほど、評価データやスコアリングの仕組み自体をAgentが書き換えるリスクも上がります。探索を強くするほど、評価の保護も強くする必要があります（もちろん、プロンプトに答えを書いてしまうなどのleak対策も必須です）。

おわりに

Agentはなぜ最初の前提を覆せないのか。ここまで見てきた範囲では、AgentやLLMの能力不足というより、単一の候補を単一のスコアで磨き続けるという探索構造（ハーネス）が原因である可能性が高いです。最初の要件定義書がアンカーとなり、自己反省は同じ推論経路をなぞり、グローバルベスト1本の近傍だけが探索される。この構造のままでは、どれだけ「もっと良くして」と頼んでも、前提を覆す案は出てきません。

抜け出すための観点は3つに整理しました。

  1. 複数の候補を並行して改善する（GEPA）
  2. 過去の候補をアーカイブして再利用する（DGM・HGM）
  3. 候補の多様性を評価に入れる（Diverse Prompts・GEA）

いずれも、Agentの賢さに期待するのではなく、前提を覆せる探索構造をハーネス側で用意するというアプローチです。

私自身は、各章の後半に書いていたように、それぞれの対処法をWF改善のAgentに徐々に適用していこうと思います。例えば、候補WFと実行トレースを木構造で残すこと、入力タイプ別のScore Matrixを持つこと、...。非常にやることがたくさんありますが、モデルも日に日に賢くなっていることですし、このブログを読み込ませて自分で最強のハーネスを構築してほしいものです。

長々した文章を書いてしまいましたが、最後までご覧になって頂き、ありがとうございました！

最近話題のFDE(Forward Deployed Engineer)やLayerXについて興味のある方は是非以下のサイトからカジュアルにお話しましょう！

https://jobs.layerx.co.jp/opendoor/2d3cdd370bae8051a659fdd1dbd9d595/

References

脚注

  1. Lehman and Stanley, Abandoning Objectives: Evolution Through the Search for Novelty Alone ↩︎

LayerX
LayerXPublication

すべての経済活動を、デジタル化する。SaaS + Fintech に取り組む LayerX のエンジニアの記事が集まる Publication です。

Discussion