公開2026.09.03更新2026.09.27 Azure

Azure Log Analyticsとは？ワークスペース設計・KQL検索・テーブルプラン別の保存コストを実装者目線で解説

Azure Log Analyticsは、Azure上のリソースやアプリケーションが吐き出すログを一箇所に集め、KQL（Kusto照会言語）で検索・集計できるようにするAzure Monitorのログ基盤です。VMや各種PaaSの診断ログ、コンテナの標準出力、独自アプリのログまでが同じワークスペースに流れ込みます。この記事では、Azure Monitorとの関係、ワークスペースを分けるか集約するかの判断軸、Analytics／Basic／Auxiliaryというテーブルプランごとの課金と機能差、KQLで使い回せるクエリの型、保存コストの設計、受託開発での採用条件と見送る場面までを整理します。数値は2026年9月時点のMicrosoft Learn記載に基づくものです。

まとめ：Log Analyticsの本質とコスト設計の物差し

Log Analyticsの実体は、ログの入れ物であるワークスペースと、その中でテーブルごとに設定するプランの二層構造です。ワークスペースはリージョンとアクセス権と課金の単位、テーブルプランは取り込み単価・クエリ課金・使える機能を決めるつまみになります。この二層を分けて捉えると、どの設定が費用と使い勝手のどちらに効くのかが見通せるでしょう。

費用のほとんどは取り込み量で決まります。保持を延ばす費用より何を入れるかのほうが桁で効くため、ノイズの多いログはデータ収集ルール（DCR）の変換で入口から落とすのが定石です。

採否の物差しは単純です。Azure上でシステムを動かしアラートやSentinelと連携させるなら、集約先はLog Analyticsが既定の答えになります。生ログを何年も安く抱えたい、複数クラウドの監視を1画面に集めたいといった要件は、別の受け皿を併用する前提で設計しましょう。

Azure Log Analyticsとは：Azure Monitorのログ基盤

Log Analyticsという言葉は、実務で二つの意味に使われます。ひとつはログの保管庫である「Log Analyticsワークスペース」、もうひとつはそのデータへKQLで問い合わせるポータル上の画面です。公式ドキュメントではデータ基盤としての名称が「Azure Monitor Logs」に整理され、その格納先がワークスペースという位置づけになりました。呼び分けが曖昧なまま設計に入ると料金の話と画面操作の話が混ざります。

ワークスペースとテーブル：ログデータが格納される器と最小単位

ワークスペースは、Azure・オンプレミス・他クラウドを問わずあらゆる種類のログを受け止めるデータストアです。中身はテーブルの集まりで、Azure環境から収集したデータについては必要なテーブルが自動で作られます。独自アプリのログは、カスタムテーブルを作って受け止める形です。

テーブルは単なる置き場ではなく、管理の単位でもあります。テーブルごとにアクセス制御・保持期間・プランを設定でき、この粒度があるから「監査ログだけ長く持つ」「デバッグログだけ安いプランに置く」という切り分けが成立します。取り込む前のログをJSONで構造化しておくと後段の検索も課金の絞り込みも楽になり、その作り方は構造化ログとは｜JSONでログを機械可読にする仕組みとslog/structlog実装で整理しました。

Azure MonitorとApplication Insightsとの役割分担

Log Analyticsは単独の製品というより、Azure Monitorという傘の下にあるログ担当です。Azure Monitorはメトリクス・ログ・トレースをまとめて扱う監視プラットフォームで、そのうち時系列の数値はMetrics、テキストや構造化された記録はLogs、つまりLog Analyticsワークスペースへ入ります。傘全体の構成と料金体系はAzure Monitorとは？監視の仕組み・Log AnalyticsとApplication Insightsの関係・料金モデルとDatadogとの違いで解説しました。

アプリケーション性能監視を担うApplication Insightsも、ワークスペースベースのリソースならデータの実体はLog Analyticsワークスペースに置かれます。APMのテレメトリも同じ課金・同じKQLの土俵に載るわけです。APM側の設定はApplication Insightsとは？機能・料金・導入手順とLog Analyticsとの違いを参照してください。

ワークスペース設計：単一に集約するか分割するかを決める判断軸

