AIが最新論文を読み、自分のコードを改良する時代へ：「ScholarEvolve」がタスク達成率を12.4ポイント向上

AIエージェントの性能を高めるには、必ずしもAIモデル自体を再学習する必要はない。モデルの重みを変更しなくても、ツールの呼び出し方や実行履歴の管理、タスクの進め方を制御するソフトウェアを改良することで、タスクの達成率を大きく引き上げられる可能性がある。カリフォルニア大学サンタバーバラ校（UCSB）とMicrosoftの研究者らは2026年9月30日、こうした考え方に基づくフレームワーク「ScholarEvolve」を提案した未査読プレプリント「Learning from Research: Toward Lifelong Agent Harness Evolution」をarXivで公開した。

ScholarEvolveは、AIエージェントの失敗履歴を分析し、関連する学術論文から改善策を探して、実行基盤となるソフトウェアを自動的に書き換える仕組みだ。改良の対象は、ツールの呼び出し処理、会話履歴やコンテキストの管理、スキルの蓄積といった機能で、これらをまとめて「ハーネス（harness）」と呼ぶ。研究チームの実験では、タスクを実行するAIモデルの重みを固定したまま、オープンウェイトモデル「Qwen3.5-27B」のAppWorld Normalにおけるタスク達成率が69.0%から81.4%へと12.4ポイント上昇した。

ただし、これはQwen3.5-27B自体が新たな知識や能力を学習したことを意味しない。実際には、外部の高性能AIモデルやコーディングエージェントを使い、研究論文から得られた知見をハーネスのコードに反映した結果である。研究チームは複数のベンチマークで性能向上を報告しているが、実用性を評価するには、最適化にかかる計算コストや再現性、外部コードを取り込む際の安全性も考慮する必要がある。

{
  "type": "bar",
  "title": "主要ベンチマークにおけるタスク達成率の比較",
  "unit": "%",
  "categories": ["AppWorld Normal (Qwen3.5-27B)", "AppWorld Challenge (Qwen3.5-27B)", "tau2-Bench Telecom (GPT-5.4-mini)"],
  "series": [
    { "name": "初期ハーネス", "values": [69.0, 49.6, 72.7] },
    { "name": "Meta Harness", "values": [null, 54.6, null] },
    { "name": "ScholarEvolve", "values": [81.4, 63.6, 81.9] }
  ],
  "caption": "各実験設定における著者らの報告値。タスク実行モデルの重みは固定して評価している",
  "source": "arXiv:2609.40169"
}

いずれの評価環境でも、ScholarEvolveによって改良されたハーネスは初期構成を上回る性能を記録した。特に、未知のAPIが含まれるAppWorld Challengeでは、実行履歴に基づいてハーネスを改良する従来手法「Meta Harness」を9.0ポイント上回った。研究チームはこの結果を、過去の失敗だけでなく、外部の研究成果を参照して設計を改善することの有効性を示すものと捉えている。

失敗履歴だけに頼る改善手法の限界

AIエージェントを自律的に改善する従来の研究では、タスク実行時の履歴（トラジェクトリ）を分析し、失敗の原因を特定して修正する手法が主流だった。例えば、エージェントがAPIの呼び出しに失敗すると、そのログを別のAIエージェントに読み込ませ、プロンプトやリトライ処理を修正する。GoogleのWikiSkillやMicrosoftのSkillOptのように、スキルやメモリの管理方法を重点的に改善する研究もあれば、SalesforceのDarwinXやスタンフォード大学のMeta-Harnessのように、実行基盤全体の構成を見直す研究もある。

しかし、研究チームは、実行履歴の分析だけに頼る方法では改善が早い段階で頭打ちになると指摘する。その理由の一つは、改善案を考えるメタエージェントが、基本的には自身の学習済み知識を頼りに修正方法を選ぶためだ。失敗ログから問題の発生箇所は分かっても、それを解決する新しい設計手法まで見つかるとは限らない。特に、未知のAPIや複雑な環境に直面した場合、既存の知識だけでは適切な対策を考えられない可能性がある。

