Azure Log Analytics ワークスペース設計の基本！ログ保存期間とコスト最適化の秘訣

1. Azure Log Analytics ワークスペースとは？

1. Azure Log Analytics ワークスペースとは？

Azure Log Analytics（アジュール ログ アナリティクス）ワークスペースとは、Microsoft Azureが提供する運用管理サービスである「Azure Monitor（アジュール モニター）」の中心的なコンポーネントです。簡単に言うと、クラウド上のさまざまな場所から集まってきた「データの貯金箱」のようなものです。

仮想マシンの動作ログ、アプリケーションの実行エラー、ネットワークの通信記録など、膨大なデータを一か所に集約して保存します。集めたデータは「KQL（Kusto Query Language：クスト クエリ ラングエッジ）」という専用の言語を使って、高速に検索したり分析したりすることができます。昔のシステム管理では、サーバーごとにテキストファイルを開いてログを確認していましたが、Log Analyticsを使えば数千台のサーバーログも一瞬で横断検索できるのです。

2. コストが決まる2つの大きな要素

2. コストが決まる2つの大きな要素

Log Analyticsの料金体系を理解することは、コスト削減の第一歩です。主に以下の2つの要素で料金が決まります。これを意識せずに設計すると、月末の請求書を見て驚くことになります。

• データ取り込み料金： ワークスペースにどれだけの量のデータを送信したか（GB単位）。
• データ保持料金（保存期間）： 取り込んだデータを何日間保存し続けるか。

基本的には、31日間（プランによっては30日間）の無料保持期間が設定されていますが、それ以上の期間保存する場合は、1GBあたりの月額費用が発生します。特に「とりあえず全部1年保存する」といった設定は、初心者の方が陥りやすいコスト増の罠です。必要なデータだけを選別して取り込み、適切な期間だけ残すという「断捨離」の考え方が重要になります。

3. ログの保存期間をテーブルごとに最適化する

3. ログの保存期間をテーブルごとに最適化する

以前のAzureでは、ワークスペース全体の保存期間を一括でしか設定できませんでした。しかし現在は、「テーブル（データの種類）ごと」に保存期間をカスタマイズできます。例えば、「セキュリティに関するログは法規制のために1年残すが、動作確認用の細かいログは7日で消す」といった柔軟な設定が可能です。

保存期間には、以下の2つの概念があります。

1. 対話型保持（インアクティブ保持）： すぐに検索できる状態。料金は高め。
2. アーカイブ保持： 検索には時間がかかるが、安価に長期間保存できる状態（最長12年）。

頻繁に見るデータと、滅多に見ないけれど念のため残しておくデータを分けることが、最強のコスト対策になります。ここで、実際にどのようにデータが管理されているか、テーブル構造のイメージをSQL形式で見てみましょう。

-- ワークスペース内の各テーブルの保存設定を確認するイメージ
SELECT 
    TableName, 
    RetentionInDays, 
    IsArchiveEnabled
FROM 
    WorkspaceSettings
WHERE 
    WorkspaceName = 'MyLogAnalyticsWS';

上記のクエリを実行した際の結果イメージは以下の通りです。

TableName          | RetentionInDays | IsArchiveEnabled
-------------------+-----------------+-----------------
SecurityEvent      | 365             | True
Heartbeat          | 30              | False
AppServiceConsole  | 7               | False
Syslog             | 90              | True

4. 低コストな「基本ログ」プランの活用

4. 低コストな「基本ログ」プランの活用

Log Analyticsには「分析ログ」と「基本ログ（ベーシック ログ）」という2種類のプラン（データプラン）があります。全てのデータを高機能な分析ログで取り込む必要はありません。デバッグ用のログなど、複雑な集計分析を必要としない大量のデータには「基本ログ」を指定しましょう。

基本ログは、取り込みコストが非常に安く設定されています。その代わり、検索機能に制限があったり、検索時にも少額の費用が発生したりしますが、トータルのコストを劇的に下げることができます。初心者のうちは、全てのログを「標準（分析）」にしがちですが、ボリュームの多いログを見つけたら「基本」に切り替えられないか検討してみてください。

5. 不要なデータを取り込まないフィルタリング設計

5. 不要なデータを取り込まないフィルタリング設計

「送られてきたものを全て貯める」のではなく、入り口でフィルターをかけることが重要です。Azure Monitor エージェント（AMA）を使用すると、データ収集ルール（DCR）を作成して、必要なログレベル（エラーだけ、警告だけなど）に絞ってワークスペースへ送信できます。

