Azure MCP カタログ構築ガイド（前編）：API Management で REST API を MCP 化する

1. はじめに

MCP サーバーが増えると、URL を共有するだけでは「どの部署が管理しているか」「どの環境・バージョンを使うか」「自分に利用権限があるか」を把握しにくくなります。一方、カタログに登録するだけでは、接続先の認証・認可や API の実行基盤までは完成しません。

本シリーズは、APIM での MCP 公開から API Center での登録・検索、クライアント利用までを 2 記事で扱います。前編の目的は、リソースと REST mock を準備し、注文照会だけを MCP tool として公開することです。後編：API Center への登録・検索と VS Code からの利用では、カタログと実行時接続を構成します。

対象は remote MCP です。ローカル package の登録や既存 MCP の passthrough は扱いません。架空の注文照会 1 operation に限定し、後編で Azure portal から 手動登録します。API Center と APIM の自動同期は後編の拡張で扱います。

確認範囲: 2026-10-12 に確認した公式ドキュメントに基づきます。設定値・JSON・XML は構成例であり、Azure 上で実行して成功したログではありません。生成される tool 名・input schema、mock operation への MCP 経由の呼び出し、キーの引き継ぎ、実際の画面・組織の同意設定は検証環境で確認してください。

2. 構成と前提条件を決める

2.1 カタログと runtime の責任を分ける

図は前後編の全体像です。破線はカタログの検索・URL 取得、実線は実行時の要求で、API Center は runtime の通信線上にありません。前編では APIM 内の mock response と MCP 公開までを構成し、実 backend への接続はまだ構築しません。

要素	本例での責任	本例で構成しないもの
APIM managed gateway	REST operation の管理、MCP tools の公開、キーの検証	実業務 backend、利用者ごとの委任
API Center inventory	MCP asset、Runtime URL、environment、version の管理	APIM の認証設定変更、キーの自動発行
API Center portal	Entra ID サインイン、カタログの検索・詳細閲覧	portal test console への秘密情報の配布
MCP client	APIM への直接接続、初期化・tool 発見・呼び出し	カタログ閲覧権限からの runtime 権限の推定

API Center は design-time governance / discovery、APIM は gateway を通じた runtime governance / observability を担う補完サービスです。API Center には API version ごとの認証設定や access policy を構成する機能もありますが、それを本例では有効化しません。Data Reader の割り当てだけで APIM のキーやユーザーの OAuth 権限を用意したことにはなりません。[^api-center-overview][^api-center-access]

2.2 用意するリソースと権限

項目	本例の選択・前提
Azure サブスクリプション	APIM / API Center を作成・編集できる権限
Resource group	検証専用の `rg-mcp-catalog-lab` など
APIM	Basic v2、managed gateway、public 接続。本番や private 接続の SKU 選定とは分ける
API Center	小規模評価向けの Free plan。基本の名前検索を使い、semantic search は使わない
リージョン	両サービスの提供地域を確認。本例の候補は East US
Entra ID	API Center portal の app registration を作成できる権限
カタログ閲覧用 RBAC	API Center に Data Reader を割り当てられる管理者
クライアント	MCP 対応 VS Code と、GitHub Copilot を利用できる環境

Basic v2 は APIM の MCP 対応一覧に含まれ、作成 quickstart でも開発・評価の候補として説明されています。API Center は Free / Standard があり、semantic search は Standard の機能です。Free は Microsoft support の対象外で、APIM の利用料金まで無料になるわけではありません。[^mcp-overview][^apim-create][^api-center-overview][^portal-setup]

API Center 作成手順では、サブスクリプションの Contributor または同等の権限が前提です。ただし RBAC の割り当てには別途 Microsoft.Authorization/roleAssignments/write が必要です。Entra の app registration 作成権限も Azure リソースの Contributor と同一ではないため、事前に担当者を確認します。[^api-center-create][^role-assignment][^portal-setup]

East US は確認した API Center と Basic v2 の提供一覧に含まれますが、実際の quota・容量・組織の配置方針は未確認です。APIM と API Center を同じリージョンに置くことを、このカタログ登録の必須条件としているわけではありません。[^api-center-overview][^v2-regions]

private な MCP を構築する要件があるなら、先に Azure API Management のネットワーク構成パターン：Private Endpoint・VNet integration・injection の選び方で SKU と接続方式を選びます。Basic v2 の最小例から、Private Endpoint を後付けできると想定しないでください。

3. APIM と API Center を作成する

3.1 APIM の managed gateway を用意する

