論文解説: 共進化するエージェント系 — 人間の設計を超えた自己進化への三段階

「デプロイ後も賢くなり続けるエージェント」はなぜ頭打ちになるのか。相手・環境・進化の仕組みそのものを順に動かしていく三段階の分類を、サーベイ論文の本文から1から解説する。定義の式、各段階の代表手法、評価と安全の未解決点まで。

Co-Evolution in Agentic Systems: Toward Self-Directed Evolution Beyond Human Design

走るのをやめた瞬間に、置いていかれる

同じ場所にとどまるためだけでも全力で走り続けなければならない——『鏡の国のアリス』の赤の女王の話です。生物学ではこれを赤の女王効果と呼び、捕食者が速くなれば獲物も速くなる、という終わらない追いかけっこを説明する言葉として使われます。

今回のサーベイ論文は、この考え方をAIエージェントに持ち込みます。出発点はこうです。エージェントは「デプロイした後も勝手に賢くなる」ことを期待されているのに、いま主流の自己進化は、たいてい片側しか動かない（§1）。

「自己進化」がぶつかる天井

自己進化とは、人手を介さずにエージェントが経験・フィードバック・失敗から自分を更新し続けることです。よくある形は単一主体の自己進化——モデル本体を追加学習する、記憶を書き換える、スキルを増やす、といった1体の中で閉じた更新です（§1）。

論文が指摘する問題は、その更新が固定された学習文脈に囲まれていること。タスクは固定、フィードバック規則も固定、相手も固定。同じベンチマークを繰り返し解く、いつも同じ相手とだけ対戦する、報酬の付け方は人が決めたまま動かさない——どれも学習文脈が止まっている状態です。片側だけが適応しても、いずれ伸びしろが尽きます。「進歩を続けるには片側だけの適応ではなく相互の適応が要る」——これが赤の女王効果の読み替えです（§1）。

まずエージェント系を定義する

論文はここを曖昧にしません（§2.1）。エージェント系 $S=(A,E)$ は、エージェントの集まり $A$ と環境 $E$ からなります。個々のエージェントは次のように分解されます。

つまり、エージェント1体（$a_i$）は「頭の中身」と「持ち物」を組にしたものにすぎない、という宣言です。

$m_i$ はモデル本体（LLMなどの中身）、$h_i$ はハーネス（記憶・ツール・スキル・プロンプト・ワークフローといった周辺装備）です。実務の言葉に直せば、$m_i$ は追加学習で動く部分、$h_i$ はプロンプトやツール定義、メモリのスキーマといったコードとして触れる部分にあたります。同じモデルを共有していても、ハーネスが違って役割や目的が異なれば別のエージェントとして扱います。そして「進化した」とは、

つまり中身か装備のどちらかが変わったとき、そのエージェントは進化した、という定義です。$\Delta$ は「前回からの変わり分」、$\iff$ は「左と右は同じ意味」、$\lor$ は「または」。これは、追加学習をしたときだけが進化ではなく、プロンプトを1行書き換えただけでも進化に数えるということです。

さらにエージェントはただの集合ではなく、役割・通信トポロジ・分業を表す構造 $\Pi$ を伴って $A=(\{a_1,\dots,a_n\},\Pi)$ と書かれます。$\Pi$ が変わるだけでも $A$ は進化した扱いです。環境 $E$ は $A$ の外側すべて、$\tau^t$ は思考→行動→観測のサイクルの履歴です。エージェントの基本構造が怪しい人は、先にLLMエージェントの基礎を読むと以降が楽になります。

共進化の条件は「互いに押し合っている」こと

進化を駆動する仕組みを $\Omega$ と置き、$S^{t+1}=\Omega(S^t,\tau^t)$ と書きます。$\Omega$ は何を・いつ・どのように・どこで進化させ、その良し悪しをどう評価するかを決める規則の束です（§2.2）。

そのうえで論文は共進化を、「少なくとも2つの進化単位が同時に適応し、互いのその後の進化条件を作り替え合うこと」と定義します。情報を交換した、やりとりした、では足りません。片方が強くなった結果として、もう片方の直面する問題が変わる——この双方向の圧力があって初めて共進化です。