例えば、LinuxのSyslog（シスログ）を取り込む際に、全てのファシリティを取得するのではなく、特定の重要度（Severity）以上に限定する設定を行うだけで、データ量を数分の一に削減できるケースも珍しくありません。以下のC#コードは、ログの重要度を判定して送信するかどうかを制御するロジックの簡易例です。

public void ProcessLog(string message, int severityLevel)
{
    // severityLevelが3（Error）以上の場合のみAzureへ送信する
    if (severityLevel >= 3)
    {
        SendToLogAnalytics(message);
        Console.WriteLine("ログを送信しました。");
    }
    else
    {
        // 2（Information）以下はコスト削減のため無視
        Console.WriteLine("このログはスキップされました。");
    }
}

このプログラムを実行すると、レベルに応じた挙動になります。

severityLevel: 4 -> ログを送信しました。
severityLevel: 1 -> このログはスキップされました。

6. コスト管理ツールで現状を可視化する

6. コスト管理ツールで現状を可視化する

設計した後は、実際にどれくらいコストがかかっているかを定期的に確認する必要があります。Azure portal内の「コストの管理と請求」メニューや、Log Analytics内の「使用量と推定コスト」ダッシュボードを活用しましょう。また、KQLを使って、どのコンピューターやどの種類のログが一番容量を消費しているかを特定するスクリプトも有効です。

特定の期間に急増したデータがないか、想定外のサービスからログが飛んできていないかをチェックすることで、無駄な出費を未然に防ぐことができます。以下のKQL（SQL風のクエリ）は、各テーブルのデータ量を集計する例です。

-- 過去24時間でデータ量が多い順にテーブルを表示
Usage
| where TimeGenerated > ago(24h)
| where IsBillable == true
| summarize TotalGB = sum(Quantity) / 1024 by DataType
| order by TotalGB desc;

実行結果のイメージはこちらです。どのデータにお金がかかっているか一目瞭然ですね。

DataType           | TotalGB
-------------------+---------
AppTraces          | 15.42
SecurityEvent      | 8.15
Perf               | 3.20
ContainerLog       | 1.05

7. ワークスペースの集約と分割の判断基準

7. ワークスペースの集約と分割の判断基準

初心者が迷うのが「ワークスペースを1つにまとめるべきか、分けるべきか」という点です。基本的には、管理の手間を減らすために「可能な限り集約する」のが推奨されます。管理単位を分ける必要があるのは、以下のような特別な理由がある場合のみです。

• アクセス権限を厳格に分けたい： 部署Aの人は部署Bのログを見られてはいけない場合。
• データの保存場所（リージョン）を分けたい： 法律の関係でデータを日本国内に置かなければならない場合。
• コストの請求先を完全に分離したい： プロジェクトごとに予算が厳密に分かれている場合。

無闇にワークスペースを増やすと、複数の場所を検索しなければならず、運用の難易度が上がってしまいます。まずは1つのワークスペースで運用し、必要に応じて「リソース コンテキスト」でのアクセス制御（特定のリソースのログだけを見せる機能）を活用しましょう。

8. アーカイブ機能を活用した長期保存戦略

8. アーカイブ機能を活用した長期保存戦略

コンプライアンスや監査（かんさ）の要件で、数年分のログを保持しなければならない場合もあります。前述した「アーカイブ保持」を活用しましょう。アーカイブされたデータは、通常の検索画面には出てきませんが、必要な時だけ「検索ジョブ」を実行して取り出すことができます。

アーカイブ料金は、通常の保持料金に比べて約90パーセント近く安くなることもあります。例えば、最初の30日間は通常のワークスペースに保存し、その後7年分をアーカイブに送るという設定が最適解となるケースが多いです。以下の設定確認コマンド（CLIイメージ）を見てみましょう。

az monitor log-analytics workspace table update --name SecurityEvent --retention-time 30 --total-retention-time 2555
Updated table: SecurityEvent. Total retention set to 2555 days (7 years).

9. コスト最適化チェックリスト

9. コスト最適化チェックリスト

最後に、設計時に見直すべきポイントを整理します。これらを順番に確認するだけで、Azure初心者の方でもプロに近い設計が可能になります。

• 本当に必要なログだけを取り込んでいるか？（DCRでのフィルタリング）
• 無料期間（31日間）を超えて保存する必要があるデータはどれか？
• 「分析ログ」である必要はあるか？「基本ログ」で代用できないか？
• 長期間保存が必要なものは「アーカイブ」設定になっているか？
• データ量が多い上位3つのテーブルを把握しているか？

