Agent Skillsとは何か — Anthropicが示した「エージェントに業務知識を持たせる」最小単位

要点

Anthropicのengineering blogが2025年10月16日に公開した「Equipping agents for the real world with Agent Skills」は、「エージェントに組織固有の業務知識をどう持たせるか」という問題へのAnthropic公式の回答です。記事はSkillsを「命令・スクリプト・リソースをまとめた組織化されたフォルダ」と定義し、新規採用者へのオンボーディング資料に例えながら、エージェントが必要なときに必要な知識だけを呼び出す仕組みを示しています。

実装の中心にあるのはprogressive disclosure(段階的情報開示)という設計原則です。SKILL.mdのYAMLフロントマター、本文、参照ファイルの三層に分けて情報を配置し、エージェントは関連性を判断したぶんだけコンテキストに読み込みます。Claude Code、Claude.ai、Claude Agent SDK、Claude Developer Platformの4系統で同じ仕様が動くため、「一度書いた業務知識をプラットフォームをまたいで使い回せる」ことが実務面の最大の価値になっています。

2025年12月18日の更新でAgent Skillsはオープン標準として公開されることが明記され、Anthropic単独の仕様から業界共有の仕組みへ位置付けが移りました。日本語の解説ではSkillsを「Claude Codeの便利機能の1つ」として紹介する記事が多いですが、本家のengineering blogはもっと広い文脈、つまり「汎用エージェントを特化エージェントに変換する設計フレームワーク」としてSkillsを提示しています。本記事ではその意図を読み解きます。

背景 — なぜSkillsという抽象が必要だったのか

エージェントの能力が上がるにつれ、汎用モデルだけでは現場の仕事が回らないという課題がはっきりしてきました。Anthropicが記事内で挙げているのは以下のギャップです。

• 汎用エージェントは一般的な作業はこなせるが、組織固有の手続き(release process / レビュー基準 / コンプライアンスルール)は知らない
• 個別エージェントを毎回ゼロから作るのはコストが高く、知識が再利用できない
• ドメイン専門性を持たせようとすると、すべてシステムプロンプトに詰め込むことになり、コンテキスト窓を圧迫する

この3つを同時に解く道具としてSkillsが設計されています。記事中の表現では「カスタム設計された個別エージェントを構築する代わりに、誰もが専門知識を再利用可能なリソースとしてパッケージ化できる」とまとめられており、「知識のパッケージング単位」を標準化することが狙いだと読めます。

ここでの抽象化の妙は、Skillsが**「ツール」でも「プロンプト」でもなく、その中間**に位置している点です。MCP(Model Context Protocol)サーバーがツール提供層を担うのに対し、Skillsは「いつ・どのツールを・どの順番で・どんな前提のもとで使うか」を教える層として機能します。ツール側の話はMCP実践ガイドで扱っているので併読すると違いが見えやすいかもしれません。

Skillsの構造 — progressive disclosureの三層

Skillsの中核はSKILL.mdと呼ばれる単一ファイルで、Claudeが情報を必要に応じて段階的に読み込むよう設計されています。記事は「目次から始まり、各章、最後に詳細な付録へ進む整理されたマニュアル」という比喩を使って、この情報設計を説明しています。

三層の役割

この設計の効果は、バンドルできる総コンテキスト量が事実上無制限になることです。Anthropicは記事内で「ファイルシステムとコード実行ツールを持つエージェントは、特定のタスク時に全スキルをコンテキストに読み込む必要がない」と書いています。スキルを100個用意しても、システムプロンプトに乗るのはname/descriptionのメタデータだけで、本文や参照ファイルは「呼ばれたときに、呼ばれたぶんだけ」入る形です。

SKILL.mdの最小構造

---
name: pdf-form-filler
description: PDF のフォームフィールドを抽出して記入する手順
---
 
# PDF Form Filler
 
このスキルは PDF のフォーム記入とフィールド抽出を扱います。
詳細手順は [forms.md](./forms.md) を参照してください。
コアスクリプトは scripts/extract_fields.py に置いてあります。

YAMLの name と description は「Claudeが関連性を判断する材料」になるため、ここの精度がSkills全体の使われ方を決めます。記事は「skillのname・descriptionはClaudeの判断基準となるため、慎重に設計すること」を強調しています。日本語で書くプロジェクトでも、descriptionは「いつ呼び出してほしいか」を一文で表現するのがコツになりそうです。

具体例 — PDF Skillが示す「コードと文書の二重化」

