Visual Studio CodeでAzure MCP Serverを使うポイントは、GitHub CopilotのエージェントモードからAzureリソースの確認や操作を自然言語で実行できるようにすることです。便利な一方で、Azure RBAC、ローカル認証情報、Copilotの実行許可設定がそのまま影響するため、管理者は「誰が、どのサブスクリプションで、どの操作まで許可するか」を先に決める必要があります。
Microsoft LearnのAzure MCP Server概要ページは2026年6月29日に更新され、Azure MCP ServerはMCPに対応したAI開発ツールからAzureリソース管理、デプロイ、クラウドサービスの照会を行うための統一的な接続手段として整理されています。Visual Studio Code向けの個別手順では、Azureアカウント、Visual Studio Code、GitHub Copilot拡張機能を前提に、拡張機能または.vscode/mcp.jsonでAzure MCP Serverを接続する流れが示されています。(Microsoft Learn)
Visual Studio Code向けAzure MCP Serverとは何か
Azure MCP Serverは、Model Context Protocol（MCP）を使ってAIアプリやエージェントとAzureサービスをつなぐサーバーです。Visual Studio Codeでは、GitHub CopilotのエージェントモードからAzure MCP Serverをツールとして呼び出し、Azureリソースグループの一覧取得、ストレージアカウントの確認、テーブルの取得などをプロンプトで実行できます。(Microsoft Learn)
従来はAzure CLI、Azure Portal、PowerShell、SDKなどを使い分ける必要がありました。Azure MCP Serverを使うと、開発者は「このサブスクリプションのリソースグループを一覧表示して」「ストレージアカウントを確認して」のように自然言語で依頼し、Copilotが必要なAzure MCP Server操作を選択する形になります。
ただし、これは単なるチャット補助機能ではありません。Azure MCP Serverは、認証済みのAzureアカウントやロールに基づいてAzureリソースへアクセスします。つまり、管理者視点では「AIからAzureを操作できる経路が1つ増える」と考えるべきです。
今回の更新ポイントで押さえるべき要点
今回の公式情報から読み取れる重要点は、Azure MCP ServerがVisual Studio Codeだけに閉じた機能ではなく、複数の開発ツール、GitHub Copilot関連ツール、Docker、Python、.NETなどから利用できる共通基盤として位置付けられていることです。Microsoft Learnの概要ページでは、接続先としてCline、Cursor、IntelliJ、Visual Studio、Visual Studio Code、Windsurfなどが並び、さらにGitHub Copilot CLI、GitHub Copilot SDK、GitHub Copilot cloud agent、Docker、Python、.NETからの利用も案内されています。(Microsoft Learn)
Visual Studio Code向けの実務上の変更点は、次の3つに整理できます。
| 確認項目 | 内容 | 管理者・開発チームへの影響 |
|---|---|---|
| 接続方法 | VS Code拡張機能、または.vscode/mcp.jsonによるディレクトリ単位の設定 | 個人利用とプロジェクト標準化のどちらで導入するか判断が必要 |
| 認証 | Azure CLI、Azure Developer CLI、Visual Studio、Visual Studio Codeなどのローカル開発ツールの資格情報を検出 | 既存のローカル認証運用がCopilot経由の操作にも影響する |
| 実行許可 | CopilotがAzure MCP Server操作の実行前に許可を求める | 「Always allow」を安易に選ばせない運用ルールが必要 |
特に重要なのは、Azure MCP Serverの導入そのものよりも、導入後に「CopilotがAzure上で何を実行できる状態になるか」です。検証環境で問題なく動いたとしても、本番サブスクリプションで同じ権限を与えると、意図しない変更操作につながる可能性があります。
前提条件：導入前に必要なもの
Visual Studio CodeでAzure MCP Serverを使うには、少なくとも次の環境が必要です。公式手順では、アクティブなサブスクリプションを持つAzureアカウント、Visual Studio Code、GitHub Copilot Visual Studio Code拡張機能が前提条件として示されています。(Microsoft Learn)
| 前提条件 | 確認内容 | 実務での注意点 |
|---|---|---|
| Azureアカウント | 利用対象のサブスクリプションにアクセスできること | 検証用と本番用のサブスクリプションを分ける |
| Visual Studio Code | GitHub Copilotエージェントモードを利用できる環境 | 会社管理端末では拡張機能ポリシーも確認する |
| GitHub Copilot拡張機能 | Copilot Chat/Agent Modeが使えること | ライセンス、組織ポリシー、利用可能なモデル設定を確認する |
| Azure CLIなどの認証ツール | az loginやVS CodeのAzureサインインが使えること | 共有端末や複数テナント環境ではサインイン先の誤りに注意する |
| Azure RBAC | 操作対象リソースへの適切なロールがあること | 最初はReaderなど読み取り権限から始める |
初心者がつまずきやすいのは、「Copilotのライセンスがあること」と「Azureリソースを操作できる権限があること」を混同するケースです。GitHub Copilotが使えても、Azure RBACで許可されていないリソースにはアクセスできません。逆に、強いAzure権限を持つユーザーがAzure MCP Serverを使うと、Copilot経由でも広い範囲の操作が可能になります。
インストール方法は拡張機能とディレクトリ設定の2通り
Visual Studio Code向けの公式手順では、Azure MCP Serverの導入方法として「拡張機能のインストール」と「ディレクトリのインストール」が示されています。拡張機能として入れると、最新のプレビュー版と自動更新を受け取れる点が説明されています。(Microsoft Learn)
拡張機能でインストールする場合
個人の検証や、開発者ごとに最新機能を試したい場合は、Azure MCP Server拡張機能のインストールが簡単です。インストール後にGitHub Copilotを開き、エージェントモードを選択し、ツール一覧を更新するとAzure MCP Serverが利用可能なツールとして表示されます。
この方法のメリットは、セットアップが簡単で更新を追いやすいことです。一方で、組織でバージョンや挙動をそろえたい場合には、自動更新による差分が問題になることがあります。検証環境では拡張機能、本番相当の開発環境ではバージョン管理できる設定方式、という使い分けが現実的です。
.vscode/mcp.jsonで設定する場合
プロジェクト単位でAzure MCP Serverを使う場合は、ワークスペースのルートに.vscodeフォルダーを作成し、mcp.jsonを配置します。公式手順では、次のようなJSONを追加する例が示されています。(Microsoft Learn)
{
"servers": {
"Azure MCP Server": {
"command": "npx",
"args": [
"-y",
"@azure/mcp@latest",
"server",
"start"
]
}
}
}この方式は、プロジェクトのREADMEや開発環境構築手順に組み込みやすい点が強みです。ただし、@azure/mcp@latestを使うと実行時点の最新版が使われるため、再現性を重視するチームではバージョン固定を検討してください。特に規制業種や本番影響のある開発では、「便利だからlatest」ではなく、「検証済みバージョンを使う」ほうが安全です。
認証の仕組み：Azure CLIやVS Codeのサインイン状態を利用する
Azure MCP Serverは、AzureアカウントとMicrosoft Entra IDを使って認証します。公式手順では、Azure CLI、Azure Developer CLI、Visual Studio、Visual Studio Codeなどのローカル開発ツールでAzureに認証しておく必要があり、Azure MCP Serverはこれらの資格情報を自動検出してAzureサービスへの認証に使うと説明されています。(Microsoft Learn)
代表的な確認コマンドは次の通りです。
az login
az account showaz account showで確認すべきなのは、単にログインできているかではありません。次の3点を確認します。
| 確認項目 | 見るべきポイント | よくある失敗 |
|---|---|---|
| アカウント | 想定したユーザーでサインインしているか | 個人アカウントや別テナントでログインしている |
| サブスクリプション | 操作対象のサブスクリプションになっているか | 検証環境のつもりが本番サブスクリプションを見ている |
| テナント | 会社のMicrosoft Entra IDテナントか | ゲスト参加先のテナントを操作しようとして失敗する |
複数サブスクリプションを持つ組織では、Azure MCP Serverを試す前にaz account setで検証用サブスクリプションを明示しておくと安全です。Copilotに「すべてのリソースグループを表示して」と依頼した場合、どのサブスクリプションを見ているのかが曖昧だと、トラブルシューティングや監査が難しくなります。
Azure RBACは最小権限から始める
公式手順では、ユーザーアカウントに操作対象のAzureサービスへ適切なロール割り当てが必要であり、例としてBlob Storage Data Contributor、Storage Account Contributor、Contributor、Readerが挙げられています。(Microsoft Learn)
実務では、最初からContributorを付与するのは避けるべきです。Azure MCP Serverの検証では、まずReaderでリソース一覧や構成確認だけを試し、必要な操作が明確になってから個別のロールを追加します。
| 利用目的 | 推奨する初期権限 | 判断基準 |
|---|---|---|
| リソース確認だけ | Reader | リソースグループ、ストレージ、App Serviceなどの一覧確認 |
| Blobの読み書き検証 | Blob Storage Data Contributor | ストレージアカウントの管理ではなくデータ操作が中心 |
| ストレージ設定変更 | Storage Account Contributor | ネットワーク設定や構成変更が必要な場合 |
| 広範な検証 | Contributorを限定スコープで付与 | 検証用リソースグループなど範囲を絞る |
| 本番環境操作 | 原則として個別承認制 | 自動許可や広範な権限付与は避ける |
ポイントは、Azure MCP Server専用の特別な権限モデルがあるわけではなく、Azure RBACがそのまま効くことです。既存の権限設計が粗い組織では、Azure MCP Server導入をきっかけに、開発者のContributor権限を見直す価値があります。
Copilotの実行許可で注意すべき「Always allow」
Visual Studio Codeでプロンプトを実行すると、Copilotは必要なAzure MCP Server操作を実行するための許可を求めます。公式手順では、許可の選択肢として「現在のセッション」「現在のワークスペース」「常に許可」に相当する動作が示されています。(Microsoft Learn)
この中で最も注意が必要なのが「常に許可」です。検証中に毎回確認されるのが面倒だからといって選ぶと、以後のセッションやワークスペースで操作が自動的に進みやすくなります。読み取り操作だけなら影響は限定的ですが、書き込みや削除を伴う操作が有効な権限で実行される環境ではリスクが高まります。
運用ルールとしては、次のように分けると分かりやすくなります。
| 操作の種類 | 許可設定の考え方 | 例 |
|---|---|---|
| 読み取り専用 | セッション単位またはワークスペース単位で許可 | リソースグループ一覧、ストレージ一覧 |
| 軽微な検証操作 | 検証用リソースグループ内に限定 | テスト用リソースの作成、設定確認 |
| 本番影響のある操作 | 毎回確認し、変更管理プロセスを通す | ファイアウォール変更、削除、スケール変更 |
| 機密情報に関わる操作 | 原則禁止または個別承認 | Key Vaultシークレット、接続文字列、証明書 |
「Copilotに聞いただけ」のつもりでも、MCPツールが実行されると実際のAzure環境にアクセスします。管理者は、開発者向けガイドに「Always allowを使ってよい範囲」を明記しておくべきです。
どんなプロンプトでテストすべきか
公式手順では、Azure MCP Serverの動作確認として「List my Azure resource groups」のようなプロンプトを入力し、リソースグループ一覧を取得する例が示されています。ほかにも、サブスクリプション内のストレージアカウント一覧や、ストレージアカウント内のテーブル取得を試す例があります。(Microsoft Learn)
最初のテストでは、書き込み操作ではなく読み取り操作に限定してください。おすすめの順序は次の通りです。
| 手順 | プロンプト例 | 確認すること |
|---|---|---|
| 1 | List my Azure resource groups | 認証、サブスクリプション、RBACが正しいか |
| 2 | List all of the storage accounts in my subscription | 対象サービスの一覧取得ができるか |
| 3 | Show details for the storage account named xxx | 特定リソースの詳細を確認できるか |
| 4 | Use read-only operations only | Copilotが読み取り前提で応答するか |
| 5 | Which Azure MCP tools are available for storage? | どのツールが使われるか把握できるか |
開発チームに展開する前に、管理者またはリードエンジニアがこの順序で確認し、社内ドキュメントに「許可するプロンプト例」「禁止するプロンプト例」を書いておくと混乱を防げます。
影響範囲：開発者だけでなく管理者・セキュリティ担当も確認が必要
Azure MCP Serverは開発体験を改善する機能ですが、影響範囲は開発者の作業効率だけではありません。Azureリソースへのアクセス、ローカル端末の認証状態、GitHub Copilotの利用ポリシー、VS Code拡張機能管理、監査ログの確認まで関係します。
| 担当者 | 主な確認ポイント | 具体的なアクション |
|---|---|---|
| 開発者 | VS Code、Copilot、Azure認証の準備 | 検証用サブスクリプションで読み取り操作から試す |
| Azure管理者 | RBAC、サブスクリプション、リソースグループの範囲 | 最小権限ロールを割り当て、Contributor乱用を避ける |
| セキュリティ担当 | 機密情報、実行許可、端末管理 | Key Vaultや接続文字列へのアクセス方針を決める |
| 情シス | VS Code拡張機能、端末標準化 | 拡張機能の許可・禁止、バージョン管理を検討する |
| プロジェクト管理者 | 利用ルール、変更管理 | 本番操作は通常の変更申請フローに乗せる |
特にグローバル企業では、国・リージョン・部門ごとにAzureテナントやサブスクリプションの運用が異なることがあります。Azure MCP Serverを一律に有効化するのではなく、開発拠点ごとのクラウド運用ルールに合わせて段階的に導入するほうが安全です。
設定変更が必要になるケース
Azure MCP Serverを試すだけなら、拡張機能のインストールとAzure認証で始められます。しかし、組織利用では次のような設定変更が必要になる場合があります。
VS Code拡張機能の利用ポリシー
企業管理端末でVS Code拡張機能のインストールを制御している場合、Azure MCP Server拡張機能やGitHub Copilot関連拡張機能を許可リストに入れる必要があります。逆に、まだ社内評価が終わっていない場合は、拡張機能の自由な導入を制限する判断もあります。
.vscode/mcp.jsonのリポジトリ管理
プロジェクト単位で.vscode/mcp.jsonを配布する場合、Gitリポジトリに含めるかどうかを決めます。チーム標準の設定として共有したい場合は含める価値がありますが、個人の環境依存設定や機密情報を混ぜないよう注意してください。
mcp.jsonには、シークレットや接続文字列を直接書かないのが原則です。認証はAzure CLIやMicrosoft Entra IDの仕組みに寄せ、設定ファイルには起動コマンドと引数だけを記載する構成が望ましいです。
バージョン固定の検討
公式のVS Code手順では@azure/mcp@latestを使う例があります。これは検証を始めるには便利ですが、同じプロンプトでも日によって内部ツールの挙動が変わる可能性があります。
本番に近い開発環境では、次のような方針を検討してください。
| 方針 | 向いている場面 | 注意点 |
|---|---|---|
@latestを利用 | 個人検証、短期評価 | 変更差分を追いにくい |
| バージョン固定 | チーム標準環境、監査が必要な環境 | 更新作業が必要 |
| 拡張機能の自動更新 | 小規模チーム、最新機能重視 | 不具合時の切り戻し手順を用意する |
| 検証後に段階展開 | 大規模組織、グローバル利用 | 部門ごとの展開計画が必要 |
移行期限はあるのか
今回確認したMicrosoft LearnのVisual Studio Code向け手順には、既存環境からAzure MCP Serverへ移行しなければならない期限は示されていません。Azure CLI、Azure PowerShell、Azure Portal、SDKが置き換えられるという案内でもありません。
そのため、管理者は「いつまでに移行するか」ではなく、「どの用途からAzure MCP Serverを使わせるか」を決めるべきです。おすすめは次の順序です。
| フェーズ | 対象 | ゴール |
|---|---|---|
| 評価 | クラウド管理者、リード開発者 | 認証、RBAC、Copilot実行許可の挙動を確認 |
| 限定導入 | 検証環境の開発チーム | 読み取り操作と安全な問い合わせに限定 |
| 標準化 | 複数チーム | .vscode/mcp.json、権限、利用ルールを整備 |
| 拡大 | 本番関連チーム | 変更管理、監査、承認フローと統合 |
期限がないから放置してよい、という意味ではありません。GitHub CopilotやAIエージェントの利用が広がるほど、MCP経由でクラウドを扱う場面は増えます。早い段階で安全な利用ルールを作っておくことが重要です。
管理者が確認すべきチェックリスト
Azure MCP ServerをVisual Studio Codeで使う前に、管理者は次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 利用対象者 | 全開発者ではなく、まず検証メンバーを限定しているか |
| 対象環境 | 本番ではなく検証用サブスクリプションから始める設計か |
| RBAC | Readerなど最小権限から開始しているか |
| サインイン | Azure CLIやVS Codeで想定テナント・サブスクリプションに接続しているか |
| 実行許可 | Copilotの「常に許可」を無条件に使わせていないか |
| 機密情報 | Key Vault、接続文字列、証明書へのアクセス方針を決めているか |
| 設定ファイル | mcp.jsonにシークレットを書いていないか |
| バージョン管理 | @latest利用の可否、拡張機能の更新方針を決めているか |
| 監査 | 誰がどのAzure操作を行ったか確認できる運用か |
| 教育 | 開発者向けに許可プロンプト・禁止プロンプトを示しているか |
このチェックリストで1つでも曖昧な項目がある場合は、全社展開ではなく限定検証にとどめるべきです。Azure MCP Serverは便利な機能ですが、Azure操作の入口になる以上、通常のクラウド管理と同じレベルで統制する必要があります。
実務でのおすすめ構成
小規模な開発チームであれば、まずは次の構成で始めると安全です。
対象者：Azureに詳しい開発者またはクラウド管理者
対象環境：検証用サブスクリプション
権限：Readerから開始
導入方法：VS Code拡張機能
確認プロンプト：リソースグループ一覧、ストレージ一覧など読み取り操作
禁止事項：本番サブスクリプションでのAlways allow、シークレット取得、削除操作プロジェクト単位で標準化する段階では、.vscode/mcp.jsonをリポジトリに含め、READMEに次の情報を明記するとよいでしょう。
1. Azure CLIでサインインする
2. 検証用サブスクリプションを選択する
3. VS CodeでGitHub CopilotのAgent Modeを開く
4. Azure MCP Serverツールが表示されることを確認する
5. 読み取り専用プロンプトで動作確認する
6. 書き込み操作はチームの承認を得てから実行するこのように手順と禁止事項をセットで示すことで、開発者は迷わず使い始められ、管理者はリスクを抑えられます。
よくある失敗と回避策
CopilotがAzureへのサインインを求めない
Azure CLIなどで既に認証済みの場合、CopilotがAzureへのサインインを求めないことがあります。公式手順でも、Azure CLIなどのローカルツールで認証済みの場合はサインインを求められないと説明されています。(Microsoft Learn)
この場合は、az account showで現在のアカウントとサブスクリプションを確認してください。意図しない環境に接続していると、リソースが見えない、または見えてはいけないリソースが表示される原因になります。
Azure MCP Serverツールが表示されない
拡張機能を入れた後、GitHub Copilotのツール一覧を更新していないと表示されない場合があります。まずAgent Modeを開き、ツール一覧を更新します。それでも表示されない場合は、GitHub Copilot拡張機能、Azure MCP Server拡張機能、VS Codeのバージョン、組織ポリシーによる拡張機能制限を確認します。
権限不足で操作できない
Azure MCP Serverは、認証済みユーザーのAzure RBACに従います。権限不足で失敗する場合は、CopilotやMCPの問題ではなく、対象リソースへのロール割り当てが不足している可能性があります。
ただし、エラーが出たからといってすぐContributorを付与するのは避けてください。必要な操作を特定し、対象リソースグループや対象サービスに限定したロールを割り当てるのが基本です。
本番環境で意図せず操作しそうになる
最も避けるべき失敗です。対策として、検証用サブスクリプションを明示し、プロンプトにも「検証用サブスクリプションのみ」「読み取り専用で」と書く習慣をつけます。管理者側では、本番サブスクリプションの権限を必要最小限にし、開発者のローカル環境で安易に本番Contributorを使わせない設計が重要です。
Visual StudioとVisual Studio Codeを混同しない
今回の主な手順はVisual Studio Code向けです。Microsoft LearnのAzure MCP Server概要ページでは、接続先のコードエディターとしてVisual StudioとVisual Studio Codeの両方が案内されていますが、設定ファイルの場所や導入方法は異なります。(Microsoft Learn)
Visual Studio Codeでは.vscode/mcp.jsonを使う一方、Visual Studioではソリューションやワークスペース側のMCP設定が関係します。記事や社内手順を作る場合は、「Visual Studio」とだけ書かず、「Visual Studio Code」「Visual Studio 2022」「Visual Studio 2026」など対象IDEを明確に分けてください。
この区別を曖昧にすると、開発者が誤った拡張機能や設定ファイルを探すことになり、導入時の問い合わせが増えます。
まず何から始めるべきか
Azure MCP ServerをVisual Studio Codeで使うなら、最初に行うべきことはインストールではなく、利用範囲の決定です。検証用サブスクリプション、対象ユーザー、許可する操作、禁止する操作を決めてから、VS Code拡張機能または.vscode/mcp.jsonで接続します。
最初の検証では、Reader権限でリソースグループ一覧を取得するところから始めてください。問題なく動くことを確認したら、ストレージ、App Service、Azure Monitorなど、実際の開発業務で効果が出やすい読み取り操作へ広げます。書き込み操作や本番環境への適用は、RBAC、承認フロー、監査の確認が終わってからで十分です。
Azure MCP Serverは、Azure操作をAIエージェントに近づける強力な仕組みです。導入の成否は、機能を使えるようにすることではなく、安全に使える境界線を先に作れるかで決まります。
コメント