Claude Skills（SKILL.md）入門｜Pro月20ドルでClaude.aiブラウザから始める3層構造の最短手順

この記事の結論

Claude SkillsはAnthropicが2025年10月16日に発表した「SKILL.md 1枚で同じ依頼の手順を永続化する仕組み」
Simon Willisonは公開当日に「awesome, maybe a bigger deal than MCP」と評価。OpenAIも2025年12月に同一仕様を採用
非エンジニアがProプラン（月20ドル）でClaude.aiブラウザから始める最短ルートは Settings → Capabilities → Skills のZIPアップロード

「いつもの依頼を毎回プロンプトに貼る生活」を、
SKILL.mdというテキスト1枚で終わらせる仕組みが半年前から動いています。
Anthropic公式ブログ（2025年10月16日）の言葉を借りれば「Skills are folders that include instructions, scripts, and resources.」と素っ気ないんですが、
Simon Willisonの評価はもっと直球です。
「Claude Skills are awesome, maybe a bigger deal than MCP」。
これは個人的にも納得感がありました。

この記事ではAnthropic公式ドキュメント、
GitHub anthropics/skills（スター12万超）、
Simon Willison、
やまと氏（21個運用）といった一次ソースから引用ベースで仕組みを整理していきます。
狙う読者像はProプランを契約済みでClaude.aiブラウザを中心に使う非エンジニアの方。
Claude Code前提のディープな運用ノウハウは扱いません。

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.

出典: claude.com/blog/skills

プラットフォームドキュメント（platform.claude.com）の説明はもう一段踏み込んでいます。

プロンプト（1回限りのタスク用の会話レベルの指示）とは異なり、
Skillsはオンデマンドで読み込まれ、
複数の会話にわたって同じガイダンスを繰り返し提供する必要がなくなります。

出典: platform.claude.com Agent Skills overview

つまりSkillsの本質は「再利用可能なファイルシステム上のリソース」と言えます。
フォルダにSKILL.mdというMarkdownファイルを置いて、
その先頭にYAMLで name と description を書く。
それだけで成立するんですね。
シンプルすぎて拍子抜けしました。

なぜ注目されているのか（Simon Willisonの評価とOpenAI採用）

Simon Willisonは公開当日（2025年10月16日）の記事タイトルで「Claude Skills are awesome, maybe a bigger deal than MCP」と書きました。
MCP（Model Context Protocol）と比較しての論点はこう整理されています。

MCP requires "a whole protocol specification" covering "hosts, clients, servers, resources, prompts, tools, sampling, roots, elicitation and three different transports."

（一方Skillsは）Markdown with a tiny bit of YAML metadata and some optional scripts.

出典: Simon Willison's Weblog

仕様の薄さが利点だ、
という主張ですね。
MCPがプロトコル仕様で武装するのに対して、
SkillsはMarkdown + YAMLという既存資産で押し切ってきました。
Simon Willisonの言葉を借りるとこうなります。

Skills feel a lot closer to the spirit of LLMs—throw in some text and let the model figure it out.

出典: 同上

テキストを置いてモデルに任せる。
ここがLLMの設計思想と整合していると読めますね。
個人的にはこの「投げ込み式」の発想がOpenAIにも刺さったのは納得でした。

The Decoderの2025年12月報道によれば、
OpenAIはAnthropicのSkills仕様をChatGPTおよびCodex CLIに「同一ファイル命名規則・同一メタデータ形式・同一ディレクトリ構成」で採用したそうです（出典: The Decoder）。
MCPがオープンスタンダード化された後の業界採用パターンと同じ流れに見えます。
Anthropic公式は2025年12月18日に agentskills.io として仕様を公開済みです。

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/ のバンドルファイル

Simon Willisonが評価しているのもまさにこの仕組みなんですね。

Each skill only takes up a few dozen extra tokens, with the full details only loaded in should the user request a task that the skill can help solve.

出典: Simon Willison's Weblog

常駐コストは100トークン程度で済んでいます。
本体の5,000トークン未満は呼ばれた時だけ読まれる。
これがあるからスキルを大量に積んでもコンテキストが圧迫されないんですね。