手早い判定法があります。片側を固定して同じ実験を回し、結果が変わらないなら、それは相互作用であって共進化ではない。この線引きがあるから、サーベイは多くのマルチエージェント研究を対象外にできています。分類はこの「どこまで動かしてよいか」の境界が広がる順に、三段階で並びます（§2.3）。

段階1: 相手が動くから、自分も動く

エージェント–エージェント共進化（§3）は、環境を固定したまま、仲間や敵の進化が自分の進化を駆動する段階です。

敵対（§3.1）は互いを倒すと報酬が入る関係。系譜はGANや、外乱を加える敵対者に対して頑健な制御方策を鍛えるRARLに遡ります。いまの中心はLLM安全性で、脱獄プロンプトを作る攻撃側と拒否を学ぶ防御側を同時に育てる形です。すでに見つかった攻撃をわざと効かなくして、攻撃側が数パターンに潰れるのを防ぐ設計が代表例です（§3.1.1）。相手を1体から増やす方向もあり、本体＋弱点を突く搾取者＋過去バージョンで戦わせるリーグ学習が古典例です（§3.1.2）。

協調（§3.2）は目的を共有する関係。並列型で目を引くのは、最終成果ではなく議論の過程そのものから報酬を作る（ある発言が後続の回答を修正・説得したか）手法です。役割分業型の基本形は「書く役と直す役」で、助言が相手の次の応答を実際に良くしたときだけ報酬を与える設計もあります。組織の進化（§3.3）はさらに上の層で、実行ログから不整合が見えたらチーム構成 $\Pi$ 自体を組み替えます。

段階2: 環境まで動かす

エージェント–環境共進化（§4）では環境の側が変わります。論文は「何が次の進化を主に駆動するか」で3つに切り分けます。

タスク空間（§4.1）は次に何を解かせるか。既存プールから選ぶ系（学習の伸びに応じたカリキュラム）と、新しく作る系（解答側の成功率に合わせた難易度較正、失敗ロールアウトのタスク化、タスクごとの検証関数）に分かれます。細かいが効く線引きが1つ——タスクを作るのがエージェントでも、それが同じタスク内で競争・協調する仲間でないなら環境の進化として数える（§4.1.2）。

フィードバック空間（§4.2）は評価・報酬・診断の側が変わる話。候補の報酬関数で方策を訓練しその失敗から報酬関数を書き換える、単体テストを実行失敗から進化させる、といった手法です。さらに整合性を条件に足す系が目立ちます——複数の批評器の順位が一致したときだけ更新する、助言に従ったら実際に方策が良くなったときだけ診断器を更新する。下地は指示チューニングとRLHFと地続きで、違いは報酬モデルを固定物ではなく共進化する相手として扱う点です。

相互作用空間（§4.3）は行動する世界そのもの。弱点を突くレベルを生成する、上達に合わせてシミュレーションのランダム化幅を広げる。エージェント集団を統治する規則を作る例（税制の学習、世代をまたぐ社会規範）や、世界モデルで実環境そのものを置き換える方向まで含まれます。

段階3: 進化の仕組み自体を進化させる

メタ共進化（§5）は $\Omega$ を人間が固定するのをやめる段階です。自己生成の改訂プロセス $\Gamma^t$ を入れて、

上の式が「進化のやり方を書き換える」、下の式が「書き換わったやり方でシステムを進める」。つまり、まず自分たちのルールブックそのものを書き直し、次のラウンドはその新しいルールブックで戦う、という二段構えです。$\Gamma^t$ が改訂役で、その材料は現在のシステム $S^t$・いまのルール $\Omega^t$・これまでの行動履歴 $\tau^t$ の3つ。$\Omega$ は5つの決定に分解されます——何を進化させるか、いつ（失敗・停滞・分布シフトの後）、どのように、どこで（サンドボックスか実環境か）、どう評価するか（§5.1）。

