Claude Code Skillsとは？作り方・使い方を実例つきで解説【2026年8月版】

「Claudeに毎回同じ指示をコピペして貼り付けている」 「CLAUDE.mdに手順を書き足していたら、どんどん膨らんで見通しが悪くなってきた」

この記事は、そんな悩みを解決するSkills（スキル）機能の完全ガイドです。

Skillsをひとことで言えば「Claudeに渡しておく業務の手順書」。一度作っておけば、Claudeが必要な場面で自動的に読み込んで、あなたのやり方どおりに作業してくれます。

ただしこの分野、Claude Codeの中でも仕様変更のスピードが特に速く、検索上位の解説記事にも古い仕様のままのものが少なくありません。そこで本記事は、2026年8月時点の公式ドキュメント（英語版）で全項目を検証した上で、SKILL.mdの書き方から「スラッシュコマンド統合後の現行仕様」まで、実例つきで紹介します。

Claude Codeそのものが初めての方は、先にClaude Codeとはで全体像をつかんでからお読みください。

Claude Code Skillsとは？一言でいうと「AIに渡す手順書」

Claude Code Skillsとは、SKILL.mdという指示ファイルを中心にスクリプトや資料をフォルダ単位でまとめ、Claudeが必要な時だけ自動で読み込む拡張機能です。

公式ドキュメントの定義はこうです。

スキルは Claude ができることを拡張します。SKILL.md ファイルに指示を記述すると、Claude はそれをツールキットに追加します。Claude は関連する場合にスキルを使用するか、/skill-name で直接呼び出すことができます。 （出典：Claude Code公式ドキュメント）

「指示を書いたファイルを置いておくと、Claudeが自分で見つけて使ってくれる」。これがSkillsの基本動作です。Anthropic社内でも数百個のスキルが実際に稼働していると公式ブログで明かされており、実務の道具として使い込まれている機能だと分かります。

公式の定義：「スキルはファイルではなくフォルダ」

公式ブログには「A skill is a folder, not just a markdown file（スキルは単なるMarkdownファイルではなくフォルダ）」という一文があります。実際の構成は次のとおりです。

my-skill/
├── SKILL.md           # メインの指示書（これだけ必須）
├── template.md        # Claudeに埋めさせるテンプレート（任意）
├── examples/
│   └── sample.md      # 期待する出力の見本（任意）
└── scripts/
    └── validate.sh    # Claudeが実行できるスクリプト（任意）

必須なのは SKILL.md だけ。テンプレートや見本、スクリプトを同じフォルダに同梱しておくと、Claudeは指示書を読んだ後、必要に応じてそれらも参照・実行してくれます。「手順書＋添付資料一式」をひとつのフォルダで渡すイメージです。

CLAUDE.mdとの決定的な違い

「手順を覚えさせるならCLAUDE.mdでいいのでは？」と思った方、良い着眼点です。使い分けの軸は読み込まれるタイミングにあります。

	CLAUDE.md	Skills
読み込み	セッション中ずっと参照される	必要になった時だけ読み込まれる
向いている内容	常に守ってほしい前提・ルール（文体、禁止事項など）	特定の作業の手順書（月次レポート作成、公開前チェックなど）
量が増えると	毎回のやり取りを圧迫する	使わないスキルはほぼコストにならない

冒頭の悩み「CLAUDE.mdが膨らんで見通しが悪い」の正体はここです。いつも使うわけではない手順までCLAUDE.mdに書いてしまうと、関係ない作業中もその分を読み込み続けることになります。手順書の部分をSkillsに切り出せば、CLAUDE.mdは「常時ルール」だけのスリムな状態に戻せます。CLAUDE.mdの基本は使い方マスターで解説しています。

「Agent Skills」と「Claude Code Skills」は同じもの？

調べていると「Agent Skills」という言葉にも出会うはずです。関係を整理しておきます。

• Agent Skills：AIツール横断で使えるオープン規格（agentskills.io で公開）。2025年10月にAnthropicが発表し、2025年12月18日にオープン規格として公開されました
• Claude Code Skills：その規格に準拠したClaude Codeの機能。規格に加えて、呼び出し制御・サブエージェント実行・動的コンテキスト注入といった独自拡張を持ちます

