.claude/skills/ を自動で育てる仕組み — 直す前に「消えない Wiki」を 1 つ挟むだけで成績が変わる

01主張は 1 つ — 直す前に「消えない Wiki」を挟む

skill を書き換える手前に、書き換えの材料をためる層を足す

論文の言い分は 1 文にまとまる。エージェントが得た経験は、skill とは別の「Wiki」に貯めてから skill に変えるべきだ。Wiki を挟むかどうかだけで、育った skill の成績が大きく変わった。

前提を 1 つ置く。skill の自動改訂は「解かせて、直して、測る」を何度も繰り返す。その 1 回分が、論文の言う iteration (イテレーション) だ。この解説では「0 回目・1 回目」と回数で数える。0 始まりは論文の数え方に合わせた。

著者が問題にするのは、学びの置き場が無いことだ。skill を直した理由、試して外した案、何度も再発する失敗。従来の自動改訂では、これらが skill の書き換え履歴のあちこちに散らばり、次の回で体系的に拾い直しにくい。

足したのは 1 層だけだ。作業ログを読んで「症状・原因・直し方」に整理し、消さずに貯め続ける層を挟む。著者はこの層を wiki と呼ぶ。経験を貯めて再利用できる知識にまとめよう、という AI 研究者 Andrej Karpathy の提案 (LLM Wiki) が着想元だ。

出典: arXiv:2608.27454 Abstract・§1 Introduction (Karpathy の LLM Wiki への言及も §1)

02「Wiki」には何が入っているのか

実行中には読ませない材料置き場。中身は目次・症状メモ・日誌・台帳の 4 つ

作業は 3 つの役に分かれる。タスク (論文が解かせる問題) を解く「実行役」、作業ログを読んで Wiki に書く「整理役」、Wiki を根拠に skill の直し方を出す「提案役」だ (手順は 03)。Wiki を開けるのは整理役と提案役だけで、実行役には見せない。

手元の CLAUDE.md は毎回の作業中に読ませる指示書だから、見せる相手が Wiki とは逆になる。この対応づけは本解説の当てはめで、論文は CLAUDE.md に触れていない。Wiki を実行役に見せた時にどれだけ落ちるかは 05 で測る。

論文は置き場を 3 つに分ける。本解説では「戻せるか」と「誰が読めるか」の 2 軸で整理する。

Wiki の中身は 4 つに分かれている。どれも普通のテキストファイル (markdown) で、特別な仕組みは使っていない。

• index.md — 1 行 1 件の目次。「問題 + 原因 + 直し方」を 1〜2 文で書く
• patterns/ — 症状 1 件に 1 枚。原因・実際のコマンド列・回避策を 10〜30 行で
• logs.md — どの回で何を見つけ、何を決めたかの日誌
• skill-impact.md — 出した改訂案が通ったか落ちたかの台帳。落ちた案の差分も丸ごと残す

台帳だけは整理役が書かない。採否と差分は、実験を回す土台のスクリプトが機械的に追記する。人手でもモデルでもない記録だから、提案役はこれを「何が試されて何が落ちたか」の確かな履歴として読める。

出典: arXiv:2608.27454 §3.1・§3.2 (3 つの役)・§3.2.4 (台帳の追記)・付録 E.2 整理役の指示文 (「目次が最重要」も同節)

031 イテレーションはどうやって回るのか

解く → まとめる → 直す → 測る。通らなかった案も台帳に残る

1 イテレーションは 4 つの手順でできている。役割が 3 つに分かれていて、それぞれ見るものが違う。

1. 実行役が、練習用のタスクを全部解く。渡されるのは skill の全文だけ
2. 整理役が、その作業ログから最大 8 本 (失敗 5 本まで・成功 3 本まで) を読み、Wiki に書き足す
3. 提案役が、Wiki の目次から読み進め、改訂案を 1 件だけ出す (「今回は直さない」も正式な選択肢)
4. 検証用のタスクで採点し、過去最高を上回った時だけ採用する

提案役の読み方には順番と下限がある。最初に渡されるのは目次・台帳・練習結果の要約だけで、あとは自分でファイルを開きに行く。考える → ファイルを開く → また考える、を繰り返す進め方 (論文では ReAct と呼ぶ) だ。提案を出す前に作業ログを最低 4 本読むことが、指示文で決められている。

