self-learning-skills解説｜Claude自身に「スキルを作らせる」自己増殖メタスキルの正体

「なぜ毎回同じことを再発見する？　一度掴んだ道は憶えておけばいい」——このひと言のようなスキルが、GitHubで★844を集めている。

Kulaxyz/self-learning-skillsは、Claude CodeやCursorをはじめとするAIコーディングエージェントを自己改善（self-improving）させるスキルだ。ただしその中身は、これまでバズってきた他のスキルとは決定的に違う。cavemanが「出力を削る」、ponytailが「コードを削る」、superpowersが「開発工程を整える」——どれも人間が書いて配った完成品だ。self-learning-skillsが提供するのは、完成品ではない。Claude自身に、あなたの作業から新しいスキルを“作らせる”仕組みである。

作者はkulaxyz氏。2026年6月28日公開のMITライセンスで、公開から短期間で★844を集めた。READMEの表現を借りれば、これはメタスキル——「作業をこなす」のではなく「どう作業がこなされたかを捕まえる」スキルだ。しかも捕まえるのは成功の道筋だけではない。失敗（ハマった袋小路）も一緒に記録する。次のセッションで既知の行き止まりを避けられることは、勝ち筋そのものより価値が高いことが多いからだ。

この記事は、Claude Skillsという仕組みそのものを解説したClaude Skills徹底解説を土台に、その仕組みを「Claude自身に使わせる」一歩先の発想を、公式リポジトリという一次情報から読み解くものだ。

self-learning-skillsとは——Claudeに「スキルを作らせる」メタスキル

self-learning-skillsを一言で言えば、「一度苦労して見つけた道（golden path）を、次のセッションでも使えるスキルに変える」仕組みだ。ここで言う「道」とは、たとえば次のようなものを指す。

・本番DBへどう到達するか（接続手順・踏み台）
・認証情報や環境変数がどこに置かれているか
・デプロイ・マイグレーション・シードのコマンドと順番
・変更を本番で「動いた」と検証する具体的な手順
・数回失敗してようやく通った、非自明なコマンド列

こうした知識は、セッションが終わると蒸発する。次のセッションはゼロから同じことを再発見する。self-learning-skillsは、この蒸発を止める。エージェントが「いま、再利用可能な道を手に入れた」瞬間を認識し、ツールが次回自動で読み込む場所にその道を永続化させるのだ。

このスキルが答える「3つの問い」

当サイトの読者がOSSに対して知りたいのは、いつも同じ3点だ。self-learning-skillsに当てはめると、こうなる。

・何ができるのか：セッションで確立した手順を、指示なしで自動的にスキル/ルール/メモに変換する
・何を解決するのか：「毎回同じ調査・デバッグを繰り返す」という、AIコーディング最大の時間浪費を解決する
・何を代替するのか：人間が手動でSKILL.mdを書き起こし、育てていく作業そのものを代替する

メタスキルであることの意味

普通のスキルは「タスクを実行」する。cavemanは出力を圧縮し、ponytailはコードを減らす。だがself-learning-skillsは、タスクを実行しない。実行するのは「タスクがどう片付いたかの捕獲」だけだ。だからこれは他のスキルと同じ土俵にいない。むしろ、他のスキルを生み出す上流にいる。

READMEはこう表現している——このスキルは道具そのものではなく、「どうやって仕事が終わったか」を捕まえる。この視点の転換が、self-learning-skillsを単なる「便利スキルの1つ」から「エコシステムの生成器」へと位置づけている。ツールごとに違うのは、掴んだ知識をどこに置くかとどう自動ロードするかだけだ。

仕組みが違っても、ループの本質——「認識する→捕まえる→再利用する」——はどのツールでも同じだ。これはAgent Skills標準の上に成り立っており、標準に準拠したエージェントなら横断的に効く。

なぜ「自己増殖」なのか——golden pathが蒸発する問題

「自己増殖」という言い方は比喩ではない。self-learning-skillsを入れたエージェントは、使えば使うほど自分専用のスキルライブラリが増えていく。その原動力は、AIコーディングの根本的な非効率にある。