記事の中で唯一具体的な実装例として取り上げられているのがPDF Skillです。ClaudeのPDF処理能力を強化する目的で作られており、構成は次のようになっています。

注目すべきはスクリプト実行による効率化で、記事は「Claudeはスクリプト実行により、PDF全体やコード自体をコンテキストに読み込まずにフォームフィールドを抽出できる」と説明しています。つまりSkills内のコードは**「実行されるだけで結果だけ返ってくる」存在**にもなり得る、ということです。

ここから引き出せる設計原則として、記事は「コード、スクリプト、リソース内では、Claudeが直接実行すべきか、参照として読み込むべきかを明確にすること」を挙げています。同じPythonファイルでも、関数定義として読ませたいのか、subprocessで実行して標準出力を返してほしいのかで、Skillの書き方が変わるという話です。

Skillsの作り方 — Anthropicが示す4つの設計原則

記事は実装ガイドラインとして4つの原則を提示しています。本メディアの読者(個人開発者・社内エンジニア)が実プロジェクトに落とす場合、それぞれが何を意味するかを補足しておきます。

1. 評価から始める

「代表的なタスクでエージェントの弱点を特定し、段階的に対応する」という原則です。いきなりSkillsを量産するのではなく、「Claudeが今、何を間違えているか」を観察してから書き始めます。記事はこのプロセス自体を「オンボーディング資料を、新人がつまずいた箇所を見ながら更新する」作業に例えています。

2. スケールを意識して設計する

SKILL.mdが大きくなったら別ファイルに分割する、相互排他的なコンテキストは分離してトークン効率を上げる、という方針です。1つのSkillに5,000トークン分の手順を詰めるよりも、概念ごとに1,000トークンの参照ファイルを5つ用意して本文から参照させた方が、実行時の読み込み量が少なくなります。

3. Claudeの視点で考える

nameとdescriptionはClaudeが「今、このスキルが必要か」を判断する材料です。「コードレビュー」のような曖昧な名前ではなく、「TypeScriptの型安全性に関するレビュー」のように発火条件が読める形にすると呼び出し精度が上がります。

4. Claudeと反復する

「Claudeに成功パターンや失敗事例を学ばせ、必要なコンテキストを実装する」という原則。Skills自体の改善ループにClaudeを巻き込む、いわゆるメタな運用です。Claude Code上でSkillを使ってみて、誤った呼び出しがあればdescriptionを直し、足りない手順があれば本文に追記する、という流れが想定されています。Skillsの具体的な書き方パターンはClaude Code Skillsの書き方 — 使える5つのパターン集でカタログ化しているので、原則を実例に落とすときの参考になります。

Tools / MCPとの位置付け — 「実行手段」と「使い方の文脈」の分離

エージェント設計を始めると最初に混乱するのが、SkillsとToolsとMCPサーバーの役割分担です。記事は明示的な比較表を出していませんが、本文の表現から整理すると以下のように位置付けられています。

記事は「Skillsは外部ツール・ソフトウェア連携を伴う複雑なワークフロー教育でMCPを補完する役割を果たしうる」と表現しており、両者は対立ではなく補完関係として描かれます。MCPは「何ができるか」、Skillsは「どう使いこなすか」を担う、という分担です。

実務上は次の判断基準が使えそうです。

• 新しい外部システムにアクセスしたい → MCPサーバー側でToolsを増やす
• 既存ツールの組み合わせ方や前提知識を共有したい → Skillsを書く
• 頻繁に変わる業務手順をモデルに学ばせたい → Skills(ファイルなのでgitで管理しやすい)

Claude Code全体の設定としてこれらをどう束ねるかはClaude Code完全ガイド2026で扱っているので、Skillsを入れる位置を全体地図と照らし合わせると理解が早まります。

セキュリティ — 「Skillを入れる」は「コードを入れる」と同じ

Skillsは便利な反面、実行可能なコードと命令を含むパッケージであるため、信頼境界の扱いが重要になります。記事は警告として以下を挙げています。

• 悪意あるSkillは環境に脆弱性を導入したり、データ流出指示を出す可能性がある
• 信頼できるソースからのみインストールすることを推奨
• 外部ソースのSkillは使用前に内容を精査
• ファイル、コード依存関係、画像・スクリプトなどバンドルリソースを検査
• 外部ネットワーク接続指示に注意

