Technology

Claude Code Skills（SKILL.md）の作り方｜業務で使える手順とテンプレート【2026年8月時点】

「同じ指示を毎回チャットに貼り付けている」「CLAUDE.mdがいつの間にか手順書みたいに膨らんできた」。Claude Codeを日常的に使っていると、必ずこの壁にぶつかります。

その解決策が Claude Code Skills（SKILL.md） です。この記事では、SKILL.mdの作り方を公式ドキュメントの仕様に沿って整理し、業務でそのままコピペできるテンプレートまで紹介します。

なお、Skillsは仕様変更が速い領域です。本記事の内容はすべて 2026年8月3日時点 の公式ドキュメントに基づいています。実際に導入する際はClaude Code公式ドキュメントで最新版を確認してください。

ソースコードが表示された画面

出典: Unsplash（撮影者 Max Chen）

Claude Code Skillsとは何か｜結論と作るべきタイミング

先に手順だけ知りたい方へ：最小構成は (1) mkdir -p ~/.claude/skills/<name> でディレクトリを作る、(2) name と description だけのフロントマター＋手順3〜5行のSKILL.mdを書く、(3) /skill-name と自然文の両方で起動するかテストする、の3ステップです。詳しい手順は次の「SKILL.mdの基本構造｜最小構成から作ってみる」で解説します。

結論から言うと、Skillsは 「SKILL.mdというファイルを1つ作るだけで、Claudeのツールキットに新しい能力を追加できる仕組み」 です。Claudeが会話の内容から関連性を判断して自動的に使うか、/skill-name の形でユーザーが直接呼び出せます（公式ドキュメント、2026-08-03時点）。

作るべきタイミングは公式ドキュメントが明確に示しています。「同じ指示やチェックリスト、複数手順の作業を何度もチャットに貼り付けている」とき、そして「CLAUDE.mdの一節が事実の記述ではなく手順に育ってしまった」ときです。

ここが重要なポイントですが、CLAUDE.mdは常に読み込まれるのに対し、Skillの本文は使われるときだけ読み込まれます。そのため長い参照資料をほぼコンテキストコスト無しで持てる、というのが最大の設計上の利点です。

CLAUDE.md・カスタムコマンド・サブエージェントとの違い

「どれを使えばいいのか」で迷いやすいので、判断軸を表に整理しました。

仕組み 読み込みタイミング 主な呼び出し元 向いている用途
CLAUDE.md 常時 自動 プロジェクトの事実・前提の記述
Skills（SKILL.md） 呼び出されたときだけ Claudeの自動判断／/名前 繰り返す手順・チェックリスト
カスタムコマンド（.claude/commands/） 呼び出されたときだけ /名前 Skillsに統合済み。既存分はそのまま動作
サブエージェント 別コンテキストで実行 Skillのcontext: forkなど 本体の文脈を汚したくない重い作業

注目すべきは、.claude/commands/ のカスタムコマンドが Skillsに統合された 点です。.claude/commands/deploy.md と .claude/skills/deploy/SKILL.md はどちらも /deploy を作り、同じ動きをします。既存の .claude/commands/ はそのまま動くので、慌てて移行する必要はありません。

ベースは「Agent Skills」というオープン標準

Claude Code のSkillsは、Anthropicが2025年10月に発表した Agent Skills というオープンな仕組み（agentskills.io）に準拠しています。つまり書いたSKILL.mdはClaude Code以外のツールでも動く可能性があります。

その上でClaude Codeは「起動制御」「サブエージェント実行」「動的コンテキスト注入」を独自拡張として持っています。標準に乗りつつClaude Code固有の機能も使える、という二層構造です。

SKILL.mdの基本構造｜最小構成から作ってみる

SKILL.mdは YAMLフロントマター＋Markdown本文 の2部構成です。ここでは最小構成から手を動かして作ってみます。

1. ディレクトリを作る

保存場所は4種類あり、スコープが違います。

保存場所 パス 有効範囲
個人 ~/.claude/skills/<name>/SKILL.md 全プロジェクト
プロジェクト .claude/skills/<name>/SKILL.md そのプロジェクトのみ
Enterprise 組織の管理設定 組織全体
プラグイン <plugin>/skills/<name>/SKILL.md 導入プラグイン

同名のSkillが競合した場合は Enterprise ＞ 個人 ＞ プロジェクト の順で優先されます。チームで配布したいならプロジェクト用、自分専用の作業効率化なら個人用が基本です。

mkdir -p ~/.claude/skills/meeting-notes

2. フロントマターを書く

主要フィールドを整理します。必須項目は公式には設けられていませんが、description のみ「推奨」とされています。

