Abstract

大規模言語モデル（LLM）ベースのエージェントシステムの最近の進歩は、複雑かつ長期的なタスクを解決する上で有望な成果を示しています。しかし、既存のエージェントプロトコル（A2A や MCP など）は、エンティティ間のライフサイクル管理やコンテキスト管理、バージョン追跡、そして安全な更新インターフェースの仕様を十分に定めていません。この欠如は、モノリシックな構成と壊れやすい「のり付けコード（glue code）」の蔓延を招いています。私たちは、何が進化するかという対象と、どのように進化するかというメカニズムを分離する自己進化プロトコルである「AUTOGENESIS PROTOCOL (AGP)」を導入します。そのリソース基板プロトコルレイヤー（RSPL）は、プロンプト、エージェント、ツール、環境、メモリを、明示的な状態、ライフサイクル、バージョン管理されたインターフェースを持つプロトコル登録済みリソースとしてモデル化します。また、自己進化プロトコルレイヤー（SEPL）は、監査可能な系譜とロールバック機能を備えた、改善の提案、評価、コミットを行う閉ループ演算子インターフェースを規定します。AGP に基づき、実行中にプロトコル登録済みリソースを動的にインスタンス化、取得、洗練する自己進化型マルチエージェントシステム「AUTOGENESIS SYSTEM (AGS)」を提示します。多様なリソースにわたる長期的な計画とツールの使用を必要とする複数の困難なベンチマークにおいて AGS を評価した結果、強力なベースラインと比較して一貫した改善が認められ、エージェントリソース管理と閉ループ型自己進化の有効性が実証されました。

1. はじめに

LLM ベースのエージェントシステムの最近の進歩は、複雑かつ長期的なタスクへの対処において顕著な可能性を示しています。しかし、静的なエージェント設計は、実世界の環境が持つ多様性や確率性に対峙する際、往にして不十分であることが証明されています。この限界を克服するため、環境からのフィードバックに基づいて戦略を自動調整し、指示を洗練し、ツールを更新する能力、すなわち「自己進化」能力をエージェントに付与することが、堅牢な自律性を実現するための重要な道筋として浮上しています。この事前定義された実行者から動的適応への移行は、エージェントシステム設計における根本的な転換を意味します。

自己進化型エージェントへの関心が高まっているにもかかわらず、その実装は依然として断片的かつその場限りのものが大半です。既存のシステムには共有された標準規格が欠如しており、進化プロセスが構成可能でも監査可能でもありません。開発者はしばしば壊れやすい「のり付けコード」への依存を余儀なくされ、維持が困難なモノリシックなアーキテクチャにつながっています。さらに、明示的なライフサイクル管理と安全な更新インターフェースがなければ、自己修正は実行時の不安定さという重大なリスクをもたらします。これらの問題に対処するには、開発を実装レベルからプロトコルレベルへと昇華させ、「何が進化するか」と「どのように進化するか」を分離する標準化された枠組みを通じて、モジュール式で追跡可能、かつ安全な進化を確保する必要があります。

Anthropic 社の Model Context Protocol (MCP) や Google 社の Agent-to-Agent (A2A) などのプロトコルは接続性を標準化しましたが、これを自己進化シナリオに直接適用することは概念的な不一致を生じます。これらのプロトコルは主に、モデルとツールの呼び出し（MCP）やエージェント間通信（A2A）という接続性の課題を解決するために設計されています。しかし、自己進化の中核は呼び出しではなく、状態の変異とその管理にあります。

既存の接続性プロトコルには、エンティティのライフサイクルとバージョンの系譜をネイティブにサポートする機能が欠けています。閉ループ型進化システムにおいて、コンポーネントの作成、更新、破棄が正確に定義されていなければ、オプティマイザは安全に変更を適用できません。さらに、バージョン追跡とロールバック機構の欠如は、誤った更新が回復不可能なエラーにつながることを意味します。したがって、通信プロトコルへの依存だけでは不十分であり、変異のダイナミクスを管理できる新たなプロトコルが必要です。

接続性から進化へのギャップを埋めるため、専門のプロトコルは 3 つの本質的な問題に対処しなければなりません。

分離 (Decoupling): プロンプト、ツール、メモリなどのリソースは、エージェントのコアロジックから抽象化され、密結合したコードブロックではなく、受動的で独立して管理されるエンティティへと変換される必要があります。

安全性と監査可能性 (Safety & Auditability): 進化の各段階が追跡可能かつ元に戻せることを保証するため、厳格なバージョン管理とロールバック機構を導入する必要があります。

形式化 (Formalism): 発見論的なテキスト修正を厳密な制御ループに変換するため、進化プロセスを厳密に管理する標準化された演算子（例：反映、提案、検証）を定義する必要があります。

これらの課題に対処するため、私たちは「AUTOGENESIS」を導入します。単なるユーティリティライブラリではなく、AUTOGENESIS は進化的基盤と進化的論理を厳密に分離するように設計された 2 層のプロトコルアーキテクチャです。私たちの核心的な動機は、基盤となるリソース表現を標準化し、多様なエージェントコンポーネント全体で同じ最適化アルゴリズムをシームレスに適用可能にすることです。

• レイヤー 1：リソース基板プロトコルレイヤー (RSPL)。このレイヤーは進化の基盤を定義し、プロンプト、エージェント、ツール、環境、メモリをプロトコル登録済みリソースとしてモデル化します。RSPL はこれらのリソースに明示的な状態、ライフサイクル、バージョン管理されたインターフェースを付与し、観察と操作が可能な標準化されたオブジェクトへと変えます。
• レイヤー 2：自己進化プロトコルレイヤー (SEPL)。このレイヤーは制御理論に基づいた閉ループ演算子インターフェースを確立します。Reflect（反映）、Select（選択）、Improve（改善）、Evaluate（評価）、Commit（コミット）という原子的操作を定義し、すべての自己修正が文書化され、厳格な安全制約に準拠していることを保証します。

このプロトコルに基づき、推論と行動を行うツール呼び出しエージェントである「AUTOGENESIS AGENT」を提示します。ハードコードされたコンポーネントに依存するのではなく、実行中にプロトコルインターフェースを介してリソースを動的にインスタンス化、取得、洗練します。GPQA、AIME、GAIA、LeetCode を含む複数の困難なベンチマークでこのシステムを評価した結果、標準化されたリソース管理と閉ループ進化を活用することで、AUTOGENESIS AGENT が強力なベースラインを一貫して大幅に上回る性能を達成することが実証されました。

本研究成果の重要性は性能向上の域を超えており、手動によるプロンプトエンジニアリングから自動化されたプロトコルエンジニアリングへの潜在的な転換を示唆するものです。エージェントに標準化された自己修復・進化能力を備えさせることで、AUTOGENESIS は複雑な環境下で持続的な自律的適応が可能な次世代エージェントシステムを構築するための基盤的パラダイムを提供します。

2. 関連研究

2.1. LLM ベースのエージェントシステムとツール使用

大規模言語モデル（LLM）ベースのエージェントシステムにおける最近の進展は、多段階の推論と外部ツールの相互作用を必要とする複雑かつ長期的なタスクを解決する能力を実証しています。これらのシステムにおいて、LLM は通常、観察を解釈し、タスクを分解し、環境に作用するためにツールを呼び出す中央集権的な意思決定モジュールとして機能します。GAIA などのベンチマークは、エージェント設計における構造化されたツール使用と計画能力の重要性をさらに浮き彫りにしました。

既存のほとんどのエージェントフレームワークは、プロンプト、ツール、メモリが密結合した内部コンポーネントとして埋め込まれたアーキテクチャを採用しています。ツールは通常、手動でキュレーションされ、エージェントパイプラインに統合された固定された機能モジュールとして扱われます。これは限定されたタスクには効果的ですが、タスク要件の進化に伴うツールの体系的な再利用と制御された適応を制限します。対照的に、私たちのアプローチは、ツール（ネイティブスクリプト、MCP ツール、エージェントスキルを含む）を、明示的なインターフェースと状態表現を持つプロトコル登録済みリソースとしてモデル化し、実行中の動的なインスタンス化と制御された洗練を可能にします。

2.2. 接続性と相互運用性プロトコル

エージェントベースのシステムが規模と複雑さを増すにつれ、モデルとツールの相互作用やエージェント間通信を標準化するためのいくつかのプロトコルレベルの取り組みが登場しました。Anthropic 社の Model Context Protocol (MCP) は、言語モデルを外部ツールやデータソースに接続するための統一インターフェースを提供します。同様に、Google 社の Agent-to-Agent (A2A) プロトコルは、複数のエージェント間のコラボレーションをサポートする通信プリミティブを標準化することを目指しています。

