Claude Code に Skill を入れすぎて、しばらく動作が重く感じる時期がありました。あれもこれもと公開リポジトリから引っ張ってきた結果、/help で見える一覧が画面 1 枚に収まらなくなり、肝心なときに「結局どの Skill が動いたのだろう」が追えなくなったのです。同じことで悩んでいる方を最近よく見かけるので、今日はその整理の話を書きます。
私は 2014年から個人で iOS / Android アプリを開発しており、累計 5,000万ダウンロードを超えた今は、Claude Lab を含む 4 つの AI 技術ブログサイトを Claude Code で並行運用しています。1 日 16 本前後の記事が自動的に生成・push される運用なので、Skill 選びを間違えるとそのまま品質が崩れます。実際に「毎日使い続けて 1 ヶ月以上残った Skill」と「数日で外した Skill」を見比べると、選定軸のようなものが自然に見えてきました。今回はそれを 5 つに分けて共有します。inari111 さんの Zenn 記事「日々の開発で使っている Claude Code Skills」 で紹介されている Skill 群と、私が個人開発で残したものを行き来する形で進めます。
軸 1：プランの「保存先」を持つ Skill だけ残す
最初に外したのは、対話の中だけで計画を立てて、そのまま実装に流れていくタイプの Skill でした。短いタスクなら問題ありませんが、4 サイト分の運用変更のように 3 〜 5 時間かかるものでは、途中で文脈が見えなくなります。
代わりに長く残っているのが brainstorming と writing-plans の組み合わせです。obra さんの superpowers に収録されている Skill で、「計画は必ず指定したディレクトリにマークダウンで保存する」ことを徹底させると、後から人間がレビューできる状態が常に手元に残ります。私の場合は plans/{site}/00x_{topic}/plan.md のような階層に固定し、4 サイトのリポジトリとは別の親フォルダにまとめています。
副次的な効果として、別の 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 アプリのバージョンアップ作業や、4 サイト共通の 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 に落とし、4 サイト運用で 2 週間動かしながら細部を微調整しました。最初から自分のオリジナル手順で組もうとすると、AI 任せの曖昧な部分が残りやすく、結果として Skill 自体が「動くけど何をしてくれるのか自分でも忘れる」状態になります。boris さんは実装について次のように書いています。
I want implementation to be boring. The creative work happened in the annotation cycles.
実装は退屈で良くて、創造的な仕事は計画への注釈のなかで終わらせる、という考え方です。これは個人開発でも同じで、私が記事生成パイプラインで毎日 16 本を回せているのは、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 を残す、というのは選定の最後の基準です。
計画ファイルをどこに置くかという、地味だが効く工夫
ここまで読んでくださった方への補足です。Skill が出してくる plan.md 群をどう運用するかも、案外悩みどころです。私は当初、各リポジトリの中に _plans/ ディレクトリを作っていたのですが、4 サイトで同じことをすると 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 つに通れば、毎日 16 本の運用に組み込んでも事故が起きづらい、というのが現時点の感覚値です。明日からの開発フローを少しでも軽くする方向に Skill が働けば、毎週金曜の夜が少しだけ早く終わります。お読みいただきありがとうございました。