静的スキルは死んだスキル

昨晩、Claude CodeガイドにSettings Referenceセクションをリリースしました。15のエントリ。各引用は行番号に対してgrepで検証済み。critique loopがクリーンに通った確信のもとリリースしたのです。.mdファイルをコミットしていた時点で、すでにv3が必要になると分かっていました。何か間違ったことをしたからではなく、ガイドが変わり、その裏の製品が変わり、ユーザーのクエリが変化し、リリースしたばかりのセクションは、私が手を離した瞬間から漂流し始めるからです。

スキル（Markdownのリファレンスセクションであれ、.claude/skills/にあるエージェントスキル定義であれ）は、誰かがそのトラジェクトリを見守っている間だけ生きています。見るのをやめた瞬間、静的なものになります。静的なスキルは、その場で劣化していくのです。以下の記事は、エージェントインフラが本番環境でどう進化するかを記録したAIエンジニアリングシリーズの一部です。

静的なAIエージェントスキルが失敗するのは、リリースした瞬間から学習を止めてしまうからです。 実際の呼び出しトラジェクトリ（実運用での入力、ツール呼び出し、出力、エラー状態）を取り込むフィードバックループがなければ、スキルは変化する製品、移ろうユーザークエリ、繰り返される失敗モードに適応できません。複数のユーザーが独立して同じ回避策を再発見する一方で、スキル定義は凍結されたままとなります。解決策は、使用パターンを自動化されたスキル更新へ変換する継続的なトラジェクトリ集約です。

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

私はこの失敗モードを数か月にわたって生きてきました。何らかのエージェントフレームワーク向けにスキルを構築しているなら、あなたも同じはずです。

TL;DR

エージェントスキルはリリースされた後、改善を止めます。ユーザーは同じ失敗モードを独立に発見し、それらの発見をスキル自体にフィードバックすることはありません。Maらはこれを集合知の問題として枠組みづけます。クロスユーザー、時系列を越えたインタラクションは、スキルがいつ機能しいつ失敗するかに関するシグナルですが、それらを集約してスキル更新につなげるエコシステムレベルのメカニズムは存在しないのです。彼らのSkillClawフレームワークは、集約されたトラジェクトリを進化シグナルとして扱い、繰り返される行動パターンを特定して改良や能力拡張に変換する自律的なエボルバーを走らせることを提案しています。¹ アブストラクトは再利用可能なスキルを使うLLMエージェントの例として「OpenClaw」を挙げています。アブストラクトだけではOpenClawを具体的な出荷製品として特定できず、この記事でその点を憶測するつもりはありません。私が主張するのは、論文が記述する構造的問題が、Claude Code、Codex、Cursor、あるいは独自のエージェントフレームワーク向けにスキルを構築している誰にでも当てはまるということです。要点は、スキルライブラリが実運用のトラジェクトリを継続的に取り込んでいないなら、それはリリースされた日から死んでいるということです。

Key Takeaways

• スキル作者へ： スキルをリリースした時点で仕事は終わりません。仕事が終わるのは、スキルがどう使われているかを見守り、繰り返される失敗モードを捕捉し、それをスキル定義にフィードバックするループを構築したときです。リリースはスキルの生涯の終わりではなく、始まりなのです。
• フレームワーク構築者へ： 各スキル呼び出しを、そのトラジェクトリ（入力、ツール呼び出し、出力、エラー状態）と共にログしてください。そのログが進化シグナルとなります。ログを取っていないなら、スキルを改善しているのではなく、ただ維持しているだけとなります。
• Jiroの心を持つ実践者へ： SkillClaw論文は、スキルに適用されたShokuninパターンの学術的表現です。スキルは craft（技）であり、トラジェクトリは practice（稽古）、進化は熟達の追求です。静的＝死、なのです。

論文が実際に述べていること

アブストラクトの主張を丁寧に追いながら、フレーミングを私自身が拡張している箇所は明確に区別していきます。

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

著者らは特定の失敗モードを標的にしており、すべてのスキルが劣化するという普遍的な主張をしているわけではありません。呼び出されないスキルは劣化しません。1人のユーザーが問題を報告せずに呼び出すだけなら、劣化は可視化されません。劣化が現れるのは、複数のユーザーがそれぞれ同じ失敗のバリエーションに遭遇し、システムがそれらの遭遇を単一の更新に集約する手段を持たないときです。（最後の一文は私のフレーミングであり、論文のものではありません。）

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

SkillClawのパイプライン（アブストラクトより）。 アブストラクトは継続的パイプラインを記述します。SkillClawは「使用中に生成されたトラジェクトリを集約し、自律エボルバーで処理する。エボルバーは繰り返される行動パターンを特定し、既存スキルの改良、または新機能による拡張としてスキルセットの更新に変換する。」¹ システムは更新済みスキルを共有リポジトリで管理し、ユーザー間で同期させるため、ある文脈で発見された改善がユーザーの手間を要せずシステム全体に伝播します。¹