これらのプロトコルは、主に呼び出しとメッセージングのレベルでの相互運用性に対処しています。これらはエージェントとツールがどのように相互作用するかを規定しますが、エージェントとリソースの内部状態は不透明なまま残しています。特に、リソースのライフサイクル管理、バージョンの系譜の追跡、時間経過に伴う状態変異の制約を定義するメカニズムを欠いています。その結果、接続性プロトコルは統合を簡素化しますが、自己修正型エージェントシステムに必要な永続的な状態の進化を直接サポートするものではありません。

2.3. 自己修正と最適化メカニズム

並行する研究分野として、自己修正と最適化を通じてエージェントのパフォーマンスを向上させるメカニズムを探るものがあります。TextGrad などの手法は、自然言語のフィードバックを勾配に類似した信号として解釈し、プロンプトなどの文字列値コンポーネントに対する反復更新を可能にします。また、強化学習に基づくアプローチもエージェントの改善に適用されています。Reinforce++ や GRPO などの手法は、エージェントコンポーネントを方策として扱い、評価信号を報酬として使用して最適化を導きます。

これらの手法はエージェントの行動が反復的に改善可能であることを示していますが、通常は狭い範囲の設定内でのみ適用され、異種のエージェントコンポーネントを管理するための共有された抽象化を欠いています。更新は、明示的なライフサイクル制御、バージョン追跡、ロールバックサポートなしに、プロンプトや方策に直接適用されることがよくあります。AUTOGENESIS は、エージェントコンポーネントを標準化された進化的リソースとして公開し、異なる最適化手法が制御された方法で適用されることを可能にする演算子レベルのインターフェースを定義することで、これらの最適化戦略を 수용するプロトコルレベルの抽象化を提供します。

2.4. 要約

エージェントシステム、相互運用性プロトコル、自己最適化に関する既存の研究は、自律的行動のための重要な基盤を築きました。しかし、これらの取り組みは、エージェント内部リソースの永続的な状態の進化を管理するための統一されたプロトコルを提供していません。特に、現在の接続性プロトコルは相互作用を重視しますが、ライフサイクル管理やバージョン化された状態変異には対処していません。AUTOGENESIS は、進化的リソースの定義とその進化を支配するメカニズムを分離する 2 層のプロトコルアーキテクチャを導入することでこのギャップを埋め、マルチエージェントシステムにおけるモジュール式で追跡可能、かつ監査可能な自己進化を可能にします。

3. Autogenesis

自己進化型エージェントへの関心が高まっているにもかかわらず、ほとんどのシステムはまだその場限りに設計されており、進化を構成可能、監査可能、相互運用可能にする共有されたプロトコル標準を欠いています。私たちは 2 層の自己進化プロトコルである AGP を導入します。リソース基板プロトコルレイヤー（RSPL）は、どのリソースが変化し得るか、そしてそれらがどのように表現、バージョン管理、アクセスされるかを規定する進化的基盤を規定します。自己進化プロトコルレイヤー（SEPL）は、更新が安全な演算子インターフェースを通じてどのように提案、評価、コミットされるかという進化ロジックを規定します。エージェントツーリングにおけるインターフェース標準化の取り組み（例：Model Context Protocol）に触発され、この分離により「何が進化するか」と「どのように進化するか」が明確に分離され、コンポーネント全体でのモジュール性、追跡可能性、安全性を維持した進化が可能になります。

3.1. レイヤー 1：リソース基板プロトコルレイヤー (RSPL)

リソース基板プロトコルレイヤー（RSPL）は、明示的な状態、ライフサイクル、バージョンの系譜を持つプロトコル登録済みリソースの集合として進化的基盤を定義します。本論文では、これらのリソースは (i) 指示（プロンプト）、(ii) 意思決定方策（エージェント）、(iii) 作動インターフェース（ツール。ネイティブツールスクリプト、MCP ツール、エージェントスキルを含む）、(iv) タスク/世界のダイナミクス（環境）、(v) 永続的状態（メモリ）で構成されます。重要なのは、RSPL におけるリソースは「受動的」であるという点です。これらは最適化ロジックをカプセル化せず、自己修正することはできません。すべての観察と状態遷移は、上位レイヤーによって呼び出される、制御されたインターフェースを介した操作を介してのみ発生します。

3.1.1. 中核エンティティ

私たちは、エージェントシステムのための最小限でありながら表現力豊かな基盤として、これら 5 つのエンティティタイプに焦点を当てています。この選択は網羅的であることを意図するものではなく、むしろ現代のエージェントスタック全体に共通する分母を特定し、SEPL が動作するための均一なターゲット空間を提供することを目的としています。

定義 3.1（リソースエンティティ）。タイプ τ のリソースエンティティとそのタイプレベルのコレクションは、次のように表すことができます。

$$e_{\tau ,i}=(n_{\tau ,i},d_{\tau ,i},{\varphi }_{\tau ,i},g_{\tau ,i},m_{\tau ,i}),E_{\tau }=\{e_{\tau ,i}\mid i\in I_{\tau }\}$$

ここで、$T=\{\text{PROMPT},\text{AGENT},\text{TOOL},\text{ENV},\text{MEM}\}$ は RSPL エンティティタイプの集合を表し、$\tau \in T$ はエンティティタイプをインデックスし、$I_{\tau }$ はタイプ $\tau$ のリソースインスタンスのインデックス集合、$i\in I_{\tau }$ は個々のインスタンスをインデックスします。ここで、$n_{\tau ,i}$ は固有のリソース名、$d_{\tau ,i}$ は短い説明、${\varphi }_{\tau ,i}:X_{\tau }\to Y_{\tau }$ は入力から出力へのマッピング、$g_{\tau ,i}\in \{0,1\}$ はリソースが進化可能かどうかを示す学習可能マーカー、$m_{\tau ,i}$ は補助メタデータ辞書です。

プロンプト、ツール、メモリを明示的な RSPL リソースとする主な動機は「分離」です。多くのエージェントシステムは、プロンプト、ツール、メモリをエージェントの内部コンポーネントとしてパッケージ化しており、これによりエージェントロジックがタスク固有の指示や機能バンドルと絡み合い、メンテナンスが増大し、転用が制限されます。これらを標準化されたインターフェースを持つファーストクラスのバージョン管理リソースとして外部化することで、同じツール呼び出しエージェント方策を異なるプロンプトやツールセットと組み合わせ、タスクや環境を変えずにデプロイすることが可能になります。

リソースの登録、統合管理、インスタンス化をサポートするため、RSPL は各リソースインスタンスに対してシリアライズ可能な登録レコードを保存します。

定義 3.2（リソース登録レコード）。リソース登録レコードとそのタイプレベルのコレクションは、次のように表すことができます。

$$c_{\tau ,i}=(e_{\tau ,i},v_{\tau ,i},{\eta }_{\tau ,i},{\theta }_{\tau ,i},F_{\tau ,i}),C_{\tau }=\{c_{\tau ,i}\mid i\in I_{\tau }\}$$

ここで、$\tau \in T$ はエンティティタイプをインデックスし、$i\in I_{\tau }$ は個々のインスタンスをインデックスします。ここで、$e_{\tau ,i}$ は定理 3.1 で定義されたリソースエンティティタプル、$v_{\tau ,i}\in V$ はバージョン文字列、${\eta }_{\tau ,i}$ は実装記述子（例：インポートパス、クラス定義、またはソースコード文字列）、${\theta }_{\tau ,i}$ はインスタンス化パラメータ（例：コンストラクタ引数）、$F_{\tau ,i}$ は LLM がリソースと対話するために使用されるエクスポートされた表現の集合（例：関数呼び出しスキーマ、自然言語テキスト、構造化引数スキーマ）です。

定義 3.3（プロトコル登録済みリソース）。各エンティティタイプ $\tau$ について、$R_{\tau }$ をプロトコル登録済みリソースのタイプ固有のレジストリとし、$R={\bigcup }_{\tau }{R}_{\tau }$ をグローバルレジストリとします。RSPL は各エンティティタイプ $\tau$ を専用コンテキストマネージャ $M_{\tau }$ およびサーバー公開インターフェース $A_{\tau }$ にバインドします。タイプレベルの登録済みリソースは次のように表されます。

$$r_{\tau }=(C_{\tau },M_{\tau },A_{\tau })$$

ここで、各 $c_{\tau ,i}\in C_{\tau }$ は定理 3.2 の登録レコードです。コンテキストマネージャ $M_{\tau }$ はコレクション $C_{\tau }$ とタイプ $\tau$ のバージョン系譜を維持し、これらのレコードに対するライフサイクルおよび更新操作を実装します。サーバー公開インターフェース $A_{\tau }$ は $M_{\tau }$ をカプセル化し、要求を対応するコンテキストマネージャのルーチンに委譲することで、統一された外部インターフェースを公開します。