研究チームが挙げた例では、検索ツールやPythonコードの実行エラーが頻発した際、メタエージェントはすべてのアクションを事前に検証するモジュールを追加した。この仕組みは不正な呼び出しを検出できたものの、判定が厳しすぎたため、タスクの完了に必要な正しいAPI呼び出しまで遮断してしまった。目の前のエラーを減らすための修正が、かえってエージェント全体の柔軟性を損なったのである。個別の問題を解決できても、システム全体の性能が向上するとは限らないことを示す事例だ。

もう一つの問題は、実行履歴に基づく改善が、基本的に失敗の発生を待つ受動的な方法であることだ。エージェントが新たな問題に遭遇するまで、その問題に対応する改善は始まらない。本番環境でこの方式を採用すると、十分な失敗データが蓄積されるまで、ユーザーが同じ不具合の影響を受け続ける可能性がある。研究チームは、人間の開発者が論文を読んで新しい設計手法を学ぶように、AIエージェントも外部の学術文献から知見を取り入れ、失敗を経験する前から実行基盤を改良できる仕組みが必要だと考えた。

学術論文から実行可能なコードを生成する4段階の仕組み

ScholarEvolveでは、AIエージェントのハーネスを5つのモジュールに分けて管理する。ツールの呼び出しを担う「ツールインターフェース」、プロンプトや実行履歴を整理する「コンテキスト管理」、再利用可能な操作手順を保持する「スキル」、過去の経験を蓄積する「メモリ」、そしてタスクの分解や実行順序を制御する「エージェントワークフロー」だ。各モジュールには明確な入出力インターフェースを設け、ある部分を変更しても他の機能が影響を受けにくい構造としている。この設計により、ハーネス全体を書き換えるのではなく、問題のある機能を個別に改良できる。

最適化は4つの段階で進む。最初に、監査役のAIモデルが開発用タスクなどの実行履歴を調べ、エージェントの弱点を特定する。例えば、以前取得した情報を適切に参照できない、Pythonの構文エラーから復旧できないといった問題を抽出する。その分析結果をもとに検索クエリを作成し、arXivから関連する学術論文や要約を取得する。

第2段階では、検索した論文を設計手法ごとに分類する。ScholarEvolveは「TopicGPT」と呼ばれる手法を利用し、各論文がどのモジュールのどのような改善に役立つのかを整理する。単純に検索結果の上位から論文を選ぶと、似たような手法ばかりが集まる可能性がある。そこで、異なるアプローチを候補に残すことで、探索する設計案の多様性を確保する。

第3段階では、論文に書かれた設計手法を実際のコードに変換する。リサーチエージェントが論文の本文や付録、公開リポジトリのコードを調べ、実装に必要な仕組みや前提条件をまとめた変更設計書（変異ブループリント）を作成する。続いてコーディングエージェントが、その設計書に基づいて対象モジュールのPythonコードを書き換える。この段階では変更対象を1つのモジュールに限定し、残りの4つは固定することで、修正による影響を把握しやすくしている。

生成されたコードは、ベンチマークで評価する前に基本的な動作検査を受ける。Pythonモジュールとして正常にインポートできるか、定められた入出力インターフェースを守っているか、適切な形式のアクションを返せるかといった項目を確認する仕組みだ。これにより、構文エラーやインターフェースの不整合があるコードを早い段階で除外できる。ただし、これは機能面の検査であり、コードの安全性を包括的に保証するものではない。

最後の第4段階では、個別に改良したモジュールを組み合わせ、ハーネス全体の性能を評価する。遺伝的アルゴリズムに似た方法で複数のモジュール候補を組み合わせ、検証用タスクでの成績を比較する。さらに、対応のあるブートストラップ法を用いて性能差を統計的に検証し、改善が確認された候補だけを、それまでの最良構成である「チャンピオン」に採用する。単発の評価で偶然高いスコアを記録した候補への置き換えを防ぎ、性能の後退を抑えるための仕組みである。

