The World Won't Stay Still: Programmable Evolution for Agent Benchmarks

本論文は、現実世界の動的な変化を反映したエージェントの適応性を評価するため、環境・データ・スキーマを統一的なグラフとして表現し、その変換を通じてスケーラブルかつ制御可能な環境進化を実現するフレームワーク「ProEvolve」を提案するものである。

要約

「世界は止まらない」：AI エージェントの新しいテスト方法

この論文は、「AI エージェント（人間に代わって作業をする AI）」を、現実世界のように「移り変わる環境」でテストする新しい方法を提案しています。

これまでの AI のテストは、まるで**「静止した水族館」のようでした。水槽（環境）は固定され、魚（データ）も道具（ツール）も一切動きません。しかし、現実の世界は「生きた森」**のように常に変化しています。新しい木が生えたり、道が閉鎖されたり、新しい動物が現れたりします。

この論文は、その「生きた森」をシミュレーションし、AI が変化にどう適応できるかを測るための**「プログラム可能な進化システム（ProEvolve）」**を紹介しています。

---

1. 問題点：なぜこれまでのテストではダメなのか？

これまでの AI のテストは、**「固定されたおままごと」**でした。

• 例： 「注文する」という道具があり、「商品データ」が決まっている。
• 現実： 明日には「キャンセル機能」が追加され、明後日には「古い検索ボタン」が消えるかもしれません。

これまでのテストでは、AI が**「変化に対応できるか」を測れていませんでした。まるで、「常に同じ道しか歩かない練習」**をして、突然「道が崩れて新しいルートが必要になった時」にどうするかを評価していないのと同じです。

2. 解決策：ProEvolve（プロ・エボリューション）とは？

著者たちは、環境を**「レゴブロックの図面（グラフ）」**として表現し、それをプログラムで自動的に書き換えるシステムを作りました。

① 環境を「つながりの図」で描く

AI が使うデータや道具を、**「点（ノード）」と「線（エッジ）」**でつなげた図（グラフ）で表します。

• 点： ユーザー、商品、注文、クーポンなど。
• 線： 「注文には商品が含まれる」「クーポンは注文に使える」などの関係。

② 進化を「図の書き換え」として行う

この図に対して、3 つの魔法のような操作（プログラム）を施して、環境を進化させます。

1. 完成（Completion）：「新しい機能を追加」
   • 図に新しい点と線を足します。
   • 例：「価格アラート」という新しい機能を作るために、図に「価格履歴」の点と「通知」の線を追加する。
2. 飽和（Saturation）：「ショートカットを作る」
   • 遠回りな線を、直接つなぐ新しい線を引きます。
   • 例：「ユーザー→注文→商品→在庫」と 3 回たどる代わりに、「ユーザーの購入履歴を直接見る」という新しい線を引いて、AI の作業を楽にする。
3. 廃止（Deprecation）：「古い機能を消す」
   • 点や線を消します。
   • 例：「カート機能」がメンテナンスで使えなくなる。AI は「カート」を使わずに、別の方法で注文を進めなければならない。

3. 実験：200 種類の「生きた世界」を作ってみた

著者たちは、このシステムを使って、1 つの「オンラインショップ」の環境から、200 種類もの異なる進化バージョンを自動生成しました。

• 結果： 合計 3,000 個のタスク（課題）を作り、最新の AI モデル（GPT-5 や Claude など）をテストしました。

発見された驚きの事実

• AI は「変化」に弱い： 環境が進化すると、AI の性能が劇的に変わることがわかりました。あるバージョンでは完璧にできたのに、次のバージョン（道具が削除された時）では全くできなくなることもありました。
• 過去の経験は万能ではない： 「前の会話の内容を記憶させる」だけでは、環境の変化には対応できませんでした。AI は「過去の記憶」をそのまま使うのではなく、**「新しい状況に合わせて思考をリセットし、再構築する」**能力が必要だとわかりました。
• コストと性能のトレードオフ： 難しい環境では、AI はより多くの道具を使って、より長く会話をする傾向がありました。しかし、それが必ずしも成功につながるとは限りませんでした。