両者は同じ仕組みを指す別レイヤーの呼び名であって、別の機能ではありません。発表時点の公式アナウンスでは、Claude.ai・Claude Code・Claude Agent SDK・Claude Developer Platformの各面でサポートされるとされています。

Skillsで何が変わるか：非エンジニアの実例

たとえばコーチ業の方が、セッション後に毎回「録音の文字起こしを要約して、決定事項と宿題を分けて、クライアント向けのフォローメール下書きまで作る」という一連の作業をClaudeに頼んでいるとします。

Skillsがないと、この長い指示を毎回コピペするか、CLAUDE.mdに常駐させるしかありません。スキル化すれば、「今日のセッション記録まとめて」と言うだけでClaudeが手順書を読み込み、いつもの形式で仕上げてくれます。指示の品質が「その日のプロンプトの出来」に左右されなくなるのが、実務での一番の効果です。

Skillsの仕組み：なぜ軽いのか、どこでトークンを使うのか

作り方の前に、仕組みを押さえておきましょう。ここを理解しておくと、後述する「descriptionの書き方」や「スキルが増えた時のコスト」の話がすっと入ってきます。

段階的開示（progressive disclosure）の3レベル

Skillsの中核にあるのが段階的開示という設計です。スキルの中身を一度に全部読むのではなく、必要な深さまでしか読まない仕組みで、公式ドキュメントでは3つのレベルに整理されています。

レベル	何が読み込まれるか	いつ	コンテキスト消費
レベル1	メタデータ（nameとdescriptionのみ）	常時	スキル1個あたり約100トークン
レベル2	SKILL.md本文の指示	スキルが発火した時	5,000トークン未満を推奨
レベル3	同梱ファイル（テンプレート・スクリプト等）	Claudeが実際にアクセスした時	それまでは0

スキルを100個持っていても、普段Claudeが見ているのは「名前と説明の一覧」だけ。だからスキルをたくさん作っても、待機中のコストはごくわずかで済みます。

自動発火を決めるのはdescription

では、Claudeはどうやって「今このスキルを使うべきだ」と判断しているのか。判定材料はフロントマターに書いたdescription（説明文）です。公式ドキュメントにも、descriptionはユーザーのリクエストと照合される対象であり、「何をするか」と「いつ使うか」の両方を書く必要があると明記されています。

• 通常のセッションでは、全スキルのdescriptionが一覧としてコンテキストに載っている
• ユーザーの発言がdescriptionと合致すると、そのスキルの本文（レベル2）が読み込まれる
• /スキル名 と打てば、descriptionに関係なく手動で呼び出せる

descriptionの質が発火率を直接決めるため、書き方のコツは後の章でビフォーアフター付きで解説します。

注意：一度読み込むとセッション中ずっと残る

「必要な時だけ読むから軽い」という説明で終わっている記事が多いのですが、公式ドキュメントには続きがあります。一度発火したスキルの本文は、そのセッションが終わるまでコンテキストに残り続けます。

関連する現行仕様（2026年8月時点）も挙げておきます。

• スキル一覧（レベル1）に使える予算はモデルのコンテキストウィンドウの1%。あふれると、呼び出し回数の少ないスキルから説明文が落とされます
• descriptionとwhen_to_useの合計は、一覧上1,536文字で切り詰められます
• 会話の自動圧縮（コンパクション）時は、各スキルの先頭5,000トークン・合計25,000トークンまでが持ち越されます
• 一覧のコンテキスト消費量は /doctor で概算を確認できます

スキルを増やすほどトークン消費は着実に増えるので、「スキル運用でどれくらいコストが変わるのか」が気になる方はClaude Codeの料金プランもあわせてどうぞ。

まずは最初から入っているスキルを使ってみる

自作の前に、Claude Codeに最初から入っているバンドルスキルを触ってみるのが近道です。「スキルが発火して動く」感覚を、作る前に体験できます。

代表的なバンドルスキル6つ（2026年8月時点）

公式ドキュメントが例として挙げているバンドルスキルは次の6つです。

スキル	役割
/doctor	設定や環境の診断（スキル一覧のコンテキスト消費の概算もここで見られます）
/code-review	現在の差分やPR・ブランチを対象にコードレビューを実行
/batch	コードベースの大きな変更を独立した単位に分解し、並列で処理
/debug	デバッグログを有効にし、そのログを読んで問題を切り分ける
/loop	同じプロンプトを繰り返し実行（実行間隔の指定も可）
/claude-api	Claude API関連のリファレンス資料を読み込む

