Azure MCP Server と GitHub Copilot CLI の連携で重要なのは、ターミナル上の GitHub Copilot CLI から /mcp add を使って Azure MCP Server を追加し、自然言語で Azure リソースを参照・操作できる導線が整理されたことです。開発者にとっては Azure CLI やポータルを行き来する手間を減らせる一方、管理者にとっては「誰の Azure 権限で何が実行されるのか」「MCP サーバーを組織として許可するのか」を確認する必要があります。
特にグローバル組織では、GitHub Copilot CLI、Azure CLI、Node.js、Microsoft Entra ID、Azure RBAC、MCP allowlist の関係を整理してから展開することが重要です。現時点でこのクイックスタートは強制移行や廃止期限を示す告知ではなく、既存運用をすぐ置き換える話ではありません。まずは検証用サブスクリプションで読み取り系の利用から試し、利用者・権限・許可する MCP サーバーを段階的に決めるのが安全です。
Azure MCP Server と GitHub Copilot CLI 連携の位置づけ
Azure MCP Server は、AI エージェントや開発ツールが Model Context Protocol、つまり MCP を通じて Azure リソースとやり取りできるようにするサーバーです。Microsoft Learn では、Azure MCP Server が自然言語コマンドで Azure リソースにアクセスできる仕組みとして説明されており、Entra ID 認証や Azure CLI、Azure Developer CLI、各種 Azure リソースとの統合が主な特徴として挙げられています。(Microsoft Learn)
今回の「Quickstart: Integrate Azure MCP Server with GitHub Copilot CLI」は、GitHub Copilot CLI の対話型セッションから Azure MCP Server を追加する手順を扱います。Microsoft Learn のクイックスタートでは、GitHub Copilot CLI、Azure CLI、Node.js を前提に、/mcp add で azure-mcp というローカル MCP サーバーを登録する流れが示されています。(Microsoft Learn)
日付の見方には少し注意が必要です。Azure MCP Server の「Get started」ページは 2026年6月29日更新として表示され、GitHub Copilot CLI、GitHub Copilot SDK、GitHub Copilot cloud agent などの接続先が案内されています。一方で、個別の GitHub Copilot CLI クイックスタートページ自体は、確認時点では最終更新日が 2026年2月25日として表示されています。運用判断では、個別手順だけでなく Azure MCP Server ドキュメント群全体と GitHub Copilot 側の管理機能を併せて確認するのが安全です。(Microsoft Learn)
何ができるようになるのか
この連携により、GitHub Copilot CLI の中で Azure コンテキストを必要とする指示を出し、Azure MCP Server のツールを通じて Azure リソース情報を取得できます。公式クイックスタートでは、例として「List my Azure resource groups.」と入力し、Azure リソースグループの一覧を取得する流れが示されています。(Microsoft Learn)
実務上は、次のような使い方が想定しやすくなります。
| 利用シーン | 具体例 | 期待できる効果 |
|---|---|---|
| Azure リソースの確認 | リソースグループ、サブスクリプション、環境情報を確認する | Azure Portal を開く前の一次確認が速くなる |
| 開発中の調査 | デプロイ先、関連リソース、設定状況をターミナルで確認する | コード作業とクラウド確認を同じ作業場所で進められる |
| トラブルシュート補助 | 開発環境の接続先や権限不足を確認する | Azure CLI コマンドを毎回思い出す負担を減らせる |
| 手順書の標準化 | /mcp show で構成を確認し、同じ名前で MCP サーバーを登録する | チーム内の設定差分を減らせる |
ただし、これは「Azure の権限管理を不要にする機能」ではありません。Azure MCP Server のツール可用性は Azure サブスクリプションの権限に依存し、利用者には適切な GitHub Copilot サブスクリプションと Azure RBAC 権限が必要です。(Microsoft Learn)
今回確認すべき主な変更点
今回のポイントは、GitHub Copilot CLI が Azure MCP Server の接続先として明確に扱われ、CLI 上で MCP サーバーを追加・確認・削除する運用が見えるようになったことです。
| 確認項目 | 内容 | 管理者・開発者が見るべきポイント |
|---|---|---|
| 接続方法 | GitHub Copilot CLI の /mcp add で Azure MCP Server を追加 | 手順をチーム標準にするか、個人設定に任せるかを決める |
| 実行方式 | npx -y @azure/mcp@latest server start をローカル MCP サーバーとして実行 | Node.js と npm 実行、社内プロキシ、パッケージ取得ポリシーを確認する |
| 認証 | Azure CLI 認証を利用するため、環境変数は空欄でよい | az login 済みのアカウント、テナント、サブスクリプションを確認する |
| 確認方法 | /mcp show で azure-mcp が登録されているか確認 | 構成ファイル ~/.copilot/mcp-config.json の扱いを決める |
| 管理 | /mcp remove azure-mcp で削除可能 | 不要な MCP サーバーを残さない運用ルールを作る |
| 統制 | GitHub の MCP registry URL と allowlist policy が Copilot CLI にも適用される | Enterprise / Organization 管理者は許可リスト運用を検討する |
GitHub Docs でも、Copilot CLI には MCP サーバーを追加する方法として /mcp add、copilot mcp add、構成ファイル編集、レジストリからの検索・インストールが用意されていると説明されています。組織または Enterprise で MCP registry URL と allowlist policy を設定している場合、その設定は Copilot CLI にも適用され、許可された MCP サーバーだけが実行できます。(GitHub Docs)
前提条件：導入前にそろえるもの
公式クイックスタートで求められている前提条件は、GitHub Copilot CLI、Azure CLI、Node.js です。Azure CLI はインストールだけでなく、az login による認証が必要です。Node.js は npx で Azure MCP Server を実行するために必要です。(Microsoft Learn)
導入前に、少なくとも次の状態を確認しておきます。
az --version
az login
az account show
node --version
npx --version
copilot --help複数テナントや複数サブスクリプションを利用している組織では、az account show の出力を必ず確認してください。GitHub Copilot CLI から Azure MCP Server を使うとき、意図しないサブスクリプションを見ていると「リソースが見つからない」「検証環境のつもりが本番環境を参照している」といった事故につながります。
必要に応じて、作業前に対象サブスクリプションを明示します。
az account set --subscription "<subscription-id-or-name>"
az account show設定手順：GitHub Copilot CLI に Azure MCP Server を追加する
公式手順の中心は、GitHub Copilot CLI を対話モードで起動し、/mcp add から Azure MCP Server を追加することです。(Microsoft Learn)
対話モードで Copilot CLI を起動する
まずターミナルで GitHub Copilot CLI を起動します。
copilot起動後、対話型セッションで次のコマンドを実行します。
/mcp addこれにより MCP サーバーの構成フォームが開きます。
Azure MCP Server の設定値を入力する
公式クイックスタートで示されている設定値は次のとおりです。(Microsoft Learn)
| フィールド | 入力値 | 補足 |
|---|---|---|
| Server Name | azure-mcp | 後で /mcp show や /mcp remove azure-mcp で使う名前 |
| Server Type | 1、Local | ローカルプロセスとして MCP サーバーを起動する |
| Command | npx -y @azure/mcp@latest server start | Node.js の npx で Azure MCP Server を起動する |
| Environment Variables | 空欄 | Azure CLI 認証を利用するため、通常は追加不要 |
| Tools | * | すべてのツールを有効化する設定 |
入力後、Windows や Linux では Ctrl + S、macOS では Cmd + S で保存します。その後、Esc で設定画面を閉じます。保存操作を忘れると、次の確認コマンドで azure-mcp が表示されないため注意してください。
.NET で実行したい場合は、公式クイックスタートでは代替コマンドとして次の指定も紹介されています。(Microsoft Learn)
dotnet dnx -p Azure.Mcp server startただし、チーム内で手順を統一するなら、まずは公式手順どおり npx 方式で検証し、.NET 方式は .NET ランタイムやパッケージ管理方針と合わせて別途評価するのが無難です。
接続確認：/mcp show で登録状態を見る
設定後は、GitHub Copilot CLI の対話型セッションで次を実行します。
/mcp show正しく構成できていれば、MCP Server Configuration に azure-mcp が表示され、構成ファイルとして ~/.copilot/mcp-config.json が示されます。公式クイックスタートでも、/mcp show による確認が案内されています。(Microsoft Learn)
確認後、次のような Azure コンテキストを必要とするプロンプトを試します。
List my Azure resource groups.最初の検証では、リソース作成・変更・削除ではなく、リソースグループ一覧やサブスクリプション確認のような読み取り系プロンプトから始めるべきです。理由は単純で、Azure MCP Server は利用者の Azure 権限に基づいて動くため、権限設計が曖昧なまま書き込み系の確認をすると、意図しない環境に影響する可能性があるためです。
copilot mcp add で手順を自動化する選択肢
GitHub Docs では、対話型の /mcp add だけでなく、ターミナルから copilot mcp add サブコマンドで MCP サーバーを追加する方法も案内されています。ローカル、つまり stdio の MCP サーバーでは、サーバー名の後に -- を置き、その後ろに起動コマンドを指定します。(GitHub Docs)
チームのセットアップスクリプトや開発環境構築手順に組み込む場合は、次のような形で検証できます。
copilot mcp add azure-mcp -- npx -y @azure/mcp@latest server startただし、組織管理下の端末では、開発者が任意の MCP サーバーを追加できる状態が望ましいとは限りません。MCP サーバーは外部ツールやデータソースへの接続点になるため、標準化する場合は GitHub 側の MCP registry と allowlist policy を先に検討してください。
管理者が確認すべき影響範囲
Azure MCP Server と GitHub Copilot CLI の連携は、開発者の作業効率を上げる一方で、管理対象が Azure だけでなく GitHub Copilot、ローカル端末、npm パッケージ、MCP ポリシーに広がります。
| 影響範囲 | 確認ポイント | 実務上の判断基準 |
|---|---|---|
| Azure 権限 | 利用者の RBAC、対象サブスクリプション、テナント | 最初は検証用サブスクリプションと読み取り権限に限定する |
| GitHub Copilot | Copilot CLI の利用可否、組織ポリシー | 利用対象者を開発者・SRE・クラウド管理者などに限定する |
| ローカル端末 | Node.js、Azure CLI、GitHub Copilot CLI、プロキシ設定 | 標準開発端末イメージに含めるか、個別導入にするか決める |
| パッケージ取得 | @azure/mcp@latest の取得元、npm 利用可否 | 本番運用ではバージョン固定や検証済み手順を検討する |
| MCP ガバナンス | MCP registry、allowlist、許可するサーバー | 許可制にする場合は Enterprise / Organization 単位で設定する |
| 監査 | Azure 操作ログ、GitHub 側の設定変更、端末管理 | 「誰が、どの権限で、どの環境を操作したか」を追跡できる状態にする |
GitHub Docs では、組織や Enterprise が MCP server usage を管理することで、開発者に有用なツールを提供しながらセキュリティとコンプライアンスを維持できると説明されています。ポリシーでは MCP サーバーの利用を許可またはブロックしたり、MCP registry に定義したサーバーだけに制限したりできます。(GitHub Docs)
MCP allowlist と registry を使うべきケース
小規模な検証では、個人の開発端末で azure-mcp を追加するだけでも動作確認できます。しかし、複数拠点・複数国・複数チームで展開する場合は、個人任せにしない方が安全です。
GitHub Docs では、Enterprise owners と Organization owners が MCP registry URL と access control policy を設定し、対応 IDE や Copilot CLI で開発者が検出・利用できる MCP サーバーを制御できると説明されています。この機能は Copilot Enterprise または Copilot Business を対象としており、MCP registry URL と allowlist は public preview とされています。(GitHub Docs)
特に次の条件に当てはまる場合は、MCP allowlist の導入を検討してください。
| 条件 | なぜ必要か |
|---|---|
| 金融、医療、公共など規制対応が必要 | 未承認の MCP サーバー経由で外部サービスに接続されるリスクを抑えるため |
| 開発者数が多い | 個人ごとのローカル設定を把握しきれなくなるため |
| 本番 Azure 環境にアクセスできるユーザーがいる | 誤操作や過剰権限の影響が大きいため |
| npm や外部レジストリ利用に制限がある | npx 実行やパッケージ取得が社内ルールに抵触する可能性があるため |
| 複数の MCP サーバーを利用する予定がある | どの MCP サーバーを公式に許可するか整理する必要があるため |
@latest 利用時の注意点
公式クイックスタートのコマンドは、次のように @latest を使います。(Microsoft Learn)
npx -y @azure/mcp@latest server start検証段階では便利ですが、エンタープライズ運用では注意が必要です。@latest は常に最新パッケージを取得する意図の指定であり、ある日から挙動や依存関係が変わる可能性があります。
本番に近い運用で使う場合は、次のような方針を決めておくと安全です。
| 方針 | 向いているケース | 注意点 |
|---|---|---|
@latest のまま使う | 個人検証、短期 PoC | 変更検知と再現性に弱い |
| バージョン固定する | チーム標準環境、本番に近い検証 | 最新機能の取り込みには更新手順が必要 |
| 社内パッケージミラーを使う | 規制業種、大規模組織 | ミラーの更新・脆弱性対応が必要 |
| Docker や dev container に閉じ込める | 開発環境を標準化したい場合 | イメージ更新と認証連携の設計が必要 |
Microsoft Learn の Azure MCP Server「Get started」ページでは、Azure MCP Server は NuGet、NPM、PyPI などのパッケージマネージャーから利用できる一方、接続方式によっては事前インストールなしで実行できることも説明されています。(Microsoft Learn)
よくある失敗と対処法
azure-mcp が /mcp show に表示されない
最も多い原因は、設定フォームで保存していないことです。/mcp add で入力しただけではなく、Ctrl + S または Cmd + S で保存する必要があります。保存後に Esc で閉じ、再度 /mcp show を実行します。
Azure リソースが見えない
Azure CLI のログイン先が違う可能性があります。次のコマンドで、現在のアカウント、テナント、サブスクリプションを確認してください。
az account show複数サブスクリプションを使っている場合は、対象を明示します。
az account set --subscription "<subscription-id-or-name>"また、Azure 側の RBAC 権限が不足している場合もあります。Azure MCP Server は利用者の権限を超えて Azure リソースを扱うものではないため、必要最小限の権限を付与したうえで確認します。
npx が失敗する
Node.js または npm / npx が利用できない、社内プロキシで npm レジストリへの接続が遮断されている、端末の実行ポリシーで外部パッケージの取得が制限されている、といった原因が考えられます。
確認コマンドは次のとおりです。
node --version
npx --version
npm config get registry企業ネットワークでは、プロキシ設定、証明書、許可済みレジストリ、EDR による実行制御をあわせて確認してください。
Tools を * にするのが不安
公式クイックスタートでは Tools に * を指定しますが、GitHub Docs では Tools に * を指定して全ツールを有効にするほか、カンマ区切りで特定ツールだけを指定する方法も説明されています。(GitHub Docs)
検証段階では * で動作確認し、運用段階では「どのツールが必要か」「書き込み系操作をどの権限で許可するか」を整理するのがよい進め方です。MCP registry と allowlist を使う場合は、個人設定だけでなく組織ポリシーとして制御します。
移行期限はあるのか
今回の確認範囲では、このクイックスタートは Azure MCP Server と GitHub Copilot CLI の連携手順を説明するものであり、既存機能の廃止や強制移行の期限を示す内容ではありません。
そのため、管理者が取るべき対応は「期限までに移行する」ではなく、「利用を許可するか、どの範囲で標準化するかを決める」ことです。
おすすめの進め方は次のとおりです。
| フェーズ | 実施内容 | ゴール |
|---|---|---|
| 事前確認 | 利用者、GitHub Copilot プラン、Azure 権限、端末要件を棚卸しする | 使える人と使えない人を明確にする |
| PoC | 検証用サブスクリプションで azure-mcp を追加する | 読み取り系プロンプトで安全に動作確認する |
| 標準化 | 手順書、推奨コマンド、サブスクリプション選択手順を整備する | チーム間の設定差分を減らす |
| ガバナンス | MCP registry、allowlist、監査ルールを決める | 未承認 MCP サーバーの利用を抑制する |
| 展開 | 開発者・SRE・クラウド管理者など対象者を段階的に広げる | 実運用に耐えるサポート体制を作る |
グローバル展開で特に注意したいポイント
グローバル企業では、同じ Azure MCP Server 連携でも国・地域・チームによって前提が異なります。特に、Azure テナント、データ所在地、社内ネットワーク、開発端末の標準イメージ、GitHub Enterprise の管理単位が異なる場合は、単純に「全員に設定手順を配る」だけでは不十分です。
確認すべき観点は次のとおりです。
| 観点 | 確認内容 |
|---|---|
| テナント | 利用者がどの Microsoft Entra テナントにサインインするのか |
| サブスクリプション | 検証、本番、顧客別環境の切り替え手順は明確か |
| 権限 | Reader、Contributor、Owner などのロールが過剰でないか |
| 端末 | Windows、macOS、Linux で同じ手順が使えるか |
| ネットワーク | npm、GitHub、Azure API への通信が許可されているか |
| 監査 | Azure 側の操作ログと GitHub 側のポリシー管理を突き合わせられるか |
| サポート | エラー時の問い合わせ先が Azure 管理者なのか GitHub 管理者なのか明確か |
特に「本番サブスクリプションに Contributor 権限を持つ開発者」が GitHub Copilot CLI から MCP を使う場合は、読み取り系だけでなく変更系の可能性も前提にしたルール作りが必要です。最初は Reader 権限や検証用リソースグループに限定し、運用実績を見てから範囲を広げる方が安全です。
導入判断の目安
Azure MCP Server と GitHub Copilot CLI の連携は、すべての組織がすぐ本番導入すべき機能というより、Azure を日常的に扱う開発者・SRE・クラウド運用担当者の作業効率を上げるための選択肢です。
導入に向いているのは、次のような組織です。
| 向いている組織 | 理由 |
|---|---|
| Azure リソースの確認を頻繁に行う開発チーム | ターミナルから自然言語で確認でき、作業の中断が減る |
| GitHub Copilot CLI をすでに利用している組織 | 既存の CLI 作業フローに Azure コンテキストを追加しやすい |
| IaC や DevOps が定着しているチーム | Azure Portal 依存を減らし、CLI 中心の作業に寄せやすい |
| MCP ガバナンスを整備できる Enterprise | 許可リストやレジストリで統制しながら展開できる |
一方、次の状態なら、すぐに全社展開するよりも準備を優先した方がよいでしょう。
| 慎重に進めるべき状態 | 先にやるべきこと |
|---|---|
| Azure RBAC が整理されていない | 役割ごとの最小権限を見直す |
| npm パッケージ取得が統制されていない | パッケージ利用ルールやミラー方針を決める |
| GitHub Copilot の管理ポリシーが未整備 | MCP registry と allowlist の要否を判断する |
| 本番と検証の切り替え手順が曖昧 | az account show と az account set を手順に入れる |
| 監査ログの確認体制がない | Azure 側と GitHub 側の監査観点を整理する |
まず実施すべきアクション
最初にやるべきことは、Azure MCP Server をいきなり本番利用することではありません。まず、検証用サブスクリプションで公式手順どおり azure-mcp を追加し、/mcp show と読み取り系プロンプトで動作確認します。
そのうえで、次の3点を決めてください。
| 決めること | 具体的な内容 |
|---|---|
| 誰に使わせるか | 開発者全員か、クラウド担当者や一部チームに限定するか |
| どの権限で使わせるか | Reader から始めるか、検証環境のみ Contributor を許可するか |
| どう統制するか | 個人設定に任せるか、MCP registry と allowlist を使うか |
Azure MCP Server と GitHub Copilot CLI の連携は、Azure 管理を「ポータル中心」から「ターミナルと自然言語を組み合わせた作業」へ近づける機能です。ただし、便利さは権限管理とセットで考える必要があります。まずは小さく検証し、RBAC、MCP ポリシー、パッケージ取得、監査の4点を確認してから、チーム標準として展開するのが現実的です。
コメント