具体例として、Qwen3.5-27Bのツールインターフェースに施された改良がある。初期のエージェントは、Pythonの構文が正しくないコードを生成したり、APIの仕様を確認せずに引数を推測したりして失敗することがあった。ScholarEvolveは研究論文「ToolACE-R」から着想を得て、コードの実行前に抽象構文木（AST）を使って構文を検査する機能と、必要に応じてAPIの仕様を表示する機能を追加した。モデルに正しいコードを書くよう指示するだけでなく、誤った操作を実行基盤側で検出し、必要な情報を参照できるようにした点が特徴だ。

このように、ScholarEvolveは論文の内容を単にプロンプトへ追加するのではなく、実行基盤の機能として実装する。改善対象をモジュール単位に分けることで複数の設計手法を比較でき、最終的にはそれらを組み合わせてシステム全体を最適化する。研究チームが目指しているのは、論文から得られた新しい知見を、AIエージェントの動作を変える具体的なソフトウェアへ継続的に反映する仕組みである。

ベンチマークで確認された性能改善

研究チームは、実際の業務に近い複雑な操作を必要とする2種類のベンチマークでScholarEvolveを評価した。一つは複数の仮想アプリケーションを操作し、Pythonコードを通じてAPIを呼び出す「AppWorld」、もう一つは通信サービスの顧客対応やトラブルシューティングを模擬ユーザーとの対話で行う「tau2-Bench Telecom」だ。タスクを実行するモデルには、オープンウェイトのQwen3.5-27Bと、プロプライエタリなGPT-5.4-miniを使用した。いずれの実験でもタスク実行モデルの重みは固定し、ハーネスの変更による性能差を測定している。

AppWorldの実験では、90件のタスクをハーネスの改良に、57件を開発段階の評価に使用した。その後、公式テストセットであるNormal（168タスク）とChallenge（417タスク）を使い、最終的な性能を測定している。評価指標のTGC（Task Goal Completion）はタスクの達成率を表し、SGC（Scenario Goal Completion）は同一シナリオに含まれる3つの変種をすべて完了できた割合を示す。SGCは、条件が多少変わっても安定してタスクを完遂できるかを見る、より厳しい指標だ。

Qwen3.5-27Bを使ったAppWorld Normalでは、TGCが初期ハーネスの69.0%から81.4%へと12.4ポイント上昇した。SGCでは48.8%から69.0%へと20.2ポイント改善しており、単に成功するタスクが増えただけでなく、条件の異なるタスクへの対応力も向上したことがうかがえる。さらに、最適化用のデータには含まれていなかったAmazonやGmailのAPIを扱うAppWorld Challengeでも、TGCは49.6%から63.6%へと14.0ポイント上昇した。

このChallengeテストでは、従来手法のMeta Harnessとの比較も行われた。同じ探索予算を与え、Codexを介してGPT-5.4を利用する条件で評価したところ、Meta HarnessのTGCは54.6%だったのに対し、ScholarEvolveは63.6%を記録した。9.0ポイントの差は、実行履歴に基づく修正だけでなく、外部の研究論文から新しい設計手法を取り入れることが、未知のAPIへの対応にも役立つ可能性を示している。

論文では、ScholarEvolveを適用したQwen3.5-27Bの81.4%というスコアについて、初期状態のGPT-5.4が記録した85.7%との差を約74%縮めたとも説明している。ただし、この比較ではタスク実行モデル自体が異なり、ハーネスの初期構成も同一ではない。そのため、Qwen3.5-27BがGPT-5.4と同等の能力を獲得したことを意味するわけではない。今回の数値は研究チームによる3回の評価の平均値であり、第三者による独立した追試もまだ示されていない。

モジュールの組み合わせが性能を左右する

ScholarEvolveの実験では、個々のモジュールを単独で評価した場合と、複数のモジュールを組み合わせた場合とで、性能の優劣が逆転する興味深い結果も得られた。研究チームは、特定の構成要素の影響を調べるアブレーション実験によって、この違いを検証している。

例えば、スキル管理モジュールを単独で評価したところ、ある候補は75.4%のタスク達成率を記録した。一方、論文「Skill-as-Pseudocode」に着想を得た別の候補は73.7%と、単独ではやや低い成績だった。ところが、改良済みのツールインターフェースやコンテキスト管理モジュールと組み合わせると、後者を使ったハーネスは84.8%に達し、前者を使った構成の80.7%を上回った。つまり、単体で高い性能を持つモジュールが、システム全体でも最適な選択になるとは限らない。