コンテキストマネージャ。コンテキストマネージャは、各リソースタイプの管理プレーンを実装します。ライフサイクル制御と依存関係の制約を超えて、(i) 具体化されたリソースのアクティブなレジストリ、および (ii) 復元のためのバージョン履歴を維持します。そのエクスポートされた API は、ライフサイクルと登録（例：init、build）、取得と検査（例：list、get_state）、進化とバージョン管理（例：update、restore）、実行と契約（例：run、load_contract）、シリアライゼーションとデシリアライゼーション（例：save_to_json、load_from_json）のための機能的にグループ化された演算子の小さなセットと見なすことができます。マネージャは明示的に「契約生成」をサポートしており、管理対象エンティティのための統合された機能と制約の仕様を生成します。これにより、安定した最新の説明が提供され、信頼性が向上し、プロンプトの肥大化が削減され、制御されたプロンプト注入による体系的なコンテキストエンジニアリングが可能になります。例えば、ツール（ネイティブスクリプト、MCP ツール、エージェントスキルを含む場合がある）の場合、契約はツールアクション、引数、前提条件、使用制約を列挙する skills.md 形式を取ることができます。

サーバーインターフェース。サーバーは、コンテキストマネージャの内部の複雑さをカプセル化し、外部呼び出し手に安定した簡素化されたインターフェースを提示するために導入されます。これは、実装の詳細をコンテキストマネージャに委譲しつつ、一貫した要求/応答のセマンティクスを持つ統一されたエンドポイントの背後に、多種多様な管理ルーチンをパッケージ化します。この分離により、クライアントは内部設計の変更から隔離され、結合が低減され、プロトコルが RSPL リソースとの安全でバージョン対応の相互作用を仲介するための単一の制御プレーンが提供されます。

3.1.2. インフラストラクチャサービス

RSPL には、信頼性の高い進化をサポートする横断的サービスがさらに含まれています。これらには、再現性、安全なデプロイ、バージョン化されたリカバリなどがあります。

• モデルマネージャ: プロバイダー（OpenAI、Anthropic、Google、OpenRouter など）間での呼び出しを標準化する統一モデル API レイヤー。コンポーネントが進化するにつれてモデルアクセスを一貫して保つためのルーティング、フォールバック、コスト対応の選択をサポートします。
• バージョンマネージャ: 各リソースのバージョン系譜を維持し、ロールバック、分岐、差分を可能にします。バージョンは、登録時または更新時に割り当てられる自動増分識別子（例：セマンティックバージョン）であり、監査可能性と再現性のために、構成レコードと関連アーティファクトの不変スナップショットを参照します。
• ダイナミックマネージャ: 永続化と転送のためのリソース構成のシリアライゼーションまたはデシリアライゼーションを処理し、エージェントシステムを再起動することなく実行時におけるリソースの安全なホットスワップを可能にします。
• トレーサーモジュール: 解釈可能性とデバッグのため、またデータセット合成と事後的改善のためのトレーニング信号として、細かな実行情跡（入力、出力、中間決定、ツール相互作用など）をキャプチャするモジュールです。

3.2. レイヤー 2：自己進化プロトコルレイヤー (SEPL)

自己進化プロトコルレイヤー（SEPL）は、エージェントシステムの進化のための制御理論に基づく形式主義を確立します。これは、エージェントシステムの継続的な改善を、異種混合状態空間上で定義された一般化された最適化問題として概念化します。形式的には、SEPL は進化ダイミクスを、厳密に型付けされた演算子代数によって支配される状態遷移関数としてモデル化します。

すべての状態変異を標準化された RSPL インターフェースを介して仲介することで、プロトコルは進化が追跡可能、可逆的、かつ構造的に安全であることを保証します。本論文では主に内省駆動型のオプティマイザに焦点を当てていますが、私たちの実装は、同じ状態操作プリミティブを使用して、TextGrad、GRPO、Reinforce++ などの他の最適化戦略もサポートします。

3.2.1. 進化可能変数

発見論的適応から体系的な進化プロトコルへ移行するため、私たちは「変数の持ち上げ (variable lifting)」という概念を導入します。この抽象化は、離散的かつ異種混合の RSPL リソース（例：ツールコード、システムプロンプト）を、進化可能変数の統一された表現へ投影します。この形式化は、進化的演算子のための相互作用面を均質化し、明示的な学習可能性マスクを通じて訓練可能な部分空間を厳密に区画化することで、重要な理論的利点を提供します。

定義 3.4（進化可能変数集合）。管理されたすべてのリソースエンティティと実行アーティファクトの和集合として、進化可能変数の普遍集合 $V_{evo}$ を定義します。

$$V_{evo}=\left(\bigcup _{\tau \in T}{E}_{\tau }\right)\cup \{y\}$$

ここで、$E_{\tau }$ は RSPL によって管理されるタイプ $\tau$ のリソースエンティティの集合を表します。要素 $y$ は実行アーティファクト、具体的には最終出力と推論トレージをカプセル化し、これらは事後的な最適化のための観察的基盤を構成します。さらに、各変数 $v\in V_{evo}$ は二値の学習可能性制約 $g_v\in \{0,1\}$ に関連付けられ、これにより訓練可能なパラメータ部分空間 $\Theta =\{v\in V_{evo}\mid g_v=1\}$ が厳密に定義されます。

3.2.2. 演算子代数

進化的軌道を厳密な制御プロセスとして形式化するため、状態遷移関数を、反復的最適化の標準的な段階（観察、帰属、提案、検証、コミット）に対応する原子的操作に分解します。その結果、プロセスが数学的に適切に定義されることを保証するための 5 つの必要な補助空間を確立します。トレース空間 $Z$ はシステムの観測可能性を保証し、仮説空間 $H$ は意味的エラー帰属の基盤を提供し、修正空間 $D$ は修正プリミティブを形式化し、目的仕様 $G$ は最適化ランドスケープを定義し、評価空間 $S$ はパフォーマンス指標と安全性の状態をカプセル化します。これらのコンポーネントは、自己進化ループを閉じるために必要な最小限の十分条件を構成します。

• Reflect ($\rho$): $\rho :Z\times V_{evo}\to \wp (H)$ と定義されます。この演算子は生の観察と最適化方向の間のギャップを埋めます。高次元の実行トレースを、変数空間内の具体的かつ因果的な失敗仮説にマッピングすることで、システムの「意味的勾配」を近似します。
• Select ($\sigma$): $\sigma :V_{evo}\times \wp (H)\to \wp (D)$ として定式化されます。この演算子は生成的方策として機能します。診断された仮説を具体的な更新提案に変換し、構造制約に従って特定されたエラー信号を最小化するように設計された候補修正 $D$ をサンプリングします。
• Improve ($\iota$): 変異演算子であり、$\iota :V_{evo}\times \wp (D)\to V_{evo}^{\prime }$ です。標準化された RSPL インターフェースを介して離散更新 $D$ を適用し、暫定的な候補状態を生成することで、物理的な状態遷移を実行します。
• Evaluate ($ϵ$): $ϵ:V_{evo}^{\prime }\times G\to S$ として指定されます。この演算子は目的関数として機能します。候補状態と目標仕様を評価空間 $S$（定量的スコアと厳格な安全不変量で構成）にマッピングします。
• Commit ($\kappa$): $\kappa :V_{evo}^{\prime }\times S\to V_{evo}$ として機能します。この関数は条件付きゲーティングメカニズムとして作用します。特定の成功基準が満たされた場合にのみ候補 $V_{evo}^{\prime }$ を受け入れることで、評価空間 $S$ の信号を使用して状態遷移を制御し、安全不変量とパフォーマンスの単調性を厳密に強制します。

3.2.3. 進化ループ

上記で定義した原子的操作は、アルゴリズム 1 に要約される厳密な閉ループプロセスに編成されます。初期状態 $V_{evo}^{(0)}$ から始まり、SEPL はシステムを反復的に実行して観察トレース ($Z$) を生成し、因果的な失敗仮説 ($H$) を導き出し、修正プリミティブ ($D$) を合成します。

重要なのは、このループが評価空間 $S$ とコミット演算子 $\kappa$ によって閉じられていることです。この設計により、自己進化は単なるランダムウォークではなく、実行情報に基づき、バージョン管理された更新を通じて追跡可能で、厳密に定義された安全不変量のもとで単調に改善される誘導された軌道であることが保証されます。

4. AGS と最適化戦略

このセクションでは、AGP プロトコルの具体的な実装例を示し、自己進化型エージェントシステムとしての実用的な有用性を実証します。

4.1. AGS アーキテクチャ

