Anthropic SkillsからAIプロダクト開発者が学べること：Skillsは"業務マニュアル付きの道具箱"
AnthropicのSkillsが発表された時、皆様はどう思いましたか？
「Tool Use（Function Calling）とは何が違うんだ...？」
「また違いの説明が求められる新しい用語が増えたのか...？」
というのが私の最初の正直な感想でした。
ただ、全くToolと同じということもないはずです。
そこで遅ればせながら、既存のTool Useとの差分や、なぜこの「Skills」という構造が必要だったのか？
プロダクト開発視点では何を持ち帰れば良いのか？について考えてみました。
AIエージェント開発の変遷とコンテキストウィンドウの限界
まず、これまでのAIエージェント開発を振り返ってみましょう。
Toolによる能力拡張 (Capability Extension)
オライリーのAIエンジニアリングでも、AIエージェントは 「環境」と、それに作用する「ツール」 が最も中心的な構成要素でした。
LLM単体では計算もおぼつきませんし、昨日の天気も分かりません（なんなら昨日がいつかもわからない）
だから「このAPI（ツール）を使えば天気が分かるよ」と教えてあげる。
これでAIは、実世界の環境に作用するための手段や新たなケイパビリティを手に入れました。
これがいわゆるTool Use（Function Calling）などと呼ばれてきたものです。
JSON Schemaで関数の仕様を渡せば、AIが適切な引数を生成し、システム側で実行する。
このループによって、AIはチャットボットから、より幅広いタスクをこなす事ができる可能性を見いだしました。
コンテキストウィンドウのジレンマ
しかし、実際にプロダクトを作っていると、エージェントにさせたいタスクが複雑になればなるほど、ある壁にぶつかりませんか？
例えば、「企業の財務レポートを作成し、送付する」という複雑なタスクをAIにさせようとすると、必要なツール（株価取得、DB検索、メール送信など）を定義するだけでは不十分です。
「どの指標を重視するか」「どういうトーンで書くか」「異常値があった場合の判断基準」といった 手順（Procedure） を教える必要があります。
私たちはこの手順を、ツールを与えた上でシステムプロンプト（もしくはToolのdescription）に記述していました。しかし、これを全部システムプロンプトに詰め込むとどうなるか。
コンテキストウィンドウが増えたとしても、依然として指示を詰め込めば詰め込むほど、性能は低下する傾向を示しています。コンテキストウィンドウのオーバーロードです。
コストとレイテンシの無駄もあります。
滅多に使わないレアケースの対応手順や、特殊なツールの定義を常にプロンプトに含めておくことは、トークンの無駄であり、処理速度を低下させる要因にもなります。
https://speakerdeck.com/rkaga/beyond-context-is-king?slide=11
コンテキストウィンドウが埋まり、モデルの推論能力が低下する領域として、ダム・ゾーン（Dumb Zone）と呼んだり、重要な指示が埋もれ、モデルの挙動が不安定になる状態としてContent Rotと呼んだり
色々な表現や言い回しはありますが、主張している内容は同じです。
https://speakerdeck.com/rkaga/beyond-context-is-king?slide=12
「必要な時に、必要な能力だけを、シュッと提供できないか？」
この課題に対する、特にツールと関連する手順をまとめる構造的な整理こそが、Anthropicの回答であるSkillsだったと理解しています。
Skillsの正体は「実行可能なドキュメント」？
では、Skillsって何なの？という話です。
従来のToolが API定義（JSON Schema）だったのに対して、Skillsの実体は 「手順と実行資産をまとめたパッケージ」 です。
スキルは、特定のタスクを完了するための手順、つまり手続き的な知識を提供します。この2つを組み合わせて使用できます。MCP接続によってClaudeはツールにアクセスできるようになり、スキルによってClaudeはそれらのツールを効果的に使用する方法を習得します。
引用: https://support.claude.com/en/articles/12512176-what-are-skills
Claude Codeではファイルシステム上のフォルダとして表現されていますが、
本質的には「段階的にロードされる手順知識・補助ドキュメント・実行ロジックの集合体」だと捉える方が正確だと感じます。
Skillは、いくつかのファイルがパッケージ化されたディレクトリとして定義されます。
my-skill-example/
├── SKILL.md # Skillの核となるファイル/プロンプト
├── scripts/ # オプション：実行可能なPython/Bashスクリプト
├── references/ # オプション：コンテキストにロードされるドキュメント
└── assets/ # オプション：テンプレートとバイナリファイル
| レイヤー | 主な役割 | 中身 |
|---|---|---|
| 判断と方針 | 何をすべきかを判断し、次に読むものを決める | SKILL.md |
| 実行資産 | 実際の処理を行う |
scripts/ 配下のコード、Tool |
| 補助ドキュメント | 詳細・例外・レアケースを補完する |
reference.md / forms.md など |
Skillsとは 手順的知識（How-to）と道具（tool/scripts）をセットにしたパッケージ、もっと平たく言えば、エージェントに対する 「業務マニュアル（道具/Tool付き）」 です。
ソフトウェア工学っぽく言うなら、実行可能なドキュメント（Executable Documentation） と言っても良いのかもしれません
少し雑ですが、これまでのTool Useが「ドリルを渡す行為」に近かったとすれば、Skillsは「日曜大工の入門書とドリル」を渡す行為に等しいです。
Progressive Disclosure（段階的ロード）
中を見てしまえば、「Markdownとスクリプトをフォルダに入れただけ？」というのも頭に一瞬浮かびますが、フォルダの中身そのものよりも、それがどう読み込まれるかという、Progressive Disclosureの方が面白いと感じます。
Anthropicは、Skillsを「エージェントの認知リソース（コンテキストウィンドウ）を効率化するための仕組み」と位置づけ、段階的ロード（Progressive Disclosure） の考え方に基づき、以下のフローで動作すると説明しています。
-
Discovery:
- エージェントの起動時、システムプロンプトには各Skillの軽量なメタデータ（
nameとdescription）のみがロードされます。この時点でのトークン消費は極小です。
- エージェントの起動時、システムプロンプトには各Skillの軽量なメタデータ（
-
Activation:
- エージェントが「このタスクには財務分析スキルが必要だ」と判断した瞬間、
SKILL.mdの中身を読み込み、その内容がコンテキストに入ります。
- エージェントが「このタスクには財務分析スキルが必要だ」と判断した瞬間、
-
Execution:
- 詳細な手順書がロードされた状態で、エージェントは指定されたスクリプトを実行し、タスクを遂行します。
これはAnthropicが繰り返し述べている、「すべてを最初からコンテキストに入れない」 というコンテキストエンジニアリングの思想、そのままだと感じます。
（思い返せばRAGに関しても、Anthropicはコンテキストに収まるならプロンプトに含めたら良いと主張していました）
Agents with a filesystem and code execution tools don't need to read the entirety of a skill into their context window when working on a particular task
ファイルシステムとコード実行ツールを持つエージェントは、特定のタスクに取り組む際、スキル全体をコンテキストウィンドウに読み込む必要はありません。
引用: https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
必要な時に必要な知識だけをロードすることで、コンテキストを不必要に汚さない、コンテキストエンジニアリングそのものだと、個人的にはmake senseでした。
また、Anthropicの公式解説では、PDF用のSkillを例に「SKILL.mdの本文を薄く保ち、分岐・詳細は別ファイルに逃がす」設計が紹介されています。
実際に公開されている PDF SkillのSKILL.mdを見ると、この設計がそのまま実装されていることが分かります。
高度な機能やJavaScriptライブラリ、詳細な使用例については reference.md を参照してください。
PDFフォームへの入力が必要な場合はforms.mdを読み、その手順に従ってください。
SKILL.md 自体は「何を判断し、どこに進むか」だけを担い、フォーム入力や詳細手順といった長文化しがちな知識は、forms.mdやreference.md に切り出されています。
（CLAUDE.mdやAGENTS.mdでもよくやるやつですね）
ちなみに、Anthropicは「Tool Search Tool」という名称で、大量のツール定義を動的に検索・ロードする似たようなアイディアをブログで紹介しています。
Tool Search Toolが、能力（Tool）の段階ロードなのに対し、Skillsはそれを手順（Procedure） まで拡張したものとも捉えるかなと。
実装者視点：ToolとSkillsの境界線
概念は理解できましたが、実装する人間として悩ましいのは 「で、どっちを使えばいいの？」 という判断です。
すごく単純に（抽象的に）言うと、Toolは「できること」を増やし、Skillsは「どう使うか」を教え、MCPは「繋ぎ方」を整理するレイヤーかなと。
（MCPは仕様的にはもっと色々想定されていますが...）
| 概念 | 本質 | 役割 |
|---|---|---|
| Tool | 能力拡張（Capability Extension） | 環境に作用するための手段。APIを叩く、DBに接続するなど。意志も手順もなく、能力の拡張、道具の提供 |
| Skills | オーケストレーション | 複数のToolをどう組み合わせるか。順序・判断基準・ワークフローをMarkdownで定義 |
| MCP | コネクティビティ（接続レイヤー） | Tool（特に外部APIやサービス向け）を汎用的につなぐための接続方式。 |
公式ドキュメントでも、この違いが明確に説明されています。
MCPはClaudeを外部のサービスやデータソースに接続します。スキルは、特定のタスクを完了するための手順、つまり手続き的な知識を提供します。この2つを組み合わせて使用できます。MCP接続によってClaudeはツールにアクセスできるようになり、スキルによってClaudeはそれらのツールを効果的に使用する方法を習得します。
引用: https://support.claude.com/en/articles/12512176-what-are-skills
Skillは、「どうやるか（How to be）」 という手順やノウハウが必要な処理、複数のToolを組み合わせるオーケストレーションです。
例えば、「天気を調べてから（Tool A）、その気温に応じて服装を提案し（LLM）、カレンダーに予定を入れる（Tool B）」といった一連の流れは、Skillsで定義します。
Tool or MCPに関しては、プロダクト開発者視点だと、MCPでなければいけないケースは割と限定的な気がしてますが、複数ツールを横断して“共通の接続口”にしたい場合などはMCPを検討するのかなと。
エージェント開発もコンテキストエンジニアリング
Skillについて考えてみると、Toolを作るだけでなく、エージェントに渡す知識パッケージ（Skill）を設計・管理する ことは、プロダクト・AIエージェント開発においても重要であることが如実に理解できます。
Skillsはアンチパターンである?
ロジックをMarkdown（自然言語）で書くのは、「テストが難しく、挙動が確率的になるため、エンジニアリングとしては後退だ」という意見も存在します。
それでもなおSkillsが採用される理由の一つには、ドメインエキスパートがエージェントの挙動を修正できる というメリットが、厳密性のデメリットを上回る領域があるからと考えます。
大事なのは、Skillsは、コードの代替ではない、という点だと捉えています。
厳密性・再現性・テスト容易性が求められるロジックは、これまで通り Tool（やコード）として実装されるべきです。
Skillsが担うのは、
- 手順の優先順位
- 判断基準の言語化
- 例外時の「人ならこうする」という知見
といった、本来コードに閉じ込めると硬直しやすい部分かなと。
Scriptを含めることもできるので、Skillsを「何でも自然言語で書くための仕組み」と誤解しないことも大事だと思います。
コードを書かないドメインの専門家がエージェントを育てる
Skillsの実体がMarkdownであることは、地味ですが大きな意味を持ちます。
なぜなら、Markdownならエンジニアでなくても書きやすいからです。
経理のプロや、カスタマーサポートのリーダーが、自分でMarkdownの手順書を修正して、エージェントの挙動を改善する。
Skillsのような仕組みがあると、「現場の人間がエージェントを育てる」 というカスタマイズが加速するでしょう。
これ自体は数年前から言われていたこと・進んでいることではありますが、一つのリファレンス実装として分かりやすい形が提示されたことで、この「育てるための基盤」を整備することの流れは進むかもしれません。
私自身、自社プロダクトでも、ラストワンマイルを埋めるための仕組みとして、エージェントの細かな振る舞いや能力をカスタマイズできる機構を構築しました。
ベースとなるシステムプロンプトやツールを用意し、CSやユーザーが個別に挙動を調整できるように、色々構造を整理して作りました。
その中でやりたかったことは、まさにこのSkillsでした。
単にツール（API）を並べるだけでなく、「ツールの抽象度を一段階上げて、複数のツールをどうオーケストレーションするか」、そして 「それをどう使うかの手順書」 をセットにしてまとめる。
さらに、ユーザー・CSが自ら設定して、エージェントの振る舞いをカスタマイズする。
AnthropicのSkillsは上手い設計だと感じました。今はインスパイアされた新しい実装をしているところです。
生成AIの強みであるFew-shotやIn-context Learningを最大限に活かすために、AIプロダクト・AIエージェント開発は 「何ができるか（Capability）」だけを定義する段階を終え、「どう振る舞うべきか（Behavior）」 まで教え込まなければいけないフェーズに今まで以上に向かうだろうなと感じています。
まとめ
要点を整理すると、次の3点です。
- コンテキストは「増やす」のではなく「管理」するもの
- Toolは能力、Skillsは「振る舞い」を定義する仕組み
- Toolは「できること」を増やし、Skillsは「どう使うか」を教え、MCPは「繋ぎ方」を整理する
技術要素だけを見れば、Skillsは既存技術の組み合わせに見え、ある種の再発明・リブランディングに見えるというのが最初の感想でした。
しかし、AIエージェントのコンテキストエンジニアリングの最適解として、従来は道具（Tool）だけだった領域に、「手順」まで含めて動的に装備させるというアプローチ。
これは、抽象度を一段階上げた、新しいアイデアだと感じました。
AIエンジニアリングを行う上でも、「能力の追加」 だけではなく、「振る舞いの設定」 を可能にする設計アプローチは手札として持っておく必要性を感じます。
最終的にSimon Willisonのように、Claude Skillsは大きなアイディアかもしれないと思ったという着地で、この記事は終わります。
Claude Skills are awesome, maybe a bigger deal than MCP
今回は以上です！
補足
OpenAIのChatGPT（Code Interpreter）環境にも、 裏側で似たような「スキル定義ファイル」内部的に存在している可能性が観測され、ダウンロードできてしまうことが話題になりました。
参考
Discussion