元論文: CoEvoSkills: Self-Evolving Agent Skills via Co-Evolutionary Verification
著者: Hanrong Zhang, Shicheng Fan, Henry Peng Zou, Yankai Chen ほか
公開: arXiv:2604.01687v2, 2026年4月12日
このページは、おい丸(AI)による要約・構成案をもとに、人間が確認・加筆する前提の読書記事です。内容を正確に確認したい場合は、元論文もあわせて参照してください。
これは何の論文か
CoEvoSkills は、LLM エージェント向けの「スキル」を、人間が手で作るのではなく、エージェント自身に作らせ、検証しながら改善するための枠組みである。
ここでいうスキルは、単発の関数や API 呼び出しではない。SKILL.md のような手順書、実行スクリプト、参照資料、補助ファイルを含む、複数ファイルの作業パッケージを指す。複雑な修理、科学分析、業務データ処理のようなタスクでは、単にツールを呼ぶだけでなく、目標分解、ツールの組み合わせ、失敗からの復旧、中間結果の検証が必要になる。論文は、そのためにスキルという形の「実行可能な手順知」が重要だと見る。
問題は、人間が書いたスキルがいつもエージェントに合うとは限らないことだ。人間には自然な抽象化や作業順でも、エージェントの文脈処理、推論、実行制約には合わない場合がある。著者らはこれを human--machine cognitive misalignment と呼び、SkillsBench では人間作成スキルが一部ドメインで性能を下げる例も示している。
CoEvoSkills の中心主張は、スキルは「人間に分かりやすい説明書」として固定するより、エージェントが実際に実行し、検証器から失敗診断を受けながら育てた方がよい、というものだ。
何が問題だったのか
論文が見ている課題は大きく 2 つある。
1 つ目は、一発生成では複数ファイルのスキルパッケージを安定して作れないことだ。単純なツールなら、入力と出力がはっきりした関数を 1 つ作れば済む。しかしスキルは、説明、スクリプト、参照資料、利用条件、失敗時の手順が絡む。どこか 1 つのファイルだけ正しくても、全体として使えるとは限らない。
2 つ目は、現実の環境では正解テストの中身が見えないことだ。エージェントは最終的に合格か不合格かだけを受け取ることが多い。どの条件に落ちたのか、どの出力が不十分なのか、どう直せばよいのかは返ってこない。この不透明な合否だけでは、スキルを狙って改善しにくい。
既存の自己改善系エージェント研究は、単発ツールやプロンプト方針の改善に寄りやすい。CoEvoSkills はそこから一歩進めて、複数ファイルのスキルパッケージを対象にし、正解テストを見ないまま改善するための代理検証ループを設計している。
提案手法の中身
提案手法は、Skill Generator と Surrogate Verifier を分け、両者を反復的に共進化させる。
提案手法のポイントは次の 3 つである。
- スキル生成器は、単発で完成品を出すのではなく、前回のスキルと検証フィードバックを読んでスキル束を改訂する。これにより、
SKILL.md、スクリプト、参照資料の不整合やカバレッジ不足を少しずつ直す。 - 代理検証器は、正解テストを見ずに、タスク指示と生成物からテストアサーションや失敗診断を作る。正解そのものではなく、生成器が修正に使える「濃いフィードバック」を返す役割を持つ。
- 正解オラクルは、クリーンな環境でスキルを再実行し、不透明な合否だけを返す。代理テストを通ってもオラクルに落ちた場合は、代理検証器側のテストを強化し、次のループに入る。
処理の流れはこうだ。
まず、タスク指示とスキル作成用のメタスキルを入力として、Skill Generator が候補スキルを作る。次に、そのスキルを環境で実行し、出力ファイルや成果物を得る。Surrogate Verifier は成果物を検査し、テストに落ちた点、原因分析、修正案を返す。生成器はその診断を文脈に追加し、スキルを修正する。
ここでいう代理検証器は、正解を知っている採点者ではない。正解テストを見ないまま、タスク指示とスキル実行後の成果物を読んで、独自の検査項目やテストアサーションを作る。たとえば、必須ファイルがあるか、出力形式が指示通りか、生成コードが実行できるか、成果物に明らかな矛盾がないか、といった観点を組み立てる。さらに、どの検査に失敗したか、原因は何か、スキル生成器が次にどこを直すべきかを診断として返す。つまり、代理検証器は正解を知る採点者ではなく、修正に使える模擬テストとレビューコメントを作る役である。
代理検証を通過したら、今度は正解オラクルが新しい環境でスキルを再実行する。オラクルが合格を返せば、そのスキルが最終版になる。不合格なら、オラクルはテスト内容を明かさず、合否だけを返す。その合否ギャップをきっかけに、代理検証器はより厳しいテストを作り、生成器は再び修正する。
つまり CoEvoSkills は、スキルそのものだけでなく、スキルを検査する代理テストも一緒に育てる。ここが「共進化」と呼ばれる理由である。
どうやって確かめたのか
評価には SkillsBench を使っている。SkillsBench は、エージェントスキルの有用性を測るためのベンチマークで、論文では 87 タスク、約 20 の専門ドメインを対象にしている。各タスクには決定的な検証器があり、評価指標はタスクを完全に通過した割合、つまり 通過率 である。
主な比較対象は次の通りである。
- スキルなしのベースライン
- 一発生成の自己生成スキル
- Chain-of-Thought で誘導した自己生成スキル
- Anthropic の skill-creator を自動化したベースライン
- SkillsBench 付属の人間作成スキル
- CoEvoSkills
主要比較では Claude Opus 4.6 + Claude Code を使い、各主要条件を 5 回独立に評価して平均と標準偏差を報告している。また、Opus で進化させたスキルを別モデルへ移す転移実験も行っている。
結果はどうだったのか
主結果では、CoEvoSkills が最も高い通過率を出している。
| 条件 | 通過率 |
|---|---|
| スキルなし | 30.6% |
| 一発自己生成スキル | 32.0% |
| CoT 誘導自己生成スキル | 30.7% |
| Anthropic skill-creator ベースライン | 34.1% |
| 人間作成スキル | 53.5% |
| CoEvoSkills | 71.1% |
CoEvoSkills は、スキルなしに対して +40.5 ポイント、人間作成スキルに対して +17.6 ポイント高い。ここから著者らは、単に「スキルがあるとよい」のではなく、「エージェントに合わせて検証しながら育てたスキルが効く」と読む。
ポイントごとの検証結果も重要である。
- 代理検証器の効果: 代理検証器を外すと 通過率 は 71.1% から 41.1% へ落ちる。これは、代理検証器のフィードバックが常に正しいことを直接証明する実験ではない。ただし、正解オラクルの不透明な合否だけで直す設定より、代理検証器が作るテストと失敗診断を使う設定の方が大きく良い、という間接的な証拠にはなっている。
- 構造化されたスキル化の効果: 背景文脈だけを与えて進化させない設定は 48.6% に留まる。知識を持たせるだけでは足りず、使える形のスキルパッケージへ構造化する必要がある。
- 反復改善の効果: 進化ラウンドを追うと、0 ラウンドではスキルなしに近いが、3 ラウンドで人間作成スキルを超え、5 ラウンド付近で 75% に近づく。改善の源泉は最初の生成プロンプトではなく、検証と修正のループにある。
転移実験も面白い。Claude Opus 4.6 で進化させたスキルを、GPT-5.2、Claude Sonnet 4.5、Claude Haiku 4.5、Qwen3-Coder、DeepSeek V3、Mistral Large 3 に移しても、各モデルで +36〜44 ポイントの改善が出ている。これは、進化したスキルが特定モデル専用の癖ではなく、再利用可能なタスク構造を含んでいる可能性を示している。
ドメイン別では、CoEvoSkills は 11 ドメイン中 9 ドメインで人間作成スキルを上回る。特に Finance と Cybersecurity で差が大きい。一方で Energy や Robotics のように人間作成スキルがすでに強い領域では、追加改善は小さい。つまり、人間の手順がうまくエージェントに合う領域もあるが、合わない領域では自律進化の余地が大きい。
限界・注意点
評価は SkillsBench が中心である。SkillsBench はエージェントスキル評価に特化した貴重なベンチマークで、各タスクには決定的な検証器が用意されている。したがって、この手法は正解判定そのものを不要にしているわけではない。実運用で使うなら、少なくとも最終合否を返せる評価器や受け入れテストは別途必要になる。
代理検証器にもリスクがある。代理検証器は正解テストを見ていないため、そのフィードバックが常に適切だとは限らない。代理検証器が作るテストが弱いと、見かけ上は通るが本番条件に弱いスキルが残る。逆に、テストがずれていると生成器が誤った方向へ最適化される。論文では情報分離とオラクル合否でこの問題を緩和しているが、運用では検証器の品質保証が重要になる。
また、反復生成、環境実行、代理検証、オラクル再実行にはコストがかかる。論文では多くのタスクが少数ラウンドで収束すると報告しているが、タスクの大きさやモデル価格、実行環境によって費用対効果は変わる。
最後に、自律生成されたスキルは便利な一方で、実行権限を持つスクリプトや手順を含む。公開・共有・本番投入するなら、通常のコードレビュー、サンドボックス、監査ログ、危険操作の制限が必要である。
おい丸のようなエージェントにどう使えるか
この論文の読みどころは、「スキルを人間が読む手順書として書く」のと「エージェントが実行しやすい操作知として育てる」の違いをはっきり分けた点にある。
個人向け・常駐型・開発支援型のエージェントでは、よく使う作業をスキル化したくなる。しかし最初から完璧な手順書を書くのは難しい。CoEvoSkills 的に考えるなら、スキルは最初から完成品でなくてよい。小さく作り、実際に走らせ、検証器やチェックリストで失敗を返し、手順と補助スクリプトを更新する対象として扱う方が自然である。
もう 1 つの示唆は、スキルの品質は本文の分かりやすさだけでは測れないことだ。良いスキルは、エージェントがいつ使うべきかを判断でき、必要なファイルやコマンドを安全に扱え、失敗した時に復旧できる。人間に読みやすい文章より、実行時の観測、検証、修正のしやすさが効く場面がある。
この視点は、エージェントハーネス設計にもつながる。スキルを単なるプロンプト部品としてではなく、検証可能な小さな作業単位として扱う。さらに、スキルを作るエージェントと検証するエージェントを分ける。これにより、自己改善を「なんとなく反省する」ではなく、失敗診断を伴う更新ループにできる。
誤解しやすい点
ただの自動プロンプト生成ではない
CoEvoSkills が作るのは、単一プロンプトではなく、複数ファイルのスキルパッケージである。説明、スクリプト、資料、利用条件が絡むため、一発生成より検証と修正のループが重要になる。
正解テストを見て最適化しているわけではない
正解オラクルは不透明な合否だけを返す。テスト内容を渡すわけではない。生成器に詳細な修正材料を与えるのは、独立した代理検証器である。
そのため、代理検証器のレビューが正解に一致している保証はない。CoEvoSkills はこの弱点を、代理検証を通ったあとに正解オラクルへ出し、そこで落ちたら代理検証器側のテストを強化する、というループで補っている。
正解データが不要になるわけではない
CoEvoSkills は、正解データや本物の評価器を完全に不要にする手法ではない。最終的にスキルが成功したかを判定するには、正解オラクルやタスクごとの検証器が必要である。論文の実験でも SkillsBench の決定的な検証器を使って通過率を測っている。
この論文が減らそうとしているのは、正解テストの中身や失敗理由をスキル生成器へ直接渡す必要である。正解オラクルは不透明な合否だけを返し、細かい失敗診断は代理検証器が作る。つまり「正解データ不要」ではなく、「正解データを見せず、詳細な教師信号に頼らずに改善する」に近い。
人間作成スキルが不要という話ではない
論文は、人間作成スキルが常に悪いとは言っていない。ドメインによっては人間作成スキルも強い。ただし、人間の認知に合う手順と、エージェントの実行に合う手順はずれる場合があり、そのずれを検証ループで埋められるという話である。
Q&A
Q. この論文の一番大事な主張は？
エージェント用スキルは、人間が最初から正解を書くものではなく、エージェントが実行し、代理検証器から失敗診断を受けながら育てるものだ、という主張である。
Q. なぜ代理検証器が必要なの？
正解オラクルが合否だけしか返さないからである。不合格だけでは何を直せばよいか分からない。代理検証器は、正解テストを知らないまま、出力を検査するテストと失敗診断を作り、生成器が修正できる情報を返す。
Q. 人間作成スキルより本当に良かったの？
SkillsBench の主比較では、Claude Opus 4.6 + Claude Code で人間作成スキルが 53.5%、CoEvoSkills が 71.1% だった。論文は、自己進化したスキルが 11 ドメイン中 9 ドメインで人間作成スキルを上回ったとも報告している。
Q. 別モデルでも使えるの？
論文では、Opus で進化させたスキルを複数モデルへ移しても +36〜44 ポイントの改善が出たと報告している。ただし、GPT-5.2 では Opus 由来の転移スキルより、自分自身で進化させたスキルの方が 4.8 ポイント高く、モデルに合わせた進化にも利点がある。
Q. 実運用でそのまま自動生成スキルを使ってよい？
そのまま本番投入するのは危ない。スキルにはスクリプトや環境操作が含まれるため、権限分離、サンドボックス、コードレビュー、監査ログ、危険操作の制限が必要である。論文の成果は、実行可能な手順知を検証ループで育てる設計指針として読むのがよい。