Azure REST APIにobservabilityAgentが追加へ｜2026-05-01-previewの確認ポイント

Azure REST APIでAzure Monitorまわりの仕様を追っている場合、今回のポイントは新しいARMリソースタイプ Microsoft.Monitor/observabilityAgents と、APIバージョン 2026-05-01-preview が追加されようとしていることです。結論から言うと、Azure Monitorの管理API、SDK生成、IaC、カスタムRBACを扱うチームは確認対象です。ただし、対象PRはOpen状態で、ARMレビュー関連のラベルも残っているため、すぐ本番実装へ組み込むというより「影響範囲の棚卸し」と「プレビュー仕様への備え」を先に進めるべき更新です。(GitHub)

特に注意したいのは、PR本文自体にはテンプレート文が残っており、実質的な変更内容はFiles changedのSwagger、TypeSpec、サンプルJSONから読み取る必要がある点です。2026年5月5日のコミットではモデル調整も入っているため、observabilityAgent を使う予定がある場合は、古い差分だけで判断せず、最新のPR状態を確認してください。(GitHub)

Azure REST APIのobservabilityAgent追加で押さえるべき要点

今回のAzure REST API更新は、Azure Monitor配下に「観測・調査系のエージェントリソース」を管理するための新しいControl Plane APIを追加する内容です。対象はデータ投入用のData Plane APIではなく、ARM経由でリソースを作成、取得、更新、削除する管理APIです。

確認項目	内容	実務での見方
新しいリソースタイプ	`Microsoft.Monitor/observabilityAgents`	Azure Monitor配下の新しい管理対象として扱う
APIバージョン	`2026-05-01-preview`	プレビューAPI。固定バージョンで検証し、安定版扱いしない
API種別	ARM / Control Plane	`management.azure.com` 経由の管理APIとして確認する
主な操作	Get、List、CreateOrUpdate、Update、Delete	SDK、IaC、RBAC、自動化スクリプトの影響を確認する
現在の注意点	PRはOpenで、ARMレビュー関連ラベルが残っている	正式な利用可否はマージ状況とMicrosoft公式ドキュメントで再確認する

仕様ファイルでは、Swaggerのタイトルが「Azure Monitor Agents Control Plane API」、バージョンが 2026-05-01-preview とされ、ホストは management.azure.com です。パスには ObservabilityAgents と Operations が含まれています。(GitHub)

何が変わったのか

今回の変更で、Azure REST APIの仕様リポジトリに Microsoft.Monitor/observabilityAgents 向けのSwagger、TypeSpec、サンプルJSON、各言語SDKレビュー対象が追加されています。API Change Checkでは、Swagger、TypeSpec、Go、Python、JavaScript、Java向けのAPIレビューが生成されています。(GitHub)

主なエンドポイントは次の通りです。

操作	HTTPメソッド	パス	用途
サブスクリプション配下の一覧取得	GET	`/subscriptions/{subscriptionId}/providers/Microsoft.Monitor/observabilityAgents`	サブスクリプション全体のエージェント一覧を取得
リソースグループ配下の一覧取得	GET	`/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Monitor/observabilityAgents`	特定リソースグループ内の一覧を取得
単体取得	GET	`/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Monitor/observabilityAgents/{observabilityAgentName}`	指定したエージェントの設定を取得
作成または置換	PUT	同上	エージェントリソースを作成、または全体更新
部分更新	PATCH	同上	タグ、ID、プロパティなどを部分更新
削除	DELETE	同上	エージェントリソースを削除

一覧取得には x-ms-pageable が設定され、nextLink によるページングが想定されています。多数のリソースを扱う運用ツールでは、最初の1ページだけで処理を終えないように実装する必要があります。(GitHub)

observabilityAgentの主要プロパティ

observabilityAgent は、ARMのTracked Resourceとして location や tags を持ち、リソース固有の設定は properties に格納されます。作成例では、ユーザー割り当てマネージドIDとAzure Monitor workspaceのリソースIDが指定されています。(GitHub)

プロパティ	型	確認ポイント
`location`	string	作成時のリージョン指定。サポートリージョンは公開時の公式情報で確認
`tags`	object	環境名、管理部門、コスト配賦など既存のタグ設計に合わせる
`identity`	Managed Identity	サンプルではUser Assigned Identityを使用。権限付与先を明確にする
`properties.monitoringAccountId`	string / ARM ID	Azure Monitor workspaceを指すリソースID
`properties.enabled`	boolean	エージェントを有効化するかどうか
`properties.disableAutonomousOperations`	string array	無効化する自律操作の一覧。現時点のサンプルでは `AutoInvestigate` が示されている
`properties.provisioningState`	string	`Succeeded`、`Failed`、`Canceled`。読み取り専用の状態値として扱う