AGP に基づき、2 層のプロトコルを AGS（自己進化型マルチエージェントシステム）として具体化します。これはエージェントバスアーキテクチャを中心に構成されています。AGS は、単一の巨大なコントローラーや剛直なパイプラインに依存するのではなく、共有メッセージバスを中央の調整バックボーンとして使用します。すべてのエージェントは標準化されたバスメッセージを介して排他的に通信し、これにより疎結合、透明な観測可能性、並列サブエージェント実行が可能になります。すべての構成において、プロンプト、ツール（ネイティブスクリプト、MCP ツール、エージェントスキルを含む）、メモリは、ハードコードされた内部コンポーネントではなく、明示的なライフサイクルとバージョンの系譜を持つファーストクラスの RSPL リソースとして扱われます。システムは 3 つの相互作用するメカニズムを通じて動作します。

計画生成によるオーケストレーション: エージェントバスからタスクを受け取ると、オーケストレーターは計画と調整のみを担当し、サブタスクを直接実行することはありません。具体的には、オーケストレーターは、実行グラフの人間が読めるフローチャート、サブタスクステップの順序付きリスト、各サブタスクの担当サブエージェント（例：ディープリサーチャー、ブラウザ使用エージェント、ツール呼び出しエージェント、ツール生成エージェント）への割り当てを記録する構造化された plan.md アーティファクトを生成します。この計画はバージョン管理された RSPL リソースとして登録され、調整構造自体を検査可能かつ進化的にします。その後、オーケストレーターは各サブタスクとその仕様をバスを介して対応するサブエージェントにブロードキャストします。

並列サブエージェントの実行と反復的再計画: ブロードキャストされたサブタスクを受信すると、各サブエージェントは、セマンティック検索を介して RSPL レジストリから関連するプロンプトとツールのリソースを独立して取得し、ツール呼び出しを実行して環境と対話し、中間結果と推論トレースを永続的で照会可能な状態として共有メモリに書き込みます。サブエージェントは並列に動作します。バスはタスクのディスパッチと完了を分離するため、複数のサブエージェントが同期のオーバーヘッドなしに並列で実行される可能性があります。現在のラウンドのすべてのサブエージェントが完了すると、オーケストレーターはバスを介してそれらの出力を収集し、集約された結果を要約して、現在の実行状態で plan.md を更新します。このグローバルな見解に基づき、オーケストレーターはタスクが完了したか、それともサブタスクの分解とブロードキャストのさらなるラウンドが必要かを決定します。この収集と再計画のループは終了条件が満たされるまで繰り返され、システムが任意の深さと分岐の複雑さを持つタスクを処理することを可能にします。

自己進化: バス調整ループと連動して、AGS は観察トレースが修正可能な失敗や最適ではないパフォーマンスを示すたびに、SEPL 進化ループ（アルゴリズム 1）をトリガーします。具体的には、エージェントは (i) 実行トレース $Z$（ツールの出力、エラー、遅延、報酬信号、タスクの進行状況）を反映して因果的な失敗仮説 $H$ を導き出し、(ii) 進化可能変数（例：プロンプトテキスト、ネイティブスクリプトのツールソースコード、MCP ツールの構成、スキル定義、または計画構造そのもの）に対する標的を絞った修正提案 $D$ を選択し、(iii) 候補更新を適用して暫定状態 ${\tilde{V}}_{evo}$ を生成し、(iv) 候補を目的 $G$ に対して評価し、(v) 受け入れられた修正を、監査可能な系譜とロールバックを備えたバージョン管理された遷移としてコミットします。失敗した進化の試みは副作用なくロールバックされ、成功したものはその後のバスラウンドですべてのサブエージェントが即座に利用可能になります。この緊密な統合により、進化はエージェントネットワークの全寿命を通じて常に安全で、追跡可能で、構成可能であることが保証されます。

4.2. オプティマイザの具体化

AGP プロトコルは特定の最適化戦略に依存しません。5 つの演算子の SEPL インターフェース（$\rho ,\sigma ,\iota ,ϵ,\kappa$）に準拠するあらゆる手順が進化エンジンとして機能できます。実験で使用した主要な具体化について記述し、実装でサポートされている代替戦略の概要を簡単に説明します。

内省オプティマイザ: 実験のデフォルトのオプティマイザは、自然言語の内省を通じて SEPL ループを実装します。実行トレース $Z^{(t)}$ と現在の進化可能状態 $V_{evo}^{(t)}$ が与えられると、Reflect 演算子 $\rho$ はバックボーン LLM にプロンプトを出し、失敗を分析して自然言語での構造化された診断仮説 $H^{(t)}$（例：「プロンプトにエッジケース処理のための明示的な指示がない」「ソートアルゴリズムが重要なパスで O(n^2) の複雑さを持っている」など）を生成させます。次に、Select 演算子 $\sigma$ はこれらの仮説を、システムプロンプトへの制約条項の追加や関数本体の書き換えなどの具体的な修正提案 $D^{(t)}$ に変換します。Improve 演算子 $\iota$ はこれらの提案を RSPL の変数設定インターフェースを介して適用し、候補状態を生成します。Evaluate 演算子 $ϵ$ は候補状態の元でタスクを再実行し、パフォーマンスを目的 $G$ と比較します。最後に、Commit 演算子 $\kappa$ は、パフォーマンスが向上するか、安全不変量が維持される場合にのみ更新を受け入れ、それ以外の場合は直前のバージョンにロールバックします。この内省駆動ループは、固定された予算 $T$ ラウンドにわたって繰り返されます。

代替戦略: 内省に加え、私たちの実装は同じ SEPL 演算子インターフェースに自然にマッピングされる追加の最適化戦略をサポートしています。

• TextGrad: $\rho$ によって生成された自然言語フィードバックを「テキスト勾配」として扱い、文字列値変数（プロンプト、コード）に対して勾配降下法に類似した更新を適用します。AGP 内では、TextGrad は $\sigma$ を勾配情報に基づく提案生成器として、$\iota$ を文字列レベルの編集演算子として具体化し、標準的な $ϵ$ と $\kappa$ を評価とゲーティングに再利用します。
• Reinforce++ / GRPO: 強化学習の視点を取り入れ、進化可能変数を方策として、評価信号を報酬として扱います。ここでは、$\rho$ が複数の候補軌道をサンプリングし、$\sigma$ がそれらを報酬でランキングし、$\iota$ が方策勾配推定値を介して方策パラメータ（例：プロンプトの重みや LoRA アダプタ）を更新し、$\kappa$ は更新された方策がベースラインの報酬閾値を超えた場合にのみコミットします。これらの戦略は、SEPL 演算子代数が推論時テキスト最適化と勾配ベースのパラメータ更新の両方を統一されたプロトコル内で収容するのに十分に一般的であることを示しています。

5. 実証研究

このセクションでは、AGP プロトコルを備えた AGS をさまざまな困難なベンチマークにデプロイした際の実証結果を提示し、その包括的な能力を実証します。

ベンチマークの指示: GPQA-Diamond（198 問）については、閉じたブック（参照なし）の評価プロトコルを採用します。エージェントには大学院レベルの STEM 多肢選択問題（生物学、化学、物理学をカバー）が提示され、最終的な答えとして正確に 1 つのオプションを出力する必要があります。GPQA-Diamond は「Google プルーフ（Google 検索で解けない）」ように設計されており、単純な Web 検索では不十分で、事実の暗記を超えた困難な多段階の科学的推論を必要とします。全体として、このベンチマークはエージェントの深い科学的理解と閉じたブックでの推論能力を測定します。AIME については、2024 年および 2025 年のアメリカ招待数学試験（AIME24 および AIME25）の問題を使用し、それぞれ 30 問で構成されます。各インスタンスでは、エージェントが競技レベルの問題を解き、単一の整数の答えを出力する必要があります。パフォーマンスは完全一致精度で評価され、これは主にエージェントの長期的な記号推論と算術精度を測定します。GAIA については、GAIA テストスプリット（300 タスク）で評価します。各タスクは、通常、計画とツールの使用（例：Web ブラウジング、ドキュメント/ファイル操作）を必要とする実世界の多段階目標を規定します。パフォーマンスはタスクの成功（完了）で測定され、これは主にエージェントの長期的な計画と信頼性の高いツール使用の実行を反映します。LeetCode については、削減されたデータ汚染の下での実行可能なコード生成を評価するために、社内の多言語プログラミングベンチマークを構築しました。広く流通している過去のからの潜在的なトレーニングデータ汚染を緩和するため、意図的に多様なカテゴリ（例：配列、木、リンクリストなど）から最近公開された問題を選択し、200 のトレーニング問題と 100 のテスト問題に分割しました。エージェントは複数の言語（Python、C++、Java、Go など）のいずれかで各問題を解決し、全体スコア（合格）、テストケース合格率、実行時間など、アルゴリズム的推論、実装の正確性、効率性を測定する複数の指標を報告します。

