AIエージェントに、過去の作業履歴から自動で手順書となるスキルを作らせ、次のタスクで参照させる仕組みが広がりつつあります。人間が毎回ルールを整備するには限界があるため、将来的には、エージェント自身が経験から学び、再利用できる知識として蓄える流れが強まると考えられます。
ただし、この仕組みは「入れれば必ず賢くなる」ものではありません。
どんな経験から作るのか、どのモデルに読ませるのか、何を品質基準にするのかを分けて考える必要があります。
参照する論文は、Microsoft Research、復旦大学、上海交通大学の合同チームが発表した「From Raw Experience to Skill Consumption: A Systematic Study of Model-Generated Agent Skills」です。彼らはスキルの表面的な読みやすさやテキスト品質ではなく、下流タスクの精度がどれだけ動いたかを基準に、5ドメイン × 6実行モデル × 5抽出モデルの総当たり検証をしました。
生の経験からスキル消費へ：モデル生成エージェントスキルの体系的研究
From Raw Experience to Skill Consumption: A Systematic Study of Model-Generated Agent Skills
| 著者 | Zisu Huang, Jingwen Xu, Yifan Yang |
|---|---|
| URL | https://arxiv.org/abs/2605.23899 |
スキルは一律導入にはリスクがある
過去のタスク履歴から作ったスキルをエージェントに読ませると、全体の七五パーセントの条件で精度が上がりました。一方で、二五パーセントの条件では精度が下がっています。つまり、平均値だけを見ると有効に見えても、個別のタスクでは四回に一回の割合で逆効果が混じることになります。
この結果は、今後のエージェント設計にとってかなり重要です。スキルを全タスクに自動適用する構成は、運用が楽になる反面、性能を落とすケースを同時に抱え込みます。将来的にエージェントがより多くの業務を担当するほど、この「平均では改善するが、局所的には壊す」性質は無視しづらくなります。
| 観点 | わかったこと | 実務上の意味 |
|---|---|---|
| 全体傾向 | 七五パーセントの条件で性能が改善 | 仕組み自体には有効性がある |
| 逆効果の頻度 | 二五パーセントの条件で性能が低下 | 一律適用には検証が必要 |
| 領域差 | 家庭内タスクでは逆効果が四七パーセントまで増加 | タスクの性質ごとに評価が必要 |
| 安定性 | 表計算やコード修正では逆効果が一三パーセント程度 | 構造化された領域では比較的扱いやすい |
強いモデルが良いスキルを作るとは限らない
直感的には、性能の高い大規模モデルにスキルを書かせればよさそうに見えます。しかし、検証結果はその予想とずれていました。表計算タスクでは、軽量モデルが抽出役として最も良い結果を出し、もともとのタスク性能が高い大規模モデルは抽出役として最下位になっています。
これは、タスクを解く能力と、経験を再利用可能な知識にまとめる能力が別物であることを示しています。将来のエージェント基盤では、実行役のモデル選定だけでなく、経験からスキルを作る抽出役の評価も独立して行う必要があります。
同じスキルでも読むモデルによって結果が変わる
同じスキルを六つの実行モデルに読ませると、性能変化はプラス九・五ポイントからマイナス二・〇ポイントまで広がりました。文章としては同じでも、受け取るモデルによって、うまく作業方針に変換できる場合と、かえってミスを増やす場合があります。
この違いは、スキルが単に新しいツール呼び出しを増やすから起きるわけではありません。むしろ、モデルがもともと持っている解き方や判断の流れを書き換える形で効いていました。今後、エージェントが複数モデルを組み合わせて動くようになるほど、「誰が作ったスキルを、誰に読ませるのか」は設計上の大きな論点になります。
読みやすいスキルほど性能が高いとは言えない
スキルの形式を、番号付きリスト、箇条書き、チェックリスト、散文に変えても、性能差は統計的に有意ではありませんでした。つまり、見た目の整い方だけでは、エージェントにとって本当に役立つスキルかどうかは判断できません。
さらに厄介なのは、大規模言語モデルに「どちらのスキルが良さそうか」を選ばせても、正解率が四六パーセントにとどまったことです。性能差が大きいスキルのペアに限ると、正解率は一六パーセントまで落ちています。人間から見ても人工知能から見ても、もっともらしく見える文章が、実際には性能を下げることがある。
経験の集め方にも最適解はない
スキルの材料になる経験ログも、ただ成功例だけを集めればよいわけではありません。成功軌跡だけ、失敗軌跡だけ、成功と失敗の混合という条件で比べると、すべて失敗例だけのプールはどの領域でも最も悪い結果になりました。スキルには、少なくとも「どうすれば動くのか」という正例が必要です。
一方で、最適な成功と失敗の比率は領域によって異なります。表計算やコード修正では成功例が多い方が有利でしたが、家庭内タスクでは失敗例が多い方が高い精度につながりました。将来のエージェントが現場のログから継続的に学ぶなら、経験ログの量だけでなく、成功と失敗の配合も管理対象になります。
性能を分ける三つの観点が見えてきた
表面的な品質評価が当てにならないなら、何を見ればよいのでしょうか。性能差が大きいスキルを比べると、勝った側に共通する特徴は三つに整理されました。この三つを評価基準として大規模言語モデルに与えると、スキルの優劣を当てる正解率は四六パーセントから七四パーセントまで上がっています。
①失敗の仕組みまで書かれている
良いスキルは、「失敗するから注意する」で終わりません。なぜ失敗するのか、どの条件で失敗するのか、その失敗をどう避けるのかまで書かれています。表計算の例では、画面を持たない実行環境では数式文字列が評価されないため、別の計算環境で静的な値まで計算してから書き戻す必要がある、といった具体的な失敗構造が性能に効いていました。
②実行できる粒度まで具体化されている
抽象的な原則だけでは、実行モデルが次の行動に落とし込めません。「作業前に状況を確認する」ではなく、「閉じた容器は中身を確認するために必ず開けてから観察する」のように、対象物と操作が具体的に書かれている必要があります。将来のエージェントに渡す知識は、人間向けの心得ではなく、機械がそのまま行動に変換できる粒度であることが重要です。
③やってはいけない行動が明示されている
肯定的な手順だけでは、避けるべき分岐がモデル任せになります。良いスキルには、「この状況でこの操作をすると失敗する」という禁止行動が具体的に含まれていました。リスクの高い行動を名前付きで避けさせることで、実行モデルが危ない選択肢を踏みにくくなります。
三つの観点を生成側に入れると改善した
この三つの観点を、スキルを作る抽出器のプロンプトに直接入れると、九つの検証条件すべてで精度が改善しました。逆に、「明確さ」「完全さ」「簡潔さ」「論理構造」「書式」「トーン」「汎用性」のような一般的な品質基準を入れた場合は、平均的に性能が下がっています。
| 評価軸 | 一見よさそうな基準 | 実際に効いた基準 |
|---|---|---|
| 文章品質 | 明確さや読みやすさ | 失敗の仕組みがあるか |
| 行動への変換 | 書式や論理構造 | 実行可能な粒度か |
| 安全性 | 丁寧な注意喚起 | 禁止行動が具体的か |
| 汎用性 | どの場面にも使えそうか | 領域固有の失敗を押さえているか |
導入判断では逆効果の出方を見る
この研究から得られる実務上の示唆は、かなりはっきりしています。自動生成されたスキルは、将来のエージェントを強くする重要な部品になり得ます。ただし、平均的な改善だけを根拠に全タスクへ広げると、一定の割合で性能低下を招きます。
導入時に見るべきなのは、スキルありの平均スコアだけではありません。
導入前に確認したいこと
- スキルを入れたとき、平均精度だけでなく悪化した条件の割合も測っているか
- 抽出役モデルを、モデルサイズや一般性能ではなく抽出性能で選んでいるか
- 同じスキルを複数の実行モデルに読ませ、相性差を見ているか
- 成功例と失敗例の比率を、領域ごとに変えて検証しているか
- スキルに失敗の仕組み、実行可能な操作、禁止行動が含まれているか
領域ごとの逆効果率、抽出役モデルと実行役モデルの相性、経験ログの配合、そしてスキルの中に失敗構造と禁止行動が書かれているかを確認する必要があります。
本記事の関連研究