すべてのデータ収集を1つのワークスペースで賄うことはできますし、Microsoftも出発点としては単一ワークスペースを想定しています。それでも分割が要る場面はあり、ワークスペース間でデータを移す仕組みがない以上、ここを取り違えると後戻りが高くつきます。

リージョンとデータ所在・課金分離でワークスペースを分ける条件

分割の理由になるのは、法規制やコンプライアンス上のデータ所在要件、部門やプロジェクト単位での課金分離、障害の影響範囲を切る回復性の3つです。単に環境が違うという理由だけで本番と検証を割ると、コミットメントレベルの割引に届かず割高になることがあります。取り込み元のAzureリソースと同じリージョンに置くのも基本でしょう。

観点	単一に集約	分割する
コスト	コミットメント割引に届きやすい	量が割れて従量課金のまま
データ所在	1リージョンに収まる場合	国や地域の保存要件がある
課金	部門按分が要る	請求単位をそのまま分けられる
権限	テーブル単位の制御で対応	境界を物理的に切りたい
セキュリティ	Sentinel課金が全体に及ぶ	運用ログとセキュリティ系を分離

最後の行は見落としがちな地雷です。ワークスペースでMicrosoft Sentinelを有効にすると、そこに集まる全データにSentinelの料金がかかります。運用ログとセキュリティログを分けるのは、この課金の巻き込みを避けるためです。ただし双方とも単独ではコミットメントレベルに届かない規模なら、まとめたほうが安く収まる場合もあります。SIEM側の設計はMicrosoft Sentinelとは？クラウドネイティブSIEM/SOARの仕組み・料金モデル・Defenderポータル統合で整理しました。

アクセス制御モードとロール設計でテーブル単位の権限を絞り込む

ワークスペースを分けずに境界を作りたいときは、アクセス制御モードが効きます。ワークスペースコンテキストは権限を持つ人が全データを見るモード、リソースコンテキストはそのAzureリソースに権限を持つ人が自分のログだけ見るモードです。開発チームごとにサブスクリプションが分かれている構成なら、後者を選ぶだけで多くの分離要件が片づき、さらに細かい制御はテーブル単位のアクセス制御で重ねられます。

テーブルプランの選び分け：Analytics・Basic・Auxiliaryの違い

2026年9月時点のLog Analyticsには、テーブルごとに設定する3つのプランがあります。Analyticsは高性能な分析向け、Basicはアクセス頻度の低いデータの低コスト保管向け、Auxiliary（公式日本語では「補助 / Lake」）は大量で冗長なデータの長期保管向けという住み分けです。プランはテーブル単位の設定なので、1つのワークスペースに3種類を混在させられます。選び分けの軸は取り込み単価だけでなく、クエリしたときに課金されるかどうか。ここを見落とすと、安いプランに置いたのに調査のたび費用が積み上がる逆転が起きます。

3つのテーブルプランの単価・クエリ課金・機能制限を並べて比べる

項目	Analytics	Basic	Auxiliary
取り込み	GB課金・31日保持込み	割安な定額GB課金	最安の定額GB課金
課金サイズ	列エントリの文字列形式	列エントリの文字列形式	非圧縮サイズ
対話型クエリ	スキャン課金なし	スキャンGBごとに課金	スキャンGBごとに課金
クエリ時間範囲	対話型保持の全期間	過去30日まで	合計保持期間まで
アラート	使える	使える	使えない
可視化	ダッシュボード可	ブック・Grafanaのみ	ブック・Grafanaのみ
対象テーブル	すべて	DCRベース＋一部Azure	DCRベースのカスタム中心

Analyticsは取り込み課金に31日間の分析保持が含まれるため、日常的に検索・アラートするログはここに置くのが基本です。Basicは「めったに見ないが、見るときは直近30日以内」というログ向け。Auxiliaryは大量で冗長なログを貯める枠で、アラートが動かない点を承知のうえで使います。組み込みのAzureテーブルは既定でAnalyticsに設定されており、変更可否はテーブルごとに異なります。レガシ価格レベルでは、そもそもBasic・Auxiliaryを使えません。

テーブルプランを変更するときの制約とデータ継続性での落とし穴

プラン変更は1テーブルにつき1週間に1回までなので、試行錯誤しながら切り替える進め方はできません。日次取り込み量とクエリ頻度を先に測ってから動かします。