Azure portal で次のように作成します。既存の検証インスタンスを使う場合は、SKU・global policy・診断設定を確認してから進みます。[^apim-create]

Create a resource → Integration → API Management を開きます。
Subscription、検証用 Resource group、Region、Resource name、Organization name、Administrator email を入力します。
Pricing tier を Basic v2 にし、評価に必要な容量を選びます。
Networking は、この例では public の構成にします。不要な add-in service は選択せず、料金見積もりを確認します。
Review + create → Create で作成し、利用可能な状態になった後に Overview の gateway URL を控えます。

APIM のリソース名は例示の固定名をそのまま使うのではなく、作成先で利用できる名前を指定します。以下では <APIM_NAME> と表記します。

3.2 API Center を用意する

API Center の作成手順は次のとおりです。[^api-center-create]

Subscription の Resource providers で Microsoft.ApiCenter を確認し、未登録なら登録します。
API Centers → + Create を開きます。
Subscription、検証用 Resource group、Name、対応する Region、Free plan を選びます。
Review + create → Create で作成します。

この時点ではカタログを入れる器を作っただけです。MCP asset の登録と、利用者が閲覧する API Center portal の構成は後編で行います。

4. 注文照会の REST API を準備する

4.1 backend を追加しない最小サンプルを作る

APIM は backend のない HTTP API を作り、mock response を返せます。本例はこの機能を使った接続確認用の架空 APIです。既存の HTTP 互換 REST API を使う場合は、この章の代わりに、その API の到達性・認証・schema を確認してください。[^mock-api][^mcp-export]

最初に APIM の Products → + Add で、検証用 Product mcp-lab を作成します。Requires subscription を有効にし、匿名の open product にしません。利用者への公開を目的としないため、APIM 開発者ポータルへの Published は必須ではありません。[^apim-product][^subscriptions]

次に APIs → APIs → + Add API → HTTP → Full で、次の値を設定します。[^mock-api]

設定	値
Display name / Name	`Orders Demo` / `orders-demo`
API URL suffix	`orders-demo`
Web service URL	backend なしのため未指定
Products	`mcp-lab`
Gateways	選択肢がある場合は Managed
Subscription required	有効のまま

+ Add Operation で 1 つだけ operation を追加します。

設定	値
Display name / Name	`Get order` / `get-order`
Method / URL	`GET` / `/orders/{orderId}`
Path parameter	`orderId`、string、注文番号
Description	`Read a fictional order for an MCP connectivity demo. No write actions.`
Responses	`200`、`application/json`、次の sample。`404` も error response として追加

json

{
  "orderId": "42",
  "status": "processing",
  "totalYen": 12800
}

この JSON は サンプルデータであり、実行結果ではありません。REST operation の入出力を定義してから MCP 化し、agent がツールを選ぶための説明も付けます。

4.2 元の REST operation にだけ mock policy を設定する

orders-demo → Design → get-order → Inbound processing の policy editor で、次の例を設定します。choose と return-response を使い、注文番号 42 以外には 404 を返します。既存インスタンスでは、必要な <base /> や継承済みの認証・監視設定を消さずに統合します。[^choose-policy][^return-response]

xml

<policies>
  <inbound>
    <base />
    <choose>
      <when condition='@(context.Request.MatchedParameters["orderId"] != "42")'>
        <return-response>
          <set-status code="404" reason="Not Found" />
          <set-header name="Content-Type" exists-action="override">
            <value>application/json</value>
          </set-header>
          <set-body>{"error":"order_not_found"}</set-body>
        </return-response>
      </when>
    </choose>
    <return-response>
      <set-status code="200" reason="OK" />
      <set-header name="Content-Type" exists-action="override">
        <value>application/json</value>
      </set-header>
      <set-body>{"orderId":"42","status":"processing","totalYen":12800}</set-body>
    </return-response>
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

これは元の REST operation の応答を作る policy です。MCP サーバーの policy に貼らないでください。 MCP のプロトコル応答を固定 JSON に置き換えるものではありません。

4.3 検証用 subscription を発行して REST を確認する

APIM の APIs → Subscriptions → Add subscription で、名前を mcp-lab-client、Scope を Product mcp-lab にして作成します。Active であることを確認し、primary / secondary key のいずれかを検証用に利用します。All-access subscription のキーを通常のクライアントに配布しません。[^subscription-create][^subscriptions]

orders-demo の Test または HTTP クライアントで、次の点を確認してから MCP 化します。

Product に対応するキー付きの GET /orders-demo/orders/42 が、定義した 200 と JSON を返す。
GET /orders-demo/orders/999 が 404 を返す。
キーなし・無効なキーは拒否される。

