--- title: "Azure MCP Serverとは？3.0 GAの導入手順と読み取り専用・権限の設計【2026年10月】" url: "https://www.issoh.co.jp/tech/details/19102/" published: 2026-10-30 updated: 2026-10-30 categories: ["AI"] publisher: "株式会社一創" --- # Azure MCP Serverとは？3.0 GAの導入手順と読み取り専用・権限の設計【2026年10月】 Azure MCP Serverは、GitHub CopilotやClaude CodeなどのAIエージェントが、Model Context Protocol（MCP）を通じてAzureのリソースを参照・操作するためのMicrosoft公式サーバーです。2026年10月29日、Azure Updatesで3.0の一般提供が告知されました。本記事では3.0で何が変わったか、4つの導入経路と版の固定、ツールの公開範囲を絞る起動オプション、認証の組み立て、Azure Terraformツールの使い方を、設定例つきで整理します。MCPそのものの仕組みは[MCPの仕組みとAPIとの違いを解説した記事](https://www.issoh.co.jp/tech/details/5736/)に譲ります。 ## まとめ：Azure MCP Server 3.0を業務で使う前に決める版・公開範囲・権限 導入は数分で終わります。決めるべきは、固定する版、エージェントに見せるツール、Azureへ入るIDとロールの3点です。 版は3.0.0を明示してください。公式手順の `npx -y @azure/mcp@latest` は、2026年10月30日時点でnpmの `latest` が4.0.0-beta.4を指すため、ベータを起動します。公開範囲は `--namespace` で必要なサービスに絞り、最初は `--read-only` を付けて始めます。 ただし読み取り専用フラグはツール一覧を絞るだけで、書き込みを止める最終線はIDに付けるAzure RBACのロールです。HTTPで共有するなら、Entra IDの受信認証とOn-Behalf-Ofの組み合わせを基本にします。 ## Azure MCP Serverとは：AIからAzureを操作する公式サーバー Microsoftには「MCP」を冠した製品が複数あるため、まず位置づけを揃えます。 ### MCPクライアントとAzureの間に入るサーバーの役割と、CLIモードの関係 [Microsoft Learnの概要ページ](https://learn.microsoft.com/ja-jp/azure/developer/azure-mcp-server/overview)によると、Azure MCP Serverは、AI搭載の開発ツールがMCPを通じてAzureのクラウドサービスとやり取りできるようにするサーバーです。認証はEntra IDで行い、アクセスの可否はAzure RBACで決まります。ソースは[GitHubのmicrosoft/mcpリポジトリ](https://github.com/microsoft/mcp)でMITライセンスとして公開されており、サーバー自体の利用料はかかりません。 実行ファイルは `azmcp` の1本で、用途はMCPサーバーとCLIの2つです。`azmcp server start` で起動すればMCPサーバーとして動き、`azmcp storage account list` のように直接叩けばCLIとしてJSONを標準出力へ返します。エージェントがつまずいたツールを、人間がCLIで同じ引数のまま再現できます。 ### 3.0 GAの追加機能：Backup・SRE Agent・Terraform [3.0.0のリリースノート](https://github.com/microsoft/mcp/releases/tag/Azure.Mcp.Server-3.0.0)によると、3.0は50回のベータを経たメジャー版で、タグは2026-10-12、一般提供の告知は10-29でした。主な追加namespaceは次のとおりです。 | namespace | 対象 | 扱える内容の例 | | -------------- | --------------- | ------------------ | | azureterraform | Terraform | プロバイダ文書・AVM・取り込み | | azurebackup | Azure Backup | コンテナー・ポリシー・復元点 | | sreagent | Azure SRE Agent | エージェント・スキル（55コマンド） | | resiliency | 回復性の管理 | 復旧計画・訓練・切替の検証 | | advisor | Azure Advisor | 推奨事項の一覧とIaCへの反映 | | optimization | コスト削減 | 代替のVMサイズと使用率の説明 | このほかIoT Hubや `insights` も加わり、Cosmos DBやMonitorには既存namespaceへのツール追加がありました。Cosmos DBのツール群と権限は[Cosmos DB用MCPサーバーの接続と権限設計を扱った記事](https://www.issoh.co.jp/tech/details/6258/)で詳しく扱っています。 ### MCP 2026-07-28のステートレス版へ移行した影響と旧版クライアントの互換 3.0は、プロトコルをMCP 2026-07-28のステートレス版へ移しました。リリースノートには、2025-11-25版のプロトコルで話すクライアントにも自動で後方互換を保つと書かれています。手元のVS CodeやClaude Codeが新しい版へ未対応でも、つながらなくなる心配はありません。 影響が出るのは自作のクライアントです。セッションと初期化の交渉が消えたため、接続ごとの状態に頼るコードは書き直しになります。詳細は[MCP仕様2026-07-28版の変更点と移行手順をまとめた記事](https://www.issoh.co.jp/tech/details/18245/)で扱いました。構造化出力（`structuredContent`）は既定で無効で、`--structured-output-mode` の指定時だけ返ります。 ## 導入手順：VS Code拡張・npx・dnx・Claude Codeの4経路と版固定 経路ごとに前提のランタイムが異なります。チームでは1つに揃えます。 ### 4つの導入経路と、それぞれが向く利用者・前提となるランタイムの比較 | 経路 | 前提 | 向く利用者 | | ---------------- | ------------------- | -------------- | | VS Code拡張 | GitHub Copilot Chat | 個人の開発者 | | npx（@azure/mcp） | Node.js LTS | 他のMCPクライアント | | dnx（Azure.Mcp） | .NET 10 SDK | .NET中心のチーム | | Claude Codeプラグイン | Claude Code | Claude Code利用者 | VS Codeは拡張機能 `ms-azuretools.vscode-azure-mcp-server` を入れてAzureへサインインすれば動きます。Claude Codeでは `/plugin install azure@claude-plugins-official` で、サーバーと関連スキルがまとめて入ります。社内配布の方法は[Claude Codeプラグインの社内配布をまとめた記事](https://www.issoh.co.jp/tech/details/17849/)にまとめました。 ### npxの@latestが4.0ベータを指す問題と、3.0.0を明示して固定する設定例 READMEの設定例は `@azure/mcp@latest` です。ところがnpm registryの `dist-tags` を2026年10月30日に確認すると、`latest` は4.0.0-beta.4（10-29公開）でした。`beta` のような別タグは無く、`@latest` と書いた全員がベータを踏みます。 業務で使う設定ファイルには、版を明示します。クライアントの `mcp.json` の例です。 ``` { "mcpServers": { "azure-mcp-server": { "command": "npx", "args": [ "-y", "@azure/mcp@3.0.0", "server", "start", "--namespace", "group", "--namespace", "monitor", "--read-only" ] } } } ``` 版を上げるときは、[リリース一覧](https://github.com/microsoft/mcp/releases)で次のGA版を確かめてから数字を書き換えます。差分がそのまま変更記録になります。 ### az loginでの認証から最初のツール呼び出しまでを確認する手順 起動前に、資格情報とツールをCLIで確かめておくとクライアント側の設定ミスと切り分けられます。 ``` # 1. Azure CLIでサインインし、既定のサブスクリプションを確認する az login az account show --query "{name:name, id:id}" -o table # 2. 版を固定してCLIモードで呼び、資格情報が通るかを見る npx -y @azure/mcp@3.0.0 subscription list # 3. 公開予定のnamespaceに含まれるツール名を一覧する npx -y @azure/mcp@3.0.0 tools list --namespace monitor --name-only # 4. 実行せずに、storageで使えるコマンドと引数だけを調べる npx -y @azure/mcp@3.0.0 storage --learn ``` 2番目でサブスクリプションが返れば、認証は通っています。ここで失敗するなら、クライアントを設定し直しても動きません。`--learn` はAzureを操作せず、コマンドの階層と引数だけをJSONで返します。 ## ツールの見せ方を決めるサーバーモードとnamespace絞り込みの設定 ツールは数百に及び、全部見せると選択を誤りやすくなります。 ### 4モードの公開単位の違いとVS Codeの128ツール上限への対応 [3.x系のコマンドリファレンス](https://github.com/microsoft/mcp/blob/release/azure/3.x/servers/Azure.Mcp.Server/docs/azmcp-commands.md)では、`--mode` に4つの値が定義されています。 | モード | 見え方 | 向く場面 | | ------------- | ------------ | ------------ | | namespace（既定） | サービスごとに1ツール | 大半の対話利用 | | consolidated | 作業単位の束ね | 選択ミスを減らしたいとき | | all | 全ツールを個別に公開 | 絞り込みと併用するとき | | single | azureの1ツールだけ | 他サーバーと併用するとき | 既定がnamespaceなのは、VS Codeが全MCPサーバー合計で128ツールまでしか扱えないためです。consolidatedは `get_azure_databases_details` のような意図ベースの束ねツールを出します。まず既定で始め、選び間違いが目立ったらconsolidatedへ移る順番が手堅いでしょう。 ### –namespaceと–toolで公開範囲を業務単位に絞る起動例 サービス単位で絞るなら `--namespace` を繰り返し、操作単位まで絞るなら `--tool` を使います。2つは併用できず、`--tool` を指定すると自動でallモードに切り替わります。 ``` # 監視とリソースグループの参照だけを、読み取り専用で公開する azmcp server start --namespace monitor --namespace group --read-only # 操作を2つに限定する（all モードになる） azmcp server start --tool azmcp_subscription_list --tool azmcp_group_list ``` 障害調査の担当には `monitor`、IaCの担当には `azureterraform` のように、役割ごとに設定ファイルを分けて配ります。起動引数が、そのまま「誰に何を触らせるか」の定義になります。 ### –read-onlyが効く範囲と、RBACのロールで最終線を引く理由 リファレンスの説明では、`--read-only` は全モードで有効で、ツール一覧を読み取り専用の操作だけに絞ります。各コマンドには「Destructive」「ReadOnly」「Secret」などのメタデータがあり、フラグはこれを見て一覧から外す仕組みです。 フラグを外した設定が1つ紛れ込めば、書き込み系のツールはそのまま見えます。だから書き込みを止める最終線はAzure側の権限制御です。サーバーが使うIDには、[Azureの組み込みロール一覧](https://learn.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles)から「閲覧者（Reader）」を基本に付け、データを読ませる場合だけ「Storage Blob Data Reader」のような読み取りロールを足します。共同作成者を持つ個人アカウントのまま使うのは、検証段階までにとどめます。 ## 認証と権限設計：資格情報チェーンとHTTP運用時のOn-Behalf-Of 1人で使うか共有するかで、認証の考え方が変わります。 ### 資格情報チェーンの順序とAZURE\_TOKEN\_CREDENTIALSでの固定 [認証のドキュメント](https://github.com/microsoft/mcp/blob/main/docs/Authentication.md)によると、標準入出力で動かすローカル実行では、次の順に資格情報を試し、最初に成功したものを使います。 1. 環境変数（EnvironmentCredential） 2. Visual Studio、続いてVisual Studio Codeのサインイン 3. Azure CLI（az login） 4. Azure PowerShell、続いてAzure Developer CLI 5. ブラウザーでの対話ログイン 落とし穴は1番目です。サービスプリンシパルの環境変数が残った端末では、本人が `az login` していても、そちらの権限で動きます。`AZURE_TOKEN_CREDENTIALS=AzureCliCredential` のように1つに固定すれば、どのIDで操作したかが曖昧になりません。 ### HTTPトランスポートで社内共有するときの受信認証と送信認証の組み合わせ 既定のトランスポートは `stdio` で、`http` はDockerイメージなどHTTP有効のビルドに限られます。共有するなら、イメージ `mcr.microsoft.com/azure-sdk/azure-mcp` をAzure Container Appsなどに置く形が基本です。 HTTPでは認証が2段です。受信側は全要求にEntra IDのベアラートークンが要り、委任型なら `Mcp.Tools.ReadWrite` スコープ、アプリ単独なら `Mcp.Tools.ReadWrite.All` ロールを求めます。送信側は `--outgoing-auth-strategy` で決まり、既定は利用者のトークンを交換して本人の権限で入るOn-Behalf-Ofです。 複数人で共有するならOn-Behalf-Ofを選んでください。マネージドIDで入る `UseHostingEnvironmentIdentity` では、誰の指示でもサーバーの権限で動き、ログから実行者を追えません。アプリ単独のトークンとOn-Behalf-Ofは、交換する利用者IDが無いため組み合わせられません。 ### dangerouslyで始まる4つのオプションを本番で付けない理由 起動オプションのうち4つは、名前の頭に `dangerously` が付いています。 - `--dangerously-disable-http-incoming-auth`：HTTPの受信認証を外す - `--dangerously-disable-elicitation`：秘密情報を読むツールの実行前確認を省く - `--dangerously-disable-ssrf-protections-by-namespace`：端点のSSRF検証を外す - `--dangerously-write-support-logs-to-dir`：機微情報を含みうる詳細ログを書き出す 2番目の実行前確認は、シークレット取得などで利用者の同意を求める仕組みで、リファレンス自身が本番では使わないよう警告しています。自動化で確認が邪魔なら、確認を外さず、そのツールを公開対象から外すのが筋です。 ## Azure TerraformでIaCを生成する使い方と既存資源の取り込み GA告知の筆頭がAzure Terraformのnamespaceである `azureterraform` です。 ### azurerm・AzAPI文書とAVMを参照する読み取り専用コマンド このnamespaceのツールはすべて読み取り専用で、エージェントに、学習時点の古い引数ではなく現行のプロバイダ文書とAzure Verified Modules（AVM）を引いてから書かせる部品です。 ``` # azurerm プロバイダのリソース文書を引く azmcp azureterraform azurerm get --resource-type azurerm_storage_account # AzAPI のスキーマを API バージョン指定で引く azmcp azureterraform azapi get \ --resource-type Microsoft.Storage/storageAccounts \ --api-version 2024-01-01 # AVM の一覧と、特定モジュールの版を確認する azmcp azureterraform avm list azmcp azureterraform avm versions --module-name avm-res-storage-storageaccount ``` 認証やbackendの設計は人が決め、リソース定義の下書きをエージェントに任せます。前者の設計を整理したのが[azurerm 5系の認証とbackend設計を扱った記事](https://www.issoh.co.jp/tech/details/16542/)です。HashiCorpが出す汎用の[Terraform MCP Serverの導入手順とtoolsetを解説した記事](https://www.issoh.co.jp/tech/details/16551/)はRegistry全体が対象で、Azureに閉じるならこちらのnamespaceで足ります。 ### aztfexportとconftestは実行せずコマンドを生成するだけという設計 既存のリソースをコードへ取り込む `aztfexport` と、ポリシー検証の `conftest` にも対応しました。リソースID単位、リソースグループ単位、Resource Graphのクエリ単位の3通りで取り込め、検証は `.tf` のフォルダーと `tfplan.json` の両方を対象にできます。 見落としやすいのは、どちらも実行まではしない点です。リファレンスには、手元で流すコマンドを返すだけでAzureのリソースは変更しないと明記されています。生成されたコマンドを人が読んでから流す前提で、手作業で作られたリソースをコード管理へ移す下ごしらえに向きます。 ## Azure MCP Serverを採用してよい条件と、見送るべき場面の判断基準 つないでよい環境は限られます。 ### Azure接続を採用してよい3つの条件と、効果が出やすい具体的な業務 採用してよいのは3条件がそろうときです。接続先が検証用か、本番でも閲覧者ロールのIDで入れること。公開するnamespaceを5つ程度に絞れること。版を固定し、更新を設定ファイルの差分でレビューできること。 効果が出やすいのは障害の一次調査です。「直近1時間にエラーが増えたリソースはどれか」をMonitorから引く作業は、ポータルを何画面も開くより速く終わります。Advisorの推奨事項からIaCへの反映案を作らせる使い方も向いています。 ### 本番への書き込みや監査要件から導入を見送る場面と、代わりに選ぶ手段 本番のサブスクリプションへ、共同作成者以上のIDで書き込みを許す構成は見送ってください。エージェントが削除対象を取り違えても、ツール側では気づけません。本番の変更はIaCのパイプラインに通し、エージェントには下書きと計画の確認までを任せます。 監査要件のある環境に、マネージドIDで下流へ入る共有サーバーを置くのも避けます。ポータルでの調べ物を自然言語で済ませたいだけなら、[Azure Copilotの機能と料金をまとめた記事](https://www.issoh.co.jp/tech/details/6734/)の製品のほうが軽く済みます。 業務システムやエージェントからAzureを安全に操作させる構成を、権限設計から任せたい場合は、[生成AI開発・AI受託開発](https://www.issoh.co.jp/service/ai/development/)で接続範囲の線引きから実装まで対応しています。 ## よくある質問 導入前の検討で出やすい5つの疑問に答えます。 ### Azure MCP Serverの利用に料金はかかりますか？ サーバー自体はMITライセンスのオープンソースで、利用料はありません。費用が生じるのは、ツール経由で作成したAzureのリソースと、HTTPで共有する場合のContainer Appsなどのホスティング代です。検証用のサブスクリプションには予算アラートを設定しておいてください。 ### Azure MCP ServerとMicrosoft Learn MCP Serverの違いは何ですか？ Azure MCP Serverは、サブスクリプション内のリソースを参照・操作するサーバーで、Entra IDでの認証とRBACの権限が要ります。Microsoft Learn MCP Serverは、Microsoftの技術文書を検索して返すだけのサーバーで、Azureのリソースには触れません。接続方法は[Microsoft Learn MCP Serverの接続設定と3ツールを実測した記事](https://www.issoh.co.jp/tech/details/7269/)で扱っています。 ### AWS MCP Serverと同じ感覚で設定してよいですか？ 考え方は近いものの、認証の仕組みが違います。Azure側は資格情報チェーンとEntra IDのトークン、共有時のOn-Behalf-Ofが軸です。AWS側は[AWS MCP Serverの接続手順と全ツールを整理した記事](https://www.issoh.co.jp/tech/details/17726/)で解説しました。両方をつなぐ場合も、IDと権限はクラウドごとに分けて設計します。 ### Foundryで作ったエージェントからAzure MCP Serverを呼べますか？ 呼び出しは可能です。認証のドキュメントにはOn-Behalf-Of用のazdテンプレートがあり、呼び出し元としてFoundryのエージェントやCopilot Studioが挙がっています。サーバーはHTTPで公開し、受信認証を有効にしたまま運用します。エージェント側は[Foundry Agent Serviceの移行と実装手順をまとめた記事](https://www.issoh.co.jp/tech/details/4297/)を参照してください。 ### 読み取り専用モードだけで本番環境につないでも安全ですか？ 不十分です。`--read-only` はツール一覧から書き込み系を外すだけで、フラグが外れれば元に戻ります。サーバーが使うIDに閲覧者ロールだけを付け、Azure側でも書き込みを拒否させてください。二重にしておけば、片方の設定ミスでは書き込みが通りません。 ## 関連記事 - [MCP（Model Context Protocol）とは？仕組み・APIとの違い・MCPサーバーの作り方](https://www.issoh.co.jp/tech/details/5736/)（MCPの基本） - [Azure Cosmos DB MCPサーバーの使い方｜Azure MCP Server 3.0とMCP Toolkitの接続・権限設計](https://www.issoh.co.jp/tech/details/6258/)（Cosmos DBに絞った使い方） - [MCP仕様2026-07-28版とは：ステートレス化の変更点と2025-11-25版からの移行手順](https://www.issoh.co.jp/tech/details/18245/)（3.0が移行した仕様） - [Terraform MCP Serverとは？導入手順とtoolsetの権限設計を実装目線で解説](https://www.issoh.co.jp/tech/details/16551/)（HashiCorp版との比較） - [Microsoft Docs MCP Server（Learn MCP Server）とは？接続設定と3ツールの実測](https://www.issoh.co.jp/tech/details/7269/)（文書検索用サーバー） --- 出典: [Azure MCP Serverとは？3.0 GAの導入手順と読み取り専用・権限の設計【2026年10月】]()（株式会社一創）