Azure FunctionsでMCPサーバーを作る公式クイックスタート「Build a custom remote MCP server using Azure Functions」は、AIクライアントから呼び出せる独自ツールを、ローカルではなくAzure Functions上のリモートMCPサーバーとして動かすための実装手順です。結論から言うと、既存のAzure Functions環境が自動的に変更されるアップデートではありません。影響を受けるのは、GitHub CopilotやAIエージェントから社内ツール、検索、保存、業務APIなどを呼び出せるようにしたい開発チームと、そのAzure環境を管理する管理者です。公式クイックスタートでは、Azure Developer CLIでテンプレートを作成し、ローカル検証後にFlex ConsumptionプランのFunction Appへデプロイする流れが示されています。(Microsoft Learn)
実装前に特に確認すべきなのは、対応言語、認証方式、Flex Consumptionプランの制約、mcp.jsonの接続情報、既存Function Appへデプロイした場合の上書きリスクです。小さな検証ならテンプレートのまま進められますが、社内利用や本番展開では「誰がAIクライアントからどのツールを実行できるのか」を先に決めておかないと、キー管理や権限管理でつまずきやすくなります。
Azure Functionsの「Build a custom remote MCP server using Azure Functions」とは
「Build a custom remote MCP server using Azure Functions」は、Azure Functionsを使ってカスタムのリモートMCPサーバーを作成・デプロイするためのMicrosoft Learnのクイックスタートです。MCPはModel Context Protocolの略で、AIモデル、エージェント、アシスタントが外部ツールやデータにアクセスするための仕組みです。このクイックスタートでは、Azure Functions MCP server extensionを使い、関数をMCPツールとして公開します。(Microsoft Learn)
ポイントは、MCPサーバーを単なるローカル開発用ツールではなく、Azure上で実行されるサーバーレスなリモートツール基盤として扱うことです。たとえば、GitHub CopilotのAgentモードから「スニペットを保存する」「保存したスニペットを取得する」といった独自ツールを呼び出し、その処理をAzure Functions上で実行できます。公式手順でも、ローカルでCopilotからSay Hello、Save this snippet as snippet1、Retrieve snippet1 and apply to NewFileのようなプロンプトを実行して動作確認する流れが示されています。(Microsoft Learn)
なお、Microsoft Learnの当該ページには、確認時点で英語版は2026年4月6日、日本語版は2026年4月7日が最終更新日として表示されています。実装時は、記事上部の言語タブ、対象ランタイム、最終更新日をあわせて確認してください。(Microsoft Learn)
何が変わるのか：ローカルMCPからリモートMCPへ移行しやすくなる
このクイックスタートの実務上の意味は、AIクライアント向けのツールをAzure Functionsの通常の開発・運用フローに乗せやすくなることです。従来のMCPサーバー検証は、開発者のPC上で動くローカルサーバーに寄りがちでした。しかし、チームで共通利用する場合や、社内API・ストレージ・業務データにアクセスさせる場合は、ローカル環境では権限、監視、スケール、可用性の管理が難しくなります。
Azure Functions上のリモートMCPサーバーにすることで、次のような運用に近づきます。
| 変更点 | 実務上の意味 |
|---|---|
| MCPツールをAzure Functionsの関数として定義できる | 既存のFunctions開発に近い形でAI向けツールを実装できる |
azd initでテンプレートから開始できる | Bicepや接続設定を含む構成を短時間で検証できる |
| Flex Consumptionプランにデプロイする | サーバーレス課金とスケーリングを前提に構築できる |
.vscode/mcp.jsonでローカル・リモート接続を管理する | VS CodeやGitHub CopilotからMCPサーバーを切り替えて検証しやすい |
| Function App名とシステムキーでリモート接続する | キー管理、認証、秘密情報の扱いが重要になる |
公式クイックスタートでは、azd initでテンプレートを取得し、Azuriteでローカルストレージを起動し、VS CodeとAzure Functions Core Toolsでローカル実行した後、azdを使ってFlex ConsumptionプランのFunction Appへデプロイする流れになっています。(Microsoft Learn)
対象者：開発者だけでなくAzure管理者も確認が必要
この内容は、MCPサーバーを作る開発者だけの話ではありません。リモートMCPサーバーはAIクライアントから呼び出される「実行可能なツール」になるため、管理者側の確認も欠かせません。
| 立場 | 確認すべきこと | 理由 |
|---|---|---|
| アプリ開発者 | 対応言語、ツール定義、Blobなどのバインディング、ログ出力 | AIから呼ばれたときに期待通りの処理だけを実行させるため |
| Azure管理者 | サブスクリプション、リージョン、Flex Consumption、ストレージ、監視 | デプロイ先、課金、クォータ、ログ管理に影響するため |
| セキュリティ担当 | Function Key、App Service認証、Microsoft Entra ID、キーの保管 | AIクライアント経由の不正利用を防ぐため |
| DevOps担当 | azd、Bicep、CI/CD、既存アプリへの上書きリスク | 検証環境と本番環境を安全に分けるため |
| AI活用推進担当 | GitHub CopilotやFoundryエージェントとの接続範囲 | どのAIクライアントにどの業務ツールを使わせるかを決めるため |
特に注意したいのは、MCPツールは「AIが説明を読むだけの情報」ではなく、「AIが実行できる処理」だという点です。読み取り専用の検索ツールと、データ更新・ファイル作成・外部API実行を行うツールでは、必要な認可設計がまったく違います。
対応言語と前提条件
公式クイックスタートでは、カスタムMCPサーバーの作成自体はFunctions言語全体でサポートされる一方、記事内のサンプルはC#、Java、Python、TypeScriptに限定されています。また、Node.jsはAzure Functionsのプログラミングモデルv4、Pythonはプログラミングモデルv2を前提としています。(Microsoft Learn)
主な前提条件は次の通りです。
| 項目 | 公式手順で示されている内容 | 確認ポイント |
|---|---|---|
| .NET | .NET 8.0 SDK | C#で始める場合に必要 |
| Java | Java 17 Developer Kit、Apache Maven 3.8.x | 別のJavaバージョンを使う場合はpom.xmlの確認が必要 |
| TypeScript | Node.js 20 | Node.jsのバージョン差でビルドや依存関係が失敗しないか確認 |
| Python | Python 3.11 | 仮想環境とFunctionsのPythonモデルを確認 |
| エディタ | Visual Studio Code | Azure Functions拡張機能とAzure Developer CLI拡張機能が必要 |
| ローカルストレージ | Azurite | AzureWebJobsStorageのローカル接続検証に使う |
| CLI | Azure CLI、Azure Developer CLI | ログイン、リソース作成、デプロイ、キー取得に使う |
| Azure | 有効なサブスクリプション | 検証でも少額のコストが発生する可能性がある |
初心者がつまずきやすいのは、Azure Functions Core Tools、Azure CLI、Azure Developer CLI、VS Code拡張機能の役割を混同することです。Core Toolsはローカル実行、Azure CLIはAzureリソース操作、Azure Developer CLIはテンプレートを使ったアプリ単位のプロビジョニングとデプロイ、VS Code拡張機能はエディタ統合、と分けて理解すると整理しやすくなります。
実装の流れ：最小構成でリモートMCPサーバーを作る
公式クイックスタートの流れは、次の順序で進みます。
テンプレートからプロジェクトを作成する
まず、azd initで言語別テンプレートを取得します。たとえばTypeScriptなら次のように実行します。
azd init --template remote-mcp-functions-typescript -e mcpserver-tsC#、Java、Pythonにもそれぞれテンプレートが用意されています。-eで指定する環境名は、azdが管理するデプロイコンテキストであり、Azure上のリソースグループ名やリソース名の一部にも関係します。検証環境と本番環境を分ける場合は、mcpserver-dev、mcpserver-prodのように用途が分かる名前にしておくと管理しやすくなります。(Microsoft Learn)
Azuriteを起動してローカルで実行する
次に、Azuriteを起動してローカルのAzure Storageエミュレーターを用意します。サンプルでは、スニペットの保存・取得にBlob Storageバインディングを使うため、ローカル実行でもストレージ接続が必要です。VS CodeからFunctionsアプリを起動すると、ターミナルにローカルで実行中の関数名が表示されます。(Microsoft Learn)
ここで大切なのは、いきなりAzureにデプロイしないことです。MCPツールはAIクライアントから実行されるため、引数、戻り値、ログ、失敗時の応答をローカルで確認してからクラウドへ出すべきです。
GitHub CopilotでローカルMCPツールを検証する
テンプレートには、ローカルMCPエンドポイントを指す.vscode/mcp.jsonが含まれています。VS Codeでlocal-mcp-functionを起動し、Copilot ChatのAgentモードでMCP Serverが有効になっていることを確認します。公式手順では、Say Helloで簡単な応答を確認し、その後スニペットの保存・取得を試す流れが示されています。(Microsoft Learn)
実務では、この段階で次の観点を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| ツール名 | AIクライアントが誤解しない名前になっているか |
| ツール説明 | 何を実行するツールなのか、制約が明確か |
| 引数 | 必須項目、型、空文字、異常値を扱えるか |
| 戻り値 | AIが次の判断に使える形で返しているか |
| ログ | 失敗原因を追えるが、秘密情報を出力していないか |
| 実行許可 | Copilot側で想定通りツール実行の許可が求められるか |
Azureにデプロイする
ローカル検証後、azdでAzureへデプロイします。公式クイックスタートでは、Flex Consumptionプランの新しいFunction Appにデプロイする構成になっており、Bicepファイルを使ってベストプラクティスに沿った安全なデプロイを行うと説明されています。デプロイ時には、Azureサブスクリプション、Azureリージョン、vnetEnabledなどのパラメーターを選択します。(Microsoft Learn)
vnetEnabledは公式手順ではFalseを選ぶことでデプロイを簡略化します。ただし、本番環境で社内API、データベース、閉域ネットワーク上のサービスに接続する場合は、VNet統合やAPI Managementの利用を含めて別途設計すべきです。
リモートMCPサーバーに接続する
デプロイ後は、.vscode/mcp.jsonに含まれるremote-mcp-function設定を使ってリモートサーバーへ接続します。接続時には、Function App名と、MCPエンドポイントにアクセスするためのシステムキーmcp_extensionが必要です。公式手順では、azdとAzure CLIを使ってFunction App名とシステムキーを出力するスクリプトが示されています。(Microsoft Learn)
このキーは秘密情報です。mcp.jsonをリポジトリにコミットする運用では、キーを直書きしないでください。VS Codeの入力プロンプトやシークレット管理、CI/CDの環境変数を使い、漏えい時には速やかに再生成・差し替えできる体制にしておく必要があります。
Flex Consumptionプランで確認すべき制約
クイックスタートはFlex Consumptionプランを前提にしています。Flex Consumptionは、従量課金型のサーバーレスモデルをベースにしつつ、仮想ネットワーク統合、インスタンスメモリサイズの選択、高速または大規模なスケールアウトなどを提供するAzure Functionsの推奨サーバーレスホスティングプランです。(Microsoft Learn)
ただし、便利な一方で、従来のFunctionsプランと同じ感覚で使うと見落としが出ます。
| 確認項目 | 注意点 |
|---|---|
| OS | Flex ConsumptionはLinuxベース。Windows前提の処理は事前確認が必要 |
| リージョン | すべてのAzureリージョンで利用できるわけではない |
| インスタンスサイズ | 512MB、2048MB、4096MBなどから選ぶ。多くのシナリオでは2048MBが既定の目安 |
| Always-Ready | コールドスタート軽減に使えるが、常時利用分の課金を考慮する |
| スケール | 最大スケールやリージョン単位のクォータに注意 |
| デプロイスロット | Flex Consumptionでは現時点でデプロイスロットがサポートされていない |
| 移行 | 既存アプリを別プランからFlex Consumptionへ一括移行できない。新しいFunction Appを作って再デプロイする必要がある |
特に移行の考え方は重要です。既存のConsumption、Premium、Dedicatedプラン上のFunction AppをそのままFlex Consumptionへ「変換」するのではなく、Flex Consumptionの新しいFunction Appを作成してコードを再デプロイする形になります。既存のFunctions資産をMCPサーバー化したい場合は、アプリ設定、接続文字列、マネージドID、ストレージ、監視設定を棚卸ししてから移行計画を作るべきです。(Microsoft Learn)
認証と承認：Function Keyだけで本番運用しない
リモートMCPサーバーは、AIクライアントからインターネット経由で呼び出される可能性があります。そのため、認証設計は最重要です。Azure FunctionsでホストするリモートMCPサーバーの不正利用を抑える方法として、公式チュートリアルでは組み込みのサーバー認証とキーベース認証の2種類が説明されています。組み込みのサーバー認証は、MCP承認仕様のOAuth要件を実装し、Microsoft Entra IDなどのIDプロバイダーにリダイレクトして認証する方法です。一方、キーベース認証はリクエストヘッダーに共有秘密鍵を含める方式で、OAuthベース認証ほどのセキュリティは提供しないと説明されています。(Microsoft Learn)
検証ではFunction Keyでも始められますが、本番利用では次の判断基準で考えるのが現実的です。
| シナリオ | 推奨される考え方 |
|---|---|
| 個人検証・短期PoC | Function Keyで開始してもよいが、キーを共有・コミットしない |
| チーム内の限定利用 | Entra ID認証を検討し、利用者とクライアントを明確にする |
| 社内データにアクセスするMCPツール | OAuthベースの認証、マネージドID、最小権限を前提に設計する |
| 外部APIや更新系処理を実行するツール | 認証だけでなく、ツール単位の入力検証、監査ログ、レート制御を設ける |
| 複数AIクライアントから利用する | クライアントごとの許可、スコープ、同意設定を整理する |
組み込み認証を使う場合、MCPサーバー側のホストベース認証を無効化するために、MCP拡張サーバーではAzureFunctionsJobHost__extensions__mcp__system__webhookAuthorizationLevel=Anonymousを設定する方法が示されています。そのうえで、App Service認証、Microsoft Entra ID、保護されたリソースメタデータの設定を行います。(Microsoft Learn)
また、App Service認証を使うMCPサーバー承認では、PRM、つまり保護されたリソースメタデータの構成が必要です。公式ドキュメントでは、WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPESにアプリケーションのスコープを設定する手順が示されています。ただし、この承認はサーバーへのアクセスを制御するものであり、個々のMCPツールごとの細かな制御までは提供しない点に注意が必要です。(Microsoft Learn)
MCP拡張サーバーとセルフホステッドサーバーの違い
Azure FunctionsでリモートMCPサーバーをホストする方法には、大きく2つの選択肢があります。MCP拡張サーバーは、Azure Functions MCP拡張機能を使ってツールエンドポイントを定義する方式です。Functionsやバインディングベースのプログラミングモデルに慣れている場合に向いています。セルフホステッドサーバーは、標準のMCP SDKで作成したMCPサーバープロジェクトをAzure Functions上にホストする方式で、既存のMCP SDKベースのサーバーをサーバーレス環境で動かしたい場合に適しています。公式チュートリアルでは、公式MCP SDKで作成したサーバーをFunctionsでホストする機能はプレビュー段階とされています。(Microsoft Learn)
選び方は次の通りです。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| MCP拡張サーバー | Azure Functionsのトリガー、バインディング、Blob入出力などを活用したい | Functionsの構成とMCP拡張の理解が必要 |
| セルフホステッドサーバー | すでにMCP SDKで作ったサーバーを持っている | プレビュー機能の扱い、カスタムハンドラー設定、必要なアプリ設定を確認する |
| APIMや追加認証を組み合わせる構成 | 複数クライアント、社外連携、ポリシー制御が必要 | 初期構成は複雑になるが、本番運用では管理しやすい場合がある |
最初の検証ではMCP拡張サーバーのテンプレートを使うと理解しやすくなります。一方、すでにPythonやNode.jsのMCP SDKでツールを作っているチームは、セルフホステッド方式を検証する価値があります。
管理者が事前に確認すべき設定
リモートMCPサーバーをチームで使う前に、管理者は次の設定を確認してください。
| 項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| サブスクリプション | 検証用と本番用を分ける | PoCのリソースが本番サブスクリプションに混在する |
| リソースグループ | azd環境名と対応づける | どのMCPサーバーがどの環境か分からなくなる |
| リージョン | Flex Consumption対応リージョンを選ぶ | 希望リージョンが表示されずデプロイが止まる |
| ストレージ | AzureWebJobsStorageとBlob利用を確認 | ストレージ権限不足でツール実行が失敗する |
| 監視 | Application InsightsとLog Analyticsを有効化する | AI経由の実行失敗を後から追跡できない |
| 認証 | Function KeyかEntra IDかを決める | 検証用キーを本番でも使い続ける |
| ネットワーク | VNet統合の要否を決める | 社内APIに接続できない、または過剰に公開される |
| コスト | Always-Ready、実行回数、ストレージを確認 | 検証後にazd downし忘れて課金が残る |
Flex Consumptionでは、デプロイやスケールに関する診断ツール、クォータ、Always-Readyインスタンス、コンカレンシーなども運用上の確認ポイントになります。特にAlways-Readyはコールドスタート軽減に有効ですが、常時確保分の課金が発生するため、MCPツールの利用頻度と応答速度要件を見て設定するべきです。(Microsoft Learn)
開発者が実装時に注意すべきポイント
MCPツールの実装では、「AIが使いやすいツール」と「安全なツール」の両立が重要です。単に関数を公開するだけでは、AIクライアントが意図した引数を渡せなかったり、危険な処理を実行してしまったりします。
ツール名と説明を曖昧にしない
saveDataやrunTaskのような抽象的な名前は避けてください。AIクライアントが何を実行するツールか判断しにくくなります。たとえば、コードスニペットをBlobに保存するなら、saveSnippetのように対象と動作が分かる名前にします。
説明文には、次の要素を入れると安定します。
- 何をするツールか
- 必須入力は何か
- どの範囲のデータにアクセスするか
- 書き込みや削除を行うか
- 実行してはいけない用途があるか
引数の検証をサーバー側で行う
AIクライアントは、人間の操作よりも多様な入力を生成します。空文字、長すぎる文字列、存在しないID、JSON形式の崩れ、想定外の日本語入力などを前提にしてください。AI側に「正しく入力してもらう」だけでは不十分です。
たとえばスニペット保存ツールなら、次のような検証が必要です。
| 入力 | 確認例 |
|---|---|
| スニペット名 | 空でない、使用可能文字、長さ制限 |
| 内容 | サイズ上限、機密情報の扱い、改行やエンコード |
| 保存先 | テナントやユーザーごとに分離されているか |
| 上書き | 同名がある場合に上書きするか、エラーにするか |
ログに秘密情報を出さない
MCPツールは、CopilotやAIエージェントとのやり取りの中で実行されます。ログにプロンプト全文、APIキー、個人情報、業務データをそのまま出すと、監視基盤に機密情報が残ります。デバッグ時は便利でも、本番ではマスキング、要約ログ、相関IDの利用を検討してください。
既存Function Appへのデプロイ上書きに注意する
公式チュートリアルでは、既存のFunction AppにデプロイするとAzure内のアプリ内容が常に上書きされると明記されています。MCPサーバー検証用のFunction Appと、既存の業務Function Appを同じデプロイ先にしないでください。(Microsoft Learn)
移行・展開で失敗しやすいポイント
既存のAzure Functions資産をMCPサーバー化する場合、単純なコード移植だけでは済まないことがあります。特に次の点は、事前に確認しておくべきです。
| 失敗しやすいポイント | 対策 |
|---|---|
| Flex Consumptionへ既存アプリを直接移行できると思い込む | 新しいFunction Appを作成し、コードと設定を再デプロイする前提で計画する |
| C#インプロセスモデルをそのまま使おうとする | Flex ConsumptionではC#インプロセスモデルがサポートされないため、分離ワーカーモデルを確認する |
| 検証用のFunction Keyをチームで共有し続ける | Entra ID認証やキーのローテーション方針を決める |
mcp.jsonにキーを直書きしてコミットする | 入力プロンプト、環境変数、シークレット管理を使う |
| リージョンやクォータを確認せずに展開する | Flex Consumption対応リージョンとリージョン単位のクォータを確認する |
| デプロイスロット前提のリリース設計をする | Flex Consumptionではデプロイスロット非対応のため、別環境や段階的デプロイの方法を検討する |
| AIが更新系ツールを自由に実行できる | 認可、入力制限、監査ログ、必要なら人間の承認フローを設ける |
このうち、最も危険なのは「AIから呼べるツール」を通常のAPI公開と同じ感覚で扱うことです。AIクライアントはユーザーの自然文からツールを選びます。ツールの説明が曖昧だったり、権限が広すぎたりすると、意図しない実行につながります。
本番展開前のチェックリスト
本番または社内共有環境に出す前に、最低限次のチェックを済ませてください。
| 分類 | チェック項目 |
|---|---|
| 開発 | ローカルで全ツールを実行し、正常系・異常系を確認した |
| 接続 | .vscode/mcp.jsonのローカル接続とリモート接続を分けて管理している |
| 認証 | Function Key運用かEntra ID認証かを決めた |
| 秘密情報 | キー、接続文字列、トークンをリポジトリに含めていない |
| 権限 | マネージドIDやストレージ権限を最小限にしている |
| 監視 | Application Insightsでツール実行ログを追跡できる |
| コスト | Flex Consumption、Always-Ready、ストレージ、ログのコストを見積もった |
| ネットワーク | 外部公開、VNet統合、API Managementの要否を判断した |
| 移行 | 既存Function Appを上書きしないデプロイ先を用意した |
| 削除 | 検証後にazd downでリソースを削除する手順を共有した |
まず何をすべきか
これからAzure FunctionsでカスタムリモートMCPサーバーを試すなら、最初は本番環境ではなく専用の検証用サブスクリプションまたはリソースグループで始めてください。C#、Java、Python、TypeScriptのいずれかで公式テンプレートを作成し、ローカルでCopilotからツール呼び出しを確認します。その後、Flex Consumptionプランへデプロイし、Function Keyで最小限のリモート接続を試します。
次の段階で、Entra ID認証、マネージドID、Application Insights、VNet統合、API Managementの必要性を判断します。業務データに接続するMCPツールを作る場合は、実装より先に「読み取り専用か、更新系か」「誰が使えるか」「実行ログをどこまで残すか」を決めることが重要です。
Azure FunctionsのMCP対応は、AIエージェントに社内ツールを安全に渡すための実用的な選択肢です。ただし、AIから実行されるツールである以上、便利さより先に認証、権限、ログ、デプロイ先の分離を設計してください。まずはテンプレートで小さく動かし、ツールの説明、入力検証、認証方式を固めてから、本番展開へ進めるのが安全です。
コメント