AIエージェントには「スキルの選別力」も必要

AIエージェントに同じ種類のタスクを何度も解かせれば、そこから「再利用できる手順」が自然に積み上がっていく。この考え方は、これからのAIエージェント開発においてかなり重要な前提になりつつあります。企業の業務AIや開発支援エージェントが本格的に使われるようになれば、人間が毎回細かく指示しなくても、過去の経験をもとに自分でうまく立ち回る仕組みが求められるからです。

ただし、その前提にはかなり厳しい課題も潜んでいます。

ポイント

• 180のタスクを6つの実環境にまたがって用意し、エージェントに過去の作業経験からスキルを抽出させ、未知のタスクに挑ませる大規模な実験が行われた
• 10種類のモデルと3つのエージェント基盤で検証した結果、整理されたスキルを使うよりも、過去の作業ログをそのまま渡したほうが成功率が高くなる場面が、頻繁に観察された
• 問題は「AIが経験を持てば賢くなるか」ではなく、「経験をどのような形で保存し、何を捨て、何を残せば、将来のタスクに役立つ知識になるのか」

今回紹介する研究では、AIエージェントが過去の作業から「スキル」を作り、それを将来の似たタスクに使えるのかを調べています。ここでいうスキルとは、人間でいう作業手順書のようなものです。過去の試行錯誤から、次にも使えそうな手順や注意点をまとめたものだと考えるとわかりやすいです。

エージェントにとって難しいのは、過去の作業ログには大量の細部が含まれていることです。

どの情報が将来も役立つのか。
どの情報はその場限りの偶然なのか。
どこまで抽象化すればよいのか。
どこから先は削ると危険なのか。

この判断がうまくできないと、スキルは便利な手順書ではなく、むしろ誤った近道や古い思い込みになってしまいます。

実験の全体像

実験では、6つの実環境にまたがって180のタスクが用意されました。

各環境には5つのタスク群があり、それぞれに6種類のタスクが含まれています。最初の3つは学習用で、エージェントはここで作業を行いながら経験を蓄積します。その後、別の「スキル作成役」が作業ログと検証結果をもとに、スキルを書くか、既存のスキルを改訂するか、何もしないかを選びます。

残りの3つは評価用です。ここではスキルライブラリを固定したうえで、エージェントが新しい条件のタスクに対応できるかを調べます。

この設計によって、単に「前にやったことを覚えているか」だけでなく、「将来の少し違う状況に転用できるか」まで見られるようになっています。

比較された条件

実験では、複数の条件が比較されました。

この比較のポイントは、「スキルがあること」そのものの効果と、「生の経験をそのまま持っていること」の効果を切り分けている点です。

もしスキル化がうまく機能しているなら、生の作業ログよりも整理されたスキルのほうが役立つはずです。しかし実際には、そこが大きく崩れました。

経験は増えても、うまく転用できるとは限らない

実験結果の大きなポイントは、現在のAIエージェントが「目の前の似たタスクには適応できても、将来の少し違うタスクにうまく転用できない」ことです。

学習用タスクや、同じタスクをもう一度解く場面では、スキルを使うことで成功率が上がるケースがありました。たとえば、Claude Opus 4.6を自己生成スキル条件で動かした場合、学習タスクの成功率は5.5ポイント、再実行時の成功率は10.0ポイント改善しています。

ところが同じ条件で、評価タスク全体の成功率や、文脈が変わったタスクへの対応力、複数スキルを組み合わせる能力は低下しました。

つまり、元の問題には強くなっているのに、少し形が変わった問題には弱くなっているのです。

これは、将来的な業務AIを考えるうえでかなり重要です。現場で使われるAIエージェントは、まったく同じ作業だけを繰り返すわけではありません。似ているけれど条件が少し違う依頼、前提が変わった依頼、複数の手順を組み合わせる依頼に対応する必要があります。

その意味で、この研究は「経験を積ませれば自動的に賢くなる」という見方にブレーキをかけています。

生の作業ログがスキルより役立つ場面