ひとつ補足しておくと、公式の書き方は「/doctor、/code-review……などが含まれます」という例示です。バンドルスキルはこの6つで打ち止めではなく、後述の /run 系をはじめ他にも用意されています。その時点の全リストは公式のコマンドリファレンスで確認でき、目的欄に「スキル」と印が付いているものがバンドルスキルです。

バンドルスキルは「プロンプトベース」、内部的にはClaudeに詳細な指示を渡して作業を組み立てさせる方式です。/help や /compact のような組み込みコマンド（固定の処理を直接実行するもの）とは動作原理が違う、と公式が区別しています。

なお /verify と /code-review は、現行仕様ではユーザーが呼んだ時だけ実行されます（以前はClaudeが自発的に走らせることもありました）。時間もトークンも食うチェック系の主導権がユーザー側にある、という設計です。

アプリ実行系の3つ

このほか、アプリを実際に起動して動作確認する系統として /run・/verify・/run-skill-generator の3スキルも用意されています（2026年8月時点）。作ったものを「本当に動くか」まで確かめる用途のもので、最初は「そういうものもある」と知っておけば十分です。

自作の前に「発火の感覚」をつかむ

まずは /doctor あたりを実際に打ってみてください。「スラッシュで手動起動する」体験がそのまま自作スキルの操作感になります。Claudeに「利用可能なスキルは何ですか？」と聞くと、いま読み込まれているスキルの一覧も確認できます。スラッシュコマンドの基本操作に不安がある方は、先にClaude Codeの使い方マスターをどうぞ。

Claude Code Skillsの作り方【3ステップ】

ここから実際に作ります。必要なのはフォルダ1個とテキストファイル1個だけ。プログラミングの知識は要りません。まだClaude Code自体を導入していない方は、先に始め方ガイドで環境を整えてからお戻りください。

ステップ1：スキル用のフォルダを作る

個人用スキルの置き場所は ~/.claude/skills/ です（~ は自分のホームフォルダのこと。WindowsならおおむねC:\Users\ユーザー名 に当たります）。ターミナルなら次の1行で作れます。

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

エクスプローラーやFinderで手動でフォルダを作っても構いません。このフォルダ名（ここでは meeting-summary）が、そのままスキルの呼び出し名になります。

ステップ2：SKILL.mdを書く

作ったフォルダの中に SKILL.md というファイルを作り、次の2部構成で書きます。

1. フロントマター：ファイル冒頭を --- で挟んだ設定欄。Claudeに「いつ使うか」を伝える
2. 本文：発火した時にClaudeが従う手順書（Markdown形式）

議事録要約スキルの例です。

---
description: 打ち合わせの文字起こしや議事メモを要約する。ユーザーが「議事録まとめて」「打ち合わせの要約」「ミーティングメモ整理」と言ったときに使う。
---

# 議事録要約の手順

1. 対象ファイルを読み、次の3区分に整理する
   - 決定事項
   - 宿題（担当者と期限つき）
   - 継続議論
2. 冒頭に3行以内の全体サマリーを付ける
3. 固有名詞は原文の表記をそのまま使い、推測で補完しない
4. 出力はMarkdownの見出し付きで、ファイル名は「日付_議事録要約.md」とする

descriptionには「何をするか」と「いつ使うか（ユーザーが言いそうな言葉）」の両方を入れるのがポイントです。ここが自動発火の判定材料になります。

なお、公式ドキュメントの最小サンプルでは本文中に !`git diff HEAD` のような記法でコマンドの実行結果を差し込む例も示されています（動的コンテキスト注入）。慣れてきたら覗いてみてください。

ステップ3：2通りの呼び出し方でテストする

公式が案内するテスト方法は2つです。

1. 自動発火のテスト：descriptionに書いた状況どおりに、自然な言葉で頼む（例：「昨日の打ち合わせメモ、議事録まとめて」）
2. 手動呼び出しのテスト：/meeting-summary と直接打つ

両方動けば完成です。ここまで、慣れれば10分もかかりません。

補足：作ったのに反映されない時

