Azure Monitor Agent 1.46.1：更新後のログ量スパイクを修正、収集品質まで検証する

結論：AMA更新の完了条件を「収集品質の確認」まで広げる

編集上の提案：Windows版AMAの更新計画に、カスタムログ量の比較を追加してください。更新前後の取込量だけでなく、業務側で発生したログ量も比較します。処理件数の増加と収集経路の異常を切り分けるためです。

編集上の反論・留意点：ログ量の増加をすべてAMAの不具合と決め付けることはできません。DCRの重複関連付け、収集対象の追加、アプリの詳細ログ化なども調査対象です。本記事は個別環境でこの不具合が発生していると判断するものではありません。

背景と技術的要因：エージェント変更が可観測性の前提を変える

確認済み事実：公式リリースノートは、Windows 1.46.1でエージェント更新後のカスタムログ取込量が予期せず増加する可能性のある問題を修正したと記載しています。発生環境、再現条件、影響した旧版の全範囲は、この記述からは確認できません。

編集上の分析：監視基盤はアプリの変更がなくても、収集エージェントの更新で挙動が変わり得ます。件数増加は費用だけでなく、検知しきい値や調査時の時系列評価にも影響し得るため、更新を監視経路全体の変更として扱います。

適用期日・数値・対象：開始日と提供完了を区別する

確認済み事実：対象修正はWindows版1.46.1で、ロールアウト開始日は2026年10月2日です。公式資料では、リージョンへの展開に4～6週間かかる場合があると説明しています。本番環境に適用済みかは、各リソースで確認が必要です。

日付の整理：展開開始日＝2026-10-02。資料の更新日＝2026-10-14（日本語ページのupdated_atメタデータ）。公表日＝null。全リージョンの展開完了日＝null。強制適用日＝null。非推奨化期日＝null。確認日＝2026-10-28。日付未確認を期限なしの意味には扱いません。

確認済み事実：資料はAzure VM、VM Scale Sets、Azure Arc対応サーバーの拡張機能を扱います。今回の修正を、Container Insightsのコンテナー版やWindowsクライアントMSIにもそのまま適用できるという説明は確認できません。REST APIバージョン変更の告知として扱うものでもありません。

アーキテクチャ・IaC：宣言値と実際の稼働版を照合する

編集上の提案：VM、VMSS、Arcを分け、リソースID、OS、リージョン、拡張機能の実行版、自動更新設定、DCR関連付け、送信先ワークスペースを一覧化します。Terraform/Bicepの宣言、Policyによる配布、手動変更のどれが設定を管理しているかを明示してください。

確認済み事実：公式の管理手順には、Azure VM向けAzureMonitorWindowsAgent、発行元Microsoft.Azure.Monitor、自動更新を有効化する設定例があります。拡張機能の導入だけではDCRは作成されず、収集にはDCRと関連付けが必要です。

編集上の提案：typeHandlerVersion、enableAutomaticUpgrade、autoUpgradeMinorVersionは、利用中のリソース種別とプロバイダーの仕様で個別に確認します。リリースノートの1.46.1をIaCの指定値として無条件に転記しないでください。planまたはwhat-ifで再作成・意図しない設定上書きがないか検査し、宣言値とは別に実行版を採取します。

• 編集上の提案：WindowsとLinuxの更新リングを分ける
• 編集上の提案：DCR、ID、DNS、プロキシ、Private Linkの変更を同時実施せず、原因を追跡可能にする
• 編集上の提案：共有DCRを変更する場合は、そのDCRに関連する全リソースを影響範囲に含める

運用・監視・DR・責任分界：更新の成功を別経路で確かめる

編集上の提案：比較窓は同じ業務条件で設定し、入力ファイルの増分、取込件数、重複候補、到着遅延、課金対象量、アラートの発火を記録します。単一のHeartbeatだけで正常判定せず、既知の試験イベントが検索・検知・通知まで届くか追跡してください。比較窓と合格値は自社の処理周期に合わせて定義します。

編集上の提案：異常量を止めるため収集を無条件に無効化すると、障害・攻撃の調査証跡を失い得ます。対象ストリームの限定、影響端末の隔離、アプリ側の原本保全を比較し、停止・再開を承認できる責任者を決めます。旧版への復帰が常に可能とは仮定しないでください。

編集上の提案：DR先でも同じ版が利用可能とは仮定せず、復旧先のDCR関連付け、ID、送信先、通信経路を再確認します。サービス側のリリースはMicrosoft、適用範囲と受入判定は基盤担当、入力ログの正しさはアプリ担当、検知確認は監視担当という分担案を、実際の契約・業務範囲に合わせて調整してください。

実装・移行手順：少数端末から監視経路全体を受け入れる

編集上の提案：最初に現行構成と計測値を保存し、対象リージョンで修正版の提供を確認します。次に検証端末で更新し、既知イベントの発生から通知までを通して検査します。異常がなければ業務単位で段階展開し、稼働版と計測結果を記録して完了を判定します。

適用上の前提：個別環境の設計保証や法的助言を行うものではありません。実装適用の前に、検証環境での事前テスト、障害時の承認経路、契約上の業務範囲の確認が必要です。

公式一次情報と未確認事項

確認に使用したのは以下のMicrosoft Learn日本語版です。リリースノートの更新日はページメタデータで確認したもので、10月2日の展開開始日とは区別しています。管理手順ページの資料日付は今回確定していないためnullとしました。

確認できません：全リージョンの提供完了日、当該不具合の全影響版、個別環境の課金影響額。これらを推測して移行期限や節約額として提示しません。