良い方法論を発明せず、集めて自分用に固める——Claude CodeのSkillsで作った"手続き的記憶"

この記事は連載「AIと作る、ひとりの開発OS」の一部です。単体で読めますが、全体像はこちらのハブ記事にまとめています。

前回は、3体のAIエージェント（蒼=Claude、ルナ=Gemini、亜里沙=Codex）が同じ記憶を読み書きする「共有メモリ層」の話を書いた。あれは「何を知っているか」を蓄積する仕組みだった。

今回は、その対になるもう一つの層——「どうやるか」を蓄積する仕組みの話だ。Claude Codeには「Skills」という機能がある。特定の状況で自動的に読み込まれる、方法論の置き場だ。

先に結論を書く。私のSkillsは、ほとんど自分で発明していない。良い方法論を、いろんな場所から見つけてきて、自分の開発に合う形まで固め直したものだ。この記事は、その出自を正直に棚卸しする記録になる。

Skillsとは何か

Skillは1つのMarkdownファイルで、冒頭にYAMLのfrontmatterを持つ。

---
name: grilling
description: >
  計画・設計を実装前に徹底的に検証するための連続インタビュー手法。
  ユーザーが「grillして」「詰めて」「壁打ちしたい」と言った時、または蒼自身が
  大きめの設計判断に着手する前に要件が曖昧だと感じた時に、実装より先にこのモードへ入ること。
---

`description`に「どんな時に使うか」を自然文で書いておくと、エージェントが状況を見てSkillを自動的に読み込む。呼び出しのたびに人間が指定する必要はない。

自分OSでは、Skillを2箇所で運用している。`_shared-ai/skills/`（蒼・ルナ・亜里沙の3体共通）と `.claude/skills/`（蒼専用）だ。「実装の前に、関連するSkillがあれば必ず読む」というルールを指示ファイルに書いてあるので、作業の要所要所で勝手に参照される。

ここまでは、機能の説明として珍しくない。面白いのはここからだ。実際にどんなSkillがあるかを見ていくと、出自がきれいに4パターンに分かれた。

パターン1：移植——GitHubで見つけて、そのまま持ってくる

`grilling` というSkillのファイルを開くと、冒頭にこう書いてある。

他人が公開しているスキル定義を見つけて、自分の運用に合わせて移植した、とそのまま書いてある。中身は、実装前に要件を一問一答で詰めていく手法だ。質問は1つずつ、回答を待ってから次へ、仮定より先にコードベースを調査する——手戻りを減らすための手続きが並んでいる。

同じ日（2026-07-02）に、同じリポジトリからもう1つ移植している。`handoff` というSkillで、セッションを終える時に次のエージェント（または次の自分）が最短で状況に追いつけるよう、構造化ドキュメントを作る手順だ。1つ良いものを見つけると、その周辺もまとめて持ってくる。移植は、だいたいこういう見つかり方をする。

パターン2：AIによる外部調査のキュレーション——人間の手を介さない編纂

`game-dev-playbook` というSkillは、移植とは作られ方が違う。ファイルの先頭にはこうある。

複数のAIサブエージェントに、放置ゲームの数学やプレステージ設計、Steamのリリース戦略などを外部調査させ、それを別のAI（当時のFable）が1体で取捨選択・照合して1つのプレイブックにまとめた。人間の手は入っていない。 AIが調べ、AIが編纂した。

内部の知見（各プロジェクトの`DECISIONS.md`）が「実際にやってみた結果」だとすれば、このプレイブックは「外の相場観」だ。両者を突き合わせて答え合わせする、という使い方を想定して作られている。

パターン3：使えるうちに、書き残してもらう

`fable-mindset` は、また違う出自を持っている。

Fableが使えなくなる前に、実装時にFableが実際に使っていた判断基準を、Fable自身に言語化して残してもらった。

「暗黙でできないことを、明示でやれ」——AIが自分の思考を、次に使う別のAI（あるいは同じ自分)へ向けて書き残した申し送りだ。読む・書く・止まる・聞く、それぞれの局面で何を基準に判断するかが書かれている。発見して移植したのではなく、使えるうちに書いてもらった。他の2つとは少し質感が違う。

パターン4：自作——全部が借り物ではない

ここまで3つとも「外から見つけて集めた」話だった。でも、それで終わらせると、今度はそれ自体が正確ではなくなる。実際には、自分たちで一から設計したSkillsもある。

`honest-advisor` は出典の明記がない。下位モデルの助言は「追従」「浅い網羅」「立場の回避」の3つで劣化しがちだ、という observation から始まり、必ず立場を取る・急所を1つ特定する・数字に落とす、という対抗策を定義している。これは見つけてきたものではなく、こちらで設計したプロトコルだ。

`daily-note` も同じく自作で、外部にインスパイア元があった痕跡はない。日々の作業の終わりに、各エージェントが自分のキャラクターの口調で一言を残す、という自分OS特有の運用そのものをSkillにしている。

移植、AIによるキュレーション、使えるうちに書き残してもらったもの、そして自作。4種類が混在しているのが実態だ。

出自は違っても、共通しているもの

出自が何であれ、Skillのファイルには必ず経緯が書いてある。移植なら出典のURL、キュレーションならどのAIが何をどう編纂したか、書き残しならいつ誰から受け取ったか。自作であることも、隠さず自作だと分かる書き方をしている。

これは規約というより、書く時の癖のようなものだ。でも、この癖があるおかげで、後から見返した時に「これはどこから来たのか」がすぐ分かる。前回書いた共有メモリ層の`CHARTER.md`にも同じ精神が流れている——出所の分からない情報は、信じきれない。

そして、一度Skillになると、3体のエージェント全員がそれを踏まえて動くようになる。個人的に見つけた1つの方法論が、チーム全体の前提に変わる。共有メモリが「何を知っているか」を揃えるなら、Skillsは「どうやるか」を揃える。両方揃って、ようやくチームとして機能する。

まとめ

Skillsは、方法論を発明する場所ではなく、良いものを見つけて、集めて、自分たちの開発に合う形まで固め直す場所だった。ただし全部がそうというわけではなく、自分で設計したものも確かにある——その混在ぶりまで含めて、実態だと思う。

これで、自分OSを支える4つの仕組み——人格を持ったエージェント、共有メモリ層、進捗ダッシュボード、そしてSkills——が一通り出揃った。

次回は、仕組みの外側の話を書く。3体のAIエージェントに、実際に声をつけた話だ。