5.1. 科学および数学ベンチマークでの実験

5.1.1. 実験設定

AGP プロトコルに基づく自己進化型エージェント AGS を検証するため、GPQA-Diamond、AIME24、AIME25 全体で実験を行い、プロンプトとエージェント出力の進化に焦点を当てました。これらのベンチマークは、エージェントアーキテクチャ、メモリシステム、環境、ツールの進化が、指示の洗練や解決策の質と比較して比較的重要度が低い標準的な推論タスクを表します。プロンプトと解決策に対する自己進化機能を分離するため、この設定では AGS に外部ツールを一切装備せず、進化戦略として「プロンプトのみ進化」「解決策のみ進化」「プロンプト＋解決策の両方を進化」の 3 つを比較します。モデル機能全体を網羅的に評価するため、複数のバックボーンモデル（低性能モデル：gpt-4o、gpt-4.1、中性能モデル：claude-sonnet-4.5、高性能モデル：gemini-3-flash-preview、grok-4.1-fast）を使用して評価を行いました。私たちの自己進化アルゴリズムは主に内省オプティマイザを使用し、最大 3 ラウンドの最適化を行い、その後のエージェント出力を最終解決策とします。

指標: パフォーマンスは完全一致精度で測定します。GPQA-Diamond の場合、エージェントが選択したオプションが正解の多肢選択回答と一致する必要があります。AIME24 および AIME25 の場合、エージェントの数値出力が参照整数の答えと正確に一致する必要があります。

5.1.2. 結果と分析

表 1 の結果は、モデルと進化戦略全体にわたる 4 つの重要な観察結果を示しています。(1) 弱いモデルほど大きく向上し、強いモデルほど向上幅は小さい。より低いバニラ（初期）スコアを持つ gpt-4.1（AIME24 で 23.3%、AIME25 で 20.0%）は、「プロンプト＋解決策」の進化により、AIME24 で 71.4%、AIME25 で 66.7% 向上しました。対照的に、gemini-3-flash-preview は 83-88% から始まり、GPQA-Diamond で 2.3%、AIME ベンチマークの両方で 12.0% 向上しました。その理由は明白です。進化は内省中に明らかになったエラーを修正するものであり、弱いモデルほど修正可能なミスを多く犯し、強いモデルはすでに上限近くで動作しているからです。claude-sonnet-4.5 は中間層（バニラで 76-78%）に位置し、GPQA、AIME24、AIME25 でそれぞれ 4.0%、13.0%、22.7% 向上し、余力が進化の利益と相関することを確認しました。(2) 組み合わせ進化がプロンプトのみ、解決策のみのいずれよりも優位。全モデルにおいて、「プロンプト＋解決策」の進化が一貫して最高のスコアを記録しました。gpt-4.1 の AIME24 では、プロンプト進化が 33.3%、解決策進化が 36.7% であるのに対し、組み合わせアプローチは 40.0% に達しました。AIME25 でも同様の傾向が見られました。claude-sonnet-4.5 でも同様のパターンを示し、3 つのベンチマークすべてで単独戦略を上回りました。これは、指示の洗練と解決策の洗練が補完的な失敗モードに対処しており、組み合わせることで単独よりも多くのエラーを修正できることを示唆しています。(3) 数学ベンチマークは科学 QA よりも強く反応する。AIME24 と AIME25 は、GPQA-Diamond よりも大きな相対的改善を示しました。gpt-4.1 では GPQA が 3.9% 向上したのに対し、AIME24 は 71.4% 向上しました。gemini-3-flash-preview でも GPQA は 2.3%、AIME 両ベンチマークは 12.0% 向上しました。長期的な記号推論（多段階の導出、算術チェーン）は、内省が標的とできる中間的な失敗点をより多く露呈させますが、閉じたブックの科学 QA は事実の暗記に依存することが多く、プロンプトや解決策の洗練によるレバーレッジが限られるためです。(4) 飽和したベンチマークでは天井効果が進化を抑制する。grok-4.1-fast は AIME24 でバニラ状態で 96.7% に達しており、改善の余地がほとんどありません。そのため、そこでの進化による利益は見られませんでした。しかし、ベースラインがより低い GPQA と AIME25 では、それぞれ 7.2%、7.4% 向上しました。これは、自己進化がモデルの能力とベンチマークの難易度の両方に改善の余地がある場合に最も効果的であることを裏付けています。

要約すると、AGS は実験全体を通じて、多様なモデル機能とベンチマーク全体で一貫した利益をもたらしました。強力なモデルは控えめですが確実に向上し、十分な余地がある場合、弱いモデルは大幅に向上しました。組み合わせのプロンプト＋解決策進化戦略は一貫して単独戦略を上回り、数学ベンチマークは科学 QA よりも反復的洗練からより大きな恩恵を受けました。

5.2. 一般エージェントベンチマークでの実験

5.2.1. 実験設定

GAIA については、ツール機能の進化に焦点を当てました。GAIA タスクは純粋な推論ではなく、主にツール機能に依存するためです。私たちのシステムアーキテクチャは、最上位のプランナーエージェント（$m=50$）と、複数の専門サブエージェント（ディープリサーチャー $m=3$、ブラウザ使用エージェント $m=3$、レポートエージェント、ツール生成エージェント $m=3$、ディープアナライザーエージェント $m=3$）で構成されます。すべてのエージェントはバックボーンモデルとして gemini-3-flash-preview を使用します。ここで $m$ はエージェントあたりの最大推論ステップ数を示します。ツールの自己進化は主にツール生成エージェントによって推進されます。サブタスクが与えられると、まず管理されたツールレジストリからセマンティック検索を介して候補ツールを取得します。適切なツールが見つかった場合、エージェントはそれを実行しようとしますが、エラーが発生すると内省を介してツールのソースコードを反復的に洗練します。適切なツールが存在しない場合、エージェントは最初から新しいツールを合成し、将来の再利用のためにバージョン管理された RSPL リソースとして登録します。

指標: GAIA テストスプリットの Pass@1 スコアを採用し、各難易度階層（レベル 1、レベル 2、レベル 3）および全体平均でのタスク完了精度を報告します。

表 2 の結果は 3 つの重要な観察結果を示しています。(1) AGS は最先端のパフォーマンスを達成。平均スコア 89.04% により、AGS はすべての公開リーダーボードエントリーを上回り、次点の ToolOrchestra（87.38%）を 1.66 ポイント上回りました。この優位性は、特に最も難しい階層で顕著です。AGS はレベル 3 で 81.63% を記録し、HALO の 69.39%、AWorld の 57.14% を大きく引き離しました。これは、タスクの複雑さが最も高い場所で、進化駆動型の適応が最大の利益をもたらすことを実証しています。より簡単な階層でもギャップは狭まりますが一貫して維持され、レベル 1 は 98.92%（ToolOrchestra の 95.70% 対）、レベル 2 は 85.53%（HALO の 84.91% 対）に達し、ツールの進化が単一の難易度領域に限定されない広範な改善を提供することを示しています。(2) ツールの進化は困難なタスクで大きな利益をもたらす。バニラベースライン（平均 79.07%）と比較して、ツール進化は全体で 12.6% パフォーマンスを向上させました。改善は難易度に対して強く偏っており、レベル 1 は 8.2%、レベル 2 は 10.6%、レベル 3 は 33.3% の向上でした。このパターンは数学ベンチマークで見られた余力効果と一致しており、より困難なタスクは内省駆動型のツール進化が標的とできる修正可能な失敗モードをより多く露呈させます。特筆すべきは、レベル 3 での 33.3% という向上率は、本研究の全ベンチマークの中で最大の相対的改善率であり、静的なツールキットでは十分にカバーできない複雑な多段階ツールチェーンを必要とするタスクにおいて、ツールの進化が特に効果的であることを強調しています。(3) 階層的リソース管理が計画の複雑さを軽減。GAIA の多分野タスクは時間的およびクロスモーダルな状態の一貫性を必要とし、多くのベースラインはドメイン遷移（例：ブラウザ検索からローカルファイル分析へ）の過程で性能が低下します。プロンプト、ツール、環境を明示的なライフサイクル管理を持つファーストクラスの RSPL リソースとして扱うことで、AGS はエージェント境界を越えてセッションに不可欠な状態を維持し、文脈の忘却を減らし、レベル 2 およびレベル 3 のシナリオでの構成的な一般化を可能にします。さらに、プランニングエージェントが新しいサブタスクに遭遇した際、ツール生成エージェントを呼び出して文脈固有の機能をその場で合成し、静的なエージェントツールキットの固定機能のボトルネックをバイパスします。SEPL 演算子インターフェースを介して完全に仲介されるこの動的なツール作成および洗練ループにより、新しい機能がバージョン追跡され、後続のタスク全体で再利用可能であることが保証されます。