現行のClaude Codeにはライブ変更検出があり、既存のskillsフォルダ内でスキルを追加・編集・削除すると、再起動なしで同じセッション中に反映されます。ただし1つだけ例外があります。

SKILL.mdフロントマターの現行仕様【2026年8月時点】

フロントマターは、多くの解説記事で情報が古くなっている場所です。ここでは2026年8月7日に公式ドキュメント（英語版）を確認した内容だけで整理します。

Claude Codeの中だけなら「全フィールド任意」

「nameとdescriptionは必須」と書いている記事をよく見かけますが、現行の公式ドキュメントの記載は違います。

All fields are optional. Only description is recommended so Claude knows when to use the skill. （すべてのフィールドは任意。Claudeがいつスキルを使うか判断できるよう、descriptionのみ推奨）

Claude Codeのローカルで使う分には、必須フィールドはひとつもありません。省略した場合の挙動も決まっています。

• name を省略 → フォルダ名がそのまま表示名になる
• description を省略 → 本文の最初の段落が説明文として使われる

実際、公式ドキュメントの最初のサンプルコードには name: がありません。「nameは書かなくていいのか」と不安になった方、公式のお手本がそうなっています。

claude.aiやAPIに配布するなら話が別

ただし、この「全部任意」はClaude Code内の話。作ったスキルをclaude.ai（Web版）へアップロードしたり、Skills API経由で配布したりする場合はルールが変わります。

この2層構造（ローカルは全任意／配布時は必須あり・フィールド限定）を知らないまま、Claude Code用のフロントマターを付けたスキルをそのままアップロードすると、エラーになって初めて気づくことになります。

フロントマター全フィールド一覧

2026年8月時点の公式リファレンスに載っている全フィールドです。太字の4つだけ覚えれば、当面は困りません。

フィールド	役割
name	一覧に出る表示名。省略時はフォルダ名
description	何をする・いつ使うか。自動発火の判定材料（唯一の「推奨」）
when_to_use	発火のヒントを追記（descriptionに連結される）
argument-hint	入力補完に出る引数のヒント
arguments	$名前 で本文に差し込める名前付き引数
disable-model-invocation	true でClaudeの自動発火を禁止（手動 /名前 のみに）
user-invocable	false でスラッシュメニューから隠す
allowed-tools	スキル実行中、確認なしで使えるツールを指定
disallowed-tools	実行中に使わせないツールを指定
model	このスキル実行時に使うモデル
effort	処理の踏み込み度合い（low〜max）
context	fork でサブエージェントとして実行
agent	context: fork 時のエージェント種別
background	fork時に結果を待つかどうか
hooks	スキルのライフサイクルに紐づく自動処理
paths	globパターンで、対象ファイルを触っている時だけ発火候補にする
shell	本文に埋め込んだシェルコマンド（動的コンテキスト注入）を実行するシェル（bash / powershell）
metadata	自作ツール向けの自由記述欄
license	ライセンス表記（Claude Codeでは動作に影響しない）
compatibility	動作要件メモ（同上）

最初に覚えるのは4つだけ

• description：発火の生命線。必ず書く
• disable-model-invocation：「勝手に実行されたら困る」作業の安全弁（実例は後述）
• allowed-tools：毎回の許可確認を減らしたい定型作業に
• paths：「このファイルを触っている時だけ」の条件付け（実例は後述）

残りは必要になった時に公式リファレンスを引けば十分です。

スキルを置く場所とチーム共有

配置場所の早見表

スキルは置く場所によって効く範囲が変わります。公式ドキュメントの整理は次の4種類です。

種類	置き場所	効く範囲
Enterprise	組織の管理設定	組織の全ユーザー
パーソナル	~/.claude/skills/スキル名/SKILL.md	自分の全プロジェクト
プロジェクト	.claude/skills/スキル名/SKILL.md	そのプロジェクトのみ
プラグイン	プラグイン/skills/スキル名/SKILL.md	プラグイン有効な場所

迷ったら判断基準はシンプルで、どの作業フォルダでも使いたいならパーソナル、その案件フォルダ専用（かつ後でチームに配るかもしれない）ならプロジェクトです。

同名スキルがぶつかったらどれが勝つか

同じ名前のスキルが複数の場所にあると、Enterprise > パーソナル > プロジェクトの順で優先されます。また、これらの自作スキルは同名のバンドルスキルも上書きできます。プラグイン配布のスキルは プラグイン名:スキル名 という名前空間を持つため、そもそも衝突しません。