Pro契約者がClaude.aiブラウザだけで始める最短手順

公式ヘルプ（support.claude.com）に明記されている経路はこうなっています。

Settings → Capabilities でコード実行を有効化
Customize → Skills を開く
SKILL.md を含むフォルダをZIP圧縮してアップロード

個人的にはここで詰まる読み手が多そうだと感じました。
「ZIPって何を入れる？」「フォルダ構造は？」がドキュメントだとサラッと書かれているだけだからです。
最小構成は skill-name/SKILL.md の1枚だけでも動くと、
公式skill-creator SKILL.mdが示しています。

具体的にもう少し細かく書くと、
Windowsならメモ帳でSKILL.mdを作って、
それを「skill-name」というフォルダに入れて、
フォルダごと右クリック→「ZIPに圧縮」、
出来たZIPをCustomize → Skillsの画面でアップロード、
という流れになります。
Macも同じです。
SKILL.mdの中身は次の見出しで触れる最小フロントマター3行＋本文1〜2段落で十分動きます。

公式ドキュメントには重要な制約も書かれています。

カスタムSkillsは各ユーザーに個別であり、
組織全体で共有されず、
管理者によって一元管理することはできません。

出典: Claude.ai サポート

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?"
---

出典: platform.claude.com

必須項目は name（最大64文字、
小文字・数字・ハイフンのみ）と description（最大1024文字、
ただしスキルリスト表示は250文字キャップ）の2つだけ。
たった2項目で動くのが正直驚きでした。

やまと氏（Zennで21個運用記事を公開）の助言が現実的でいいんですね。

完璧を目指すと挫折します。
最初はnameとdescriptionだけのシンプルなSKILL.mdで十分。

出典: Zenn やまと氏「Claude Code Skillの作り方」

呼ばれないスキル問題（descriptionの書き方）

Skillsで一番ハマるのが「書いたのに呼ばれない」現象だと思います。
Ivan Seleznovが650試験で測った数字が衝撃的でした。

デフォルトのdescriptionスタイルでは「activated about 77% of the time」。
ディレクティブスタイルでは「achieved 100%」。
統計的有意差: Cochran-Mantel-Haenszel odds ratio = 20.6, p < 0.0001

出典: Ivan Seleznov（Medium）

23ポイントも開きが出ました。
書き方ひとつで起動率がここまで動くのは正直怖いですね。
コミュニティスキルの2026年監査では「214本中73%が60点未満」と報告されています（出典: buildtolaunch.substack.com）。
これは深刻だと思います。

公式ドキュメントが推奨する書き方はシンプルにまとめられています。

descriptionには、
Skillが何をするか、
およびClaudeがいつそれを使用すべきかの両方を含める必要があります。
主要なユースケースを前置きしてください。

出典: platform.claude.com

「何をするか」と「いつ使うか」の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文字以内に詰めるのが大事なんですね。
これがdescription設計の核だと思います。

Skillsが呼ばれた後に失敗する「2つ目」の問題

Marc Bara（Medium）の指摘が鋭いんですね。
信頼性問題は1つではなく2種類あるんだと書いています。

Activation Failure（スキルが全く呼ばれない）と Execution Failure（スキルは読み込まれるが中のステップを飛ばす）の2種類。

Execution Failureは dangerous failure mode because it's invisible—an execution failure produces output that appears to have followed the process.

出典: Marc Bara（Medium）

呼ばれたのに中身を飛ばされてしまう。
しかも「飛ばされたことが見えない」のが厄介なんですね。
Paddo.devも同様の論点を整理しています。

Skills lack critical controls including explicit invocation flags, prevention controls to block auto-invocation, context visibility, invocation logging, and debugging capabilities, because skills use LLM reasoning for invocation which is inherently non-deterministic.

出典: Paddo.dev

呼び出しがLLM推論ベースなので本質的に非決定的だと指摘しています。
これは設計トレードオフの話で、
解決は使う側の運用に寄せる必要がありそうですね。
GIZIN社（27人のAI社員運用）の経験談がリアルです。

気づいたら50個以上のSKILLができていました。
そして、
うまくいかなくなりました。
見つけられないSKILLは、
存在しないのと同じです。