採点は 1 つの数字だけを見る。検証用のタスクを実際に解かせた平均点だ。同点は不合格で、厳密に上回った時だけ採用する。skill は空の状態から始まってこの 4 手順で育ち、モデルの中身は一切変わらない。

タスクの中身と規模は次のとおり。同じタスク集を練習用・検証用・本番用に分けて使う。06 以降の点数は、この本番用のタスクを解かせた正解率だ。この解説では以後、タスクを左端の日本語名で呼ぶ。

skill も Wiki も、タスクごとに別々に育てる (タスク 5 種で 5 セット)。タスクをまたいで 1 つの Wiki を共有する実験はしていない。

出典: arXiv:2608.27454 §3.2・付録 C (作業ログの抽出数)・付録 E.3 提案役の指示文 (「最低 4 本」「no_action」も同節)・表 6 (タスクの内訳)・表 4 (タスクごとの skill と Wiki の統計)

04落ちた案は、本当に次の案の設計図になるのか

0 回目で却下された 128 行が、1 回目の採用を導いた

Wiki が効く仕組みは、論文の実例を追うのが一番早い。題材は家事のタスクで、動かしたのは Qwen-3.6-27B だ。Qwen は誰でも手元で動かせる公開モデルで、27B はその大きさを表す。

点数はこの節だけ論文の表記に合わせて 0〜1 で書く (0.72 = 72%)。

0 回目、整理役は「物を取る → 調べる → 元に戻す」を繰り返す症状を 1 枚に起こした (症状メモ名は take-examine-move-loop)。同じ回に提案役が出した skill は、目的から行動を決めよという 128 行の抽象的な手順書だった。検証の点は 0.72 に留まり、却下される。

1 回目、提案役はまず台帳を読み、落ちた 128 行そのものを見た。そこから「抽象的すぎた」と診断し、具体的な行動の規則に書き換える。「物を元の場所に戻すな」という 1 行と、失敗した操作列・成功した操作列を並べた skill が、0.78 で採用された。

skill-impact.md (採否の台帳)
      Iteration 0: create goal-directed-action   -> REJECTED
        @@ -0,0 +1,128 @@   (提案の差分がそのまま残る)
      Iteration 1: create break-repetition-loop  -> ACCEPTED
      Iteration 4: update break-repetition-loop  -> ACCEPTED
    
    logs.md (日誌)
      Iteration 0: Reject skill 'goal-directed-action' (val score = 0.72)
      Iteration 1: Accept skill 'break-repetition-loop' (val score = 0.78)
    
    SKILL.md (break-repetition-loop)
      Trigger: 同じ行動を繰り返しかけている時に読む
      Rule: Never Return an Item to Its Origin Location
        失敗: take clock from desk -> examine -> move clock to desk
        成功: take clock -> go to shelf -> move clock to shelf

改善は 1 回目で終わらない。4 回目には同じ症状の別型が新しい作業ログに現れ、整理役が証拠の行を足した。提案役はその証拠を根拠に、同じ skill へ「1 つの物に同じ操作は 1 回だけ」という規則を追記している。図が示すのは 0・1・4 回目の 3 時点だ。

出典: arXiv:2608.27454 §5.2・§5.3 事例・図 3 (p.12 — 0.72 / 0.78 / +128 行 / PURPOSE.md の原文)・表 5

05Wiki が効いていると、なぜ言えるのか

部品を外して測ると、Wiki を消した時の落ち込みが一番大きい

効き目を確かめるために、部品を 1 つ外して測る比べ方をしている。論文はこれを ablation と呼ぶ。外したのは Wiki を見る権利で、実行役と提案役のそれぞれに見せる・見せないを組み、4 通りを比べた。

使ったのは Gemini-3.5-Flash (Google の商用モデル) 1 つ。タスクは 4 つで、家事は入っていない。論文は除いた理由を明記していないが、このモデルは家事の検証用タスクを最初から満点で解く (§4.2)。検証用タスクが満点になった時点で育てる工程は打ち切る規則 (§3.2.4) なので、skill を育てる余地が無いからだと読める。