評価（アブストラクトより）。 論文は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」（「LLM agents such as OpenClaw」）を挙げています。アブストラクトだけからはOpenClawが何かは分かりませんし、具体的な出荷製品としてすぐに特定することもできませんでした。論文のフレームワーク（SkillClaw）はOpenClaw固有ではなく一般的なマルチユーザーエージェントエコシステムを対象としているため、「OpenClawとは何か」という問いは議論にほぼ接線的です。この点をフラグしておくのは、この記事を読んで論文がClaude Codeについてのものだと思い込む人が出ないようにするためです。そうではないのです。論文はOpenClawを例として挙げ、SkillClawを一般的なメカニズムとして提案しています。

論文とは別に私が主張するのは、論文が記述する構造的問題が、Claude Codeスキルエコシステムで私が生きてきた現実の問題にマッピングされるということです。その主張は私のものであり、論文のものではありません。マッピングされると考える理由は以下の通りです。

Claude Codeエコシステムのスキルは静的なアーティファクトとしてリリースされます。 スキルとは、タスクをどう実行すべきかを記述した SKILL.md ファイル（または補助ファイルのバンドル）です。一度書いてコミットします。スラッシュコマンドや@skill-name typeaheadで参照します。カスタムスキル構築の仕組みは単純明快です。リリースされてしまえば、それは静的なアーティファクトとなります。スキルが実運用でどう使われるかを監視し、何が機能し何が失敗するかに基づいてスキル定義を更新する自動メカニズムは存在しません。

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

集約シグナルは存在するが使われていません。 もし私がリリースした全スキルの全呼び出しの全トラジェクトリを見ることができたなら、繰り返しの失敗モードを午後いっぱいで特定できるでしょう。そのシグナルは各ユーザーのセッション履歴に存在します。ただどこにも集約されていないため、誰も行動を起こしません。

解決策は手動であるか、存在しないかです。 現時点でスキル改善の唯一のメカニズムは、私自身の使用で問題に気づくこと、誰かがissueを立てること、誰かがPRを開くことです。これらすべての経路がユーザーの労力を必要とします。トラジェクトリデータはすでに存在し、自動的にスキル更新に供給されるべきだというSkillClaw論文のコアな洞察は、まさに私たちに欠けているメカニズムなのです。

以上が、論文のフレーミングがClaude Codeにどう適用されるかに関する私の主張です。これは論文が述べていることではありません。自分の仕事に照らして論文をどう読んでいるか、です。

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

craft（技）について考えるとき、繰り返し浮かび上がる1つのフレーミングがあります。寿司職人の小野二郎が正統な例です。60年間、同じ仕事。毎日カウンターで起きることを見守り、技を調整し、シャリの温度、包丁の角度、握るタイミングを磨いていきます。仕事そのものが訓練シグナル。実践者が集約者なのです。

Shokunin／quality-loopのフレーミングについて以前書きました。中核のアイデアはこうです。craft（技）はフィードバックループである、と。仕事をし、仕事を見守り、何が壊れたかに気づき、調整し、また仕事をする。それを何度も繰り返す。熟達は、意図したものと実際に起きたことの差分の中に宿り、その差分を次の試みへと運ぶ意志の中に宿ります。

静的なスキルはそのループを断ち切ります。スキルをリリースし、見守るのをやめる。スキルが意図したものと実際に起きたものの差分が、あなたが決して見ることのない100ものセッションに蓄積していく。職人がカウンターにいないため、スキルは良くなりません。

SkillClaw論文は自動集約者を提案しています。人間の代替ではなく、すべてのトラジェクトリを監視し、セッション横断で何が壊れたかに気づき、スキル定義への更新を提案するメカニズムです。その野心は狂気ではありません。スキルを自身のデプロイに耐えさせたいなら、むしろそれが最低ラインなのです。

これが実運用でどう見えるか

今日私が保守しているClaude Codeスキルに対してSkillClawパターンを構築するとしたら、必要なものは以下の通りです。

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

2. パターン検出器。 トラジェクトリログを読み、繰り返しパターンを特定する何か。同じ入力クラスが同じ失敗につながる、同じツール呼び出しが同じ方法で失敗する、同じエッジケースが異なるユーザー文脈の下で現れる。要件は構造化されたトラジェクトリデータに対するクラスタリングであり、AGIではありません。

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

4. ゲート。 提案された各更新は、人によるレビュー、事実検証（他のすべてに適用する厳格なゲートと同じもの）、critique loopを経てからリリースされます。自動化が行うのは集約であり、リリースではありません。

5. 配布。 提案された更新が受理されると、そのスキルの全ユーザーに伝播します。中央集権的なエコシステムでは簡単です（正典スキルを更新、全員がpull）。分散型エコシステムではより困難です。

