2026年6月29日に更新された Azure MCP Server の公式情報で重要なのは、GitHub Copilot cloud agent が Azure の構成ファイルやリソース情報を理解し、Issue からコード変更の Pull Request を作れるようになる点です。ただし、単に機能をオンにするだけではありません。Azure 側のマネージド ID、RBAC、GitHub 側の MCP configuration、生成される GitHub Actions ワークフローを管理者が確認する必要があります。(Microsoft Learn)
結論から言うと、この変更は「Copilot に Azure の文脈を安全に渡すための設定手順」です。Bicep や Terraform で Azure を管理しているチーム、GitHub Issues を起点に開発タスクを回しているチーム、GitHub Copilot cloud agent の利用を検討している Azure 管理者は、権限設計とリポジトリ設定を先に固めてから導入するのが安全です。
Azure MCP Server と GitHub Copilot cloud agent の連携で何ができるのか
Azure MCP Server は、AI エージェントや MCP 対応クライアントが自然言語で Azure リソースにアクセスし、情報取得や開発支援を行うための仕組みです。Model Context Protocol、Microsoft Entra ID 認証、Azure RBAC を前提に、Azure CLI や Azure Developer CLI などの Azure 開発ツールとも連携します。(Microsoft Learn)
今回の「Connect GitHub Copilot cloud agent to the Azure MCP Server」は、GitHub Copilot cloud agent が Azure MCP Server を使えるようにする設定手順です。これにより、Copilot cloud agent は Azure ベースのプロジェクトで、Azure 固有のファイルやリソース情報を踏まえてコード変更を提案できます。たとえば、GitHub Issue に「Azure Database for PostgreSQL のストレージサイズを Bicep テンプレート上で上げたい」と書いて Copilot に割り当てると、Copilot cloud agent がブランチを作成し、変更を含む Pull Request を作成する流れになります。(Microsoft Learn)
ここで大切なのは、Copilot cloud agent が本番環境を勝手に変更するための機能ではないという点です。公式手順では、既定でユーザー割り当てマネージド ID に Reader ロールが割り当てられます。そのため、既定状態で期待すべき主な用途は、既存リソースを直接変更することではなく、Bicep や Terraform などのデプロイスクリプトを修正することです。(Microsoft Learn)
今回の更新で押さえるべきポイント
2026年6月29日更新の公式ページでは、手順の中心として Azure Developer CLI の azd と coding-agent 拡張機能が説明されています。GitHub の UI 上では表示名として「Copilot cloud agent」が使われますが、安定した拡張機能 ID は azure.coding-agent、CLI コマンドは azd coding-agent ... のままと説明されています。(Microsoft Learn)
| 確認項目 | 内容 | 管理者が見るべきポイント |
|---|---|---|
| 対象機能 | GitHub Copilot cloud agent と Azure MCP Server の接続 | Copilot に Azure リソース文脈を渡す範囲を決める |
| 主な設定ツール | azd coding-agent config | 実行者に Azure と GitHub の適切な権限があるか確認する |
| Azure 側の認証 | ユーザー割り当てマネージド ID | 既定の Reader から権限を広げる場合は理由を明確にする |
| GitHub 側の設定 | リポジトリの MCP configuration | JSON の内容、利用可能ツール、対象リポジトリを確認する |
| 自動生成物 | GitHub Actions ワークフロー設定を含むブランチ | そのままマージせず、ワークフローと権限をレビューする |
| 移行期限 | 公式ページ上では強制移行日や廃止期限の記載は確認できない | 緊急移行ではなく、検証環境から段階導入する |
影響範囲：誰が確認すべきか
この更新の影響は、Azure 管理者だけに閉じません。GitHub のリポジトリ設定、Copilot の利用ポリシー、Azure RBAC、CI/CD ワークフローが交差するため、複数の担当者で確認する必要があります。
| 役割 | 主な影響 | 確認すべきこと |
|---|---|---|
| Azure 管理者 | マネージド ID と RBAC の管理 | Reader で足りるか、追加ロールが必要か、スコープはサブスクリプションかリソースグループか |
| GitHub 管理者 | Copilot cloud agent と MCP 設定の管理 | 対象リポジトリ、MCP configuration、Actions ワークフロー、Secrets/Variables |
| DevOps 担当者 | IaC と Pull Request 運用 | Bicep/Terraform の変更レビュー、CI/CD の実行条件、環境分離 |
| セキュリティ担当者 | 自律実行ツールの制御 | Copilot が利用できるツール、ログ、権限昇格、秘密情報の扱い |
| 開発チーム | Issue 起点の作業委任 | Copilot に依頼してよいタスクと、人が判断すべきタスクの線引き |
特に注意したいのは、MCP server を設定すると、Copilot はそのサーバーが提供するツールを自律的に使用でき、使用のたびに承認を求めるわけではない点です。GitHub Docs でも、MCP server 設定後は Copilot が提供ツールを自律的に使えることが警告されています。(GitHub Docs)
前提条件：導入前にそろえるもの
公式手順では、Azure アカウントと Azure サブスクリプションへのアクセス、GitHub アカウント、GitHub Copilot サブスクリプション、既存の GitHub リポジトリのローカルクローンが前提です。また、対象リポジトリには Bicep や Terraform など、Azure へのデプロイに関係するスクリプトが含まれていることが想定されています。(Microsoft Learn)
実務では、次の状態を満たしてから作業を始めると失敗しにくくなります。
- Azure サブスクリプションとテナントを特定できている
- 対象リポジトリが GitHub 上にあり、Copilot cloud agent の利用対象になっている
- Bicep、Terraform、Azure Developer CLI などのデプロイ資産がリポジトリ内で管理されている
- Copilot が作成する Pull Request をレビューする担当者が決まっている
- 本番環境に対する直接変更を許可するかどうかの方針が決まっている
設定手順：管理者が見るべき流れ
公式手順では、多くの作業を azd の coding-agent 拡張機能で自動化できます。ただし、完全自動ではありません。生成されたブランチのマージ、Azure ロールの調整、GitHub 側の MCP configuration 追加は、人が確認して進める必要があります。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | azd をインストールする | チーム標準のバージョン管理、実行端末の権限 |
| 2 | 対象リポジトリのローカルクローンに移動する | 作業対象のリポジトリを間違えない |
| 3 | azd coding-agent config を実行する | Azure サブスクリプション、GitHub リポジトリ、マネージド ID を確認 |
| 4 | Azure location と resource group を選ぶ | アプリの実体に近いリージョン・リソースグループを選ぶ |
| 5 | 生成されたブランチを確認する | GitHub Actions ワークフロー、環境、Secrets/Variables をレビュー |
| 6 | 必要に応じて RBAC を調整する | 既定の Reader から広げる場合は最小権限にする |
| 7 | GitHub 側に MCP configuration を追加する | JSON、tools、対象サーバー名、設定場所を確認 |
| 8 | Issue を作成して Copilot に割り当てる | Issue 文に「Azure」を含め、変更範囲を明確にする |
公式ページでは、azd coding-agent config 実行時に Azure サブスクリプション、GitHub リポジトリ、ユーザー割り当てマネージド ID の新規作成または既存利用、Azure location、resource group などを選択すると説明されています。選択する location と resource group は、対象アプリケーションの Azure リソースに合わせるのが自然です。(Microsoft Learn)
MCP configuration の基本形
GitHub 側には、Azure MCP Server を Copilot cloud agent に認識させるための JSON を設定します。公式ページでは、次のような構成例が示されています。(Microsoft Learn)
{
"mcpServers": {
"Azure": {
"type": "local",
"command": "npx",
"args": [
"-y",
"@azure/mcp@latest",
"server",
"start"
],
"tools": [
"*"
]
}
}
}この例では、npx で @azure/mcp@latest を実行し、Azure MCP Server を起動します。tools に * を指定しているため、利用可能なツールを広く許可する形です。検証環境ではこの形で動作確認しやすい一方、本番相当のリポジトリでは「本当に全ツールを許可してよいか」を確認する必要があります。
GitHub Docs では、リポジトリ管理者が GitHub.com のリポジトリ設定から MCP servers を構成でき、JSON 形式の mcpServers オブジェクトを登録すると説明されています。また、リポジトリレベルの MCP configuration は Copilot cloud agent と Copilot code review で共有されます。(GitHub Docs)
GitHub の設定画面名に注意する
Microsoft Learn の Azure MCP Server ページでは、GitHub の設定場所として「Settings > Copilot > cloud agent > MCP configuration」が案内されています。一方、GitHub Docs では「Settings > Copilot > MCP servers」という経路で MCP configuration を追加する説明になっています。(Microsoft Learn)
これは、GitHub 側の UI や機能整理によって画面名が変わる可能性があるためです。実際の運用では、リポジトリの Settings 配下で Copilot 関連項目を開き、「Model Context Protocol」「MCP」「MCP servers」「MCP configuration」といった名称の設定画面を確認するとよいでしょう。
権限設計：最初は Reader を前提に考える
この連携で最も重要なのは、Copilot cloud agent にどの Azure 権限を与えるかです。公式手順では、azd の coding-agent 拡張機能がユーザー割り当てマネージド ID を作成または利用し、既定で Reader ロールを割り当てます。(Microsoft Learn)
Reader のままであれば、Copilot cloud agent は Azure リソースを参照しながら、Bicep や Terraform などのコード変更を提案する用途に向きます。一方、リソース作成、構成変更、シークレット更新、デプロイ実行まで任せたい場合は追加ロールが必要になる可能性があります。ただし、権限を広げるほど誤操作や想定外の変更リスクも大きくなります。
| やりたいこと | 推奨される考え方 |
|---|---|
| Bicep/Terraform の修正提案だけをさせたい | 既定の Reader を基本にする |
| リソース情報を参照して設定値を提案させたい | Reader と対象スコープの確認で足りるか検証する |
| 開発環境のリソース作成まで任せたい | 開発用リソースグループに限定して追加ロールを検討する |
| 本番環境の構成変更を任せたい | 原則として避け、Pull Request と人間の承認を必須にする |
| シークレットや Key Vault を扱わせたい | 最小権限、監査ログ、期限付き権限、アクセスレビューを前提にする |
Azure MCP Server は Azure user credentials または managed identity を使い、Azure RBAC によってアクセスが制御されます。ツールの可用性は Azure サブスクリプション側の権限に依存するため、Copilot 側の設定だけでなく Azure 側のロール割り当ても必ず確認する必要があります。(Microsoft Learn)
使いどころ：Copilot に任せやすいタスク
Azure MCP Server と Copilot cloud agent の組み合わせは、Azure の前提知識が必要だが、人間が最終レビューすべき変更に向いています。
たとえば、次のようなタスクです。
Azure の Bicep テンプレートで、開発環境の Azure Database for PostgreSQL Flexible Server のストレージを現在より1段階大きい構成に変更してください。対象ファイルを確認し、必要なパラメーター変更を Pull Request にしてください。Azure App Service の診断ログを有効化するため、Terraform の設定に不足している diagnostic settings を追加してください。既存の命名規則と module 構成に合わせてください。Azure リソースのタグ付けルールに合わせて、Bicep 内の storage account と key vault に environment、owner、costCenter タグを追加してください。公式ページでは、Copilot cloud agent が Azure MCP Server を使うようにするには、Issue のプロンプトに「Azure」という語を含めることが重要だと説明されています。Azure 関連タスクだと明確に伝えることで、Copilot が Azure MCP Server のツールを要求しやすくなります。(Microsoft Learn)
Copilot に任せにくいタスク
一方で、次のようなタスクは慎重に扱うべきです。
| タスク | 理由 |
|---|---|
| 本番データを変更する作業 | 影響範囲が大きく、ロールバック判断が必要 |
| Key Vault シークレットの作成・更新 | 秘密情報の露出、監査、アクセス制御が絡む |
| ネットワーク境界やファイアウォール変更 | 接続断やセキュリティ低下につながる可能性がある |
| サブスクリプション全体のリソース削除 | 誤操作時の影響が大きい |
| 複数リポジトリにまたがる大規模変更 | Copilot cloud agent はタスクごとに対象リポジトリやブランチの制約がある |
GitHub Docs では、Copilot cloud agent は1回のタスクで指定されたリポジトリの変更に限定され、1つのタスクにつき1つの Pull Request を開くという制約があります。また、セッションには最大実行時間の制限があるため、大きな改修は小さな Issue に分けるのが現実的です。(GitHub Docs)
失敗しやすいポイントと対策
導入時のトラブルは、Azure MCP Server そのものよりも、権限、GitHub 設定、Issue の書き方で起きやすくなります。
| 失敗しやすいポイント | 起きること | 対策 |
|---|---|---|
| Issue に Azure の文脈がない | Copilot が Azure MCP Server を使わない | Issue タイトルや本文に「Azure」「Bicep」「対象サービス名」を明記する |
Reader 権限のまま直接変更を依頼する | 既存リソース変更が認可されない | IaC の変更依頼に寄せるか、開発環境だけ追加権限を検討する |
| 生成ブランチを確認せずマージする | 想定外の GitHub Actions 設定が入る可能性がある | ワークフロー、Secrets、環境名、権限をレビューしてからマージする |
tools: ["*"] をそのまま本番リポジトリで使う | Copilot が広いツールセットを使える | 必要なツール範囲を検討し、検証環境で挙動を確認する |
| GitHub の画面名だけを頼りにする | 設定場所が見つからない | Copilot 配下の MCP servers / MCP configuration を探す |
| 大きすぎる Issue を投げる | セッション時間やレビュー負荷が増える | 「1 Pull Request でレビューできる単位」に分割する |
| テナントやサブスクリプションが曖昧 | 403 Forbidden や誤った環境参照につながる | Issue や設定で subscription、tenant、resource group を明示する |
Azure MCP Server の概念ドキュメントでも、401 は認証トークンや資格情報の問題、403 は RBAC 権限不足、サブスクリプションやテナントの誤りなどで発生し得ると説明されています。特に複数テナント・複数サブスクリプションを扱う企業では、Copilot に依頼する文面にも対象スコープを明記した方が安全です。(Microsoft Learn)
セキュリティ上の注意点
MCP は便利ですが、Copilot cloud agent に外部ツールやデータソースへの経路を与える仕組みでもあります。設定後の Copilot は、MCP server が提供するツールを自律的に使えるため、承認フローを Pull Request レビューだけに頼りすぎない方が安全です。(GitHub Docs)
特に注意したいのは、GitHub の content exclusions との関係です。GitHub Docs では、Copilot cloud agent は content exclusions を考慮せず、対象ファイルを見たり更新したりできると説明されています。機密情報をリポジトリ内に置かない、Secrets は GitHub の Agents secrets/variables で管理する、レビュー時に差分だけでなく参照可能なファイル範囲も意識する、といった運用が必要です。(GitHub Docs)
また、Copilot cloud agent は GitHub Actions によって動く一時的な開発環境を使います。利用にあたっては GitHub Actions minutes と AI credits を消費するため、組織で利用量を可視化し、コスト管理の対象に含めるべきです。(GitHub Docs)
移行期限はあるのか
今回の Microsoft Learn ページには、移行期限、廃止予定日、強制切り替え日といった記載は確認できません。したがって、既存環境に対して即時対応が必要な「期限付き移行」と見るより、Copilot cloud agent に Azure 文脈を与えるための新しい導入手順として捉えるのが適切です。(Microsoft Learn)
一方で、GitHub Docs では、以前 Copilot cloud agent settings 配下で管理されていた既存のリポジトリ MCP configurations は、新しい共有 MCP settings ページに自動移動されており、移行作業は不要と説明されています。既存利用者は、移行作業そのものよりも、移動後の設定内容が Copilot cloud agent と Copilot code review の両方に影響する点を確認すべきです。(GitHub Docs)
グローバル環境での管理ポイント
グローバル企業や複数拠点で Azure を使っている場合は、単一リポジトリの設定だけで判断しない方が安全です。
| 観点 | 確認内容 |
|---|---|
| テナント | 対象 Azure テナントを明確にし、誤ったテナントで認証しない |
| サブスクリプション | 開発・検証・本番を分け、Copilot 用 ID の権限スコープを限定する |
| リージョン | azd coding-agent config で選ぶ location と resource group を対象アプリに合わせる |
| GitHub Organization | Copilot cloud agent の利用ポリシー、Actions、MCP server 設定権限を確認する |
| レビュー体制 | Azure 管理者、アプリ担当、セキュリティ担当の承認条件を決める |
| 監査 | Pull Request、Actions ログ、Azure Activity Log、GitHub 監査ログを確認できるようにする |
| コスト | GitHub Actions minutes、AI credits、Azure 側の実行コストを定期確認する |
最初から全社展開するのではなく、開発用サブスクリプションと限定されたリポジトリで試し、成功パターンをテンプレート化してから拡大するのが現実的です。
管理者向けチェックリスト
導入前に、次の項目を確認しておきましょう。
- 対象リポジトリは GitHub 上にあり、Azure IaC ファイルを管理している
- GitHub Copilot cloud agent を組織またはリポジトリで利用できる
- Azure サブスクリプション、テナント、リソースグループが明確になっている
azd coding-agent configを実行する担当者と権限が決まっている- Copilot 用のユーザー割り当てマネージド ID を新規作成するか既存利用するか決まっている
- 既定の
Readerから権限を広げる必要性を説明できる - 生成された GitHub Actions ワークフローをレビューする担当者がいる
- MCP configuration の
toolsをどこまで許可するか決まっている - Copilot に依頼してよい Issue の基準がある
- Pull Request のレビュー、CI、マージ条件が整っている
- 本番環境への直接変更を避ける運用になっている
- GitHub Actions minutes と AI credits の利用状況を確認できる
まず取るべき次の行動
Azure MCP Server と GitHub Copilot cloud agent の連携は、Azure 開発の自動化を一歩進める機能です。ただし、便利さの中心にあるのは「Copilot が Azure の文脈を理解できること」であり、「人間の承認なしに本番作業を任せること」ではありません。
最初に行うべきことは、対象リポジトリを1つ選び、開発用 Azure サブスクリプションで Reader 権限のまま検証することです。Issue から Pull Request が作られる流れ、Azure MCP Server がどの情報を参照するか、レビュー担当者が差分を判断できるかを確認します。その後、必要に応じて MCP tools の範囲や Azure RBAC を調整し、チーム標準の運用手順として展開するのが安全です。
コメント