知識が蒸発する、という毎回の損失

AIエージェントは、セッションのたびに賢く振る舞う。だが、セッションが閉じた瞬間に、その賢さの多くは失われる。「どうやって本番DBに繋いだか」「どのコマンドが正解で、どれが罠だったか」——苦労して掴んだ道は、コンテキストと一緒に消える。次のセッションのエージェントは、また同じ壁にぶつかり、また同じ調査をする。人間のチームで言えば、優秀な新人が毎朝記憶を失って出社してくるようなものだ。

self-learning-skillsは、この「毎朝のリセット」を止める。エージェントが道を掴んだ瞬間に、それを永続化された形——次のセッションが自動で読む場所——に書き出す。だから次のセッションは、ゼロからではなく勝ち筋の上から始まる。これが「自己増殖」の核心だ。

成功だけでなく「失敗」も収穫する

self-learning-skillsが独特なのは、成功の道筋だけでなく排除した袋小路も一緒に記録する点だ。READMEはこう言い切っている——「次のセッションで既知の行き止まりをスキップできることは、勝ち筋そのものより価値が高いことが多い」。

たとえば「このAPIは /health が落ちていても200を返すので、/ready を見ないと死活監視にならない」といった罠の知識は、成功手順と同じかそれ以上に時間を節約する。self-learning-skillsは、スキルを収穫するときに必ず「What didn’t work（効かなかったこと）」を記録するよう促す。これは、単なるメモ帳との決定的な差だ。

指示を待たない——「その瞬間」を自分で認識する

もう一つの特徴は、ユーザーの指示を待たないことだ。self-learning-skillsは、次のようなシグナルを「収穫すべき瞬間」として自分で検知する。

・タスクが数回の失敗の末にようやく通った
・エージェントが事前に知らなかったプロジェクト固有の事実を発見した（認証情報の場所、非自明なコマンド、必要な順序、直感に反する落とし穴）
・再発しそうな運用ワークフロー（DB到達・デプロイ・マイグレーション・ログの追い方）
・ユーザーが「これ憶えといて」「次から説明させないで」と明示的に言った

これらのどれか1つでも当てはまれば、許可を求めずに即座に収穫し、あとから「何をどこに保存したか」を報告する。ユーザーはいつでも編集・削除できる。この「先に動いて後で報告」という設計が、自己増殖を摩擦なく回す。

自己増殖ループを追う——検出→収穫→再利用の3ステップ

self-learning-skillsの動作は、どのツールでも同じ3ステップのループに落ちる。ここではその流れを、mermaidで俯瞰してから中身を見ていく。

図の通り、ループは「認識」に戻ってくる。使うほどライブラリが育ち、育つほど次の認識が速くなる。これが増殖のフライホイールだ。

ステップ①：認識する（Recognize the moment）

前章で挙げた4つのシグナルのどれかが立った瞬間が、収穫の合図だ。重要なのは、合図に対して即座に動くこと。「これはスキルにすべきか？」と毎回ユーザーに聞いていたら、摩擦で誰も使わなくなる。self-learning-skillsは「先に収穫、あとで報告」を徹底する。

ステップ②：収穫する（トリアージ→Promotion rule→書き出し）

ただし、何でもスキルにするわけではない。まず3段のトリアージで粒度を決める。

・多段の再利用可能な手順・ワークフロー（デプロイ手順、DB到達、マイグレーションの段取り、本番検証）→ 新しいスキルに収穫する
・単一の事実や1行の訂正（環境変数名、パス、1つの落とし穴）→ 軽量なメモ/notes（MEMORY.mdのインデックス等）に記録する。1行のためにスキルを作るのは過剰
・真に一回きりで再発しないもの → スキップする

トリアージが「粒度」を決めるのに対し、次章のPromotion ruleが「確信度」を決める。この2段構えが、スキルライブラリを肥大化と低品質から守る。

ステップ③：書き出しを委譲する（Delegate the write）