その大部分はすでにClaude Codeに存在します。セッションロギング、バージョン管理されたスキル定義、運用上のcritique loopがあります。欠けているのは、セッショントラジェクトリをスキル更新に接続する集約とパターン検出のレイヤーです。コマンド、スキル、サブエージェント、ルールの組織的分類はすでに構造的基盤を提供しています。欠けているのは、各カテゴリをデプロイ後も生かし続けるフィードバックチャンネルなのです。

不都合な含意

過去6か月にリリースした私のスキルは、すべてSkillClaw論文が記述するちょうどその意味で死んでいます。スキルを書き、自分で使い、問題に気づき、自分の使うスキルでそれを修正する。私のスキルは私にとってはよくなる。他の誰かが独立に同じ問題に気づいて何かを提出しない限り、他の誰にとってもよくならないのです。

昨晩Settings Referenceで行った作業は、まさにこのパターンです。Claude Codeガイドは共有アーティファクトです。ユーザーは特定のconfigキーを求めてクエリを投げます。私はGSCデータを見て、どのconfigキーが検索されているかを把握できます。それは集約されたトラジェクトリデータであり、文字通りガイド内のどのスキルが呼び出され、結果がどこに着地しているかを示しています。そして私がそのデータを見に行くまで、ガイドは静的でした。何週間も静的だったのです。トラジェクトリを誰も見ていなかったからではなく、見られるのが私だけで、私には他にすることがあったから、です。

SkillClaw論文はその問題の学術的な定式化です。実務上のメカニズムはもっと単純で、トラジェクトリデータからスキル更新への自動パイプラインがないなら、スキルはその場で老いていきます。一部の条件下で一部のユーザーには依然として機能するかもしれません。よくはなっていないのです。

唯一の問いは、スキルがリリースの瞬間に死ぬことを受け入れるか、それとも生かし続ける監視者を構築するかです。ここにはcompound contextの原則が適用されます。各トラジェクトリ観察は次と複利的に積み重なり、スキルの価値は取り込んだフィードバックに対して非線形に成長します。逆に、context as architectureとして扱うということは、スキルの構造がそもそも新しい情報を吸収する能力を決定するということを認識することです。

実用最小の集約器

この記事を書き始める前、私のスキルにはトラジェクトリ集約はゼロでした。皆無。手動で読めるセッション履歴はあったものの、セッション横断でパターンを浮かび上がらせるものはありませんでした。それはまさに論文が記述する静的スキルの病理であり、私はそれを生きていたのです。

今日、今すぐリリースできる最小の実物は次のものです。自分自身のセッション横断で各スキル呼び出しをログする単一のテキストファイル。追記専用で、タイムスタンプ＋スキル名＋入力形状＋最終処置（accepted／revised／reverted）を記録する。 パターン検出器はなし。自律エボルバーもなし。ただのログ。

そのファイルが実用最小の集約器です。それはSkillClawではありません。SkillClawが存在するなら必要とする入力レイヤーであり、私のスキルに繰り返しの失敗モードがあるかどうかを見るためにも私に必要な入力レイヤーです。それがなければ、私は推測しているに過ぎません。それがあれば、少なくともスキルをレビューするときにログを手で走査して、「同じ破綻が今月3回起きたか？」と尋ねることができます。

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

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

FAQ

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

違います。そしてOpenClawが何かも私には分かりません。アブストラクトは、再利用可能なスキルを使うエージェントの一例として「LLM agents such as OpenClaw」に言及していますが、定義してはいません。アブストラクトだけからは具体的な出荷製品としてすぐに特定できませんでした。重要なのは、論文のSkillClawフレームワークがOpenClawやClaude Code固有ではなく、一般的なマルチユーザーエージェントエコシステムを対象としているという点です。OpenClawが何であれ、論文はClaude Codeの論文ではなく、この記事におけるClaude Codeに関する主張は私自身のものであり、論文のものではありません。¹

論文の実質的に新しい貢献は何ですか？

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

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

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

スキル定義に対するgitのプルリクエストと何が違うのですか？

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

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

論文は特定のClaude Codeスキルエコシステムについて主張していません。論文とは別の私の主張は、構造的な問題（スキルが静的アーティファクトとしてリリースされ、失敗モードが各ユーザーによって独立に再発見され、集約メカニズムがない）はClaude Codeスキルに当てはまるということ、そしてClaude Codeや類似のエージェントフレームワーク向けにスキルを構築している人は、トラジェクトリ駆動の改善ループをどう構築するか考えるべきだということです。これは私の意見であり、論文の知見ではありません。

Shokuninとのつながりは？

Shokunin／quality-loopのフレーミングは、熟達は意図したものと実際に起きたものの差分から生まれ、それを次の試みに運ぶことで得られると論じます。静的なスキルはそのループを断ち切ります。職人が決して見ることのないセッションに差分が蓄積するからです。SkillClawはそのループを閉じる学術版で、差分の収集を自動化し、スキルにフィードバックします。規律は同じで、メカニズムが違うのです。

References