🧭 本記事は Claude Code実務運用シリーズ の STEP 9「Skill化して再利用可能にする」です。
Skill を作って増やしてきた先に必ず来る「どこに何があるか分からない」問題を、Claude 自身に棚卸しさせて解決します。
シリーズ全体の地図と読む順は 親記事 にまとめています。
はじめに:スキルは増える。そして行方不明になる
このシリーズで Skill を作ったり、プラグインを入れたりしてきた結果、私の環境にはスキルがずいぶん増えました。
正確に何がどれだけあるのか、実は今回の棚卸しをするまで自分でも把握していませんでした。
自作したものは覚えています。でも、プラグインを入れるたびに付いてくるスキル、claude.ai 側で作って同期されるスキル、Claude Code 本体に組み込まれているスキル。これらが別々の場所に住んでいて、横断して一覧する組み込みコマンドがないのです。
結果、こうなります。
- 「あのスキル、スラッシュでどう呼ぶんだっけ」を毎回スキルファイルを開いて確認する
- 自然言語で依頼したら意図と違うスキルが起動する(似た description が複数あるため)
- どのスキルがサブエージェントを何体起動するのか、実行するまで分からない
そこで Claude Code 自身に全スキルを棚卸しさせ、1枚の HTML カタログにして GitHub Pages に置きました。成果物はこちらです。
スキルカタログ：呼び出し方とエージェント構成
この記事では、(1) スキルが住んでいる4つの場所、(2) カタログの4列設計とエージェント構成の分類、の2点を実際の手順で書きます。
スキルが住んでいる4つの場所
まず前提知識です。Claude Code のセッションで使えるスキルは、少なくとも次の4系統から集まってきます。
| 系統 | 場所 | 誰のもの |
|---|---|---|
| ① プロジェクト | <repo>/.claude/skills/ |
そのリポジトリ専用 |
| ② グローバル | ~/.claude/skills/ |
自分の全プロジェクト共通 |
| ③ プラグイン | ~/.claude/plugins/cache/<marketplace>/<plugin>/<ver>/skills/ |
インストールしたプラグイン由来 |
| ④ claude.ai 同期 | ~/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/…/skills/ |
claude.ai(デスクトップアプリ)で作った個人スキル |
①②は既知の方が多いと思います。今回の発見は③④でした。
③のプラグインスキルは、マーケットプレイスごとにキャッシュディレクトリが分かれています。何がインストールされているかは ~/.claude/plugins/installed_plugins.json が正で、スキル実体は次で洗い出せます。
find ~/.claude/plugins/cache -maxdepth 6 -name SKILL.md
④は今回いちばん手こずった場所です。私の環境には anthropic-skills: という名前空間のスキル群(自作の Slack 文体変換など)が見えていたのですが、①〜③のどこにも実体がない。mdfind で探した結果、デスクトップアプリ(Cowork)のセッションデータ配下に同期されていました。
mdfind -name <スキル名>
# → ~/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/<UUID>/<UUID>/skills/
④のパスは私の環境(macOS + Claude デスクトップアプリ)での観測結果です。ドキュメントに明記された仕様ではないため、アプリの更新で変わる可能性があります。「見つからないときは mdfind で実体を探す」を手順として覚えておくのが安全です。
各スキルの情報は SKILL.md の frontmatter に集約されています。4系統を横断して frontmatter だけ抜くワンライナーはこれです。
for d in .claude/skills/*/; do
echo "=== ${d%/} ==="
awk '/^---$/{c++; next} c==1{print} c==2{exit}' "$d/SKILL.md"
done
カタログの4列設計:「自然言語」と「エージェント構成」が本体
一覧表の列は最終的にこの4つに落ち着きました。
スキル / スラッシュ形式 / 自然言語での依頼例 / AIエージェントチーム構成
最初は「スキル名と使い方」の2列で作り始めたのですが、運用目線で見返すと足りませんでした。追加した2列にこそ理由があります。
「自然言語での依頼例」列が要る理由
スキルは /skill-name で明示起動するほかに、依頼文と description のマッチングで自動起動します。つまり description の書き方次第で「レビューして」の一言で起動したり、逆に狙っても起動しなかったりする。カタログに「この言い方なら起動する」の代表例を載せておくと、チームメンバーへの説明にもそのまま使えます。
frontmatter を読むと、自然言語起動まわりの制御がいくつか見つかります。
# 例1: 自然言語起動を意図的に封じる(明示的な /dev-loop でのみ起動)
name: dev-loop
disable-model-invocation: true
# 例2: 起動キーワードを description に書き込む
description: >
...「シリーズに編入して」「親記事を更新して」「シリーズを監査して」で起動。
記事本文の執筆には使わない。
例1のような自律ループ系スキルは、「チケット対応して」程度の曖昧な依頼で走り出すと危険なので、自然言語起動を切っています。カタログにも「自然言語では起動しない」と明記する。この情報は frontmatter を読まないと分からないので、一覧化の価値が出るところです。
「AIエージェントチーム構成」列が要る理由
これが今回のカタログの独自部分です。スキルには、1体で完結するものと、内部で複数のサブエージェントを起動するものがあります。実行コストも実行時間もまるで違うのに、外からは同じ「スキル」に見える。
そこで各スキルの SKILL.md(と、参照している orchestrator 系ファイル)を Claude に読ませて、構成を分類させました。私の環境のスキルは、きれいに5類型に分かれました。
| 類型 | 構成 | 私の環境での実例 |
|---|---|---|
| チーム型 | 複数サブエージェントを並列/直列起動 | 6体レビュー(Reviewer A〜F+Aggregator+Self-Critique の9役)、企画レビュー(専門家6+検証役)、自律開発ループ |
| 単独+検証型 | 本体1体+独立の検証・校閲役 | 週次レポート(決定論チェック+別モデル点検の二重ゲート)、シリーズ編集(校閲サブエージェント必須) |
| ルーター型 | 自身は判定のみ、他スキルへ委譲 | レビュー振り分け(/review-smart) |
| 単独型 | メインエージェント1体で完結 | Crashlytics 分析系、ドキュメント生成系の大半 |
| 参照型 | エージェントを起動しない共通手順・ガイド | レビュー共通手順(review-shared)、デザインガイド |
分類してみて分かったことが2つあります。
1つ目: チーム型は思ったより少ない。 分類してみると、真のチーム型は全体のごく一部でした。サブエージェントの多段構成は強力ですが、大半の業務は単独型で足りている。「とりあえずマルチエージェント」ではなく、レビュー・企画検討のような多視点が本質的に必要な工程だけがチーム型になっている、という自分の設計傾向が可視化されました。
2つ目: 「単独+検証型」という中間形態が意外と効いている。 フル並列チームは重いが、生成物をそのまま信用もできない。そこで「本体1体+検証役1体」の最小構成。週次レポートのスキルでは決定論スクリプト検証と別モデル点検の二重ゲートにしていて、これはチーム型より安く、単独型より事故りにくい妥協点です。
分類のやり方は単純で、SKILL.md 内の「Agent ツール」「サブエージェント」「並列」等の記述を grep → ヒットしたスキルだけ本文を精読、です。プラグイン製スキルは SKILL.md が読める場所にあるので同じ方法が使えます(一部は description からの推定になるため、カタログにはその旨を注記しています)。
作り方:Claude との対話ログ(実録)
カタログ生成は Claude Code に依頼しました。一発のプロンプトではなく、列を育てていく流れです。実際の依頼はこの5往復でした。
1. このプロジェクト内にあるスキルの一覧を表示して。なお、使い方も表示して
2. 使い方ですが、自然言語による使い方も一覧に乗せて
3. では、グローバルのスキルもお願いします
4. (プラグイン由来のスキルも)お願いします
5. これら全てを、「スキル、スラッシュ形式、自然言語での依頼例、
AIエージェントチーム構成」で、一覧を作成することはできますか?
ポイントは2つです。
最初から完成形を注文しない。 1回目の出力(2列の表)を見て「自然言語列が欲しい」と気づき、3回目で「グローバルも」と範囲を広げ、5回目で列構成を確定しました。最初から4列×4系統を注文していたら、途中の「この列は要らない/これが足りない」の判断ができませんでした。
「エージェント構成」列は裏取りさせる。 5回目の依頼のとき、Claude は各スキルの SKILL.md・orchestrator ファイルを grep して構成を確認してから表を埋めました。description の要約だけで書かせると「複数の観点でレビュー」のような曖昧な記述になりがちなので、「実装を確認してから書いて」に相当する動きをしてくれるかは成果物の質を分けます。出てきた表の数字(9役、8役など)は、私も元ファイルを開いて数え直しました。
HTML 化は「一覧をカタログページにして」で終わりです。折り返しやダークモード対応などの細かい調整も対話で済ませました。
GitHub Pages に置く
ここは短く。リポジトリを作って HTML を置き、Settings → Pages でブランチを指定するだけです。カタログは自己完結の単一 HTML(CSS インライン、外部リソースなし)にしてあるので、index.html 1ファイルで済みます。
置き場所を GitHub Pages にした理由は3つあります。
- URL が固定: チームに「ここ見て」と言える。チャットのやり取りに埋もれない
- リポジトリ管理: カタログの更新履歴が git log で追える
- ローカル HTML より共有しやすく、Qiita 記事より更新しやすい: 一覧表は生き物なので、記事本文に表を貼ると必ず腐ります。記事は手法を書き、表はリンクにする——本記事がその構成です
なお、業務環境のカタログには社内固有の名称(プロジェクト名・社内ツール名・チャンネル名など)が混ざりやすいので、公開リポジトリに置く場合は、push 前に固有名詞の grep 検査だけ挟むことをおすすめします。
陳腐化対策:再生成をスキル化する(設計案)
カタログの弱点は明白で、スキルを追加・削除した瞬間から古くなります。手作業の再生成は続かないので、カタログ生成そのものをスキルにするのが次の一手です。
---
name: skill-catalog-update
description: >
スキルカタログ(GitHub Pages)を再生成する。プロジェクト/グローバル/
プラグイン/claude.ai 同期の4系統を走査し、frontmatter とエージェント構成を
抽出して index.html を更新する。「カタログを更新して」で起動。
---
## 手順
1. 4系統のパスを走査し、SKILL.md の frontmatter を抽出する
2. 前回カタログとの差分(追加/削除/description 変更)を一覧表示する
3. 新規スキルはエージェント構成を SKILL.md 本文から分類する
(Agent/サブエージェント/並列 の記述を確認。推定の場合はその旨を注記)
4. index.html を再生成し、差分をユーザーに提示する
(git commit / push は人間が実行する)
このスキルは現時点では設計案で、私はまだ運用していません。手順1〜2(走査と差分表示)は本記事のコマンドの組み合わせでそのまま動きますが、手順3の自動分類の精度は運用して検証が必要です。push まで自動化しない(人間が差分を見てから公開する)のは、シリーズで繰り返してきたガードレールの原則どおりです。
まとめ
- Claude Code のスキルは4系統(プロジェクト/グローバル/プラグイン/claude.ai 同期)に散在し、横断一覧の組み込み手段がない。パスさえ知っていれば frontmatter の抽出は awk ワンライナーで足りる
- カタログの価値は「スキル名一覧」ではなく、自然言語での起動例(description マッチングの可視化)とエージェント構成の分類(チーム型/単独+検証型/ルーター型/単独型/参照型)にある。分類してみると、チーム型は全体のごく一部だった
- 一覧表は腐るので、記事に表を貼らず GitHub Pages に分離する。次の一手は再生成のスキル化
スキルを「作る」話はこのシリーズで繰り返してきましたが、資産は増えた瞬間から管理コストを生みます。棚卸しの仕組みまで含めて Skill 化——が、STEP 9 の締めくくりとして私が実感している運用です。
このシリーズの歩き方
Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。
- ◀ 前の記事: 「今日の日報作って」の一言で終わる — Codex Skillで日報作成を自動化
- ▶ 次の記事(自作Skillの実例①): Redmineチケット確認からSlack通知まで行うiOSコードレビュー用Codex Skillを作成する
- ▶ 次の記事(自作Skillの実例②): ビジネス担当の企画に、6人の専門家AI+検証役が意見書を返す ― Claude Codeスキル公開
- 🔍 あわせて読む: Fable 5が復活したので、Claude Codeの運用ルールを3つのプロンプトで棚卸しした【プロンプト全公開】 ― 何をSkill化すべきかを決める「運用ルール」の棚卸し編
- 🗺 シリーズ全記事の地図(親記事)