Microsoft が Skill を MCP に載せたあと、発見がまだ JSON な理由：SEP-2640、skill://index.json と skills/list

結論から：Skill を MCP に載せたあと、手順書は Markdown でよい。発見契約はなお JSON である。2026 年 9 月 16 日、Microsoft Agent Framework の Tommaso Stocchi が並びの記事を出した：スキー場アドバイザーを「専門家ごとにモデルを回す」から「親 Agent が必要時に Skill を読み、MCP ツールを直接呼ぶ」へ変えた。サービスはなお分散。推論は親コンテキストへ戻す。本サイト 9 月 11 日の MCP / Skills / Tools / Subagents は四層の分担を書いた。本稿が足すのは 11 日以降のことだけ：発見ドキュメントがどんな形か、SEP-2640 がどこで止まっているか、なぜ先に JSON を一通検証すべきか。

本稿は 2026 年 9 月 22 日時点。SEP-2640（Skills Extension）は 9 月 3 日に Accepted と記された。Final ではない。Microsoft のデモが釘付けにしているのは歴史的 Draft の skill://index.json。新しい草案は skills/list / skills/get。二つの発見形状が同時に走っている。「Skill が Agent を置き換えたか」より、互換性を先に見よ。

9 月 16 日に実際に出たもの

Stocchi の原文タイトルは From Specialist Agents to Distributed Skills over MCP。スキー場アドバイザーはもともと A2A で四人の専門家を呼んだ：天気、安全、スキーコーチ、リフト待ち。各専門家が指示、ツール、モデルループを持っていた。第二条の経路は同じ領域サービスを MCP Provider にする：それぞれ説明、SKILL.md、型付き MCP ツールを出す。アドバイザーは MAF の SkillsProvider と MCPSkillsSource で発見と読み込みをする。SkillToolsMiddleware は load_skill が成功したあと、その Provider のツールを次のモデルターンへ掛ける。

ウェブ調査はなお普通の Agent ツール。意図した混成である：自律が要るところは自律のまま、能力に落とすところは Skill にする。四つの MCP エンドポイントは /skillsmcp。リソース面はたいていこれだけ：

skill://index.json
skill://<skill-name>/SKILL.md

skill:// が識別するのはすでに繋がった MCP 接続上のリソースであり、ホスト名ではない。Skill 本文が自分で新しいネットワークホップを開くこともできない。認証、転送、認可はなおインフラとコードにあり、Markdown にはない。

MCP が A2A を置き換えるのではない

原文は境界をきれいに書いている。A2A はタスクを別の推論ループへ渡す。Distributed Skill は能力と操作を今の推論ループへ渡す。表一枚で足りる：

関心	Agent をツールにする（A2A）	Distributed Skill
親 Agent が発見するもの	呼べる専門家 Agent	読み込める能力
専門家の指示はどこで走るか	専門家自身のモデルコンテキスト	親 Agent のモデルコンテキスト
誰が領域操作を選ぶか	専門家モデル	親モデル
リモートで実行するもの	専門家ループ + そのツール	MCP ツール + 背後のサービス
なお分散しているもの	Agent、サービス、データ	Skill Provider、サービス、データ

Agent Card の名前と説明は発見エントリになる。システムプロンプトは SKILL.md になる。ツール引数は MCP の input / output Schema になる。業務サービスはツール処理関数の後ろに残る。Card 上のエンドポイント、認証、転送能力は Skill 説明へ書くな。これは 11 日の稿と同じ：Skills は手順書、MCP はソケット、Tools は契約。変わるのは手順書の発見の仕方であり、三層を一層に潰すことではない。

発見契約：skill://index.json

オーケストレータは毎回のリクエストで全手順書を食う必要はない。ルーティングに足りる目録が要る。デモの天気 Provider の索引は：

{
  "$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
  "skills": [
    {
      "name": "weather",
      "type": "skill-md",
      "description": "Weather intelligence agent providing real-time conditions, forecasts, and storm alerts for the ski resort",
      "url": "skill://weather/SKILL.md"
    }
  ]
}

