Azure Monitor取り込み上限の自動スケールがプレビュー：監視欠損と費用を別々に検証する

結論（エンジニアリング判断・要点）

編集上の判断：クラスター増設や時系列増加で取り込み量が変わる環境では、自動スケールを検証する価値があります。採用条件はスイッチが有効であることだけでなく、増加時の欠損検知、変更履歴、手動管理へ戻す手順が確認できることです。

個別環境の設計保証や法的助言は行いません。実装適用には検証環境での事前テストおよび業務範囲の確認が必要です。プレビュー採用、権限付与、アラート対応、費用判断の担当範囲を事前に合意します。

背景と技術的要因（機能拡張の経緯）

確認済み事実：Microsoftの2026年11月11日公式発表は、従来の手動による上限引き上げに代わるオプトインの自動調整を紹介しています。使用量が増えると上限を引き上げ、低い状態が続くと上限を引き下げます。上限変更はActivity Logに記録されます。

確認済み事実：英語版Learnは、Prometheusメトリックが取り込み制限に達するとスロットリングや欠落が起こり得ると説明しています。編集上の判断：自動化の目的を、収集設定やラベルの設計不備を放置する理由とせず、急増原因の調査と並行して扱います。

具体的な日付・数値・対象リソース／APIバージョン

確認済み事実：公式ブログの公表日は2026-11-11、当記事の確認日は2026-11-15です。ブログの別途の更新日、正確な全環境適用日、GA予定日、非推奨化期日は確認できずnullです。日本語版の表示更新日2026-08-13は既存アラート仕様の資料日付であり、新機能の公表日ではありません。

確認済み事実：英語版Learnの有効化例はMicrosoft.Monitor/accounts/<workspace>/metricsContainers/defaultに対するAPIバージョン2026-09-03-previewの更新です。properties.limits.enableAutoScale=trueで有効化し、falseで無効化すると上限は固定され手動管理となります。API名に含まれる日付を機能の適用開始日と読み替えません。

確認済み事実：既定値は毎分イベント数100万、アクティブ時系列100万です。編集上の注意：これは個別環境で現在有効な上限値とは限りません。スケール発動の具体的な使用率、反応時間、上限増加幅は今回の資料では確定できず、未確認として検証対象にします。

アーキテクチャ設計・実装上の確認事項（IaC・設定・依存関係）

確認済み事実：公式例はaz resource update --ids <metricsContainers/defaultのリソースID> --api-version 2026-09-03-preview --set properties.limits.enableAutoScale=true --force-stringです。編集上の提案：対象サブスクリプションとリソースID、実行主体の書き込み権限、変更前後の取得結果を記録してから適用します。

編集上の設計案：IaCでは自動スケールを有効にする意図と、サービスが動的に変える上限値を分けて管理します。使用中プロバイダーが子リソースと設定を扱えるか検証し、再適用による無効化や古い上限値への巻き戻しを試験します。広範囲の差分無視は避け、必要な属性だけを対象にレビューします。

確認済み事実：公式ブログはポータル対応を段階的展開として案内しています。編集上の提案：画面の有無だけで提供状態を断定せず、対象環境でAPIの結果を確認します。新機能の説明がない日本語版は既存アラートの参照に限定し、自動スケールの仕様は英語版Learnと公式発表で補います。

運用・監視・フェイルオーバー・責任分界上の技術論点

確認済み事実：日本語資料の推奨アラートはActiveTimeSeriesPercentUtilizationとEventsPerMinuteIngestedPercentUtilizationを使用し、既定しきい値75%・95%、30分集計、5分評価の例を示します。編集上の判断：上限が変われば使用率の分母も変わるため、比率の低下だけを収集正常化の証拠にしません。

編集上の提案：上限と使用量、収集元の発生量、クエリで確認できるデータ到着、欠落イベント、Activity Logを同じ時間軸で比較します。監視対象が増える試験と、アラート通知が担当者へ届く試験を分け、失敗時に手動引き上げを判断する経路も残します。

確認済み事実：課金は実際の取り込みに基づき、自動スケールはクォータ上限を調整します。編集上の判断：料金体系が変わらないことと総支出が変わらないことは別です。DR先への収集集中や再送で実量が増える場合を試験し、費用承認と監視継続の責任者を決めます。

編集上の提案：復旧先ワークスペースでも設定とアラートを確認し、本番側で有効にした状態が自動的に引き継がれると仮定しません。基盤担当は設定・権限、収集担当は時系列数と収集品質、運用担当は通知と復旧判定、費用担当は実量増加の承認を受け持ちます。