投稿者 投稿日: カテゴリー AIニュース
WikiSkillとは、AIエージェントが経験を記録し自己改善する仕組みです。
Google Research が2026年8月28日付で公開した研究フレームワーク「WikiSkill」が、AIエージェントの積年の弱点である「毎回ゼロから始まる」問題に、実装可能な回答を出しました。5種類のベンチマーク平均で、Gemini 3.5 Flash のスコアが49.5パーセントから68.1パーセントへ、18.6ポイント上がっています。とくにスプレッドシート操作の課題が50.5パーセントから76.6パーセントへ跳ねた点は、CSVと表計算で日々の受注処理を回している日本のEC事業者にとって他人事ではありません。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が解説します。
WikiSkillとは何か、何が起きたのか
WikiSkill は、AIエージェントの作業場を3つの階層に分ける枠組みです。The Decoderが報じ、arXiv に公開された論文（Tang ほか、2026年）に詳細がまとまっています。
一番下が「Raw Layer」で、ツールの呼び出しから結果まで実行の記録をそのまま残します。その上の「Wiki Layer」で、生の記録を「どこで失敗したか」「何がうまくいったか」という構造化された知見に整理します。この層はリセットされず、回を重ねるごとに増えていくのが特徴です。最上段の「Skill Layer」には、エージェントが実際に従う手順書が置かれます。
動き方は4段階です。まず推論役のエージェントが現在の手順書で作業し、実行記録を残します。次に「Wiki Maintainer」がその記録を読んで失敗パターンと成功パターンを抽出し、Wiki に書き込みます。続いて「Skill Proposer」が Wiki を踏まえて手順書の修正案を出します。最後にゲート役が、その修正を別の検証データで試して本当に効果があるか確かめます。効果がなければ手順書は元に戻されますが、Wiki の記録は消えません。失敗した提案すら「なぜ駄目だったか」として次に活きる設計です。
考え方の下敷きになっているのは、Andrej Karpathy が公開したメモの「LLM Wiki」構想です。蓄積された知見は、Agent Skills として標準化されつつある形式で再利用できるモジュールにまとめられます。モデルそのものを追加学習させるわけではないので、既存のAIをそのまま使いながら賢くしていける点が実務的です。
日本のEC事業者にとっての3つの論点
結論から言えば、EC運営で効いてくるのは「表計算・繰り返し作業の精度が上がる」点です。研究チームは数学推論、Web検索、スプレッドシート操作、文書質問応答、仮想環境での対話タスクという5種類のベンチマークで検証しています。伸び幅が最も大きかったのはスプレッドシート操作と数学の課題で、Gemini 3.5 Flash はスプレッドシートで50.5パーセントから76.6パーセント、数学系の LiveMath で33.0パーセントから72.6パーセントに上がりました。
第一の論点は、日々の在庫更新CSVや売上集計のようなルーチン作業ほど恩恵が大きいということです。楽天RMSの商品一括更新CSVやAmazonの在庫ファイルは、店舗ごとに独自の癖があります。「この列は空欄禁止」「この店舗はSKU番号の桁数が違う」といった暗黙のルールを、担当者が毎回口頭で伝え直しているのが実情ではないでしょうか。WikiSkill 型の設計は、その暗黙知をエージェント側の手順書として溜めていく発想です。
第二の論点は、モデルの大きさより「蓄積の有無」が効く場面があることです。The Decoder は、小型モデルでも WikiSkill を使えば使わない大型モデルの性能に並びうると伝えています。実際に Qwen-3.6-27B は平均39.4パーセントから63.3パーセントへ上がっており、上位モデルへの課金を増やす前に「自社の運用知見を書き溜める」ほうが投資効率が良い可能性があります。
第三の論点は、万能ではないという事実です。長い文書を読ませる OfficeQA のような課題では伸びが小さく、小型モデルは複数手順にまたがる検索戦略をうまく実行できず元の振る舞いに戻ってしまうと研究チームは指摘しています。問い合わせ対応のように長文の履歴を読む業務では、期待値を上げすぎないほうが安全です。
今後の動きと、いま取れる初動
WikiSkill は現時点で Google Research の研究成果であり、一般提供される製品として発表されたものではありません。いつどの形で Gemini などに載るかは要確認です。ただし考え方自体は、外部のツールを待たずに今日から真似できます。
第一に、社内でAIに任せている作業の「失敗ログ」を残す場所を決めることです。チャットの履歴に流してしまわず、スプレッドシートでもドキュメントでも構わないので、失敗した指示と原因を1行ずつ追記していきます。これが Wiki Layer にあたります。
第二に、溜まった失敗パターンからプロンプトや手順書を書き換えることです。ここで大事なのは、書き換えたら必ず過去の別案件で試してから本番に戻すこと。研究側のゲート機構と同じ役割で、改善したつもりが悪化する事故を防げます。
第三に、担当者ごとに散らばっている手順を1本化することです。研究では、あるモデルが作った手順書が別のモデルでも機能する場合があり、受け取った側が自分で作った手順書より良い結果を出すことすらあったと報告されています。ただし常にそうとは限らないため、移植のたびに検証は必要です。社内でも同様に、Aさんが磨いた指示文をBさんの業務へ横展開する価値は十分あります。
なお、エージェント運用はトークン消費とコストが直結します。手順書が長くなりすぎると費用が膨らむため、AIエージェントのトークンコストに関する論点や、手順のアンカー化に関するAgent Skillsの整理もあわせて確認しておくと判断しやすくなります。モデル選定でコストを見直す場合は、Gemini 3.7 Flash の価格改定に関する記事も参考になります。
まとめ
WikiSkill が示したのは、モデルを鍛え直さなくても、経験を書き残して手順書に反映するだけでスコアが平均18ポイント以上動くという事実です。EC事業者にとっての実装コストはほぼゼロで、必要なのは「失敗を残す場所」と「書き換えたら検証する習慣」の2つだけです。まずは在庫更新やCSV加工など、毎週繰り返している作業から始めるのが現実的です。
参考文献
- The Decoder｜Google’s WikiSkill gives AI agents a persistent memory of past mistakes to sharpen future performance
- arXiv｜WikiSkill 論文（Tang et al., 2026）
- Andrej Karpathy｜LLM Wiki についてのメモ
- The Decoder｜Anthropic publishes Agent Skills as an open standard for AI platforms
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: The Decoder
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