これは Agent Skills の発見索引に MCP 意味を足したもの：url はリソース URI であり、https ホストではない。$schema は schemas.agentskills.io の discovery 0.2.0 を指す。説明は「いつこの能力を使うか」に答える。SKILL.md は「どう使うか」——weather_forecast のような操作を名指しし、区間、単位、観測の捏造禁止。操作そのものの型と範囲は、なお MCP tools/list が出す JSON Schema が決める。

親 Agent は起動時に MCP 経由で目録と tools/list を取る。モデルが最初に見るのは Skill 要約と読み込みヘルパーであり、全操作 Schema ではない。load_skill("weather") のあと、ミドルウェアがその組のツールを掛ける。ツールがコンテキストに出たことは、実行したことではない。

SEP-2640：Accepted、Final ではない

SEP-2640 は Extensions Track 上の Skills バインディング：MCP Resources で Agent Skills を出す。拡張識別は io.modelcontextprotocol/skills。ディレクトリ構造、YAML frontmatter、段階的開示はなお Agent Skills 仕様の管轄。SEP が決めるのは輸送だけ。

Stocchi 文中の 9 月 10 日時点の照合：9 月 3 日改訂が状態を Accepted とし、発見面を skills/list と skills/get に変えた（ページング可、エントリは uri、解析済み frontmatter、sha256: digest 付きリソース目録）。対応 PR は当時まだ未マージ。デモが釘付けにしているのはより早い Draft：skill://index.json を読み、新しい二つのメソッドは実装しない。孵化リポジトリはなお Experimental。

だから伝聞の「9 月 13 日 Final」を本番チェックリストへ書くな。2026 年 9 月 22 日に確定できるのは：Accepted、未 Final、二つの発見形状が並存。Draft 索引を「コア MCP の必須項」とみなすのは、原文自身の脚注と逆である。

ツール契約はなお JSON Schema

天気予測はデモでは Range(1, 24) の hours を取り、UseStructuredContent を開いている。SDK がツール定義を出し、処理関数が先に範囲を検証し、それから領域サービスへ渡す。SKILL.md はどのツールを選ぶかを導く。パラメータ Schema の代わりにはならないし、サーバ側検証の代わりにもならない。

権威ある操作定義は tools/list から来る。実行は tools/call。手順書は resources/read。三ホップとも JSON-RPC。Skill は「ページングせよ」と言えるが、cursor を永続化してはくれない。「承認せよ」と言えるが、認可はしてくれない。これは Tool Calling が JSON Schema に依存する理由と同じ層：散文が道を選び、契約が不正な引数を止める。

三対の計測：速いが、token が安いとは限らない

同じプロンプト（天気と待ち時間を考慮して、どこから始めるべきか）、同じ Aspire アプリ、gpt41、三対の新しい会話。A2A 経路は 6 / 6 / 7 回のモデル呼び出し（専門家は並列可）。Skills 経路は毎回 3 回：先に load_skill、それから MCP 操作を直接打ち、それから最終返答。クライアントのウォールクロック平均はおよそ 6.35 秒対 15.48 秒。

token は減っていない。三回合計、Skills 側で観察されたのは約 13,533、A2A は約 11,134、およそ 22% 多い。モデルホップが少ないことは、累積コンテキストが小さいことではない——手順書、グループ Schema、結果は三回の呼び出しで積み上がる。A2A のキャッシュ計数は不完全。これは請求書の比較ではなく、対照実験でもない。原文自身が書いている：三対の例示であり、同じ正しさや完全さの証明ではない。

持ち帰れる構造観察は一文だけ：落ちるのは入れ子の専門家ループであり、JSON 往復ではない。発見索引、ツール Schema、構造化結果のホップは残る。ただ「専門家がそれぞれ一通り話す」から「親コンテキスト内の数通の契約」へ収まった。

二つの発見形状、Host が噛み合わない

2026 年 8–9 月ですでに裂け目は見えていた。Microsoft.Agents.AI.Mcp の UseMcpSkills はなお skill://index.json を読む。skills/list だけ実装した Server には「index リソースがない」と記す。新草案どおり索引だけ出し、拡張を宣言せず digest もしない Server は、新しい Host には見えない。索引ベースの Server をすでに legacy と印す Host もある。