実験結果で最も意外だったのは、整理されたスキルが、生の作業ログに負ける場面が多かったことです。

普通に考えると、過去の作業ログをそのまま渡すより、そこから重要な手順だけを抜き出したスキルのほうが使いやすそうに見えます。人間でも、長い作業履歴を読むより、要点をまとめた手順書を見るほうが便利だからです。

しかし、AIエージェントではそう単純ではありませんでした。

生の作業ログには、一見すると余計に見える情報がたくさん含まれています。試行錯誤の順番、失敗した操作、途中で確認した条件、なぜその方法を選ばなかったのか、といった細部です。

スキル化の過程では、こうした情報が削られます。ところが、後のタスクではその「削られた情報」が重要になることがあります。

研究では、この問題を「情報を失う抽象化のボトルネック」と呼んでいます。スキルとしてきれいにまとめる過程で、将来の判断に必要な文脈や手続き上の細部が失われてしまう、ということです。

抽象化そのものが悪いわけではない

ここで注意したいのは、「スキル化は無意味だ」という話ではないことです。

問題は、いまのエージェントが何を残し、何を捨てるべきかをうまく判断できていない点にあります。

人間が熟練していくときも、すべての経験を丸暗記するわけではありません。大事なパターンを抜き出し、次にも使える判断基準として整理します。ただし、そのためには「この情報は本質的か」「これはその場限りの偶然か」を見分ける力が必要です。

現在のエージェントは、この選別力がまだ十分ではない可能性があります。

将来的にAIエージェントが本当に経験から学ぶようになるには、単にスキルを書く仕組みではなく、経験の中から何を抽象化するかを判断する仕組みが必要になります。

失敗のパターン

この研究では、成功率を細かく分けて見ることで、失敗の種類も明らかにしています。

たとえば、ある条件では評価タスク全体の成功率が上がっていても、文脈変化への対応力だけが下がることがあります。別の条件では、文脈変化には強くなっても、近道の罠に引っかかりやすくなることがあります。

つまり、「平均成功率が上がったから良いスキルだ」とは言えません。

将来のエージェント評価では、単一のスコアだけでなく、どの種類の変化に強いのか、どの種類の罠に弱いのかを分けて見る必要があります。

更新頻度を上げても解決しない

直感的には、スキルをこまめに更新すれば、経験学習はうまくいきそうに思えます。

しかし、実験結果はそれほど単純ではありませんでした。

毎回の試行後に必ずスキルを更新する条件では、一部のモデルで改善が見られました。たとえば、GPT-5.2-Codexでは評価タスク全体の成功率や文脈変化への対応力が伸びています。Gemini 2.5 Proでも、複数の評価指標で改善がありました。

一方で、別のモデルでは、頻繁な更新によってむしろ性能が落ちるケースもありました。

理由は、更新頻度を上げると、有用な情報だけでなく、その場限りのノイズもライブラリに混ざってしまうからです。タスク固有の条件や、たまたまうまくいった手順まで保存されると、将来のタスクではかえって邪魔になります。

これは、経験学習における「量より選別」の問題です。

たくさん覚えればよいのではなく、何を覚えるべきかを判断できるかが重要になります。

容量を増やしても汎化しない

スキル本文だけでなく、補助スクリプト、参考資料、テンプレートなどを追加で保存させる実験も行われました。

もし問題が「保存容量の不足」なら、こうした追加ファイルを持たせることで性能は上がるはずです。

結果は、半分だけ当たっていました。

一部の条件では、追加資料が役立ちました。たとえば、手続きが安定している領域では、検証用のスクリプトや参照テンプレートを保存しておくことで、タスク成功率が上がるケースがあります。

しかし、多くのケースでは、ライブラリが大きくなっても性能は横ばいか低下しました。

この結果から見えるのは、未来のエージェントに必要なのは、巨大な記憶容量だけではないということです。

むしろ重要なのは、記憶の中から今のタスクに本当に関係するものを選び出す力です。容量を増やすだけでは、知識ベースは賢くなるどころか、散らかった作業机のようになってしまいます。

