Claude Codeを毎日使っているのに、毎回同じ指示を一から書いている。チームのメンバーごとに頼み方がバラバラで、結果もそろわない。そんな悩みを解決するのがSkills(スキル)です。最近は、エンジニアが自分の .claude/skills をGitHubで公開する動きも広がっています。
公開されているSkillsを見てみたんですが、どう書けば「良いSkill」になるのかが分かりません…。
この記事の結論
Skillは、.claude/skills/スキル名/SKILL.md に「説明文(description)」と「手順」を書くだけで作れます。Claudeは説明文を見て自動で使うかどうかを判断し、/スキル名 で自分から呼ぶこともできます。良いSkillのコツは、①説明文に「何をするか」と「いつ使うか」を書く、②役割を1つに絞る、③SKILL.mdは500行以内にして詳しい資料は別ファイルに分ける、の3つです(公式ドキュメント・2026年10月時点)。
この記事で分かること
- Skillsの仕組みと、置く場所
- SKILL.mdの書き方(そのまま使える例つき)
- よく使う設定項目(frontmatter)
- 公式のベストプラクティスと、つまずきやすい点
Skillsの仕組み
Skillは、Claudeに渡す「手順書」です。新人に渡す引き継ぎ資料のようなものだと考えると分かりやすいでしょう。
大事なのは、読み込まれるタイミングです。
- 説明文(description):いつも読み込まれていて、Claudeが「このSkillを使うべきか」の判断に使う
- 本文(手順):Skillが呼ばれたときに初めて読み込まれる
- 補足のファイル:本文から参照されていて、必要になったときだけ読み込まれる
つまり、説明文が雑だと、どれだけ良い手順を書いても使われません。逆に、本文や資料をたくさん置いても、呼ばれるまでは使用量を消費しにくい作りになっています。

Skillを置く場所
| 場所 | パス | 使える範囲 |
|---|---|---|
| 個人用 | ~/.claude/skills/スキル名/SKILL.md |
自分のパソコンのすべてのプロジェクト |
| プロジェクト用 | .claude/skills/スキル名/SKILL.md |
そのリポジトリ(コミットすればチームで共有できる) |
| プラグイン | プラグイン/skills/スキル名/SKILL.md |
プラグインを有効にした場所 |
自分だけがよく使う手順は個人用に、チームで共有したい手順はプロジェクト用に置くと整理しやすくなります。
実際に1つ作ってみる
公式ドキュメントにある「変更内容をまとめるSkill」を例に作ってみます。
- フォルダを作る:
~/.claude/skills/summarize-changes/ - その中に
SKILL.mdを作り、次の内容を書く
---
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
---
## Current changes
!`git diff HEAD`
## Instructions
Summarize the changes above in two or three bullet points, then list any risks you notice such as missing error handling, hardcoded values, or tests that need updating. If the diff is empty, say there are no uncommitted changes.
これで、Claude Codeに「何を変えたっけ?」と聞くと自動でこのSkillが使われ、/summarize-changes と打てば自分から呼ぶこともできます。
!`git diff HEAD` の部分は、Skillを読み込む前にコマンドを実行して、その結果を差し込む書き方です。推測ではなく「今の状態」をもとにClaudeが答えられるようになります。説明文や手順は日本語で書いてもかまいません。
よく使う設定項目(frontmatter)
SKILL.mdの先頭の --- で囲んだ部分で、Skillの動きを設定できます。1行目が --- でないと、全体が本文として扱われるので注意しましょう。
| 項目 | 内容 |
|---|---|
name |
コマンド名。省略するとフォルダ名になる |
description |
何をするか・いつ使うか。Claudeが自動で使う判断に使う(推奨) |
disable-model-invocation |
true にすると、Claudeが自動では使わない。デプロイなど自分のタイミングで実行したい作業向け |
user-invocable |
false にすると / のメニューに出さず、Claudeだけが使う |
argument-hint |
引数のヒント。例:[issue-number] |
allowed-tools |
そのSkillの実行中、許可の確認なしで使えるツール。例:Bash(git status *) |
paths |
自動で使う対象のファイルを絞る |
context |
fork にすると、会話の履歴を持たない別の場所(サブエージェント)で動かす |
引数は、本文の中で $ARGUMENTS(すべて)や $0・$1(順番で指定)として使えます。たとえば /fix-issue 123 と打てば、$ARGUMENTS が「123」に置き換わります。
良いSkillを書くコツ(公式のベストプラクティス)
- 説明文は短く具体的に:ユーザーが実際に言いそうな言葉(「何を変えた?」「コミットメッセージ作って」など)を入れる。説明文は、追加の説明と合わせて1,536文字で切られる
- 「今回だけ」ではなく「ずっと有効な指示」を書く:Skillの内容は、呼ばれたあともその会話に残り続ける。「今回はテストを実行して」ではなく「変更のたびに〜を確認する」と書く
- SKILL.mdは500行以内に:詳しい資料は
reference.mdなどの別ファイルに分け、SKILL.mdからリンクする - 役割は1つに絞る:いろいろ詰め込むと説明文があいまいになり、結局呼ばれなくなる
- 使われていないSkillは消す:
/skill-doctorで、それぞれのSkillがどれくらい使われ、どれくらい容量を使っているかを確認できる
Claude Codeを安全に動かす環境づくりは、Claude Code・Codexを安全に動かす爆速サンドボックス構築ガイドで解説しています。

つまずきやすいポイント
| 症状 | 原因と対処 |
|---|---|
| Skillが自動で使われない | 説明文に「いつ使うか」が書かれていない。ユーザーが言いそうな言葉を足す |
| 設定が効かない | SKILL.mdの1行目が --- になっていない |
| 使用量が増えた | 一度呼ばれたSkillは会話に残り続ける。長い資料は別ファイルに分ける |
| 公開されているSkillがうまく動かない | 自分の環境や業務に合っていない。構成は参考にして、手順は自分用に書き直す |
よくある質問
.claude/commands との違いは何ですか?
以前からある .claude/commands/ のファイルも引き続き使え、どちらも /コマンド名 で呼べます。Skillsは、補足のファイルを同じフォルダに置ける、Claudeが説明文を見て自動で使えるなどの点で機能が多く、公式ドキュメントでも新しく作るならSkillsが勧められています。
日本語で書いても大丈夫ですか?
大丈夫です。説明文には、自分やチームが実際に使う言葉を入れておくと、自動で使われやすくなります。
チームで共有するには?
プロジェクトの .claude/skills/ に置いて、リポジトリにコミットします。同じリポジトリで作業する人は、同じSkillを使えるようになります。
まとめ
良いClaude Code Skillは、説明文に「何をするか」と「いつ使うか」が書かれていて、役割が1つに絞られているものです。SKILL.mdは短く保ち、詳しい資料は別ファイルに分けましょう。
まずは上の「変更内容をまとめるSkill」をそのまま作って動かし、自分の作業に合わせて書き換えるところから始めてみてください。
出典・参考
Claude Code公式ドキュメント「Skills」(2026年10月時点)
AIサブスクの月額がかさんできたら
複数のAIサービスを1つの契約にまとめて、コストを抑えながら使い倒す選択肢もあります。





コメント