チームで共有する3つの方法

公式が挙げる配布手段は次の3つです。

1. プロジェクトスキル：.claude/skills/ をGitにコミットする。リポジトリを共有している全員に行き渡る、いちばん手軽な方法
2. プラグイン：プラグイン内に skills/ フォルダを作って配布する
3. 管理設定：組織の管理設定で全社展開する（Enterprise向け）

自動発火するdescriptionの書き方

スキル自作で最初につまずくのが「作ったのに使ってくれない」問題です。原因のほとんどはdescriptionにあります。

「何をするか」と「いつ使うか」の両方を書く

公式ドキュメントは、descriptionを「Claudeがユーザーのリクエストと照合する対象」と位置づけ、What（何をするか）とWhen（いつ使うか）の両方を書くよう求めています。片方だけでは照合の手がかりが足りません。

悪い例と良い例

発火しない時の公式チェックリスト

公式ドキュメントが案内するトラブルシュートは4項目です。

1. descriptionに、ユーザーが自然に言うキーワードが含まれているか確認する
2. 「利用可能なスキルは何ですか？」と聞いて、一覧にスキルが表示されるか確認する
3. descriptionの文言に近い言い方でリクエストを言い換えてみる
4. /スキル名 で直接呼び出してみる

逆に発火しすぎる時は

関係ない場面でスキルが呼ばれてしまう場合の対処も公式に明記されています。①descriptionをより具体的にする、②手動でだけ使いたいなら disable-model-invocation: true を付ける、の2つです。

skill-creatorプラグインでスキルを評価・改善する

スキル作りを助けてくれる公式ツールにskill-creatorがあります。ただし、ここで多くの記事が触れていない重要な前提がひとつ。

skill-creatorはプラグイン：最初は入っていない

skill-creatorは標準搭載ではなく、公式マーケットプレイスからインストールが必要なプラグインです。/skill-creator と打っても何も出ない場合、壊れているのではなく、単に入っていません。導入手順は次のとおりです（2026年8月時点）。

/plugin install skill-creator@claude-plugins-official

これでエラーになる場合は、先にマーケットプレイス自体を登録します。

/plugin marketplace add anthropics/claude-plugins-official

その後、再度installを実行。インストール完了時に「Run /reload-plugins to activate.」と表示されたら、/reload-plugins を実行すると現在のセッションで使えるようになります。

skill-creatorでできること

名前から「スキルを作ってくれるツール」と思われがちですが、公式ドキュメントでの位置づけは評価と改善のループを自動化するツールです。テストケースの作成（evals）、クリーンな環境での分離実行、結果の採点、バージョン間のブラインドA/B比較、descriptionのチューニング支援などが含まれます。使い方は「evaluate my meeting-summary skill with skill-creator」のように自然な文章で頼むだけです。

「発火したか」と「期待通り動いたか」は別物

公式ドキュメントの評価の考え方は明快で、スキルが発火したことは「Claudeがスキルを見つけた」ことしか意味せず、意図どおりの出力が出たかは別問題だとしています。測るべきは2つ。

1. 使ってほしい場面で、ちゃんと呼び出されるか（発火率）
2. 呼び出された時、期待どおりの出力になるか（品質）

テストは新しいセッションで行うのが公式推奨です。スキルを作った直後のセッションには文脈が残っているため、指示書の不備が隠れてしまうからです。

Skills・スラッシュコマンド・サブエージェント・MCP・CLAUDE.mdの違い

Claude Codeには拡張の仕組みが複数あり、初心者が最も混乱するポイントです。しかもこの整理は、2026年に入って大きく変わりました。

カスタムスラッシュコマンドはSkillsに統合された

以前のClaude Codeには「カスタムスラッシュコマンド（.claude/commands/ に置くファイル）」という別機能がありましたが、現行の公式ドキュメントにはこう明記されています。

Custom commands have been merged into skills.（カスタムコマンドはスキルに統合されました）

現行仕様のポイントは4つです。

• .claude/commands/deploy.md と .claude/skills/deploy/SKILL.md は、どちらも同じ /deploy を作り、同じように動く
• 既存の .claude/commands/ は今も動く（後方互換あり）。慌てて移行する必要はありません
• ただし新規に作るならSkillsが公式推奨。同梱ファイルや呼び出し制御など、Skillsにしかない機能があるため
• 同名のコマンドとスキルがある場合はスキルが優先される