要約すると、GAIA での結果は、AGP の自己進化プロトコルが純粋な推論タスクを超えて、複雑でツール集約的なエージェントシナリオにまで拡張されることを確認しました。最大の利益は、反復的なツールの洗練と階層的リソース管理が最大のレバレッジを提供する、最も困難なタスク階層で生まれました。

5.3. アルゴリズム的コーディングベンチマークでの実験

5.3.1. 実験設定

ベンチマーク設計の根拠: 私たちのベンチマーク構築は、(i) 実行可能なコードに対する推論時自己進化の評価、(ii) 人間の提出物分布に対するエージェントパフォーマンスの較正、(iii) 長尾言語使用におけるクロスランゲージの堅牢性の評価、という 3 つの動機によって推進されています。私たちは、実行ベースの評価インターフェースと豊富なフィードバック信号を提供する LeetCode オンラインジャッジを基盤としています。具体的には、受理ステータスと各テストケースの合格率により、二値的成功を超えた機能的正確性のきめ細かい評価が可能になります。受理された提出については、プラットフォームは実行時間とメモリ使用量を報告し、人間の提出物の分布に対して計算されたパーセンタイルベースの実行時間ビートおよびメモリビート統計を報告します。これにより、人間を基準とした評価が直接サポートされます。最後に、LeetCode は多くのプログラミング言語にわたって標準化されたスターターコードを提供しており、統一されたプロトコルの下での一貫性のある再現可能な多言語評価を可能にします。

データ収集: クロール時に LeetCode で利用可能だった 3,822 個のプログラミング問題の全セットを収集しました。各問題について、自然言語の記述、公式の入出力例、言語固有のスターターコードテンプレートを抽出しました。各問題には、プラットフォーム提供の難易度ラベル（Easy、Medium、Hard）と、必要なアルゴリズム的概念（例：配列、木、動的計画法）を記述するトピカルタグが注釈付けられています。形式不良なレコードのフィルタリング、重複の削除、記述、例、テンプレートの構文解析の成功確認を含む品質チェックを実施しました。全プールから、トレーニングデータの汚染を軽減するために、多様なカテゴリにわたって最近公開された 100 のテスト問題を選択しました。

評価プロトコル: バニラベースラインと、解決策の進化を有効にした AGS を比較します。バニラベースラインでは、エージェントはモデルに対して固定された入力表現を提示し、決定論的に実行可能なソースコードを抽出し、ワンパスで実行ベースの判定器に提出します。AGS では、エージェントは 3 ラウンドという固定された修正予算内で SEPL 内省オプティマイザを介して解決策を反復的に洗練しますが、タスク仕様と評価インターフェースは変更しません。この制御された設定により、ワンショット生成と推論時の自己進化を解決策の質において直接比較できます。5 つの言語（Python3、C++、Java、Go、Kotlin）で評価を行い、複数のバックボーンモデルを使用して多次元指標を報告します。

指標: 表 4 に示すように、コーディングパフォーマンスの補完的な側面を捉える 3 つのグループの指標を報告します。第 1 に、機能的能力指標は、判定器の制約下での機能的正確性と失敗モードを測定します。第 2 に、効率性指標は、受理された提出の実行時間とメモリコストを要約します。第 3 に、人間指標は、受理された提出が実行時間とメモリの両方で人間の解決策の分布をどの程度上回るかを定量化します。

表 3 および図 2 の結果は、コーディング機能、効率性、人間基準の各次元全体にわたる 4 つの主要な調査結果を明らかにしています。(1) 自己進化は全言語で合格率を一貫して向上させる。解決策進化エージェントは、Python3 で 10.1% から Kotlin で 26.7% までの相対的な合格率の向上を達成し、コンパイル言語が最も恩恵を受けました。C++ は 100 問中 99 問、Java は 98 問に達しました。これらの向上は、実行を阻害するエラーの広範な減少を伴っています。コンパイルエラー、ランタイムエラー、タイムアウト、レスポンスエラーはしばしばゼロまで減少し、反復的な洗練が outright な失敗を引き起こす形式やツール設定の問題を効果的に修復することを示しています。図 2（1 段目）もこの調査結果を裏付けており、問題が蓄積するにつれて進化するエージェントの一貫して高い合格軌跡を示しています。(2) 進化は実行効率を向上させるが、メモリ効果はまちまち。平均実行時間は全言語で減少し、Python3 で 7.8%、コンパイル言語で 19.8-46.4% の削減となりました。図 2（2 段目）もこの傾向を確認しています。進化するエージェントは累積実行時間が大幅に低く、タスクが蓄積するにつれてその差が広がっています。このパターンは TLE エラーの減少と一致しており、内省が最適ではないアルゴリズムをより効率的なものと置き換えるのに役立つことを示唆しています。一方、メモリ使用量は一貫しない傾向を示しています。C++、Java、Go では減少していますが、Python3 と Kotlin ではわずかに増加しています。これは、進化するエージェントが正しさや速度を確保するために補助的なデータ構造を導入している可能性があるためと考えられます。(3) 進化した解決策は人間の提出物に対してより競争力を持つ。コンパイル言語では実行時間ビート（ARB）が大幅に増加し、C++ で 30.8%、Java で 24.4% の向上が見られました。Go（7.0%）や Kotlin（0.1%）でも小幅な向上が見られました。メモリビート（AMB）は Python3、C++、Java、Go で増加しましたが、Kotlin では減少しました（15.0% 減）。図 2（3 段目）は、進化するエージェントがほとんどの設定でバニラエージェントよりも高い ARB および AMB 軌跡を維持していることを示しており、推論軌道上で人間に対する競争力が一貫して向上していることを示しています。Kotlin の逸脱は絶対的なメモリ使用量の傾向と一致しており、長尾言語では進化するエージェントが正しさや速度のためにメモリをトレードオフしている可能性を示唆しています。(4) 推論内軌道は複合的な改善ダイミクスを明らかにする。エンドポイント指標を超えて、図 2 は自己進化の軌道レベルの分析を可能にします。3 つの指標グループすべてにおいて、進化するエージェントとバニラエージェントの差は、問題が蓄積するにつれてプラトー化するのではなく広がっています。これは、内省駆動型のオプティマイザが評価全体を通じて修正可能な失敗モードを見つけ続けていることを示唆しています。この複合的な振る舞いは、特に実行時間のパネルで顕著であり、累積的な効率性の向上が後半の問題で加速しています。

要約すると、アルゴリズム的コーディングベンチマークにおける自己進化は、5 つの言語すべてで機能的正確性と実行効率の両方において一貫した改善をもたらしました。特に、型システムとコンパイラからのフィードバックが内省により豊富なシグナルを提供するコンパイル言語で最大の利益が得られました。人間基準の指標は、これらの利益が人間の提出物とますます競合する解決策につながっていることを確認しています。推論内軌道の分析はさらに、AGP がエンドポイントスコアを向上させるだけでなく、単一の推論エピソードの最中に自己進化がいつ、どのように最大のレバレッジを提供するかについてのきめ細かい可視性を可能にすることを示しています。

6. 結論

私たちは、「何が進化するか」と「どのように進化するか」を分離する 2 層の自己進化プロトコル AGP を提示しました。リソース基板プロトコルレイヤー（RSPL）は、プロンプト、エージェント、ツール、環境、メモリを、明示的なライフサイクルとインターフェース契約を持つファーストクラスのバージョン管理リソースとしてモデル化します。自己進化プロトコルレイヤー（SEPL）は、監査可能な系譜とロールバックを備えた改善の提案、評価、コミットを行うための閉ループ演算子代数を規定します。このプロトコルに基づき、実行中に異種混合リソースを動的に取得、洗練、進化させる思考と行動の代理店である AGS を具体化しました。このプロトコルレベルの自己進化へのアプローチは、モジュール式で追跡可能、かつ安全に改善可能なエージェントシステムを構築するための原則的な基盤を提供すると信じています。

参考文献