また、変更しても取り込み済みのデータは移動も削除もされず、変わるのは変更後に取り込まれるデータの扱いだけです。AnalyticsからAuxiliaryへ切り替えたテーブルでは、切り替え日をまたぐ対話型クエリが部分的な結果しか返さないことがあります。逆に戻した場合、変更前のデータは検索ジョブか検索APIで取りに行くことになるでしょう。AnalyticsからBasicへ移すと30日を超えるデータが長期保有扱いになり、リソースクエリスコープを使うサマリールールも動作しなくなります。

KQLでのログ検索：実装で使い回せる基本の型とクエリの組み立て

Log Analyticsの検索言語はKQL（Kusto Query Language）です。SQLに似た読み心地ですが、テーブル名を先に書いてパイプでつないでいく流れが特徴でしょう。

まず覚える5つの演算子：where・summarize・project他

AppTraces
| where TimeGenerated between (ago(24h) .. now())
| where SeverityLevel >= 3
| project TimeGenerated, Message, OperationId
| summarize ErrorCount = count() by bin(TimeGenerated, 1h)
| order by TimeGenerated asc

骨格はこの形で足ります。whereは行の絞り込み、projectは列の選択、summarizeは集計、order byは並べ替え、takeは件数の打ち切りに使います。集計時のbinは時間を一定幅に丸める関数で、時間帯別の傾向を見るときに常用するものです。よく使うクエリは関数として保存でき、Analyticsテーブルならユーザー定義関数も再利用できます。

時間範囲とクエリスコープ：検索の速さとコストを左右する指定方法

KQLでは時間範囲の指定が性能とコストの両方を握ります。画面上部の時間範囲ピッカーとクエリ内のTimeGenerated条件は、積集合ではなく和集合として解釈される点に注意してください。ピッカーで24時間を選びながらクエリで30日を指定すると、意図せず広い範囲を舐めることになります。BasicとAuxiliaryではスキャン量がそのまま請求に乗るため、この取り違えは金額へ直結するでしょう。

スコープも設計事項です。ワークスペースをスコープにすればその中の全テーブルが対象になり、特定のAzureリソースをスコープにすればそのリソースが書いたログだけが見えます。BasicとAuxiliaryではワークスペーススコープしか使えず、同時実行もユーザーあたり2クエリまでです。

BasicとAuxiliaryでのKQL制限：joinとunionが効かない範囲

BasicとAuxiliaryのテーブルへのクエリは、単一テーブルに限定されます。スカラー関数と集計関数はすべて使えるものの、複数テーブルを結合する系の演算子には次の制限がかかります。

演算子・機能	Basic・Auxiliaryでの可否
join / find / search	サポートされない
externaldata	サポートされない
lookup / union	分析テーブル5つまで
ユーザー定義関数	サポートされない
クロスワークスペース	サポートされない
Power BIからの参照	アクセスできない
個人データの消去	実行できない

この一覧を先に見ておくと、プラン選定の判断が変わることがあります。マスターデータと突き合わせる調査が前提のログは、量が多くてもAnalyticsに置いたほうが総額で有利になる場合があるからです。

保持期間と保存コスト：取り込み・対話型保持・長期保有の設計軸

Log Analyticsのデータは、対話型データ保持と長期保有という2つの状態を持ちます。対話型保持の間はクエリ・可視化・アラートに使え、その期間を過ぎると割安な長期保有に移る流れです。対話型保持は最大2年、長期保有まで含めた合計では最大12年まで持てます。

課金の起点は取り込み量：除外される列と無料テーブルを押さえる

課金はGB単位の取り込み量が起点になります。押さえておきたいのは、請求対象のサイズが実際に送ったJSONより小さいことです。AnalyticsとBasicでは平均して約25%小さく、小さなイベントでは最大50%の差が出るとされています。Auxiliaryだけは非圧縮サイズでの計算になるため、同じ考え方を当てはめないよう気をつけてください。

サイズ計算から外れる標準列も決まっています。_ResourceId、_SubscriptionId、_ItemId、_IsBillable、_BilledSize、_TenantId、Typeの7つがそれで、これ以外の列はすべて計算に含まれるという整理。さらにAzureActivity・Heartbeat・Usage・Operationといったテーブルは取り込み料金がかからず、_IsBillable列を見ればレコード単位で課金対象かを判別できます。

