WikiSkillとは？Googleのエージェントスキル進化フレームワーク、仕組みや性能、使い方を解説

WikiSkill（ウィキスキル）は、Google Researchが2026年8月27日にarXivで発表したAIエージェントのスキル進化フレームワークです。
生の実行履歴・蓄積される知識・実行可能なスキルを3層に分離し、失敗と成功を永続的なWikiに畳み込みながらスキルを更新していく設計で、小型モデルでも大型モデルを上回る精度を出せる点が注目されています。

本記事では、仕組み・性能・使い方・EvoSkillなど類似手法との違い・導入判断までを、2026年10月時点の最新情報で体系的に解説します。

WikiSkillとは？Google Researchが提案したエージェントスキル進化の新しい設計

WikiSkill（ウィキスキル）とは、Google ResearchとVirginia Techの研究チームが2026年8月27日にarXiv:2608.27454で発表した、AIエージェントの経験を永続的なWiki（知識ベース）に畳み込みながら、エージェント自身のスキルを進化させるフレームワークです。

従来のエージェント運用では、1タスクを実行して得られた教訓は実行履歴に残るだけで、スキルファイル（SKILL.md等）に反映されるかどうかは人間の判断に委ねられていました。WikiSkillはここに「失敗と成功を蓄積するWiki層」と「WikiをもとにスキルをパッチしていくProposer」を挿入し、エージェントが自分で経験を資産化していく仕組みを定式化しています。

WikiSkillが他のスキル進化手法と根本的に違うのは、提案したスキル改修が却下されても、却下理由と失敗パターンはWikiに残り続けるという点です。

その結果、エージェントは履歴を参照して「過去に試して却下された改修と似た提案を避ける」よう設計されており、学習が同じ地点を周回しにくくなります。失敗を忘れないメモリを持ったエージェント、というのが最大のポジショニングです。

メモリ・スキル系フレームでの位置づけ

AIエージェントまわりで「経験を蓄積する」話は、2026年に入って複数の方向から進んできました。たとえばMem0・Zep・Lettaなどのメモリ系フレームワークは、ユーザーとの会話履歴から事実を抽出して長期記憶として引き出す層を提供します。

一方、Claude CodeのAgent SkillsやCodexのAgent Skillsは、手順書（SKILL.md）をエージェントが読み込んで実行する層を提供します。

ここでのポイントは、メモリ層は「事実の記憶」、スキル層は「手順の記憶」を担うのに対し、WikiSkillは両者の中間にある「教訓の記憶」を定式化した、という点です。

事実（Raw実行履歴）とスキル（手順書）の間に、「過去にこういう失敗があり、こう対処した」というパターンのwikiを挟む設計で、既存のSKILL.md運用に失敗ログを組み込む具体的な方法を示したところが新しさです。

---

WikiSkillの3層アーキテクチャ——Raw/Wiki/Skillsの分離設計

WikiSkillの実装は、エージェントのワークスペースをRaw / Wiki / Skillsの3層に明確に分けるところから始まります。本セクションでは、各層が何を保持し、なぜ分離する必要があるのかを整理します。

WikiSkill論文の表現を借りれば、Rawは「不変の実行履歴」、Wikiは「反復ごとに蓄積される構造化知識」、Skillsは「可逆的に更新される実行可能な手順書」です。層ごとに書き換えポリシーが異なり、情報の寿命と役割が整理されています。

Raw Layerは実行トレースを不変に残す

Raw Layerには、エージェントがタスクを実行したときの生のトレース（ツール呼び出し・観察・推論ステップ）が、イテレーションごとに追記されていきます。この層は一度書き込まれたら書き換えないという原則が強く置かれており、過去のトレースを後から改ざんすることはできません。

役割はシンプルで、「後段のWiki MaintainerやSkill Proposerが失敗と成功の原因を分析するための一次ソース」です。SIer現場でいえば、障害対応時に真っ先に取りに行くログファイルに近い位置づけです。

重要なのは、Raw Layerの情報をそのままinference agent（本番でタスクを実行するエージェント）には渡さないという設計です。生のトレースは量が多すぎてコンテキストを圧迫するため、本番で読むべきは後段のSkill Layerだけに絞る、という割り切りが入っています。

Wiki Layerで知識が蓄積する3要素

Wiki Layerは3層の心臓部で、Raw層の実行履歴を失敗モードや成功パターン単位に畳み込んだ知識を保持します。構造は以下の3要素です。

