WikiSkillは、AIエージェントにwiki型の永続メモリを与え、タスクのたびに学んだことを捨ててしまう状態をなくすGoogle Researchのフレームワークです。エージェントの作業領域を3つの層に分けます。起きたことの生ログ、その実行結果を文書化された失敗パターンと成功戦略に蒸留するwiki、そしてエージェントが実際に読むスキルファイル群です。wikiは増える一方ですが、個々のスキルは検証スコアを改善しなければ元に戻されます。
結果は本物です。5つのベンチマークで、Gemini-3.5-Flashの平均精度は49.5%から68.1%に上がり、WikiSkillを使った小さなモデルが、スキルなしの大きなモデルを上回りました。スキルはモデル間でも移せます。
率直な注意点もあります。これはモデルが賢くなったわけではありません。あるメディアの表現では、エージェントは真に学習するのではなく「自分のためにより良い指示を書いている」のです。回避策ですが、きちんと測定されています。
サポートチームを率いているなら、役立つのは論文そのものではなくそのパターンです。実際のチケット履歴を再利用可能な知識にまとめるAIエージェントは、まさにeesel AIがヘルプデスク向けにすでに行っていることで、顧客に回答する前に過去のチケットでシミュレーションできます。
WikiSkillとは実際に何か
多くのAIエージェントは記憶喪失です。タスクを与えると処理しますが、途中で見つけた工夫や、10ステップも無駄にした行き止まりといった学びは、実行が終わった瞬間に消えます。次のタスクはゼロから始まります。単発なら問題ありませんが、何千回も行う仕事で上達する方法としては最悪です。
WikiSkillは、これに対するGoogle Researchの答えです。2026年8月27日にLiyan Tang氏、Cyrus Rashtchian氏ら6名がarXivで公開したもので、実行をまたいで蓄積される永続的なナレッジベース、つまり「wiki」と並行して、エージェントのスキルを共進化させるフレームワークです。著者らの中心的な問いは率直です。エージェントの経験を、長期的なスキル進化を支える永続的な知識にまとめられるか、というものです。
まず定義を簡単に。ここでの「スキル」には特定の意味があります。エージェントスキルとは、再利用可能なファイルベースのモジュールで、手順の指示とそれを適用する条件を記したSKILL.mdを含む整理されたフォルダです。モデルの重みには触れずにエージェントの能力を拡張します。これまでの研究でも、エージェントの実行からこうしたスキルを自動的に発見する試みはありました。WikiSkillの貢献は、生の経験とスキルの間に置かれるもの、つまり構造化され成長するwikiです。
この発想には有名な系譜があります。論文は、Andrej Karpathy氏の2026年の「LLM Wiki」という見方、つまりモデルの経験を散逸させず、永続的で積み上がる知識にまとめるべきだという主張を挙げています。DAIR.AI創設者のelvis (@omarsar0)も、論文が公開された際に同じ点を指摘しました。
"This WikiSkill paper from Google is a must-read. At a high level, it shows the effectiveness of persistent agents, knowledge bases, and skills. @karpathy popularized LLM Wikis. But this paper provides an actual framework for how agents can tap into a wiki of skills that evolve."
3つの層：raw、wiki、skill
設計全体は、多くのシステムが混ぜてしまう3つのもの、つまり何が起きたか、何を学んだか、次に何をするかを分けて保つことに尽きます。WikiSkillはそれぞれに専用の層を与えます。
Raw層（raw/）は日記です。各実行の完全な実行トレースを保存します。エージェントの推論、すべてのツール呼び出し、すべての結果、最終回答です。不変なので、後から書き換えられることはありません。ほかのすべてが築かれる素材です。
Wiki層（wiki/）は経験が知識になる場所で、フレームワークの中心です。パターンページのディレクトリを持ち、各ページが1つの失敗モードまたは1つの成功戦略を具体的な回避策とともに記録します。さらに進化ログとスキル影響トラッカーも含みます。要となるルールは、wikiは決してリセットされず、ロールバックもされないことです。蓄積のみです。スキルの実験が失敗しても、そこから得た教訓は書き残されます。
Skill層（skills/）は、エージェントが作業中に実際に読む部分です。各スキルフォルダには指示を記したSKILL.mdと、そのスキルを生んだwikiパターンへ対応付けるPURPOSE.mdがあります。wikiと違い、ここでのスキルは元に戻せます。性能を悪化させる変更は取り消されます。
この分離、つまり永続的な記憶と元に戻せる行動こそが巧妙な点で、見落としやすい部分です。同じ考えを図にしたのが次の画像です。
進化ループの仕組み
学習の各ラウンドは4ステップのループで動き、そのうち1つはまさに直感に反します。
- Inference Agent。 現在のスキルを訓練タスクで実行し、生のトレースを生成します。注目すべきは、論文がこのエージェントに訓練中のwiki閲覧を意図的に禁じていることです。アブレーションでは、ここでwikiを覗かせると最終的なスキルの質がむしろ悪化し、平均が63.7%から60.9%に下がりました。仮説は、エージェントがスキルではなくwikiから答えを得ると、そのトレースがスキル改善の証拠として役に立たなくなる、というものです。
- Wiki Maintainer。 成功と失敗のトレースのサンプルを読み、失敗の根本原因を分析し、成功から戦略を抽出して、すべてをパターンページとしてwikiに書き込みます。
- Skill Proposer。 wikiのインデックスと実行履歴から始め、必要に応じて特定のパターンページを読むマルチターンのエージェントです。新しいスキルか既存スキルの編集のどちらか、ちょうど1つの原子的な変更を提案します。
- ゲーティングとロールバック。 提案されたスキルセットを、別の検証用分割で採点します。現時点の最良を上回れば採用され、そうでなければ取り消されます。どちらの場合も、wikiには試した内容の記録が残ります。
Googleチーム自身のケーススタディがこれを具体的に示しています。ALFWorldベンチマークで、proposerが最初に試みた「goal-directed-action」スキルは抽象的すぎるとして却下されました。却下とその理由がwikiに保存されていたため、次の反復ではより鋭く採用されるスキルが、具体的なルール（"Never return an item to its origin location"）とともに書かれ、その数回後にも新たな失敗のバリエーションが現れるたびにさらに洗練されました。
論文のアブレーションは、wikiが存在価値を持つ理由を裏づけます。Skill Proposerに永続wikiへのアクセスを与えると、ベンチマーク平均が48.7%から63.7%に上がり、15ポイントの跳ね上がりとなりました。メモリは飾りではなく、利得の大部分の源です。
本当に機能するのか？数字で見る
はい、しかも一貫して機能します。これが、よくある研究デモの但し書きと一線を画す点です。チームは5つのモデルを5つのベンチマーク（数学、ウェブ検索、スプレッドシート、長文脈の文書QA、インタラクティブなタスク）で試し、それぞれ3回の完全な実行の平均を取りました。
| モデル | 平均（スキルなし） | 平均（WikiSkillあり） |
|---|---|---|
| Qwen-3.5-4B | 26.2% | 38.5% |
| Qwen-3.5-9B | 29.9% | 47.4% |
| Qwen-3.6-27B | 39.4% | 63.3% |
| Gemma-4-31B | 41.3% | 54.9% |
| Gemini-3.5-Flash | 49.5% | 68.1% |
出典：Tang et al., 2026。単一ベンチマークではさらに大きな伸びもありました。Gemini-3.5-Flashは数学ベンチマークで33.0%から72.6%に、Qwen-3.6-27Bはスプレッドシートで40.8%から81.7%に上がりました。
WikiSkillは、競合するすべてのスキル進化手法（Trace2Skill、EvoSkill、SkillOpt）を5つすべてのモデルの平均で上回り、それらの手法と違って特定のベンチマークを悪化させることもほとんどありませんでした。この信頼性が静かな見出しです。平均では役立つが3つに1つのタスクで崩れる手法は、本番では信頼しづらいものです。サポートチームが、簡単な問い合わせだけでなくあらゆる種類の問い合わせでAIによるチケット解決率が維持されることを重視するのも、同じ理由です。
私が繰り返し立ち返る発見は、スキルが規模の代わりになりうるということです。WikiSkillを使ったQwen-3.5-9B（47.4%）は、スキルなしのはるかに大きなQwen-3.6-27B（39.4%）を上回りました。手続き的な知識とモデルの素の大きさは、互換ではなく補完の関係にあるようです。
モデル間を移動するスキル
最も注目された結果がこれです。あるモデルが進化させたスキルは他のモデルやファミリーにも移せ、移したスキルは、スキルなしの場合にも、そのモデル自身が自己進化させたスキルにも、しばしば勝ります。ALFWorldでは、Qwen-3.5-9BがQwen-3.6-27Bが進化させたスキルを使って70.2%に達し、自分のスキルでの63.4%を上回りました。小から大でも機能します。小さなQwen-3.5-4Bのスキルが、はるかに大きなGemma-4-31Bを数学とインタラクティブのベンチマークで押し上げました。
Mark Kretschmann (@mark_k)は、これを最も興味深い点として挙げました。
"'WikiSkill' lets agents turn their own experience into persistent knowledge that compounds over time... Even more interesting: skills transfer between models. In some cases, a model performed better using skills learned by another model than skills it developed itself."
著者の見方では、良いスキルを見つけることと実行することは別の能力であり、自己進化は通常この2つを混同します。サポート業務向けのLLMを選ぶ際に役立つ捉え直しです。プレイブックの実行が最も得意なモデルが、書くのも最も得意とは限りません。
ただし、移転は無料ではありません。モデル固有の回避策を組み込んだスキルは裏目に出ることがあります。小さなQwen-3.5-4Bのスプレッドシート用スキルは低レベルなPythonの小技だらけで、より強いモデルがすっきりしたエンドツーエンドのコードを書くのを妨げたため、Gemini-3.5-Flashを50.5%から18.1%に落としてしまいました。つまり「スキルは移せる」は実在する性質ですが、前提とせず、ケースごとに試すべきものです。
率直な注意点：これは回避策であり、真の学習ではない
多くの報道が控えめに扱う部分ですが、冷静に見ておく価値があります。WikiSkillは基盤モデルを学習させるわけではありません。重みは変わりません。THE DECODERははっきりこう述べました。エージェントは"doesn't truly learn in a continuous sense, which remains an unsolved problem."で、代わりに"it writes better instructions for itself after each run and can pull them up the next time around."とのことです。このアプローチへの評価は、"not elegant, and it's probably more error-prone than real learning, but the study shows it's an effective workaround."でした。
購入判断に持ち込むべき見方はこれです。この種のシステムの質は、書き残す知識と、それを選別するゲートの質で決まります。論文も限界について率直です。
- wikiの剪定なし。 wikiは増える一方なので、非常に長い実行では古くなったパターンを忘れる仕組みが必要になりますが、まだありません。
- 厳格なゲーティング。 提案されたスキルは検証スコアを改善しなければ残らないため、後で効いたかもしれない中立的な変更は捨てられます。
- スキル検索は未検証。 スキルの質を切り分けるため、研究では関連スキルを検索せず、すべてのスキルをプロンプトに直接入れています。スキルが多くなると重要になる点です。
- 公式コードなし。 2026年9月時点で、GoogleはWikiSkillのコードを公開していません。独立した開発者が論文から再実装し、自分の実行では検証ゲートが有害なスキルを2つ止めたと記しており、安全確認が実際に機能していることの裏づけになっています。
これらはWikiSkillの魅力を損ないません。むしろ誠実さを示します。AIシステムが何をして何をしないのかを誠実に説明してくれることは、実務を任せる前に私が求める条件であり、AIと人間のエージェントを比べるときにも同じ基準を当てはめます。
AIサポートエージェントにとっての意味
ベンチマークを取り除くと、WikiSkillが描いているのは、サポートやCXのチームがすぐに見覚えを感じる形です。繰り返しの仕事で、自らの経験を再利用可能で検証可能な知識にまとめることで、測定可能なほど上達していくエージェントです。これはサポートにすでにAIを使っている企業が頼っているパターンであり、研究室の珍品ではありません。それこそが要点です。
elvis氏も、研究から実践へ同じ飛躍をしています。
"The practical takeaway here is that we should all be thinking about how to build persistent knowledge bases across our companies and projects. And how to use that to upgrade and evolve our skills."
サポートキューは、このパターンの理想的な居場所です。過去のチケットが、そのままraw層です。マクロ、ヘルプセンター、解決済みのスレッドが、そのままwikiです。そして「変更を受け入れる前にゲートを通す」という考え方は、多くのAIサポート導入が省いて後悔する唯一のものです。ボットを本番に出して祈るだけだからです。ここで研究とカスタマーサポート自動化の現実が出会います。成功するチームは、WikiSkillのゲートがスキルを残す前に検証するのと同じように、信頼する前に測定するチームです。これは、AIと人間のエージェントのコスト比較を誠実に行うと、結局「まず解決率を測る」に行き着く理由でもあります。
チケットから学ぶサポートをeeselで試す
WikiSkillが私にとって馴染み深く読めるのは、eeselのAIヘルプデスクチームメイトがすでにこの原理で動いているからです。サイトに後付けされた汎用チャットボットではありません。既存のナレッジ、過去のチケット、ヘルプセンター、ドキュメントで学習し、Zendesk、Freshdesk、Gorgias、Help Scoutなど、すでに運用しているヘルプデスクの中でキューに加わります。1000以上の連携に対応しています。
WikiSkillのゲートに最も直接対応する差別化要素がシミュレーションです。eeselのチームメイトがライブの顧客に一件も回答する前に、過去のチケットに対して実行し、どう対応したかを確認できるため、解決率は信じて受け入れる約束ではなく、自分で確かめる数字になります。「受け入れる前に検証する」という規律を、自社のサポート履歴に適用したものです。営業電話なしで無料でeeselを試せ、顧客のGlobal Payは稼働後に最大80%の時間削減を報告しています。