🧭 本記事は 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化すべきかを決める「運用ルール」の棚卸し編
🗺 シリーズ全記事の地図(親記事)