統合のタイミングは2026年1月ごろのアップデートとされています。注意点として、/help や /compact のような組み込みコマンドはこの統合の対象外です。「スラッシュコマンドとSkillsは別物」という解説を見かけたら、それはカスタムコマンド統合前の古い情報だと判断してください。

5つの機能の比較表

機能	一言でいうと	読み込み
Skills	作業の手順書（ファイル同梱可）	発火時のみ本文読み込み
カスタムスラッシュコマンド	Skillsに統合済み（旧方式も後方互換で動作）	同上
CLAUDE.md	常に守るルール・前提	セッション中ずっと
サブエージェント	作業を分担する別働隊	タスク実行時
MCP	外部サービスへの接続口	接続設定に応じて

サブエージェントと組み合わせる（context: fork）

フロントマターに context: fork を書くと、そのスキルをサブエージェントとして実行できます。メインの会話を汚さずに重い作業を別働隊へ切り出せる、Claude Code独自拡張のひとつです。サブエージェントの仕組み自体はClaude Codeのサブエージェント解説で詳しく扱っています。

MCPとの使い分け

MCPは外部サービス（データベース、ブラウザ、各種SaaSなど）とClaudeをつなぐ接続の仕組み、Skillsは手順知識を渡す仕組みです。役割が違うので競合せず、たとえば「MCPでスプレッドシートに接続し、Skillsの手順書どおりに月次集計する」といった組み合わせ方になります。MCPの導入方法はClaude Code MCPの解説記事をどうぞ。

実例：ブログ運営の作業をスキル化してみた

ここからは、私自身の業務であるブログ運営を題材に、非エンジニアの実務でそのまま真似できる実例を3つ紹介します。

例1：記事のファクトチェック手順をスキル化する

私は記事公開前に必ず「断定表現の抽出→一次情報との突き合わせ」というチェックをやっています。この手順をスキルの形にすると、次のようになります。

---
name: fact-check
description: ブログ記事の公開前ファクトチェックを行う。記事中の断定表現を抽出し、公式情報と突き合わせて判定する。ユーザーが「ファクトチェックして」「公開前チェック」「事実確認して」と言ったときに使う。
---

# 記事ファクトチェックの手順

1. 対象記事から断定表現（「〜できる」「〜が必要」「月額◯円」など）をすべて抜き出して一覧にする
2. 1件ずつ、公式ドキュメント・公式サイトで根拠を確認する
3. 結果を「主張／根拠URL／判定」の3列の表で報告する

## 判定基準

- 公式一次情報で確認できた → OK
- 二次情報しか見つからない → 「〜とされています」への書き換えを提案
- 根拠が見つからない → 削除または「未検証」明記を提案
- 読者に優しく見せるための言い切りで事実が曲がっていないかも確認する

ポイントは、判定基準まで手順書に含めていることです。「チェックして」とだけ頼むと毎回基準がぶれますが、スキル化すれば確認の厳しさそのものを固定できます。士業の方の「引用条文の確認手順」、コーチの方の「クライアント名の匿名化チェック」など、公開・納品前の点検作業は何でもこの型に落とせます。

例2：特定のファイルを触った時だけ発動させる（paths）

フロントマターの paths フィールドにglobパターン（例：posts/**/*.html のような、対象ファイルを指定する書き方）を設定すると、そのパターンに合うファイルを扱っている時だけスキルが自動発火の候補になります。

私の場合なら「記事HTMLを編集している時だけ、装飾ルールのチェックスキルを候補に入れる」という使い方です。関係ない作業中に記事向けスキルが誤発火するのを構造的に防げるので、スキルが増えてきた段階で効いてきます。具体的な記法は公式リファレンス（英語版）の paths の項を確認してください。

例3：勝手に実行されたら困る作業を手動限定にする

「便利だけど、Claudeの判断で勝手に走られたら困る」作業もあります。私なら記事の公開処理、事業をされている方なら請求書の発行やメール送信の類です。これはフロントマター1行で解決します。

---
description: ブログ記事をサーバーに公開する。
disable-model-invocation: true
---

