はじめに
こんばんは、mirukyです。
Claude Codeを日々使い込んでいる方でも、Skillsをちゃんと活用できている人はまだ少ないのではないでしょうか。
CLAUDE.mdに全部書いてしまっている、/help に表示されるコマンドしか使っていないなど、そんな方にこそ読んでほしい記事です。
SkillsはClaude Codeに 「ドメイン知識」と「再現可能なワークフロー」 を持たせる仕組みで、CLAUDE.mdが「毎セッション読み込まれるルールブック」だとすれば、Skillsは 「必要なときだけ呼び出せる専門マニュアル」 です。
この記事では、公式ドキュメントを徹底調査し、Skillsの実践的な活用テクニックを10個厳選しました。初心者向けの基本から、知っている人が少ない上級テクニックまで、段階的に紹介していきます。
◎ 対象読者:Claude Codeを使い始めた〜中級者
◎ 前提:Claude Codeがインストール済み(最新版推奨)
◎ 公式ドキュメント:https://code.claude.com/docs/en/skills
① まず基本形 -- SKILL.mdを30秒で作る
①-1. Skillの最小構成
Skillsの最小単位は、.claude/skills/ ディレクトリに置いた SKILL.md ファイルです。
your-project/
├── .claude/
│ └── skills/
│ └── my-first-skill/
│ └── SKILL.md
SKILL.mdの中身はYAMLフロントマター + Markdownの本文だけのシンプルな構成です。
---
name: api-conventions
description: REST API設計のコーディング規約
---
# API規約
- URLパスはkebab-case
- JSONプロパティはcamelCase
- リストAPIには必ずページネーション
- URLパスにバージョンを含める(/v1/, /v2/)
これだけで、Claudeはタスクの文脈に合わせて自動的にこのSkillを読み込んでくれます。明示的に呼びたいときは /api-conventions と入力するだけです。
①-2. Skillの配置場所
Skillの配置場所によって、誰がそのSkillを使えるかが変わります。
| 優先度 | パス | 用途 |
|---|---|---|
| 高 | Enterprise(組織管理) | 全社ルール |
| 中 | ~/.claude/skills/ |
個人の汎用Skill |
| 低 |
.claude/skills/(プロジェクト内) |
プロジェクト固有 |
同名のSkillが複数階層に存在する場合、上位の階層が優先されます。プロジェクトのSkillはgitにコミットすればチーム全体で共有できます。
SkillsはAgent Skillsというオープンスタンダード(agentskills.io)に準拠しています。Claude Code固有の仕組みではなく、複数のAIツール間で互換性があります。
② 5つのバンドルSkillsを使いこなす
②-1. バンドルSkills一覧
Claude Codeには最初から5つのSkillが内蔵されています。ビルトインコマンド(/helpや/compact)とは異なり、バンドルSkillsはプロンプトベースで動作します。つまり、Claude自身がツールを使って柔軟に作業を進めてくれます。
| Skill名 | 何ができるか |
|---|---|
/batch |
コードベースを調査し、5〜30の独立ユニットに分解。各ユニットをgit worktreeで並列実行し、それぞれPRを作成 |
/claude-api |
Claude APIのリファレンスを読み込み、API関連コードの作成・デバッグを支援。コード内にanthropicをimportしていると自動発動 |
/debug |
Claude Codeセッション自体のデバッグログを読んでトラブルシュート。Claude Codeが期待通り動かないとき用 |
/loop |
プロンプトを一定間隔で繰り返し実行。デプロイ監視やPR状態のポーリングに最適 |
/simplify |
最近変更したファイルに対し、コード再利用・品質・効率の3観点で並列レビュー。問題を発見したら修正まで実行 |
②-2. 特に強力な /batch と /loop
/loop の使い方:
/loop 5m デプロイが完了したか確認して
5分おきにプロンプトを繰り返し実行します。セッションを開いたままにしておくだけで、定期的な監視を自動化できます。
/batch の使い方:
/batch src/ のすべてのReactコンポーネントにdisplayNameを追加して
コードベースを調査→作業を独立ユニットに分解→各ユニットを独立したgit worktreeで並列実行→完了後にPRを作成、という流れを全自動で行います。gitリポジトリが必須です。
バンドルSkillsは Claude Codeのバージョンによって増減する可能性があります。最新の一覧は /help コマンドで確認してください。
③ $ARGUMENTSで動的Skillを作る
③-1. 引数を受け取るSkill
Skillをただの静的ドキュメントで終わらせるのはもったいないです。$ARGUMENTS を使うと、ユーザーの入力を受け取って動的に動くSkillを作れます。
---
name: fix-issue
description: GitHubのissueを分析して修正する
disable-model-invocation: true
---
GitHubのissue: $ARGUMENTS を分析して修正してください。
1. `gh issue view` でissueの詳細を取得
2. 問題を理解する
3. コードベースから関連ファイルを検索
4. 修正を実装
5. テストを書いて実行
6. lint・型チェックをパス
7. コミットしてPRを作成
使い方は非常に簡単です。
/fix-issue 1234
これだけで、issue #1234の内容を取得→修正→テスト→PR作成まで一気通貫で実行してくれます。
③-2. 位置引数の使い方
引数は位置指定でも参照できます。0ベースのインデックスである点に注意してください。
| 変数 | 説明 |
|---|---|
$ARGUMENTS |
/skill-name の後のテキスト全体 |
$ARGUMENTS[0] / $0
|
最初の引数 |
$ARGUMENTS[1] / $1
|
2番目の引数 |
$ARGUMENTS[2] / $2
|
3番目の引数 |
位置引数を使ったSkillの例:
---
name: migrate-component
description: コンポーネントをフレームワーク間で移行する
---
$0 コンポーネントを $1 から $2 に移行してください。
既存の振る舞いとテストをすべて維持すること。
/migrate-component SearchBar React Vue
$0=SearchBar、$1=React、$2=Vue に置換されます。
④ 動的コンテキスト注入(!command構文)
④-1. シェルコマンドの出力をSkillに注入する
これが知る人ぞ知る強力な機能です。SKILL.mdの中で !コマンド`` と記述すると、Skillがロードされたタイミングでシェルコマンドが実行され、その出力がSkillの内容に埋め込まれます。
---
name: project-status
description: プロジェクトの現在のステータスを把握する
---
# 現在のブランチ
!`git branch --show-current`
# 最近のコミット(10件)
!`git log --oneline -10`
# 未コミットの変更
!`git diff --stat`
# 失敗しているテスト
!`npm test 2>&1 | tail -20`
Skillが呼び出されるたびにコマンドが再実行されるので、常に最新のプロジェクト状態をClaudeに伝えられます。
④-2. 動的コンテキストの仕組み
公式ドキュメントでは「preprocessing」と説明されています。
- ユーザーがSkillを呼び出す(または自動ロードされる)
-
Claudeが内容を受け取る前に、各
!コマンド`` が実行される - コマンドの出力でプレースホルダーが置換される
- Claudeは置換済みの完成テキストを受け取る
つまり、Claudeがコマンドを実行するのではなく、Skill読み込み時に前処理として1回だけ実行される仕組みです。
動的コンテキスト注入はSkillのロード時に1回だけ実行されます。対話中にリアルタイムで更新されるわけではない点に注意してください。
④-3. 活用例:環境依存のデプロイ手順
---
name: deploy
description: 環境に応じたデプロイ手順
---
# 現在の環境
!`echo $NODE_ENV`
# Dockerコンテナ状況
!`docker ps --format "table {{.Names}}\t{{.Status}}" 2>/dev/null || echo "Docker未起動"`
# 最新のデプロイタグ
!`git tag --sort=-creatordate | head -5`
⑤ context: fork でコンテキストを節約する
⑤-1. メインのコンテキストを汚さない実行方式
長いセッションでコンテキストウィンドウが埋まってきた経験はありませんか? context: fork を使うと、Skillを別のサブエージェントのコンテキストで実行できます。
---
name: audit
description: コードベースのセキュリティ監査を実行
context: fork
---
以下の観点でコードベースを監査してください:
1. SQLインジェクション
2. XSS
3. 認証・認可の不備
4. ハードコードされた秘密情報
5. 安全でないデータ処理
ファイルごとに具体的な行番号と修正案を提示してください。
⑤-2. fork実行の流れ
- 新しい独立したコンテキストが作成される
- サブエージェントがSkillの内容をプロンプトとして受け取る
- ファイル読み込みや検索を自由に行う(メインのコンテキストには影響なし)
- 要約結果だけがメインの会話に返される
数十のファイルを読み込むような重い調査でも、メインのコンテキストには要約結果しか入らないため、コンテキストウィンドウを大幅に節約できます。
⑤-3. エージェントタイプの指定
agent フィールドでサブエージェントの種類を選択できます。
context: fork
agent: Explore
| エージェント | 特徴 |
|---|---|
Explore |
Haikuモデル、読み取り専用。リサーチ向け |
Plan |
計画の立案に特化 |
general-purpose(デフォルト) |
汎用。省略時はこれが使われる |
| カスタムエージェント名 |
.claude/agents/ に定義した独自エージェント |
context: fork は明確なタスク指示があるSkillに向いています。「APIの規約に従ってください」のようなガイドライン系のSkillをforkで実行すると、サブエージェントは指示を受け取るだけで何もせずに返ってきます。
⑥ ultrathinkでExtended Thinkingを起動する
⑥-1. ultrathinkキーワードとは
Skillの本文のどこかに ultrathink というキーワードを含めると、そのSkillの実行時に**Extended Thinking(拡張思考)**が有効になります。
---
name: architect
description: システム設計を深く考えるSkill
---
以下の要件について、アーキテクチャを設計してください。ultrathink
$ARGUMENTS
## 必ず検討する項目
- スケーラビリティ
- 障害耐性
- セキュリティ
- コスト最適化
- 運用容易性
Extended Thinkingが有効になると、Claudeは通常よりも長く深い推論を行ってから回答します。
⑥-2. 向いているタスク
| 向いている | 向いていない |
|---|---|
| アーキテクチャ設計 | 単純なファイル生成 |
| 複雑なデバッグの根本原因分析 | テンプレートの適用 |
| セキュリティ監査 | 定型的なリファクタリング |
| 大規模リファクタリングの計画 | 1ファイルの修正 |
Extended Thinkingはトークン消費が大幅に増えます。単純なタスクには使わず、本当に深い思考が必要な場面に限定してください。
⑦ disable-model-invocation で誤発動を防ぐ
⑦-1. Skillの2つの呼び出し方
Skillには2つの呼び出され方があります。
| 呼び出し方 | 説明 |
|---|---|
| Claudeが自動判断 | タスクの文脈に合うSkillをClaudeが自動的に読み込む |
| ユーザーが手動 |
/skill-name で明示的に呼び出す |
⑦-2. 副作用のあるSkillを保護する
デプロイやDB操作など副作用のあるSkillは、Claudeに勝手に呼ばれると困ります。disable-model-invocation: true を設定すると、ユーザーが明示的に /skill-name で呼び出したときだけ実行されます。
---
name: deploy-prod
description: 本番環境にデプロイする
disable-model-invocation: true
---
本番デプロイを実行します。
1. mainブランチに切り替え
2. `git pull origin main`
3. テスト全件パスを確認
4. `npm run build`
5. `npm run deploy:prod`
6. デプロイ結果を確認
⑦-3. コンテキストコストの削減効果
disable-model-invocation: true には副作用防止以外にもメリットがあります。
| 設定 | 起動時の動作 | コンテキストコスト |
|---|---|---|
| デフォルト(false) | descriptionがコンテキストに読み込まれる | 毎リクエスト消費 |
true |
descriptionもコンテキストから除外 | ゼロ |
手動でしか使わないSkillをたくさん作る場合、このフラグを立てておけばコンテキストウィンドウを無駄に消費しません。
逆に user-invocable: false を設定すると、ユーザーからは直接呼べなくなり、Claudeの自動判断や他のサブエージェントからの参照専用になります。バックグラウンド知識として使いたいSkillに便利です。
⑧ サブエージェントにSkillsを読み込ませる
⑧-1. サブエージェントとSkillsの組み合わせ
カスタムサブエージェント(.claude/agents/ に置くMarkdownファイル)のフロントマターに skills フィールドを指定すると、そのサブエージェントに特定のSkillsを事前に読み込ませることができます。
---
name: security-reviewer
description: セキュリティ観点でコードをレビュー
tools: Read, Grep, Glob, Bash
model: opus
skills:
- api-conventions
- security-checklist
---
あなたはシニアセキュリティエンジニアです。
以下の観点でコードをレビューしてください:
- インジェクション脆弱性(SQL, XSS, コマンドインジェクション)
- 認証・認可の不備
- コード内の秘密情報・クレデンシャル
- 安全でないデータ処理
使い方は @ メンションで呼び出すだけです。
@security-reviewer src/auth/ をレビューして
⑧-2. サブエージェントにSkillsを持たせるメリット
サブエージェントは独立したコンテキストウィンドウで動作します。通常のSkillだと、Skillの内容はdescriptionだけが起動時にロードされ、全文は使用時に読み込まれますが、サブエージェントにプリロードされたSkillは起動時に全文が注入されます。
これにより、専門知識を最初から持った自律的なワーカーを構築できます。
⑧-3. 永続メモリの追加
サブエージェントには memory フィールドで永続メモリも設定できます。レビューで得た知見をセッションをまたいで蓄積していくことが可能です。
memory: project
メモリのスコープは user(全プロジェクト共通)、project(プロジェクト単位)、local(ワーキングツリー単位)から選べます。
⑨ CLAUDE.md vs Skills -- 正しく使い分ける
⑨-1. 判断基準
「CLAUDE.mdに書く」のと「Skillにする」のとで迷ったことはありませんか? 判断基準は明確です。
| 基準 | CLAUDE.md | Skills |
|---|---|---|
| ロードタイミング | 毎セッション開始時に全文読み込み | 説明文のみ起動時ロード、全文は使用時 |
| コンテキストコスト | 常にフルサイズで消費 | 起動時は説明文だけ(軽量) |
| 適するもの | 短い・常に必要なルール | 長い・特定場面でだけ必要な知識 |
| 例 | 「pnpmを使え」「コミット前にテスト」 | APIスタイルガイド、デプロイ手順 |
⑨-2. 迷ったときの判断フロー
① そのルール、毎回の会話で必要か → YESならCLAUDE.mdに書く
② NOの場合、特定のタスクでだけ使うか → YESならSkillにする
③ どちらでもない → そもそも書かなくていい
⑨-3. CLAUDE.mdの肥大化は性能低下に直結する
公式ドキュメントでは1ファイルあたり200行以下を目標にすることが推奨されています。ファイルが長くなるほどコンテキストを消費し、指示の遵守率が低下します。
公式から引用:
Bloated CLAUDE.md files cause Claude to ignore your actual instructions!
長くなってきたら、詳細な内容はSkillsに切り出しましょう。CLAUDE.mdには「Claudeが間違えたときに原因になるルール」だけを残すのがベストです。
「CLAUDE.mdに書いたルールが守られない」という場合、ファイルが長すぎてルールが埋もれている可能性があります。ルールを減らすか、.claude/rules/ に分割することを検討してください。
⑩ Plugin化してチームに配布する
⑩-1. Pluginの構成
作ったSkillsをチームや世界中の開発者と共有したくなったら、Plugin化しましょう。
my-plugin/
├── .claude-plugin/
│ └── plugin.json # プラグインのメタデータ(ここだけ.claude-plugin内)
├── skills/
│ └── code-review/
│ └── SKILL.md # Skill本体
├── agents/ # カスタムエージェント(任意)
└── hooks/
└── hooks.json # フック設定(任意)
よくある間違い: skills/ や agents/ を .claude-plugin/ ディレクトリの中に入れてしまうケースが多いです。.claude-plugin/ の中には plugin.json だけを置き、それ以外はすべてプラグインルートに配置してください。
⑩-2. plugin.jsonの作成
{
"name": "my-team-tools",
"description": "チーム共通のSkillsとフック集",
"version": "1.0.0",
"author": {
"name": "Your Name"
}
}
⑩-3. テストとインストール
ローカルテスト:
claude --plugin-dir ./my-plugin
Plugin内のSkillは 名前空間が自動付与 されるので、/my-team-tools:code-review のように呼び出します。複数Pluginが同名のSkillを持っていても衝突しません。
開発中にSkillを修正した場合は、Claude Code内で /reload-plugins を実行すると再起動なしで反映されます。
⑩-4. マーケットプレイスへの公開
公式マーケットプレイスへの投稿も可能です。
| 投稿先 | URL |
|---|---|
| Claude.ai | https://claude.ai/settings/plugins/submit |
| Console | https://platform.claude.com/plugins/submit |
おわりに (Skills活用チートシートを添えて)
| テク | キーポイント | 難易度 |
|---|---|---|
| ① SKILL.md基本形 |
.claude/skills/ にMarkdownを置くだけ |
低 |
| ② バンドルSkills |
/batch /loop /simplify を活用 |
低 |
| ③ $ARGUMENTS | 引数を受け取って動的に動くSkill | 中 |
④ !command構文 |
シェルコマンドの結果を前処理で注入 | 中 |
| ⑤ context: fork | 別コンテキストで実行、メインを節約 | 中 |
| ⑥ ultrathink | Extended Thinkingで深い推論を起動 | 低 |
| ⑦ disable-model-invocation | 副作用のあるSkillの誤発動を防止 | 低 |
| ⑧ サブエージェント連携 | 専門ワーカーにSkillsをプリロード | 高 |
| ⑨ CLAUDE.md vs Skills | 常時ロードか必要時ロードかで判断 | 低 |
| ⑩ Plugin化 | チーム・マーケットプレイスに配布 | 高 |
まずは①と②から始めて、③→④→⑤と段階的に手を伸ばしてみてください。 特に④(動的コンテキスト注入)と⑤(context: fork)を使いこなせるようになると、Claude Codeの使い方が根本から変わります。
ではまた、お会いしましょう。
参考リンク
Claude Code Skills 公式ドキュメント
- Extend Claude with skills - Claude Code Docs
- Create custom subagents - Claude Code Docs
- Extend Claude Code - Claude Code Docs