2026年6月16日、Azure Monitorの「Log Analytics Summary Rules experience」が一般提供（GA）になりました。今回の中心は、Summary Rules機能そのものの初回GAではなく、Azure portalからルールを作成・編集・停止・再開し、実行状況を確認できる管理体験の正式提供です。Summary Rules自体は2025年7月にGAが発表されています。少なくとも今回の公式案内には、既存ルールの強制移行や対応期限は示されていません。(Microsoft Azure)
すでにSummary Rulesを利用している管理者は、ポータル上の表示、実行状態、診断設定を確認しましょう。未利用の場合、今回のGAだけで設定や課金が自動的に変わることはありません。ただし、大量ログを使った定期レポートや長期間のダッシュボードが遅い環境では、クエリ性能とコストを改善できる可能性があります。
Azure Monitorの新機能：Log Analytics Summary Rules experienceのGAで変わったこと
Log Analytics Summary Rulesは、大量のログを一定間隔で集計し、その結果を別のカスタムテーブルへ保存する機能です。
2026年6月16日の更新により、この機能をAzure portalから管理する新しい操作画面がGAになりました。
| 操作 | Azure portalでできること | 管理者への影響 |
|---|---|---|
| ルール作成 | KQLの入力・テスト、出力先テーブル、実行間隔を画面上で設定 | REST APIやテンプレートを作成しなくても導入しやすい |
| ルール確認 | ワークスペース内のルールを一覧表示し、条件で絞り込み | 稼働中・停止中のルールを把握しやすい |
| ルール更新 | クエリ、説明、スケジュールなどを編集 | 小規模な変更をポータル上で実施できる |
| 運用操作 | ルールの停止、再開、削除 | 障害対応や一時停止を画面上で行える |
| 実行確認 | 実行結果を確認し、失敗した時間枠を再実行 | 集計漏れの調査と復旧を行いやすい |
公式ドキュメントでは、Azure portalに加えてAzure CLI、PowerShell、REST API、ARMテンプレートによる管理方法も引き続き案内されています。既存の自動化をポータル操作へ置き換える必要はありません。(Microsoft Learn)
Log Analytics Summary Rulesでできること
Summary Rulesを使うと、元のログを保持したまま、レポートやダッシュボードに必要な集計結果だけを別テーブルへ保存できます。
処理の流れは次のとおりです。
- Log Analyticsワークスペース内のログをKQLで検索する
- 設定した間隔ごとに集計処理を実行する
- 集計結果をAnalyticsプランのカスタムテーブルへ保存する
- ダッシュボードやレポートでは集計済みテーブルを参照する
たとえば、アプリケーションのリクエストログが毎時間100万件発生していても、サービス名、結果コード、成功・失敗別の件数に集約すれば、ダッシュボードが検索するレコード数を大幅に減らせます。
AppRequests
| summarize
RequestCount = count(),
AverageDurationMs = avg(DurationMs)
by AppRoleName, ResultCode, Successこのクエリを1時間ごとに実行するSummary Ruleとして登録すると、ダッシュボード側は大量のAppRequestsを毎回検索せず、集計結果のテーブルを参照できます。
Summary Rulesの主な用途は次の3つです。
- 大量ログを使う長期間レポートの高速化
- BasicまたはAuxiliaryプランに元ログを置き、必要な集計結果だけをAnalyticsプランで利用するコスト設計
- ユーザーIDやメッセージ本文などを除外し、詳細情報を含まない集計テーブルを提供するアクセス制御
ただし、Summary Rulesは元ログを削除したり匿名化したりする機能ではありません。集計テーブルから機密項目を除外しても、元のテーブルにデータが残っている限り、元ログ側の権限管理と保持期間の設定は必要です。(Microsoft Learn)
今回の変更で影響を受けるユーザー
| 対象 | 影響度 | 確認すべきこと |
|---|---|---|
| 既存のSummary Rules管理者 | 高 | ポータルにルールが表示されるか、状態や出力先が正しいか |
| IaCやREST APIでルールを管理している担当者 | 中 | ポータル編集による構成差分が発生しない運用になっているか |
| 大量ログのダッシュボード管理者 | 高 | 繰り返し実行している集計クエリをSummary Rulesへ移せるか |
| Basic・Auxiliaryプランの利用者 | 高 | データスキャン料金と集計結果の取り込み料金を試算したか |
| Summary Rulesを使用していない一般ユーザー | 低 | 原則として直ちに行う作業はない |
| セキュリティ・監査担当者 | 中 | 集計テーブルの権限、元ログの権限、保持期間が適切か |
特に確認したいのは、毎回同じ大量ログを集計しているダッシュボードです。月次レポートや長期間の傾向分析など、即時性よりも検索効率が重要な処理はSummary Rulesに向いています。
一方、数分以内の検知が必要なアラートやインシデント対応では、通常のログアラートなどを優先します。Summary Rulesは一定間隔で動くバッチ処理であり、リアルタイム処理ではありません。
Azure portalでSummary Rulesを設定する手順
必要な権限を確認する
ルールの作成や更新には、少なくとも次の操作に対応する権限が必要です。
- Summary Rulesを作成・更新する権限
- 出力先となるカスタムテーブルへの書き込み権限
- 集計対象テーブルを検索する権限
代表的な組み込みロールは「Log Analytics共同作成者」です。ただし、組織独自のカスタムロールを利用している場合は、Microsoft.OperationalInsights/workspaces/summarylogs/writeなどの必要な操作が含まれているか確認してください。(Microsoft Learn)
ルールを作成する
- Azure portalで対象のLog Analyticsワークスペースを開く
- 「設定」から「Summary rules」を選択する
- 「作成」を選択する
- ルール名、説明、出力先テーブルを入力する
- Log AnalyticsのクエリエディターでKQLを作成し、結果をテストする
- 「Run summary every」で集計間隔を設定する
- 内容を確認してルールを作成する
クエリをテストするときは、単にエラーなく動くかだけでなく、次の点も確認します。
- 出力列がダッシュボードやレポートで本当に必要か
- リクエストID、ユーザーID、メッセージ本文など、高カーディナリティーの列を残していないか
- 1レコードが過度に大きくならないか
- 集計前と比べてデータ量を十分に減らせるか
- 利用しているテーブルプランでKQL演算子がサポートされているか
Summary Rule側が実行対象の時間範囲を決めるため、通常はクエリに独自の時間フィルターを追加しません。TimeGenerated > ago(1h)などを固定で記述すると、実行タイミングや遅延によって一部のログを集計できない可能性があります。(Microsoft Learn)
実行ログを有効にする
本番運用では、Log Analyticsワークスペースの診断設定で「Summary Logs」カテゴリを有効にします。
実行情報はLASummaryLogsテーブルへ送信でき、次の状態を確認できます。
- 集計処理の開始
- 正常終了
- 失敗
- 再試行
- 処理時間
失敗を検知するログアラートも設定しておくと、集計テーブルの欠損を早期に発見できます。自動再試行で復旧できなかった時間枠は、Azure portalの実行履歴から再実行できます。(Microsoft Learn)
既存ルールの更新・移行・期限で確認すること
強制移行や対応期限は発表されていない
2026年6月16日の公式更新には、既存ルールの廃止、再作成、移行期限に関する案内は含まれていません。
そのため、現時点で必要なのは新しい方式への強制移行ではなく、Azure portal上で次の情報を確認することです。
- 既存ルールが一覧に表示されているか
- ルールがActiveまたはInactiveのどちらになっているか
- 出力先テーブルが意図したものか
- 集計間隔と開始時刻が正しいか
- 直近の実行に失敗がないか
将来、APIバージョンの廃止や移行期限が発表される可能性はあるため、Azure UpdatesとMicrosoft Learnの変更履歴は継続して確認してください。(Microsoft Azure)
IaC管理ではポータルとの二重編集を避ける
ARMテンプレート、Bicep、TerraformやREST APIを構成管理の正本としている場合、Azure portalから直接変更するとIaCの定義との差分が発生します。
緊急時を除き、次のいずれかに運用を統一するのが安全です。
- ポータルは参照専用とし、変更はIaCから行う
- ポータルで変更した内容を直ちにIaCへ反映する
- 変更履歴と承認手順を用意する
また、ポータルに表示されるdisplayNameと、APIで利用する一意のnameは同じとは限りません。自動化スクリプトを修正するときは、表示名ではなくAPI上の識別子を確認してください。(Microsoft Learn)
クエリ変更後も不要な列が残ることがある
ルールのクエリから列を削除しても、出力先テーブルの既存列が自動的に削除されるとは限りません。
たとえば、当初はUserIdを出力していたものの、後からクエリから除外した場合でも、テーブルスキーマにはUserId列が残る可能性があります。スキーマを整理する必要がある場合は、出力先テーブルの列を別途確認してください。(Microsoft Learn)
停止中の期間は自動的にすべて補完されない
ルールを停止してから再開した場合、通常は次の区切り時刻または設定した開始時刻から処理が再開されます。停止中のすべての時間枠が自動的にバックフィルされるわけではありません。
メンテナンスのために停止するときは、集計結果に空白期間が生じても問題ないかを事前に確認してください。(Microsoft Learn)
Summary Rulesの料金はどう変わるか
Summary Rule自体に追加の利用料金はありません。ただし、検索元のテーブルプランと集計結果の取り込みに応じて料金が発生します。
| 検索元のプラン | クエリに関する料金 | 集計結果の料金 |
|---|---|---|
| Analytics | Summary Ruleによるクエリの追加料金なし | Analyticsログとして取り込み料金が発生 |
| Basic | スキャンしたデータ量に応じた料金が発生 | Analyticsログとして取り込み料金が発生 |
| Auxiliary | スキャンしたデータ量に応じた料金が発生 | Analyticsログとして取り込み料金が発生 |
総コストは、概ね次の要素で考えます。
元ログの取り込み・保持料金 + データスキャン料金 + 集計結果のAnalytics取り込み料金
Summary Rulesを作成しただけで、元ログの取り込み量や保持料金が自動的に減るわけではありません。コスト削減を目的にする場合は、元ログをBasicまたはAuxiliaryプランへ配置できるか、集計後のデータ量をどこまで減らせるかを合わせて検討します。
公式ドキュメントでは、効果を高める目安として、集計結果をソースデータ量の0.01％以下に抑える設計が示されています。ユーザーIDやリクエストIDのように値の種類が多い列をグループ化条件に含めると、レコード数がほとんど減らず、期待した性能改善やコスト削減につながりません。(Microsoft Learn)
運用で失敗しやすいポイント
| 失敗しやすい設定 | 起こり得る問題 | 対策 |
|---|---|---|
| リアルタイム処理として利用する | 集計処理の待ち時間により検知が遅れる | 即時性が必要な処理はログアラートなどを使う |
| クエリに固定の時間条件を入れる | 一部の時間帯が集計対象から外れる | 時間範囲はSummary Ruleの実行間隔に任せる |
| 高カーディナリティー列で集約する | 出力件数が減らず、料金と性能の効果が小さい | サービス名、リージョン、結果コードなどに絞る |
| Basicプランで未対応のKQLを使う | ルール作成時や実行時に失敗する | 対象プランのKQL制限を確認してから登録する |
| 診断設定を有効にしない | 失敗や集計漏れを把握しにくい | 「Summary Logs」を有効化してアラートを設定する |
| ルール停止後の自動補完を期待する | 停止期間の集計結果が欠落する | 停止前に影響を確認し、必要な時間枠は再実行する |
| ポータルとIaCの両方で変更する | 次回デプロイで設定が元に戻る | 構成管理の正本を明確にする |
また、Summary Rulesにはワークスペースごとの有効ルール数、実行時間、クエリ機能などの制限があります。ユーザー定義関数、特定のクロスリソースクエリ、ワークスペース変換との組み合わせなど、サポートされない構成もあるため、本番導入前に対象クエリを実際のテーブルプランで検証してください。(Microsoft Learn)
まず実施すべき確認
今回のGAに対して、Summary Rulesを利用していない環境で急いで設定を変更する必要はありません。
既存利用者は、対象ワークスペースをAzure portalで開き、ルールの状態、出力先、実行間隔、失敗履歴、診断設定を確認します。IaCを利用している場合は、ポータルから不用意に編集せず、構成差分が発生しない運用を決めておきましょう。
新規導入を検討する場合は、まず実行時間が長い定期クエリを1つ選びます。集計後のデータ量と料金を試算し、小規模なルールで実行結果を検証してから、ダッシュボードの参照先を集計テーブルへ切り替えるのが安全です。
コメント