実装時に「どちらが勝つか」を賭けるな。目録が小さければ両方出せ：Draft 索引を古いクライアントへ、skills/list / skills/get を拡張を宣言した Host へ。索引が欠けている、または空であることは、「この Server に Skill はない」と Host に読ませてはならない——草案は、大きい目録や動的生成の目録に部分列挙を許している。

いまもローカルで検証する三つの JSON

発見ドキュメント。skill://index.json または skills/list のエントリ：name、type、description、url / uri。$schema と照合。余分なキー、空の説明、url に https ホストを書くのはルーティング誤りであり、文案の問題ではない。
ツール Schema。tools/list から inputSchema を取る。必須を埋め、additionalProperties: false、列挙と範囲を締める。Skill 本文が名指しするツール名は、一覧の名前と一致しなければならない。
構造化結果。デモは Structured Content を開いている。親モデルへ戻す output はなお合法 JSON であるべきで、それから Schema で検証する。データベース行ごとやスタックを戻すな。Agents API のあと JSON がより必要な理由を見よ。

ローカル JSON ツールで発見ドキュメントを見る

MAF や任意の Host に繋ぐ前に、ブラウザで三つのテキストを広げよ：発見索引、tools/list の Schema 一通、サンプル tools/call の arguments。

JSONバリデーター — 文法が合法か；Schema があればフィールド、必須、余分なキーを合わせて見る。
JSONフォーマッター — 一行に潰した index を展開し、url が本当に skill:// かを見る。
JSON Diff — Draft 索引エントリと skills/list エントリを比べ、二つの目録が食い違わないようにする。

データはブラウザを出ない。発見契約が安定してから、親 Agent に SKILL.md を読ませよ。手順書は言い回しを変えてよい。フィールド名と URI は週ごとに動かしてはならない。

FAQ

SEP-2640 はいま Final か？

いいえ。9 月 3 日改訂は Accepted。Microsoft の 9 月 10 日照合ではまだ未マージの PR があった。デモが使うのは歴史的 Draft の skill://index.json。「すでに Final」で古いクライアントを切るな。

Distributed Skill は A2A を置き換えるか？

一刀両断にはならない。独立したライフサイクル、非公開コンテキスト、専用モデルが要るものは、なお Agent であるべきだ。手順書と操作だけで足りるものだけ Skill へ移せ。原文がウェブ調査を Agent ツールのまま残したのは、その区別である。

skill:// は解決すべき URL か？

いいえ。すでに設定済みの MCP 接続上のリソースを識別する。Skill 本文がそれを使って別ホストへ繋ぎ直すことはできない。

SKILL.md があれば JSON Schema は不要か？

要る。Markdown はツール選択と結果の読み方を導く。パラメータの型、範囲、必須はなお tools/list の Schema と、あなた自身の二次検証の仕事である。

skill://index.json だけ実装すれば足りるか？

いまの一部 Microsoft クライアントには足りる。新しい草案の Host には足りない。目録が小さければ両方出せ。一方だけだと、もう半分の Host には見えない。

Skills 経路はより安いか？

デモではウォールクロックは速く、観察された token はおよそ 22% 多い。対照実験ではない。先にルーティングと構造化結果が正しいかを比べ、それから請求を見よ。

まとめ

9 月 16 日のデモは「Agent は時代遅れだ」と宣言していない。宣言したのは：入れ子の推論が要らない能力は、手順書と操作だけを配り、発見面は JSON でよい、である。サービス境界は残る。落ちるのは専門家モデルループ。まだ握っているのは発見索引、ツール Schema、構造化結果。

SEP-2640 はなお Accepted。Draft 索引と skills/list はしばらく並んで生きる。先にローカル検証で三つの JSON を平らに見てから、Host へ渡せ。11 日の層分けは廃れていない。廃れたのは「Skill はローカルフォルダだけ」という既定である。モデルと harness は版を替える。name、url、inputSchema は一緒に緩めてはならない。