はじめに
2026年1月、Anthropicが「The Complete Guide to Building Skills for Claude」という32ページのPDFを公開しました。
スキルとは、Claudeに特定のタスクを一貫して実行させるための仕組みです。Markdownファイルをフォルダに入れるだけで、Claudeの振る舞いを変えられます。プロンプトのコピペや毎回の説明が不要になる、いわば「再利用可能なプロンプト」です。
このガイドは中身が濃いものの、32ページのPDFを英語で通読するのはなかなか骨が折れます。この記事では、ガイドの核心を要約し、実務で使うときに本当に効く部分を解説します。
対象読者
- Claude Code / Claude.ai を業務で使っている方
- 毎回同じ説明を繰り返すのが面倒な方
- MCPは知っているけど、スキルはまだ触っていない方
この記事で得られること
- スキルの設計思想と構造がわかる
- 5つの実践パターンを把握できる
- よくあるハマりどころと対処法を事前に知れる
スキルの正体：フォルダ1つで何が変わるのか
スキルの実体は驚くほどシンプルです。
your-skill-name/
├── SKILL.md # 必須。指示の本体
├── scripts/ # 任意。実行可能なコード
├── references/ # 任意。補足ドキュメント
└── assets/ # 任意。テンプレートなど
必須ファイルは SKILL.md だけ。しかもその中身はMarkdownです。プログラミング不要で、誰でも書けます。
では、たったこれだけのものがなぜ強力なのか。ガイドが示す設計思想を見てみましょう。
ガイドが教える3つの設計原則
1. プログレッシブ・ディスクロージャー（段階的開示）
スキルの読み込みは3段階で制御されます。
| レベル | 読み込み対象 | タイミング |
|---|---|---|
| 第1 | YAMLフロントマター | 常に読み込まれる |
| 第2 | SKILL.md本文 | スキルが発動したとき |
| 第3 |
references/ 内のファイル |
Claudeが必要と判断したとき |
ここが重要です。フロントマターは常にコンテキストウィンドウに存在します。つまりスキルを有効にした時点で、その分のトークンを常に消費します。一方、本文は「必要なときだけ」読み込まれます。
この仕組みがあるから、スキルを20個有効にしても実用的なのです。全スキルのフロントマターだけが常駐し、実際の指示は発動時にだけ展開される。コンテキストの節約と専門性を両立させる設計です。
裏を返せば、フロントマターが大きすぎるスキルは、他のスキルや会話を圧迫します。フロントマターは「いつ使うか」の判定情報に絞り、具体的な指示は本文に書くのがベストです。
2. コンポーザビリティ
Claudeは複数のスキルを同時に読み込めます。ガイドは「あなたのスキルが唯一の機能であることを前提としてはいけない」と明記しています。
実務では、以下のような組み合わせが自然に生まれます。
-
qiita-writing+frontend-design→ Qiita記事にインタラクティブなデモを埋め込む -
sentry-code-review+linear-tasks→ バグを検知してタスクまで自動作成
スキルは単体で完結するのではなく、組み合わせて使うものという前提で設計すべきです。
3. ポータビリティ
スキルはClaude.ai、Claude Code、APIのすべてで同じように動作します。一度作れば、どの環境でもそのまま使えます。
descriptionが9割：スキルが発動する仕組み
ガイドで最も力が入っているのが、YAMLフロントマターの description フィールドの書き方です。
---
name: your-skill-name
description: 何をするか。ユーザーが[特定のフレーズ]を求めたときに使用。
---
description はスキルの「発動条件」そのものです。Claudeはユーザーの依頼を見て、有効なスキルの description と照合し、関連度が高いスキルを自動で読み込みます。
つまり、ここの書き方がすべてを決めます。
良いdescriptionと悪いdescriptionの差
# 悪い例：曖昧すぎて何にでもマッチしうる
description: プロジェクトを支援する。
# 良い例：具体的なトリガーフレーズを含む
description: スプリント計画、タスク作成、ステータス追跡を含む
Linearプロジェクトワークフローを管理。ユーザーが「スプリント」
「Linearタスク」「プロジェクト計画」に言及したり
「チケットを作成」を求めた場合に使用。
ガイドが示す構造はシンプルです。
[何をするか] + [いつ使うか] + [主要な機能]
この3要素が揃っていれば、スキルは適切なタイミングで発動します。逆に「いつ使うか」が抜けていると、発動しなかったり、無関係な場面で発動したりします。
スキルがトリガーされない場合、本文の内容をいくら改善しても意味がありません。問題はほぼ確実に description にあります。デバッグの第一歩は、Claudeに「[スキル名]スキルはいつ使いますか？」と聞くことです。Claudeが description を引用して返すので、不足している条件がすぐわかります。
MCPとスキルの関係：キッチンとレシピ
ガイドの中で最もわかりやすいアナロジーが「キッチンとレシピ」です。
- MCP = プロのキッチン（ツール、材料、設備へのアクセス）
- スキル = レシピ（価値あるものを作るためのステップバイステップの指示）
MCPを接続しただけでは、ユーザーは「で、何ができるの？」となりがちです。スキルがあれば、構築済みのワークフローが必要なときに自動で起動します。
| MCPだけ | MCP + スキル | |
|---|---|---|
| 初回体験 | 「何をすればいいかわからない」 | ワークフローが自動で案内される |
| 結果の安定性 | ユーザーのプロンプト次第 | 一貫した品質 |
| サポート負荷 | 使い方の質問が多発 | 学習曲線が低い |
MCPを提供しているサービスにとって、スキルは「使い方のドキュメントを書く」のではなく「使い方そのものをClaude に埋め込む」行為です。
3つのスキルカテゴリ
ガイドはユースケースを3つのカテゴリに分類しています。
カテゴリ1：ドキュメント＆アセット作成
外部ツール不要で、Claudeの組み込み機能だけで完結するスキルです。
例：フロントエンドデザイン、ドキュメント生成、プレゼン作成
スタイルガイドやテンプレートを埋め込み、一貫した出力品質を保証します。最も手軽に始められるカテゴリです。
カテゴリ2：ワークフロー自動化
マルチステッププロセスを一貫した方法論で実行するスキルです。
例：skill-creator（スキル自体を作るスキル）、スプリント計画
バリデーションゲートや改善ループを含み、手順を標準化します。
カテゴリ3：MCP強化
MCPサーバーが提供するツールアクセスに、ワークフローの知識を上乗せするスキルです。
例：Sentryのエラーデータを使ってPRのバグを自動修正するスキル
複数のMCP呼び出しを正しい順序で連携させ、ドメイン専門知識を埋め込みます。
初めてスキルを作る場合、カテゴリ1から始めるのがおすすめです。外部依存がなく、SKILL.md 1ファイルだけで完結するため、設計→テスト→改善のサイクルが最も速く回せます。
5つの実践パターン
ガイドの第5章では、実際に効果があった5つのパターンが紹介されています。それぞれの「使いどころ」を整理します。
パターン1：シーケンシャルワークフロー
使うとき： 手順に順序があり、前のステップの結果を次で使う場合
例：顧客オンボーディング（アカウント作成 → 支払い設定 → サブスクリプション → ウェルカムメール）
ポイントは、各ステップにバリデーションを入れること。そして失敗時のロールバック指示を明記すること。「Step 2で失敗したらStep 1の結果をどうするか」まで書いておくと、実運用で壊れにくくなります。
パターン2：マルチMCPコーディネーション
使うとき： 1つのワークフローが複数のサービスをまたぐ場合
例：デザインハンドオフ（Figma → Drive → Linear → Slack）
フェーズを明確に分け、フェーズ間でデータを受け渡す設計にします。「Phase 1の出力がPhase 2の入力になる」という依存関係を明示します。
パターン3：反復的改良
使うとき： 一発で完璧な出力が難しく、イテレーションで品質を上げたい場合
例：レポート生成（ドラフト → 品質チェック → 改良 → 再チェック → 最終化）
バリデーションスクリプトを scripts/ に用意し、品質チェックをプログラムで行うのが効果的です。言語による指示は解釈のブレがありますが、コードは決定論的です。
パターン4：コンテキスト対応のツール選択
使うとき： 同じ目的でも状況によって最適な手段が変わる場合
例：ファイル保存（大きいファイル → クラウドストレージ、コード → GitHub、一時ファイル → ローカル）
判断ツリーを明示し、なぜその選択をしたかをユーザーに説明する設計にします。
パターン5：ドメイン固有のインテリジェンス
使うとき： ツールアクセス以上の専門知識が価値を持つ場合
例：コンプライアンス付き決済処理（制裁リストチェック → 管轄区域検証 → リスク評価 → 処理 → 監査証跡）
ドメインルールをスキルに埋め込むことで、「ツールを呼ぶ」だけでなく「正しい順序で正しい判断をしてからツールを呼ぶ」動作を実現します。
よくあるハマりどころと対処法
ガイドのトラブルシューティングから、特に遭遇しやすい問題を抜粋します。
スキルがトリガーされない
最もよくある問題です。原因はほぼ description にあります。
チェックリスト：
-
descriptionが一般的すぎないか（「プロジェクトを支援する」ではトリガーされない） - ユーザーが実際に言いそうなフレーズを含んでいるか
- 関連するファイルタイプに言及しているか
デバッグ方法： Claudeに「[スキル名]スキルはいつ使いますか？」と聞く。
スキルが頻繁にトリガーされすぎる
意図しない場面でスキルが発動する問題です。
対処法： ネガティブトリガー（「～には使用しない」）を description に追加する。
description: CSVファイルの高度なデータ分析。統計モデリング、回帰、クラスタリングに使用。
単純なデータ探索には使用しない（data-vizスキルを使用）。
指示が守られない
スキルは読み込まれているのに、Claudeが指示通りに動かない場合。
よくある原因：
- 指示が冗長すぎる → 箇条書きにして簡潔にする
- 重要な指示が埋もれている → 先頭に配置する
- 曖昧な表現 → 「適切にバリデーションすること」ではなく、具体的な条件を列挙する
ガイドの上級テクニックとして紹介されているのが、重要なバリデーションはスクリプトにするというアプローチです。scripts/ にPythonやBashを置いて、プログラムでチェックさせます。「言語の解釈は不確実だが、コードは決定論的」という考え方です。
コンテキストが大きすぎて遅い
対処法：
- SKILL.md本文を5,000語以下に抑える
- 詳細なドキュメントは
references/に分離する - 20～50以上のスキルを同時有効にしていないか確認する
テストの考え方
ガイドはテストを3段階に分けています。
| テストの種類 | 目的 | 方法 |
|---|---|---|
| トリガーテスト | 適切なタイミングで発動するか | 10～20のテストクエリを実行し、発動率を確認 |
| 機能テスト | 正しい出力を生成するか | 同じタスクを3～5回実行し、一貫性を確認 |
| パフォーマンス比較 | スキルありで改善されるか | スキルなしとの比較（やり取り回数、エラー率、トークン消費量） |
特に実用的なのが「パフォーマンス比較」の視点です。ガイドの例では、スキルなしで15回のやり取り・3回のAPIエラー・12,000トークンかかっていたタスクが、スキルありで確認2回・エラー0回・6,000トークンに改善されています。
ガイドは「まず1つの難しいタスクでイテレーションし、成功したアプローチをスキルに抽出する」ことを推奨しています。最初から完璧なスキルを設計しようとするのではなく、実際の会話で成功パターンを見つけてからスキル化する方が速いです。
配布とオープンスタンダード
スキルは「エージェントスキル」としてオープンスタンダード化されています。MCPと同様、特定のプラットフォームに縛られない設計です。
現時点での配布方法は主に2つです。
- Claude.ai → 設定 > 機能 > スキル からZIPでアップロード
-
Claude Code →
~/.claude/skills/にフォルダを配置
組織向けには、管理者がワークスペース全体にスキルをデプロイする機能も提供されています。
APIからのスキル利用も可能で、/v1/skills エンドポイントと Messages APIの container.skills パラメータを使ったプログラマティックな制御ができます。
まとめ：スキルは「再利用可能なプロンプト」以上のもの
ガイドを通して見えてくるのは、スキルが単なる「プロンプトの保存」ではないということです。
- 段階的開示でコンテキストを効率的に使い
- descriptionで発動タイミングを制御し
- **references/**で必要なときだけ知識を展開し
- **scripts/**でバリデーションを決定論的に行う
この設計があるから、スキルは「毎回同じことを説明する手間を省く」だけでなく、「Claudeの判断と出力品質を構造的に底上げする」仕組みとして機能します。
まずは自分の業務で「毎回Claudeに同じことを説明している部分」を1つ見つけて、スキルにしてみてください。15～30分で最初のスキルが動きます。