『エージェンティックWeb』と『MCP 入門』- Azure Functions でハンズオン開発への実践ガイド
はじめに：AIエージェント時代の到来
2025年5月に開催された Microsoft Build 2025 は、まさに「AIエージェントの時代」の幕開けを告げるイベントでした。基調講演でサティア・ナデラCEOが語ったのは、AIが単なるツールから、自律的にタスクをこなし、協調して動作する「エージェント」へと進化していく未来。
このビジョンを実務に落とし込む鍵となるのが、MCP（Model Context Protocol） です。Anthropicが2024年11月に公開したMCPは、エージェントと外部システム（SaaS、データベース、API、ファイルなど）をベンダー非依存で接続するための、共通かつ拡張可能なプロトコル仕様です。クライアント（エージェント）とサーバー（外部機能）を、共通の手順で“発見・呼び出し”できるように設計されています。
本記事では、このMCPを Azure Functions 上で“リモートMCPサーバー”として動作させるための2つの SDK（拡張方式 / BYO方式） を概観します。MCP開発の全体像をつかみ、次回以降のハンズオンにスムーズに入るためのガイドとしてご活用ください。
エージェンティックWebとは？ ― 新たなプラットフォームの姿
Microsoft AI Tour 2025の基調講演で、サティア・ナデラCEOは「我々は常に、プラットフォームとパートナーにフォーカスしてきた」と語りました。これは、BASICの実行環境から始まり、PC、サーバー、クラウドに至るまで、50年にわたりアプリケーションのための基盤を提供し続けてきたマイクロソフトの歴史そのものを表しています。
図1: マイクロソフトのエージェンティックWeb構想（出典：Microsoft Build 2025）
そして今、マイクロソフトが次なるプラットフォームとして構築を進めているのが 「エージェンティックWeb」 です。
サティア ナデラCEOの言葉を借りれば、それは「これまでアプリケーションやWebサイトとして構築されてきた、個人や企業、チームのエンド・ツー・エンドのビジネスプロセスが全て、AIエージェントやAIエージェント同士のコミュニケーションとして再構築される」未来です。
現在のWebがWebサイトやサービスの集合体であるように、エージェンティックWebは、自律的にタスクを実行する無数の「AIエージェント」がネットワーク上に存在し、互いに連携し合う世界のことを指します。
図2：エージェンティックWebの概念図
図2に示すように、エージェンティックWebでは、ユーザーの自然言語による指示がAIエージェントに伝わり、そのエージェントがMCP（Model Context Protocol）を介してデータベース、SaaS、そして他のAIエージェントと連携しています。AIエージェント同士の連携はA2A（Agent-to-Agent）と呼ばれ、人間の指示が「意図の宣言」に近づき、実際の作業はエージェント群が分担して実行する新しいパラダイムを表しています。
これまでのAIエージェントが単体で「調査」などのタスクを実行するものが中心だったのに対し、これからのエージェントは、様々な種類のエージェントが協調・連携することで、より複雑なタスクをこなせるように進化していきます。
この変化は、私たちの生活や仕事のあらゆる側面に影響を及ぼします。
- 個人ユーザーの世界: 情報を探す、ニュースを読む、買い物をする、エンターテイメントを楽しむといった、現在ブラウザやモバイルアプリに依存している全ての体験が、AIエージェントによって再定義されます。
- エンタープライズの世界: 従業員体験、顧客サービス、ビジネスプロセス、そしてイノベーションそのものまで、過去10年間で追求されてきたDX（デジタルトランスフォーメーション）のあらゆる目標が、AIによって再構築されることになります。
この壮大なビジョンを実現するために、LLM（大規模言語モデル）には「マルチモーダルによる自然なUI」「高度なプランニングと論理的推論能力」「過去のやり取りを記憶する高度な長期記憶」といった能力の向上が不可欠だとサティア ナデラCEOは述べています。
そして、このエージェントたちが協調し合う世界のハブとなる技術こそが、 MCP (Model Context Protocol) なのです。
MCP（Model Context Protocol）とは？
エージェンティックWebを支える「USB-C」
2024年11月25日、AIスタートアップのAnthropicが発表した MCP（Model Context Protocol） は、AIエージェントと外部システムを連携するための標準プロトコルです。GitHubのトーマス・ドムケ元CEOは、MCPを「1990年代のHTTPに匹敵する革命的な技術」と評価し、「AIエージェントにとっての『USB-C』のようなもの」と表現しています。
図3: MCP イメージ図（出典：https://www.linkedin.com/in/norah-klintberg-sakal/）
なぜ「HTTPに匹敵」なのか？
ドムケ元CEOの言葉を借りれば：
「1990年代初めにティム・バーナーズ=リー氏がWorld Wide Web（WWW）を発明した際、画期的だったのはハイパーリンクで、もう1つはHTTPだった。人々は当初、静的なWebページをつくっていたが、今日においては（HTTPによって他のシステムと連係する）動的なWebサイトやWebサービスが主流になった」
MCPも同様に、現在ベンダー各社が定義する世界の中で閉じて活動するAIエージェントたちが、MCPを通じてベンダーの垣根を越えて動的に連携する未来を実現します。これこそが、ドムケCEOの予測する「エージェンティックWeb」の世界です。
MCPが解決した課題：旧来のベンダー固有「コネクター」問題
MCP登場以前、AIエージェントは「コネクター」と呼ばれる技術を使ってSaaS（ソフトウェア・アズ・ア・サービス）やDB（データベース）などの外部システムと連携していました。しかし、マイクロソフトの「Copilot」やAWSの「Amazon Q」といった各社のAIエージェント技術ごとに、それぞれ独自のコネクターが存在しており、相互の互換性がないという問題がありました。
旧来の問題点
- 個別実装の負担: LLM/エージェントが外部資産（DB・SaaS・社内API・ファイル）へアクセスするたびに個別実装が必要
- 標準化の不在: 認証・I/O定義がベンダーごとにバラバラ
- 開発効率の低下: 拡張性・再利用性・監査性が低下
MCP以降：共通プロトコルによる標準化
このコネクターの課題を解決するため、MCPはAIエージェントが様々な外部システムと連携する共通のプロトコルとして標準化を実現しました。これにより、 一度MCPサーバーを構築すれば、異なるベンダーのAIエージェントから同じ機能を利用できるようになります。
MCPの実現内容：
- MCPクライアント（Copilot / VS Code / 他）と MCPサーバー（あなたが提供するMCPサーバー）を共通手順で接続
- ツール（機能）一覧・スキーマ・呼び出しフローの標準化
- ベンダーの垣根を越えたエージェント連携の実現
MCPの基本構成要素
MCPの基本構成は以下のようになっています。
図4：MCPの基本構成
1. MCPクライアント
- 役割: UI側の制御
- 機能: ツールの列挙・リソース取得・スキーマ理解・呼び出し制御
- 例: GitHub Copilot、VS Code、Copilot Studio
2. MCPサーバー
- 役割: 実装側の機能提供
- 機能: "ツール"を公開し、リクエストを受けて処理結果を返却
- 例: GitHubのソースコード管理機能を提供するMCPサーバー
3. トランスポート
- 役割: クライアントとサーバー間の通信
- 方式: Streamable HTTP /SSE（Server-Sent Events）など
- 選択基準: クライアント特性に合わせて選択
A2A（Agent-to-Agent）との違い
MCPと混同されやすい概念として、 A2A（Agent-to-Agent） プロトコルがあります。A2Aはその名の通り、AIエージェント同士が直接やり取りを行い、協調的にタスクを進めるためのプロトコルです。MCPが「エージェントと外部システムを標準的に接続するためのUSB-C的役割」を担うのに対し、A2Aは「エージェント同士のワークスタイルや会話の型」を定義するものと考えると理解しやすいでしょう。
図5: A2A イメージ図（出典：https://codelabs.developers.google.com/intro-a2a-purchasing-concierge?hl=ja#1）
例えば、購買エージェントと配送エージェントが、共通のルールに従って自然にやり取りを行うイメージです。これにより、異なるベンダーやプラットフォームのエージェント同士でも、シームレスに連携することが可能になります。
まとめると、A2Aは次のような特徴を持っています。
- 役割: エージェント同士の協調パターン（ワークスタイルの概念）
- 発表: Google（2025年4月9日）、Microsoft（2025年5月7日サポート発表）
- 目的: MCPを補完する仕様として、AIエージェント同士の連携を実現
A2Aのエージェントに備わる、明確に定義されたスキルは、ステートレスなツール的動作が可能な場合に限って、MCP 互換のリソース／ツールとして外部に公開できます。その結果、別のエージェントは、MCP スタイルのツール記述を通じて該当エージェントのスキルを発見して呼び出せるようになります。
ただし、A2Aの本来の強みは、単なるツール呼び出しを超えた、柔軟なエージェント同士の協調的なやり取りにあります。エージェント同士がタスクを分担し、対話を通じて共同で作業を進める能力こそが、A2Aの目的です。
一方で、MCPは「エージェントが機能ツールを利用する」という視点に重きを置いており、A2Aとは目的が異なります。
それぞれの得意領域を活かし、適材適所で組み合わせることで、より柔軟なAIシステムを構築できます。これにより、ベンダーやプラットフォームの垣根を越えてAIエージェントが連携できる状況が整います。
マイクロソフトの総合戦略
サティア・ナデラCEOは、エージェンティックWebという新しいプラットフォームにおいても、マイクロソフトが必要な要素を全て提供する方針を示しています。MCPはその戦略の中核を担う技術として位置付けられており、次世代のAIエージェント連携基盤の標準となることが期待されています。
Azure Functions で作る Remote MCP ― 2つのアプローチ
なぜ「リモート」MCPなのか？
ローカルのMCPサーバー（IDE内や開発マシン上）だけに依存すると、以下の壁にぶつかります。
-
配布・再利用性の問題
手元の環境に依存するため、他チーム・他端末・自動化パイプラインからの再利用が困難 -
可用性とスケールの限界
ローカルは常時起動やスケールアウトに弱く、混雑時の処理遅延や停止リスクが発生 -
ゼロトラストと統制の課題
認証・監査・ネットワーク分離（V-Net/Private Link等）を徹底しづらい
そこで Remote MCP（クラウド上のMCPサーバー）にすることで、エージェント／IDE／Bot／バックエンドから安定したエンドポイントにアクセスでき、サーバーレスで自動スケール、認証・ネットワーク統制も組み込みやすくなります。MicrosoftはAzure Functions上でのリモート化を公式に推進しており、言語別のクイックスタートと設計ガイドが整備されています。
なぜ Azure Functions なのか？
Azure Functionsを採用する理由は以下の通りです。
-
サーバーレス運用の最適化 :
アクセスが増えたときだけ自動でスケールし、使わない時はゼロに戻る（Flex Consumption）。突発的な負荷に強く、従量課金でコスト最適。 -
エンタープライズグレードのセキュリティ :
関数キー／内蔵認証（Easy Auth）／API Management／V-Net統合など、エンプラ要件に必要な部品を素直に足せる設計。 -
MCPに最適化された機能 :
functionsの MCP拡張（トリガー＆バインド） が提供され、MCPツール呼び出しをそのまま関数として実装できる。
全体像：remote-mcp-functions リポジトリ
Microsoftは、Azure Functions 上でRemote MCPサーバーを構築するための2つの公式SDK を提供しています。FastMCP (BYO) SDK 方式は2025年8月に"Early Preview"として公開されました。
まず、Functions でRemote MCPを作るための集約リポジトリが提供されています。
ランディング（全体像）
こちらには、Functions Extension MCP SDKと、BYO（Bring Your Own）MCP SDKの両方式に加え、言語別サンプル（Python / Node / .NET）が含まれています。
図4：Azure Function Remote MCP SDK
A. Functions MCP Extension（拡張方式）
Functions の 拡張（Extension） で MCP を"ネイティブ"にホスト。関数に MCP 用トリガーを付けるだけでツール公開ができる方式です。
サンプルリポジトリ（※こちらが拡張方式の Python クイックスタート）
ポイント
-
関数に
@app.generic_trigger(... type="mcpToolTrigger")を付けるだけで MCP ツール化。コード例は上記 README に掲載。 -
Azure 側では、system key
mcp_extensionをx-functions-keyヘッダーに付与して呼び出します（Portal/CLI で取得可）。 -
ドキュメント上のバンドルは
Microsoft.Azure.Functions.ExtensionBundle.Previewを指定します（4.x プレリリース帯）。サンプルによってはExperimentalの表記が残っているものがあります。 -
エンドポイントは拡張が公開する固定パス：
-
Streamable HTTP:
/runtime/webhooks/mcp（推奨） -
SSE:
/runtime/webhooks/mcp/sse（新しいプロトコルでは非推奨）
-
Streamable HTTP:
2025年9月時点の公式ドキュメントでは Streamable HTTP を使うべきと明記。SSE はプロトコル側で非推奨になっています。VS CodeではSSE、HTTP方式のどちらもサポートされています。
B. BYO（Bring Your Own）— MCP SDK で作ったサーバーを Functions に持ち込む
既に FastMCP / MCP Python SDK 等で MCP サーバーを書いているなら、それを Functions の Custom Handler として同梱してホスティングする方式。自由度が高く、コード資産をそのまま活かせます。
サンプルリポジトリ（Python）
（Node / .NET 版もあり。Java は 拡張方式 のテンプレートはありますが、BYO の公式サンプルは現時点で掲載なし）
ポイント
-
既存の MCP サーバー（FastMCP / 公式 Python SDK など） を最小変更で Functions に載せる。
azd upで一発デプロイも用意。 - APIM（API Management）前段での認可フローや Entra 連携のサンプルもあり（Protected Resource Metadata など MCP 認可仕様準拠のポリシー例）。
- Microsoft 公式のアナウンスでは "Early Preview" として Python/Node/.NET をサポート。Flex Consumption プランでのホスト想定、Streamable HTTP にフォーカス。
拡張方式とBYO方式の選択基準
2つのアプローチの選択において、最も重要な違いはMCP要素のサポート範囲です。
拡張方式（Functions MCP Extension）の現状
Azure Functions の MCP 拡張は現在プレビュー段階にあり、「MCP Tool Trigger」のみを提供しています。これはMCPサーバーとしてツールの公開に特化した実装となっており、Resource や Prompt については現行ドキュメントと実装上の説明に記載がありません。
つまり、拡張方式では現時点で Tool のみがサポートされ、Resource（ファイルやデータベース等の読み取り専用リソース）と Prompt（プロンプトテンプレート）は利用できません。
BYO方式の包括的サポート
一方、公式の MCP Python SDK および FastMCP は、MCP仕様の全要素である Tools、Resources、Prompts のすべてでサーバー実装が可能です。これにより、既存のMCPサーバー資産を最大限活用でき、MCP仕様の機能をフル活用したサーバーを構築できます。
実際の選択指針
BYO方式を推奨するケース：
ファイルやデータベースなどのResourceからの情報取得が必要な場合、動的なPromptテンプレートを配布したい場合、または既存のMCPサーバー実装を活用したい場合は、BYO方式が適しています。MCP仕様の全要素に対応しているため、柔軟性の高いサーバーを構築できます。
拡張方式を選択するケース：
シンプルなツール実行のみで要件を満たせる場合は、拡張方式が有効です。特にAzure Functions の各種バインディング（Blobストレージ、Cosmos DB、Service Bus等）を活用して外部サービスと素早く連携したい場合や、運用の簡便性を重視したい場合に適しています。Functions のネイティブ機能との親和性が高く、開発・デプロイ・監視の統合された環境を活用できます。
本記事のハンズオン方針
この連載では、A：Functions MCP Extension を主軸とします。Azure Portal でコード/設定を直接触りながら、以下のステップを段階的に学習していきます：
- ローカル MCP の基礎理解
- Azure Functionにデプロイ
- Azure Functionの前段にAPIM の配置
- V-Net で閉域化したセキュアな構成
実際に手を動かしながら、MCP の全体構成をゼロから理解していくことを目指しています。
ここから始める：連載ハンズオン・ロードマップ
| Part | タイトル | 目的 | 到達点 | URL |
|---|---|---|---|---|
| 1 | ローカルで最小 MCP | reverse_text ツール最小実装 | VS Code / Copilot Agent から検出→実行→結果取得 | ローカル編 |
| 2 | Azure Functions で Remote MCP | ローカル実装を公開エンドポイント化 | SSE & Streamable HTTP 両接続 | リモート編 |
| 3 | APIM 前段化 | フロントをAPIMで一元化 | APIM 経由で各クライアント接続 | APIM |
| 4 | V-Net 閉域化（Private Endpoint & DNS） | Private Link / DNS でPublicアクセス遮断 | APIM 経由のみ到達 | V-Net |
まとめ
本記事では、AIエージェント時代の新しいプラットフォーム「エージェンティックWeb」とその実現を支える「MCP（Model Context Protocol）」について解説しました。
エージェンティックWebは、従来のWebサイトやアプリケーション中心の世界から、AIエージェント同士が自律的に連携し、ビジネスプロセスを再構築する次世代のプラットフォームです。この変革を技術的に支えるMCPは、AIエージェントと外部システムを標準的に接続するプロトコルであり、「AIエージェントにとってのUSB-C」として今後広く採用されていくことが予想されます。
Azure Functions上でのMCPサーバー構築には、既存機能を拡張して利用する「拡張方式」と、独自実装を持ち込む「BYO（Bring Your Own）方式」の2つのアプローチがあります。次回以降のハンズオンでは、拡張方式を中心に、ローカル実装からクラウドリモート化、そしてV-netによる閉域化までを段階的に学べるよう構成しています。
エージェンティックWebの時代はすでに始まっており、MCPはその基盤技術として不可欠な存在となっていくのではないかと思います。本連載を通じて、AI連携アーキテクチャを構築するスキルを身につけ、新しいビジネス価値の創出に役立てていただければ幸いです。
参考文献
- NIKKEI COMPUTER 2025.5.29
- Microsoft Build 2025: The age of AI agents and building the open agentic web
- Anthropic｜Introducing the Model Context Protocol
- Microsoft Learn｜Copilot Studio：既存MCPサーバーへの接続
- Microsoft Tech Community｜Early Preview: BYO Remote MCP Server on Azure Functions
- Microsoft Learn（Code Samples）｜Remote MCP with Azure Functions（Python）
Discussion