フィールド 役割
name Skill名。最大64文字、小文字英数字とハイフンのみ
description 何をする／いつ使うかの説明。自動起動の判断材料
when_to_use 使いどころの補足
disable-model-invocation trueでユーザーの/名前呼び出し限定にする
user-invocable ユーザーが/名前で直接呼び出せるかどうかの制御
allowed-tools / disallowed-tools 使用ツールの許可・禁止
context forkでサブエージェント実行
paths Globでファイル種別ごとに自動起動を限定
argument-hint / arguments 引数の受け取り
model / effort 使用モデル・処理の重さ

name には “anthropic” や “claude” などの予約語は使えません。description は空にできず、XMLタグも不可とされています（ベストプラクティス、2026-08-03時点）。

なお description の文字数上限は、ドキュメントによって記載が異なります。ベストプラクティス側では「最大1,024文字」、概要側では「descriptionとwhen_to_useの合計1,536文字でリストが切り詰められる」とされており、バージョンや文脈によって上限の扱いが変わりうる 点に注意してください。いずれにせよ、実務では数行に収めるのが無難です。

3. 動作を確認する

作成後は必ず両方の経路をテストします。まず /skill-name で直接呼び出して動くか。次に、descriptionに書いた言い回しに近い依頼を普通の文章で投げて、自動的に起動するかです。

起動しないときの確認手順も公式が示しています。(1) descriptionに自分が実際に使う言葉が入っているか、(2)「What skills are available?」と聞いて一覧に出るか、(3) descriptionに近い言い回しで頼み直す、(4) /skill-name で直接呼ぶ、の順です。

業務で使えるSKILL.mdテンプレート3選

ここからはコピーしてすぐ試せる例を挙げます。いずれも骨格なので、自社のフォーマットに合わせて書き換えてください。

議事録・打ち合わせ要約Skill

---
name: meeting-notes
description: 会議の文字起こしやメモから議事録を作成する。決定事項・ToDo・保留事項の3区分で整理したいときに使う。
---

# 議事録作成

1. 入力テキストから発言者と時系列を把握する
2. 以下の3見出しで出力する
   - 決定事項（誰が何を決めたか）
   - ToDo（担当者・期限つき。不明なら「未定」と明記）
   - 保留・次回持ち越し
3. 推測で担当者や期限を補わない。原文にない情報は書かない

議事録のSkill化は個人ブログでも効果が報告されています。1会議あたり30〜60分かかっていた作成時間が合計6分になった、という実践レポートもあります。ただしこれは個人の体験談であり、Anthropic公式の統計ではありません。効果は業務内容によって大きく変わる前提で捉えてください。

週次・月次レポート作成Skill

---
name: weekly-report
description: data/ 配下のCSVから週次レポートを作成する。前週比較とハイライト抽出を含む定例レポート作成時に使う。
allowed-tools: Read, Glob
---

# 週次レポート

1. data/ 配下の最新2週分のCSVを読む
2. 主要指標を前週比で比較し、表形式（指標／今週／前週／増減率）で出力
3. 増減率±10%を超えた項目だけを「ハイライト」として3件以内で列挙
4. 原因の断定はせず「〜の可能性」と幅を持たせる

allowed-tools に指定したツールは、そのSkillを呼び出したターン（ユーザーとClaudeの1往復のやり取り）の間だけ許可プロンプトなしで実行できます。ただしこの許可は 次のメッセージを送ると消える 仕様で、セッション全体の許可にはなりません。

コードレビュー・チェックリストSkill

---
name: review-checklist
description: 変更差分に対してレビュー観点チェックを行う。プルリク作成前のセルフレビュー時に使う。
disable-model-invocation: true
allowed-tools: Read, Grep
paths: ["**/*.ts", "**/*.py"]
---

# レビューチェックリスト

以下の観点で差分を確認し、該当箇所をファイル名:行番号で示す。
- 例外処理の抜け
- 入力値の検証漏れ
- ハードコードされた認証情報
- テストが追加されていない変更

paths にGlobを指定すると、対象ファイル種別のときだけ自動起動するよう絞り込めます。副作用を持たせたくないレビュー系では disable-model-invocation: true との併用が扱いやすい構成です。

テキストが表示されたコンピュータ画面

出典: Unsplash（撮影者 Markus Spiske）

良いSkillを書くコツ｜公式ベストプラクティス

Anthropicのベストプラクティスが挙げる最重要原則は明快です。「Claudeはすでに賢いという前提に立ち、Claudeが知らないことだけ書く」「簡潔さが命」の2点です。

同ドキュメントでは、冗長な説明を省いた例（約50トークン）と冗長な例（約150トークン）が比較で示されています。丁寧に書くほど良い、という直感は当てはまりません。

タスクの自由度に応じて厳密さを変える