disableAutonomousOperations は配列として定義されています。過去のレビューコメントではCSV文字列ではなくJSON配列にする指摘があり、その後「string array」に変更された旨がコメントされています。設定ファイルやスクリプトで "AutoInvestigate,OtherValue" のような文字列として扱うと、将来のSDKやポリシー検証で不整合が起きる可能性があります。(GitHub)

影響を受ける可能性が高いチーム

今回のAzure REST API更新は、Azure Portalだけを使っているユーザーよりも、APIやコードでAzure Monitorリソースを管理しているチームへの影響が大きい変更です。

対象者	確認すべきこと
Azure Monitor運用担当	新しい `observabilityAgents` が既存の監視設計、調査フロー、権限設計に関係するか
REST API利用者	`api-version=2026-05-01-preview` を使うコードを分離して検証できるか
SDK利用者	Python、JavaScript、Go、Javaなどの生成SDKに新パッケージや新型が出るか
IaC担当	ARM/Bicep/Terraform/AzAPIで扱えるタイミングと差分管理方法
セキュリティ担当	カスタムロールに `read`、`write`、`delete` 操作を含める必要があるか
SRE/運用自動化担当	Deleteが同期処理として扱われる点、Listがページングされる点への対応

Operations_Listのサンプルでは、Microsoft.Monitor/observabilityAgents/read、write、delete が追加され、いずれも isDataAction: false とされています。これはデータアクセス権限ではなく、管理プレーンの操作権限として扱うべき変更です。(GitHub)

移行や設定確認で見るべきポイント

既存APIからの単純な「移行」というより、新しいリソースタイプを組織の管理ルールへ取り込む準備が重要です。特に、APIバージョン、権限、削除処理、配列プロパティの扱いを先に確認しておくと、正式公開後の手戻りを減らせます。

確認項目	判断基準	失敗しやすいポイント
PRの状態	マージ済みか、ARMレビューが完了しているか	Open PRの差分だけを見て本番コードに組み込む
APIバージョン	`2026-05-01-preview` を明示して検証する	Preview版を暗黙の最新版として扱う
SDK対応	利用言語のSDKレビュー・リリース状況を見る	Swaggerに出た時点でSDKが使えると判断する
RBAC	`read/write/delete` をカスタムロールに追加する必要があるか	管理権限不足で作成・更新・削除だけ失敗する
名前規則	英数字とハイフン中心、先頭・末尾ハイフンを避ける	環境名にアンダースコアを使い、APIで弾かれる
削除処理	Deleteは200または204の同期応答として扱う	LRO前提で `Azure-AsyncOperation` のポーリングを実装する
自律操作の無効化	`disableAutonomousOperations` は配列で扱う	CSV文字列として保存し、SDKや検証で不整合になる
将来値への対応	`AutoInvestigate` 以外が増えても壊れない実装にする	enumを厳密に固定し、未知の値で例外にする

レビュー過程では、Deleteの非同期応答やLROヘッダーに関する指摘がありましたが、最終的には「202とasync responseを削除した」とコメントされ、サンプルでもDeleteの応答は 200 と 204 になっています。削除完了待ちの実装を作る場合は、この仕様変更を見落とさないようにしてください。(GitHub)

REST APIで確認する場合の基本手順

実際に検証する場合は、いきなり作成APIを叩くのではなく、次の順序で進めるのが安全です。

| 手順 | 作業 | 目的 |
| -: | ————————————- | ———————————— |
| 1 | PRがマージ済みか、公式REST APIドキュメントに反映済みか確認 | 仕様差分と実サービスの利用可否を切り分ける |
| 2 | 対象サブスクリプション、リソースグループ、リージョンを決める | 誤った環境への作成を防ぐ |
| 3 | Azure Monitor workspaceのリソースIDを取得 | monitoringAccountId に正しいARM IDを入れる |
| 4 | マネージドIDと権限を確認 | エージェントが必要な操作を実行できるようにする |
| 5 | PUTで作成、GETで確認、PATCHで更新、DELETEで削除を順に検証 | 各操作のレスポンスと状態遷移を確認する |
| 6 | CI/CDやIaCに反映するか判断 | Preview仕様を本番管理に入れる範囲を決める |

検証用のリクエストイメージは次の通りです。実行前に、対象APIが利用可能になっているか、サブスクリプションで対象リソースプロバイダーが使えるかを確認してください。

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Monitor/observabilityAgents/{observabilityAgentName}?api-version=2026-05-01-preview

{
  "location": "eastus",
  "tags": {
    "env": "dev"
  },
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{identityName}": {}
    }
  },
  "properties": {
    "monitoringAccountId": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Monitor/accounts/{monitoringAccountName}",
    "enabled": true,
    "disableAutonomousOperations": []
  }
}

更新時に AutoInvestigate を無効化する場合は、文字列ではなく配列として指定します。

{
  "properties": {
    "enabled": false,
    "disableAutonomousOperations": [
      "AutoInvestigate"
    ]
  }
}

SDKとIaCで気を付けたいこと

