Claude Code Skillsとは?AIコーディングアシスタントを自分専用に拡張する仕組み
室谷今回は Claude Code Skills の話をしましょう。これ、.AI(ドットエーアイ)コミュニティでもここ1〜2ヶ月で一気に話題になってきたテーマですよね。
テキトー教師講座でも「skillsって何ですか?」という質問が増えてきましたね。前回の Claude Code とは?の記事では基本的な概念を解説しましたが、今回はスキルに絞って深掘りしていきます。
室谷スキルって一言で言うと、SKILL.md というファイルに指示を書くと Claude がそれをツールキットに追加してくれる仕組みです。要は「Claude に新しい能力を教える」イメージですね。
テキトー教師私はよく「後輩への引き継ぎマニュアル」と説明しています。スキルに書いた内容を Claude が読み込んで、関連する場面で自動的に使ってくれる。
毎回同じ説明をしなくて済むようになるんですよ。
毎回同じ説明をしなくて済むようになるんですよ。
室谷CLAUDE.md がプロジェクトの背景情報や制約を書く場所だとすると、スキルは「この作業をするときはこう動いてほしい」という手順書みたいなイメージですね。MYUUUでも記事執筆スキル、コードレビュースキル、デプロイスキルをそれぞれ作っていて、チームで共有しています。
テキトー教師コミュニティのメンバーさんにもよく聞かれるのが「CLAUDE.mdとスキルって何が違うの?」という質問です。整理すると、こういう使い分けになります。
| 項目 | CLAUDE.md | SKILL.md(スキル) |
|---|---|---|
| 役割 | プロジェクトの背景・制約・ルール | 特定の作業手順・行動パターン |
| 呼び出し方 | 常に読み込まれる | 関連する場面で自動 or /スキル名で手動 |
| 適した内容 | コーディング規約、技術スタック | デプロイ手順、コードレビュー基準 |
| スコープ | プロジェクト全体 | タスク単位 |
室谷この区分けを理解するだけで、両方の使い方がぐっとクリアになりますよね。CLAUDE.mdは「常に知っておいてほしいこと」、スキルは「この作業をやるときだけ必要なこと」という感じです。
テキトー教師補足すると、スキルは「カスタムコマンド」という名称で以前から存在していたんですが、2026年に入って大幅に進化したんですよね。
室谷そうなんですよ。
ただスキルの方が機能が豊富なので、新規で作るならスキル形式がおすすめですね。
.claude/commands/deploy.md というファイルと .claude/skills/deploy/SKILL.md は同じ /deploy コマンドとして動作するので、既存の commands ディレクトリのファイルはそのまま使えます。ただスキルの方が機能が豊富なので、新規で作るならスキル形式がおすすめですね。
テキトー教師公式ドキュメントによると、Claude Code スキルは に準拠していて、複数の AI ツール全体で機能するように設計されています。つまり今後他のツールとの互換性も期待できますね。
Claude Code Skillsの仕組みを理解する

