Google Researchとバージニア工科大学の研究チームは2026年8月27日、AIエージェントの成功と失敗を蓄積し、実行手順を更新する「WikiSkill」をarXivで公開した。名前からは、エージェントが仕事中に共有Wikiを引く仕組みに見える。しかし実験の既定構成では、タスクを解く実行役にWikiを読ませない。Wikiはモデルの記憶を直接増やす装置ではなく、実行ログから再利用できる手順を作る開発工程に置かれている。
その境界がWikiSkillの要点だ。モデルのパラメータは更新せず、失敗したスキル変更も記録し、検証で成績が上がった手順だけを次の実行へ渡す。研究チームは5種類のベンチマークと5モデルで既存のスキル進化手法を上回ったと報告したが、論文は査読済みとは確認できないarXiv v1のプレプリントである。数字が示す可能性と、まだ実運用へ持ち出せない条件を分けて読む必要がある。
Wikiは記憶装置ではなく、スキル編集部である
WikiSkillの作業領域はRaw、Wiki、Skillの3層に分かれる。Raw層には推論、ツール呼び出し、その結果、最終回答までの実行軌跡を変更せず保存する。Wiki層は、そこから繰り返す失敗や成功した戦略をMarkdownのパターンページへまとめ、変更履歴とスキルへの影響を積み上げる。Skill層に置くのは、次のタスクで実際に使う手順書だ。
着想源は、Andrej Karpathy氏が2026年4月に公開した「LLM Wiki」である。元の構想は、文書を質問のたびに検索して組み立て直すのではなく、内容の矛盾や関連をMarkdownのWikiへ継続的に反映するというものだった。WikiSkillはこの考えをエージェント開発へ移し、知識を実行手順に変える層と、その変更を採否判定する仕組みを加えた。
ただし、実行役にまでWikiを開放すればよいわけではなかった。Gemini-3.5-Flashを使った4ベンチマークのアブレーションでは、実行役のWikiアクセスを無効にしたまま、スキル提案役へ永続Wikiを与えると平均スコアは48.7%から63.7%へ15.0ポイント上がった。一方、実行役にもWikiを見せると60.9%へ2.8ポイント下がった。
研究チームは、実行役がWikiから解法を拾うと、現在のスキルに何が欠けているかを表す軌跡が得にくくなる可能性を挙げる。これは著者らの仮説であり、低下の因果を直接測った結果ではない。それでもアクセス権の切り分けは明快だ。Wikiが支えるのはタスクの直接回答より、手順を診断して直す側である。
失敗した更新も残す4段階のループ
進化のループは4段階で進む。まずInference Agentが現在のスキルを使って訓練タスクを実行する。次にWiki Maintainerが成功と失敗の軌跡を読み、原因や有効な戦略をWikiへ反映する。Skill ProposerはWikiの索引、過去の変更効果、今回の成否一覧から必要な記録を選んで読み、1回につき1つのスキル作成または修正を提案する。最後に候補スキルを別の検証セットで試し、過去最高スコアを上回った場合だけ採用する。
採用されなければSkill層は直前の版へ戻る。だが、Wikiは戻さない。提案の変更箇所、検証スコア、採否をskill-impact.mdへ追記するため、後の提案役は同じ失敗を繰り返さずに済む。実行用の手順は可逆にし、そこへ至る学習履歴は蓄積する設計である。
Wiki Maintainerへ無制限にログを詰め込むわけでもない。各反復で最大8件を選び、内訳は失敗が最大5件、成功が最大3件である。1件のログは15,000文字までに制限する。提案役は固定された大量のログを一括で受け取らず、必要なパターンページやRaw軌跡をツールで選ぶ。Wikiは、長い履歴を丸ごとプロンプトへ足すための倉庫ではなく、診断結果を探せる中間表現として働く。
この仕組みは、モデルが自律的に何でも学ぶ「継続学習」とは異なる。正解を持つ訓練・検証・テスト分割があり、改善を判定できる評価関数がある。WikiSkillが自動化したのは、その条件下で経験を手順へ編集し、悪化した変更を戻す工程だ。
9B＋スキルが27Bの無スキル構成を上回った
評価対象は、数学推論のLiveMath、Web検索のSealQA、表計算のSpreadsheetBench、長文書QAのOfficeQA、対話型環境のALFWorldである。モデルはQwenの4B、9B、27BにGemma-4-31B-ItとGemini-3.5-Flashを加えた5種類だ。Trace2Skill、EvoSkill、SkillOptの3手法とスキルなしの基準を比較し、全工程を3回独立に実行した平均値を報告している。
Qwen系列では、スキルなしからWikiSkillへ替えた平均スコアの伸びが4Bで12.3ポイント、9Bで17.5ポイント、27Bで23.9ポイントとなった。大きいモデルほど手順の発見と利用から得る伸びが大きい。もっとも、モデル規模だけで結果は決まらない。Qwen-3.5-9Bに自身が進化させたスキルを与えると平均47.4%となり、スキルなしのQwen-3.6-27Bが記録した39.4%を上回った。
さらにALFWorldでは、Qwen-3.5-9Bが自ら作ったスキルを使った場合の63.4%に対し、Qwen-3.6-27Bが作ったスキルを移植すると70.2%へ上がった。常に他モデル製が優れるわけではないが、手順を見つける能力と、その手順を実行する能力が別物であることを示す例だ。高性能モデルをスキルの開発役に置き、安価なモデルへ配る構成にもつながり得る。
ただし、平均値の「勝利」を全セルの勝利と混同できない。WikiSkillはQwen-3.5-4BのOfficeQAで28.5%となり、スキルなしの30.2%を下回った。論文の統計判定はテスト項目を復元抽出する1,000回のブートストラップ法を使い、5%水準で差を調べている。タスクとモデルの組み合わせによっては、進化した手順が長文検索を安定して実行させるとは限らない。
強い数字ほど、実験の外側を読む
最初の制約は、スキルの検索と起動を試していないことだ。研究では、選択ミスを評価へ混ぜないため、実行時に有効なスキル全文をシステムプロンプトへ直接入れた。スキルが増えたとき、適切な1件を見つけ、限られたコンテキストへ収められるかは別の問題として残る。
採否判定にも幅がある。5ベンチマークの検証セットは10件から40件で、論文自身が小規模な検証セットによるノイズを認めている。3回の独立実行とテスト結果へのブートストラップ検定は最終値のばらつきを抑えるが、各反復での採否が常に正しいとは保証しない。また、最高値を厳密に上回らない変更は却下されるため、直後の点数は同じでも後の改善を助ける変更を落とす可能性がある。
運用期間が延びれば、別の問題も出る。Wikiにはパターンページ、変更ログ、却下された変更履歴が増え続けるが、自動で整理・削減する機能はない。数百回の操作や数時間に及ぶタスクも未評価であり、1回の長い実行中に手順を更新する仕組みではない。
計算費用の読み方にも注意が要る。論文は訓練データを一括処理した場合、Wiki Maintainerの1回とSkill ProposerのReAct処理を合わせ、反復あたりの最適化用LLM呼び出しを「1＋約10〜20回」と見積もる。この回数は訓練セットの件数に比例しないが、各タスクを実行して軌跡を作る費用は別に発生する。エンドツーエンドの計算量や料金が一定になるという意味ではない。
WikiSkillが提示したのは、AIエージェントへ曖昧な「長期記憶」を足す方法より、経験を証拠、知識、実行手順に分けて管理する方法である。実用性を判断するには、直接注入を外してもスキルを正しく選べるか、Wikiを整理しながら改善を保てるか、そして全工程の費用に見合う失敗削減が得られるかを測る必要がある。