• patterns/
  失敗モード・成功戦略ごとに1つのMarkdownページを置くフォルダ。各ページには症状・根本原因・具体的な回避策またはコマンド列が記録される。
  
  

• logs.md（evolution log）
  各イテレーションで何を観察し、どのパターンを更新したかの時系列ログ。Wiki MaintainerとSkill Proposerの両方が参照する。
  
  

• skill-impact.md（skill impact tracker）
  提案されたスキル改修のメタデータ・unified diff・バリデーションスコア・採用／却下結果を1件1行で記録する台帳。却下された改修も削除せず残す。

Wiki Layerはどのイテレーションでもロールバックしないという設計が特徴です。スキルが途中で失敗してロールバックされても、Wiki側は「失敗の記録」を抱えたまま次のイテレーションに引き継がれます。

この「Skillは可逆、Wikiは不可逆」という非対称が、WikiSkillが同じ失敗を繰り返さなくなる原理的な理由です。失敗を抱えたまま前進できる構造を、ファイルシステム上で素直に実装したと言えます。

Skills LayerはSKILL.md形式で凝縮する

Skills Layerは、Wikiから抽出した知識を**実行可能な手順書（SKILL.md）**として凝縮した層です。Claude CodeやCodexがそのまま読み込める形式のため、本番環境ではこの層のファイルだけがinference agentに渡されます。

論文によれば、WikiSkillの実験ではモデル別の平均でSKILL.mdが45〜129行に収まっており（Gemma-4-31Bで45.1行・Qwen群で118〜128行）、本番で読み込ませるファイルがコンパクトに保たれる設計になっています。タスク別で見るとSpreadSheet系が平均142.5行と長めで、タスク特性で変動する点に注意が必要です。

Skills Layerは、Validation Gating（後述）の結果に応じて可逆的に書き換わる設計です。改修が失敗すれば直前の状態に戻せますが、戻した事実はWiki側のskill-impact.mdに残るため、Proposerは次の提案時にその履歴を参照して類似の改修を避けるよう動きます。

Claude CodeのSubagentsやGitHub CopilotのAgent Skillsでも使われるSKILL.mdフォーマットと互換性があるため、他のエージェント基盤に移植してもそのまま動作します。これはWikiSkillが単発のフレームワークではなく、既存のスキル配布エコシステムに乗る形で設計されている証拠でもあります。

WikiSkillフレームワークの全体像。Raw/Wiki/Skillsの3層と4ステップの進化ループが示されている（出典：arXiv:2608.27454 Figure 2）

Wiki Layerだけが「Compounding, Never Reset」として永続化され、Skill Layerは「Reversible, Conditional Update」として可逆的に書き換わるという非対称が、この図を見ると一目で把握できます。学習の軌跡がWikiに残る一方、本番で使うSkillだけは安全にロールバックできる、というWikiSkillの設計思想がそのまま視覚化されています。

---

WikiSkillの進化ループ——Wiki Maintainer・Skill Proposer・Validation Gating

3層アーキテクチャの上で、WikiSkillはInference Agent → Wiki Maintainer → Skill Proposer → Gating & Rollbackという4ステップのサイクルを回し続けます（Wikiの更新は各処理内で行われます）。1イテレーションでこのサイクルを1周し、スキルが改善しないときはSkillだけロールバックしてWikiはそのまま前進する、というのが基本動作です。

本セクションでは、各コンポーネントの役割と、却下された提案がWikiにどう残るかを整理します。

Wiki Maintainerの畳み込み処理

Wiki Maintainerは、直近のイテレーションで集まった実行トレース（Train splitからサンプリング）を読み込み、失敗の根本原因と成功の戦略を抽出してpatternsページに畳み込む役割を担います。既存のパターンページがある場合は更新し、未知のパターンなら新規ページを作ります。

ここで重要なのは、MaintainerはSkill本体には手を加えないという分業です。Skillの編集はあくまでSkill Proposerの仕事で、Maintainerは「知識ベースを綺麗に保つ」ことに専念します。この役割分離が、Wiki側とSkill側の変更責任を切り分ける土台になっています（なお論文のLimitationsにもあるとおり、Wiki自体を自動で整理・圧縮する仕組みは本手法には含まれません）。

Skill Proposerはatomic提案を出す

Skill Proposerは、Wiki index・skill-impact.mdの履歴・タスクサマリから作業を開始し、単一スキルに対する原子的（atomic）な修正提案を1つ生成します。

