静的なスキルは死んだスキルである

昨晩、Claude Code ガイドに Settings Reference セクションを出荷しました。15 項目。すべての引用は行番号に対して grep で検証済み。批評ループをクリーンに通過した後、確信を持って出荷したのです。.md ファイルをコミットしている頃には、すでに v3 が必要になるとわかっていました。何か間違ったことをしたからではありません。ガイドは変わり、製品の基盤が変わり、ユーザーのクエリも変化します。今まさに出荷したそのセクションも、私がそこから離れた瞬間からドリフトし始めるからです。

スキルというものは、それが Markdown のリファレンスセクションであれ、.claude/skills/ 内のエージェントスキル定義であれ、誰かがその軌跡を見守っている間だけ生きています。見守るのをやめた瞬間、それは静的なものとなります。静的なスキルはその場で劣化していくのです。

Ma、Yang、Ji、Wang、Wang らによる新しい arxiv 論文（「SkillClaw: Let Skills Evolve Collectively with Agentic Evolver」、2026 年 4 月）は、この問題を研究レベルで形式化しています。¹ 冒頭の枠組みを直接引用しましょう。「OpenClaw のような大規模言語モデル（LLM）エージェントは、複雑なタスクを実行するために再利用可能なスキルに依存しているが、これらのスキルはデプロイ後もほぼ静的なままである。その結果、類似のワークフロー、ツール使用パターン、そして失敗モードがユーザー間で繰り返し再発見され、システムが経験から改善されることを妨げている」¹

私はこの失敗モードに何ヶ月も直面してきました。何らかのエージェントハーネス向けにスキルを構築している方なら、同じはずです。

TL;DR

エージェントスキルは出荷された後、改善が止まります。ユーザーたちは同じ失敗モードを独立して発見しますが、それらの発見がスキル自体にフィードバックされることはありません。Ma らはこれを集合知の問題として枠付けしています。クロスユーザーかつ時間を超えたインタラクションは、スキルがいつ機能しいつ失敗するかのシグナルですが、それをスキル更新に集約するエコシステムレベルのメカニズムが存在しないのです。彼らの SkillClaw フレームワークは、集約された軌跡を進化シグナルとして扱い、繰り返される行動パターンを特定してそれをリファインメントや機能拡張に翻訳する自律的な evolver を実行することを提案しています。¹ アブストラクトは「OpenClaw」を再利用可能なスキルを使う LLM エージェントの例として挙げていますが、アブストラクトだけから OpenClaw が特定の出荷済み製品であるとは識別できず、この投稿ではそれについて推測するつもりはありません。私が主張するのは、論文が記述している構造的問題は、Claude Code、Codex、Cursor、または独自のハーネス向けにスキルを構築しているすべての人に当てはまるということです。結論：スキルライブラリが実利用からの軌跡を継続的に取り込んでいないなら、それは出荷した日から死んでいます。

重要なポイント

• スキル作成者へ： スキルを出荷したら仕事が終わるわけではありません。スキルがどう使われているかを監視し、繰り返される失敗モードを捕捉し、それをスキル定義にフィードバックするループを構築して初めて、仕事は終わります。出荷はスキルの寿命の始まりであって、終わりではないのです。
• ハーネス構築者へ： すべてのスキル呼び出しを、その軌跡とともにログに記録してください。入力、ツール呼び出し、出力、エラー状態まで。そのログが進化シグナルです。ログを取っていないなら、スキルを改善しているのではなく、単に維持しているだけです。
• Jiro 志向の実践者へ： SkillClaw 論文は、スキルに適用された Shokunin パターンの学術的な言葉です。スキルは技であり、軌跡は稽古、進化は熟達の追求にあたります。静的＝死んでいる、ということです。

論文が実際に何を述べているか

アブストラクトの主張を丁寧に辿り、私が枠組みを拡張している箇所を明確にマークしていきます。

問題提起（アブストラクトより）。 LLM エージェントは複雑なタスクを実行するために再利用可能なスキルに依存している。これらのスキルはデプロイ後もほぼ静的なままである。類似のワークフロー、ツール使用パターン、失敗モードがユーザー間で繰り返し再発見される。システムは経験から改善されない。¹

これは特定の失敗モードについての主張であって、すべてのスキルが劣化するという主張ではありません。呼び出されないスキルは劣化しません。問題を報告しない 1 人のユーザーだけが呼び出すスキルも、目に見える形では劣化しません。劣化が表面化するのは、複数のユーザーがそれぞれ同じ失敗の自分なりのバージョンに遭遇し、システムがそれらの遭遇を 1 つの更新に集約する手段を持たない場合です。（この最後の一文は私の枠組みであり、論文のものではありません。）