• Anthropic. Equipping agents for the real world with agent skills. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills, 2025a. 2025 年 10 月アクセス.
• Anthropic. Introduction to agent skills. https://anthropic.skilljar.com/introduction-to-agent-skills, 2025b 年 10 月.
• Hu, J. Reinforce++: A simple and efficient approach for aligning large language models. arXiv preprint arXiv:2501.03262, 2025a.
• Hu, J. Reinforce++: A simple and efficient approach for aligning large language models. arXiv preprint arXiv:2501.03262, 2025b.
• LeetCode. Leetcode online judge. https://leetcode.com. 2025 年アクセス.
• Mialon, G., Fourrier, C., Wolf, T., LeCun, Y., and Scialom, T. Gaia: a benchmark for general ai assistants. In The Twelfth International Conference on Learning Representations, 2023.
• Rein, D., Hou, B. L., Stickland, A. C., Petty, J., Pang, R. Y., Dirani, J., Michael, J., and Bowman, S. R. Gpqa: A graduate-level google-proof q&a benchmark. In First Conference on Language Modeling, 2024.
• Shao, Z., Wang, P., Zhu, Q., Xu, R., Song, J., Bi, X., Zhang, H., Zhang, M., Li, Y., Wu, Y., et al. Deepseekmath: Pushing the limits of mathematical reasoning in open language models. arXiv preprint arXiv:2402.03300, 2024.
• Yuksekgonul, M., Bianchi, F., Boen, J., Liu, S., Lu, P., Huang, Z., Guestrin, C., and Zou, J. Optimizing generative ai by backpropagating language model feedback. Nature, 639(8055):609-616, 2025.

付録 A. 記法

主要な数学記号とその意味を表 5 に要約します。可読性を高めるため、記法は機能カテゴリ（灰色の行）ごとにグループ化されており、RSPL 基板（リソースエンティティ、登録レコード、レジストリ）と SEPL レイヤー（進化可能変数、補助空間、最適化ループで使用される演算子の定義）をカバーしています。

付録 B. 他のプロトコルとの比較

Autogenesis、Google A2A、Anthropic MCP の構造化された比較を表 6 に示します。この比較の目的は、エージェントツーリングにおいて広く使用されているプロトコル抽象化に対する Autogenesis の位置付けを明確にし、自己進化を実践的に構成可能、監査可能、かつ安全にするために必要なプロトコルレベルのプリミティブを明確にすることです。したがって、比較は 4 つの高レベル次元（灰色の行）に整理されています。基本情報、エージェントおよびシステム機能、進化可能リソース管理、自己進化メカニズムです。青色で強調表示された項目は、閉ループ改善を可能にする特定の機能（例：ライフサイクル制御、バージョン系譜、契約生成、演算子化された更新）を強調しており、これらは通信中心または呼び出し中心のプロトコルでは直接対処されていません。

B.1. 基本情報

提案者: この次元は、各プロトコルの発信組織と設計の文脈を特定します。Google の A2A は、標準化された相互作用プリミティブを介したエージェント間のコラボレーションを可能にすることに焦点を当てたエージェント通信フレームワークの一部として導入されました。Anthropic の MCP（Model Context Protocol）は、LLM が外部ツールやリソースに接続する方法を標準化するために設計されています。Autogenesis は、本論文で提案された、構成可能、監査可能、更新可能なエージェントシステムを対象とした体系的な自己進化のためのプロトコルです。

プロトコルの焦点: この次元は、各プロトコルが標準化する主要な相互作用パターンと制御プレーンを記述します。Autogenesis は、プロトコル演算子とバージョン管理された状態を介してリソースと更新を整理することにより、エージェントシステムの閉ループ改善を可能にすることに焦点を当てています。A2A はマルチエージェントのコラボレーションと通信に焦点を当てています。MCP はモデルからツール（およびリソース）への呼び出しインターフェースの標準化に焦点を当てています。

エンティティの範囲: この次元は、何がファーストクラスの、プロトコルによって管理されるコンポーネントとして扱われるかを定義します。Autogenesis は、異種混合エンティティ（プロンプト、エージェント、ツール、環境、メモリ）を、明示的な状態と系譜を持つプロトコル登録済みリソースとして明示的に管理します。これはコンポーネントレベルの進化（プロンプトの洗練、ツール/コードの更新など）に必要です。A2A はエージェント（およびその相互作用）を中核としており、通常、ツール/環境/メモリを統合された管理対象エンティティとしては確立しません。MCP はツール/リソースを LLM のための呼び出し可能インターフェースとして扱いますが、ライフサイクルとバージョンの系譜を持つ進化的コンポーネントとしてネイティブにモデル化はしません。

B.2. エージェントおよびシステム機能

エージェントのファーストクラス化: ファーストクラスサポートとは、エージェントが明示的なスキーマ、メタデータ、ライフサイクルフック（登録、発見、オーケストレーション、制御された更新を可能にする）を持つ管理対象プロトコルコンポーネントとしてモデル化されることを意味します。Autogenesis はエージェントをファーストリソースとしてサポートします。A2A はエージェント中心のコラボレーションを提供しますが、エージェントを統一されたライフサイクル/バージョン系譜を持たないサービスエンドポイントとして扱うことがよくあります。MCP はモデルからツールへの接続性に焦点を当てており、エージェントをプロトコルコンポーネントとして定義していません。

マルチエージェント: この次元は、プロトコルがその場限りのアプリケーションロジックを超えて、ネイティブにマルチエージェント構成をサポートするかどうかを捉えます。Autogenesis は、より広範なシステム基板の一部としてマルチエージェント構成をサポートし、追跡可能性と進化対応の状態を備えた調整された実行を可能にします。A2A はエージェント間コラボレーションを直接サポートします。MCP はプロトコルの関心事としてマルチエージェントオーケストレーションには対処していません。

トレーサー/観測可能性: 観測可能性とは、プロトコルがデバッグ、評価、学習信号のために実行トレース（入力/出力、中間決定、ツール呼び出し、状態遷移）を記録するネイティブメカニズムを提供するかどうかを指します。Autogenesis には、監査可能な進化をサポートするためのプロトコルレベルのトレーシングが含まれています。A2A および MCP は通常、トレーシングをアプリケーションレベルの実装に委ねており、観測可能性にばらつきが生じる可能性があります。

リソースとしてのメモリ: この次元は、メモリが明示的にモデル化され、プロトコルレベルのコンポーネントとして管理されているかどうかを反映しています。Autogenesis はメモリをファーストリソース（例：明示的なインターフェースを持つ読み書き可能な状態）として扱い、永続的な改善と再現可能な進化を可能にします。A2A および MCP は一般にメモリ管理プロトコルを規定しておらず、メモリを外部システムに任せています。

B.3. 進化可能リソース管理

ライフサイクル演算: ライフサイクル演算とは、プロトコル管理コンポーネントの初期化、登録、構築、廃止のための標準化された手順を指します。Autogenesis は、更新が明確に定義されたターゲットに安全に適用されることを保証するための明示的なライフサイクル演算子を提供します。A2A および MCP は、異種混合コンポーネントタイプ全体で包括的なライフサイクル管理を提供していません。

バージョニングとロールバック: バージョンの系譜とロールバックは、安全な進化の基盤を提供します。すべての更新が監査可能なスナップショットを生成し、比較をサポートし、後退が発生した際に復元を可能にします。Autogenesis はバージョン管理をプロトコル機能として統合しています。A2A および MCP は、プロトコル管理コンポーネントのバージョン系譜をネイティブにサポートしておらず、体系的な進化を困難にしています。

レジストリと取得: この次元は、プロトコルがコンポーネントの統一された登録、リスト表示、取得（オプションでセマンティック検索経由）をサポートし、再利用とスケーラブルな調整を可能にしているかどうかを捉えます。Autogenesis はプロトコル登録済みコンポーネントのレジストリを維持し、重複を減らし構成可能性を向上させるための取得をサポートします。A2A および MCP は部分的な発見メカニズムを提供しますが、異種混合コンポーネント上の統一された管理プレーンを定義していません。

契約生成: 契約生成とは、信頼性の高いオーケストレーションとプロンプトの肥大化削減のために、統合された最新の機能と制約の仕様（例：ツールアクション、引数、前提条件、使用制約）を生成することを指します。Autogenesis は、体系的なコンテキストエンジニアリングの形態として契約生成をサポートします。A2A および MCP は一般に、プロトコルレベルの契約集約なしに、静的な記述またはアプリケーションレイヤーのドキュメントに依存しています。

B.4. 自己進化メカニズム

閉ループ進化: 閉ループ進化とは、プロトコルが一度きりの適応ではなく、反復的な改善ループ（実行 → 診断 → 提案 → 検証 → コミット）をサポートすることを意味します。Autogenesis は、持続的な改善を可能にするために、このループを明示的に中心に設計されています。A2A および MCP はネイティブな自己進化ループを提供していません。

演算子化された更新: この次元は、システム更新が型付けされた構成可能な演算子インターフェース（その場限りのスクリプトではなく）として表現されるかどうかを捉え、制御された状態遷移と再現可能な進化を可能にします。Autogenesis は、自己進化をプロトコル管理リソース上の演算子によって仲介される遷移として定義します。A2A および MCP は進化のための演算子代数を定義していません。

