--- title: "Azure Log Analyticsとは？ワークスペース設計・KQL検索・テーブルプラン別の保存コストを実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/17259/" published: 2026-09-03 updated: 2026-09-27 categories: ["Azure"] publisher: "株式会社一創" --- # 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実装](https://www.issoh.co.jp/tech/details/15703/)で整理しました。 ### Azure MonitorとApplication Insightsとの役割分担 Log Analyticsは単独の製品というより、Azure Monitorという傘の下にあるログ担当です。Azure Monitorはメトリクス・ログ・トレースをまとめて扱う監視プラットフォームで、そのうち時系列の数値はMetrics、テキストや構造化された記録はLogs、つまりLog Analyticsワークスペースへ入ります。傘全体の構成と料金体系は[Azure Monitorとは？監視の仕組み・Log AnalyticsとApplication Insightsの関係・料金モデルとDatadogとの違い](https://www.issoh.co.jp/tech/details/15645/)で解説しました。 アプリケーション性能監視を担うApplication Insightsも、ワークスペースベースのリソースならデータの実体はLog Analyticsワークスペースに置かれます。APMのテレメトリも同じ課金・同じKQLの土俵に載るわけです。APM側の設定は[Application Insightsとは？機能・料金・導入手順とLog Analyticsとの違い](https://www.issoh.co.jp/tech/details/7169/)を参照してください。 ## ワークスペース設計：単一に集約するか分割するかを決める判断軸 すべてのデータ収集を1つのワークスペースで賄うことはできますし、Microsoftも出発点としては単一ワークスペースを想定しています。それでも分割が要る場面はあり、ワークスペース間でデータを移す仕組みがない以上、ここを取り違えると後戻りが高くつきます。 ### リージョンとデータ所在・課金分離でワークスペースを分ける条件 分割の理由になるのは、法規制やコンプライアンス上のデータ所在要件、部門やプロジェクト単位での課金分離、障害の影響範囲を切る回復性の3つです。単に環境が違うという理由だけで本番と検証を割ると、コミットメントレベルの割引に届かず割高になることがあります。取り込み元のAzureリソースと同じリージョンに置くのも基本でしょう。 | 観点 | 単一に集約 | 分割する | | ------ | ---------------- | --------------- | | コスト | コミットメント割引に届きやすい | 量が割れて従量課金のまま | | データ所在 | 1リージョンに収まる場合 | 国や地域の保存要件がある | | 課金 | 部門按分が要る | 請求単位をそのまま分けられる | | 権限 | テーブル単位の制御で対応 | 境界を物理的に切りたい | | セキュリティ | Sentinel課金が全体に及ぶ | 運用ログとセキュリティ系を分離 | 最後の行は見落としがちな地雷です。ワークスペースでMicrosoft Sentinelを有効にすると、そこに集まる全データにSentinelの料金がかかります。運用ログとセキュリティログを分けるのは、この課金の巻き込みを避けるためです。ただし双方とも単独ではコミットメントレベルに届かない規模なら、まとめたほうが安く収まる場合もあります。SIEM側の設計は[Microsoft Sentinelとは？クラウドネイティブSIEM/SOARの仕組み・料金モデル・Defenderポータル統合](https://www.issoh.co.jp/tech/details/15647/)で整理しました。 ### アクセス制御モードとロール設計でテーブル単位の権限を絞り込む ワークスペースを分けずに境界を作りたいときは、アクセス制御モードが効きます。ワークスペースコンテキストは権限を持つ人が全データを見るモード、リソースコンテキストはその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との違い）](https://www.issoh.co.jp/tech/details/15521/)やEvent Hubsを指定でき、料金はエクスポートしたデータ量に基づきます。同じ発想はサードパーティでも共通なので、比較の際は[Datadogログ収集の3経路とパイプライン設計：インデックス制御で保管費を抑える実装手順](https://www.issoh.co.jp/tech/details/16595/)も参考になります。 長期保有から取り出すときは検索ジョブを実行します。課金はスキャンしたGB単位で、Analyticsログなら長期保有期間にスキャンした分だけ、BasicとAuxiliaryは時間範囲内の全データが対象です。データ復元機能は最小課金が2TBかつ12時間と大きく、単発の調査で気軽に叩くものではありません。 ## 受託開発でLog Analyticsを採る条件と、見送るべき場面の線引き ここまでの仕様を踏まえて、実案件での採否を条件付きに言い切ります。判断を先送りにすると運用開始後にワークスペースを割り直すことになり、そのときにはデータの移行手段がありません。 ### 採用条件：Azure中心の構成でアラートまで一気通貫にしたい 採用してよいのは次の条件がそろう場合です。第一に、監視対象の中心がAzure上のリソースであること。診断設定を有効にするだけでログが流れ込み、エージェントの作り込みがほぼ要りません。第二に、ログを見るだけでなくアラートや自動アクションにつなげたいこと。第三に、Microsoft SentinelやDefender for Cloudを併用する予定があること。これらはワークスペースを前提に組み立てられており、後から別基盤に寄せると二重投資になります。 導入時にまず決めるのは、ワークスペースの数とリージョン、テーブルごとのプラン、保持期間の3点です。ここさえ握れば、あとは運用しながら微調整できます。既存システムの監視設計を見直したい、運用の内製化まで見据えたいという場合は、[保守運用 / 内製化支援](https://www.issoh.co.jp/service/system/maintenance/)で設計から運用移管までを引き受けています。 ### 見送る場面：マルチクラウド前提や長期の生ログを大量保管するとき 逆に、次の場合は主軸に据えないほうが収まります。ひとつは、AWSやGoogle Cloudを含む複数クラウドの監視を1画面に集めたいケースです。各クラウドのマネージドなログ基盤との二重管理になりがちで、統合を売りにするサードパーティ製品のほうが素直でしょう。GCP側の対応物は[Cloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違い](https://www.issoh.co.jp/tech/details/15671/)で整理しました。 もうひとつは、法令対応で生ログを何年も丸ごと保管する要件が主目的のケースです。長期保有は最大12年まで対応するとはいえ、まず取り込み課金を通す必要があります。閲覧頻度がほぼゼロなら、エクスポートでストレージに落として安く寝かせる構成のほうが総額を抑えられます。レガシ価格レベルを引き継いだ場合は打ち手が限られるため、価格レベルの移行を先に検討してください。 ## よくある質問 ### Log AnalyticsとAzure Monitorはどう違いますか？ Azure Monitorはメトリクス・ログ・トレースを扱う監視プラットフォーム全体の名前で、Log Analyticsはそのうちログを格納・検索する部分を指します。データ基盤としての正式な呼び名はAzure Monitor Logsで、その格納先がLog Analyticsワークスペースです。 ### ワークスペースを作るだけで料金は発生しますか？ ワークスペースの作成や維持そのものに直接の料金はかかりません。課金されるのは取り込んだデータ量とその保持で、テーブルごとのプランに応じて単価が決まります。ただし専用クラスターだけは、作成した時点から課金が始まる点が異なります。 ### データの保持期間は最長どれくらい設定できますか？ 対話型データ保持は最大2年、長期保有まで含めた合計では最大12年です。長期保有中のデータは検索ジョブで対話型保持へ取り出して調べます。なおAnalyticsプランには31日間の分析保持が取り込み料金に含まれます。 ### Basicプランに変えればクエリも安くなりますか？ いいえ、逆に増えることがあります。Basicは取り込み単価が下がる代わりに、対話型クエリでスキャンしたGB単位で課金される仕組みです。日次100GBのテーブルで3日分をスキャンすれば300GB分が請求されます。クエリ頻度を測ったうえで判断してください。 ### アラートはどのテーブルプランでも設定できますか？ AnalyticsとBasicでは設定できますが、Auxiliaryのテーブルではアラートが機能しません。すでにアラートを設定しているテーブルをAuxiliaryへ切り替えると、そのアラートは動かなくなります。切り替え前に、対象テーブルを参照するルールを洗い出してください。 ## 関連記事 - [Azure Monitorとは？監視の仕組み・Log AnalyticsとApplication Insightsの関係・料金モデルとDatadogとの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15645/)：Log Analyticsを包む監視プラットフォーム全体の構成。 - [Application Insightsとは？機能・料金・導入手順とLog Analyticsとの違い【2026年版】](https://www.issoh.co.jp/tech/details/7169/)：ワークスペースにテレメトリを格納するAPM側の設定と料金。 - [Microsoft Sentinelとは？クラウドネイティブSIEM/SOARの仕組み・料金モデル・Defenderポータル統合を実装者目線で解説](https://www.issoh.co.jp/tech/details/15647/)：同じワークスペースを土台にするSIEM。課金の巻き込みを避ける設計の参考に。 - [Cloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15671/)：GCP側の対応物。マルチクラウドで比較するときの対照。 - [Datadogログ収集の3経路とパイプライン設計：インデックス制御で保管費を抑える実装手順](https://www.issoh.co.jp/tech/details/16595/)：サードパーティ製品での保管費制御。同じ発想の別実装として。 --- 出典: [Azure Log Analyticsとは？ワークスペース設計・KQL検索・テーブルプラン別の保存コストを実装者目線で解説]()（株式会社一創）