1 つ注意が要る。提案役に Wiki を見せない条件では、整理役ごと外れる。Wiki に書き足す役がいないので、回をまたぐ積み上げそのものが消える。Wiki には採否の台帳も入っているので、落ちた案の記録も提案役には届かない。

提案役に Wiki を見せると、平均は 48.7 → 63.7 に上がる。差は 15.0 点。実行役に Wiki を渡した時の差 (提案役にも見せる場合は 63.7 → 60.9 で -2.8 点、見せない場合は 48.7 → 45.3 で -3.4 点) より 4〜5 倍大きく、著者はこれを中心主張の根拠に置いている。数学は 51.3 → 72.6、表計算は 49.9 → 76.6 と動いた。

逆に実行役にも Wiki を見せると、平均は 63.7 → 60.9 に下がる。数学の落ち込みが一番大きく 72.6 → 64.8 だ。表計算だけは 76.6 → 80.2 と逆に上がるが、論文はこの点に触れていない。

理由について論文は推測を述べるにとどめる。解く側が skill でなく Wiki から答えを拾うと、残る作業ログが skill の弱点を映さなくなる、という筋だ。

出典: arXiv:2608.27454 §5.1・表 3 (Gemini-3.5-Flash の家事が検証用タスクで満点になる旨は §4.2)

06本当に成績は上がるのか

5 つのタスク・5 つのモデルで、平均はすべて 1 位 (最小モデルは同点)

結果から言うと、5 つのモデルすべてで平均 1 位だった。ただし一番小さい Qwen-3.5-4B は先行手法と統計的に同点で、単独 1 位ではない (08 で詳述)。比べたのは skill 無しの状態と、先行 3 手法 (EvoSkill・Trace2Skill・SkillOpt) が育てた skill だ。先行手法も作業ログを読んで skill を書き直す点は同じで、違いは学んだことの残し方にある。

• EvoSkill — 失敗した作業ログだけを提案役に渡し、過去の提案と採否を平らな履歴として持つ
• Trace2Skill — 作業ログを 1 本ずつ別々に分析し、段階的にまとめて skill にする
• SkillOpt — 却下された編集への指摘と、回ごとの方針メモを持つ

つまり採否の履歴を残すだけなら先行手法もやっていて、それでも負けた。この論文だけが持つのは、学んだことを症状メモと目次に整理し、整理役が育て続ける別の Wiki だ。

モデルは 5 つ。Qwen と Gemma は誰でも手元で動かせる公開モデルで、4B から 31B はその大きさを表す。Gemini-3.5-Flash は中身が公開されていない Google の商用モデルだ。点数は 5 つのタスクの平均で、単位は %。

1 つのタスクに絞ると差はもっと大きい。Gemini-3.5-Flash の数学は 33.0 → 72.6、表計算は 50.5 → 76.6 になった。Qwen-3.6-27B の家事は 52.8 → 77.6 だ。

先行手法は当たり外れが大きい。EvoSkill は Gemma-4-31B の数学を 33.9 → 29.8 に下げた。SkillOpt は Gemini-3.5-Flash の調べものを 29.4 → 28.2 に下げている。

順位が入れ替わる場面もある。skill 付きの Qwen-3.5-9B は平均 47.4 点で、skill 無しの Qwen-3.6-27B の 39.4 点を上回る。手元の skill を育てれば、1 段上のモデルの素の状態を越えることがある。

効くタスクと効きにくいタスクがある。Qwen-3.6-27B の伸びは、表計算 +40.9・数学 +28.0・家事 +24.8 に対し、調べもの +14.1・長文書 +11.6 と差が開く。数学は 5 モデル全部で +20.6〜+39.6 点と安定して効く一方、長文書は小さいモデルが多段の検索手順を実行しきれず素の読み方に戻り、わずかに下がる。手順が閉じている作業ほど効く、と読める。

出典: arXiv:2608.27454 表 1・§4.1 (モデル)・§4.2.1 (規模別・タスク別の伸び)・§1 と付録 D.1 (先行 3 手法の残し方)

07他のモデルが育てた skill を借りてよいのか