既存のギャップ（アブストラクトより）。 アブストラクトは、クロスユーザーインタラクションは「スキルがいつ機能しいつ失敗するかについての補完的なシグナルを提供するが、既存のシステムはそのような異質な経験を信頼できるスキル更新に変換するメカニズムを欠いている」と述べています。¹ これが論文の中核的主張です。誰もスキル改善について考えていないというわけではなく、軌跡を集約し、繰り返しパターンを特定し、更新に翻訳するエコシステムレベルのメカニズムが存在しないということです。

SkillClaw パイプライン（アブストラクトより）。 アブストラクトは継続的なパイプラインを記述しています。SkillClaw は「使用中に生成された軌跡を集約し、それらを自律的な evolver で処理する。evolver は繰り返される行動パターンを特定し、既存のスキルをリファインしたり新しい機能で拡張したりすることで、それらをスキルセットへの更新に翻訳する」とされています。¹ 更新されたスキルは共有リポジトリで維持され、ユーザー間で同期されるため、ある文脈で発見された改善はユーザーの労力を必要とせずにシステム全体に伝播します。¹

評価（アブストラクトより）。 論文は WildClawBench というベンチマーク上で、基盤モデルとして Qwen3-Max を用いて SkillClaw を評価しています。アブストラクト自体の表現は公開バージョンで文法的に崩れています：「experiments on WildClawBench show that limited interaction and feedback, it significantly improves the performance of Qwen3-Max in real-world agent scenarios.」¹ 私はこれを次のように読み取ります。限定的なインタラクションとフィードバックのもとでも、SkillClaw はベースラインに対して大きなパフォーマンス改善を生み出す、と。アブストラクトは具体的な数値を公開していません。おそらく論文本文にはあるのでしょう。

それがアブストラクトが記述している論文の内容です。著者らは、共有スキルを持つマルチユーザーのエージェントエコシステムは、自動化された軌跡集約が自動化されたスキル更新に供給されることから恩恵を受けると提案し、彼らの実装が限定フィードバック条件下で Qwen3-Max のパフォーマンスを大きく改善することを報告しています。

論文が述べていないこと（および私が付け加えていること）

アブストラクトは「OpenClaw」を再利用可能なスキルを使うエージェントの例（「OpenClaw のような LLM エージェント」）として挙げています。私はアブストラクトだけから OpenClaw が何であるかわかりません。特定の出荷済み製品として手早く識別することができませんでした。論文のフレームワーク（SkillClaw）は、OpenClaw 専用ではなく、マルチユーザーのエージェントエコシステム全般に対する解決策として提示されているため、「OpenClaw とは何か」という問いは議論にとってほぼ接線的なものです。これを指摘しているのは、誰もこの投稿を読んで「論文は Claude Code についてのものだ」と誤解しないようにするためです。そうではありません。OpenClaw を例として名指しし、SkillClaw を一般的なメカニズムとして提案しているだけです。

私が論文とは別に主張しているのは、論文が記述している構造的問題は、私が Claude Code スキルエコシステムで実際に直面してきた問題に対応するということです。その主張は私のものであり、論文のものではありません。以下がその理由です。

Claude Code エコシステムのスキルは静的な成果物として出荷されます。 スキルとは、タスクをどう実行すべきかを記述する SKILL.md ファイル（または付随ファイルのバンドル）です。一度書き、コミットし、スラッシュコマンドまたは @skill-name のタイプアヘッドで参照します。一度出荷されれば、それは静的な成果物です。スキルが実際にどう使われているかを監視し、何が機能して何が失敗したかに基づいてスキル定義を更新する自動メカニズムは存在しません。

異なるユーザーが同じ失敗モードに独立して遭遇します。 私が出荷してきたすべてのスキルには、特定の条件下でのみ現れる少なくとも 1 つの繰り返し失敗モードがあります。誰かが私の想定していない入力でスキルを呼び出し、エッジケースに当たり、手動で回避し、先に進みます。どこか別の場所にいる別の誰かが同じエッジケースに当たり、自分なりの回避策を取ります。スキルそのものは変わりません。

集約シグナルは実在するが活用されていません。 私が出荷したすべてのスキルのすべての呼び出しからの軌跡を見られれば、繰り返される失敗モードを午後のうちに特定できます。そのシグナルは存在します。個々のユーザーのセッション履歴の中にあるのです。ただどこにも集約されていないため、誰も行動を起こさないだけです。

修正手段は手動であるか、欠けています。 現時点では、スキル改善のための唯一のメカニズムは、私が自分の利用で問題に気づくか、誰かが issue を立てるか、誰かが PR を開くかです。どれもユーザーの労力を必要とする経路です。SkillClaw 論文の核心的洞察、すなわち軌跡データはすでに存在しており自動的にスキル更新に変換されるべきであるという主張こそが、まさに私たちに欠けているメカニズムなのです。

これが、論文の枠組みがどう Claude Code に適用されるかについての私の主張です。論文が述べていることではありません。論文を自分の仕事に照らして読んでいる私の解釈です。