4. この研究の重要性

この研究は、**「AI が現実世界で生き残るためには、静的なテストではなく、動的な進化のテストが必要だ」**と示しました。

• これまでのテスト： 「同じ道で走る練習」
• この研究のテスト： 「道が常に変わり、時には橋が崩れる森で、どうやって目的地にたどり着くか」を練習させること。

これにより、私たちが使う AI アシスタントは、API が変わったり、システムが更新されたりしても、パニックにならずに柔軟に対応できる、よりタフで賢い存在になるはずです。

---

まとめ：一言で言うと？

「AI のテストを、静止した水族館から、常に進化する生きた森に変えた」
これがこの論文が世界に伝えたいメッセージです。AI が本当の意味で「賢い」かどうかは、変化にどう向き合うかで決まるのです。

技術概要

論文「The World Won't Stay Still: Programmable Evolution for Agent Benchmarks」の技術的サマリー

本論文は、大規模言語モデル（LLM）駆動のエージェントの評価において、静的な環境から動的に変化する環境への移行という重要な課題を提起し、それを解決するための新しいフレームワーク「PROEVOLVE」を提案するものです。現実世界では API、データスキーマ、ツールが継続的に進化しますが、既存のベンチマークは固定された環境を前提としており、エージェントの適応性を十分に評価できていません。

以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳細にまとめます。

---

1. 問題定義 (Problem)

現在の LLM エージェント評価の多くは、以下の点で現実との乖離があります。

• 静的な環境仮定: 既存のベンチマーク（SWE-bench, WebArena など）は、固定されたツールセットとデータスキーマを持つ「スナップショット」環境を前提としています。
• 進化の欠如: 現実世界では、新しい機能の追加、既存ツールの更新、古い機能の廃止（Deprecation）が継続的に起こります。
• 構成要素の非整合性: 既存のアプローチは単にツール数やデータ量を増やすだけで、ツール、データ、スキーマ間の整合性（Coherence）を維持したまま環境を進化させるメカニズムが欠けています。

これにより、エージェントが環境の変化（ダイナミクス）に対してどのように適応し、ロバスト性を維持できるかを包括的に評価することが困難になっています。

2. 手法：PROEVOLVE (Methodology)

著者らは、環境をグラフとして明示的にモデル化し、そのグラフ変換を通じて環境をプログラム可能に進化させるフレームワーク「PROEVOLVE」を提案しました。

2.1. グラフ形式化 (Graph Formalism)

環境のバージョンをタイプ付き関係グラフ $G = (V, E)$ として表現します。

• ノード ($V$): スキーマ要素（例：User.user_id, Order.order_id）やデータエンティティ。
• エッジ ($E$): 型付き関係や、ツールによる遷移（情報源からターゲットへのマッピング）。
• 進化の定義: 環境の進化は、グラフ変換の系列として定義されます。
  $$G^{(0)} \xrightarrow{\Delta^{(1)}} G^{(1)} \xrightarrow{\Delta^{(2)}} \dots \xrightarrow{\Delta^{(K)}} G^{(K)}$$
  ここで、$\Delta^{(k)}$ は現実世界の環境変化を模倣する構造化された操作です。

2.2. 進化のプログラム化 (Programming Evolution)

一貫性のあるグラフ変換を自動的に生成するために、3 つの戦略を用いたエージェントパイプラインを導入しています。

1. Completion (機能追加): 現在のグラフがサポートしていない機能（例：「価格アラート」）を提案し、必要な新しいノード（エンティティ）とエッジ（ツール）を追加します。
2. Saturation (効率化): ランダムウォークなどを用いて間接的な関係性を発見し、複数の操作をまとめた「ショートカットツール」を追加して利便性を高めます。
3. Deprecation (機能廃止): 特定のノードやエッジ（ツール/API）を削除し、システムメンテナンスやサービス終了をシミュレートします。これにより、代替手段の探索やエラーハンドリングをエージェントに求めます。

これらの戦略は LLM エージェントによって提案・実装され、ユニットテスト付きの可実行コード（データモデル、ツール実装）として生成されます。

