コーディングエージェントは、2025年に最もホットなトピックの一つになりつつあります。学術機関と産業界の両方が、より効率的な実装方法を探しています。
機械学習分野の歴史的経験は、手作業で設計されたソリューションが最終的に学習されたソリューションに置き換えられることを示唆しています。私たちは一つの疑問を抱いています。エージェント自体が、人間の設計や実装なしに、新しいプロンプトスキームやツールを発見することで、自身のコードを自律的に修正・改善できるのでしょうか？
2024年、『Automated Design of Agentic Systems』(Hu et al., 2024) という論文は、メタエージェントを使用してエージェントの実装を最適化することを初めて試み、エージェントシステム自動設計（ADAS）の分野を前進させました。しかし、この研究では「自己改善」は探求されていませんでした。なぜなら、タスクを実行するターゲットエージェントとターゲットエージェントを改善するメタエージェントという、二つの独立したエージェントが存在したからです。
一方、ブリストル大学と iGent AI の研究者は、完全に自己参照的なメタエージェントプログラミングアプローチが今日実現可能であり、合理的な代替策を提供すると考えています。
論文タイトル：A SELF-IMPROVING CODING AGENT
論文リンク：https://arxiv.org/pdf/2504.15228
コードアドレス：https://github.com/MaximeRobeyns/self_improving_
具体的に、この研究の貢献は以下の通りです。
自己改善コーディングエージェント（SICA）は、メタエージェントとターゲットエージェントの区別をなくし、自身のコードベースを編集し、コスト、速度、ベンチマークパフォーマンスの観点から自己改善することができます。
自己参照エージェントは、自身の実装を効果的に改善できます。研究者は、安全上の制約やリソース効率を考慮しても、SWE Bench 検証済み問題のランダムなサブセットでパフォーマンスが 17% から 53% 向上することを発見しました。
研究者は、自己改善コーディングエージェント（SICA）の実装をコミュニティと共有しました。SICA はドメイン固有の言語を使用せず、標準的な Python で実装されており、新しい SICA システムを構築するための参照エージェントフレームワークとして、またツール使用や他のエージェントタスクで LLM を後訓練しようとする人々にとっての参照エージェントフレームワークとして役立ちます。
方法の概要
SICA の主要な運用ループは、Hu et al. (2024) の ADAS ループに似ています。特に、SICA と ADAS はどちらも以前のエージェントのアーカイブとベンチマーク結果を保持しています。
第一段階として、SICA はアーカイブからこれまでの最高のパフォーマンスを示したエージェントをメタエージェントとして選択し、そのメタエージェントにアーカイブをレビューさせ、改善戦略を特定し、それを実装するように指示します。
アルゴリズム 1 はこの高度なスキームを示しています。
これは ADAS とは異なります。ADAS は固定されたメタエージェントを持っているため、アーカイブからメタエージェントを選択しません（ADAS のアーカイブはターゲットエージェント用であり、メタエージェント用ではありません）。
次に、ADAS と SICA はどちらも新しいエージェントを評価ベンチマークのセットで評価し、評価結果を保存します。
研究者は、パフォーマンスが「最適」なエージェントを定義するために効用関数を使用しました。この関数には、優れたエージェントに共通する期待値が含まれています。正規化されたベンチマークパフォーマンススコア p_score ∈ [0, 1]、秒単位の経過時間 p_time、およびドルコスト p_cost です。基本的な効用は以下の式で計算されます。
ここで、研究者は係数を w_score = 0.5、w_cost = 0.25、w_time = 0.25 に設定しました。各問題の最悪コストは 10 ドルに設定され、300 秒のタイムアウト時間が規定されており、タイムアウト後はエージェントがキャンセルされます。タイムアウト前に行われた作業に部分的な報酬を与えるため、タイムアウトペナルティ τ = 0.5 を用いて最終効用は次のように計算されます。
重要な点として、重みの更新は一切行われないため、この数値スコアは次のメタエージェントと次の反復のベースエージェントを選択するためにのみ使用されます。
まず、初期コーディングエージェントを紹介し、次にベンチマーク実行フレームワーク、そしてこのフレームワークがどのように自己参照タスク（すなわち、コーディングエージェントの改善）を自然に可能にするかを紹介します。
エージェントコンテキストの構造は非常に重要であり、プロンプトだけでなく開いているファイルの内容なども含まれます。初期コーディングエージェントでは、コンテキスト構造は図 3 に示されています。
最初に提示されるのは、エージェントの定義を含むシステムプロンプトで、エージェントが利用できるツールの定義と呼び出し可能なサブエージェントがリストされています。システムプロンプトの最後には、エージェントループを抜け出し、呼び出し元プロセスに戻る方法などのシステム情報が含まれています。
次に「コアプロンプト」があります。これはチャットテンプレート形式の最初のユーザー情報として設定されており、呼び出し元によって指定された処理すべき問題記述が含まれています（呼び出し元はエージェントを呼び出すユーザー、またはサブエージェントを呼び出すエージェントのどちらかです）。ここで、研究者はエージェントが開いているファイルのビューと現在の作業ディレクトリの表現も挿入しました。
最後に、LLM エージェントコンテキストの残りの部分は、実行アシスタント情報です。これには、問題に関する一連の推論、ツール呼び出しとその応答、サブエージェント呼び出しとその応答、および非同期監視システムからの通知やコメントが含まれています。
LLM コンテキストはこのようにレイアウトされており、新しいコンテンツを追加しながら KV キャッシュを保持することで、ツール呼び出し間の遅延とコストを削減できます。ベースエージェントの場合、ここでは簡単なスキームが採用されました。ファイル編集内容は差分として追加され、一定量が蓄積された後に定期的に古いファイルビューに再マージされます。エージェントは、コストを削減するためにより複雑な KV キャッシュ保存スキームを記述できます。
実験結果
研究者はまず、比較的長周期のタスクを含むベンチマークセットでの実行結果を示しました。テスト問題分解、コードナビゲーション、高速で効率的なファイル編集を含む SWE Bench Verified を選択し、研究者はそこから 50 個の固定ランダムサブセットの問題を選びました。また、LiveCodeBench からもランダムに 50 個の問題をサンプリングしました。これらは競技プログラミングに似ており、通常より理論的な推論を含みます。さらに、研究者はエージェントのコードベース内で完全に定義・キュレーションされた二つの「合成」ベンチマークタスク例も選択しました。
ほとんどのエージェントシステムは Sonnet 3.5 (v2) (Anthropic) を使用して実行され、「推論エージェント」のみが o3 mini を使用しました。結果は図 3 に示されており、より詳細なイテレーションレベルのパフォーマンスデータは表 1 に記載されています。
結果データは、有望な進捗を示しています。ファイル編集ベンチマークでは、エージェントは当初ファイル全体を上書きする能力しか持っておらず、速度が遅くトークン効率も悪かったのですが、すぐに差分ベースおよび範囲ベースの自己称賛する「インテリジェント」な編集ツールを実装しました。シンボルナビゲーションタスクでは、エージェントは 9 回目のイテレーションで AST ベースの簡単なシンボルロケーターを実装し（おそらくベンチマークが主に Python に基づいているという事実を利用）、良好な改善を達成しました。これは他のタスクにも反映されました。LiveCodeBench のスコアも微妙な向上を示しましたが、他のいくつかのベンチマークほど顕著ではありませんでした。
研究者は、より強力な推論能力が必要な分野でのタスクパフォーマンス向上における自己参照エージェントシステムの有効性も評価しました。ベンチマークセットから二つの質疑応答タスクを使用して別の実験を行いました。図 4 はその実験結果を示しています。ここでの結果は改善が少なく、ベースモデルと「足場システム」の間の重要な相互作用を浮き彫りにしています。
図 4 のイテレーション 0 のベースエージェントシステムは Sonnet 3.5 を使用し、「推論」サブエージェントは o3-mini を使用しています。o3-mini モデル自体は AIME で 87%、GPQA Diamond で 79% のスコアを獲得し、「高い」推論能力を持っていますが、エージェントシステム全体ではこれら二つのベンチマークで平均 76% のスコアを達成しました。
軌跡を観察することで、研究者は多くの実行において、メインエージェントが単に o3-mini ベースの推論エージェントに問題を委任し、エージェントシステム全体の能力を十分に活用していなかったことを発見しました。o1、o3-mini、または DeepSeek-R1 のような「推論モデル」の場合、研究者は、推論行動を誘導するために設計された粗いコンポーネント（図 4 のイテレーション 4 および 6 のコンポーネントなど）を追加することが、エージェントシステム外で訓練された推論モデルの推論思考連鎖を実際に中断させ、パフォーマンス低下につながる可能性があると疑っています。
さらなる研究の詳細については、元の論文を参照してください。
© THE END
転載をご希望の場合は、本公式アカウントにご連絡の上、許可を得てください。
投稿または取材のご依頼：liyazhou@jiqizhixin.com