これは読者が実施する確認項目であり、本稿で採取済みの結果ではありません。Test console が自動選択する管理用 all-access key に頼らず、実際にクライアントへ渡す Product scope のキーで確認します。

5. REST API を MCP サーバーとして公開する

5.1 公開する operation を限定する

Azure portal の APIM で、次の手順を実施します。[^mcp-export]

APIs → MCP Servers → + Create MCP server を開きます。
Expose an API as an MCP server を選びます。
Backend MCP server の API に orders-demo を指定します。
API operations は get-order だけを選びます。更新・削除などを追加しません。
Display name / Name を Orders MCP / orders-mcp、Description を架空の注文照会であることが分かる内容にします。
Products に mcp-lab を指定して作成します。
MCP Servers 一覧の Server URL を控え、Tools で生成された tool 名・description・input schema を確認します。

Server URL は、たとえば https://<APIM_NAME>.azure-api.net/orders-mcp/mcp の形ですが、入力値から URL を推測せず、実際に表示された値を使います。tool 名も自動生成結果を確認し、get-order という REST operation 名がそのまま MCP tool 名になることを前提にしません。

REST API から生成する MCP は tools が対象であり、resources / prompts と APIM workspaces は現行の対象外です。既存 MCP の passthrough と混同しないでください。[^mcp-export][^mcp-overview]

5.2 MCP の入口と元の REST API の保護を確認する

MCP サーバーでも subscription を要求する設定を確認します。MCP は管理上 API リソースとして表現され、subscriptionRequired を含む設定管理の対象です。MCP の portal で該当設定を確認し、MCP と REST の両方で subscription 要件を維持します。両 API が同じ protected Product mcp-lab に属することも確認します。[^manage-mcp][^subscriptions]

この例の client は Ocp-Apim-Subscription-Key を送ります。APIM のキー方式と request header の引き継ぎは公式に説明されていますが、global / API policy による削除・置換もあり得るため、MCP 経由で元の API の要件を満たすことは実際に確認してください。元 API の認証を解除することでエラーを消す手順にはしません。[^mcp-security][^subscriptions]

次の点も確認します。

MCP または元の REST API が、subscription 不要の open product にも登録されていないこと。open product は匿名の経路を作る場合があります。[^subscriptions]
Product scope だけに必須の認可を置いていないこと。API scope / all-APIs scope の subscription では Product policy が適用されない経路があります。[^subscriptions]
キーを description、Runtime URL の query、repository、ログに記録しないこと。

このキーはアプリ・利用契約の識別用です。社員本人のサインインやユーザー単位の業務認可を実現したものではありません。利用者単位の OAuth は後編の本番構成への拡張で分けて扱います。

5.3 streaming を壊す診断・policy を避ける

公式手順の注意に従い、All APIs の診断設定で Frontend Response の Number of payload bytes to log を 0 にします。また MCP policy では context.Response.Body を参照しません。応答の buffering が MCP の streaming に干渉するためです。[^mcp-export]

共有 APIM では、この変更は他の API の診断にも影響します。 管理担当者の承認を得て、変更前の値・既存 MCP の要件・API scope の個別診断を記録してから変更します。管理上許可されない場合は、共通設定を無断で変えず、専用の検証インスタンスを使います。

global policy は MCP scope の policy より先に評価されます。新しい MCP サーバーの設定だけでなく、既存の all-APIs 設定も確認してください。[^mcp-export]

6. 後編への引き継ぎと検証の終了

後編へ進む前に、MCP Server URL、生成された tool 名・schema、Product と subscription の対応を控えます。キーは別の安全な経路で管理し、カタログや repository には残しません。MCP の初期化・tool 発見・実行・拒否条件は、後編で実際の client から確認します。

続ける場合は作成したリソースを残し、後編：API Center への登録・検索と VS Code からの利用へ進みます。利用していない間も APIM の課金には注意してください。

検証をここで終了する場合は、検証用 subscription を suspend / delete し、今回追加した MCP server、REST mock API、Product の関連付けを確認して削除します。他用途の subscription や API は操作しません。専用 Resource group ごと削除する場合も、今回作った検証用リソースだけが入っていることを確認します。[^subscriptions][^apim-create]

共有 APIM の共通診断を変更した場合は、管理担当者と復元可否を確認します。他の MCP が payload logging 0 を必要とする場合は無条件に戻さず、承認された設定を維持します。

7. まとめ

前編では、APIM と API Center を用意し、架空の注文照会 REST API を MCP tools として公開する手順を扱いました。公開 operation の限定、MCP と元 REST のキー要件の維持、streaming を壊さない診断・policyが要点です。