disable-model-invocation: true を付けたスキルは、Claudeが自動で呼び出すことはなくなり、自分が /スキル名 と打った時だけ動きます。自動化の便利さと「最後のボタンは人間が押す」安全性の両立ができる、実務では最重要級のフィールドです。

使う前に知っておくべきセキュリティの注意点

Skillsは強力な分、他人が作ったスキルを入れる時には注意が必要です。

「ソフトウェアをインストールするのと同じ」心構えで

公式ドキュメントは、スキルの利用を信頼できるソース（自作またはAnthropic提供）に限るよう明確に求めています。スキルは指示とコードを通じてClaudeに新しい能力を与えるため、悪意あるスキルなら、表向きの説明と違う動作をClaudeにさせることもできてしまうからです。公式の表現を借りれば「ソフトウェアをインストールするのと同じ」感覚で扱うべきものです。

また、Claude Code上のスキルは、あなたのPC上の他のプログラムと同様にネットワークへフルアクセスできる点も公式に明記されています。「ただのテキストファイルだから安全」ではありません。

配布スキルを入れる前の3つのチェック

1. SKILL.mdの中身を読む：やることが説明と一致しているか
2. scriptsフォルダの中身を読む：同梱スクリプトが何を実行するのか
3. 外部URLへのアクセスがないか見る：公式ドキュメントは、外部URLからデータを取得するスキルは取得内容に悪意ある指示が混ざりうるため特にリスクが高い、と警告しています

組織・チームで制限をかける方法

管理側の制御手段も公式に用意されています。スキル経由のシェル実行を一律禁止する disableSkillShellExecution 設定、スキル機能自体を止めたい場合は /permissions でSkillツールをdenyする方法があります。バンドルスキルをまとめて無効化する disableBundledSkills 設定（/doctor のみ残ります）もあります。

よくある失敗と注意点

最後に、運用でつまずきやすいポイントを4つ。

1つのスキルに役割を詰め込みすぎる

「ブログ作業全部入り」のような巨大スキルを作ると、descriptionが曖昧になって発火が不安定になり、読み込まれた時のトークン消費も膨らみます。実際に多数のスキルを運用している方々の報告でも、詰め込みすぎは失敗パターンの筆頭とされています。1スキル1目的で小さく分けるのが基本です。

SKILL.mdが長すぎて「軽さ」が死ぬ

公式ドキュメントには「SKILL.mdは500行以下に保ち、詳細な参考資料は別ファイルに移す」というTipが明記されています。前述のとおり、発火したスキル本文はセッション中ずっとコンテキストに残ります。手順の本体だけをSKILL.mdに書き、長大な資料はフォルダ内の別ファイルに逃がして、必要な時だけ読ませる（レベル3）構成にしましょう。

公式の日本語ドキュメントは英語版より遅れている

これは私が本記事の執筆で英語版・日本語版の公式ドキュメントを同日に突き合わせて確認した実地の話です。2026年8月7日時点で、日本語版のフロントマター一覧には英語版にある metadata・license・compatibility・background が載っておらず、プラグインスキルの名前の扱いなど、挙動の説明が英語版と食い違っている箇所もありました。仕様で迷ったら、code.claude.com/docs/en/skills（英語版）を正としてください。日本語の解説記事に古い情報が多いのも、翻訳の時差が一因だと考えられます。

claude.aiで作ったスキルはClaude Codeに出てこない

公式ドキュメントに「カスタムスキルは面をまたいで同期しない」と明記されています。claude.ai（Web版）にアップロードしたスキルはClaude Codeには現れませんし、逆も同様です。Claude CodeのスキルはあくまでPC上のファイルとして管理されます。「Webで作ったのに出てこない」は故障ではなく仕様です。

よくある質問（FAQ）

まとめ：まず1個、明日の作業をスキルにする

Skillsの上達に、たくさんのスキルを一気に作る必要はありません。昨日もやって、明日もやる作業をひとつ選び、その手順を10分でSKILL.mdにする。それが最初の一歩として最も効率が良く、効果も一番実感しやすい道です。

作ったスキルの運用に慣れてきたら、サブエージェントとの組み合わせや外部サービス連携へ進むと、自動化の幅が一段広がります。Claude Code自体をまだ導入していない方は始め方ガイドから、日々の基本操作は使い方マスターからどうぞ。