概要
https://zenn.dev/r_kaga/articles/810cc2e8326ca5
詳細内容
## Anthropic SkillsからAIプロダクト開発者が学べること：Skillsは"業務マニュアル付きの道具箱"
https://zenn.dev/r_kaga/articles/810cc2e8326ca5
AnthropicのSkillsは、AIエージェントのコンテキストウィンドウの限界を克服し、手順とツールを統合した「業務マニュアル付きの道具箱」として、エージェントの動的な振る舞いを定義し、現場の専門家によるカスタマイズを可能にします。
**Content Type**: ⚙️ Tools
**Language**: ja
**Scores**: Signal:4/5 | Depth:4/5 | Unique:4/5 | Practical:4/5 | Anti-Hype:4/5
**Main Journal**: 100/100 | **Annex Potential**: 100/100 | **Overall**: 80/100
**Topics**: [[AIエージェント開発, Anthropic Skills, コンテキストウィンドウ管理, Tool Use, ドメインエキスパート連携]]
筆者は、Anthropicが発表した「Skills」について、当初「Tool Use（Function Calling）との違いは？」という疑問を抱いたものの、その本質を深掘りし、AIプロダクト開発者が学ぶべき点を考察しています。
これまでのAIエージェント開発では、LLM単体でできないことをAPI（ツール）で拡張する「Tool Use」が中心でした。しかし、タスクが複雑化すると、ツールを定義するだけでは不十分で、具体的な「手順（Procedure）」を教える必要が生じます。これらの手順をシステムプロンプトに詰め込むと、コンテキストウィンドウのオーバーロードによる性能低下やコスト増大を招くという課題がありました。筆者はこれを「ダム・ゾーン」や「Content Rot」と表現し、「必要な時に、必要な能力だけをシュッと提供できないか」という問題意識がSkills誕生の背景にあると指摘します。
Skillsの正体は、従来のAPI定義のようなToolに対し、「手順と実行資産をまとめたパッケージ」、より平たく言えばエージェントに対する「業務マニュアル（道具/Tool付き）」であると筆者は説明します。これは「実行可能なドキュメント（Executable Documentation）」とも言え、SKILL.mdをエントリポイントとして、scripts/、references/、assets/といったファイル群で構成されます。
Skillsの重要なメカニズムは「Progressive Disclosure（段階的ロード）」です。エージェントは起動時に各Skillの軽量なメタデータのみをロードし、必要なタスクが判明した時点で初めてSKILL.mdの内容をコンテキストに読み込みます。これにより、コンテキストを不必要に汚染せず、効率的な推論を可能にする、Anthropicのコンテキストエンジニアリング思想が具現化されていると筆者は評価します。
実装者視点では、Toolが「できること（Capability）」を増やし、Skillsが「どう使うか（How-to）」を教え、MCPが「繋ぎ方」を整理するという違いがあります。Skillsは、複数のToolを組み合わせるオーケストレーションや、手順的な知識を定義するのに適しています。
筆者は、ロジックをMarkdownで書くことの「テストが難しい」といったアンチパターン論も認識しつつも、Skillsの最大の利点は、エンジニアではないドメインエキスパート（経理担当者やカスタマーサポートリーダーなど）が、Markdown形式の手順書を直接修正することで、エージェントの振る舞いを自律的に改善できる点にあると強調します。厳密なロジックは引き続きコード（Tool）で実装し、Skillsは手順の優先順位や判断基準、例外時の知見など、硬直しやすい部分を担うべきだと筆者は主張しています。
結論として、AIプロダクト・AIエージェント開発は、「何ができるか」だけでなく、「どう振る舞うべきか」まで教え込むフェーズに進んでおり、Skillsは「能力の追加」だけでなく、「振る舞いの設定」を可能にする新しい設計アプローチとして、非常に示唆に富むものだと筆者は締めくくっています。