Azure Log Analytics の料金: Azure 監視コストが膨らまないようにする方法

By Mirko Peters · 2026-10-23

Azure Log Analytics の料金を管理し、ワークスペースのテーブルプランを最適化し、取り込みのノイズをフィルタリングして、クラウド監視コストが膨らまないようにする方法を解説します。

Automatically translated with AI from the original post. Read the English original

Azure Log Analytics の料金を管理するには、取り込みデータ量、テーブルのデータプラン、長期保存のコストを理解する必要があります。KQL による早期のデータフィルタリングを実施し、基本ログや補助ログなどの適切な階層プランを選択し、危険な 1 日あたりの収集上限を避けることで、管理者は Azure 監視の請求額が制御不能に膨らむのを防げます。

重要なポイント

• Azure Log Analytics の料金は、主に取り込むデータ量と、そのデータをストレージに保持する期間によって決まります。
• テーブルプランは費用に大きく影響します。基本ログのストレージは分析ログよりも大幅に安くなることがあり、補助ログは大量のアーカイブデータに対して極めて大きな割引を提供します。
• データ収集ルールを使って、ノイズが多く読まれることのないログ行を発生源でフィルタリングすることが、クラウド監視コストを削減するもっとも効果的な方法です。
• 1 日あたりの取り込み上限を厳密に設定すると、日中にすべてのデータ収集が止まり、セキュリティチームや運用チームの監視が意図せず機能しなくなるおそれがあります。
• 対話型の保持期間と長期のコールドストレージを適切にバランスさせることで、高速なクエリ機能に過剰な費用をかけることなく、コンプライアンス要件を満たせます。

Log Analytics の実際のコスト要因

組織がクラウド監視を導入する当初は、ほぼすべての関心が可視性に向けられます。システム同士が確実に通信し、すべてのエラーが記録されているかを確認することが中心です。しかし、月次のクラウド請求書が届くと現実に直面します。Log Analytics の課金は、主に 2 つの消費要素に基づいています。ワークスペースに送信されるデータのギガバイト量と、それらのレコードを対話型クエリで利用できる状態に保つ期間です。

ワークスペースの作成自体は無料なので、それが誤った安心感につながりがちです。チームはログのリポジトリを際限のないデジタルの物置のように扱い、詳細なアプリケーションのデバッグデータ、冗長なハートビート信号、未検証のトレースを 1 つのコンテナにまとめて投入しがちです。特定のテーブルを誰も開かなくても、届いたギガバイトすべてに課金されるため、統制されていないデータ取り込みは、すぐに予算超過につながります。

テーブルプランの選び方: 分析ログ、基本ログ、補助ログ

管理者が行える最も影響の大きい判断のひとつは、個々のテーブルに適切な価格階層のプランを割り当てることです。すべてのログデータに同じレベルのパフォーマンスが必要なわけではなく、Microsoft はこうした運用上のトレードオフを反映した階層型プランを提供しています。

標準の分析ログ階層

標準の分析ログプランは、密に監視し、すぐにクエリを実行する必要があるデータ向けに設計されています。リアルタイムの脅威検出や迅速なトラブルシューティングをサポートします。ただし、もっとも高価な選択肢でもあります。複雑な Kusto Query Language (KQL) ステートメントを、1 秒未満で実行できるようにするため、フルインデックスを維持します。

基本ログと補助ログの階層

何かが故障したときにだけ事後的に確認するデータや、監査目的のみで保持する大量のレコードには、基本ログと補助ログのプランによって大幅なコスト削減が見込めます。標準の分析ログは 1 GB あたり約 2.30 ドルかかることがありますが、基本ログではその価格を大きく下げることができ、補助ログの階層では標準料金のごく一部まで下げられます（最も安い場合、最大 46 倍安くなることもあります）。

問題は運用上の機能差です。低コストのプランは検索が遅く、完全なインデックスがなく、リアルタイムのセキュリティアラートにはまったく適しません。1 つのワークスペース内でこれらのプランを組み合わせると、重要なセキュリティシグナルは高価で高速なテーブルにルーティングし、ノイズの多いコンプライアンスログは安価な補助ストレージに保管できます。

収集時のフィルタリングとデータ収集ルールでコストを大幅に削減する