出典: GIZIN

50個超えると破綻するんですね。これは現場の数字として重く受け止めたいです。

無料/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」と明記される。

出典: support.claude.com / claude.com/pricing

個人的には現時点でこの2つの記述が公式内で食い違っているという事実を、
そのまま読み取っておくのが筋だと思います。
一方は「Free含む全プラン対応」、
もう一方は「ProでSkillsが付与される」と読める書き方になっていて、
どちらが最新なのかは公式から明確なアナウンスが出ていません。
Free運用を考える方は、
support.claude.com側の記載を根拠に試すのが現実的なルートですし、
料金ページの記載を重く見る方はProから入るのが安心、
と判断材料を分けて見ておきたいですね。

Anthropic既製スキルはPowerPoint・Excel・Word・PDFの4種が「すべてのユーザー向けで自動的に起動」と公式ブログに書かれています。
Boxは「ユーザーは保存ファイルをPowerPointやExcelに変換できる」と評価していて、
Rakutenは「What once took a day, we can now accomplish in an hour」とコメントしています（出典: claude.com/blog/skills）。
1日が1時間に短縮されたとの事例で、
これは大きいと思いました。

外部スキルを入れる時のセキュリティ確認はどうするか

公式ドキュメントの警告がはっきりしています。

信頼できないまたは未知のソースからのSkillsを使用する必要がある場合は、
極度の注意を払い、
使用前に徹底的に監査してください。
悪意のあるSkillsはデータ流出、
不正なシステムアクセス、
またはその他のセキュリティリスクにつながる可能性があります。

Skillsを「ソフトウェアのインストールのように扱う」

出典: platform.claude.com

「ソフトウェアのインストールのように扱う」という比喩は重いですね。
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）」も覚えておきたいです。
マルウェアや「説明と一致しない動作」を含まないことが判定基準になります（出典: 公式skill-creator SKILL.md）。
description通りに動くか、
を中身確認の主軸に置いてください。

Skillsを書くこと自体が「業務棚卸し」になる

仕組み解説の記事は多いんですが、
ここはあまり言語化されていない論点だと思います。
SKILL.mdを書く作業は、
私の依頼パターンを言語化して標準手順書（SOP）に落とす作業と構造が同じなんですね。

すぅ氏（AI駆動PM）のnote記事はこの感覚に近いです。

普通に話しかけるだけでAIが適切なスキルを判断して発動する仕組みは「かなり便利」

プロンプトと比較してSkillsは「ほぼ間違いが起きません」

出典: note すぅ氏

「ほぼ間違いが起きない」が言えるのは、
書く側の指示が文章として固定されているからなんですね。
プロンプトを毎回書くと毎回ニュアンスがズレる。
SKILL.mdに固定すれば、
その手順は二度ゆらがないわけです。
私はここがSkillsの一番おいしい部分だと考えていて、
個人で繰り返してる業務にこそ効きます。

やまと氏の表現を借りるとこうなります。

Skillは「自分専用のClaude Code」を育てることに近いと感じています。
最初はぎこちない指示しかできなかったClaude Codeが、
Skillを入れることで「こういうことね」と察してくれるようになる。

出典: Zenn やまと氏

育てる、
という言い方がしっくりきますね。
プロンプトの蓄積を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公式内に齟齬が残っている状態なので、
支援ヘルプの記述を信じて試すか、
料金ページの記述を信じて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が呼ばれない時はどうすればいいですか

Ivan Seleznovの650試験データによると、
descriptionをディレクティブスタイル（「ALWAYS invoke this skill when...」型）に書き換えるだけで起動率が77%から100%に上昇しました。
動詞・名詞・ユーザー発話語句を含めること、
Use when句を入れることが基本です。

Q. 公式以外のスキルを入れる時の注意点は

公式ドキュメントは「ソフトウェアのインストールのように扱う」と警告しています。
①バンドルファイル全目視確認 ②外部URL呼び出しコード確認 ③GitHub最終更新日とIssue確認、
の3ステップを推奨します。
中身読解はClaude本体に「危険コードがないか確認して」と頼むのが現実的です。