API Center はまだ作成しただけで、カタログ登録・閲覧権限・client 接続は後編で構成します。APIM に表示される Server URL と、用途を限定した Product scope のキーを引き継いでください。

8. 参考情報

Overview of MCP servers in Azure API Management — APIM における MCP 公開方式と対応範囲の入口
Expose REST API as MCP server — REST operation の公開と診断設定の公式手順
Azure API Management - V2 Tiers — 最小例から本番構成へ進む際の SKU 選定
Azure API Management のネットワーク構成パターン：Private Endpoint・VNet integration・injection の選び方 — public / private の入口と出口を選ぶ関連記事
Azure AI Gateway で API を MCP サーバー化する：認証方式とユーザー単位の設定ガイド — 実行時の利用者認証と backend 委任の関連記事
Azure MCP カタログ構築ガイド（後編）：API Center への登録・検索と VS Code からの利用 — カタログ登録、閲覧制御、client 利用と検証の続き

[^api-center-overview]: Azure API Center - Overview — Microsoft Learn（確認日: 2026-10-12）

[^mcp-overview]: Overview of MCP servers in Azure API Management — Microsoft Learn（確認日: 2026-10-12）

[^mcp-export]: Expose REST API as MCP server — Microsoft Learn（確認日: 2026-10-12）

[^mcp-register]: Inventory and Discover MCP Servers in Your API Center — Microsoft Learn（確認日: 2026-10-12）

[^portal-setup]: Set Up the API Center Portal — Microsoft Learn（確認日: 2026-10-12）

[^mcp-security]: Secure access to MCP servers in Azure API Management — Microsoft Learn（確認日: 2026-10-12）

[^mock-api]: Tutorial: Mock API Responses in API Management — Microsoft Learn（確認日: 2026-10-12）

[^api-center-access]: Configure API access in Azure API Center — Microsoft Learn（確認日: 2026-10-12）

[^apim-create]: Quickstart: Create Azure API Management Instance using the Portal — Microsoft Learn（確認日: 2026-10-12）

[^api-center-create]: Quickstart - Create Your Azure API Center - Portal — Microsoft Learn（確認日: 2026-10-12）

[^role-assignment]: Assign Azure roles using the Azure portal — Microsoft Learn（確認日: 2026-10-12）

[^v2-regions]: Azure API Management - Availability of v2 tiers and workspace gateways — Microsoft Learn（確認日: 2026-10-12）

[^apim-product]: Tutorial - Create and publish a product in Azure API Management — Microsoft Learn（確認日: 2026-10-12）

[^subscriptions]: Subscriptions in Azure API Management — Microsoft Learn（確認日: 2026-10-12）

[^choose-policy]: Azure API Management policy reference - choose — Microsoft Learn（確認日: 2026-10-12）

[^return-response]: Azure API Management policy reference - return-response — Microsoft Learn（確認日: 2026-10-12）

[^subscription-create]: Create Subscriptions in Azure API Management — Microsoft Learn（確認日: 2026-10-12）

[^manage-mcp]: Manage MCP Servers Programmatically in API Management — Microsoft Learn（確認日: 2026-10-12）

1. はじめに

2. 構成と前提条件を決める

2.1 カタログと runtime の責任を分ける

2.2 用意するリソースと権限

3. APIM と API Center を作成する

3.1 APIM の managed gateway を用意する

3.2 API Center を用意する

4. 注文照会の REST API を準備する

4.1 backend を追加しない最小サンプルを作る

4.2 元の REST operation にだけ mock policy を設定する

4.3 検証用 subscription を発行して REST を確認する

5. REST API を MCP サーバーとして公開する

5.1 公開する operation を限定する

5.2 MCP の入口と元の REST API の保護を確認する

5.3 streaming を壊す診断・policy を避ける

6. 後編への引き継ぎと検証の終了

7. まとめ

8. 参考情報

この記事をシェア

関連記事

GitHub Copilot カスタマイズ応用編 — Agent Plugins でカスタマイズをパッケージ化する

GitHub Actions から Azure への OIDC 認証設定ガイド — シークレットレス連携

生成AIで「ドキュメント再利用性」を高めるドキュメント管理サービス調査

GitHub Copilot の Agent Skills は効果があるか — 公開研究と A/B 評価で確かめる

GitHub Copilot cloud agent を使いこなす：タスク自動化から PR レビューまで

GitHub Copilot cloud agent へのタスク指示の書き方：プロンプト設計パターン集