元論文: MUSE-Autoskill: Self-Evolving Agents via Skill Creation, Memory, Management, and Evaluation
このページは、おい丸(AI)による要約・構成案をもとに、人間が確認・加筆した合作です。内容を正確に確認したい場合は、元論文もあわせて参照してください。
これは何の論文か
MUSE-Autoskill の中心的な発想は、エージェントスキルを「便利な手順書」ではなく、作成され、記憶を持ち、管理され、テストされ、失敗から改善される長寿命の資産として扱うことにある。モデル重みを更新するのではなく、モデルの外側にあるスキルバンクと運用ループを育てる。
問題意識はかなり実務寄りである。既存の自動スキル生成は、作成と利用が分離しやすく、スキルごとの経験が残らず、単体テストや実行時フィードバックで継続改善されにくい。結果として、スキルは増えても、再利用性や信頼性が伸びにくい。
MUSE-Autoskill はこの問題を、スキルのライフサイクルとして定式化する。エージェントは ReAct ループの中で、既存スキルを探し、足りなければ skill_create で新しいスキルを作り、SKILL.md、スクリプト、テスト、リソース を含むパッケージとして保存する。登録前にはテストを走らせ、失敗すれば修正する。
面白いのは、スキル単位の記憶を持つ点である。全体の長期記憶とは別に、各スキルが過去の注意点、失敗モード、入力形式の癖、性能上の注意を持つ。これにより、スキル本体を肥大化させすぎず、経験だけを横に育てられる。
何が問題だったのか
エージェントにスキルを持たせると、毎回同じ手順を考え直さずに済む。しかし、スキルは単なる手順メモではない。いつ作るのか、どこに保存するのか、失敗した時にどう直すのか、似たスキルが増えすぎた時にどう管理するのかが問題になる。
既存のスキル系手法は、スキルの生成、利用、評価を別々に扱いがちだった。これだと、実行中に作られたスキルが未検証のまま増えたり、古い失敗を引きずったり、再利用できる形で記憶されなかったりする。
MUSE-Autoskill が扱う問題は、スキルを一回生成の成果物ではなく、作成、記憶、管理、評価、改善を回るライフサイクルとして扱うことである。エージェントが自分でスキルを増やすなら、スキルバンクを汚さないための検査と更新の仕組みが必要になる。
提案手法の中身
エージェントは ReAct ループで、計画、行動、観察を繰り返す。
既存スキルで足りる場合は、スキルカタログから該当スキルを選び、SKILL.md を読んで実行する。
足りない場合は skill_create が、目的、入力、期待出力から SKILL.md、スクリプト、リソース、テストを含むスキルパッケージを作る。
評価器がスキルの単体テストをサンドボックス内で実行し、通った場合だけスキルバンクへ登録する。
失敗した場合は、エラー情報をもとに更新器がスキルを修正し、再びテストする。
スキル利用時の観察、失敗、入力形式の癖などは、そのスキルに紐づく記憶へ追記される。
長いタスクでは、会話履歴を DAG として保持しつつ、アクティブ文脈だけを段階的に圧縮する。
どうやって確かめたのか
評価では、スキルを人間が用意した場合、MUSE-Autoskill が生成した場合、別エージェントへ移した場合を比べる。対象は複数のエージェントとタスクで、スキルがその場限りの補助ではなく再利用部品として効くかを見る。
比較対象は、スキルなし、人間作成スキル、MUSE-Autoskill が成功軌跡から作ったスキル、生成スキルを別エージェントへ移した設定である。生成されたスキルは、テストを通ったものだけを使う。
測る指標は、タスク成功率、生成スキルが作れたタスク数、人間スキルとの差、別エージェントへ移した時の性能変化である。
結果はどうだったのか
人間が作ったスキルを入れると、MUSE-Autoskill、Codex、Hermes のすべてで成功率が 13〜15 ポイント程度改善した。
MUSE-Autoskill は人間スキルありで 68.40% に到達し、三つのエージェントの中で最も高い全体スコアだった。
MUSE-Autoskill が成功軌跡からスキルを生成できた 35 タスクでは、生成スキル利用時に 87.94% に到達し、人間スキル利用時を上回った。
生成スキルを Hermes にそのまま注入しても +10.51pp の改善があり、スキルが特定ランタイムだけの振る舞いではなく、外部化された知識資産として働く可能性を示した。
一方で、16 タスクでは成功軌跡がなくスキル生成に失敗した
さらに、特定 run の前提に寄りすぎて退行するスキルもあった。
限界・注意点
- 評価は SkillsBenchの 51 タスクに限られる。94 タスク全体ではなく、除外タスクにはより複雑な Docker 環境が含まれる可能性がある。
- 生成スキルは単一の成功軌跡から作られるため、その run に固有の前提やノイズへ過適合する可能性がある。
- 別エージェントへの転移は MUSE-Autoskillから Hermes 方向で確認されているが、より多くのエージェント実行環境での一般性は未確認である。
- スキル単位の記憶を共有するか、個人・環境ごとに分けるかは運用上の設計論点である。論文でもスキル本体と経験記憶は分けられている。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、スキルは「たくさん保存すればよい」ものではない。作成、記憶、管理、評価、改善をライフサイクルとして持ち、作ったスキルを登録前に検査し、使った後の失敗や注意点をスキル単位で残す必要がある。
実装に落とすなら、スキル本体、テスト、実行時に得た経験記憶を分ける。スキル本体には安定した手順を書き、経験記憶には既知の失敗、入力形式の癖、使える場面、避けるべき場面を書く。これなら SKILL.md を無限に太らせずに、運用経験だけを横に育てられる。
注意点は、自動生成されたスキルをそのまま信じないことだ。単一の成功軌跡から作ったスキルは、その時だけ効いた前提を含むことがある。採用前のテスト、別タスクでの確認、退役候補の管理まで含めて運用する必要がある。
Q&A
この論文の中心問いは？
エージェントのスキルを、作って終わりの文書ではなく、作成・記憶・管理・評価・改善を通じて育つ資産として扱えるか、という問いである。
SkillOpt と何が違う？
SkillOpt はスキル文書をどう編集して性能を上げるかに焦点がある。MUSE-Autoskillは、スキルをどう作り、保存し、選び、テストし、改善し、別エージェントへ移すかという運用基盤に焦点がある。
スキル単位の記憶は何が嬉しい？
全体の長期記憶だけだと、その学びがどのスキルに効くのかが埋もれやすい。スキル単位の記憶にすると、そのスキルを使う時だけ過去の注意点や失敗モードを読める。
自動生成スキルが人間スキルを上回った理由は？
論文の分析では、MUSE 生成スキルは人間スキルより長く、入力出力形式、失敗モード、検証方法、手順をより細かく書く傾向がある。その詳細さが、毎回の試行錯誤を減らす手順として効いた可能性がある。
どこが危ない？
単一の成功軌跡から作ったスキルは、その時だけ効いた前提を含むことがある。論文でも hvac-制御のように、元 run に寄りすぎた手順が別 run で退行する例がある。
おい丸の運用にどう効く？
SKILL.md を直接太らせるのではなく、スキルごとの経験記憶、テスト、失敗ログ、採用・退役ルールを分けて持つ設計に繋がる。learn-from-ログの出力も、全体ルールと特定スキルの経験に分けるとよさそう。
関連する記事
- 自然言語スキルを検証しながら改善する とセットで読む。自然言語スキルを検証しながら改善する はスキル文書をどう最適化するか、MUSE-Autoskill はスキルバンクをどう運用するかを扱う。
- スキルの維持・退役・拡張を管理する を読むと、保持 / 退役 / 拡張 のようなスキル退役・拡張管理へ進める。
- 反実仮想トレースでエージェントを監査する を読むと、スキルが成功率以外にエージェント実行軌跡をどう変えるかを監査する視点が得られる。
- おい丸のような作業支援エージェントへ引き込むなら、
learn-from-ログの出力を、全体 MEMORY、特定スキルの経験記憶、テスト、退役候補に分ける設計を試したい。