借りて自作を超える場面がある。逆に壊す場面もある

借りてよい場面は確かにある。育った skill はただのテキストの手順書だから、別のモデルへそのまま渡せる。論文は他のモデルが育てた skill を渡す実験をし、自作を上回る場面を見つけた。

表 2 の全マスをこの解説で数え直すと、作った側と使う側が別モデルのマスは 56 通りある (使う側 5 モデル × 別モデルの作った側 2〜3 通り × タスク 5 つ = 60 マスから、Gemini-3.5-Flash が家事の skill を持たない 4 マスを除いた数)。56 通りのうち 49 通りで skill 無しを上回った。自作 skill が無い 2 通り (Gemini-3.5-Flash が家事を解くマス) を除いた 54 通りで見ると、23 通りで自作を上回る。この集計は論文に載っていない。

小さいモデルが作った skill が、大きいモデルを助ける場面もある。Qwen-3.5-4B の skill は Gemma-4-31B の数学を 33.9 → 73.1 に上げた。強い側が良い skill を作るとは限らない。

分かれ目の 1 つは skill の中身だ。どのモデルでも通る手順として書かれていれば運べる。そのモデル専用の逃げ道として書かれていれば壊すことがある。

タスクで見ると、数学の skill はよく運べる (Qwen-3.5-4B 製・Qwen-3.6-27B 製とも Gemini-3.5-Flash を 33.0 → 67.5 / 73.9 に上げる)。表計算は組み合わせで大きく変わり、同じ Gemini-3.5-Flash が Qwen-3.5-4B 製では 18.1、Qwen-3.6-27B 製では 63.4 になる。

もう 1 つは使う側の力だ。良い直し方を見つける力と、実際に使いこなす力は別物だと論文は分けて考える。Qwen-3.5-4B が作った長文書の skill は、自分では 30.2 → 28.5 と下がるが、Qwen-3.6-27B では 42.1 → 52.9 に上がる。書いた側と使う側は別でよい。

出典: arXiv:2608.27454 §4.2.2・表 2。56 / 49 / 23 は表 2 の全マスを本解説で数え直した独自集計 (同点は上回りに数えない。Gemini-3.5-Flash の家事は自作 skill が無いため自作比較から除く)

08この結果はどこまで信じてよいのか

平均の勝ち・小さい検証・1 モデルの比較。土台は思ったより細い

数字は強いが、土台は細い。信じてよい範囲を先に絞っておくと、手元への持ち帰り方を間違えにくい。

• 「一貫して勝つ」は 5 つのタスクの平均での話。1 つのタスクだけ見ると統計的な引き分けが多い
• 一番小さい Qwen-3.5-4B の平均 38.5 点は、先行手法 SkillOpt の 35.2 点と統計的に同点扱い。単独 1 位ではない
• 論文 1 ページ目の折れ線図 (図 1) は 5 モデルのうち 4 つしか描いていない。省かれた Gemma-4-31B (54.9) を入れると、Qwen-3.6-27B (63.3) の後で一度下がり、右肩上がりが崩れる
• 採用を決める検証用のタスクは 10〜40 件しかない。1 件の正誤で数点動く
• 報告値は育てる工程をまるごと 3 セットまわした平均。セットごとのばらつきは公開されていない
• Wiki を外す比較は Gemini-3.5-Flash 1 モデル・4 つのタスクだけ。しかも整理役も一緒に消える
• 整理役と提案役をどのモデルが動かしたかは、本文に明記がない。skill を作った側のモデルと読むのが自然だが、逐語の記載はない
• どの skill が呼ばれるかは測っていない。その時点で持っている skill の全文を、毎回まとめてプロンプトへ入れる前提だ
• Wiki を刈り込む仕組みが無い。何回まわしたかは本文に無いが、表 5 の区分が 5〜7 回目で止まっているので、観察は 0〜7 回目の 8 回ぶんと読める

Wiki と skill がどのくらいの大きさになるかは、表 4 に出ている。育てる工程 1 セット (8 回ぶん) で Wiki の症状メモは 6〜9 枚、skill 本体は 45〜130 行だ。提案は 1 回につき 1 件で計 8 件、通るのは 2〜3 件。つまり提案の 6〜7 割は落ちる。

