Azure Monitorのログ調査やメトリック確認、Azure Workbooksの管理を、IDE上の自然言語プロンプトから実行したいと考える管理者は少なくありません。一方で、「AIエージェントに本番Azureを操作させてもよいのか」「既存環境の設定変更や移行が必要なのか」と不安を感じる場面もあります。
結論からいうと、「Azure MCP Server Tools for Azure Monitor and Workbooks」は、Azure MonitorやWorkbooksを置き換えるサービスではありません。Azure MCP Serverを介して、Log Analyticsの検索、メトリック取得、正常性確認、Webテスト、Workbooksの作成・更新・削除などを、MCP対応のIDEやAIツールから実行できるようにする仕組みです。既存リソースが自動的に変更されるわけではなく、公式情報上、強制的な移行期限も示されていません。管理者が優先して確認すべきなのは、RBAC、読み取り専用設定、対象サブスクリプション、書き込み操作の承認ルール、バージョン管理です。(Microsoft Learn)
なお、Microsoft Learnの「Get started with the Azure MCP Server」は2026年6月29日更新です。一方、Azure Monitor／Workbooksの詳細なツールリファレンスは、その後も更新されています。そのため、2026年6月29日を単発の破壊的変更日と捉えるのではなく、Azure MCP Serverの導入方法や対応範囲が整理されたタイミングとして確認し、実際の導入時には最新のツールリファレンスも照合する必要があります。(Microsoft Learn)
Azure の新機能・変更点：「Azure MCP Server Tools for Azure Monitor and Workbooks」で確認すべきポイント
今回の公式情報を管理者向けに整理すると、判断の要点は次のとおりです。
| 確認項目 | 結論 |
|---|---|
| 変更の位置付け | IDEやAIエージェントからAzure Monitor／Workbooksを操作するためのMCPツール群 |
| 主な影響対象 | Azure MCP Serverを有効化する開発者、SRE、運用担当者、クラウド管理者 |
| 既存リソースへの影響 | ツールを導入しただけでは変更されない。書き込みツールを実行した場合のみ変更が発生する |
| 必要な設定 | MCPクライアント設定、Azure認証、RBAC、対象namespace、承認ポリシー |
| 移行期限 | 参照した公式ページには強制移行日や廃止期限の記載なし |
| 推奨する初期構成 | 読み取り専用、対象namespace限定、検証用環境、最小権限 |
| 注意すべき操作 | Webテストの作成・更新、Workbookの作成・更新・削除、ローカルコードの計装 |
Azure MCP Serverは、Azure CLIの既定サブスクリプションや環境変数などから操作対象を解決します。また、読み取り専用モードの初期値は無効で、namespaceを指定しない場合は複数のAzureサービスが公開対象になり得ます。企業環境では、公式サンプルをそのまま利用するのではなく、利用できるツールと操作権限を明示的に絞ることが重要です。(Microsoft Learn)
Azure MCP Server Tools for Azure Monitor and Workbooksとは
Azure MCP Serverは、Model Context Protocolに対応したAIツールとAzureサービスを接続するサーバーです。ユーザーがIDEやチャット画面で指示すると、AIエージェントが必要なAzure MCPツールを選び、Azure APIに対する操作を実行します。
たとえば、次のような指示を自然言語で行えます。
- 指定したLog Analyticsワークスペースから、過去1時間のエラーを検索する
- Application Insightsの失敗リクエスト数を5分間隔で取得する
- 特定リソースのActivity Logから設定変更者を調べる
- Azure Workbooksの一覧を取得し、指定したWorkbookの定義を表示する
- エンドポイント監視用のWebテストを作成する
Azure MCP Serverは、Azureユーザーの資格情報またはマネージドIDを使用し、Azure RBACの範囲内で操作します。MCPを有効化しても、ユーザーがAzure上で持っていない権限を新たに取得できるわけではありません。また、ローカルMCPサーバーは、組織内の承認された開発環境で利用することが前提とされています。(Microsoft Learn)
接続先はVisual Studio Codeだけではありません。公式情報では、Visual Studio、Cursor、Cline、IntelliJ、Windsurf、GitHub Copilot関連ツール、Docker、Python、.NETなどの利用方法が案内されています。(Microsoft Learn)
Azure MonitorとWorkbooksで利用できる主な機能
| 機能領域 | 主な操作 | Azure上の変更 | 活用例 |
|---|---|---|---|
| Activity Log | リソースの操作履歴を取得 | なし | 失敗したデプロイや設定変更者の調査 |
| Log Analytics | ワークスペース、テーブル、ログの検索 | なし | 障害ログやエラー傾向の分析 |
| Metrics | メトリック定義と時系列データの取得 | なし | 応答時間、失敗数、可用性の確認 |
| Health | カスタム正常性モデルの状態取得 | なし | アプリケーション単位の正常性確認 |
| Web Tests | 一覧・詳細取得、作成・更新 | 作成・更新時にあり | 外形監視の設定 |
| Instrumentation | 学習情報の取得、計装作業のオーケストレーション | ローカルコード変更の可能性あり | Application Insightsなどの導入支援 |
| Workbooks | 一覧、詳細、作成、更新、削除 | 作成・更新・削除時にあり | 運用ダッシュボードの管理 |
Activity Log、Log Analytics、Metricsの取得系ツールは読み取り専用です。一方、Webテストの作成・更新や、Workbooksの作成・更新・削除は状態を変更するツールとして定義されています。(Microsoft Learn)
Log Analyticsでは検索前にワークスペースとテーブルを特定できる
Azure MCP Serverでは、いきなりKQLを実行するだけでなく、次の順序で調査できます。
- サブスクリプション内のLog Analyticsワークスペースを一覧表示する
- 対象ワークスペースのテーブルとテーブル種別を確認する
- 対象テーブル、時間範囲、件数上限を指定してKQLを実行する
この流れを使えば、ワークスペース名やテーブル名が曖昧な状態でも、段階的に対象を絞り込めます。ワークスペース全体に対する検索と、特定Azureリソースに関連するログ検索を使い分けられる点も実務上の利点です。(Microsoft Learn)
ただし、本番ワークスペースに対して「エラーを全部調べて」のような広すぎる指示を出すと、不要なデータまで取得される可能性があります。最低でも、サブスクリプション、リソースグループ、ワークスペース、テーブル、時間範囲、最大件数を指定してください。
HealthツールはAzure Resource Healthと同じではない
Azure MonitorのHealthツールが返すのは、Azure Monitor health modelで定義したアプリケーションレベルの正常性です。仮想マシンやApp Serviceなど、Azureリソース自体の可用性を調べるAzure Resource Healthとは用途が異なります。
「仮想マシンがAzure基盤上で利用可能か」を確認したい場合はResource Healthを使用し、「注文サービスを構成する複数コンポーネントが業務上正常か」を確認したい場合はhealth modelを使用します。ここを混同すると、正常性の判断を誤る可能性があります。(Microsoft Learn)
Workbooksは検索から削除まで実行できる
Workbooksツールでは、Azure Resource Graphを利用したメタデータ検索、Workbook定義の取得、作成、更新、削除を実行できます。
一覧取得では、既定でWorkbookの完全な定義であるserializedDataは返されません。まずメタデータのみを取得し、対象を絞ってから詳細を取得することで、応答サイズと情報露出を抑えられます。(Microsoft Learn)
Workbookの削除はソフトデリートとして処理され、公式リファレンスでは90日間保持されると説明されています。Azureポータルのごみ箱から復元できますが、削除中は利用者がダッシュボードを参照できなくなる可能性があります。復元可能だから安全と判断せず、削除前にリソースIDとserializedDataを保存しておくべきです。(Microsoft Learn)
影響範囲はAzure MCP Serverを有効化した利用者と権限に限定される
直接影響を受ける組織・担当者
主な影響対象は次のとおりです。
- Azure MCP ServerをIDEやAIエージェントに登録する開発者
- Azure MonitorやLog Analyticsを利用するSRE、運用担当者
- Azure Workbooksを管理するクラウド運用チーム
- Microsoft Entra IDとAzure RBACを管理するIAM担当者
- AIツールへのデータ送信ルールを管理するセキュリティ担当者
- 開発端末やIDE拡張機能を管理するエンドポイント管理者
Azure MCP Serverを利用しないユーザーや、MCPクライアントを構成していない端末には、今回の情報だけを理由とする設定変更は必要ありません。
また、既存のAzure Monitor、Log Analytics、Application Insights、Workbooksの構成が自動的に書き換えられるわけではありません。変更が発生するのは、必要なRBAC権限を持つIDで、作成・更新・削除などの書き込みツールを実際に実行した場合です。
グローバル環境ではクラウドとテナントを明示する
Azure MCP ServerはAzure Public Cloudに加え、Azure China CloudとAzure US Governmentへの接続設定に対応しています。既定値はAzure Public Cloudであり、ソブリンクラウドでは--cloudオプションやAZURE_CLOUD環境変数などを使用して、認証先を明示します。(GitHub)
グローバル企業では、次の単位で設定を分けると誤操作を防ぎやすくなります。
- Azure Public、Azure China、Azure US Government
- 本番、検証、開発
- 地域別または事業会社別のMicrosoft Entraテナント
- 読み取り用IDと書き込み用ID
- Monitor用MCP構成とWorkbooks更新用MCP構成
特に、複数のテナントやサブスクリプションに同じリソース名が存在する環境では、リソース名だけをプロンプトに書かないことが重要です。
設定変更は必要か
必要な変更は、既存のAzure Monitorリソースではなく、主にMCPクライアントとアクセス制御にあります。
| 対象 | 変更の要否 | 管理者が行うこと |
|---|---|---|
| 既存のAzure Monitor設定 | 原則不要 | 現行の収集設定やアラートを維持する |
| 既存のWorkbooks | 原則不要 | MCPから更新する対象だけ管理ルールを定める |
| IDE／MCPクライアント | 必要 | 拡張機能またはmcp.jsonを構成する |
| Azure認証 | 必要 | 利用ID、テナント、サブスクリプションを確認する |
| Azure RBAC | 環境による | 最小権限でロールを割り当てる |
| 書き込み操作の承認 | 必要 | 実行前確認と恒久許可の禁止範囲を決める |
| バージョン管理 | 必要 | 自動更新の可否と検証手順を決める |
認証先とサブスクリプションを最初に確認する
ローカル環境では、Azure CLI、Azure Developer CLI、Visual Studio、Visual Studio Codeなどの資格情報が自動検出されます。Azure CLIを使用する場合は、導入テストの前に次のコマンドでログイン先を確認します。(Microsoft Learn)
az login --tenant <tenant-id>
az account set --subscription <subscription-id>
az account show --output tableaz account showで、少なくとも次の項目を確認してください。
- アカウント
- テナントID
- サブスクリプション名
- サブスクリプションID
- Azureクラウド環境
複数アカウントでサインインしている端末では、意図しないIDが選択されることがあります。プロンプトにもサブスクリプションID、テナントID、リソースグループを含めると、対象の取り違えを減らせます。
初期導入ではread-onlyとnamespaceを指定する
Visual Studio Codeの公式設定例では、.vscode/mcp.jsonからnpxでAzure MCP Serverを起動します。企業向けの検証では、公式の基本例に読み取り専用とnamespace制限を追加する構成が安全です。
{
"servers": {
"Azure Monitor Read Only": {
"command": "npx",
"args": [
"-y",
"@azure/mcp@latest",
"server",
"start",
"--read-only",
"--namespace",
"monitor",
"--namespace",
"workbooks"
]
}
}
}--read-onlyを指定すると書き込み操作を禁止できます。--namespaceは複数回指定できるため、Azure MonitorのmonitorとAzure Workbooksのworkbooksだけを公開できます。(Microsoft Learn)
公式例で使われる@azure/mcp@latestは、常に最新パッケージを取得する指定です。検証環境では便利ですが、変更管理が必要な本番運用では、組織で検証済みのバージョンを明示し、更新前に回帰テストを実施してください。Visual Studio Code拡張機能を利用する場合も、公式情報では最新のプレビュー版と自動更新が提供されるため、拡張機能の自動更新ポリシーを確認する必要があります。(Microsoft Learn)
読み取り用と書き込み用の構成を分離する
日常的なログ調査と、WorkbookやWebテストの変更を同じMCP構成で実行すると、誤操作時の影響が大きくなります。
次のように分離するのが現実的です。
- 通常利用は
--read-onlyを付けたMonitor／Workbooks参照専用構成 - Workbook更新時だけ、
workbooksnamespaceに限定した書き込み構成 - Webテスト管理時だけ、必要なリソースグループに権限を持つ専用ID
- 本番書き込みは変更申請やプルリクエストと紐付ける
- Workbookの一括削除は通常のチャット操作から除外する
Azure MCP Serverの読み取り専用設定は、RBACとは別の防御層です。RBACが書き込みを許可していてもMCP側で書き込みを止められるため、両方を設定することで誤操作を抑えられます。
Azure RBACは操作内容に合わせて最小化する
Azure MCP Serverは、実行ユーザーまたはマネージドIDに割り当てられたAzure RBACを使用します。管理者権限やContributorを一律に付与する必要はありません。
| 利用目的 | ロール候補 | 管理上の注意 |
|---|---|---|
| ログ、メトリック、Activity Logの参照 | Monitoring Reader、Log Analytics Reader | サブスクリプション全体ではなく、対象リソースやリソースグループに限定する |
| Workbookの一覧・詳細確認 | Workbook Reader | Workbookが参照するデータソース側の読み取り権限も必要 |
| Workbookの作成・更新・削除 | Workbook Contributor | 読み取り専用利用者とはIDまたはグループを分ける |
| Webテストの作成・更新 | Monitoring Contributorまたはカスタムロール | Monitoring Contributorは権限範囲が広いため、適用スコープを絞る |
| KQLによるLog Analytics検索 | Log Analytics Readerなど | ワークスペース単位で割り当てることを検討する |
Monitoring Readerはメトリックやログなどの監視データを読み取れます。Log Analytics Readerは監視データの表示・検索権限を含みます。Workbook ContributorはWorkbookの読み取り、書き込み、削除などを許可します。Monitoring ContributorにはWebテストやWorkbooksを含む広い監視設定権限が含まれるため、安易にサブスクリプションスコープで付与しないでください。(Microsoft Learn)
Workbooksは、Workbookファイル自体を読めるだけでは十分でない場合があります。Workbook内でLog Analytics、Resource Graph、Application Insightsなどを参照している場合、利用者には各データソースへのアクセス権も必要です。(Microsoft Learn)
実務で使えるプロンプト例
自然言語で操作できるからといって、曖昧な指示でよいわけではありません。対象と制約を具体的に書くほど、誤ったツール呼び出しや不要な検索を減らせます。
Log Analyticsの障害調査
テナントID「<tenant-id>」、サブスクリプションID「<subscription-id>」を使用してください。
リソースグループ「rg-prod-monitoring」のLog Analyticsワークスペース
「law-prod-japan」で、テーブル「AppRequests」を対象に、
過去60分のHTTP 5xxを時刻の新しい順で最大100件取得してください。
最初に実行予定のKQL、対象ワークスペース、時間範囲を表示し、
対象が一致していることを確認してから実行してください。メトリックの傾向確認
サブスクリプション「<subscription-id>」のApplication Insights
「appi-orders-prod」について、過去6時間の失敗リクエスト数と例外数を
5分間隔で取得してください。
前の6時間と比較し、増加している時間帯を要約してください。
Azureリソースの変更は行わないでください。Workbooksの棚卸し
リソースグループ「rg-global-monitoring」にあるAzure Workbooksを
summary形式で一覧表示してください。
各Workbookについて、表示名、リソースID、更新日時を表示してください。
この段階ではserializedDataを取得しないでください。Workbook更新前の差分確認
Workbook「<workbook-resource-id>」について、現在のserializedDataを取得し、
追加予定のグラフを反映した更新後JSONとの差分を表示してください。
まだ更新は実行しないでください。
変更対象のWorkbook ID、表示名、追加・削除される要素を確認できる形で示してください。書き込みを依頼するときは、「更新して」だけで終わらせず、対象リソースID、変更内容、実行前確認、バッチ操作の可否を明記することが重要です。
移行期限は設定されているか
2026年6月29日更新の導入情報および確認したAzure Monitor／Workbooksツールの公式リファレンスには、既存のAzure Monitor、Log Analytics、Application Insights、WorkbooksからAzure MCP Serverへ移行しなければならない期限は記載されていません。
Azure MCP Serverは、既存のAzure監視機能に対する新しい操作インターフェースです。Azureポータル、KQL、Azure CLI、PowerShell、REST API、SDKなどの既存運用を直ちに置き換える必要はありません。したがって、期限優先で展開するのではなく、セキュリティと運用品質を確認しながら段階的に導入するのが適切です。(Microsoft Learn)
推奨する導入順序は次のとおりです。
- 検証用サブスクリプションで読み取り専用構成を試す
- Log Analytics、Metrics、Activity Logの取得結果を既存手順と比較する
- 本番環境へ読み取り専用構成を展開する
- 利用状況と誤操作リスクを評価する
- WorkbookやWebテストの書き込み機能を別構成で限定開放する
- バージョン更新とロール変更のレビュー手順を定める
導入時に失敗しやすいポイント
| 失敗例 | 起こり得る問題 | 対策 |
|---|---|---|
| サブスクリプションを書かずに指示する | Azure CLIの既定サブスクリプションが使われる | IDまたは一意な名称を毎回指定する |
| 複数テナントで同じアカウントを使う | 意図しないテナントへ接続する | テナントIDを明示し、az account showで確認する |
| 「本番のエラーを全部調べて」と依頼する | 検索範囲と取得データが過大になる | リソース、テーブル、時間、件数を限定する |
| HealthをResource Healthとして解釈する | アプリ正常性と基盤可用性を取り違える | health modelとResource Healthを使い分ける |
| すべての操作をAlways allowにする | 書き込み操作が継続的に承認される | 読み取りと書き込みで承認ポリシーを分ける |
@latestを本番で無検証利用する | 更新後にツールや応答が変わる可能性がある | 検証済みバージョンを固定する |
| Workbook一覧を常にfullで取得する | serializedDataが大量に返される | 一覧はsummary、詳細は選択した対象だけにする |
| ソフトデリートをバックアップ代わりにする | 復旧までダッシュボードが利用できない | 削除前に定義を保存する |
| 計装作業をメインブランチで直接行う | 意図しないコード変更が混入する | 専用ブランチとコードレビューを使用する |
Azure MCP Serverで発生する401エラーは資格情報やトークン、403エラーはRBAC不足、誤ったテナント、誤ったサブスクリプションなどが主な確認対象です。公式情報でも、テナントとサブスクリプションを明示し、正しいスコープにRBACが割り当てられているか確認する方法が案内されています。(Microsoft Learn)
また、Visual Studio Codeでは、操作を現在のセッションだけ許可する設定、現在のワークスペースで許可する設定、すべてのセッションとワークスペースで許可する設定があります。書き込みツールに対して恒久的な許可を与えると、プロンプトの誤解釈や意図しないツール選択が、そのままAzureリソース変更につながる可能性があります。(Microsoft Learn)
管理者が確認すべきチェックリスト
- [ ] Azure MCP Serverを利用するユーザー、端末、IDEを一覧化した
- [ ] 対象のAzureクラウド、テナント、サブスクリプションを明確にした
- [ ] 読み取り用と書き込み用のIDまたはグループを分離した
- [ ] 初期構成に
--read-onlyを設定した - [ ]
monitorとworkbooks以外のnamespaceを公開していない - [ ] Log AnalyticsとWorkbooksの権限を最小スコープで割り当てた
- [ ] WorkbookとWebテストの変更前承認ルールを定めた
- [ ] 「Always allow」を許可する操作と禁止する操作を定めた
- [ ] プロンプトへ機密情報や不要なログを入力しないルールを定めた
- [ ] 利用するAIクライアントのデータ処理・保持ポリシーを確認した
- [ ]
@latestまたは拡張機能の自動更新を管理している - [ ] Workbook削除前の定義保存と復元手順を確認した
- [ ] 計装機能を専用ブランチで検証する手順を用意した
- [ ] Azure ChinaやAzure US Governmentではクラウド設定を明示した
- [ ] 401、403、タイムアウト発生時の問い合わせ先を決めた
まずは読み取り専用の障害調査から始める
Azure MCP Server Tools for Azure Monitor and Workbooksの価値は、障害調査や運用ダッシュボード管理を、IDE上の自然言語操作へ組み込める点にあります。一方で、自然言語で操作できることと、安全に操作できることは同じではありません。
既存環境の強制移行や一律の設定変更は必要ありません。最初に行うべきなのは、検証環境で--read-onlyとnamespace制限を設定し、Monitoring ReaderやLog Analytics Readerなどの読み取り権限だけで、次の3点を確認することです。
- Log Analyticsの検索結果が既存のKQL実行結果と一致するか
- メトリックとActivity Logの対象リソースを正しく特定できるか
- サブスクリプション、テナント、時間範囲の指定が運用手順として定着するか
読み取り操作が安定してから、WorkbookやWebテストの書き込み機能を別構成で段階的に開放してください。MCPの利便性を最大化する鍵は、広い権限を与えることではなく、利用目的ごとにツール、ID、スコープ、承認方法を分けることです。
コメント