ここが他のスキル進化手法との大きな違いで、ProposerはReAct形式のマルチターンで動作し、関連しそうなpatternsページや過去の実行トレースを環境ツール経由で明示的に読みに行きます。全知識を一度にコンテキストへ詰め込むのではなく、必要な部分だけ取り出すインクリメンタルな設計です。

Proposerが「atomicな提案」を出すよう制約されている理由は、複数スキルをまとめて書き換えると、どの変更が性能に効いたか切り分けられなくなるからです。1イテレーション=1スキル1パッチに縛ることで、Validation Gatingの判定が明確になります。

Validation Gatingの採用基準

生成された提案は、Validation splitで即座に評価されます。既存ベストスコアを厳密に上回った場合のみ採用され、下回ったり同点の場合は提案を破棄してスキルを直前の状態に戻します。

論文の表現を借りれば「改善が確認できなければそのパッチは本番に出さない」というだけの話で、仕組み自体は深層学習におけるearly stoppingやvalidation-based model selectionとほぼ同じ思想です。

決定的に違うのは、スキル側はロールバックするが、Wiki側はロールバックしないという点です。失敗した提案が何だったか、どのパターンを狙ったのか、なぜ落ちたのかは、全てWikiに記録されたまま次のイテレーションに引き継がれます。

却下提案はskill-impact.mdに残る

Validation Gatingで却下された提案は、unified diff・バリデーションスコア・却下結果とともにskill-impact.mdに記録されます。次のイテレーションでSkill Proposerはこの履歴を読み込むため、「以前却下されたパッチと類似の提案を出すと即座に自覚できる」ようになります。

これは一見地味ですが、スキル進化系フレームワークの長年の課題である**「同じ失敗を永遠に繰り返す」問題**への直接の処方箋になっています。
VentureBeatはこれを「失敗の記憶を、プロンプトに積まずに持たせる方法」と表現しました。

本番のinference agentは失敗ログ全体を読まないため、プロンプトは肥大化しません。失敗の記憶を扱うのはイテレーション外側のProposer側だけという切り分けが、本番コストを抑えたまま学習を蓄積する鍵になっています。

Iteration 0の却下情報がWikiに残り、Iteration 1で採用スキルに反映されるケーススタディ（出典：arXiv:2608.27454 Figure 3）

左側のskill-impact.mdでIteration 0が「REJECTED」として履歴に残り、Iteration 1でpatternsとlogsを根拠に「break-repetition-loop」という新スキルが「ACCEPTED」として採用される流れが実例で確認できます。

却下した事実が消えずに次の提案を導く、という本章の説明がALFWorldタスクで実装されたときの具体的なファイル構造です。

---

WikiSkillのベンチマーク結果——5タスク×5モデルで+12〜24点

WikiSkillは論文内で5つのベンチマーク×5つのモデルで評価されており、無スキルベースライン・既存のスキル進化手法（EvoSkill・SkillOpt・Trace2Skill）を一貫して上回る結果が報告されています。

評価対象の5ベンチマークは、LiveMathematicianBench（数学推論）、SealQA（Web検索）、SpreadSheetBench（スプレッドシート操作）、OfficeQA（長文QA）、ALFWorld（身体化タスク）です。マルチステップで評価関数が明確なタスクが揃っています。

本セクションでは、代表的な数字と小型モデルの逆転事例、そして本番コストの観点を整理します。

Qwen 27Bで+23.9ポイント、9Bが27B超え

以下の表で、Qwen-3.6-27B（モデルサイズ約270億パラメータ）における無スキル・WikiSkillの平均精度を整理しました。

条件	平均精度	代表タスクでの変化
無スキル（baseline）	39.4%	LiveMath 33.9% / SpreadSheet 40.8% / ALFWorld 52.8%
WikiSkill適用後	63.3%	LiveMath 61.9%（+28.0）／SpreadSheet 81.7%（+40.9）／ALFWorld 77.6%（+24.8）

平均で**+23.9ポイント**という伸びに加え、5モデルで横並びに見ると無スキルからの改善幅は+12.3〜23.9ポイントの範囲に収まります。

既存のスキル進化系手法（EvoSkill・SkillOpt・Trace2Skill）に対しても、各モデルの最良競合と比べて+3.3〜12.0ポイントの優位が報告されており、特にスプレッドシート操作のような手順の積み重ねが効くタスクで差が大きく出る傾向があります。