![[MCP·Skill #2] AIエージェントのSkillを完全解説：スラッシュコマンドから自動トリガーまでのカバー画像](/assets/images/posts/60116d30-9205-43b5-b09e-610a09bd6239/1.jpg)
AIコーディングツールを使っていると、「コミットメッセージはこの形式で」「デプロイ前はこのチェックリストに従って」のように、同じ指示を繰り返しがちです。
毎回プロンプトで説明すると長くなり、CLAUDE.mdやAGENTS.mdのような常時ルールファイルにすべて入れると、セッションごとのコンテキストが重くなります。
Skillはこの繰り返しを解決します。特定の作業に必要な手順と知識をファイルにまとめ、必要なときだけ読み込むモジュールです。
もともとはClaude Codeの機能として始まりましたが、今や特定のツールだけのものではありません。2025年12月、AnthropicがAgent Skillsというオープン標準として仕様を公開し、その後OpenAI Codex、Gemini CLI、Cursor、VS Code（GitHub Copilot）など30を超えるツールが同じ形式を採用しました。一度作ったSKILL.mdは、ツールを乗り換えてもそのまま使えます。
この記事では、Skillの構造、スラッシュコマンドと自動トリガーという2つの呼び出し方法、ツールごとの対応状況、常時ルールファイルとの役割分担を整理します。例はこの機能をいち早く導入したClaude Codeを使いますが、考え方はどのツールでも同じです。
まず要点をまとめます。
- SkillはSKILL.md 1ファイルから始まる指示書フォルダーで、今ではツールを問わないオープン標準です
- 呼び出し方は2つ。ユーザーが直接呼ぶスラッシュコマンドと、モデルが自動で呼ぶ自動トリガーです
- 中核となる設計は段階的な読み込みです。通常は名前と説明だけが読み込まれ、本文は実行時に読み取られます
- 常に適用するルールはCLAUDE.mdやAGENTS.mdなどの常時ルールファイルに、特定作業の手順はSkillに分けます
Skillの正体はMarkdownフォルダー
Skillの構造はシンプルです。1つのフォルダーにSKILL.mdが1つあれば最低条件を満たします。
---
name: release-note
description: リリースノートの下書きを作成。「リリースノート」「デプロイノート」の依頼で使用
---
# リリースノート作成手順
1. 直前のタグ以降のコミットを集める
2. feat/fix/chore分類する
3. ユーザーへの影響順に並べて下書きを作成する先頭のfrontmatterにあるnameとdescriptionが登録情報で、その下の本文が実際の手順書です。参考資料やスクリプトを追加して、「指示書＋ツールボックス」に拡張することもできます。
標準が定義するのはこの形式までです。どのフォルダーから読むかはツールごとに異なるため、主に使うツールのパスだけ把握しておけば十分です。
| ツール | Skillディレクトリ |
|---|---|
| Claude Code | ~/.claude/skills/（グローバル）、프로젝트/.claude/skills/（プロジェクト） |
| OpenAI Codex | .agents/skills/ |
| Gemini CLI (Antigravity) | ~/.gemini/antigravity/skills/ |
プロジェクトフォルダーに置けばGitでチームメンバーと共有できる点が、実務では特に便利です。作業のノウハウが個人メモではなくリポジトリの資産になります。チームメンバーが異なるコーディングエージェントを使っていても同じSKILL.mdを読めるため、ツールを統一せずに手順を共有できます。
呼び出し方は2つ：手動と自動
Skillが実行される経路は2つあります。
1つ目はスラッシュコマンドです。ユーザーが/release-noteのように直接入力して明示的に呼び出します。実行するタイミングを人が決める方式です。
2つ目は自動トリガーです。モデルが会話内容を見て、「この依頼はあのSkillの担当だ」と判断し、自ら読み込みます。その判断材料になるのがfrontmatterのdescriptionです。
descriptionは人向けの説明ではなく、モデル向けのルーティング条件です。「いつこのSkillを使うか」をトリガー文言まで含めて具体的に書くほど、自動呼び出しの精度が上がります。
ここで重要なのが、段階的な読み込み（progressive disclosure）という設計です。セッション開始時にコンテキストへ入るのは、各Skillの名前と1行のdescriptionだけです。本文全体は、そのSkillが実際に呼び出されたときだけ読み込まれます。
そのため、Skillを数十個登録しても普段のコンテキスト負荷はほとんどありません。すべての手順を常時ルールファイルに詰め込む方式との決定的な違いです。多くのベンダーがこの形式を採用した大きな理由も、この段階的な読み込みにあります。コンテキストウィンドウはどのモデルにとっても高価なリソースだからです。
常時ルールファイルとの役割分担
Claude CodeのCLAUDE.md、CodexのAGENTS.md、Cursorのrulesのように、ツールごとに「常に読むルールファイル」があります。どちらも「モデルに与える指示」なので混同しやすい部分です。基準は適用されるタイミングです。
- 常時ルールファイル（CLAUDE.md・AGENTS.mdなど）：毎セッション、すべての作業に常に適用されるルール。コーディング規約、禁止事項、プロジェクトの背景
- Skill：特定の作業をするときだけ必要な手順。デプロイ、レビュー、ドキュメント作成などの単位作業
「常に真であるべきか？」と考え、そうなら常時ルールファイル、特定の状況でだけ真ならSkillです。常に適用するルールをSkillに分けると、トリガーされないときにルールが消えます。逆に手順をすべて常時ルールファイルに入れると、コンテキストを浪費します。
作成時につまずきやすい点
実際によくぶつかるポイントを2つだけ押さえておきます。
自動トリガーが動かないときは、ほぼ必ずdescriptionが原因です。「ドキュメント作成アシスタント」のように抽象的に書くと、モデルはいつ使うべきか判断できません。実際のユーザーが入力しそうな文言を列挙すると効果的です。
逆にトリガーされすぎるときは、descriptionに「〜の場合のみ使用。単純な質問には使用しない」のような除外条件を明記すると抑えられます。
このコツはどのツールでも通用します。自動トリガーの判断主体は結局モデルであり、モデルが見るのはdescriptionの1行だけという構造が、標準上共通しているからです。
まとめ
Skillは結局、プロンプトの関数化です。繰り返す指示をコピー＆ペーストする代わりに名前を付けて保存し、必要なときだけ読み込みます。そして今では、その関数が特定のツールに依存しない標準形式になりました。
同じ指示を一度でも2回入力したなら、それが最初のSkill候補です。今日作ったSKILL.mdは、来年どのエージェントを使っていても付いてきます。