ここで効いてくるのは「Skill = npmパッケージやDockerイメージと同じカテゴリのもの」という認識です。npmに何でも入れないように、Skillsも何でもインストールしないというだけの話ですが、Markdownファイルに見えるぶん油断しやすいので注意点として明記されています。Claude Code自体の権限設計やセキュリティ運用はClaude Codeのセキュリティ設計を参照すると、Skillを導入する際のリスク評価のベースが揃います。

「オープン標準化」の意味 — Anthropic単独仕様から業界仕様へ

記事末尾の2025年12月18日付更新で、Agent Skillsがオープン標準として公開されることが明記されました。これは単なるライセンス開放ではなく、「Skillsという形式をAnthropic製品以外でも採用できる」ことを意味します。

ここから読み取れる戦略意図は次のようなものです。

• Anthropicはモデルとプラットフォーム(Claude Code / Cowork / Agent SDK)で覇権を取りに行くと同時に、「業務知識のパッケージ形式」でも標準を握ろうとしている
• MCPがツール提供層の標準として定着しつつあるのと同様に、Skillsを「業務知識の標準形式」として広げる狙いがある
• オープン標準化により、Anthropic以外のエージェントでも同じSkillを解釈できるエコシステムが生まれる可能性がある

これが意味するのは、企業や個人が時間をかけて書いたSkillが特定ベンダーにロックインされないということです。SKILL.mdという単純なMarkdown形式が「業務知識の単位」として共有可能になれば、Skillを100個書いた組織は、それ自体が転用可能な資産を持つことになります。Claudeエコシステム全体でのSkillsの位置付けはAnthropicのAgent SDKクイックスタートとあわせて読むと、API層・SDK層・知識層の関係が立体的に見えてきます。

Skillsが変えるもの — 「エージェント設計」から「知識パッケージ設計」へ

ここまでの内容を踏まえて、編集視点でSkillsが示している思想転換を見ていきます。Anthropicの記事は明示しませんが、行間から読み取れるのは「カスタムエージェントを作る時代から、汎用エージェント + 知識パッケージの時代への移行」です。

従来の発想では、ある業務に対して専用のエージェントを設計し、専用のシステムプロンプト・専用のツール群・専用の評価基準をセットで作っていました。これは初期コストが高く、業務が変わるたびに作り直しが必要でした。

Skillsの発想では、汎用Claude + 業務固有のSkills群という構成になります。新しい業務が増えてもSkillsを書き足すだけで、エージェント本体は同じです。さらにprogressive disclosureによりSkillsが増えてもコンテキスト圧迫が起きにくく、スケール可能な知識ベースとして運用できます。

この変化は、ソフトウェア開発で言えば「モノリス → マイクロサービス」の構造変化に近いところがあります。エージェント機能を1つの大きなプロンプトに詰め込むのではなく、疎結合な知識単位に分解して必要時に呼び出すという設計に向かっている、と読むこともできるかもしれません。Claude Codeでこれを実プロジェクトに落とすときの手触りはClaude Code開発ワークフロー集に近い形になりそうです。

まとめ

Anthropicのengineering blog記事「Equipping agents for the real world with Agent Skills」は、Skillsを「業務知識のパッケージ単位」として標準化する試みを示しています。SKILL.mdとprogressive disclosureの三層構造により、コンテキスト窓を圧迫せずに大量の業務知識を扱える仕組みが整い、Claude Code / Claude.ai / Agent SDK / Developer Platformの4系統で共通仕様が動きます。

技術的に重要なのは「コードと文書の二重性」で、SKILL.md内のスクリプトは「Claudeが読む対象」にも「Claudeが実行する対象」にもなり得ます。設計原則としては評価から始めること、スケールを意識すること、Claude視点で書くこと、Claudeと反復することの4つが提示されています。

Tools / MCPとの関係では、Skillsは「いつ・どう使うか」の手続き知識を担い、MCPの「何ができるか」を補完する位置付けです。セキュリティ面ではSkill = 実行可能コードを含むパッケージという認識が必要で、信頼できないソースの導入には監査が必要です。

2025年12月のオープン標準化により、SkillsはAnthropic単独仕様から業界共有の仕組みへ移行しました。書き方の具体パターンはClaude Code Skillsの書き方 — 使える5つのパターン集、Tools層の理解はMCP実践ガイド、Claudeエコシステム全体の文脈はClaude Code完全ガイド2026で補完できます。Skillsを実プロジェクトに導入するときは、まず1つの業務(例: PRレビュー / 記事生成 / リリース手順)を選び、評価 → 試作 → 反復という小さなループから始めるのが、記事が示す設計原則と整合する進め方になりそうです。