Shokunin パターンをスキルに適用する

技について考えるとき、いつも立ち返る枠組みがあります。寿司職人の小野二郎がその典型例です。60 年間、同じ仕事。毎日、カウンターで何が起こるかを見守り、技術を調整し、シャリの温度、包丁の角度、酢飯のタイミングを研ぎ澄ましていく。仕事そのものがトレーニングシグナルであり、実践者が集約器なのです。

少し前に Shokunin / quality-loop の枠組みについて書きました。中心的な考えはこうです。技とはフィードバックループである。仕事をし、仕事を見守り、何が壊れたかに気づき、調整し、再び仕事をする。繰り返し、繰り返し。熟達は、意図したものと実際に起こったものとの差分の中に、そしてその差分を次の試みに持ち込む意志の中に宿るのです。

静的なスキルはそのループを壊します。スキルを出荷し、見守るのをやめる。スキルが意図したものと実際に起こったことの差分は、あなたが決して見ることのない何百ものセッションに蓄積されていきます。職人がカウンターにいないため、スキルは改善されないのです。

SkillClaw 論文は自動化された集約器を提案しています。人間の代替ではなく、すべての軌跡を見守り、セッションを越えて何が壊れたかに気づき、スキル定義への更新を提案するメカニズムです。これは狂った野心ではありません。スキルが自らのデプロイを生き延びさせたいなら、これが実は最低限の基準なのです。

実際にはどう見えるか

今日維持している Claude Code スキルに対して SkillClaw パターンを構築したいなら、必要となるのは次の要素です。

1. すべてのスキル呼び出しの軌跡ログ。 スキルが実行されるたびに、入力、行ったツール呼び出し、出力、エラー状態、そして最終処置（ユーザーは結果を受け入れたか？ 取り消したか？ 書き直したか？）を記録します。これは Claude Code のセッションレベルではすでに存在しています。問題は、それがセッションを越えて集約され、スキル所有者のために抽出されているかどうかです。

2. パターン検出器。 軌跡ログを読み、繰り返されるパターンを特定するもの。同じ入力クラスが同じ失敗につながる、同じツール呼び出しが同じように失敗する、同じエッジケースが異なるユーザー文脈で現れる、など。これは AGI ではなく、構造化された軌跡データ上のクラスタリングです。

3. 提案生成器。 検出されたパターンを踏まえ、スキルへの候補更新をドラフトします。新しい処理分岐、追加の例、SKILL.md 本文への追加制約など。更新は提案であり、出荷される変更ではありません。

4. ゲート。 提案された更新はすべて、人間のレビュー、事実検証（私が他のすべてに適用しているのと同じ厳格なゲート）、そして出荷前の批評ループを通ります。自動化は集約を担うのであり、出荷を担うのではありません。

5. 配布。 提案された更新が受け入れられたとき、それはそのスキルのすべてのユーザーに伝播します。中央集権的なエコシステムではこれは自明です（正規スキルを更新すれば、全員がプルする）。分散型エコシステムではより難しくなります。

その大部分はすでに Claude Code に存在しています。セッションログは存在し、スキル定義はバージョン管理され、批評ループは運用中です。欠けているのは、セッション軌跡をスキル更新に接続する集約とパターン検出のレイヤーです。

不都合な含意

過去半年間に私が出荷したすべてのスキルは、SkillClaw 論文が記述している通りの意味で死んでいます。スキルを書く。自分で使う。問題に気づく。自分が使うスキルでそれを修正する。スキルは私にとっては改善されます。他の誰かがその人自身で同じ問題に気づき、何かを提出しない限り、他の誰にとっても改善されることはありません。

昨晩 Settings Reference で行った仕事はまさにこのパターンです。Claude Code ガイドは共有された成果物です。ユーザーは特定の設定キーについてそれを検索します。どの設定キーが検索されているかを示す GSC データも見られます。それは集約された軌跡データであり、ガイドのどのスキルが呼び出され、結果がどこに着地しているかを文字通り教えてくれるのです。そして私がそのデータを見に行くまで、ガイドは静的でした。何週間も静的なままでした。誰も軌跡を見守っていなかったからではなく、それを見守れるのは私だけであり、私には他にすべきことがあったからです。

SkillClaw 論文はその問題の学術的な形式化です。実務上のメカニズムはもっと単純です。軌跡データからスキル更新への自動パイプラインがないなら、スキルはその場で老朽化しています。ある条件下では、一部のユーザーにとってまだ機能するかもしれません。しかし改善されることはありません。

唯一の問いは、スキルが出荷された瞬間に死んでいることを受け入れるのか、それとも生きたままにしておく watcher を構築するのか、ということです。

ミニマルバイアブルな集約器

