Agent SkillsがLinux Foundationへ──SKILL.mdはエージェント連携の共通語になるか

エージェントに同じ作業を頼むたび、手順をチャットに貼り直していませんか。リポジトリごとに指示ファイルが増え、どれが最新かわからなくなり、詳しい人に聞かないと実行できない——。Agent Skillsは、この「手順の属人化」を、フォルダとMarkdownで配布する仕組みとして標準化しました。

2026年10月22日、AnthropicはAgent SkillsをLinux Foundation配下のAgentic AI Foundation（AAIF）へ寄贈すると発表しました。MCPに続いて、エージェント向けの標準がベンダー中立の財団へ移ります。この記事では、仕様の中身、実装例、MCPやAGENTS.mdとの違い、コンテキスト設計、セキュリティ、そしてチームで導入する判断までを整理します。

30秒でわかる結論

Agent Skillsは、SKILL.mdと任意のscripts・references・assetsを1つのフォルダにまとめた配布単位。
2025年10月にClaude Code向けに登場し、2025年12月にオープン標準化。2026年10月22日にAAIFへ寄贈された。
Anthropicの発表によると、70以上のエージェント製品が採用し、公開数は100万、インストールは約2.8億に達する。
起動時はnameとdescriptionだけを読み、必要になったとき本文、さらに必要なら参照ファイルを読む3段階の開示。
MCPは「接続」、Skillsは「手順」。競合ではなく、層が違う。導入は繰り返している手順1つから始める。

何が起きたのか：Agent Skillsの3年史

時系列を整理します。2025年10月、AnthropicはClaude Codeのための機能としてスキルを公開しました。汎用的な知識は扱えても、業務固有の手順を知らないという課題に対して、手順そのものをファイルとして渡すアプローチです。数週間で数千のスキルがGitHubに公開され、CodexやCursor、OpenCode向けのローダーもコミュニティから出ました。

2025年12月には、特定ベンダーの機能からオープン標準へ移行します。専用のGitHub organizationとagentskills.ioドメインが用意され、仕様が公開されました。そして2026年10月22日、Anthropicは標準の名称、ロゴ、GitHub organization、ドメインをAAIFへ寄贈すると発表しました。AAIFはLinux Foundationの下にあり、AnthropicがBlock、OpenAIと共同で設立した団体です。MCPもすでに同じ場所へ寄贈されています。

発表では、今後のロードマップとしてバージョン付きリリース、正式な提案プロセス、スキルを書く人と導入する人のためのセキュリティガイダンスが提案されています。維持はAnthropic、Google、OpenAIなどのエンジニアが個人として担い、David Soria ParraとMahesh Muragがリードメンテナーを務めます。

寄贈先が財団であっても、仕様の実装が自動で揃うわけではありません。フィールドの解釈やスクリプトの実行可否は製品ごとに差があります。導入時は「どのクライアントで動かすか」を先に決めてください。

課題の整理：なぜプロンプトでは足りないのか

エージェント活用が進むと、次の3つの失敗が繰り返し起きます。

毎回説明する。同じリリース手順、同じレビュー観点、同じ画像変換の手順を、会話のたびに貼り付ける。トークンも時間も浪費し、言い忘れが品質のばらつきになる。
指示ファイルが肥大化する。AGENTS.mdやCLAUDE.mdにすべてを書き、常に全文がコンテキストへ載る。関係ない作業でも大量のトークンを消費し、重要な指示が埋もれる。
属人化する。手順が個人のチャット履歴やWikiに散らばり、更新されない。新人は同じ失敗を繰り返す。

Skillsは、この3つに対して「発見可能性」「段階的な読み込み」「配布単位」を用意します。プロンプトの改善ではなく、手順のパッケージ化とでも言うべき変化です。

仕様：SKILL.mdとディレクトリ構成

スキルは、最低1つのSKILL.mdを含むディレクトリです。任意でscripts、references、assetsを置けます。ファイル構成に強い制約はなく、必要なファイルを同じフォルダにまとめられます。

Bash

link-audit/
├── SKILL.md
├── scripts/
│   └── check_links.py
└── references/
    └── policy.md

SKILL.mdはYAMLのfrontmatterとMarkdown本文で構成します。必須はnameとdescriptionの2つだけです。ほかにlicense、compatibility、metadata、実験的なallowed-toolsがあります。

フィールド	必須	制約
`name`	はい	64文字以内。小文字英数字とハイフンのみ。ディレクトリ名と一致させる
`description`	はい	1024文字以内。「何をするか」と「いつ使うか」を書く
`license`	いいえ	ライセンス名、または同梱ファイルへの参照
`compatibility`	いいえ	500文字以内。必要な実行環境やパッケージ
`metadata`	いいえ	文字列キーと文字列値のマップ
`allowed-tools`	いいえ	空白区切りのツール名。実験的で対応差がある