逆に、意図せず課金される落とし穴もあります。送信先テーブルのスキーマと一致しない列を送ると、格納されないにもかかわらず課金されるのです。データ収集ルールと宛先テーブルのスキーマが揃っているかは設計時に必ず突き合わせてください。

コミットメントレベルと専用クラスターで取り込み単価を下げる条件

従量課金のほかに、取り込み量を先に確約して単価を下げるコミットメントレベルがあります。100GB/日から選べて、従量課金と比べて最大30%の節約です。確約量を超えた分は同じレベルのGB単価で請求されるので超過に罰則はありませんが、確約量に届かない日があっても確約分は請求されます。

運用上の縛りは、選択または変更した時点から31日のコミットメント期間が始まることです。期間中により高いレベルへ変更すると31日が再スタートし、期間が終わるまで低いレベルへは戻せません。設定直後6時間以内なら引き下げは可能。この割引はAnalyticsログの取り込みだけに適用され、BasicとAuxiliaryは定額のGB課金のままです。専用クラスターは最低100GB/日からで、作成した時点から課金が始まります。

DCRの変換で入口を絞る：取り込む前に落とすというコスト圧縮策

コストを下げる打ち手として最も効くのは、取り込む前に減らすことです。データ収集ルール（DCR）には変換を定義でき、ワークスペースに入る前にフィルタや列の加工をかけられます。ヘルスチェックやデバッグレベルの大量ログを入口で落とすだけで、請求が目に見えて軽くなるでしょう。

長期の生ログを安く抱えたいなら、データエクスポートでストレージへ流す設計も併用しましょう。エクスポート先にはAzure Blob Storage（仕組み・Blobの種類とアクセス層・S3との違い）やEvent Hubsを指定でき、料金はエクスポートしたデータ量に基づきます。同じ発想はサードパーティでも共通なので、比較の際はDatadogログ収集の3経路とパイプライン設計：インデックス制御で保管費を抑える実装手順も参考になります。

長期保有から取り出すときは検索ジョブを実行します。課金はスキャンしたGB単位で、Analyticsログなら長期保有期間にスキャンした分だけ、BasicとAuxiliaryは時間範囲内の全データが対象です。データ復元機能は最小課金が2TBかつ12時間と大きく、単発の調査で気軽に叩くものではありません。

受託開発でLog Analyticsを採る条件と、見送るべき場面の線引き

ここまでの仕様を踏まえて、実案件での採否を条件付きに言い切ります。判断を先送りにすると運用開始後にワークスペースを割り直すことになり、そのときにはデータの移行手段がありません。

採用条件：Azure中心の構成でアラートまで一気通貫にしたい

採用してよいのは次の条件がそろう場合です。第一に、監視対象の中心がAzure上のリソースであること。診断設定を有効にするだけでログが流れ込み、エージェントの作り込みがほぼ要りません。第二に、ログを見るだけでなくアラートや自動アクションにつなげたいこと。第三に、Microsoft SentinelやDefender for Cloudを併用する予定があること。これらはワークスペースを前提に組み立てられており、後から別基盤に寄せると二重投資になります。

導入時にまず決めるのは、ワークスペースの数とリージョン、テーブルごとのプラン、保持期間の3点です。ここさえ握れば、あとは運用しながら微調整できます。既存システムの監視設計を見直したい、運用の内製化まで見据えたいという場合は、保守運用 / 内製化支援で設計から運用移管までを引き受けています。

見送る場面：マルチクラウド前提や長期の生ログを大量保管するとき

逆に、次の場合は主軸に据えないほうが収まります。ひとつは、AWSやGoogle Cloudを含む複数クラウドの監視を1画面に集めたいケースです。各クラウドのマネージドなログ基盤との二重管理になりがちで、統合を売りにするサードパーティ製品のほうが素直でしょう。GCP側の対応物はCloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違いで整理しました。

もうひとつは、法令対応で生ログを何年も丸ごと保管する要件が主目的のケースです。長期保有は最大12年まで対応するとはいえ、まず取り込み課金を通す必要があります。閲覧頻度がほぼゼロなら、エクスポートでストレージに落として安く寝かせる構成のほうが総額を抑えられます。レガシ価格レベルを引き継いだ場合は打ち手が限られるため、価格レベルの移行を先に検討してください。