Azureのコスト最適化は、一度設定して終わりではありません。システムの稼働状況に合わせて、定期的に設定を見直す「継続的な改善」が、運用の質を高める鍵となります。まずはスモールスタートで、データ量を確認しながら少しずつ調整していきましょう。

まとめ

まとめ

Azure Log Analytics ワークスペースの設計において、最も重要なのは「データのライフサイクル」を正しく理解し、コストと利便性のバランスを最適化することです。クラウド運用では、ログは単なる履歴ではなく、システムの健康状態を把握するための貴重な資産ですが、無計画な蓄積は膨大なコストを招きます。今回の解説を通じて、ログの取り込みから保存、そしてアーカイブまでの流れを整理できたのではないでしょうか。

効率的なログ管理のポイント

まず、データ収集ルール（DCR）を活用して、入り口で不要なデータをカットすることが基本です。すべてのログを「分析ログ」として扱うのではなく、デバッグ情報や頻繁に参照しないデータは「基本ログ」へ振り分けることで、取り込みコストを大幅に抑制できます。また、テーブルごとに保存期間（リテンション）を個別に設定できる機能を駆使し、法的要件があるセキュリティログは長期間、一時的なパフォーマンスログは短期間といった使い分けが効果的です。

さらに、長期保存が必要なデータについては、通常の保持期間が過ぎた後に「アーカイブ保持」へ自動移行させる設定を検討しましょう。これにより、検索の即時性は失われるものの、ストレージコストを極限まで抑えつつ、数年単位の監査対応が可能になります。Azure Portalのコスト管理ツールを定期的にチェックし、どのリソースが容量を消費しているかを可視化する習慣をつけることが、運用の安定化に繋がります。

設計の見直しと今後の展望

ワークスペースの構成については、管理の煩雑さを避けるために原則として集約（統合）を優先し、権限分離やリージョンの制約がある場合にのみ分割を検討するという方針が推奨されます。技術が進歩するにつれ、AIを活用したログ分析や自動アラートの精度も向上していますが、その土台となるのは常に「正しく設計されたワークスペース」です。

初心者のうちは設定項目が多く感じるかもしれませんが、まずは「取り込み量を減らす」「保存期間を最適化する」という二点に集中して取り組んでみてください。これだけで、プロジェクト全体のクラウドコストを劇的に改善できる可能性があります。運用を開始した後も、実際の使用量データに基づいた微調整を繰り返すことで、より強固で効率的な監視基盤を築き上げることができるでしょう。

LogId | Timestamp           | Level   | Message             | ServerName
------+---------------------+---------+---------------------+-----------
101   | 2026-03-31 12:00:01 | Error   | Connection Failed   | WebSrv01
102   | 2026-03-31 12:05:22 | Info    | User Login Success  | WebSrv02
103   | 2026-03-31 12:10:45 | Warning | High CPU Usage      | AppSrv01
104   | 2026-03-31 12:15:30 | Error   | Database Timeout    | DbSrv01

-- エラーログのみを抽出して、特定の列だけを表示する
SELECT 
    Timestamp, 
    Message, 
    ServerName
FROM 
    SystemLogs
WHERE 
    Level = 'Error';

Timestamp           | Message             | ServerName
--------------------+---------------------+-----------
2026-03-31 12:00:01 | Connection Failed   | WebSrv01
2026-03-31 12:15:30 | Database Timeout    | DbSrv01

az monitor log-analytics workspace table show --name AppTraces --resource-group MyResourceGroup --workspace-name MyWorkspace
{ "name": "AppTraces", "retentionInDays": 30, "totalRetentionInDays": 365 }

public class LogManager
{
    public void WriteStructuredLog(string msg, string severity)
    {
        // ログレベルがCritical（致命的）な場合のみ、即時通知とログ送信を行う
        if (severity == "Critical")
        {
            SendAlertNotification(msg);
            PushToAzure(msg, true);
            Console.WriteLine("【緊急】ログを送信し、管理者に通知しました。");
        }
        else if (severity == "Error" || severity == "Warning")
        {
            PushToAzure(msg, false);
            Console.WriteLine("ログを送信しました。");
        }
        else
        {
            // InfoやDebugはローカル出力のみに留め、クラウドへの送信は控えてコスト削減
            Console.WriteLine("低優先度ログのため、クラウド送信をスキップしました。");
        }
    }

    private void PushToAzure(string m, bool isHighPriority) { /* 送信処理 */ }
    private void SendAlertNotification(string m) { /* 通知処理 */ }
}