この投稿を書き始める前、私は自分のスキルに対する軌跡集約を一切持っていませんでした。ゼロ。手動で読めるセッション履歴はありましたが、セッションを越えてパターンを浮上させるものは何もありませんでした。それはまさに論文が記述する静的スキルの病理であり、私はそれを走らせていたのです。

今日、今すぐに、それに対して私が出荷できる最小の現実的なものは次のとおりです。すべてのスキル呼び出しを、タイムスタンプ＋スキル名＋入力の形状＋最終処置（受諾／修正／取り消し）とともに、自分のセッション全体で追記専用で記録する 1 つのテキストファイル。 パターン検出器はなし。自律的な evolver もなし。ただのログだけ。

そのファイルがミニマルバイアブルな集約器です。これは SkillClaw ではありません。SkillClaw が存在するなら必要とするであろう入力レイヤーであり、私がスキルに繰り返される失敗モードがあるかどうかを見ることさえできるようになる前に必要な入力レイヤーです。それがなければ、私は推測しているだけです。それがあれば、少なくともスキルをレビューするときにログを手作業でスキャンし、「これは今月同じように 3 回壊れたか？」と問いかけることができます。

それが私のコミットメントです。1 つのファイル。追記専用。呼び出しごとに記録。スキルをレビューするときに確認する。

これが機能すれば、次のレイヤーはパターン検出器です。パターン検出器が機能すれば、次のレイヤーは提案生成器です。論文の野心はマルチユーザーエコシステム全体で動く完全に自律的な evolver です。私の野心は、暗闇の中を走らないことです。

FAQ

論文の「OpenClaw」は Claude Code と同じものですか？

いいえ、そして OpenClaw が何であるかも私にはお伝えできません。アブストラクトは「OpenClaw のような LLM エージェント」を再利用可能なスキルを使うエージェントの一例として、定義することなく言及しています。アブストラクトだけから特定の出荷済み製品として手早く識別することはできませんでした。重要なのは、論文の SkillClaw フレームワークはマルチユーザーのエージェントエコシステムに対する一般的な解決策として提示されており、OpenClaw や Claude Code 専用の解決策ではないということです。OpenClaw が何であれ、この論文は Claude Code の論文ではありませんし、この投稿における Claude Code についての私の主張は私自身のものであって、論文のものではありません。¹

論文の実際の新規性はどこにありますか？

アブストラクトによれば、マルチユーザーのエージェントエコシステムにおける集合的スキル進化のフレームワークであり、（1）ユーザーと時間を越えて軌跡を集約し、（2）繰り返しパターンを検出する自律的な evolver を実行し、（3）パターンを共有リポジトリ内のスキル更新に翻訳してユーザー間で同期させる、というものです。¹ 新規性は「スキルを改善できる」ことではありません。それは自明です。新規性は、改善ループが人間駆動ではなく自律的かつ軌跡駆動であるべきだと提案している点です。

論文は具体的な改善数値を報告していますか？

アブストラクトは、WildClawBench というベンチマーク上で Qwen3-Max を用い、限定フィードバック条件下での改善を「significant（有意）」と記述していますが、具体的な数値は公開していません。¹ 数値については論文本文が情報源となります。

これはスキル定義に対する git のプルリクエストとどう違うのですか？

PR は人間が起点となるメカニズムです。誰かが問題に気づき、修正を書き、PR を提出し、レビューし、マージする必要があります。すべてのステップが人間の労力を必要とします。論文が提案する SkillClaw フレームワークは自律的な集約であり、システムが多くのユーザーを通じてパターンに気づき、修正自体を提案し、特定のユーザーが何かを提出することなく更新を同期させるのです。¹ その自律バージョンが特定のエコシステムにとって望ましいか安全かは別の問題です。論文の貢献は、それが技術的に整合していることを示した点にあります。

これは私の Claude Code カスタムスキルにも当てはまりますか？

論文は特定の Claude Code スキルエコシステムについて主張していません。私の主張は論文とは別のもので、構造的問題（スキルが静的成果物として出荷され、失敗モードが各ユーザーによって独立に再発見され、集約メカニズムが存在しない）は Claude Code スキルにも当てはまる、というものです。また、Claude Code または類似のハーネス向けにスキルを構築している人なら誰でも、軌跡駆動の改善ループをどう構築するかを考えるべきだと思います。これは私の意見であって、論文の結論ではありません。

Shokunin との接点はどこにありますか？

Shokunin / quality-loop の枠組みは、熟達とは意図したものと実際に起こったものとの差分を次の試みへ持ち込むことから生まれると説きます。静的スキルはそのループを壊します。なぜなら差分は職人が決して見ないセッションに蓄積されていくからです。SkillClaw はそのループを閉じる学術的バージョンであり、差分の収集を自動化し、それをスキルへフィードバックするのです。規律は同じ、メカニズムが異なるだけです。

参考文献