監査可能性: 監査可能性とは、システムの変更が追跡可能かつレビュー可能であることを意味します。何が変更されたか、なぜ変更されたか、どのような証拠に基づいているか、どのような評価結果であったかです。Autogenesis は、バージョン管理された系譜とトレースベースの評価信号を通じて監査可能性を強調しています。A2A および MCP は、プロトコルレベルの保証ではなく、外部ツールを介して部分的な監査証跡のみを提供します。

B.5. 一般およびエコシステム

モデル非依存: この次元は、プロトコルが異なる LLM バックエンドおよびプロバイダー間で機能するかどうかを捉えます。Autogenesis は統一モデルインターフェースレイヤーを介して設計上モデル非依存です。A2A および MCP も、相互作用の標準を定義し、特定のモデルにバインドしないため、広義にはモデル非依存です。

スケーラビリティ: スケーラビリティは、コンポーネントの数が増加するにつれて、調整と発見がどのように振る舞うかを反映します。Autogenesis は、異種混合コンポーネントを取得メカニズムを備えたレジストリ管理リソースとして扱うことでスケーラブルな管理をサポートし、効率的なルックアップと制御されたオーケストレーションを可能にします。A2A は、大規模なマルチエージェント設定で相互作用が密になるにつれて調整のオーバーヘッドに直面する可能性があります。MCP はツールインターフェースを標準化しますが、大規模なツール/リソースセットについては依然としてアプリケーションレベルのオーケストレーションに依存する可能性があります。

オープンエコシステム: オープンエコシステムのサポートとは、プロトコルが相互運用可能なコンポーネントの再利用可能なエコシステムを有効にできるかどうかを指します。Autogenesis は、エージェントコンポーネントの管理、進化、監査のための完全なプロトコルスタックを提供し、コンポーネントの共有と安全な統合をサポートします。A2A および MCP は、相互運用性またはツールインターフェースに焦点を当てた部分的なエコシステムの実現を提供しますが、通常、進化対応の管理には追加のレイヤーを必要とします。

付録 C. 自己進化プロトコルの詳細

C.1. レイヤー 1：リソース基板プロトコルレイヤー

リソース基板プロトコルレイヤー（RSPL）は、明示的な状態、ライフサイクル、バージョンの系譜を持つプロトコル登録済みリソースの集合として進化的基盤を定義します。本論文では、これらのリソースは (i) 指示（プロンプト）、(ii) 意思決定方策（エージェント）、(iii) 作動インターフェース（ツール。ネイティブツールスクリプト、MCP ツール、エージェントスキルを含む）、(iv) タスク/世界のダイナミクス（環境）、(v) 永続的状態（メモリ）で構成されます。重要なのは、RSPL におけるリソースは「受動的」であるという点です。これらは最適化ロジックをカプセル化せず、自己修正することはできません。すべての観察と状態遷移は、上位レイヤーによって呼び出される、制御されたインターフェースを介した操作を介してのみ発生します。

C.1.1. 中核エンティティ

私たちは、エージェントシステムのための最小限でありながら表現力豊かな基盤として、これら 5 つのエンティティタイプに焦点を当てています。この選択は網羅的であることを意図するものではなく、むしろ現代のエージェントスタック全体に共通する分母を特定し、SEPL が動作するための均一なターゲット空間を提供することを目的としています。

定義 C.1（リソースエンティティ）。タイプ $\tau$ のリソースエンティティとそのタイプレベルのコレクションは、次のように表すことができます。

$$e_{\tau ,i}=(n_{\tau ,i},d_{\tau ,i},{\varphi }_{\tau ,i},g_{\tau ,i},m_{\tau ,i}),E_{\tau }=\{e_{\tau ,i}\mid i\in I_{\tau }\}$$

ここで、$T=\{\text{PROMPT},\text{AGENT},\text{TOOL},\text{ENV},\text{MEM}\}$ は RSPL エンティティタイプの集合を表し、$\tau \in T$ はエンティティタイプをインデックスし、$I_{\tau }$ はタイプ $\tau$ のリソースインスタンスのインデックス集合、$i\in I_{\tau }$ は個々のインスタンスをインデックスします。ここで、$n_{\tau ,i}$ は固有のリソース名、$d_{\tau ,i}$ は短い説明、${\varphi }_{\tau ,i}:X_{\tau }\to Y_{\tau }$ は入力から出力へのマッピング、$g_{\tau ,i}\in \{0,1\}$ はリソースが進化可能かどうかを示す学習可能マーカー、$m_{\tau ,i}$ は補助メタデータ辞書です。

プロンプト、ツール、メモリを明示的な RSPL リソースとする主な動機は「分離」です。多くのエージェントシステムは、プロンプト、ツール、メモリをエージェントの内部コンポーネントとしてパッケージ化しており、これによりエージェントロジックがタスク固有の指示や機能バンドルと絡み合い、メンテナンスが増大し、転用が制限されます。これらを標準化されたインターフェースを持つファーストクラスのバージョン管理リソースとして外部化することで、同じツール呼び出しエージェント方策を異なるプロンプトやツールセットと組み合わせ、タスクや環境を変えずにデプロイすることが可能になります。

リソースの登録、統合管理、インスタンス化をサポートするため、RSPL は各リソースインスタンスに対してシリアライズ可能な登録レコードを保存します。

定義 C.2（リソース登録レコード）。リソース登録レコードとそのタイプレベルのコレクションは、次のように表すことができます。

$$c_{\tau ,i}=(e_{\tau ,i},v_{\tau ,i},{\eta }_{\tau ,i},{\theta }_{\tau ,i},F_{\tau ,i}),C_{\tau }=\{c_{\tau ,i}\mid i\in I_{\tau }\}$$

ここで、$\tau \in T$ はエンティティタイプをインデックスし、$i\in I_{\tau }$ は個々のインスタンスをインデックスします。ここで、$e_{\tau ,i}$ は定理 C.1 で定義されたリソースエンティティタプル、$v_{\tau ,i}\in V$ はバージョン文字列、${\eta }_{\tau ,i}$ は実装記述子（例：インポートパス、クラス定義、またはソースコード文字列）、${\theta }_{\tau ,i}$ はインスタンス化パラメータ（例：コンストラクタ引数）、$F_{\tau ,i}$ は LLM がリソースと対話するために使用されるエクスポートされた表現の集合（例：関数呼び出しスキーマ、自然言語テキスト、構造化引数スキーマ）です。

定義 C.3（プロトコル登録済みリソース）。各エンティティタイプ $\tau$ について、$R_{\tau }$ をプロトコル登録済みリソースのタイプ固有のレジストリとし、$R={\bigcup }_{\tau }{R}_{\tau }$ をグローバルレジストリとします。RSPL は各エンティティタイプ $\tau$ を専用コンテキストマネージャ $M_{\tau }$ およびサーバー公開インターフェース $A_{\tau }$ にバインドします。タイプレベルの登録済みリソースは次のように表されます。

$$r_{\tau }=(C_{\tau },M_{\tau },A_{\tau })$$

ここで、各 $c_{\tau ,i}\in C_{\tau }$ は定理 C.2 の登録レコードです。コンテキストマネージャ $M_{\tau }$ はコレクション $C_{\tau }$ とタイプ $\tau$ のバージョン系譜を維持し、これらのレコードに対するライフサイクルおよび更新操作を実装します。サーバー公開インターフェース $A_{\tau }$ は $M_{\tau }$ をカプセル化し、要求を対応するコンテキストマネージャのルーチンに委譲することで、統一された外部インターフェースを公開します。

C.1.2. コンテキストマネージャ

コンテキストマネージャは、各リソースタイプの管理プレーンを実装します。ライフサイクル制御と依存関係の制約を超えて、(i) 具体化されたリソースのアクティブなレジストリ、および (ii) 復元のためのバージョン履歴を維持します。そのエクスポートされた API は、ライフサイクルと登録（例：init、build）、取得と検査（例：list、get_state）、進化とバージョン管理（例：update、restore）、実行と契約（例：run、load_contract）、シリアライゼーションとデシリアライゼーション（例：save_to_json、load_from_json）のための機能的にグループ化された演算子の小さなセットと見なすことができます。マネージャは明示的に「契約生成」をサポートしており、管理対象エンティティのための統合された機能と制約の仕様を生成します。これにより、安定した最新の説明が提供され、信頼性が向上し、プロンプトの肥大化が削減され、制御されたプロンプト注入による体系的なコンテキストエンジニアリングが可能になります。例えば、ツール（ネイティブツールスクリプト、MCP 接続ツール、エージェントスキルを含む場合がある）の場合、契約はツールアクション、引数、前提条件、使用制約を列挙する skills.md 形式を取ることができます。$M_{\tau }$ によって実装され、$A_{\tau }$ によって公開されるエクスポートされた管理インターフェースは以下の通りです。

C.1.3. サーバーインターフェース