次世代AIエージェントを読み解く「5つの必須用語」Microsoft編：Copilot Studio / Microsoft Foundryで何が起きているか
1. イントロダクション：前回のおさらいと、なぜ「Microsoft編」か
前回の記事では、AIエージェントを理解する上で欠かせない5つの必須用語――agents.md、Agent Skills、MCP（Model Context Protocol）、A2A（Agent to Agent）、Subagents――を、主にAnthropicやGoogleの文脈で整理しました。
https://blogs.itmedia.co.jp/osonoi/2026/07/ai5_3.html
では、企業のAI活用で最も導入が進んでいるプラットフォームの一つ、Microsoftの「Copilot Studio」「Azure AI Foundry」(現在は「Microsoft Foundry」に名称統合)ではどうなっているのでしょうか。結論から言うと、Microsoftはこれらの業界標準を傍観するのではなく、むしろ積極的に取り込むという姿勢を取っています。ある社内アーキテクトの発言を借りれば、拡張性における最優先事項はMCP、僅差でAgent2Agentプロトコルが続くという位置づけです。
本記事では、5つの用語がMicrosoft Foundry / Copilot Studioの世界でどう実装されているか、そして実務でCopilot Studioを触ると出てくる「説明」「指示」「ナレッジ」「トピック」「ツール」「チャンネル」といった画面用語が、5つの用語のどれに対応するのかを整理します。
2. MCP -- Microsoftが「100%受け入れる」と明言した標準
MCPはCopilot Studio・Microsoft Foundry Agent Serviceの両方で一般提供(GA)済みです。Microsoftの担当者は、拡張性の観点でMCPを最優先事項に位置づけ、全面的に採用していく方針を明言しています。
Foundry側の実装は前回紹介したAnthropic/Google陣営よりむしろ手厚いほどです。
- クラウドホスト型のFoundry MCP Server：VS CodeやVisual Studioから直接接続でき、IDEのMCP設定に追加するだけで使えます。
- Toolboxes（プレビュー）：複数のMCPサーバー・OpenAPIツール・A2A接続を一つのMCP互換エンドポイントにまとめ、認証やライフサイクル管理を一元化できる機能です。
- Copilot Studio側にも「MCP Connector」というツールが追加され、ローコード環境からもMCPサーバーに接続できます。
3. A2A -- 「MCPの次」に優先される協調プロトコル
A2Aは、Microsoftの拡張性戦略における優先順位でMCPに次ぐ2番目の位置づけとして明言されています。実装としては、Copilot Studioの「Connected Agents（接続エージェント）」機能や、FoundryのToolboxesが A2A接続をサポートしており、Copilot StudioからFoundry上のエージェントをA2A経由で呼び出す実装例(学習アシスタントが化学の質問を専門の化学エージェントへ委譲するデモなど)も公開されています。
4. Agent Skills -- フォーマットレベルでそのまま採用
5つの用語の中で最も興味深いのがこれです。MicrosoftはAgent Skillsについて独自形式を作るのではなく、SKILL.mdファイルという形式そのものを採用しました。
Microsoft Agent FrameworkとFoundryは、Foundry側のSkills REST APIでSKILL.mdを一元管理し、エージェントは必要になった時だけ内容をロードする「progressive disclosure（段階的開示）」というパターンを実装しています。具体的には次の3段階です。
- Advertise（広告）：スキル名と説明をシステムプロンプトに注入し、エージェントに存在を知らせる
- Load（読み込み）：エージェントが関連性を判断したら、スキル本体を取得する
- Read resources（資料参照）：参考資料などの付随コンテンツがあれば、必要な時だけ読み込む
これは前回紹介した「ジャストインタイムな学習」とまったく同じ設計思想であり、フォーマットレベルでの事実上の相互運用性が生まれている珍しいケースと言えます。
5. Subagents -- 「Connected Agents」「宣言的オーケストレーション」として実装
純粋な「サブエージェントを一斉にスポーンして並行処理する」というAnthropic的な実装というより、Copilot Studioの「Connected Agents」パターンや、Agent Frameworkの「宣言的オーケストレーション（特化エージェント間でのハンドオフ）」という形で、複数の専門エージェントに処理を委譲する設計思想が実装されています。並行実行というよりオーケストレーション寄りの実装ですが、単一エージェントの限界を突破するという目的は共通しています。
6. agents.md -- やや不透明なポジション
ここだけは明確な採用表明が見当たりませんでした。GitHub Copilot Agent Modeでは.agent.mdファイルでエージェントの振る舞いを定義する仕組みがあり、思想的には近い位置にありますが、agents.md自体への直接対応は確認できていません。他の4項目に比べると温度差がある部分です。
7. Copilot Studioの画面用語との対応表
実際にCopilot Studioを触ると、「説明」「指示」「ナレッジ」「トピック」「ツール」「チャンネル」といった用語が出てきます。これらは5つの用語ときれいに1対1対応するわけではありません。
| Copilot Studioの用語 | 役割 | 対応する概念 | 補足 |
|---|---|---|---|
| 説明 | オーケストレーターがツール・トピック・ナレッジ・他エージェントの中から「どれを呼ぶか」を判断する材料 | Agent Skillsのdescriptionメタデータ、A2AのAgent Card |
どちらも「相手に自分の能力を伝える自己紹介文」という点で本質的に同じ役割 |
| 指示 | エージェント自身の振る舞い・トーン・ガードレールを定義する本文 | agents.md（プロジェクト固有のルールをエージェントに伝える指示書）に近い | agents.mdはコーディングエージェント向け、指示は会話エージェント向けという用途の違いはある |
| ナレッジ | SharePointやWeb等を根拠にした回答生成（グラウンディング） | 対応なし | MCP経由でナレッジソースを繋ぐケースもあるが、機能軸自体は独立 |
| トピック | 決まった会話フローを組み立てるノーコード機能 | 対応なし | Copilot Studio固有の実装機能 |
| ツール | MCPコネクタ、カスタムAPI、Power Automateフローなどを呼び出す入り口 | MCP | 「MCP Connector」の追加先がここ |
| チャンネル | Teams、Web、Slack、LINEなど公開先 | 対応なし | エージェントの内部構造ではなく配信・デプロイの話 |
| （他のエージェントを呼ぶ機能） | マルチエージェント連携 | A2A、Subagents | 「Connected Agents」として実装。指示文中で/から他エージェントを参照できる |
まとめると、MCP→ツール、Agent Skills/A2A→説明、agents.md→指示はわりと明確に対応する一方、ナレッジ・トピック・チャンネルはCopilot Studio独自の機能軸であり、5つの用語のどれとも直接は結びつきません。これらは「業界標準」ではなく、Copilot Studio自身の設計思想を表す部分だと捉えると整理しやすくなります。
8. 結論：標準化の波はプラットフォームを問わず押し寄せている
前回、5つの用語を「業界団体による標準規格」と「現代のシステムで信頼されている設計パターン」に分類しましたが、Microsoft編を見て分かるのは、Microsoftがこれらの標準を独自路線で置き換えるのではなく、むしろ積極的に取り込みにいっているという事実です。MCPとA2Aは明確に採用・GA化され、Agent Skillsはフォーマットレベルで事実上の相互運用が生まれ、Subagentsは概念として実装されています。agents.mdだけがやや不透明なポジションにあります。
Claude・Gemini陣営とMicrosoft陣営が同じ語彙・同じファイル形式で会話できるようになりつつある、というのが今回の一番の発見でした。プラットフォームを選ぶ際の判断軸も、「どのモデルが優れているか」だけでなく、「標準化されたエコシステムにどれだけ乗れているか」という観点が今後ますます重要になりそうです。