収穫すると決まったら、この会話の文脈を持ったままスキルを書く。golden pathはこの会話の中にしか存在しないからだ。書き方は2通りある。

・インライン：メインループの中で自分で書く。常に使える
・サブエージェント：ツールがこの会話を引き継ぐサブエージェントに委譲できるなら、収穫作業をメインコンテキストの外に出せる（Claude Codeなら context: fork を持つスキル）

ここでやってはいけないのは、文脈を持たない“まっさらな”エージェントに丸投げすることだ。それでは抽出する素材が何もない。書き手には必ず「いま解いた道」の記憶が要る。

ステップ④：再利用する（Reuse）

書き出されたスキルは、次のセッションで自動的にロードされる。Claude Codeならdescriptionのマッチで、Cursorならルールのdescription/globsで、AGENTS.md系なら常時読み込みで。ユーザーは何もしなくていい。次の朝、エージェントは勝ち筋を憶えたまま出社してくる。

暴走を防ぐ2つの安全弁——Promotion ruleとSecrets safety

「Claudeが勝手にスキルを量産する」と聞くと、2つの不安が湧く。質の悪いスキルが増えないか、そして秘密が漏れないか。self-learning-skillsは、この2点にそれぞれ明確な安全弁を用意している。

安全弁1：Promotion rule——推測を権威にしない

スキルは権威だ。次のセッションは、そのスキルを再検証せずに信頼して使う。だからこそ、昇格のハードルは高く設定されている。self-learning-skillsは、次の3条件を全て満たすときだけスキルに昇格させる。

このどれか1つでも欠ければ、それはまだスキルではない。暫定的なメモ（unverifiedと明記）に留めるか、スキップする。READMEによれば、この昇格ルールはコミュニティのフィードバックから生まれたものだ。「確信はあるが検証していない推測」をスキルセットから締め出すための、実運用由来の歯止めである。

安全弁2：Secrets safety——値は絶対に書かない

収穫されたスキルはコミットされ、共有され、しばしばオープンソース化される。だからこのスキルは、秘密の“値”を絶対に書き込まないよう設計されている。パスワード・トークン・接続文字列・APIキー——これらの値そのものは記録しない。記録するのはどこにあるかだけだ。

・環境変数名（例：FOO_TOKEN は lib/clients/foo-real.ts を見よ）
・セレクタ関数・クライアント
・MCPツール
・secret manager / vaultのエントリ

READMEはこれを「このスキルで最も重要なルール」と位置づけている。秘密を共有ファイルに再現すること自体が漏洩だからだ。self-learning-skillsは、収穫の手続きの中でこの制約を繰り返し強調している。

さらに書き手（特にサブエージェント）はデフォルトで越権しがちなので、収穫の指示は「スキルディレクトリ以外を触るな・ビルドするな・元のタスクを再開するな」と強く箱で囲う。名前はディレクトリ名と一致させ、小文字・ハイフンのみ（先頭/末尾/連続ハイフン禁止）——一致しないとスキルがロードされない、という実務的な落とし穴も明記されている。

他のClaude Skillとの違い——「自分で作る」か「作らせる」か

2026年のClaude Codeエコシステムでは、スキルが次々にバズった。だがself-learning-skillsは、それらと同じカテゴリにいない。ここを整理すると、何と併用すべきかが一目でわかる。

決定的な違いは「誰がスキルを書くか」にある。superpowers・caveman・ponytailは、開発者が手で書いて配布した完成品だ。あなたはそれを消費する。self-learning-skillsは真逆で、Claude自身があなたの作業からスキルを書く。あなたは消費者ではなく、スキルの生産者になる。

autoskillsとの違い——「導入」と「生成」は別レイヤー

混同しやすいのがautoskillsだ。autoskillsは「あなたのスタックに合う既存のスキルをレジストリから検出して導入する」ツール——いわばスキルの依存解決ツール（npmのようなもの）だ。対してself-learning-skillsは「あなたの作業から新しいスキルを生む」——スキルの生産側にいる。