API Change Checkでは、Pythonの azure-mgmt-monitoragents、JavaScriptの @azure/arm-monitoragents、Goの sdk/resourcemanager/monitor/armmonitor、Javaの com.azure.resourcemanager:azure-resourcemanager-monitoragents などがレビュー対象として表示されています。これはSDK生成への影響が想定されていることを示しますが、PR段階ではパッケージ名、型名、公開タイミングが確定しているとは限りません。(GitHub)

SDKやIaCで扱う場合は、次の方針が現実的です。

利用方法	推奨対応
REST APIを直接呼ぶ	`api-version` を固定し、Preview用の処理として分離する
SDKを使う	該当言語のSDKリリースノートとAPIレビュー結果を確認してから採用する
ARM/Bicepで使う	リソースタイプが公式に公開され、テンプレート検証が通るか確認する
Terraformで使う	AzureRM Providerの対応を待つか、必要に応じてAzAPI Providerで検証する
社内カスタムツール	未知のプロパティや将来のenum値を無視・保持できる設計にする

プレビューAPIでは、仕様変更が入る可能性があります。特に今回のPRでは、disableAutonomousOperations の型、Deleteの同期・非同期、プロパティ構造などがレビュー過程で調整されています。自動生成コードを早期に取り込む場合は、型変更に追従できるようにCIでSwagger差分やSDK差分を検出する仕組みを入れておくと安全です。(GitHub)

今回の更新を確認するときの実務チェックリスト

次のチェックリストを使うと、運用、開発、セキュリティの観点を漏れなく確認できます。

チェック	確認内容
仕様の確定状況	PRがマージ済みか、Microsoft LearnのREST API Referenceに反映されているか
API利用可否	対象サブスクリプションで `Microsoft.Monitor/observabilityAgents` を作成・取得できるか
権限	カスタムロールに `read`、`write`、`delete` が必要か
ID設計	User Assigned Managed Identityを使う場合、誰が作成・管理するか
監視ワークスペース	`monitoringAccountId` に指定するAzure Monitor workspaceが正しいか
命名規則	`observabilityAgentName` に先頭・末尾ハイフンや記号を入れていないか
削除処理	200/204を正常終了として扱えるか
ページング	List APIで `nextLink` を処理しているか
IaC反映	Preview APIを本番IaCに入れる範囲を決めているか
将来変更	Preview仕様変更時に差分レビューできる運用があるか

よくある疑問

Azure Monitor Agentと同じものですか？

名前は似ていますが、今回のPRで追加されているのは Microsoft.Monitor/observabilityAgents というARMリソースタイプです。既存のAzure Monitor AgentやData Collection Ruleの置き換えと断定する材料は、このPRだけでは不足しています。混同せず、公式ドキュメントで用途が明記されてから設計へ反映するのが安全です。

すぐ本番で使うべきですか？

現時点では慎重に扱うべきです。PRはOpenで、NotReadyForARMReview や ARMModelingReviewRequired などのラベルが残っています。仕様の把握、PoC準備、権限設計の棚卸しには有用ですが、本番導入はマージ状況、公式REST APIドキュメント、SDKリリース、対象リージョンの利用可否を確認してから判断してください。(GitHub)

カスタムRBACには何を追加すればよいですか？

サンプルのOperations_Listでは、Microsoft.Monitor/observabilityAgents/read、Microsoft.Monitor/observabilityAgents/write、Microsoft.Monitor/observabilityAgents/delete が示されています。読み取りだけの監視ダッシュボードなら read、自動作成や設定変更を行うツールなら write、クリーンアップ処理まで行うなら delete が必要になる可能性があります。(GitHub)

もっとも見落としやすい変更点は何ですか？

Deleteの扱いと disableAutonomousOperations の型です。Deleteは最終的なサンプルで同期的な 200 / 204 応答になっており、LROポーリング前提の実装は合わない可能性があります。また、disableAutonomousOperations は配列です。CSV文字列として設定管理していると、SDKやポリシー検証で問題になりやすい部分です。

まず取るべきアクション

今回のAzure REST API更新は、新しいAzure Monitor管理リソースに備えるための早期シグナルとして見るのが適切です。すぐに本番へ組み込むより、まずは次の3つを進めてください。

1つ目は、PRと公式ドキュメントの状態確認です。Open PRの差分だけで「利用可能」と判断せず、マージ、公式REST API Reference、SDKリリースの順に確認します。

2つ目は、社内の影響範囲の棚卸しです。Azure MonitorをREST API、SDK、IaC、カスタムRBACで管理している箇所を洗い出し、Microsoft.Monitor/observabilityAgents が追加された場合にどの権限・スクリプト・検証ルールへ影響するかを整理します。

3つ目は、Preview API向けの実装ルール作りです。api-version を固定する、未知の値に強い実装にする、Listのページングを処理する、Deleteを200/204で扱う、配列プロパティをCSV化しない。この基本を押さえておけば、正式公開後の検証や移行をスムーズに進められます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。