この結果は、ハーネスを構成する機能同士の相互作用が、エージェントの性能に大きく影響することを示している。例えば、ツールインターフェースが構文エラーを適切に検出し、コンテキスト管理が必要な履歴を保持できる環境では、操作手順を型付き疑似コードとして管理するスキルモジュールが効果を発揮しやすくなると考えられる。各モジュールの性能を個別に高めるだけでなく、組み合わせた状態で評価することが重要になる。ScholarEvolveが候補モジュールの組み合わせを探索するのも、このためだ。

実行時のエラーへの対応能力にも改善が見られた。AppWorld Challengeで、途中でPythonの実行時エラーが発生したタスクの履歴を分析したところ、初期ハーネスのタスク達成率は44.9%だったのに対し、改良後は59.9%に上昇していた。エラーの発生を完全に防いだというよりも、エラー発生後にトレースバックなどの情報を利用して処理を修正し、タスクを続行する能力が向上したと考えられる。実際の業務環境ではAPIの呼び出し失敗や予期しない応答を避けられないため、こうした復旧能力は重要な要素となる。

一方、すべての種類の失敗が大幅に減ったわけではない。研究チームの失敗分析によると、不正な応答フォーマットに起因するエラーは492件から206件へと半減以下になった。しかし、業務上の制約違反は91件から89件、必要な情報の取得漏れは77件から70件と、改善幅は小さかった。構文の不備やAPIの呼び出しエラーはハーネス側の工夫で減らせても、複雑な業務ルールの理解や必要な情報の判断といった問題は、同じ方法では解決しにくいことがうかがえる。

新しい論文を取り込むことで性能は向上し続けるのか

研究チームは、参照できる学術論文を時間とともに増やすことで、ハーネスの性能が継続的に向上するかも検証した。この実験では、タスク実行モデルの重みと蓄積された実行履歴を固定し、利用できる論文の範囲だけを段階的に拡張した。対象期間は、2025年12月までの文献を第1期、2026年1〜4月の文献を第2期、同年5〜8月の文献を第3期としている。

その結果、AppWorld NormalにおけるQwen3.5-27BのTGCは、初期状態の69.0%から第1期に77.4%、第2期に79.8%、第3期に81.5%へと段階的に上昇した。第3期のSGCは66.7%だった。モデルの重みや実行履歴を増やさなくても、新しい研究成果を利用することでハーネスをさらに改良できる可能性を示す結果である。

この実験を踏まえ、著者らは最新論文を毎月収集し、その内容をもとにエージェントの実行基盤を継続的に更新する運用方法を提案している。ただし、今回の検証は過去の論文を公開時期によって分けた実験であり、実際の業務環境で数カ月から数年にわたり自律更新を続けた実績ではない。また、新しい論文を増やすことが常に性能向上につながるとは限らず、改善効果が頭打ちになったり、特定のタスクに最適化しすぎたりする可能性もある。長期間の運用でどの程度の改善を維持できるかは、今後の検証課題だ。

実用化に残る計算コスト、再現性、セキュリティの課題

ScholarEvolveは、タスク実行モデルを再学習せずに性能を高める手法として有望だが、企業が実際に導入するにはいくつかの課題がある。特に注意すべきなのは、モデルの再学習が不要であることと、システム全体の最適化コストが低いことは同じではないという点だ。

今回の実験では、論文の検索・選定にGPT-5.4を使用し、モジュールのコード生成にもCodexとGPT-5.4を利用した。AppWorldの最適化では20組、tau2-Bench Telecomでは15組の論文由来の候補が生成され、それぞれについてタスクの実行と性能評価が繰り返された。さらに、候補同士の比較や統計的な検証にも追加の計算が必要になる。タスク実行モデルの重みを固定することで再学習の負担は避けられるものの、外部モデルによる論文分析、コード生成、ベンチマーク実行には相応の計算資源が必要だ。