・autoskills：既存スキルを.claude/skillsに入れる（消費者側の自動化）
・self-learning-skills：新スキルをskills/<name>/SKILL.mdとして書き出す（生産者側の自動化）

両者はレイヤーが違うので競合しない。むしろ、self-learningが生んだ良質なスキルを、autoskillsのようなレジストリ経由でチームに配る——という流れすら考えられる。

superpowers・caveman・ponytailとの併用

同様に、superpowers（開発工程の方法論）、caveman（出力トークンを削る）、ponytail（書くコードを削る）とも、self-learningは役割が重ならない。前3者が「今のタスクをどう良くするか」を扱うのに対し、self-learningは「今のタスクから何を次に持ち越すか」を扱う。だから4つ同時に入れても衝突しない。superpowersで工程を整え、cavemanで出力を締め、ponytailでコードを減らしつつ、self-learningがその過程で掴んだ道を次回のスキルに変える——という重ね方が自然だ。

self-learning-skillsの導入と、実際にスキルが生まれる流れ

self-learning-skillsは、主要なAIコーディングエージェントに横断対応している。導入は3経路あるが、最も確実なのはコミュニティ製のスキルCLIを使う方法だ。

1. npx（推奨・70+エージェント対応）

vercel-labsのskillsCLIを使う。環境にあるエージェント（Claude Code・Cursor・Codex・Cline・OpenCodeなど）を自動検出して導入する。

# このプロジェクトに導入（エージェント自動検出）
npx skills add kulaxyz/self-learning-skills

# 全プロジェクト共通（グローバル）
npx skills add kulaxyz/self-learning-skills -g

# 特定エージェントだけに
npx skills add kulaxyz/self-learning-skills -a claude-code

インストールせずに一度だけ試すこともできる。

npx skills use kulaxyz/self-learning-skills --skill self-learning | claude

2. Claude Codeプラグイン

Claude Codeのプラグインマーケットプレイス経由でも入る。

/plugin marketplace add kulaxyz/self-learning-skills
/plugin install self-learning@self-learning-skills

3. 手動コピー

ファイルを直接置く方法。各ツールの自動ロード先にコピーするだけだ。

git clone https://github.com/kulaxyz/self-learning-skills

# Claude Code（グローバル。プロジェクト共有なら .claude/skills/ へ）
cp -R self-learning-skills/skills/self-learning ~/.claude/skills/

# Cursor（.cursor/rules/ を自動ロード。収穫ルールは learned/ に溜まる）
mkdir -p .cursor/rules
cp self-learning-skills/.cursor/rules/self-learning.mdc .cursor/rules/

# AGENTS.md系（Codex・Zed・Aider・Gemini CLI…）
curl https://raw.githubusercontent.com/kulaxyz/self-learning-skills/main/AGENTS.md >> AGENTS.md

実際にスキルが「生まれる」流れ

導入後、特別なコマンドを打つ必要はない。あなたが普通に作業し、たとえば数回のデバッグの末に本番検証の手順を確立したとする。その瞬間、self-learning-skillsは収穫の6手順を回す。

・1. 昇格ルールの適用——検証が通ったか・失敗パターンを名指せるか・排除した袋小路があるか。欠けるならスキルにせずメモへ
・2. スコープと名前を自分で決める——プロジェクト用かグローバルか。デフォルトはプロジェクト用
・3. 重複チェック——既存スキルを更新できないか、.claude/skillsと~/.claude/skillsを見る
・4. golden pathを抽出——この会話が新鮮なうちに、正確なコマンド・パス・環境変数名・必要な順序・避けるべき袋小路を書き出す
・5. 書き出しを委譲——この会話の文脈を持つサブエージェント（context: fork）かインラインで執筆
・6. パスを報告——新しいスキルの場所と、何を捕まえたかを1行で伝える

生成されるスキルは、リポジトリ同梱のskill-authoring仕様に沿った形になる。SKILL.mdのfrontmatterには「何をするか」と「いつ使うか」を両方書いたdescriptionが入り（これがトリガーの生命線）、本文には手続き・Gotchas・「What didn’t work」が並ぶ。生成されたスキルの雛形は、おおよそ次のような構造だ。