費用の読み方にも注意が要る。論文は「skill を育てる工程でモデルを呼ぶ回数は、タスクが何件でも一定」と書く。ただしこれは、練習用のタスクをまとめて 1 回の整理役に渡す数え方だから成り立つ。1 イテレーションあたりの回数を先行手法と並べると次のとおりだ。

同じ「全件まとめて」の数え方なら EvoSkill は 2 回で済み、この論文のほうが多い。ただし論文は、先行 2 手法 (EvoSkill・SkillOpt) は小分けにしないと成績が出ないため、実際には回数がタスクの件数に比例する、と反論している (付録 D.2)。「データセットによっては推論の費用が増える」と論文自身も認めたうえで、成績の伸びが見合うと主張する。それでも、この数え方には実行役がタスクを解く分が入っていない。

解く分は大きい。表計算なら 1 イテレーションで練習 80 件 + 検証 40 件 = 120 件を解く。8 回ぶんを 3 セットまわすと約 2,900 件になる (表 6 と付録 A から本解説が計算・本番 280 件は別)。提案の 6〜7 割は落ちるので、検証の実行の大半は戻しに終わる。文字数に応じてかかる分 (トークン量) も数えられていない。

限界は論文自身も 4 つ挙げている。

• skill の呼び出し方を測っていない。skill が増えた時にどれを開くかは別問題のまま
• 過去最高を上回った時だけ採用する、という採点の関門は厳格で、今は横ばいでも後で効く直しを捨てる。より柔軟な基準は今後の課題だと論文は書く
• Wiki を自動で刈り込む仕組みが無い。長く回すほど症状メモも台帳も溜まり続ける
• 数百手・数時間級の長い作業は試していない

出典: arXiv:2608.27454 表 1 の太字 (p.8 — Qwen-3.5-4B の平均は 35.2 と 38.5 が両方太字)・図 1 (p.1 — 横軸は 4 モデル)・§4.2 (3 セット平均)・§3.2.1 (skill 全文の注入)・表 4 (skill と Wiki の統計)・表 5 (何回目に採用されたかの区分)・表 6・表 7 と付録 D.2 (呼び出し回数)・付録 A (1 イテレーションの手順)・Limitations

09Claude Code の運用にどう活かすか

論文が決めている規律と、ここから先の当てはめを分けて置く

持ち込めるのは仕組みではなく、順番と規律だ。実験の規模は人の手には重い。正解つきのタスクを数十件そろえ、毎回まるごと解き直す前提だからである。一方、置き場の分け方と書き方の決まりは今日から真似できる。

まず、論文が実際に決めている規律だけを並べる。右の列は、その根拠がある論文の節だ。

以下は当てはめの推測だ。論文は Claude Code にも CLAUDE.md にも触れていない。性質が似ている置き場へ寄せた、という以上の根拠は無い。

• CLAUDE.md と .claude/skills/ は skill の側。実行中に必ず読ませるからだ (推測)
• Wiki は docs/wiki/ のような別の場所を新しく作り、実行中には読ませない。作業の種類ごとに Wiki を分けるほうが、論文の条件 (タスクごとに Wiki 1 つ) に近い (推測)
• 採点の関門は版管理 (git) に載せる。作業用の枝 (branch) で測り、通ったら本流 (main) へ入れ、落ちたら枝ごと捨てる。ただし Wiki へ足した記録は戻さない (推測)
• 関門の厳しさは手元で緩めてよい。同点の直しを別枠で残す、数回ぶんまとめて測る、など。論文には無い緩め方で、効くかは測っていない (推測)
• まず試すなら、手順が閉じている作業 (表・コード・計算) から。調べものや長い文書の読み込みは効きが鈍い (推測 — 06 のタスク別の伸びから)
• 他人が育てた skill を借りる価値はある。ただし借りたら自分の環境で測り直す (推測)

出典: arXiv:2608.27454 §1 (先行手法が持つ履歴)・§3.1・§3.2.1・§3.2.3・§3.2.4・§4.2.1 (タスク別の伸び)・§5.1・付録 E.2 / E.3・表 4・Limitations