はじめに
AIエージェントを使っていると、「プロンプト」「スキル」「ツール」という言葉が並んで出てきます。
私も最初は、スキルを「長いプロンプトを保存したもの」くらいに考えていました。ただ、実際にQiita記事を書く手順をスキルとしてまとめてみると、プロンプトやツールとは役割が少し違うと分かりました。
先に結論を書くと、迷ったときは次のように考えると整理しやすいです。
今回だけ伝えたい依頼や条件か？
└─ はい → プロンプト
└─ いいえ
├─ 繰り返し使う手順・判断基準か？ → Agent Skill
└─ 外部の情報取得や操作が必要か？ → ツール／MCP経由
※ 両方に当てはまる場合は、Skillの手順の中でツールを使う
実際には、3つは排他的ではありません。プロンプトで依頼し、スキルに書かれた手順に沿って、ツールを使うという組み合わせがよくあります。
本記事では、主にAnthropicが公開し、現在はクロスプラットフォーム向けのオープン標準として整備されている Agent Skills形式を対象にします。Anthropicは2025年10月にAgent Skillsを発表し、同年12月にクロスプラットフォームで使えるオープン標準として公開しました。「スキル」という言葉は製品ごとに意味が異なるため、すべてのAIエージェントに共通する実装を説明するものではありません。
※本記事は個人の整理メモであり、図解も公開情報をもとに筆者が独自に作成したものです（Anthropic公式の資料ではありません）。2026年10月4日時点の公開仕様と公式情報を確認しています。対応状況や読み込み方法は、利用するエージェントやクライアントによって異なります。
1. まずは3つの役割を分ける
ざっくり言えば、プロンプトは「今回の依頼」、スキルは「再利用する進め方」、ツールは「実行できる操作」です。
| プロンプト | Agent Skill | ツール／MCP経由 | |
|---|---|---|---|
| 主な役割 | 今回してほしいことや条件を伝える | 繰り返し使う手順・知識・補助資材をまとめる | 計算、ファイル操作、外部サービス接続などの能力を提供する |
| 例 | 「この記事を初心者向けに直して」 | 「Qiita記事を調査・執筆・確認する手順」 | Web検索、ファイル保存、GitHubへの反映 |
| 向いているもの | 一度きりの依頼、その場の条件 | 複数手順、判断基準、チェックリスト | 外部状態の取得・変更、決まった処理 |
| 再利用方法 | 再入力、テンプレート化 | スキルのディレクトリを再利用 | 同じツールを呼び出す |
MCP（Model Context Protocol）は、AIアプリケーションと外部システムを接続するためのプロトコルです。ここでは説明を簡単にするため「ツール／MCP経由」と表記していますが、MCPそのものが個々のツールと同じという意味ではありません。
また、境界は完全には分かれません。Agent Skillには実行用スクリプトを同梱できますし、ツールの説明だけで使い方が十分伝わる場合もあります。上の表は、設計時に主な責務を考えるための目安です。
2. 迷ったときの3択
今回だけの条件なら、まずプロンプト
次のような内容は、その場のプロンプトで十分です。
- 今回の記事は初心者向けにする
- 表を1つ追加する
- 今日はコード例を省く
- この文章だけを300文字に要約する
一度しか使わない条件までスキルにすると、更新対象が増えます。短い依頼なら、無理にファイル化しない方が扱いやすいです。
同じ進め方を繰り返すなら、Agent Skill
毎回同じ説明をしているなら、スキル化を検討できます。
たとえばQiita記事の作成では、次のような手順を何度も使います。
- 公式情報を優先して調べる
- Preview、Beta、GAを区別する
- 誇張表現を避ける
- コードとリンクを確認する
- 公開前に個人情報や秘密情報を点検する
これは「今回の記事で何を書くか」ではなく、記事作成をどう進めるかという再利用可能な手順です。こうした内容はAgent Skillに向いています。
外部の情報取得や操作が必要なら、ツール
次の作業には、文章の指示だけでなく実行能力が必要です。
- 公式ページの現在の内容を取得する
- リポジトリ内を検索する
- ファイルを保存する
- GitHubへコミットする
- Slackへ通知する
この部分を担うのがツールです。MCPサーバーによって提供されるツールもあります。
スキルには「公式ページを確認してから記事を書く」と書けますが、それだけでWebへ接続できるわけではありません。利用するエージェント側にWeb検索などのツールが必要です。
3. 3つを組み合わせるとどうなるか
Qiita記事の作成を例にすると、役割分担は次のようになります。
プロンプト
「このニュースを初心者向けのQiita記事にして」
↓
Agent Skill
「一次情報を確認する → 構成を作る → 本文を書く
→ ファクトチェックする → 公開リスクを確認する」
↓
ツール
Webページを取得する／ファイルを読む・書く／GitHubへ反映する
この整理で大事なのは、Agent Skillを「プロンプトとツールの中間にある製品」と捉えすぎないことです。
Agent Skillは、主に作業の進め方を再利用するためのパッケージ形式です。プロンプトやツールと競合するのではなく、両方をつなぐ手順書として働きます。
4. Agent Skillの最小構成
Agent Skillsの公開仕様では、スキルは最低限 SKILL.md を含むディレクトリです。SKILL.md にはYAMLフロントマターとMarkdown形式の指示を書きます。
qiita-article/
├── SKILL.md # 必須
├── references/ # 任意：詳しい資料
├── scripts/ # 任意：実行用コード
└── assets/ # 任意：テンプレートや素材
現行の公開仕様で、フロントマターの必須項目は name と description です。
---
name: qiita-article
description: Qiita向けの技術記事を作成・確認する。Qiita記事、技術記事、記事のファクトチェックを依頼されたときに使う。
---
# Qiita記事作成
## 手順
1. 対象読者と記事の目的を確認する
2. 公式情報を優先して調べる
3. 本文を作成する
4. 技術的な主張と公開リスクを確認する
主な制約は次のとおりです。
| 項目 | 制約（公開仕様） |
|---|---|
name |
1〜64文字。小文字英数字とハイフンのみ。先頭・末尾のハイフンと連続ハイフン（--）は不可。親ディレクトリ名と一致させる |
description |
1〜1024文字。「何をするか」と「いつ使うか」を書くことを推奨 |
上の例では、ディレクトリ名 qiita-article/ と name: qiita-article を揃え、description には「どんな依頼で使うか」まで含めています。
このほか、license、compatibility（動作環境の要件）、metadata、allowed-tools（実験的機能）といった任意項目もあります。allowed-tools のサポート状況はエージェント実装によって異なります。
自動選択では、最初に提示される name と description のうち、特に description が主要な判断材料になります。ただし、最終的な有効化方法はクライアント実装によって異なります。モデルが自分で SKILL.md を読み込む方式や専用の有効化ツールを呼ぶ方式のほか、/skill-name のようなスラッシュコマンドでユーザーが明示的に指定する方式もあります。
5. 必要なものだけを段階的に使う
Agent Skillsでは、必要な情報を段階的に扱う考え方が **Progressive Disclosure（段階的開示）**として説明されています。
| 段階 | 提示・利用されるもの | タイミング | 目安（公開仕様・実装ガイド） |
|---|---|---|---|
| Level 1 | 利用可能なスキルの name と description
|
セッション開始時など | 1スキルあたり約50〜100トークン |
| Level 2 |
SKILL.md の指示本文 |
スキルが有効化されたとき | 5,000トークン未満を推奨 |
| Level 3 |
references/、scripts/、assets/ など |
作業中に必要になったとき | 必要なファイルだけ |
各スキルの全文を最初からすべて読み込むわけではないため、長い手順を毎回プロンプトへ貼るよりも、初期コンテキストの負担を抑えやすくなります。
公開仕様では、SKILL.md 本体は500行未満に抑え、詳しい資料は別ファイルへ分けることが推奨されています。
ただし、「スキルを増やしても負担がまったく増えない」という意味ではありません。利用可能なスキルのメタデータ分は増えます。また、どのスキルを提示するか、いつ本文を読み込むかはクライアントの実装に左右されます。
実行環境を備えたエージェントでは、scripts/ のコードをソース全文としてコンテキストへ入れず、コマンドとして実行して結果だけを受け取ることもできます。一方で、実行にはランタイム、依存関係、権限が必要です。スクリプトを資料として読む使い方もあります。
6. Skill化しない方がよいもの
「繰り返し使うものなら何でもSkill」と考えると、かえって管理が難しくなります。
一度きりの依頼
その場で終わる依頼はプロンプトで十分です。
なお、公式ガイド「Optimizing skill descriptions」によると、エージェントは基本ツールだけで片付く単純な1ステップの依頼（例:「このPDFを読んで」）では、description が合っていてもSkillを参照しないことがあります。Skillが効きやすいのは、専門知識や独自の手順が必要な作業です。
常に守る短いルール
すべての作業で必ず守る短い規約は、クライアントのシステム指示やプロジェクト共通ルールに置く方が合う場合があります。Skillは、特定の作業で必要になるまとまった手順に向いています。
完全に決定的な変換処理
同じ入力から必ず同じ出力を得たい処理は、自然言語の手順だけでなくスクリプトや専用ツールにした方が安定します。Skillからそのスクリプトを呼ぶ構成にはできます。
危険な操作を無承認で進める手順
削除、送信、課金、公開などの副作用がある操作は、Skillに書いたから安全になるわけではありません。確認手順、権限、実行範囲、失敗時の扱いを別途設計する必要があります。
7. 作る前に確認するチェックリスト
次のうち複数に当てはまるなら、Skill化を検討してみる価値がありそうです。
- 同じ説明を何度も繰り返している
- 作業が複数の手順に分かれている
- 判断基準や合格条件がある
- 必要なときだけ参照したい詳しい資料がある
- 毎回同じ変換や検査をスクリプトで実行したい
- チームで同じ進め方を共有したい
逆に、「今回だけの条件」「常時適用する短い規約」「外部操作そのもの」であれば、プロンプト、共通ルール、ツールの方が適している可能性があります。
8. 外部Skillを使うときの注意
Agent Skillには、エージェントへの指示、スクリプト、参考資料を含められます。第三者が公開しているSkillを導入する場合は、少なくとも次を確認した方が安全です。
-
SKILL.mdに意図しない指示がないか - スクリプトが何を読み、どこへ通信し、何を変更するか
- 必要な権限と依存関係
- APIキーや社内情報を入力する設計になっていないか
- 仕様変更後もメンテナンスされているか
Anthropicも、Skillは信頼できる提供元からのみ導入し、信頼度の低い提供元のものは使用前に十分に監査するよう推奨しています。
また、クローンしたリポジトリに含まれるプロジェクト単位のSkillにも注意が必要です。公式のクライアント実装ガイド「How to add skills support to your agent」では、信頼されていないリポジトリが指示を紛れ込ませるのを防ぐため、ユーザーが信頼済みとしたプロジェクトでのみ読み込む「信頼チェック」を設けることが、検討事項として挙げられています。
Skillは便利な手順書ですが、内容を確認せずに信頼する仕組みではありません。
まとめ
- プロンプトは、今回してほしいことや条件を伝えるもの
- Agent Skillは、繰り返し使う手順・知識・補助資材をまとめるもの
- ツール／MCP経由は、計算、ファイル操作、外部接続などの能力を提供するもの
- 3つは排他的ではなく、プロンプトで依頼し、Skillの手順に沿ってツールを使う構成ができる
- Skill化するか迷ったら、「今回だけか」「再利用する進め方か」「外部操作か」で切り分ける
- Agent Skillsの読み込み方や対応範囲には、クライアントごとの差がある
一言でまとめるなら、Agent Skillは「毎回貼っていた長い指示」を保存するだけでなく、繰り返す仕事の進め方を、必要なときに使える形へまとめる仕組みと捉えると分かりやすいです。