環境によって難しさは大きく変わる

スキルが有効に働くかどうかは、タスク環境によって大きく異なりました。

最も易しい環境と最も難しい環境では、学習タスクの成功率に67.3ポイント、評価タスクの成功率に42.1ポイントもの差がありました。一方で、スキルの有無や種類による平均的な差は、それよりずっと小さいものでした。

これはかなり重要です。

つまり、スキル機構そのものよりも、「どんな環境で使うのか」のほうが結果を大きく左右する場合があるということです。

この結果は、企業が将来エージェント学習を導入する際の判断材料になります。

すべての業務に同じように「経験から学ぶAI」を入れればよいわけではありません。まずは、手順が安定していて、成功条件が明確で、検証しやすい領域から導入するほうが現実的です。

コスト効率もモデルによって変わる

スキル機構を導入すると、多くの場合でタスクあたりのコストは増えます。

スキルを読ませるにも、更新するにも、追加の処理が必要になるからです。問題は、そのコスト増に見合うだけの性能向上があるかどうかです。

実験結果を見ると、答えは「モデルと条件による」です。

モデル依存も大きく出ています。あるモデルではスキル機構が多くの条件で改善をもたらす一方、別のモデルでは導入そのものが逆効果になるケースがありました。

これは、将来のAIシステム設計において、「この仕組みは一般に有効」と簡単には言えないことを示しています。スキル機構の良し悪しは、モデルがそのスキルをどう解釈し、いつ呼び出し、どの程度信じるかに強く依存します。

AIエージェント設計に対する実務的な示唆

スキル化を急がない

過去の作業ログをきれいな手順書に変換する前に、まずは生の作業ログを検索しやすい形で残すほうが有効な場合があります。

特に、タスクの文脈が頻繁に変わる業務では、早すぎる抽象化が情報損失につながる可能性があります。

単一の成功率だけで評価しない

学習済みタスクへの再対応がうまくいっても、将来の少し違うタスクに対応できるとは限りません。

評価では、少なくとも次の観点を分けて見る必要があります。

更新頻度より選別力を重視する

頻繁に更新すれば学習が進む、という考え方は危険です。

重要なのは、更新の回数ではなく、何を残し、何を捨てるかです。将来的には、スキル作成そのものよりも、経験の選別や検証を担う仕組みのほうが重要になる可能性があります。

モデルごとに検証する

同じスキル機構でも、モデルによって結果は大きく変わります。

あるモデルでは改善する仕組みが、別のモデルではコスト増と性能低下を同時に招くことがあります。そのため、エージェント学習を導入する場合は、使用するモデルごとに小さく検証してから広げるほうが安全です。

適用する業務を選ぶ

経験学習が向いているのは、手順が安定していて、検証しやすい領域です。

コード修正、データ処理、ツール操作のような領域では、スキル化が比較的機能しやすい可能性があります。一方で、情報統合、交渉、予定調整、コミュニケーションのように文脈依存が大きい領域では、現在の方法だけではまだ難しさが残ります。

まとめ

AIエージェントに経験を積ませれば、自然に再利用可能なスキルができる。

この考え方は魅力的ですが、今回の研究はそこに慎重な見方を示しています。整理されたスキルよりも、生の作業ログのほうが役立つ場面が多くあり、容量を増やしたり、更新頻度を上げたりしても、問題が単純に解決するわけではありませんでした。

ただし、これはスキル化という発想そのものが間違っているという意味ではありません。

問題は、AIエージェントが経験の中から何を残し、何を捨てるべきかをまだ十分に判断できていないことです。手順が安定した領域では効果が出ているため、抽象化そのものが不可能なわけではありません。

これからのAIエージェント開発で重要になるのは、単に「経験を保存する」ことではなく、「将来の別の状況でも役立つ形に選別する」ことです。

未来の業務AIが本当に自律的に学び、成長していくためには、スキルライブラリの量よりも、経験を見極める力のほうが大きな課題になりそうです。

本記事の関連研究