管理者が犯す最大の間違いは、データがワークスペースに取り込まれた後で整理しようとすることです。ログレコードが保存された時点で、すでにその取り込みに対して料金を支払っています。

適切なアプローチは、Azure Monitor エージェントと組み合わせたデータ収集ルール (DCR) を使うことです。DCR は、仮想マシンやコンテナークラスターに展開される命令セットとして機能します。どのイベントを収集するか、どのように整形するか、どのテーブルに格納するかを正確に定義します。さらに重要なのは、繰り返し発生する不要なノイズを発生源で破棄できる点です。

アプリケーションが、チームが一度もクエリしない情報レベルのログを 1 時間に数千件生成しているなら、入口の段階で破棄してください。ストレージエンジンに届く前にデータを整形およびフィルタリングすることで、使用しないテレメトリに対して課金されることを確実に避けられます。

日次取り込み上限の危険性

予測のつきにくいクラウド請求額に直面し、多くの財務・IT マネージャーは、Azure Log Analytics の日次上限機能を絶対的な安全網とみなしています。日次上限は取り込みデータ量に厳格な制限を設けるもので、しきい値に達すると、その日の残りの時間はワークスペースが新しいレコードを受け付けなくなります。

これは予期しない料金の急増を防ぎますが、Microsoft は日常的なコスト管理のためにこの機能に依存することを明確に警告しています。日次上限に達すると、データ収集は完全に停止します。セキュリティアナリストは可視性を失い、運用チームは状況が見えなくなり、夜間にシステム障害が発生した場合は重要なアラートを見逃します。突然の監視の停止は、クラウド監視の請求額がやや増えることよりも、ほぼ確実に高くつきます。

インタラクティブ保持と長期アーカイブのバランス

コスト管理は取り込みだけでなく、データをどれだけ保持するかにも及びます。既定では、インタラクティブ保持により 31 日間 (Microsoft Sentinel を有効にしている場合は 90 日間) は高速なクエリアクセスが可能です。その期間が過ぎてもデータは消えず、長期ストレージに移行します。

インタラクティブにクエリ可能な状態でデータを保持するコストは、長期ストレージにアーカイブする場合と比べて、ギガバイトあたりの月額が大幅に高くなります。数年間のデータ保持が求められるコンプライアンス要件では、アーカイブストレージはギガバイトあたりわずかな費用で済みます。ただし、アーカイブされたデータの取得には、即時のインタラクティブクエリではなく検索ジョブの実行が必要になるため、事前の戦略が欠かせない点に注意してください。

まとめと次のステップ

Azure Log Analytics の価格を管理することは、意図的なアーキテクチャ設計の実践です。包括的なデータ収集戦略から離れ、テーブルごとのプランを活用し、エッジで厳格なデータ収集ルールを実装することで、クラウド予算を超過させることなく、エンタープライズ級の可視性を維持できます。

これらのシステムの内部動作の基礎をさらに深く理解するには、M365 FM Podcast の エピソード全編を聴いて、ワークスペース、テーブル、KQL クエリの基本について専門用語を使わない解説をぜひご覧ください。

よくある質問

Azure Log Analytics ワークスペースの作成は無料ですか?

はい、ワークスペースの作成に基本料金は発生しません。課金対象は、ワークスペースに取り込まれたデータ量と、そのデータを保存する期間です。

Analytics、Basic、補助ログのプランの違いは何ですか?

Analytics プランは、リアルタイムのセキュリティアラートと高速なインタラクティブクエリに最適化された、高速で完全にインデックス化されたストレージを提供します。Basic プランと補助ログプランは、検索頻度が低いデータや、主にコンプライアンスやアーカイブ目的で保持するデータ向けに、はるかに安価なストレージオプションを提供します。

日次取り込み上限を使うべきでないのはなぜですか?

日次取り込み上限は、支出のしきい値に達すると、データ収集を完全に停止します。これにより、その日の残りの時間はセキュリティおよび監視システムが見えなくなり、システム障害やセキュリティ侵害の際に受け入れがたいリスクを生じさせます。

Log Analytics のデータ取り込みコストを削減するには、どうすればよいですか?

コストを最も効果的に削減する方法は、Data Collection Rules (DCR) を使ってソースの段階で不要なログデータを除外することです。これにより、読まれることのないノイズの多いデバッグログが、課金対象のワークスペースに到達する前に破棄されます。