指示の粒度は一律ではなく、タスクの性質で変えるのが推奨されています。

  • 高自由度（複数の正解がある）: 文章での方針指示にとどめる
  • 低自由度（DBマイグレーションなど厳密な手順が必要）: 具体的なスクリプトをそのまま実行させる

500行を超えたら分割する

Skillディレクトリには SKILL.md（必須）のほか、テンプレート・サンプル出力・実行可能スクリプト・詳細リファレンスを自由に追加でき、SKILL.mdからリンクして参照させられます。公式は SKILL.mdを500行未満に保ち、詳細は別ファイルに逃がす ことを推奨しています。

評価（eval）を書いてから育てる

公式が勧めるのは「evaluation-driven development」という順序です。Skillなしでの失敗を記録 → 3つ程度のテストシナリオを作成 → ベースライン計測 → 最小限の指示を書く → 反復改善、という流れになります。

この作業はAnthropic公式の skill-creator プラグインで対話的に自動化できます。/plugin install skill-creator@claude-plugins-official でインストールし、/reload-plugins 後に「evaluate my … skill with skill-creator」のように依頼します。

参考実装を探すなら、anthropics/skills リポジトリにCreative & Design、Development & Technical、Enterprise & Communicationなどのカテゴリでサンプルが公開されています。多くはApache 2.0ライセンスですが、docx/pdf/pptx/xlsxの文書系4種はソース公開ながら非オープンソースのライセンスなので、流用時は要確認です。

業務で使う際の注意点と制限

便利な反面、業務利用では押さえておくべき制約があります。

  • 副作用のある操作は自動起動させない。 デプロイやコミット、送信系の処理には disable-model-invocation: true を付けるのが公式推奨です。これでユーザーが /名前 で明示的に呼んだときだけ動きます。
  • 信頼していないリポジトリのプロジェクトSkillに注意する。 プロジェクト配下のSkillは allowed-tools を自ら指定できるため、外部リポジトリを開く際は中身を確認する習慣が必要です。
  • Cowork／クラウドセッション（routines含む）はローカルの ~/.claude/skills/ を読み込みません。 個人Skillをroutineで使いたい場合は、claude.aiアカウント側でSkillを有効化するか、リポジトリの .claude/skills/ にコミットする必要があります。
  • コンテキストの残り方も知っておくと安心です。 Skillが呼び出されると、その内容は1つのメッセージとしてセッションに残り続けます。ターンが進んでも、Claude Codeは後続のターンでSKILL.mdを再読込しません。また、会話が長くなり要約整理される「コンパクション」（コンテキストが上限に近づいた際に過去のやり取りを圧縮する処理）が起きた時は、直近呼び出し分を先頭5,000トークンまで、複数Skill合計25,000トークンまで保持する仕組みです。

なお、機密情報や個人情報を扱うSkillを社内で運用する場合は、必ず自社のセキュリティ規程や情報システム部門の判断を確認してください。また、価格プラン別の利用可否については今回の公式ドキュメント調査で明確な記載を確認できなかったため、契約内容は公式サイトでご確認ください。

よくある失敗パターン

21個のSkillを運用した実践者のレポートでは、失敗原因として「詰め込みすぎ」「曖昧なdescription」「テスト不足」「メンテナンス放棄」が挙げられています。

特に強調されているのが 「1 Skill = 1目的」の分割設計 です。1つのSkillに手順を盛り込むほど、Claudeがいつ起動すべきか判断しづらくなり、結果として自動起動しなくなります。

descriptionが曖昧だと起動しない、という点は公式のトラブルシューティングとも一致しています。「自分が普段その作業を頼むときの言葉」をそのままdescriptionに入れるのが、最も効きやすい対処です。

まとめ｜最初の1つは「今週2回以上やった作業」から

Claude Code SkillsはSKILL.mdを1枚作るだけで始められます。最初から完璧な設計を狙う必要はありません。

今日から着手するなら、今週2回以上くり返した作業を1つだけ選んでSkill化する ところからです。手順は3つだけ。

  1. mkdir -p ~/.claude/skills/<name> でディレクトリを作る
  2. name と description だけのフロントマター＋手順3〜5行のSKILL.mdを書く
  3. /skill-name と自然文の両方で起動するかテストする

うまく動いたら、本文で紹介した安全設定（副作用のある操作を自動起動させない設定など）を必要に応じて足し、育ってきたら参照ファイルに分割していく。この順番が最短ルートです。

繰り返しになりますが、Skillsは仕様変更の速い機能です。導入前には必ずClaude Code公式ドキュメントとAgent Skillsのベストプラクティスで最新の仕様を確認してください。

参考リンク（すべて2026-08-03確認）

Related Posts

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です