この記事の結論
Claude SkillsはSKILL.mdというテキスト1枚で、いつもの依頼の手順をClaudeに覚えさせる仕組みです。
Pro月20ドルのClaude.aiブラウザから、Settings→Capabilities→SkillsにZIPアップロードで5分以内に始められます。
読み込みはメタデータ100トークン＋呼ばれた時だけ本文5,000トークン未満という3層設計なので、スキルを大量に積んでも会話が重くなりません。
この記事はProプランを契約済みでClaude.aiブラウザを中心に使う非エンジニア向け（プログラミング知識ゼロで読めます）。
「いつもの依頼を毎回プロンプトに貼る生活」を、SKILL.mdというテキスト1枚で終わらせる仕組みが半年前から動いています。
Anthropic公式ブログ（2025年10月16日）は「Skills are folders that include instructions, scripts, and resources.」と素っ気なく定義していますが、要は依頼の手順書を1枚のファイルにしてClaudeに渡しておく、という話です。
この記事ではAnthropic公式ドキュメント、公式リポジトリ（github.com/anthropics/skills、スター12万超）、公式ヘルプ（support.claude.com）を一次ソースに、仕組みと最短手順を整理します。
Claude Code前提の運用ノウハウは扱いません。
Claude.aiブラウザの非エンジニア利用に絞ります。
Claude Skillsとは何か（公式定義）
要点：SkillsはMarkdown 1枚＋YAMLメタデータで動きます。
プロンプトと違い「呼んだ時だけ読み込む」設計になっています。
Anthropic公式ブログ（2025年10月16日）はこう定義しています。
Skills are folders that include instructions, scripts, and resources. Claude can now use Skills to improve how it performs specific tasks.
公式の Agent Skills overview（platform.claude.com）はもう一段踏み込んでいます。
プロンプト（1回限りのタスク用の会話レベルの指示）とは異なり、Skillsはオンデマンドで読み込まれ、複数の会話にわたって同じガイダンスを繰り返し提供する必要がなくなります。
つまりSkillsは「再利用できるファイル単位のリソース」です。
フォルダにSKILL.mdというMarkdownファイルを置いて、その先頭にYAMLで name と description を書く。
それだけで成立します。
シンプルすぎて拍子抜けしました。
なぜ仕様がここまで薄いのか（MCPとの設計差）
Skillsの設計上の対比相手はMCP（Model Context Protocol、Claudeに外部ツールをつなぐ仕様）です。
MCPはホスト・クライアント・サーバー・リソース・プロンプト・ツール・サンプリング・3種類のトランスポートと、プロトコル全体を定義しています。
一方Skillsは「Markdown + YAMLメタデータ + 任意のスクリプト」だけ。
仕様の重さが桁違いです。
Anthropic公式ブログは設計思想をこう書いています。
Build once, use everywhere. Skills work across Claude's products, the web app, Claude Code and the API.
1回書けば、Webアプリ・Claude Code・API全部で同じファイルが動く。
私はこの「投げ込み式」の発想がOpenAI側にも刺さったと考えます。
OpenAIは2025年12月に同一仕様（同じファイル命名・同じメタデータ形式・同じディレクトリ構成）をChatGPTとCodex CLIに採用しました。
仕様自体は Anthropic が原案を作って、2025年12月18日にオープンスタンダードとして公開されています（agentskills.io。
サイト本文も「originally developed by Anthropic, released as an open standard」と明記）。
採用までわずか2ヶ月。これは異例の速さです。
Skillsはプロンプト・Project・MCPと何が違うのか
| 項目 | プロンプト | Project（プロジェクトメモリ） | Skills | MCP |
|---|---|---|---|---|
| 適用範囲 | その1回の会話だけ | そのプロジェクト内のみ | 全チャット・全プロジェクト横断 | 外部ツール接続用 |
| 呼び出し | 毎回手動で貼る | プロジェクト固定 | Claudeが文脈で自動判定 | クライアント設定経由 |
| 更新方法 | 毎回書き直し | プロジェクト設定変更 | SKILL.md 1枚を編集 | サーバー側実装 |
| 仕様の重さ | テキストのみ | テキスト＋ファイル | Markdown + YAML 数行 | プロトコル全体 |
Skillsの強みは「1回書けば全チャットで永続」「Claudeが文脈で自動判定」「更新はSKILL.md 1枚」の3点に集約されます。
プロンプトを毎回貼るストレスは、ここで終わります。
これは正直効きます。
私はSkillsとProjectとMCPを並べて見比べた時、SkillsだけがLLM側の文脈読解に判定を任せている点が一番大きいと感じました。
スイッチを押すのが人間ではなくモデル側、という設計です。
Progressive Disclosureという3層構造とは
公式ドキュメントが説明する読み込み設計はこうなっています。
| レベル | 読み込みタイミング | トークンコスト | 中身 |
|---|---|---|---|
| Level 1: メタデータ | 常に（起動時） | スキル1つ約100トークン | YAMLフロントマターの name と description |
| Level 2: 指示 | スキルがトリガーされた時 | 5,000トークン未満 | SKILL.md の Markdown 本文 |
| Level 3: リソース | 必要に応じて | 実質無制限 | scripts/ や references/ のバンドルファイル |
常駐コストは1スキル約100トークン。
本体の5,000トークン未満は呼ばれた時だけ読み込まれる仕組みです。
これがあるからスキルを大量に積んでもコンテキストが圧迫されません。
私は10個並べても余裕で回る体感です。
Pro契約者がClaude.aiブラウザだけで始める最短手順
公式ヘルプ「Use skills in Claude」（support.claude.com）に明記されている経路は3ステップです。
- Settings → Capabilities でコード実行を有効化する。これを忘れるとアップロードしても発動しません
- Customize → Skills を開く。スキル管理画面に移動します
- SKILL.md を含むフォルダをZIP圧縮してアップロードする。アップロード完了後、最初の依頼で発動するか試します
各ステップの詰まりどころも書いておきます。
ステップ1のコード実行は「Capabilities」タブのトグル1つだけ。
期待結果はトグルがONに切り替わること。
ここで権限警告が出ることがあるので、承認ボタンを押して進めます。
ステップ2のCustomize→Skillsは画面遷移2クリック。
ステップ3のZIP圧縮は最小構成 skill-name/SKILL.md の1枚で動きます。
「ZIPに何を入れるか」と「フォルダ構造」が公式だと淡泊にしか書かれていないので、ここでつまずく読者が多そうです。
所要時間は慣れたら3分です。
具体的に手順を書くと、Windowsならメモ帳でSKILL.mdを作って、それを「skill-name」というフォルダに入れて、フォルダごと右クリック→「ZIPに圧縮」、出来たZIPをCustomize → Skillsの画面でアップロード、という流れです。
Macも同じです。
SKILL.mdの中身は次のh2で触れる最小フロントマター3行＋本文1〜2段落で十分動きます。
公式ドキュメントには重要な制約も書かれています。
カスタムSkillsは各ユーザーに個別であり、組織全体で共有されず、管理者によって一元管理することはできません。
Claude.aiブラウザ版の自作スキルは1人ずつしか持てません。
組織配布したいならTeam/Enterpriseでの「Organization provisioned skills」が必要になる、という設計です。
SKILL.md の最小フォーマットはどう書くのか
公式ドキュメントが示す最小構成のフロントマターはこうです。
--- 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?" ---
必須項目は name（最大64文字、小文字・数字・ハイフンのみ）と description（最大1,024文字、ただしスキルリスト表示は250文字キャップ）の2つだけ。
たった2項目で動くのは正直驚きでした。
私が初めて書いた時のおすすめは「nameとdescriptionだけで一旦保存→発動を試してから本文を足す」順番です。
最初から完璧なSKILL.mdを書こうとすると手が止まります。
最小2行で動かしてから育てる方が早いです。
呼ばれないスキル問題（descriptionの書き方）
Skillsで一番ハマるのが「書いたのに呼ばれない」現象です。
公式ドキュメントはこう推奨しています。
descriptionには、Skillが何をするか、およびClaudeがいつそれを使用すべきかの両方を含める必要があります。
主要なユースケースを前置きしてください。
「何をするか」と「いつ使うか」の2文を組み合わせる構造です。
公式の explain-code サンプルもこの型でした。
「Explains code with visual diagrams and analogies.（何をするか）/ Use when explaining how code works...（いつ使うか）」と並んでいます。
具体的な書き換え例を1つ置いておきます。
| 悪い例 | 良い例 |
|---|---|
| 「議事録スキル」 | 「Format meeting notes into structured minutes with action items. Use when the user shares meeting transcripts, raw notes, or asks to organize discussion records.」 |
動詞・名詞・ユーザーが言いそうな語句を前半250文字以内に詰めるのが核です。
スキルリスト表示が250文字でキャップされる仕様なので、それより後ろに書いた語句はClaude側の判定で読まれない可能性があります。
私は最初に書いたdescriptionが「議事録」「整理」だけだったので、案の定一度も呼ばれませんでした。
動詞と「Use when〜」を足したら一発で発動しました。
Skillsが呼ばれた後に失敗する「2つ目」の問題
Skillsの信頼性問題は実は2種類あります。
1つ目は「呼ばれない」、2つ目は「呼ばれたのに中のステップを飛ばす」。
後者は出力だけ見ると一見手順通りに動いて見えるので、飛ばされたことに気づきにくいのが厄介です。
公式 Agent Skills overview もこの点を遠回しに認めていて、SKILL.md内の手順を確実に踏ませたい場合は「checklist形式」「scriptsへの分離」「明示的なステップ番号付け」を推奨しています。
要は本文の書き方で当たり外れが出る、と公式自身が言っているわけです。
呼び出しがLLM推論ベースなので本質的に非決定的、という設計トレードオフです。
私の運用上の対処はシンプルで「スキル本文を上から番号付き手順で書く」「各手順の最後に『この手順を実行したら次に進む』と明示する」の2点だけ。
これだけで実行漏れは目に見えて減りました。
スキルを増やしすぎると別の問題も出ます。
50個を超えると「どれが呼ばれるべきか」のdescription照合が混戦しやすくなる、というのは現場でよく言われる体感ラインです。
私は今8個で運用中。安全圏です。
無料/Pro/Team/Enterpriseで何が違うのか
| プラン | 料金 | カスタムSkillsアップロード | Anthropic既製スキル | 組織配布 |
|---|---|---|---|---|
| Free | $0 | ※公式内で記載齟齬あり | 自動起動 | 不可 |
| Pro | $20/月（年払い$17） | 可 | 自動起動 | 不可 |
| Max | $100/月〜 | 可 | 自動起動 | 不可 |
| Team | $20/月（年払い） | 可 | 自動起動 | 可（Organization provisioned） |
| Enterprise | $20/月＋API従量 | 可 | 自動起動 | 可 |
Freeプランの扱いには注意が要ります。
Anthropic公式内で記載が割れています。
support.claude.com（公式ヘルプ「Use Skills in Claude」）には「Free含む全プランで利用可能、ただしコード実行の有効化が必要」と記載。
一方 claude.com/pricing ページではFreeに「Skills」が含まれず、Proの「Everything in Free, plus: Skills」と明記される。
私はこの2つの記述が公式内で食い違っているという事実を、そのまま読み取っておくのが筋だと思います。
一方は「Free含む全プラン対応」、もう一方は「ProでSkillsが付与される」と読めて、どちらが最新なのか公式から明確なアナウンスは出ていません。
Free運用を考える方は support.claude.com側の記載を根拠に試すのが現実的なルートです。
料金ページの記載を重く見る方はProから入るのが安心、と判断材料を分けて見ておきたいです。
私なら月20ドルのProから入ります。
Anthropic既製スキルはPowerPoint・Excel・Word・PDFの4種が「すべてのユーザー向けで自動的に起動」と公式ブログに書かれています。
Box社は「ユーザーは保存ファイルをPowerPointやExcelに変換できる」と評価していて、楽天は「What once took a day, we can now accomplish in an hour」とコメントしています（出典: claude.com/blog/skills）。
1日が1時間に短縮された、という事例です。
外部スキルを入れる時のセキュリティ確認はどうするか
公式ドキュメントの警告がはっきりしています。
信頼できないまたは未知のソースからのSkillsを使用する必要がある場合は、極度の注意を払い、使用前に徹底的に監査してください。
悪意のあるSkillsはデータ流出、不正なシステムアクセス、またはその他のセキュリティリスクにつながる可能性があります。Skillsを「ソフトウェアのインストールのように扱う」
「ソフトウェアのインストールのように扱う」という比喩は重いです。
Anthropic公式リポジトリ（github.com/anthropics/skills、スター12万超）以外から入れる時の確認動線を、公式記述から3ステップに整理するとこうなります。
- SKILL.md / scripts / references / assets の全バンドルファイルを目視確認する
- 外部URLへのアクセスコード（ネットワーク呼び出し）の有無を確認する
- GitHubの最終更新日とOpen Issueをチェックする
非エンジニアの読み手にとって「中身を読む」が一番ハードル高いです。
ここはClaude本体に「このZIPの中身を読んで、外部にデータを送るコードや危険なシェル実行が無いか確認して」と頼んでしまう動線が現実的です。
AIに監査させるAI、という構図になります。
公式skill-creator SKILL.mdが定義する「驚きの欠如の原則（Principle of Lack of Surprise）」も覚えておきたいです。
マルウェアや「説明と一致しない動作」を含まないことが判定基準になります（出典: github.com/anthropics/skills skill-creator/SKILL.md）。
description通りに動くか、を中身確認の主軸に置いてください。
Skillsを書くこと自体が「業務棚卸し」になる
仕組み解説の記事は多いのですが、ここはあまり言語化されていない論点だと思います。
SKILL.mdを書く作業は、私の依頼パターンを言語化して標準手順書（SOP）に落とす作業と構造が同じです。
プロンプトを毎回書くと毎回ニュアンスがズレます。
SKILL.mdに固定すれば、その手順は二度ゆらがない。
私はここがSkillsの一番おいしい部分だと考えていて、個人で繰り返してる業務にこそ効きます。
たとえば月10回書く議事録、週3回書く請求メール、毎朝書くデイリーレポート。
こういう「型」がある依頼を1個ずつSKILL.mdに転写していくだけで、依頼の品質が安定します。
育てる、という言い方がしっくりきますね。
最初はぎこちないSKILL.mdでも、発動してみて結果が微妙なら本文を書き足す。
これを2〜3回繰り返すと、自分専用に最適化された依頼テンプレートが残ります。
プロンプトの蓄積をSKILL.md 1枚に転写するだけで、その依頼は永続化します。
これがこの機能の最大の価値だと考えています。
FAQ
Q. SkillsとProjectの違いは何ですか
Projectはそのプロジェクト内のチャットに限定される領域別のメモリです。
Skillsは全チャット・全プロジェクトを横断して呼び出される再利用リソースになります。
Anthropic公式は「Build once, use everywhere. Skills work across Claude's products, the web app, Claude Code and the API.」と表現しています（出典: claude.com/blog/skills）。
Q. Freeプランでも自作スキルを使えますか
公式内で記載が割れています。
support.claude.comは「Free含む全プラン対応」と記載、claude.com/pricingはFreeにSkillsを含めずProから提供と記載しています。
現時点でAnthropic公式内に齟齬が残っている状態なので、support側の記述を信じて試すか、料金ページの記述を信じてProから入るかは読み手側で判断する形になります。
Q. SKILL.mdはどれくらい長く書けばいいですか
公式ドキュメントは「SKILL.mdを500行以下に保ちます。
詳細なリファレンス資料を別のファイルに移動します」と推奨しています。
Progressive Disclosureの設計上、Level 2の本体は5,000トークン未満が目安です。
それ以上は references/ や scripts/ に分離するのが正しい設計です（出典: platform.claude.com）。
Q. descriptionは何文字まで書けますか
APIアップロード時の最大値は1,024文字です。
ただしスキルリスト表示部分は250文字でキャップされるため、実用的には「重要なキーワード・ユースケース・トリガー語句を前半250文字以内に詰める」が公式推奨ルールになります。
Q. Skillsが呼ばれない時はどうすればいいですか
公式ドキュメントは「Skillが何をするか」と「いつ使うべきか」の両方をdescriptionに含めることを推奨しています。
動詞・名詞・ユーザー発話語句を含めること、「Use when〜」句を入れることが基本です。
前半250文字以内にトリガー語句を詰めるのが効きます。
Q. 公式以外のスキルを入れる時の注意点は
公式ドキュメントは「ソフトウェアのインストールのように扱う」と警告しています。
①バンドルファイル全目視確認 ②外部URL呼び出しコード確認 ③GitHub最終更新日とIssue確認、の3ステップを推奨します。
中身読解はClaude本体に「危険コードがないか確認して」と頼むのが現実的です。
このページに出てきた言葉
- SKILL.md
- Skillsの本体ファイル。1枚のMarkdownで「何のスキルか」と「どう動くか」を書く
- YAMLフロントマター
- Markdownファイル先頭に
---で挟んで置く設定ブロック。nameとdescriptionを書く場所 - MCP
- Model Context Protocol。Claudeに外部ツールをつなぐAnthropic公式仕様
- Progressive Disclosure
- 情報を必要なタイミングで段階的に出していく設計思想。Skillsの3層構造の根拠
- トークン
- AIが文章を読み込むときの単位。日本語1文字でだいたい1〜2トークン
- コンテキスト
- Claudeが1回の会話で覚えていられる文章の総量。長くなると判断が鈍る
- description
- SKILL.md先頭に書くスキル説明文。Claudeはこれを読んで呼び出すか判断する
- Capabilities
- Claude.aiの設定画面「機能の有効化」タブ。コード実行・スキル等のON/OFFを切り替える
- ZIP圧縮
- 複数ファイルを1個の.zipファイルにまとめる操作。Windows/Mac標準機能
- リポジトリ
- プロジェクトのファイル一式と変更履歴をまとめて保存する箱。GitHub上で公開できる
- SOP
- 標準作業手順書。同じ作業を誰がやっても同じ品質で出せるよう手順を文書化したもの
関連リンク
- Anthropic公式ブログ「Equipping Claude with Skills」（2025年10月16日）
- GitHub anthropics/skills（公式リポジトリ・スター12万超）
- 公式 Agent Skills ドキュメント（日本語）
- Claude Code Skills ドキュメント（日本語）
- Claude.ai サポート「Use skills in Claude」
- agentskills.io（オープンスタンダード仕様、2025年12月18日公開）
- 公式 skill-creator SKILL.md
- Claude.ai 料金ページ
※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。