Claude Code に Skill を入れすぎて、しばらく動作が重く感じる時期がありました。あれもこれもと公開リポジトリから引っ張ってきた結果、/help で見える一覧が画面 1 枚に収まらなくなり、肝心なときに「結局どの Skill が動いたのだろう」が追えなくなったのです。同じことで悩んでいる方を最近よく見かけるので、今日はその整理の話を書きます。
複数のリポジトリと題材を並行して抱えていると、Skill を一つ選び間違えるだけで、生成物の品質が静かにぶれていきます。厄介なのは、ぶれ始めた瞬間には気づけないことです。気づくのは数日後、出来上がったものを読み返したときでした。入れられるだけ入れて 20 個近くまで膨らんだ一覧を、最終的に日常へ残したのは 6 個でした。「毎日使い続けて 1 ヶ月以上残った Skill」と「数日で外した Skill」を見比べると、その 6 個を選び分けた軸のようなものが自然に見えてきます。今回はそれを 5 つに分けて共有します。inari111 さんの Zenn 記事「日々の開発で使っている Claude Code Skills」 で紹介されている Skill 群と、私が個人開発で残したものを行き来する形で進めます。
先に結論を置きます。5 つの軸は、それぞれ「Skill の何を見ているか」が違います。
| 軸 | 見ているもの | 残った例 | 外した例 |
|---|---|---|---|
| 1. 保存先 | 計画や中間成果がファイルとして残るか | brainstorming / writing-plans | 対話内で完結する計画系 |
| 2. 取りこぼし防止 | 質問や分解で要件漏れを物理的に止めるか | dig / decomposition | 要約だけを返すもの |
| 3. 編集可能性 | 成果物を後から人の手で直せるか | drawio の skill-cli | 画像だけを出す図解系 |
| 4. 初版の出どころ | 手順が実績のある型の写しか | 自作 feature-dev | 自分の思いつきで組んだ初版 |
| 5. 別系統のレビュー | 最終確認が同じ癖の外から来るか | codex | 同系統の追加レビュー |
この 5 つのうち、実際に手元の Skill を最も強く選別したのは軸 1 でした。その理由は記事の後半で、手元のコレクションを機械的に採点した結果とあわせて書きます。
軸 1：プランの「保存先」を持つ Skill だけ残す
最初に外したのは、対話の中だけで計画を立てて、そのまま実装に流れていくタイプの Skill でした。短いタスクなら問題ありませんが、複数サイトにまたがる運用変更のように 3 〜 5 時間かかるものでは、途中で文脈が見えなくなります。
代わりに長く残っているのが brainstorming と writing-plans の組み合わせです。obra さんの superpowers に収録されている Skill で、「計画は必ず指定したディレクトリにマークダウンで保存する」ことを徹底させると、後から人間がレビューできる状態が常に手元に残ります。私の場合は plans/{site}/00x_{topic}/plan.md のような階層に固定し、各サイトのリポジトリとは別の親フォルダにまとめています。
副次的な効果として、別の Claude Code セッションを開いたときに「先週どこまで考えたか」を plan.md を読ませるだけで再開できるようになりました。Skill が出してくる出力を、自分の脳の延長線として外部に置けるかどうかは、毎日使えるかの分かれ目になります。
軸 2：要件の取りこぼしを物理的に止める Skill かどうか
2 つ目は、要件定義のフェーズで「考慮漏れを再帰的に拾ってくれる」Skill です。fumiya-kume さんの dig と decomposition を併用していますが、これを入れる前後で、生成された記事に対する私の手戻り回数が体感で 3 割ほど減りました。
dig は AskUserQuestionTool を使って質問を再帰的に投げてくれます。私が最初に与える指示は「カテゴリは何にするか」「level は beginner / intermediate / advanced のどれにするか」「premium かどうか」程度ですが、dig を挟むと「想定読者は何で詰まっているか」「他サイトに類似記事はないか」「題材の最近 30 日のアップデートはあるか」と質問が続きます。最初は煩わしく感じましたが、これに答えていく過程で、私自身が要件を整理し直していることに気づきました。実際、ある記事では「他サイトに類似記事はないか」の一問で重複に気づき、着手前に題材そのものを差し替えたことがあります。
decomposition は計画完了後にタスクを細かく割ってくれます。私の経験では、これを通したあとに実装フェーズへ渡すと、Claude Code が 30 〜 40 分ほど止まらずに走り続けます。auto モードを常用しているわけではない通常運転でも、ここまで連続稼働してくれるのは大きく、記事を書いているあいだに別のアプリ開発タスクへ手を動かす時間が生まれました。
軸 3：成果物が「人が後でも編集できる形」で残るか
3 つ目は、出力フォーマットの選定です。jgraph 公式の drawio-mcp の skill-cli を入れてから、アーキテクチャ図を描く頻度が大幅に増えました。Go アプリのときの紹介で見かけることが多い Skill ですが、私のように iOS / Android アプリのバージョンアップ作業や、サイト共通の Cloudflare Workers 構成図を残す用途でも同じように使えます。
何が良いかというと、最終出力として .drawio のソースと PNG / SVG の両方を Git 管理できることです。AI が生成した図を画像だけで残すと、3 ヶ月後に「ここを少し直したい」が発生したときに最初から描き直しになります。ソースが残っていれば、人間が手で線を 1 本足すだけで済みます。Skill を選ぶときに「生成物が後で人の手で編集できる形に落ちるか」を見るようになってから、画像生成系の Skill が手元に残らなくなったのは納得感がありました。
軸 4：自作 Skill は「他人のブログ記事」を写経するところから始める
4 つ目は自作 Skill の話です。私の手元で最も長く残っている自作 Skill は、boris さんの How I Use Claude Code の手順をそのまま feature-dev という Skill 名でテンプレ化したものです。
3 フェーズ（リサーチ・計画・実装）構造で、特にフェーズ 2 で plan.md に注釈を書き込むワークフローが、私の運用と相性が良いと感じています。
<!-- NOTE: 補足・提案 -->
<!-- REJECT: この部分を却下する理由 -->
<!-- QUESTION: 質問・確認したいこと -->
3 種類のコメントタグだけで意図を返せるので、レビューがほぼ Slack の絵文字感覚で進みます。
このとき大事だと感じているのは、自作 Skill の最初のバージョンは、信頼している他人のブログ記事をほぼそのまま書き写す ことです。私の場合、boris さんの記述を Skill に落とし、実際の運用で 2 週間動かしながら細部を微調整しました。最初から自分のオリジナル手順で組もうとすると、AI 任せの曖昧な部分が残りやすく、結果として Skill 自体が「動くけど何をしてくれるのか自分でも忘れる」状態になります。boris さんは実装について次のように書いています。
I want implementation to be boring. The creative work happened in the annotation cycles.
実装は退屈で良くて、創造的な仕事は計画への注釈のなかで終わらせる、という考え方です。これは個人開発でも同じで、私が毎日のブログ運用を安定して回せているのは、Skill 内の手順が退屈なくらい固定されているからです。
軸 5：レビューを別系統のモデルにもさせる Skill を 1 つ入れる
最後は、私が手放せなくなった codex Skill の話です。owayo さんの Claude Code と Codex の連携を MCP から Skill に変えたら体験が劇的に改善した を参考に自作した時期もありましたが、現在は公式の openai/codex-plugin-cc と併用しています。
使い方は単純で、Claude Code で実装が終わったあとに /codex 差分をレビューしてください と打つだけです。計画段階では気づけなかった observation を Codex 側が返してくれることが多く、特に Cloudflare Workers の DEPLOY_VERSION 更新漏れや、articles.json 書き出し後のキャッシュ無効化忘れなど、私の運用に固有のミスを 8 週間で 6 件ほど指摘してもらえました。1 件あたりサイト全体のキャッシュが古いまま固まる可能性があったので、これだけで Skill を入れた価値は十分にありました。
Codex に限らず、別系統のモデルを「最後のレビュアー」として 1 つ用意しておくと、自分が同じプロンプトで書いた Skill 群の盲点を補ってくれます。1 個だけ毛色の違う Skill を残す、というのは選定の最後の基準です。
5 つの軸のうち、どれが実際に差を生んだのか
軸を 5 つ挙げておいて言うのも妙な話ですが、5 つが等しく効いているわけではありません。この記事を書いたあとも Skill の出入りは続いたので、手元のコレクションを一度まとめて採点してみました。個人開発で 4 つのサイトを一人で回している以上、感覚で「軸 1 が一番効く」と書くより、数えたほうが正確だと思ったからです。
採点は、SKILL.md の本文を 3 つの正規表現に通すだけの単純なものです。軸 1（保存先が明記されているか）、軸 2 の代理指標として手順の構造化（番号付きステップ・チェックボックス・Step 見出しの数）、そして検証やレビューの工程が言及されているか。
# skill_audit.py — 手元の SKILL.md を 3 つの観点で機械採点する
import re, sys, pathlib
root = pathlib.Path(sys.argv[1]) # 例: ~/.claude/skills
PERSIST = re.compile(
r'(?:write|save|output|create|生成|保存|書き出)'
r'[^\n]{0,80}?[`"\']?[\w./{}-]+\.(?:md|json|ya?ml|csv|html|txt)', re.I)
STEP = re.compile(
r'(?:^\s*\d+\.\s|^\s*- \[ \]|^#{2,3}\s*(?:Step|Phase|ステップ|手順))', re.I | re.M)
REVIEW = re.compile(r'(?:verify|validate|review|checklist|gate|テスト|検証|レビュー)', re.I)
rows = []
for p in sorted(root.glob('*/SKILL.md')):
t = p.read_text(errors='ignore')
if 'DEPRECATED' in t[:200] or len(t.splitlines()) < 15:
continue # 移設済みのスタブは数えない
rows.append({
'name': p.parent.name,
'persist': bool(PERSIST.search(t)),
'steps': len(STEP.findall(t)),
'review': bool(REVIEW.search(t)),
})
n = len(rows)
proc = [r for r in rows if r['steps'] >= 3] # 手順型
ref = [r for r in rows if r['steps'] < 3] # 参照型
ok = [r for r in proc if r['persist'] and r['review']]
print(f'audited={n} procedural={len(proc)} reference={len(ref)}')
print(f'persist={sum(r["persist"] for r in rows)} review={sum(r["review"] for r in rows)}')
print(f'procedural passing all three = {len(ok)}/{len(proc)}')
for r in ok:
print(' -', r['name'], 'steps=', r['steps'])手元の Skill コレクション 42 本に対して走らせた結果が、こちらです。移設済みのスタブ 4 本を除いた 38 本が採点対象になりました。
| 指標 | 件数 | 割合 |
|---|---|---|
| 採点対象 | 38 本 | — |
| 手順型（構造化ステップ 3 個以上） | 31 本 | 81.6% |
| 参照型（同 3 個未満） | 7 本 | 18.4% |
| 保存先が明記されている | 5 本 | 13.2% |
| 検証・レビュー工程への言及がある | 26 本 | 68.4% |
| 手順型のうち 3 観点すべてを満たす | 4 / 31 本 | 12.9% |
数えてみて、腑に落ちた点が二つありました。
一つは、保存先を明記している Skill が 13.2% しかないことです。検証やレビューへの言及は 68.4% あり、手順の構造化に至っては 81.6% が満たしています。つまり、この 3 つのうち軸 1 だけが際立って満たされにくいわけです。選定基準として最も差がつくのは、最も多くの Skill が落ちる基準です。私が「軸 1 が一番効く」と感じていたのは、私の好みではなく、単に世に出ている Skill の書かれ方の偏りだったわけです。
もう一つは、38 本が手順型と参照型のはっきり二つに割れたことです。参照型として出てきた 7 本は、いずれもデザイン規約かフレームワークの実装規約でした。これらに「保存先を書け」と要求するのは筋違いです。参照型は、実行の手順ではなく判断の材料を渡すためにあるので、成果物が残らないのは欠陥ではありません。
そう考えると、この記事で書いてきた 5 つの軸は、正確には手順型の Skill にだけ当てはまる基準でした。参照型を同じ物差しで測って外していた時期があり、そのときに落とした Skill をいくつか戻しています。手元で走らせて数えるまで、自分の基準に前提条件が付いていることに気づけませんでした。
Record a Skill が加わって、軸 4 の入り口が一つ増えた
軸 4 で「自作 Skill の初版は、信頼している他人のブログ記事を写経するところから始める」と書きました。この前提が、2026 年 7 月 21 日に少し変わりました。Pro・Max・Team のユーザーであれば、デスクトップアプリの + メニューにある Record a Skill から、画面を録画しながら手順を声に出して説明するだけで Skill を作れるようになったためです。録画を止めると、手順とその判断理由がまとめられ、再実行できる形で書き出されます。詳細と提供条件は Claude Code の What's new で確認できます。提供範囲や条件は変わりうるので、実際に使う前に一次情報を見ていただくのが確実です。
写経と録画は、埋めてくれる穴が違うと感じています。写経が強いのは、自分がまだ持っていない型を借りられることです。録画が強いのは、自分がすでに持っているのに言語化できていない手順を引き出せることです。私の場合、記事を push する前の確認手順は完全に手が覚えていて、文章にすると必ずどこかが抜けました。録画ならその抜けが起きません。
ただし、録画から出てくる Skill は、そのままでは軸 1 を満たしません。画面上の操作は記録されても、「その結果をどのファイルに残すか」は操作として現れないからです。先ほどの採点で保存先の明記が 13.2% しかなかったことを思うと、これは録画に限った話ではなく、手順を書き起こすとき全般に共通する抜け方なのだと思います。録画で初版を作ったあとに、出力先のパスを一行足す。この一手間を挟むかどうかで、1 ヶ月後にその Skill が残っているかが分かれる、というのが今の実感です。
計画ファイルをどこに置くかという、地味だが効く工夫
ここまで読んでくださった方への補足です。Skill が出してくる plan.md 群をどう運用するかも、案外悩みどころです。私は当初、各リポジトリの中に _plans/ ディレクトリを作っていたのですが、複数サイトで同じことをすると git status が見づらくなり、リポジトリ間で計画を流用しにくいと感じました。
現在は、ローカルにリポジトリと並列で plans/ フォルダを切り、サイトごとのサブディレクトリで管理しています。
~/Workspace/
├── claudelab.net/
├── gemilab.net/
├── antigravitylab.net/
├── rorklab.net/
└── plans/
├── claudelab/
│ ├── 001_skill-md-grep-guard/
│ │ ├── research.md
│ │ └── plan.md
│ └── 002_premium-rescue-pipeline/
│ └── plan.md
└── gemilab/
└── 001_gemini-canva-mcp-coverage/
└── plan.md
ブラウザで読み返したいときは k1LoW/mo を使ってマークダウンを localhost で開いています。
1 ヶ月使い続けるための、私なりの最終チェック
Skill を新しく試すときに、私は自分用に 3 つの確認をするようになりました。
- その Skill の出力が、3 ヶ月後の自分にも読める形で残るか
- 自然言語の指示ではなく、構造（ディレクトリ・ファイル形式・チェックリスト）として強制力があるか
- 別系統のモデルや人間が最終レビューに入れる余地が残っているか
この 3 つに通れば、毎日の運用に組み込んでも事故が起きづらい、というのが現時点の感覚値です。明日からの開発フローを少しでも軽くする方向に Skill が働けば、毎週金曜の夜が少しだけ早く終わります。お読みいただきありがとうございました。