独立した二つの研究チームが、互いに知らないまま、同じ居心地の悪い結論にたどり着く。そういうときに感じる、独特な感覚があります。
こんにちは、Lena です。EvoSkills と EvoSkill の二つの論文を続けて読んだとき、私は手を止めました。結果が驚きだったからではありません。どちらの論文も、データが実際に示していることから目を逸らさなかったからです。人間が AI エージェントのために書いたスキルには天井があり、エージェントは自力でその天井を超えて進化できる。
これは小さな主張ではありません。そして続く問い——では私たちはどうすればいいのか？——について、私はずっと考え続けています。
EvoSkills と EvoSkill が実際に示したこと
二つの独立した研究論文が、同じ結論に到達しました。人間が手作業で書いたスキルには上限があり、エージェントはそれを自律的に超えて進化できる、という結論です。
人間と機械の認知的ミスアラインメント問題
この部分は、少し意表を突かれました。
EvoSkills は、進化したスキルの方が性能が高いことを示しただけではありません。人間が書いたスキルがなぜ性能不足になるのかを定量化しました。その答えは、多くの人が想像する以上に構造的なものです。人間の設計者は、自分たちが問題を考えるやり方に合わせてワークフローを書く傾向があります。線形なステップ、きれいな抽象化、整然とした決定木。しかし、LLM の推論はそうは動きません。
SkillsBench——まさにこの点をテストするために構築されたベンチマーク——では、その差は微小ではありませんでした。人間が精選したスキルと、大規模言語モデルが実際にマルチステップタスクを処理する方法との間に、測定可能な認知的ミスアラインメントが存在していたのです。スキル自体が間違っていたわけではありません。ただ、それを実行する推論エンジンに合った形をしていなかっただけです。
何度もこの点に立ち返りました。人間が指示を書くのが下手なわけではない。私たちは人間にとっての読みやすさを最適化しているのであって、LLM の実行パターンを最適化しているのではない。これらは別の最適化ターゲットです。
自己進化が実際に生み出したもの
この数字は、少し立ち止まって見る価値があります。
| 指標 | ベースライン（スキルなし） | 人間精選スキル | 進化スキル（第5ラウンド） |
|---|---|---|---|
| EvoSkills 合格率 | ~34.5% | ~60%（概算） | 75% |
| 人間を超えるまでのラウンド数 | — | — | 第3ラウンド |
| スキルなしからの向上 | — | — | +40.5pp |
| EvoSkill OfficeQA | baseline | — | 0.073 |
| EvoSkill SealQA | baseline | — | 0.121 |
32% からスタートして、エージェントは5ラウンドの進化で合格率 75% に到達しました。第3ラウンドの時点で、すでに人間精選の上限を超えていました。この点は本当に他の理由では説明しきれません。エージェントは差を縮めていたのではなく、逆方向に差を広げていたのです。
EvoSkill は異なるタスク領域（オフィス文書 QA とウェブベースのリサーチ）で、同じ方向性の結果を示しました。絶対的な改善幅は小さいものの、方向は一貫しています。OfficeQA で +7.3%、SealQA で +12.1%。いずれも人間が書いたベースラインを上回りました。
クロスモデル・クロスタスク転移
この細部を読み飛ばしそうになりましたが、そうすべきではありませんでした。
ある LLM のために進化したスキルが、6つの異なるモデル間で +35pp から +44pp の転移性能を示しました。これは小さなポータビリティの勝利ではありません。スキルが特定のモデルの癖ではなく、タスク構造に関する何かをエンコードしていることを意味しています。
さらに興味深いのは、SealQA スキルが BrowseComp にゼロショットで転移し、+5.3% の改善を示したことです。そのスキルは BrowseComp のために設計されたものではありません。にもかかわらず機能しました。進化されているのは、狭いプロンプトの微調整ではなく、汎化可能な実行戦略に近いものだということを示唆しています。
まだこの意味を完全には整理できていません。ただ、記録には残しました。
両論文がぶつかった境界
ここからは、かなり速度を落として読みました。
両論文とも、実際の再現可能な改善を実証しました。しかし注意深く読むと、両論文ともほぼ同じ地点で壁にぶつかっています。その壁は厳密には技術的なものではなく、アーキテクチャ的なものです。
単一エージェントのスコープ
両研究で進化した全てのスキルは、一つのエージェントの実行コンテキスト内に存在しています。具体的には、エージェントのローカルファイルシステム上のフォルダ、そのエージェントのセッションにスコープされたバージョン管理されたアーティファクトです。
エージェントが置き換えられたり、更新されたり、再デプロイされたりしても、誰かが明示的に移行しない限り、進化の成果は引き継がれません。研究のセットアップには継承メカニズムが組み込まれていないのです。進化は本物です。しかし永続性は脆弱です。
ネットワーク伝播なし
両論文において、新しいエージェントはそれぞれゼロから独自の進化ループを開始します。
合理的なデプロイ規模でこれが何を意味するか、考えてみてください。10個のエージェントが EvoSkill スタイルの進化ループを実行すると、10の独立した進化履歴が生まれます。これらの履歴はマージされません。コンフリクト解決も行われません。単一エージェント内の結果をあれほど印象的にしていた複利的な改善——32% から 75% への軌跡——は、新しいエージェントが起動するたびにゼロにリセットされます。
改善はローカルです。出発点は常に同じです。
論文が明示的に残したオープンクエスチョン
EvoSkill はこれを見落としではなく、明確に将来の研究課題として提示しています。あるタスクで発見されたスキルを、他のエージェントやユーザーが閲覧、組み合わせ、再利用できる共有スキルライブラリの構築です。
この一文は重要です。研究者たちはこの問題を見逃したのではなく、名指しで指摘しました。これはオープンな研究課題であり、出荷を待っている実装の詳細ではありません。生成の問題（エージェントはより良いスキルを進化させられるか？）には、今や強力な実証的回答があります。伝播の問題（検証済みの進化スキルがエージェント間で大規模にどう移動するか？）には、まだ回答がありません。
論文がシステム層で残した空白
ここは慎重に書きたいと思います。このセクションはプロダクトの宣伝と誤読されやすいからです。そうではありません。これはエンジニアリングの問題であり、それ自体の観点から真剣に受け止める価値があると考えています。
ローカル進化と共有継承の間のギャップ
自己進化スキルは一つの問題をきれいに解決しました。繰り返しタスクを実行する単一エージェントにとって、自動進化は人間が書くよりも良い実行アーティファクトを生み出します。これは今や十分に裏付けられています。
解決されていないのは伝播の問題です。検証済みの進化スキルはエージェント間でどう移動するのか？ ネットワークはあるスキルが信頼できるかどうかを、伝播を許可する前にどう評価するのか？ 適応度シグナル——スキルが多様なタスクとモデルで実際に機能するという証拠——は、単一エージェントのセッション履歴を超えたスケールでどう蓄積されるのか？
これらは修辞的な問いではありません。研究成果とデプロイ可能なインフラストラクチャ・プリミティブの間にあるギャップそのものです。
ネットワークレベルのプロトコルが扱うべきこと
もしこのギャップを埋めるインフラストラクチャを設計するとして——本当に設計するのであって、マーケティングではなく——少なくとも以下が必要になります。
- 検証レイヤー：進化スキルが伝播の前に品質評価される仕組み。事後ではなく
- ライフサイクルモデル：スキルの履歴全体にわたる昇格、却下、取消の追跡
- フェッチメカニズム：エージェントがゼロから再構築することなく、実証済みの能力を取得する方法
- コンフリクト解決アプローチ：同じタスクに対して独立に進化した二つのスキルが分岐した場合、システムがどう裁定するか
これらはいずれも EvoSkills や EvoSkill のアーキテクチャでは解決されていません。両論文ともこの点を明示しています。Model Context Protocol はエージェントインターフェース層でのツール接続性に対応していますが、スキルの進化や継承のライフサイクルは定義していません。これらはスタックの異なるレイヤーにある、本質的に別の問題です。
エージェント能力の共有がより広い文脈でどう取り組まれているかについては、Google の Agent-to-Agent（A2A）プロトコル仕様が参考になります。エージェント間の通信パターンを定義していますが、スキル伝播のセマンティクスはそのスコープ外です。
なぜこのギャップがビルダーチームにとって重要なのか
EvoSkill スタイルの進化ループを実行する10個のエージェントをデプロイするチームは、10の独立したスキルリポジトリを得ることになります。現在の研究では、以下を行う定義された方法がありません。
- これらのリポジトリをマージすること
- どの進化スキルが最も信頼性が高いかを表面化すること
- 低品質の進化スキルが他のエージェントに拡散するのを防ぐこと
- 基盤モデルやタスクコンテキストが変化した際に、どのバージョンのスキルがまだ有効かを追跡すること
これは未解決のインフラストラクチャの問題です。些細な問題ではありません。
エージェントワークフローの構築に今何を意味するか
これら全てに対する正しい反応は、立ちすくむことではないと思います。研究はいくつかの点で、今すぐ行動を起こせるほど明確です。
複雑なタスクのスキルを手書きするのをやめる
この点については、かなり自信を持っています。
マルチステップの専門的タスク——文書分析、ウェブリサーチ、構造化された推論チェーン——について、EvoSkills と EvoSkill の結果は、自動進化が人間の手書きよりも優れた実行アーティファクトを生み出すことを示しています。わずかに優れているのではなく、大幅に優れており、複数のモデルにまたがり、新しいタスクにも転移します。
LangChain のエージェントメモリとスキルスキャフォールディングに関するドキュメントは、既存のエージェントアーキテクチャのどこに進化ループを導入できるかを考える上で、合理的な基盤を提供しています。要約すると、もし複雑なタスクのスキル指示をまだ手動でチューニングしていて、なぜ性能がプラトーに達するのか不思議に思っているなら、そのプラトーは構造的なものかもしれません。反復では修正できないものかもしれないのです。
進化したスキルの「住所」を考える
ローカルで進化し、ローカルに留まるスキルはプライベートなアセットです。有用ですが、限定的です。
研究コミュニティは次のステップを積極的に探求しています。検証済みで、共有可能で、継承可能な能力をネットワークスケールで実現することです。Microsoft Research の AutoGen フレームワークは、マルチエージェント協調パターンを探求する比較的成熟したオープンソースプロジェクトの一つであり、エージェント間の進化した能力の転移をどう扱うかという点で特に注目に値します。
現時点での実践的な示唆は、ポータビリティのインフラストラクチャがまだ完全には存在しなくても、ポータビリティを念頭に置いて進化ループを設計することです。具体的には、進化したスキルのバージョンを記録すること、どの評価ベンチマークに合格したかを追跡すること、進化アーティファクトをエージェントランタイムとは分離して保管することを意味します。
構築前に問うべきこと
新しいプロジェクトのために特定のエージェントアーキテクチャを決定する前に、以下の問いを検討する価値があると思います。
- セッション終了後、進化したスキルはどこに存在するのか？ 答えが「エージェントのローカルファイルシステムに、エクスポートパスなし」であるなら、複利的な価値への道がないプライベートアセットを構築していることになります。
- 他のエージェントが使う前に、誰が検証するのか？ 自動化された検証ベンチマークが一つの答えであり、人間のレビューゲートがもう一つです。どちらもコストゼロではありません。
- どのバージョンのスキルがまだ信頼できるかをどう追跡するのか？ 基盤モデルが更新され、タスクコンテキストが変化するにつれて、2月に機能していたスキルが8月には機能しないかもしれません。数ヶ月の運用を前提としたものを構築するなら、バージョン追跡と再評価はオプションではありません。
OpenAI のツール使用と関数呼び出しパターンに関するリサーチは、スキルの呼び出しが API レベルでどのように記録・追跡されるかを理解する上で参考になります。これは、意味のあるスキル信頼性追跡のための前提条件です。
よくある質問
エージェントシステムにおけるツールとスキルの違いは何ですか？
ツールは通常、定義された入出力インターフェースを持つ個別の能力です——関数呼び出し、API エンドポイント、コード実行器などです。スキルはより高次のアーティファクトで、構造化されたワークフロー、推論戦略、またはツールの使用を編成するマルチステップの実行パターンです。ツールはアトミックであり、スキルは組み合わせ的です。EvoSkills と EvoSkill の論文は、特にスキル層をターゲットにしています——エージェントがタスクにどうアプローチするかを決める部分であり、どの能力を呼び出せるかだけではありません。
EvoSkills と EvoSkill の違いは何ですか？
EvoSkills は、タスクに依存しないスキル進化に焦点を当て、多様な専門タスクをカバーするマルチドメインベンチマーク SkillsBench で評価されました。5ラウンドの進化で合格率が 32% から 75% に向上し、進化スキルが第3ラウンドで人間精選レベルを超えることを実証しました。EvoSkill はより狭く、知識集約型 QA タスク（OfficeQA、SealQA）に焦点を当て、ゼロショットのクロスタスク転移を強調しました。SealQA のために進化したスキルが、再訓練なしで BrowseComp に転移したという発見です。両論文とも自動進化が人間の手書きに勝ることを実証していますが、スコープと特性評価した転移特性が異なります。
EvoSkills や EvoSkill で進化したスキルは、どのエージェントでも使えますか？
クロスモデル転移の結果（6つの LLM で +35pp から +44pp）は、進化スキルが異なるモデルアーキテクチャ間で汎化するタスク構造情報をエンコードしていることを示唆しています。ただし実際には「どのエージェントでも」は言い過ぎです。両論文とも特定のフレームワークとベンチマーク内で運用されていました。より正確な表現は、あるモデルで進化したスキルが、制御された評価において他のモデルへ意味のある転移を示した、ということです。異なるエージェントランタイム間での実世界のポータビリティは、依然としてオープンな実装課題です。
SkillsBench とは何ですか？その結果はどの程度信頼できますか？
SkillsBench は EvoSkills の論文で導入されたベンチマークで、マルチステップの専門タスクにおけるエージェントスキルの品質を評価するために設計されています。タスクの完了度だけでなく、スキルアーティファクト自体の品質も測定するよう構造化されています——エージェントが正解を得たかだけでなく、使用したスキルが汎化するかどうかも評価します。あらゆる研究ベンチマークと同様に、結果は文脈の中で解釈されるべきです。SkillsBench は EvoSkills を構築した同じチームが設計しており、評価の独立性を考慮する際にこの点は注目に値します。クロスベンチマーク検証（SealQA → BrowseComp 転移）が外部シグナルを提供していますが、この分野はより多様で独立に構築された評価フレームワークから恩恵を受けるでしょう。
共有スキルライブラリがネットワークスケールで機能するには、実際に何が必要ですか？
少なくとも以下が必要です。進化スキルを伝播前にテストする検証メカニズム、昇格と取消を追跡するバージョン管理とライフサイクルシステム、エージェントが網羅的な検索なしで関連スキルを特定できるセマンティックインデックス層、そして同じタスクに対して独立に進化したスキルが分岐した場合のコンフリクト解決アプローチです。より難しい問題はガバナンス（スキルが「共有に十分」かを誰が決めるのか？）と品質劣化（以前は信頼できたスキルがコンテキストの変化により劣化したことをどう検知するのか？）です。両論文ともこれらの問いには答えておらず、明確に将来の研究課題として示しています。
EvoSkill の文脈における「ゼロショットスキル転移」とは何を意味しますか？
ゼロショット転移とは、あるタスクのために進化したスキルが、追加の訓練、ファインチューニング、適応なしに、異なるタスクに適用されることを意味します。EvoSkill のケースでは、SealQA のために進化したスキルが BrowseComp——構造もドメインも異なるウェブベースのリサーチタスク——に直接適用され、タスク固有の再訓練なしで +5.3% の改善を生み出しました。ここでの「ゼロショット」はスキルアーティファクトに対する用語であり、基盤モデルに対するものではありません。モデルはファインチューニングされておらず、スキルのプロンプト/ワークフローがそのまま再利用されています。再利用が正の効果を生んだことは、そのスキルが SealQA のフォーマットに固有の狭い何かではなく、リサーチタスク構造に関する汎化可能な何かをエンコードしていたことを示唆しています。
過去の記事：