nameの制約は思ったより厳格です。大文字は使えず、先頭と末尾のハイフン、連続するハイフンも禁止されます。ディレクトリ名と一致しないと検証で落ちます。

descriptionは短ければ短いほどよい？→ 逆です。エージェントはこの1文だけを見て「使うかどうか」を判断します。「PDFを扱うときに使う」のような曖昧な説明では発見されません。対象・操作・トリガーとなるキーワードを入れます。

実装：最小のスキルを作る

まずはスクリプトなしの最小構成です。記事のリンク切れを検査する手順をスキルにしてみます。

TEXT

---
name: link-audit
description: 記事HTML内のリンク切れを検査し、修正候補を表形式で報告する。公開前のリンク確認や、CMS記事の一括点検を依頼されたときに使う。
license: MIT
metadata:
  version: "1.2"
---

# リンク切れ監査

## 手順
1. 対象ファイルのパスを受け取る
2. scripts/check_links.py を実行する
3. 失敗したURLを references/policy.md の基準で分類する
4. 結果を表形式で報告する

## 出力
| URL | 状態 | 対応 |
| --- | --- | --- |
| 例 | 404 | 代替URLを提示 |

本文には、エージェントが迷わない粒度で手順を書きます。仕様では、SKILL.md本体を500行以内に保ち、詳細は参照ファイルへ逃がすことが推奨されています。本文は「実行の順番」と「判断基準」に絞り、網羅的なリファレンスはreferencesに置くのが基本です。

frontmatterのmetadataは自由なキーを書けますが、クライアントによっては無視されます。バージョン管理に使いたい場合は、本文にも変更履歴を書いておくと確実です。

実装：スクリプトと参照ファイルを分ける

定型処理はスクリプトにします。エージェントに毎回コードを書かせるより、検証済みのスクリプトを実行させるほうが再現性が高く、トークンも節約できます。

Python

"""Markdown内のhttpリンクを検査する。"""
import re
import sys
import urllib.request
from pathlib import Path

LINK = re.compile(r"\[[^\]]+\]\((https?://[^)]+)\)")

def check(path: Path) -> int:
    urls = set(LINK.findall(path.read_text(encoding="utf-8")))
    failed = 0
    for url in sorted(urls):
        request = urllib.request.Request(
            url,
            method="HEAD",
            headers={"User-Agent": "link-audit/1.2"},
        )
        try:
            with urllib.request.urlopen(request, timeout=10) as response:
                status = response.status
        except Exception as error:
            print(f"NG {url} {error}")
            failed += 1
            continue
        if status >= 400:
            print(f"NG {url} {status}")
            failed += 1
    return failed

if __name__ == "__main__":
    sys.exit(1 if check(Path(sys.argv[1])) else 0)

スクリプトは自己完結させ、依存関係と前提をcompatibilityに書きます。ネットワークアクセスが必要なら、その旨も明記します。エラー時は原因がわかるメッセージを出し、終了コードで成否を返すと、エージェント側が結果を解釈しやすくなります。

参照ファイルはSKILL.mdから1階層だけ深く置きます。深いネストは、エージェントがファイルを辿るコストを上げ、参照漏れの原因になります。

配布とバージョン管理

スキルはフォルダなので、配布方法はGitリポジトリ、社内レジストリ、npmパッケージ、あるいは単純なコピーのいずれでも構いません。重要なのは、バージョンを固定して配ることです。手順は業務の前提を含むため、無断で更新されると実行結果が変わります。

Bash

# 仕様に沿っているかを検証する
npx skills-ref validate ./link-audit

# リポジトリではタグで固定する
git tag link-audit-v1.2.0
git push origin link-audit-v1.2.0

参照実装のskills-refは、frontmatterの必須項目、nameの形式、ディレクトリ名との一致などを検査します。CIに組み込んでおくと、命名規則の違反がレビュー前に落ちます。

チームで運用する場合は、metadataのversionとGitタグを対応させ、変更履歴をSKILL.mdの末尾に残すと追跡しやすくなります。破壊的な変更はメジャー、手順の微修正はパッチとして扱う、といった緩い規約で十分です。

比較：MCP・AGENTS.md・Skills

よく混同される3つを整理します。どれか1つを選ぶ話ではなく、役割が違います。

仕組み	役割	単位	向く用途	注意
MCP	外部システムへの接続	サーバーとツール	DB、API、ファイル、SaaSの操作	認証と権限設計が中心
AGENTS.md	リポジトリ固有の常時指示	1ファイル	コーディング規約、禁止事項	肥大化しやすく、常にコンテキストを消費
Agent Skills	手順と知識の配布	フォルダ	リリース手順、レビュー観点、変換処理	発見性は`description`次第

