Azure Monitorの「Overview – Azure Monitor」を見てまず押さえるべき点は、Azure Monitor本体の監視機能が大きく変わる告知ではなく、Azure Monitor Logs / Log Analytics Query APIで収集済みログをREST APIから取得するための使い方・認証・実行手段・移行確認ポイントが整理された更新だということです。
特に影響を受けるのは、Log Analyticsワークスペースのデータを、独自アプリ、ダッシュボード、ETL、Power BI連携、運用自動化スクリプト、Azure CLI、Azure PowerShell、SDKから取得している管理者・開発者です。Azureポータルでログを手動確認しているだけの利用者よりも、API経由でKQLクエリを実行している環境を優先して確認してください。
Microsoft Learn上では対象ページの最終更新日が2026年5月14日と表示され、GitHub上の公式ドキュメント履歴でも同日にOverviewの更新コミットが確認できます。日本時間の運用では2026年5月15日更新として扱われるケースもあるため、本稿では2026年5月中旬の公式更新として、実務上の確認ポイントを整理します。(Microsoft Learn)
Azure MonitorのOverviewは何を説明しているのか
今回の対象である「Azure Monitor Log Analytics API overview」は、Azure Monitor logsが収集したデータを、Log Analytics Query APIというREST APIで取得するための概要ページです。APIではAzure Monitor内で使われるKusto Query Language、いわゆるKQLを使ってログを検索でき、取得した結果を可視化、レポート、外部ツール連携、独自アプリケーションに利用できます。(Microsoft Learn)
つまり、このOverviewは「Azure Monitorでログを集める方法」そのものよりも、集めたログをAPIでどう取り出すかを説明するページです。次のような用途が該当します。
- 障害調査用の社内ダッシュボードにLog Analyticsの結果を表示する
- 定期的にKQLを実行し、異常値を別システムへ連携する
- 監査ログやアクティビティログを外部レポート基盤へ取り込む
- 運用スクリプトから特定ワークスペースのログを取得する
- SDKを使ってアプリケーション内からAzure Monitor Logsを検索する
一方で、Log Analyticsワークスペースの作成、診断設定の作成、データ収集ルールの管理、アラートルールの管理は、別のAzure Monitor APIやAzure Resource Manager系APIの領域です。Azure Monitor REST API indexでも、Azure MonitorにはARMベースの管理API、Application Insights API、Azure Monitor Logs APIが分けて整理されています。(Microsoft Learn)
今回の更新で押さえるべき変更点
今回のOverview更新で重要なのは、API仕様そのものの全面変更ではなく、実行方法と関連ドキュメントへの導線が実務向けに整理されたことです。特に、クライアントライブラリだけでなく、Azure CLIとAzure PowerShellからクエリできることがOverview上で明示されました。GitHubの差分では、az monitor log-analytics query と Invoke-AzOperationalInsightsQuery への参照が追加されています。(GitHub)
| 確認ポイント | 内容 | 実務上の意味 |
|---|---|---|
| REST APIの位置づけ | Log AnalyticsワークスペースのログをKQLで取得するAPI | 独自アプリ、監視基盤、レポート連携で使う |
| 認証 | ワークスペースをクエリするにはMicrosoft Entra認証が必要 | APIキー運用ではなく、Entra IDとRBACを前提に設計する |
| 試用方法 | サンプルデータはデモ用APIキーで確認可能 | 本番環境の認証方式と混同しない |
| 実行手段 | REST、SDK、Azure CLI、Azure PowerShellが整理された | 運用チームはCLI/PowerShellで検証しやすくなった |
| 関連ドキュメント | タイムアウト、エラー、移行、制限への導線が整理された | 403、429、504などのトラブル調査がしやすくなった |
Overviewでは、直接REST APIを呼ぶ方法に加えて、.NET、Go、Java、JavaScript、Python向けのAzure Monitor Queryクライアントライブラリも案内されています。さらに、コマンドラインからはAzure CLIのaz monitor log-analytics query、Azure PowerShellのInvoke-AzOperationalInsightsQueryでKQLを実行できることが示されています。(Microsoft Learn)
影響を受ける対象者
今回のOverview更新は、すべてのAzure Monitor利用者に同じ重みで影響するものではありません。優先して確認すべきなのは、Log Analytics Query APIを使っている、または使う予定があるチームです。
| 対象者 | 確認すべきこと |
|---|---|
| Azure管理者 | ワークスペースのIAM、API利用者、サービスプリンシパル、旧エンドポイント利用有無 |
| 開発者 | REST APIのエンドポイント、認証ヘッダー、KQL、レスポンス処理、SDKバージョン |
| SRE・運用担当 | 定期実行スクリプト、監視ダッシュボード、CLI/PowerShellの実行権限 |
| セキュリティ担当 | 監査ログ取得、権限最小化、トークン管理、外部連携先 |
| データ基盤担当 | ETL、Power BI、Data Factory、外部BIツールとの連携方式 |
逆に、Azureポータル上でログを検索するだけの利用者や、Log Analytics APIを使っていない環境では、すぐに設定変更が必要になる可能性は高くありません。ただし、将来的にAPI連携を追加する予定がある場合は、今回整理された認証、エンドポイント、制限、移行方針を設計段階で確認しておくべきです。
APIエンドポイントはapi.loganalytics.azure.comを基準に確認する
Log Analytics APIにクエリを送る場合、公式ドキュメントでは次のパブリックAPIエンドポイント形式が示されています。現在のAPIバージョンはv1です。(Microsoft Learn)
https://api.loganalytics.azure.com/v1/workspaces/{workspaceId}/queryPOSTで実行する場合の基本形は次のとおりです。
POST https://api.loganalytics.azure.com/v1/workspaces/{workspaceId}/query
Authorization: Bearer {token}
Content-Type: application/json
{
"query": "AzureActivity | summarize count() by Category",
"timespan": "PT12H"
}queryは必須です。timespanは任意で、ISO 8601形式の期間、または開始時刻と終了時刻の組み合わせで指定できます。workspacesを使うと、追加のワークスペースを含めたクロスワークスペースクエリも実行できます。(Microsoft Learn)
注意したいのは、古いapi.loganalytics.ioエンドポイントです。公式ドキュメントでは、api.loganalytics.ioはapi.loganalytics.azure.comに置き換えられつつあるものの、当面はサポートされると説明されています。ただし、新規実装ではapi.loganalytics.azure.comを基準にしたほうが、今後の保守がしやすくなります。(Microsoft Learn)
よくある実装ミス
API連携で失敗しやすいのは、KQLそのものよりも、リクエスト形式や認証まわりです。
| ミス | 起きる問題 | 対策 |
|---|---|---|
Content-Type: application/jsonを付け忘れる | POSTで期待した結果が返らない | POSTでは必ずJSON本文とContent-Typeを指定する |
| URLにワークスペース名を入れる | パス不正や権限エラーになる | AzureポータルのWorkspace ID、つまりGUIDを使う |
timespanを指定しない | 想定以上に広い範囲を検索する | 定期実行では必ず期間を明示する |
古いbetaパスを使い続ける | 将来的に動作しない | v1へ変更する |
| トークンのaudienceやresourceが不一致 | 403系エラーになる | エンドポイントとトークン取得設定をセットで確認する |
認証はMicrosoft Entra IDが基本
ワークスペースのデータをクエリするには、Microsoft Entra認証が必要です。Overviewでは、認証フローとしてAuthorization code、Implicit、Client credentialsが示されており、ユーザー操作なしのサーバー間連携ではClient credentials flowを使う選択肢が説明されています。(Microsoft Learn)
本番環境では、単にトークンを取得できればよいわけではありません。アプリ登録、APIアクセス許可、Log Analyticsワークスペース側のIAMロール割り当てをセットで確認する必要があります。公式のアクセス手順では、アプリ登録後にLog Analytics APIのData.Read権限を追加し、さらに対象ワークスペースのAccess control、つまりIAMでアプリにロールを割り当てる流れが説明されています。(Microsoft Learn)
実務では、次の順番で確認すると抜け漏れを減らせます。
| 項目 | 確認内容 |
|---|---|
| テナント | トークンを取得しているMicrosoft Entraテナントが正しいか |
| アプリ登録 | クライアントID、シークレット、証明書、リダイレクトURIが用途に合っているか |
| APIアクセス許可 | Log Analytics APIへの必要な権限が付与されているか |
| ワークスペースIAM | 対象ワークスペースにアプリまたはユーザーのロールが割り当てられているか |
| トークン | Authorization: Bearerヘッダーに正しいトークンを入れているか |
| 権限反映 | ロール付与直後の403を権限不足と即断していないか |
Microsoft Entra認証では、RBAC権限がREST API側で認識されるまで最大60分かかる場合があり、その間は403エラーになることがあります。ロールを追加した直後に失敗した場合は、設定ミスだけでなく権限伝播の時間も考慮してください。(Microsoft Learn)
Azure CLIとAzure PowerShellでの確認がしやすくなった
今回のOverview更新で実務上ありがたいのは、REST APIをいきなり実装しなくても、Azure CLIやAzure PowerShellでクエリ結果を確認できる導線が明確になった点です。
Azure CLIでは、次のようにKQLを実行できます。公式のリクエスト形式ページでは、az monitor log-analytics queryがLog Analyticsワークスペースに対してKQLを実行するコマンドとして示されています。(Microsoft Learn)
workspaceId="myWorkspaceId"
az monitor log-analytics query \
--workspace "$workspaceId" \
--analytics-query "AzureActivity | summarize count() by Category" \
--timespan "PT12H"Azure PowerShellでは、Invoke-AzOperationalInsightsQueryを使えます。
$workspaceId = 'myWorkspaceId'
$queryParams = @{
WorkspaceId = $workspaceId
Query = 'AzureActivity | summarize count() by Category'
Timespan = (New-TimeSpan -Hours 12)
}
$results = Invoke-AzOperationalInsightsQuery @queryParams
$results.Results開発前の検証では、まずCLIまたはPowerShellで同じKQLが成功するかを確認すると、問題を切り分けやすくなります。CLIやPowerShellで成功し、アプリからだけ失敗する場合は、アプリ登録、トークン取得、ヘッダー、JSON本文、SDK設定のどこかに問題がある可能性が高いです。
beta APIとbatch操作の移行を確認する
Azure Monitor Logs query APIでは、beta APIバージョンとbatch query operationの非推奨スケジュールが公式に整理されています。betaバージョンのサポート終了日は2026年3月31日、batch操作のサポート終了日は2028年3月31日です。(Microsoft Learn)
| 対象 | サポート終了日 | 必要な対応 |
|---|---|---|
Logs query API betaバージョン | 2026年3月31日 | APIパスをbetaからv1へ変更する |
Logs query API batch操作 | 2028年3月31日 | requests配列でまとめていたクエリを単一クエリに分割する |
古いコードでは、次のようなパスが残っている可能性があります。
https://api.loganalytics.azure.com/beta/
https://api.loganalytics.io/beta/移行後は、v1のクエリエンドポイントを使います。
https://api.loganalytics.azure.com/v1/workspaces/{workspaceId}/querybatch操作を使っている場合は、1回のリクエスト本文に複数のクエリを入れる設計から、個別のクエリ呼び出しへ分割する必要があります。公式ドキュメントでは、SDKクライアントライブラリでバッチクエリを実行している場合も、対応するメソッドで別々のクエリとして実行するよう案内されています。(Microsoft Learn)
移行時に見落としやすいのは、コード本体ではなく設定ファイルや外部ツール側のURLです。CI/CDの変数、Key Vaultのシークレット、Logic Apps、Data Factory、Power BI、社内ジョブ管理ツール、コンテナ環境変数などに古いURLが残っていないか確認してください。
Query APIの制限を前提に設計する
Log Analytics Query APIは、無制限に大量データを返すためのAPIではありません。Azure Monitorのサービス制限では、Query APIに対して、1回のクエリで返される最大レコード数、データ量、実行時間、リクエストレートの制限が示されています。(Microsoft Learn)
| 制限項目 | 上限 |
|---|---|
| 1回のクエリで返される最大レコード数 | 500,000件 |
| 返却データサイズ | 約104MB、約100MiB |
| 最大クエリ実行時間 | 10分 |
| 最大リクエストレート | 30秒あたり200リクエスト、Microsoft EntraユーザーまたはクライアントIPアドレス単位 |
運用設計では、これらの上限を超えないように、最初からクエリを絞り込むことが重要です。たとえば、日次バッチで全ログを取得するより、where TimeGenerated >= ago(1h)のように時間範囲を限定し、必要な列だけをprojectで選び、集計できるものはAzure Monitor側でsummarizeしてから取得します。
避けたいのは、「APIで全件取得してからアプリ側で絞り込む」設計です。これはレスポンスサイズ、実行時間、スロットリング、コストの面で不利になりやすく、障害時には429や504の原因になります。
タイムアウトとエラーの扱いを事前に決める
クエリの実行時間は、KQLの複雑さ、対象データ量、システム負荷、ワークスペース負荷によって変わります。公式ドキュメントでは、既定のタイムアウトは3分、最大タイムアウトは10分と説明されています。クエリが指定タイムアウトを超えると、504 Gateway Timeoutになる可能性があります。(Microsoft Learn)
REST APIでサーバー側の待機時間を指定する場合は、Preferヘッダーを使います。
POST https://api.loganalytics.azure.com/v1/workspaces/{workspaceId}/query
Authorization: Bearer {token}
Prefer: wait=30
Content-Type: application/json
{
"query": "Heartbeat | count"
}Azure CLIの専用コマンドaz monitor log-analytics queryではカスタムタイムアウトヘッダーを直接扱えないため、Prefer: wait=を指定したい場合はaz restを使う必要があります。Azure PowerShellではInvoke-AzOperationalInsightsQueryの-Waitパラメーターで待機秒数を指定できます。(Microsoft Learn)
エラー対応では、次の切り分けを運用手順に入れておくと復旧が早くなります。
| ステータス・現象 | 主な原因 | 確認ポイント |
|---|---|---|
| 400 | KQLの構文ミス | テーブル名、列名、演算子、余分な空白 |
| 401 | 認証ヘッダーなし | Authorization: Bearer <token>があるか |
| 403 | 権限不足、無効なトークン、audience不一致 | IAM、API権限、トークン取得先、権限伝播 |
| 404 | パス不正 | エンドポイント、v1、Workspace ID、HTTPメソッド |
| 429 | クエリ数や同時実行数の超過 | リトライ間隔、実行頻度、並列数 |
| 504 | クエリ実行時間超過 | KQL最適化、期間短縮、集計、Preferヘッダー |
| 204 | ワークスペースにデータなし | データ収集設定、対象期間、テーブル存在確認 |
| 空の200応答 | POST本文またはContent-Type不足の可能性 | JSON本文とContent-Type: application/json |
公式のタイムアウト・エラーページでは、認証なし、無効なトークン、権限不足、パス不正、Content-Type不足、データなしなどの代表的なケースが整理されています。アプリ側では、エラーメッセージ全文をログに残し、ステータスコードだけで判断しないようにしてください。(Microsoft Learn)
管理者が確認すべき設定
管理者は、まず「誰が、どのワークスペースに、どの権限で、どのエンドポイントからアクセスしているか」を棚卸しします。特に、サービスプリンシパルやマネージドIDを使っている環境では、利用者が人ではないため、放置された権限が残りがちです。
確認すべき項目は次のとおりです。
| 項目 | 確認内容 | 判断基準 |
|---|---|---|
| ワークスペースID | APIで使うWorkspace IDが正しいか | 名前ではなくGUIDを使っている |
| IAMロール | アプリやユーザーに必要な権限だけを付与しているか | Readerなど広すぎる権限は必要性を確認 |
| アプリ登録 | 使われていないクライアントシークレットがないか | 期限切れ、長すぎる有効期限、所有者不明を解消 |
| ネットワーク | APIエンドポイントへの接続が許可されているか | プロキシ、FW、許可リストを確認 |
| 旧URL | betaや古いエンドポイントが残っていないか | コード、環境変数、外部ツールを検索 |
| 監査 | API実行者を追跡できるか | アプリ名、ジョブ名、実行元を記録 |
権限設計では、「とりあえずContributor」ではなく、取得対象と運用責任に応じて最小権限を検討します。公式ドキュメントでも、例ではReaderロールを使いつつ、必要以上の権限が含まれる場合があるため、より細かいロールと権限を作成できると説明されています。(Microsoft Learn)
開発者が確認すべき実装ポイント
開発者は、REST APIを呼ぶ前に、KQL、認証、レスポンス処理、制限対策を分けて確認すると安全です。
まず、KQLはAzureポータルのLog Analyticsで実行して、期待した結果が出ることを確認します。その後、Azure CLIまたはPowerShellで同じKQLを実行します。ここまで成功してからアプリに組み込むと、問題がKQLなのか、API呼び出しなのか、認証なのかを切り分けやすくなります。
実装時のチェックリストは次のとおりです。
| チェック項目 | 実装上のポイント |
|---|---|
| HTTPメソッド | 長いKQLや複雑な条件ではPOSTを基本にする |
| JSON本文 | query、必要に応じてtimespanとworkspacesを入れる |
| ヘッダー | AuthorizationとContent-Typeを必ず指定する |
| レスポンス | tables、columns、rowsの構造で処理する |
| 例外処理 | 400、401、403、429、504を個別に扱う |
| リトライ | 429や一時的な失敗では指数バックオフを検討する |
| ログ | 実行したクエリ名、対象期間、ワークスペース、ステータスを残す |
| セキュリティ | トークン、シークレット、クエリ結果を不用意にログ出力しない |
レスポンスは、テーブル名、列定義、行データを含むJSON構造で返ります。アプリ側で列順に依存した実装にすると、クエリ変更時に壊れやすくなります。可能であれば、KQL側でprojectを使って必要な列と順序を明示し、レスポンス処理も列名ベースで扱う設計にしておくと保守しやすくなります。
展開前に実施したい動作確認
本番展開前には、成功ケースだけでなく、失敗ケースも確認してください。特にAzure Monitor LogsのAPI連携は、平常時には問題なくても、障害調査時に対象期間を広げた瞬間にタイムアウトやサイズ上限にぶつかることがあります。
| テスト | 確認する内容 | |
|---|---|---|
| 最小クエリ | Heartbeat | countなど軽いクエリで疎通を確認 | |
| 代表クエリ | 実運用で使うKQLが想定時間内に返るか確認 | |
| 広い期間 | 期間を広げたときにタイムアウトしないか確認 | |
| 権限不足 | 権限がないワークスペースで403を正しく扱えるか確認 | |
| データなし | 204や空結果を異常扱いしすぎないか確認 | |
| リトライ | 429や一時的な失敗時に過剰再試行しないか確認 | |
| 秘密情報 | トークンやシークレットをログに出していないか確認 | |
| 移行 | beta、batch、旧URLが残っていないか確認 |
実務では、クエリ本文をアプリコードに直書きするより、設定ファイルやQuery Pack、バージョン管理されたKQLファイルとして管理するほうが変更履歴を追いやすくなります。障害対応用のクエリと定期実行用のクエリを分け、定期実行では必ず時間範囲と返却列を絞るのが安全です。
すぐにやるべきこと
今回のAzure MonitorのOverview更新を受けて、管理者と開発者がまず行うべきことは、Log Analytics Query APIを使っている箇所の棚卸しです。特に、次の4点は早めに確認してください。
- APIエンドポイントが
api.loganalytics.azure.comとv1を基準に整理されているか - Microsoft Entra認証、APIアクセス許可、ワークスペースIAMが正しく設定されているか
betaAPIやbatch操作を使っているコード、ツール、設定が残っていないか- クエリ件数、データサイズ、実行時間、リクエストレートの制限を前提に設計しているか
Azure Monitor LogsのREST APIは、ログデータを外部システムや自動化に活用するうえで強力な手段です。ただし、認証、権限、クエリ最適化、制限、移行対応を曖昧にしたまま使うと、403、429、504などのトラブルにつながります。
まずは既存のAPI呼び出しを洗い出し、CLIまたはPowerShellで代表クエリを再現し、古いURLやbetaパスが残っていないか確認してください。そのうえで、本番アプリではPOST、明示的なtimespan、最小権限、エラー別のリトライ制御を標準にすると、Azure Monitor Log Analytics APIを安定して運用できます。
コメント