Qwen3.5-27Bの実行環境も比較的大規模な構成となっている。論文に記載された設定では、推論サーバーにvLLM 0.27.1を使用し、テンソル並列度を4、サンプリング温度を0、思考モードを有効に設定している。また、モデル呼び出し1回あたりの最大トークン長は65,536に設定されていた。これは各呼び出しで常に65,536トークンを消費したという意味ではないが、長いコンテキストを扱うことを想定した実行環境である。

企業が導入を判断するには、最終的なタスク達成率に加えて、最適化に必要なAPI呼び出し回数や総トークン消費量、GPU稼働時間などを把握する必要がある。例えば、ハーネスを一度改良するために大量の外部モデル呼び出しが必要なら、改善によって削減できる日常的なタスク実行コストと、最適化にかかる費用を比較しなければならない。今回の報告値だけでは、こうした費用対効果を十分に判断することは難しい。

再現性も重要な課題だ。論文にはGitHubリポジトリへのリンクが記載されているものの、原稿執筆時点では、公式コードの公開や詳細な実行手順を確認できていない。外部の開発者が同じ条件で実験を再現するには、最適化パイプラインのコードだけでなく、評価スクリプト、モデルの設定、候補の選抜方法、実行環境などの情報が必要になる。リポジトリの公開状況やライセンス、実験に必要な依存関係が明確になるまでは、第三者による独立した検証には制約が残る。

外部の研究成果を自動実装することのリスク

もう一つの大きな課題がセキュリティだ。ScholarEvolveは外部の学術論文や公開リポジトリから設計手法を取得し、それをもとにエージェントの実行基盤を書き換える。この仕組みは新しい研究成果を素早く取り入れられる一方、信頼できない情報をコード生成の工程に持ち込むというリスクも抱えている。

論文で説明されている健全性プローブは、生成されたPythonコードをインポートできるか、インターフェースの規約を守っているか、正しい形式のアクションを返せるかといった機能面の検査が中心だ。これらはプログラムの基本的な動作を確認するうえで有効だが、悪意のある処理や情報漏洩につながるコードを確実に排除する仕組みではない。正常に動作するコードであっても、不正な外部通信や過剰な権限の使用など、セキュリティ上の問題を含む可能性がある。

特に、外部の論文やリポジトリに含まれる文章をAIエージェントが読み込み、その指示に従ってコードを生成する仕組みでは、プロンプトインジェクションへの対策が欠かせない。攻撃者が公開資料に不正な指示を埋め込んだ場合、コード生成エージェントがその内容を正当な設計要件と誤認するおそれがある。また、第三者の公開コードを参照する過程で、脆弱な実装や意図しない依存関係を取り込む可能性もある。現時点でScholarEvolve自体にこうした脆弱性が実証されたわけではないが、外部情報を取り込んで実行コードを自動更新する仕組みには、一般的にこうした脅威を想定した設計が必要になる。

企業がこの手法を応用する場合は、インターネット上の論文やコードを無制限に利用するのではなく、事前に審査した設計文書や社内ライブラリに参照先を限定する方法が考えられる。生成されたコードは隔離された環境で実行し、静的解析やセキュリティテストを通過したものだけを採用する。さらに、ハーネスの変更を本番環境へ反映する前には人間によるレビューを挟み、外部APIへのアクセスや機密情報の取り扱いについては、モデルの判断とは独立したポリシー制御を適用することが望ましい。機能面の検査と安全性の審査を分けて設計することが重要だ。

ScholarEvolveが示したのは、AIエージェントの性能向上がモデルの大規模化や再学習だけに依存するものではないということだ。既存モデルの重みを固定していても、周囲のソフトウェアを適切に改良すれば、タスクの達成率を大きく引き上げられる。さらに、学術論文から設計手法を取り入れることで、過去の失敗履歴だけに頼る改善方法の限界を超えられる可能性も示された。

一方、今回の成果は未査読の研究報告に基づくものであり、長期的な自律更新や実運用での安全性、費用対効果まで実証されたわけではない。今後は公式コードの公開と第三者による再現実験に加え、探索コストの定量評価、外部情報を取り込む際の安全性検証が重要になる。モデルそのものを改良するだけでなく、モデルを動かす実行基盤を継続的に改善するという方向性が、どこまで実用的な性能向上につながるのかが注目される。