室谷スキルの仕組みをもう少し詳しく見ていきましょう。スキルはどこに置くかによって、適用範囲が変わります。
テキトー教師この「スコープ」の概念は最初に押さえておきたいポイントですね。公式ドキュメントにまとまっているので見てみましょう。
| スコープ | パス | 適用範囲 |
|---|---|---|
| Enterprise | 管理設定から配布 | 組織内の全ユーザー |
| Personal | ~/.claude/skills/<skill-name>/SKILL.md | 自分の全プロジェクト |
| Project | .claude/skills/<skill-name>/SKILL.md | そのプロジェクトのみ |
| Plugin | <plugin>/skills/<skill-name>/SKILL.md | プラグインが有効な場所 |
室谷優先度は Enterprise > Personal > Project の順番なんですよね。で、プラグインスキルは
plugin-name:skill-name という名前空間を使うので他と競合しない。
テキトー教師個人で使う分には Personal か Project のどちらかをよく使います。チームで共有したいスキルは
.claude/skills/ を Git にコミットすれば、プロジェクトメンバー全員で使えるので便利ですよ。
室谷MYUUUでも Git 管理しています。新しいメンバーが入ってきたときに、スキルをプロジェクトに含めておくだけでチームの作業品質が揃うんですよね。
これはかなり大きいです。
これはかなり大きいです。
テキトー教師スキルのディレクトリ構造も理解しておくといいですね。基本はこういう形です。
.claude/skills/my-skill/
├── SKILL.md # メインの指示(必須)
├── template.md # Claude が埋めるテンプレート
├── examples/
│ └── sample.md # 期待する出力例
└── scripts/
└── validate.sh # Claude が実行するスクリプト
室谷SKILL.md だけあれば動くんですが、サポートファイルを追加すると格段に強力になります。例えばコードレビュースキルなら、良いコードの例を
examples/ に入れておくと、Claude が参照するときにロードできます。
テキトー教師ポイントは「SKILL.md は 500 行以内に抑える」というガイドラインですね。詳細なリファレンスは別ファイルに分けて、必要なときだけ読み込む設計にした方が、コンテキストの無駄遣いを防げます。
室谷コンテキストウィンドウって有限リソースなので、うまく管理することが大事なんですよね。さっき紹介した Wharton 教授の Mollick の話ですが、Codex と Claude Code のスキル設計思想の違いを比較した投稿が面白くて・・・
テキトー教師この比較、核心をついてますよね。「AIに参照資料を渡す」発想 vs「AIに思考プロセスを教える」発想。
Claude Code のスキルは後者で、反復改善が前提の設計になっている。
Claude Code のスキルは後者で、反復改善が前提の設計になっている。
室谷単にガイドラインを書いておくだけじゃなくて、「ドラフト → テスト → 評価 → 改善」のサイクルで育てていくのが Claude Code スキルの本来の使い方ですね。
バンドルされたスキル一覧:最初から使えるスキルをまず押さえる

