AI に携わる人なら誰でも、こんな問題に直面したことがあるでしょう。
何かを教えても、翌日新しい会話を始めると、すべてがリセットされてしまう。
ワークフローの調整に 3 日間費やし、Claude と何度もやりとりしてようやく完成させても、次の日にはまた最初から説明しなければならない。
メモにプロンプトを保存して毎回貼り付けているが、500 文字の指示を毎日 1 ヶ月も貼り続けていると、ふと考えてしまう。「これが本当に AI の正しい使い方なのか？」と。
そんな問題を解決するために生まれたのが、スキルです。
スキルは Anthropic が 2025 年 10 月にリリースし、12 月にオープンスタンダードとなりました。
現在、インターネット上では「スキルが生産性を変える」と叫ばれていますが、ほとんどの人はその言葉を聞いたことがあるだけで、スキル、プロンプト、ナレッジベース、MCP、エージェントの違いを本当に理解しているわけではありません。ましてや、自分でスキルを構築するとなればなおさらです。
この記事では、それらをすべて一度に説明します。
まず、一つ理解しておいてほしいことがあります。スキルは特定の AI に紐づくものではないということです。
多くの人は「Claude スキル」と聞いて、Claude 限定の機能だと思っていますが、そうではありません。エージェントスキルは Anthropic が立ち上げたオープンスタンダードであり、Claude はその主要な実装例に過ぎません。
同じスキルフォルダを Claude Code では ~/.claude/skills/ に、Cursor では ~/.cursor/skills/ に配置でき、OpenAI Codex、Gemini CLI、VS Code Copilot、JetBrains Junie でも使用できます。
今日あなたが書いたスキルは、明日には別のエージェントにシームレスに移行できます。あなたの投資が一つの会社に閉じ込められることはありません。
この記事では主に Claude Code を例として使用します（スタンダードを設定し、最も完全なエコシステムを持つため）が、すべての原則、記述方法、トラブルシューティングの経験は、エージェントスキルをサポートするすべての AI ツールに適用されます。
「Claude スキル」と書いてあれば、「エージェントスキル」と読み替えてください。
1. スキルとは一体何か？
一言で定義するなら：
スキルとは、SKILL.md と呼ばれる Markdown ファイルを中心としたフォルダであり、あなたが定義した SOP に従って、AI が特定の種類の専門作業を安定して実行する方法を指示するものです。
「ある種類の作業をどのように行うか」を、再利用可能で自動的にトリガーされる機能モジュールにカプセル化します。
本質的には、汎用 AI の「拡張パック」のようなものです。
汎用 AI は、インテリジェントではあるもののドメイン知識を持たない、素のマシンのようなものです。スキルはプラグアンドプレイのモジュールです。「小红书（シャオホンシュー）スタイルスキル」をインストールすれば、AI はすぐにあなたのブランドを理解する編集者になります。「週報スキル」をインストールすれば、AI はあなたの会社のフォーマットでレポートを生成します。
そして、この「拡張パック」は AI を選びません。Claude Code、Codex、Cursor、Gemini CLI、Junie はすべて同じフォーマットを認識します。
あなたが作っているのは、Claude 限定のスクリプトではなく、エージェントスキルです。
他の 4 つの概念との境界：
多くの人がスキルをプロンプト、ナレッジベース、MCP、エージェントと混同していますが、これらは明確に異なります。
よく使われるたとえ：
- プロンプト = 社員に WeChat でメッセージを送るようなもの。一度終われば忘れられてしまう。
- スキル = 社員のためにマニュアルを作り、机の上に置いておくようなもの。道具箱も一緒に。
- ナレッジベース = 世の中に何があるかを教えてくれる図書館。
- MCP = 「できるかどうか」という問題を解決する、さまざまな台所道具。
- エージェント = 記憶と意思決定を持つ社員システム全体。スキルはその一部。
これら 4 つは相互排他的ではありません。
実際の作業では、これらはよく組み合わされます。MCP で Claude を Reddit に接続してデータをスクレイピングし、スキルでそのデータのフィルタリング、分類、レコメンド方法を教え、ナレッジベースでブランド資料を提供し、エージェントがプロセス全体を実行するシステムとなります。
2. アーキテクチャと動作メカニズム
ファイル構造
各サブディレクトリは異なる問題を解決しますが、同じ目標（コンテキストの節約と品質の安定化）に貢献します。
scripts/：正確な計算を、コンテキストを消費せずに実行。references/：オンデマンドで読み込まれ、スペースの無駄を防ぐ。assets/：出力フォーマットを標準化。
3 層プログレッシブディスクロージャー — スキル設計の真髄
スキルの核となるメカニズムは 3 層の読み込みであり、これによって十数個のスキルが同時に存在してもコンテキストが爆発しない理由です：
例えば：
Claude は起動時に、すべてのスキルの「表紙」だけをめくって、どれを使うかを判断します。実際に作業をするときになって初めて本文を開き、付録を確認する必要があるときだけリファレンスを参照します。
このメカニズムにより、200K のコンテキストウィンドウを詰まらせることなく、17 個ものスキルを同時にアクティブにできます。
YAML メタデータ
フィールドの説明：
説明文が成否を分ける
3 層アーキテクチャにおいて、L1 の説明文は最も重要です。これによってあなたのスキルがトリガーされるかどうかが決まります。
重要な事実：
- Claude は起動時に、すべてのスキルの説明文だけを読み取ります。
- キーワードマッチングではなく、説明文に基づいて意味的な判断を下します。
- Claude は保守的な傾向があります。確信が持てなければトリガーしません。テストでは、曖昧な説明文のトリガー精度はわずか 55% でした。
悪い例（決してトリガーされない）：
[曖昧な説明文]
良い例（Anthropic が推奨する「押しの強い」スタイル）：
[具体的な説明文]
説明文を作成するための 3 つの黄金律：
- WHAT + WHEN を一緒に書く：何をするのか、いつ使うのかを書く。
- トリガーワードを中国語と英語の両方でリストアップする：ユーザーが何と言ってもマッチするように。
- 保守的になるよりも押しの強さを優先する：Anthropic は、主な問題はトリガー不足であると明言しています。
3. 優れたスキルを書くための核心原則
3 つの主要原則
自由度の扱い方：
5 つのデザインパターン
Anthropic は初期ユーザーから 5 つのスキルデザインパターンをまとめました：
実用的なスキルは、多くの場合複数のパターンを組み合わせています。厳密に従う必要はありませんが、存在を知っておくことで、より構造的に設計できるようになります。
黄金律：「Must」ではなく「Why」を使う
これは skill-creator（スキルを作成するための Anthropic 公式メタスキル）のソースコードからの引用です：
モデルに対して、なぜそれが重要なのかを説明するように心がけてください。頭ごなしの Must や MUST を使う代わりに。
悪い例：
[厳格な MUST ルール]
良い例：
[理由を説明]
前者の場合、Claude はその 2 つのルールに従うだけです。ルールがカバーしていない状況（一見安全だがリスクのあるコマンドなど）では、行き詰まってしまいます。後者の場合、Claude は「なぜ安全性が重要なのか」を理解し、グレーゾーンでも慎重な方向に傾きます。
理由によってモデルは一般化できますが、ルールはあなたが考えられるシナリオしかカバーできません。唯一の例外は出力フォーマットです。「出力はこのテンプレートを使うこと」のような機械的な要件には説明すべき「理由」がないので、ハードコードしてしまいましょう。
情報の所有権：繰り返してはいけない
skill-creator には、もう一つ鉄則があります：
情報は SKILL.md か references のどちらかに存在すべきであり、両方には存在すべきではありません。
SKILL.md には基本手順のみを含め、詳細は references/ に移動させましょう。重複して保存すると、一方を更新したときに他方を忘れてしまい、不整合が生じます。
避けるべきファイル
スキルは AI のためのものであり、人間のためのものではありません。README.md、INSTALLATION_GUIDE.md、QUICK_REFERENCE.md、CHANGELOG.md などは追加しないでください。これらの人間向けドキュメントはコンテキストを無駄に消費するだけです。
4. 最初のスキルを構築する
Anthropic 公式の 6 ステップ
skill-creator 内で定義されている標準プロセス：
- 意図の把握：何をするか、いつトリガーするか、出力形式、テストの必要性を明確にする。
- インタビューと調査：エッジケース、I/O 形式、サンプルファイル、依存関係。
- SKILL.md の作成：ドラフトを書く。
- テストケース：実際のテストケースを 2～3 件作成する。
- 実行と評価：スキルありとベースライン（スキルなし）を並行して実行し、ベンチマークを取る。
- 反復：フィードバックに基づいて修正し、満足するまで再実行する。
一般ユーザー向けの 4 つの高速パス
skill-creator：スキル作成のためのメタスキル
Anthropic 公式の skill-creator を最初にインストールすることを強くお勧めします。これはスキルを作成するためのスキルです。起動すると、Claude があなたにインタビューします。ワークフロー、トリガー条件、境界について質問し、SKILL.md とフォルダ構造を自動生成します。
インストールコマンド：
[コマンド]
出力を生成するだけでなく、以下のことも支援します：
- 評価：テストケースを自動生成し、スキルが正しくトリガーされるか検証。
- 改善：テスト結果に基づいて説明文と指示を自動最適化。60/40 のトレーニング/テスト分割で過学習を防止。
- ベンチマーク：成功率とトークン使用量を追跡し、2 つのバージョン間で A/B テストを実行することも可能。
最小限の例
あなたが小红书のフードブロガーで、通常のレシピを小红书スタイルに書き換えたいとします：
~/.claude/skills/xiaohongshu-recipe/SKILL.md に配置します。今後、「小红书版に変換して」と言うだけで自動的にトリガーされます。
ファイルを作成してから使用するまで、20 分もかかりません。
5. インストール、保存、クロスツールでの使用
読み込み優先順位（4 段階）
Claude Code は以下の順序で検索します。より具体的な場所ほど優先順位が高くなります：
ヒント：プロジェクト固有のものでない限り、個人の ~/.claude/skills/ ディレクトリに保管して一元管理しましょう。
3 つのインストール方法：
インストール後は Claude Code を再起動することを忘れずに。
クロスツール互換性（再度強調）
前述の通り、スキルは Claude に紐づくものではありません。以下が各ツールのパス比較です：
運用上の意義：同じ SKILL.md フォルダを異なるツールのディレクトリにシンボリックリンクできます。これこそが、エージェントスキルがオープンスタンダードであることの最大の利点です。
国内ユーザーの悩みどころ
- Claude 公式は高額：コストパフォーマンスを高めるにはプロキシ API を利用。
- CC Switch：複数の API 設定を管理・切り替えるためのオープンソースツール（github.com/farion1231/cc-switch）。
- ネイティブインストールの方が npm より安定：
curl -fsSL https://claude.ai/install.sh | bash。
6. 発展編 — マルチスキル連携アーキテクチャ
粒度
核心原則：1 つのスキルには 1 つの明確なタスク。汎用スキルは作らない。
粒度が粗すぎると説明文が不明瞭になり、トリガーが不正確になります。細かすぎると管理コストが上がります。適切な粒度は、問題のカテゴリごとに 1 つのスキルであり、SKILL.md の本文は約 200～500 行です。
ケーススタディ：ブログ作成スキルスイート
1 つの「オールインワン作成スキル」は作らないでください。代わりに、連携する 5 つのスキルに分割します：
連携モード：メインスキルが ## Steps セクションで他のスキルを明示的に呼び出します。
この分割の利点：
5 つのエンジニアリング経験則
- 細かい粒度：1 つのスキルには 1 つの明確なタスク。
- 明示的な連携：メインスキルの ## Steps を使用して他のスキルを呼び出す。
- 計算にはスクリプト：SEO 文字数やリンク統計にはスクリプトを使用。モデルに推定させない。
- 独立したスタイルガイド：安定した知識（ライティングスタイルやブランド仕様）は
references/に置き、1 つのファイルを変更するだけでスタイルを更新できるようにする。 - テンプレートフォールバック：テンプレートがあればベースラインが保証されるため、出力が大きく外れることがない。
7. 専門的な評価と反復
評価システム：
skill-creator の標準プロセス：
evals/evals.jsonにテストプロンプトを記述。with_skillとbaseline（スキルなし）を同時に実行し、二重盲検比較を実施。agents/grader.mdを使用して各アサーションをスコアリング。aggregate_benchmarkを使用して、pass_rate / time / tokens のレポートを出力。
説明文の自動最適化
skill-creator で最も価値があるのは説明文の最適化です：
- トリガー評価クエリを 20 件作成（8～10 件はトリガーされるべきもの + 8～10 件はトリガーされるべきでないもの）。
- 難しさ：非トリガーには「ニアミス」を使用。キーワードは共有するが、別のツールが必要なクエリ。
- 最適化スクリプト：60% をトレーニング、40% をホールドアウトテストに使用し、過学習を防止。
- 5 ラウンド実行し、テストスコアが最も高い説明文を選択する。
トリガーの良い例：「PDF テーブルを抽出」とだけ書くのではなく、実際のユーザーのように書く：
あのさ、上司から xlsx ファイルが送られてきたんだけど（ダウンロードフォルダにあって、「Q4 売上 最終 最終版 v2.xlsx」みたいな名前）、利益率をパーセンテージで表示する列を追加してほしいって言われたんだ。
これにはファイルパス、個人のコンテキスト、列名、カジュアルな言葉遣い、潜在的なタイプミスが含まれています。
反復のマインドセット
skill-creator からの 4 つのポイント：
- フィードバックから一般化する：単一のケースのために細かいルールを追加しない。問題が繰り返し発生する場合は、別のメタファーやワークフローを試す。
- スリムに保つ：トランスクリプトを確認して時間の無駄になっている指示を見つけ、役に立たない部分を削除する。
- 理由を説明する：LLM は心の理論を持ち、一般化できる。
- 冗長な作業を見つける：すべてのサブエージェントが個別に
create_docx.pyを書いているなら、それをscripts/にバンドルする。
最初のバージョンは決して完璧ではありません。
実際の反復事例：ある著者の /daily スキルは、安定するまでに 6 つのバージョンを要しました。
- v1：ステップが不明確、パスが間違っている。
- v2：コンテンツ発見システムの統合を追加。
- v3：週次進捗計算のエラーを修正。
- v4：自動トリガーを追加（火曜日のリマインダー、月末のアーカイブ）。
- v5：iPhone ライトモードを追加（モバイルでは Python ステップをスキップ）。
- v6：ようやく「使える」状態に。
スキルは、一度設定すれば終わりの構成ファイルではありません。あなたのワークフローを反映する生きたドキュメントです。
8. いつスキルを作るべきか？
すべてがスキルにする価値があるわけではありません。次の 3 つのシグナルのいずれかが現れたときだけ、行動を起こすべきです：
逆に：作るべきでない時
- 単発のタスク：プロンプトを使えば十分。
- 過剰なカプセル化：たった 3 回使っただけでスキルを分割する。メンテナンスコストがメリットを上回る。
- 完璧主義：v1 を完璧にしようとする。実際に使い始めると、ニーズは想像上のものだったことに気づく。
9. 落とし穴チェックリスト
10. エコシステムと必須スキルリスト
スキルリソースマップ
必須スキルリスト
11. スキルの商業的可能性
スキルは単なる個人の効率化ツールではありません。AI アプリケーションの作り方そのものを再定義しています。
これまで、垂直特化型 AI アプリの開発には長いサイクル、高いコスト、技術チームが必要でした。現在は：
- コード不要の敷居：コーディングなしで垂直エージェントを構築。
- 迅速な検証：開発サイクルを数週間から数分に短縮。
- API サービス：スキルを API としてパッケージ化し、既存の製品を強化。
- スキルを製品として：プロンプト集を販売するのと似ているが、より高い価値を持つ。
実際の事例：
- Article-Copilot：素材のクリーニングから執筆までの全チェーンをカバーする単一のスキル。
- AI パートナースキル：汎用エージェントに深い記憶を与え、真のパートナーにする。
- 面接対策スキル：企業、職種、履歴書に基づいて完全なレポートを生成。これを使って Hithink RoyalFlush の面接を受けた人もいる。
- スーパー・フォンさんの方法：数十のスキルと cron ジョブを組み合わせ、睡眠中に時間単位のレポートを実行。
業界に深く携わる人は誰でも、自分の経験をスキルに凝縮して時間を節約したり、製品として販売したりできます。
結論
エージェントが AI 世界の身体であるなら、スキルはそこに注入される魂です。
それは Steam と Workshop の関係のようなものです。拡張可能なアーキテクチャがゲームに無限の命を与えます。
スキルは難しいものではありません。ただ少し構造化された Markdown に過ぎません。しかし、それが示すトレンドは極めて重要です。AI が「毎回教えなければならない」ものから、「一度教えればそれで終わり」のものへと移行しているのです。
そして、その標準はオープンです。今日 Claude Code 用に書いたスキルは、明日には Cursor や Gemini に移行できます。
まだ様子を見ている皆さんへ：
スキルは設計されるものではなく、繰り返しの労働から生まれるものです。
まず一つのことを動かしてみて、それをカプセル化しましょう。優れたワークフローは計画されるものではなく、反復されるものです。
ターミナルを開き、skill-creator をインストールして、今日あなたが 3 回繰り返したあのパラグラフを、最初の SKILL.md に変えましょう。