たとえば「社内のデザインシステムからコンポーネントを生成する」なら、MCPがデザイントークンへ接続し、Skillsが生成手順とレビュー観点を提供し、AGENTS.mdがリポジトリ固有の禁止事項を書く、という分担になります。3つを1つの巨大な指示ファイルに押し込むと、どれも保守できなくなります。

コンテキスト設計：progressive disclosure

Skillsの設計で最も実務的な価値があるのが、読み込みの段階化です。仕様では次の3段階が推奨されています。

メタデータ：全スキルのnameとdescriptionを起動時に読む。目安は1スキル約100トークン。
本文：スキルが有効化されたときだけSKILL.mdを読む。目安は5,000トークン未満。
リソース：scriptsやreferencesは必要になったときだけ読む。

仕様の目安で試算すると、10個のスキルを登録しても起動時の負担は約1,000トークンです。1つが有効化されると本文が加わりますが、残り9個の本文は読まれません。すべてをAGENTS.mdに書く場合、10手順分が毎回のコンテキストに載ります。手順が増えるほど差は広がります。

この設計は、エージェントの注意力を「今の作業に必要な情報」に集中させる効果も期待できます。ただし、descriptionが曖昧だと有効化されず、本文が読まれません。発見性はメタデータの質に依存します。

ハマりどころ

descriptionが一般論になっている。「開発を支援する」では発見されません。対象、操作、トリガーを具体的に書きます。
nameがディレクトリ名と違う。検証で落ちます。小文字とハイフンに統一します。
本文が長すぎる。500行を超えると、読み込みコストが増え、指示の優先順位も曖昧になります。詳細は参照ファイルへ。
allowed-toolsを過信する。実験的なフィールドで、製品によっては無視されます。権限制御は実行環境側でも行います。
クライアント差。スクリプトの実行可否、参照ファイルの自動読み込み、対応するfrontmatterは製品ごとに異なります。同じスキルが全製品で同じように動く前提は置けません。
パスの前提。相対パスはスキルのルート基準です。絶対パスやホームディレクトリ前提のスクリプトは移植できません。

スキルが有効化されたかどうかは、クライアントのログや実行トレースで確認できます。「動かない」と思ったときは、まずdescriptionが検索にヒットしているかを見てください。本文の書き方より先に、発見の段階で失敗していることが多いです。

セキュリティとガバナンス

Skillsは手順とスクリプトのパッケージなので、配布経路はサプライチェーンになります。次の4点を運用に組み込みます。

出所の確認。外部のスキルは、作者、リポジトリ、ライセンス、最終更新を確認します。匿名のスキルを業務リポジトリへ直接置かない。
差分レビュー。スキルの更新はコードレビューと同じ扱いにします。とくにscriptsの追加・変更は必ず目を通します。
最小権限。スクリプトが触れる範囲を限定します。本番の認証情報や書き込み権限を、検証用のスキルへ渡さない。
固定と監査。バージョンをタグで固定し、どのスキルのどのバージョンで実行したかをログに残します。

AAIFはロードマップとしてセキュリティガイダンスの整備を提案していますが、執筆時点では策定中です。標準化されたから安全、ではなく、配布物として審査する体制が必要です。とくにallowed-toolsは実験的であり、これだけで権限を制御できると考えるのは危険です。

本番投入の判断

自分なら使うか：今すぐ使う。 ただし、社内の反復手順に限定します。リリース前チェック、記事のリンク監査、画像の一括変換、レビュー観点の提示など、手順が固まっていて成果物が検証できるものが向きます。最初の1つは、週に何度も同じ説明をしている作業から選ぶのが鉄則です。

条件付きになるのは、外部配布とスクリプト実行を伴う場合です。社外へ配るスキルは、ライセンス、サポート範囲、更新方針を決め、実行するスクリプトの権限を最小化します。逆に、手順がまだ流動的で、毎回判断が変わる作業をスキル化すると、古い手順が固定化されて害になります。手順が安定してからパッケージ化してください。

移行手順：既存の手順書をスキルにする

手順を1つ選ぶ。週1回以上繰り返し、入力と出力が明確で、成功条件を検証できるものを選びます。
手順書を分解する。実行手順、判断基準、参照資料、定型処理に分けます。定型処理はscripts、判断基準は本文、網羅的な資料はreferencesへ。
frontmatterを書く。nameはディレクトリ名と一致させ、descriptionには対象・操作・トリガーを入れます。
検証する。skills-ref validateを通し、実際のタスクで1回実行して、出力が期待どおりか確認します。
バージョンを切る。タグを打ち、変更履歴を残します。以後の更新はレビュー必須にします。