動機は段階1・2の観察です。図4のまとめでは、段階1・2はほとんどの設定で性能を上げるものの、進化が停滞に近づくにつれて伸びが小さくなるとされています（§5.1）。ただし著者らは正直で、この段階に該当する研究はほとんどないと書きます。変異プロンプトや自己改変機構、記憶アーキテクチャを進化させる手法は単一主体の先行例であって、下位に共進化するシステムを持たないからです（§5.2）。

「共進化ではないもの」との線引き

付録Aは紛らわしい概念を1つずつ潰していきます。実はここが一番使えます。

• マルチエージェント相互作用: 通信・協調・競争しても、自分が変わらなければ違う。持続的な更新が複数側に残って初めて共進化。
• ハーネス工学: 記憶やツールを設計するだけでは進化ではない。モデルとハーネスが両方変わっても、それは1体の進化。
• 自己対戦: 自分のコピーや過去版と戦うのは、現在の学習者しか変わらないなら自己進化止まり。

図4を鵜呑みにしない読み方

論文は自前で実験していません。図4は先行研究が報告した結果の要約で、モデルもベンチマークも指標も違うため生スコアは合算していない、と付録Cに明記されています。採用条件は「同じバックボーン・同じ評価設定で、相手が固定か進化かだけが違う対照条件」を持つ論文だけ。軌跡は掲載図から近似的に数値化したものを含み、影の帯は論文間のばらつきであって信頼区間ではありません。傾向の可視化であって、性能保証ではないということです。

この論文の限界

著者ら自身が2点挙げています（Limitations）。第一に、メタ共進化はまだ初期段階で、定義を満たす研究が限られるため、議論の多くを単一主体のメタ進化という先行例に頼っている。第二に、安全とガバナンスが具体化されていない。共進化特有の失敗モードは指摘するものの、望ましい要件のレベルにとどまる。加えてサーベイである以上、新しい実験証拠はここにはありません。

現場ではこう使う

誰が、いつ: エージェント基盤やRL学習パイプラインを回すチームと、評価・レッドチーム側。「自己改善ループを入れたのに伸びが止まった」ときに、どこを可変にすべきかの地図として使えます。

触る対象: 対戦相手の集合（リーグ、過去バージョンのスナップショット）、報酬モデル／検証器のバージョン、タスク生成器の難易度目標（解答側の成功率をターゲットに較正）、そして学習に使わない held-out 評価者。段階1なら「相手を固定するのをやめる」、段階2なら「タスクか報酬か世界のどれを可変にするか1つだけ選ぶ」が最初の一手です。

落とし穴は§6の3つがそのまま実務の失敗モードになります。(1) 評価者の悪用 — 評価者ごと共進化させるとスコアは伸びるのに中身は搾取的になりうる。(2) パートナー過適合 — 一緒に育てた相手には強いが未知の相手・環境で落ちる。(3) 多様性崩壊 — 攻撃側が少数モードに潰れ、防御側がそれだけに強くなる。対策は固定ベンチマークとプロセス評価の併用——過去バージョンとの交差対戦、構成要素のアブレーション、学習に使っていない評価者での再測定（§6）。設計レビューでいちばん効く問いは「この改善は、相手を固定したままでも出たのか」で、答えられないならその対照条件を先に作るのが正解です。評価設計の基礎は過学習と評価と共通します。

ガバナンスはサンドボックス化した実行、継続的な監視、検証済み状態へのロールバック、人間の介入点の確保（§6）。ロールバック先の「検証済み状態」を先に決めておかないと、共進化が進んだ後で戻る場所がなくなります。

まとめ

• 主張は「単一主体の自己進化は固定された学習文脈に囲まれて頭打ちになる。伸ばすなら相手側も動かせ」
• 三段階は動かしてよい範囲の広がり: 仲間や敵 → タスク・フィードバック・世界 → 進化の仕組みそのもの
• 判定条件は「双方が持続的に変わり、互いのその後の進化条件を作り替える」。単なる相互作用や自己対戦は含まない
• 未解決は評価・スケール・安全。評価者の悪用とパートナー過適合は、スコアが上がるほど見えにくくなる