AI

Azure MCP Serverとは？3.0 GAの導入手順と読み取り専用・権限の設計【2026年10月】

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との違いを解説した記事に譲ります。

まとめ：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の概要ページによると、Azure MCP Serverは、AI搭載の開発ツールがMCPを通じてAzureのクラウドサービスとやり取りできるようにするサーバーです。認証はEntra IDで行い、アクセスの可否はAzure RBACで決まります。ソースはGitHubの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のリリースノートによると、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サーバーの接続と権限設計を扱った記事で詳しく扱っています。

MCP 2026-07-28のステートレス版へ移行した影響と旧版クライアントの互換

3.0は、プロトコルをMCP 2026-07-28のステートレス版へ移しました。リリースノートには、2025-11-25版のプロトコルで話すクライアントにも自動で後方互換を保つと書かれています。手元のVS CodeやClaude Codeが新しい版へ未対応でも、つながらなくなる心配はありません。

影響が出るのは自作のクライアントです。セッションと初期化の交渉が消えたため、接続ごとの状態に頼るコードは書き直しになります。詳細はMCP仕様2026-07-28版の変更点と移行手順をまとめた記事で扱いました。構造化出力（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プラグインの社内配布をまとめた記事にまとめました。

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/[email protected]",
        "server",
        "start",
        "--namespace", "group",
        "--namespace", "monitor",
        "--read-only"
      ]
    }
  }
}

版を上げるときは、リリース一覧で次のGA版を確かめてから数字を書き換えます。差分がそのまま変更記録になります。

az loginでの認証から最初のツール呼び出しまでを確認する手順

起動前に、資格情報とツールをCLIで確かめておくとクライアント側の設定ミスと切り分けられます。

# 1. Azure CLIでサインインし、既定のサブスクリプションを確認する
az login
az account show --query "{name:name, id:id}" -o table

# 2. 版を固定してCLIモードで呼び、資格情報が通るかを見る
npx -y @azure/[email protected] subscription list

# 3. 公開予定のnamespaceに含まれるツール名を一覧する
npx -y @azure/[email protected] tools list --namespace monitor --name-only

# 4. 実行せずに、storageで使えるコマンドと引数だけを調べる
npx -y @azure/[email protected] storage --learn

2番目でサブスクリプションが返れば、認証は通っています。ここで失敗するなら、クライアントを設定し直しても動きません。--learn はAzureを操作せず、コマンドの階層と引数だけをJSONで返します。

ツールの見せ方を決めるサーバーモードとnamespace絞り込みの設定

ツールは数百に及び、全部見せると選択を誤りやすくなります。

4モードの公開単位の違いとVS Codeの128ツール上限への対応

3.x系のコマンドリファレンスでは、--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の組み込みロール一覧から「閲覧者（Reader）」を基本に付け、データを読ませる場合だけ「Storage Blob Data Reader」のような読み取りロールを足します。共同作成者を持つ個人アカウントのまま使うのは、検証段階までにとどめます。

認証と権限設計：資格情報チェーンとHTTP運用時のOn-Behalf-Of

1人で使うか共有するかで、認証の考え方が変わります。

資格情報チェーンの順序とAZURE_TOKEN_CREDENTIALSでの固定

認証のドキュメントによると、標準入出力で動かすローカル実行では、次の順に資格情報を試し、最初に成功したものを使います。

  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設計を扱った記事です。HashiCorpが出す汎用のTerraform MCP Serverの導入手順とtoolsetを解説した記事は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の機能と料金をまとめた記事の製品のほうが軽く済みます。

業務システムやエージェントからAzureを安全に操作させる構成を、権限設計から任せたい場合は、生成AI開発・AI受託開発で接続範囲の線引きから実装まで対応しています。

よくある質問

導入前の検討で出やすい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ツールを実測した記事で扱っています。

AWS MCP Serverと同じ感覚で設定してよいですか？

考え方は近いものの、認証の仕組みが違います。Azure側は資格情報チェーンとEntra IDのトークン、共有時のOn-Behalf-Ofが軸です。AWS側はAWS MCP Serverの接続手順と全ツールを整理した記事で解説しました。両方をつなぐ場合も、IDと権限はクラウドごとに分けて設計します。

Foundryで作ったエージェントからAzure MCP Serverを呼べますか？

呼び出しは可能です。認証のドキュメントにはOn-Behalf-Of用のazdテンプレートがあり、呼び出し元としてFoundryのエージェントやCopilot Studioが挙がっています。サーバーはHTTPで公開し、受信認証を有効にしたまま運用します。エージェント側はFoundry Agent Serviceの移行と実装手順をまとめた記事を参照してください。

読み取り専用モードだけで本番環境につないでも安全ですか？

不十分です。--read-only はツール一覧から書き込み系を外すだけで、フラグが外れれば元に戻ります。サーバーが使うIDに閲覧者ロールだけを付け、Azure側でも書き込みを拒否させてください。二重にしておけば、片方の設定ミスでは書き込みが通りません。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.28　テックブログ リンツ不正アクセス：314万件の対象確認とパスワード強制リセット後の対処
  2. 2026.10.29　テックブログ ソニー生命の不正アクセス：38.5万件の対象確認と窓口、停止中の手続き
  3. 2026.10.27　テックブログ Brotli 脆弱性：CVE-2026-111497の影響確認とNode.js・Python・.NETの更新手順
  4. 2026.01.30　コラム 税務調査は個人と法人で何が違う？担当部署・件数・調べられる点と追徴税額を比較【令和6事務年度】
  5. 2026.09.26　コラム 価格転嫁とは？価格交渉促進月間の調査に回答義務はあるか・取適法の協議記録まで

RELATED POSTS 関連記事

一覧へ戻る

目次