2.3. タスクサンドボックスの生成 (Task Sandboxes)

進化後の環境 $G^{(k)}$ において、タスクは制約付き部分グラフサンプリングとして生成されます。

• サブグラフサンプリング: 特定のタスクを達成するために必要なスキーマ/ツールの範囲（部分グラフ）を抽出します。
• サンドボックス具体化: 抽出された部分グラフに基づき、必要なエンティティと状態を初期化します。
• エージェント歩行 (Agentic Walk): 参照となるマルチターン対話経路を生成します。各ターンで、ユーザー指示（状態ごとのゴール）と、エージェントが実行したツール呼び出し、そして到達可能なノードの拡張（コンテキストの拡大）を記録します。

2.4. 評価指標

タスクの成功は「終点でのみ」評価するのではなく、状態ごとの成功率 (State-wise Success Rate) で評価します。

• 各状態 $t$ において、必要な情報（グラフから導出された事実）が取得できたかを確認します。
• 状態ごとの成功を累積し、経路全体の成功率 $C(\tau)$ を算出します。これにより、エージェントが依存関係のあるリクエストを順を追って処理できるかを詳細に測定できます。

3. 主要な貢献 (Key Contributions)

1. 動的環境評価の定式化: エージェント評価を「静的スナップショット」から「進化環境」へ移行させるための、最初の明示的な研究問題の定式化と体系的な手法の提供。
2. プログラム可能な進化フレームワーク: グラフ変換を用いて、一貫性を持ちながらスケーラブルに環境を進化させ、自動的にタスクサンドボックスを生成する仕組みの実装。
3. 大規模な検証: 1 つのeコマース環境から、200 の環境変種と 3,000 のタスクサンドボックスを生成し、代表的な LLM エージェント（GPT-5, Claude-Opus, DeepSeek-V3 など）をベンチマークしました。

4. 実験結果 (Results)

e コマースシナリオを用いた実験では、以下のような知見が得られました。

• 環境進化による性能の不安定性: エージェントの性能は環境のバージョンによって大きく変動しました。
  • 例：GPT-5 は機能追加（Completion）フェーズでは性能が向上しましたが、機能廃止（Deprecation）フェーズでは急激に低下しました。
  • 逆に、DeepSeek-V3.2 は進化を通じて一貫して性能が低下する傾向を示しました。
  • この結果は、静的な環境での評価だけでは、エージェントの適応性の真の姿（脆さやモデル固有の適応戦略）を見逃すことを示唆しています。
• リプレイ戦略の効果: 過去の対話履歴（History Replay）や要約（Reflection Replay）を利用しても、性能向上が保証されるわけではありません。
  • DeepSeek-V3.2 はリプレイ戦略により大幅な性能向上を示しましたが、ツール呼び出し回数が増加しました。
  • 他のモデル（Claude-Opus など）では、リプレイ戦略が過剰な探索や誤った自己修正を招き、性能が低下するケースも見られました。
• コストとロバスト性のトレードオフ: 難易度の高いタスクでは、成功率を高めるためにツール呼び出し回数や会話ターン数（コスト）が増加する傾向があり、モデル間で「高コスト・高成功」と「低コスト・低成功」のトレードオフが明確になりました。

5. 意義と将来展望 (Significance)

• 現実的な評価基準の確立: 本フレームワークは、API やスキーマが変化する現実世界のデプロイ環境におけるエージェントのロバスト性を評価するための標準的な手法を提供します。
• 失敗モードの特定: 静的なベンチマークでは隠蔽されがちな、環境変化に対するエージェントの脆弱性（脆さ）を特定し、より堅牢なエージェント開発を促します。
• 将来の方向性:
  • 環境進化を認識し、明示的に適応するエージェント戦略の開発。
  • 効果的な進化順序を設計するためのカリキュラム学習の適用。
  • 多様なドメインへの拡張による、エージェントロバスト性の一般原則の解明。

結論として、本論文は「世界は静止しない」という前提に立ち、エージェント評価のパラダイムを静的なスナップショットから、プログラム可能な動的進化へと転換させる重要な一歩を踏み出しました。