長く仕事をしてきた人ほど「前にこうやったらうまくいった」というコツをたくさん持っている。ところが、そのコツがたった一度の成功から生まれたものだとしたら、似て見える次の仕事にそのまま当てはめて、かえって台無しにしてしまうこともある。一度の経験を規則だと勘違いしてしまったせいだ。
AIエージェントもまったく同じだ。モデルを再学習させなくても、「このアプリはこう使う」「この実験はこの順序でやる」といったコツを文章にして渡してやれば、仕事がうまくなる。このコツを書いた文書をスキル(skill)と呼ぶ。モデルの外に置いておき、必要なときに取り出して見る手順書のようなものだ。そして、エージェントが経験を積んでこの手順書を一度手直しするサイクルをエポック(epoch)という。エポックを重ねるほどスキルが良くなるだろう、というのが常識的な期待だ。
問題は、その期待がしばしば裏切られることにある。失敗から学んで直すほど良くなりそうなものだが、実際には手を入れる前より悪くなることがよくある。先ほどのベテランのように、エージェントも一度の経験を早合点で規則として刻み込んでしまうからだ。では、これを自分たちの仕事に置き換えるとどういう意味になるのか — この問いは後ほどONTLEの事例で改めて取り上げる。
吉林大学の研究チーム(Yan Zhouほか)が打ち出したEviSkillは、ここにシンプルな規則を立てる。スキルを直すたびに、問題が起きたまさにその場面を修正案で再実行してみて、実際に振る舞いが良くなったときだけ反映する、というものだ。3つのベンチマーク・6種のLLMで検証したところ、ほとんどの組み合わせで最も高い成功率を出した。特に目を引くのは、ほかの自動修正手法が同じ条件でむしろ初期スキルより性能が落ちる後退を見せるなか、EviSkillはその場で最も高いスコアを出したという点だ。
EviSkillは、既存の自動修正方式が抱える2つの穴を狙う。1つは修正の根拠が消えてしまうこと、もう1つは却下された修正の束をまるごと捨ててしまうことだ。以下の3つの段階が、それぞれこの穴をどう塞ぐのかをたどっていくと、既存方式がなぜ後退したのかも自然と見えてくる。
ステップ1 — エビデンスカードで根拠をつかんでおく。 既存方式は観察をそのまま「こう直せ」に変換する。すると、なぜこの一文を変えたのか、どんな状況がその変更を正当化したのかが消えてしまう。半年後に「このステップはなぜ入ったのか」と問われても、答えようがない。EviSkillは観察を、まずエビデンスカードとして整理する。カード1枚には、追跡用の識別子、この修正を裏づける実行区間(どの課題の、どのエポックの、何ステップ目から何ステップ目までか)、そして提案された修正が収められる。修正を作るときには、その修正がどのカードに依拠しているかリンクを張っておく。根拠が修正とともに残るのだ。カードが際限なく積み上がることはない。役目を終えたカードは寿命が来れば押し出され、繰り返し却下されたカードは新しい修正を作る際に除外される。
ステップ2 — 問題の場面だけを再現して検証する。 ここでEviSkillはほかの手法と袂を分かつ。他の研究は実行記録からもっともらしい教訓を抜き出し、そのままスキルに反映する。だが、経験から出た修正だからといって、いつも改善を保証するわけではない。論文の予備的研究がこれを実測で示している。経験から抜き出した修正を元のスキルに適用してその課題を回し直したところ、性能が上がるものもあったが、そのままのものや、むしろ下げてしまうものもあった。そこでEviSkillは反映の前に一段階を挟む。カードの区間情報でその場面の直前までの状態と対話履歴を復元したうえで、修正されたスキルのもとでその区間だけ再実行する。課題全体を最初から回すのではなく、詰まっていた場面だけをピンポイントで再現するのだ。そのうえで評価者(判定を担うLLM)が、元の場面と再現した場面を比べ、3つのうちいずれかに判定する。新たな失敗なく意図した修正が成立すれば受容、欠陥は見えるが手直しできそうなら保留、それ以外は却下。保留された修正は一度手直ししてから、再び再現・再評価する。
ステップ3 — エポックをまたいで改めて吟味する。 再現を通ったからといって、すぐに確定はしない。EviSkillはスキルを2組で運用する。1つは検証性能が上がったときだけ更新する保守的な確定スキル、もう1つは再現で裏づけられた修正を暫定的に乗せ、複数のエポックにわたって見守る試験スキルだ。きれいな正本と、まだ実験中の下書きを別々に置いておくわけである。
この2組構造が2つ目の穴、すなわち束ごと廃棄を防ぐ。既存方式は1ラウンドで却下された修正の束をまるごと捨てる。その中に使える修正が混ざっていても一緒に消える。だが論文の予備的研究を見ると、束全体が却下されても、その中の一部の修正だけを選んで残せば、それ以前に通過したスキルより性能が上がった。そこでEviSkillは、束が却下されてもその中の修正を1つずつ別々に再現し、ほかの暫定修正に頼らずそれ単独でも効果があるかを確かめたうえで、通過したものだけを拾う。定められたエポックが終わると、確定スキルだけを凍結して実運用に使い、最後まで確定できなかった暫定修正は外す。
経験駆動の手法の中でもっとも近いSkillOptは、「検証スコアが上がる修正だけを受け入れる」という1つの関門だけを置く。EviSkillはその関門はそのまま残しつつ、その手前に再現チェックと、却下された修正の再審議という層をさらに敷いた格好だ。
評価の舞台は、相互作用型のベンチマーク3つだ。アプリAPIで課題をこなすAppWorld(168課題)、科学実験を扱うScienceWorld(211)、テキスト環境で家事課題を解くALFWorld(134)。3つのデータセットいずれも、学習・検証・テストを重ならないように分け、学習セットでスキルを直し、検証セットで採用の可否を決め、テストセットで最終評価する。指標は課題成功率(%)の1つだ。
エージェントの振る舞いを実際に生み出すLLM、すなわちバックボーンにはGPT系とQwen系の6種を使った。比較対象は2つの束だ。スキルを使わないNoSkillと、初期スキルを固定で使うLLM Skillが「進化しない」ベースライン、Trace2Skill・EvoSkill・SkillGrad・SkillOptが「スキルを直していく」競合手法である。
第一のメッセージは、EviSkillがおおむね最も良かったということだ。18のモデル×データセットの組み合わせのうち14で最高、16で上位2位以内に入り、すべての組み合わせでNoSkillを上回った(NoSkill比で平均+17.93%p)。ただしこの平均は、出発点がまちまちな組み合わせを束ねた値なので、単一設定の成果として読んではいけない。優位が際立った例として、ScienceWorld・Qwen3.5-9BでEviSkillは37.91%と、その設定の最強ベースライン(SkillOpt 22.27%)を15.64%p上回った。
第二のメッセージのほうが重い。スキルを直したからといって初期版より良くなる保証はないということだ。ある最新のGPT系モデルをScienceWorldで回した結果を見ると、初期スキルが76.78%なのに対し、Trace2Skillは65.40%、EvoSkillは54.50%、SkillGradは67.30%とむしろ下がった。何も直さなかったほうにすら及ばない結果だ。
なぜこんなことが起きるのか。一度の実行から抜き出した教訓は、その状況にだけあった偶然の事情まで「規則」だと取り違えやすい。その教訓が手順書に刻まれると、以降すべての課題がその偏った規則を経由して解かれる。一事例の特殊性が全体の既定値になってしまうのだ。すでに答えを知っている人が、初心者がどこで詰まるか想像できない「知識の呪い」のように、ある場面で学んだスキルはその場面の外を見ないまま、システム全体に誤った偏りを注入する。性急な学習ほど損が深くなる理由だ。同じ設定でEviSkillが83.41%に達し、全体として初期スキル比で17設定で改善・1設定で同点を出したのは、修正を振る舞いで検証し、確定は保守的に進める関門が、まさにこの罠をふるい落とすからである。
2つの仕掛けがそれぞれ役割を果たしていることも確認された。GPTバックボーン3種の平均を基準にすると、再現検証を外すと3つのベンチマークで平均精度がそれぞれ2.49・4.56・2.85%p下がった。エポックをまたぐ再審議をなくした条件でも性能は下がった。論文はこの結果を、2つの仕掛けが互いに重ならず独立して寄与している根拠として提示している。
著者たち自身が認めている部分から。AppWorldでは、競合手法に対する優位が一貫していない。先に見た最新のGPTモデルをAppWorldで回すと、EviSkill 94.64%はLLM Skill 94.05%と大差なく、Qwen3.5-9B・AppWorldではEviSkill 43.45%がSkillOpt 47.62%に後れを取る。手法そのものの欠陥というより、APIを組み合わせて解く課題のように「振る舞いの再現で修正効果をきれいに切り分けにくい」環境がある、というシグナルとして読むのが妥当だ。これは筆者の解釈である。
測定の範囲も押さえておく必要がある。指標がテスト課題の成功率なので、「修正が実際に機能する手順の改善なのか」はうまく測れるが、その改善がベンチマークの扱わないまったく別のタイプの課題にまで広がる汎用性は、この数字だけで断定しにくい。学習・検証・テストを重ならないように分けているので、テスト課題そのものを事前に見てしまうことはないが、それと「学んだことのないタイプへの拡張」は別の問いだ。
コストも、実務導入の前に別途見積もっておくべき箇所だ。EviSkillは修正ごとに場面を再現し、エポックを比較し、却下された修正まで回し直す。一度の推定で終える方式より再実行が多い。論文は効率分析を含んでいるが、実際のコストは使う環境によって変わりうる。最後に、評価者・抽出器・編集器がすべてLLMであるという点は、「この再現が修正を成立させたか」をLLMが判定する構造だということを意味するので、評価者自身の偏りがどこまでふるい落とされるのかは、この指標だけでは分かりにくい。
最初に投げた問い — 「これが自分たちの仕事にどういう意味を持つのか」 — に戻ってみよう。ONTLEのAI PMが「新規取引先登録」の手順を回していて、ある顧客企業で事業者番号の検証ステップに詰まったとしよう。
経験駆動の方式なら、「このステップの前に事業者番号の形式チェックを入れろ」という教訓をすぐ手順書に刻む。ところが、その失敗が実はその顧客企業だけの入力フォームのせいだったとしたら、この修正はほかの顧客に不要なステップを強いることになり、その上にまた別の修正が積み上がる。一顧客の特殊な事情が全社の既定値になってしまうのだ。
EviSkill式は4つのステップを踏む。まず詰まった場面を証拠として残す — どの顧客の、どの作業の、何ステップ目で、何に詰まったのか。次に、手順書全体を作り直す前に、その場面だけを修正手順で再現する。直した手順で回したら新たな問題なく通過すれば、修正案そのものはひとまず「その場面では」成立したことになる。
だが、ここで止まらないのが肝心だ。この通過は一顧客の場面を再現した結果にすぎず、その修正が全取引先にとって良いかはまだ分からない。そこでほかの顧客の事例まで含んだ検証セットで回し直す。 ここで「その顧客だけの事情だったのか」「みんなに通じる共通の改善なのか」が分かれる。局所再現(詰まった一場面を戻すこと)と適用範囲の検証(複数の顧客にまたがって吟味すること)は、このように別の段階だ。最後に、この検証で指標が上がったときだけ正式な手順に昇格させる。
この過程で目に見える効用は2つだ。一顧客の特殊な状況から出た修正が全取引先の手順にすぐ広がる前に、別の検証という一層を経ることになるということ(完全に防ぐというより、通過しなければ上がらない、というほうに近い)、そして「なぜこのステップが入ったのか」と問われれば、いつでも元の場面で答えられるということだ。
EviSkillが投げかける問いは、技術というより態度に近い。失敗が見えるたびに手順書に一行ずつ書き足して修正の「量」を積む仕事はたやすい。だが、その一行が本当に効くのかを問題の場面で戻して確かめ、どこから出た修正なのか根拠をともに残し、一度否決されても中身だけを改めて審議する仕事 — そうやって「質」を担保する修正は面倒だ。EviSkillの実験が示したのは、その面倒を飛ばした多くの修正が、何も直さなかったものにすら及ばない場所へとしばしば滑り落ちる、という事実である。直した回数ではなく、その直しが検証を通ったかどうかが、スキルの運命を分ける。