室谷Claude Code にはインストール直後から使える「バンドルされたスキル」が付属しています。自作スキルの前に、まずここを把握しておくといいですね。
テキトー教師バンドルされたスキルと、
並列エージェントを生成したり、コードベースに適応したりできるので、より柔軟です。
/help や /compact などの組み込みコマンドは別物です。組み込みコマンドは固定ロジックを実行しますが、バンドルされたスキルはプロンプトベースで動作します。並列エージェントを生成したり、コードベースに適応したりできるので、より柔軟です。
室谷公式ドキュメントを確認したので、claude code skills 一覧をまとめてみましょう。
| スキル | 使い方の例 | 用途 |
|---|---|---|
/batch <instruction> | /batch migrate src/ from Solid to React | コードベース全体の大規模変更を並列で調整。5〜30の独立したユニットに分解してエージェントを生成 |
/claude-api | /claude-api | 各言語のClaude APIリファレンスとAgent SDKを読み込む。コードが anthropic をインポートする場合は自動で有効化 |
/debug [description] | /debug ビルドが失敗する | 現在のセッションのデバッグログを読み取り、トラブルシューティング |
/loop [interval] <prompt> | /loop 5m check if the deploy finished | セッション中、指定間隔でプロンプトを繰り返し実行 |
/simplify [focus] | /simplify focus on memory efficiency | 最近変更したファイルのコード品質レビューと修正。3つのレビューエージェントを並列生成 |
テキトー教師/batch は特に強力ですね。例えば「Reactのコンポーネントを全部TypeScript化して」という作業を、人間が1つずつやると1日かかるのが、並列エージェントで一気にできる。
室谷MYUUUでも大規模リファクタリングに使っています。30個のエージェントが並列で動いて、それぞれプルリクエストを開く。
人間が承認するだけでいい、という状態になります。
人間が承認するだけでいい、という状態になります。
テキトー教師/simplify も講座でよく紹介するスキルです。コードを書いた後のレビューに使うんですが、3つのエージェントが並列でレビューして結果を集約してくれる。一人のレビュアーより多角的な指摘が返ってくることが多いですね。
室谷/loop は監視系のタスクに便利です。「デプロイが完了したか5分おきにチェックして」というユースケースにぴったりです。CI/CDと組み合わせると待ち時間がゼロになります。
テキトー教師これだけでも相当使えますが、真の価値は自分でスキルを作るところから出てきます。次は使い方を見ていきましょう。
Claude Code Skillsの使い方:最初のスキルを作る手順
室谷では実際にスキルを作ってみましょう。公式ドキュメントに「コードを視覚的に説明するスキル」の例があるので、それをベースに手順を解説しますね。
テキトー教師このステップバイステップの説明が分かりやすいんですよね。claude code skills 使い方の基本として、まず3ステップで作れることを覚えておくといいです。
室谷ステップ1は、スキルディレクトリを作ること。Personal スキル(全プロジェクトで使いたい場合)なら
~/.claude/skills/ の下に作ります。mkdir -p ~/.claude/skills/explain-code
テキトー教師ステップ2が SKILL.md の作成です。これがスキルの本体です。
ファイルは2つの部分から成り立っています。
ファイルは2つの部分から成り立っています。
室谷上の部分(
--- で囲まれた YAML フロントマター)が「Claudeがいつこのスキルを使うか」を決める設定で、下の部分(マークダウン)が「スキルが呼ばれたときに Claude が従う指示」ですね。---
name: explain-code
description: Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?"
---
When explaining code, always include:
1. **Start with an analogy**: Compare the code to something from everyday life
2. **Draw a diagram**: Use ASCII art to show the flow, structure, or relationships
3. **Walk through the code**: Explain step-by-step what happens
4. **Highlight a gotcha**: What's a common mistake or misconception?
テキトー教師description フィールドが特に重要です。Claude はここを読んで「このスキルを使うべき場面かどうか」を判断するので、具体的に書くほどスキルが自動的に呼ばれやすくなります。
室谷name フィールドで設定した名前が /explain-code というコマンドになります。/ の後にスキル名を入力して直接呼び出せる。
テキトー教師ステップ3は、テストです。2つの方法があります。
- 「how does this code work?」と聞いて Claude に自動で呼び出させる
/explain-code src/auth/login.tsと直接スキルを指定する
室谷最初のうちは
/スキル名 で直接呼び出した方がデバッグしやすいですね。自動呼び出しが想定通りに動いているか確認できたら、description の調整を繰り返していく感じです。フロントマターの主要フィールドを把握する
テキトー教師スキルを実用的に使うには、フロントマターの各フィールドをしっかり理解しておく必要があります。特によく使うものをピックアップしておきましょう。
| フィールド | 説明 | よく使うシーン |
|---|---|---|
name | スキル名(/name コマンドになる) | 必ず設定 |
description | いつ使うかを Claude に伝える | 自動呼び出しを制御 |
disable-model-invocation: true | Claude が自動で使うのを防ぐ | デプロイ等の副作用があるスキル |
user-invocable: false | `/メニューから非表示にする | バックグラウンド知識スキル |
allowed-tools | 使えるツールを制限する | 安全な読み取り専用スキル |
context: fork | フォークされたサブエージェントで実行 | 重い処理を分離したい場合 |
argument-hint | オートコンプリートのヒント表示 | 引数があるスキル |
室谷disable-model-invocation: true はかなり重要です。デプロイスキルに設定しておけば、Claude が勝手に本番環境にデプロイするという事故を防げます。
テキトー教師受講生さんが最初にハマるのが「スキルが自動で呼ばれすぎる」か「全然呼ばれない」かのどちらかなんですよ(笑)。description の書き方でこのバランスが決まります。
室谷呼ばれすぎる場合は description を具体的に絞り込む。呼ばれない場合は「Use when〜」という形で使用シーンを明記する。
これだけで大体解決します。
これだけで大体解決します。
引数を使ったスキルの作り方
テキトー教師少し応用として、引数を受け取るスキルも紹介しましょう。GitHub の issue 番号を引数に取るスキルの例です。
---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
argument-hint: [issue-number]
---
Fix GitHub issue $ARGUMENTS following our coding standards.
1. Read the issue description
2. Understand the requirements
3. Implement the fix
4. Write tests
5. Create a commit
室谷/fix-issue 123 と実行すると、$ARGUMENTS が 123 に置き換えられて Claude に渡されます。$ARGUMENTS[0]、$ARGUMENTS[1] で複数の引数を個別に受け取ることもできます。
テキトー教師短縮形として
$0、$1 も使えます。「コンポーネントを別のフレームワークに移行するスキル」なら、/migrate-component SearchBar React Vue のように渡せます。---
name: migrate-component
description: Migrate a component from one framework to another
---
Migrate the $0 component from $1 to $2.
Preserve all existing behavior and tests.
室谷このパターン、めちゃくちゃ再利用性が高いんですよね。チームで同じような作業を繰り返すときに、スキルとして抽出しておくと作業品質が均一になります。
スキルの作り方【実践編】:チームで使えるスキルを設計する
室谷claude code skills の作り方について基本は分かったと思いますが、もう少し実践的なスキル設計の話をしましょう。単体で動くスキルと、チームで使えるスキルは設計が少し違います。
テキトー教師受講生さんに最初に作ってもらうのは「自分の業務の中で繰り返している作業を1つスキル化する」という課題です。ほとんどの人が「コードレビュー」「PRの説明文作成」「デバッグの進め方」あたりから始めますね。
室谷MYUUUでよく使うスキルの一つが「PR説明文生成スキル」です。うちのチームはコミットメッセージの規約があって、それをスキルに入れておくとフォーマットが揃います。
リファレンスコンテンツ型とタスクコンテンツ型
テキトー教師スキルには大きく2つの種類があります。公式ドキュメントでは「リファレンスコンテンツ」と「タスクコンテンツ」と呼んでいます。
室谷リファレンスコンテンツは「Claude がいつでも参照する知識」です。コーディング規約、API設計パターン、ドメイン知識などを入れる場所です。
---
name: api-conventions
description: API design patterns for this codebase
---
When writing API endpoints:
- Use RESTful naming conventions
- Return consistent error formats
- Include request validation
テキトー教師タスクコンテンツは「特定のアクションを Claude に実行させる手順書」です。デプロイ、コミット、コード生成など、ステップバイステップの指示を書きます。
---
name: deploy
description: Deploy the application to production
context: fork
disable-model-invocation: true
---
Deploy the application:
1. Run the test suite
2. Build the application
3. Push to the deployment target
室谷この2種類の違いを意識するだけで、スキルの設計が格段に整理されますよね。リファレンスは「Claude に知識を持たせる」、タスクは「Claude に手順を覚えさせる」というイメージです。
テキトー教師混ぜて書いてしまう人も多いですが、分けた方がスキルの再利用性が上がります。コーディング規約スキルとデプロイスキルを合体させる必要はないですから。
動的コンテキスト注入:スキルを使うたびに最新情報を渡す
室谷高度な使い方として「動的コンテキスト注入」があります。
!command` という構文で、スキルが呼ばれる前にシェルコマンドを実行して、その結果をプロンプトに埋め込めます。
テキトー教師これを使うと「PR の最新状態を取得してからレビューする」というスキルが作れます。スキルが呼ばれるたびに最新のコードやデータが自動で渡されるわけです。
---
name: pr-summary
description: Summarize changes in a pull request
context: fork
agent: Explore
allowed-tools: Bash(gh *)
---
## Pull request context
- PR diff: !`gh pr diff`
- PR comments: !`gh pr view --comments`
- Changed files: !`gh pr diff --name-only`
## Your task
Summarize this pull request for the review meeting.
室谷これ、地味にめちゃくちゃ便利なんですよ。毎回「今のPRのdiffを見て」と手動でコピペしていたのが、スキルを呼ぶだけで自動化される。
テキトー教師ポイントは「前処理である」という点です。
Claude は最終的な結果だけを受け取ります。
!command` は Claude が実行するのではなく、スキルコンテンツが Claude に送られる前にシェルで実行されます。Claude は最終的な結果だけを受け取ります。
室谷コマンドの実行結果が Claude のプロンプトに埋め込まれる、というイメージですね。これを使うと「最新のgit logを見てリリースノートを書いて」とか「現在のエラーログを見てデバッグして」というスキルが作れます。
おすすめのスキルと活用事例
テキトー教師ここからは実際に使えるスキルの事例を紹介しましょう。「claude code skills おすすめは何ですか?」という質問が.AIコミュニティでもよく出るのですが、用途によって全然違います。
室谷大きく「個人の生産性向上」と「チームの品質均一化」の2軸で整理するといいですよね。前者は自分専用の Personal スキル、後者はプロジェクトの
.claude/skills/ に入れるスキルです。個人向けおすすめスキル
テキトー教師個人でまず作っておくといいスキルを挙げると、コミットメッセージ生成スキル、コードレビュースキル、テスト生成スキルあたりが鉄板ですね。
室谷コミットメッセージは特に効果が高いです。自分のプロジェクトでのコミットの書き方のルールをスキルに入れておけば、毎回フォーマットが揃います。
---
name: commit
description: Create a well-formatted git commit following our conventions
disable-model-invocation: true
---
Create a git commit with the following format:
type(scope): subject
Types: feat, fix, docs, style, refactor, test, chore
Subject: imperative mood, 50 chars max
Body: explain the "why", wrapped at 72 chars
1. Run `git diff --staged` to see changes
2. Determine the type and scope
3. Write the commit message
4. Run `git commit`
テキトー教師disable-model-invocation: true を必ず入れてください。これがないと Claude が「コミットしてよさそうだ」と判断して勝手に実行してしまうことがあります(笑)。
室谷あと個人的によく使うのが「コードベース探索スキル」です。新しいリポジトリを触るときに「このコードはどう動いているか」を素早く理解するための手順を入れておくと、毎回同じことを説明しなくて済みます。
テキトー教師受講生さんが作って「便利だった」と言ってくれるのが「エラー解析スキル」です。エラーが出たときに何を確認するか、どの順番でデバッグするかを書いておくと、初心者でも体系的にデバッグできます。
チーム向けおすすめスキル
室谷チームで使う場合は、バリューが高い順に「コードレビュー基準スキル」「PR作成スキル」「テスト生成スキル」だと思います。
テキトー教師コードレビュー基準スキルは特に効果が大きいですね。「うちのチームではこういう観点でレビューする」という基準をスキルに入れておくと、レビューの品質がレビュアーによってブレなくなります。
室谷MYUUUで実際に使っているコードレビュースキルの構成としては、こんな感じです。
.claude/skills/code-review/
├── SKILL.md # レビューの進め方の手順
├── standards.md # コーディング規約の詳細
└── examples/
├── good-code.md # 良いコードの例
└── bad-code.md # 直すべきコードの例
テキトー教師サポートファイルを入れておくメリットが出てくる場面ですね。SKILL.md は 500 行以内に収めつつ、詳細な規約は
standards.md に分けて「必要なときだけ読んで」とSKILL.mdから参照する形にする。
室谷これで SKILL.md 本体が軽くなって、コンテキストウィンドウの消費を抑えられます。
GitHub公開スキルの活用:コミュニティで共有されるスキル
室谷claude code skills github では、コミュニティが公開しているスキルを探したり、自分のスキルを公開できます。GitHubでの共有方法も紹介しておきましょう。
テキトー教師公式ドキュメントにスキルの共有方法が書いてありましたよね。プロジェクトスキルは
.claude/skills/ をバージョン管理にコミットするだけです。
室谷OSS として公開したいなら、
.claude/skills/ ディレクトリをリポジトリに含めて GitHub に push すれば誰でも使えるようになります。別のユーザーが git clone した瞬間にスキルも一緒に入ってくる。
テキトー教師これ、npmの初期に似ている発想ですよね。室谷さんがTwitterで言っていたことと全く同じで・・・
室谷そうなんですよ。Claude Code のエコシステムで今起きていることはnpmの初期に似ていて、「スキルを作れる人」が圧倒的に少なくて「使う人」が爆発的に増えている。
今スキルを作れるポジションにいるのはかなりアドバンテージがあります。
今スキルを作れるポジションにいるのはかなりアドバンテージがあります。
テキトー教師コミュニティで共有されているスキルを探す場合は、GitHub で
claude-code-skills や agent-skills というトピックで検索するといくつか見つかります。ただ、品質はまちまちなので自分のユースケースに合うか確認してから使った方がいいですね。プラグインとスキルの関係
室谷claude code skills marketplace の話もしておきましょう。Claude Code にはプラグインという仕組みがあって、スキルを含めて一つのパッケージとして配布できます。
テキトー教師プラグインスキルは
他のスキルと名前が衝突しないので、プラグインとして配布する場合はこの形式が推奨です。
plugin-name:skill-name という名前空間を使います。例えば「my-plugin:deploy」という形式です。他のスキルと名前が衝突しないので、プラグインとして配布する場合はこの形式が推奨です。
室谷マーケットプレイスについては、公式ドキュメントで「マーケットプレイスから事前構築されたプラグインを発見してインストールする」というページがあります()。コミュニティが作ったプラグインを探せる仕組みが整備されてきています。
テキトー教師エンタープライズ向けには、管理設定から組織全体にスキルをデプロイする機能もあります。管理者がスキルを一元管理して、全員に配布できる。
大きい組織だとこれが非常に重要になってきますね。
大きい組織だとこれが非常に重要になってきますね。
高度な使い方:サブエージェントとMCPとの連携
室谷少し高度な話ですが、claude code skills subagent の連携、つまりスキルをサブエージェントで実行する方法も見ておきましょう。
テキトー教師context: fork をフロントマターに追加すると、スキルが分離したサブエージェントで実行されます。メインのセッションとは独立した環境で動くので、重い処理を分離したい場合に使います。
室谷使い所としては「今の会話の文脈に依存しない処理」ですね。コードベース全体を調査して結果を返す、とか、外部APIを叩いてデータを取ってくる、とかいった処理は
context: fork で分離すると綺麗に動きます。
テキトー教師agent フィールドでサブエージェントの種類も指定できます。Explore(コードベース探索に最適化)、Plan(計画立案に最適化)、general-purpose(汎用)の3種類があります。---
name: deep-research
description: Research a topic thoroughly
context: fork
agent: Explore
---
Research $ARGUMENTS thoroughly:
1. Find relevant files using Glob and Grep
2. Read and analyze the code
3. Summarize findings with specific file references
室谷agent: Explore は読み取り専用ツールに最適化されているので、コードの調査に使うなら最適です。「このリポジトリの認証周りの設計を調べて」という作業を非同期に投げられます。MCPとスキルの組み合わせ
テキトー教師claude code skills mcp、つまり MCP(Model Context Protocol)との組み合わせも重要なトピックですね。
室谷MCPがツールを提供するとすると、スキルはそのツールをどう使うかのワークフローを定義するものです。例えば
allowed-tools: Bash(gh *) とすると、GitHub CLI のコマンドだけを許可するスキルが作れます。
テキトー教師ツールへのアクセスを制限できるのが地味に便利です。「このスキルはファイルを読むだけで変更しない」と保証したい場合は
allowed-tools: Read Grep Glob と書けばいい。
室谷MCPサーバーで追加したツールも
allowed-tools で指定できます。「このスキルがアクティブな場合は Slack 通知ツールを使っていい」という設定も可能です。
テキトー教師スキルとMCPを組み合わせることで、Claude Code の能力を大幅に拡張できます。例えば「コードをコミットしてSlackに通知するスキル」みたいなものも作れます。
スキルを自動改善する:AIにスキルを育てさせる
室谷ここが今一番面白いトピックかもしれないんですが、スキル自体を AI に改善させることができるんですよね・・・
テキトー教師スキルクリエータースキルという話ですよね。先ほどのTwitterの投稿にあった、Karpathy の autoresearch パターンをスキルに応用した話も面白かったです。
室谷このパターンの凄いところは「スキルに対して二値テストを定義する」んですよ。AIが一つだけ変更→テスト→良くなったら保持、悪化したら自動リバート。
一晩放置で30〜50回のループが回る。
一晩放置で30〜50回のループが回る。
テキトー教師claude code skills best practices として、「スキルも育てるもの」という考え方は本当に重要だと思います。最初に完璧なスキルを作ろうとするのではなく、使いながら改善していく。
室谷定量的な評価があればそれをベースに改善できる。コピーライティングスキルなら「このヘッドラインは良いか悪いか」という判定基準を定義して、AIが自分でA/Bテストして改善していく。
人間がやると数週間かかる試行錯誤をAIが一晩で100回やれる。
人間がやると数週間かかる試行錯誤をAIが一晩で100回やれる。
テキトー教師これ、受講生さんに話すと最初は「そこまでやるの?」という顔をするんですが、実際に自動改善が回り始めると品質の向上スピードが全然違いますよ。
室谷まずは手動でも使えるスキルを一つ作って、それを徐々に洗練させていく。最終的にはスキルがスキルを改善する、というサイクルに持っていくのが理想ですね。
Claude Code Skillsのよくある質問
テキトー教師最後によくある質問をまとめておきましょう。コミュニティやオンライン講座で実際に出た質問をベースにしています。
室谷では、一つずつ答えていきましょう。
テキトー教師まず「スキルがトリガーされない」という問題。これは
「Use when〜」という形で具体的な使用シーンを書き直すと解決することが多いですね。
description が曖昧すぎることが原因であることが多いです。「Use when〜」という形で具体的な使用シーンを書き直すと解決することが多いですね。
室谷逆に「スキルが頻繁にトリガーされる」場合は、description の範囲が広すぎます。より限定的な条件に絞り込む。
「コードを説明するとき」より「コードの仕組みを聞かれたとき」の方が具体的ですね。
「コードを説明するとき」より「コードの仕組みを聞かれたとき」の方が具体的ですね。
テキトー教師「スキルの説明が短縮される」という問題もあります。description が 250 文字を超えるとコンテキスト節約のために短縮されます。
主要なユースケースは最初の 250 文字に収めるよう意識してください。
主要なユースケースは最初の 250 文字に収めるよう意識してください。
室谷「カスタムコマンドとスキルはどっちがいいの?」という質問もよく来ます。新しく作るなら絶対にスキル形式がいいです。
サポートファイル、フロントマター、自動検出など、スキルの方が機能が豊富です。既存の
サポートファイル、フロントマター、自動検出など、スキルの方が機能が豊富です。既存の
.claude/commands/ のファイルはそのまま動くので、移行を急ぐ必要はありません。
テキトー教師「スキルは有料プランでしか使えない?」という質問も来たことがあります。スキル機能自体は Claude Code のすべてのプランで使えます。
ただし、
ただし、
context: fork でサブエージェントを使う場合は、計算リソースを多く使うので Pro 以上の方が快適です。
室谷「チームメンバーにスキルを共有する一番簡単な方法は?」は、プロジェクトの
.claude/skills/ ディレクトリを Git にコミットするだけです。リポジトリを clone した人が自動的にスキルも取得できます。まとめ:Claude Code Skillsは「Claudeを育てる」仕組み
テキトー教師今回は Claude Code Skills を一通り解説しましたが、一番伝えたかったのは「スキルは育てるもの」という考え方です。
室谷SKILL.md に指示を書いて Claude に渡す、というシンプルな仕組みですが、設計次第でめちゃくちゃ強力なツールになります。
テキトー教師スキルの種類を整理すると、こういう使い分けになります。
- リファレンスコンテンツ型: コーディング規約、API規約、ドメイン知識 → Claude に「知識」を与える
- タスクコンテンツ型: デプロイ手順、コードレビュー手順、PR作成手順 → Claude に「手順」を覚えさせる
- 動的コンテキスト型: PR の差分、最新ログ、リアルタイムデータ → Claude に「最新情報」を渡す
室谷最初のスキルとしては、自分が毎日繰り返している作業を1つ選んでスキル化するのがおすすめです。コミットメッセージ、PRの説明文、コードレビューの観点、あたりが始めやすいですね。
テキトー教師.AI(ドットエーアイ)の講座でも「1週間に1つスキルを追加する」という課題を出しています。1ヶ月後には4〜5個のスキルが揃って、作業効率が体感できるくらい変わっている人が多いですね。
室谷スキルを共有する文化も広がってきています。チームで作って Git 管理するだけで、「ベストプラクティスが自動的に伝承される」状態になる。
これはオンボーディングコストの大幅削減にもつながります。
これはオンボーディングコストの大幅削減にもつながります。
テキトー教師最後に、スキルは完璧じゃなくても OK という点を強調しておきたいです。最初は粗削りでも使い始めて、フィードバックを得ながら少しずつ磨いていく。
その反復改善の姿勢が Claude Code スキルの本質だと思います。
その反復改善の姿勢が Claude Code スキルの本質だと思います。
室谷・・・これ、エンジニアリングの本質でもありますよね。完璧を目指して何も作らないより、動くものを作って改善していく。
Claude Code スキルを使い始めるきっかけが今日の記事になれば嬉しいです。
Claude Code スキルを使い始めるきっかけが今日の記事になれば嬉しいです。
出典・参考リンク
- Claude Code Skills 公式ドキュメント - Anthropic
- Agent Skills オープンスタンダード - Anthropic