---
name: verify-prod-deploy
description: >
  本番デプロイの検証手順。デプロイ後に変更が本当に反映されたかを
  確認するとき、または「ちゃんと出たか確認して」と言われたときに使う。
---

# 本番デプロイの検証

## 手順
1. `<正確なコマンド>` を実行（順序が重要ならそのまま守る）

## Gotchas
- `/health` はDB停止時も200を返す。死活は `/ready` を見る
- 認証情報は環境変数 `FOO_TOKEN`（値は書かない・場所だけ）

## What didn't work
- キャッシュを消さずに再デプロイ → 幻の型エラー。先に `clean` が要る

秘密の値がどこにも入っていない点、そして「効かなかったこと」が独立した節で残る点に注目してほしい。これが、次のセッションの時間を最も節約する部分だ。

どんなチーム・使い方に効くか——判定材料と限界

self-learning-skillsは万能ではない。効く場面と、そうでない場面をはっきりさせておく。

効く条件

・同じプロジェクトで運用作業が繰り返し発生する——デプロイ・マイグレーション・本番検証を何度も回す環境ほど、溜まった道が効く
・チームで手順を共有したい——プロジェクト用スキルはgit経由でチームに配られる。「あの人しか知らない手順」を資産化できる
・非自明な落とし穴が多い——直感に反するgotchaが多いコードベースほど、「What didn’t work」の記録が時間を生む

限界と注意

・即効性はない——効果はライブラリが育つ数週間後から。導入直後に劇的な変化は起きない
・単発・使い捨てのタスクには向かない——再発しない作業は収穫しても無駄。トリアージが「スキップ」に振り分ける
・生成物は必ず人間がレビューする——Promotion ruleとSecrets safetyという歯止めはあるが、自動生成されたスキルを鵜呑みにしてよいわけではない。特に共有する前に、秘密の混入と手順の正しさを目視する
・1行の知識にスキルは過剰——単一の事実はメモに。ここを外すとスキルリストが1行スキルで溢れる

self-learning-skillsは、Claude Skillsという仕組みの土台の上に立つ、一段メタな発想だ。他のスキルが「今のタスクをどう良くするか」を競う中で、これだけが「今のタスクから何を次に残すか」を問う。使うほど自分専用に育つこの仕組みは、単発の便利さでは測れない種類の価値を持っている。

まとめ——「スキルを配る」から「スキルを生ませる」へ

self-learning-skillsは、AIコーディングエージェントの発想を一段ずらす。これまでのスキルは「人が書いて配る完成品」だった。self-learning-skillsは、Claude自身にスキルを書かせる仕組みだ。あなたの作業からgolden pathが収穫され、次のセッションのスキルとして自己増殖していく。

・★844・MITの、Claude Code / Cursor / AGENTS.md系70+エージェント対応メタスキル
・セッションで掴んだgolden path（成功手順＋失敗の袋小路）を、指示なしで自動収穫
・トリアージ（スキル/メモ/スキップ）で粒度を、Promotion rule（検証・失敗パターン・排除した袋小路の3条件）で確信度を制御
・秘密の値は絶対に書かず、どこにあるかだけを記録する
・superpowers・caveman・ponytail・autoskillsとはレイヤーが違うので併用できる

自分専用のスキルが自動で育つこの仕組みは、Claude Skillsというレイヤーが成熟したからこそ生まれた発想だ。スキルを「使う」段階の次にある、スキルを「生ませる」段階——その入口として、self-learning-skillsは最も試す価値のある一手のひとつである。

参照ソース

• Kulaxyz/self-learning-skills — GitHub公式リポジトリ（README・SKILL.md・skill-authoring）
• Agent Skills 標準（agentskills.io）
• vercel-labs/skills — 70+エージェント対応のスキルCLI
• midudev/autoskills — 比較対象（既存スキルの導入を自動化）
• obra/superpowers — 比較対象（開発方法論スキル群）