Log Analytics の Auxiliary 適用を GitHub Copilot に聞いてみた

このサイトの Hot Topic を見ていたところ、Microsoft Community Hub の記事「Azure Monitor Auxiliary Logs expands with Azure tables support, plan switching, and sovereign clouds」に気付きました。

記事では、Azure Monitor の Auxiliary Logs について、対応する Azure テーブルの拡大やテーブルプランの切り替えなどが紹介されています。そこで、Auxiliary をこのサイトで使っている Log Analytics Workspace に適用すれば、監視コストを下げられるのではないかと気になりました。

そこで GitHub Copilot に、Microsoft Learn の公式情報、リポジトリの Bicep、実際の Azure リソースと直近30日の取り込み量を確認してもらいました。今回は設定変更を行わず、適用した場合に何が起きるかだけを調べています。

目次

• 先に結論
• Auxiliary についての概要
• このサイトで現状使っている Log Analytics Workspace
• Auxiliary を適用したときのメリット
• Auxiliary を適用したときのデメリット
• このサイトへ適用する場合の判断
• まとめ

先に結論

現在の Memolog では、Auxiliary を適用せず、Analytics を維持するのがよいと判断しました。

理由は、直近30日のログ取り込み量が 2 つの Log Analytics Workspace を合計しても約 32 MB と少なく、Auxiliary による削減余地が小さいためです。一方で、Auxiliary に変更したテーブルではアラートが使えなくなり、クエリ性能や機能にも制約が加わります。

また、セキュリティログの大部分が入っている AzureDiagnostics は、2026年8月16日時点の公式情報では Auxiliary に対応していません。現在の収集方法を維持したまま、Security 用の Workspace を丸ごと Auxiliary に変更することはできません。

取り込み量が少なく、リアルタイム監視を重視する現在の構成では、わずかなコスト削減よりも Analytics の機能を維持する方が適しています。

Auxiliary についての概要

Log Analytics Workspace では、保存するログの用途に応じてテーブルごとにプランを選べます。

ここで大事なのは、Auxiliary は Workspace 全体へ一括適用する料金プランではないことです。1 つの Workspace の中で、テーブルごとに Analytics、Basic、Auxiliary を使い分けます。ただし、すべてのテーブルが全プランに対応しているわけではありません。

Auxiliary は、普段はほとんど参照しないものの、監査や将来の調査に備えて残しておきたい大量ログに向いています。対話的に頻繁に調べたり、数分ごとにアラート判定したりするログには向いていません。

Auxiliary の対話的な保持期間は30日です。総保持期間は最大12年まで設定できますが、30日を超えるデータの調査には Search Job などを使います。

詳しい機能差は、Microsoft Learn の Azure Monitor Logs のテーブルプランと Log Analytics Workspace でテーブルプランを構成するで確認できます。

このサイトで現状使っている Log Analytics Workspace

2026年8月16日時点で、Memolog は East US 2 に 2 つの Log Analytics Workspace を持っています。GitHub Copilot から Azure MCP Server を使い、実リソースと直近30日の Usage を読み取り専用で確認しました。

通常監視用の Workspace

memolog-prod-law には、主に次のテーブルからデータが入っていました。

この Workspace では、AppRequests、AppTraces、StorageTableLogs、AppAvailabilityResults、AppEvents などを使って、API の 5xx、長時間のキャンセル、Table Storage の失敗、定期収集の失敗、ブラウザーでの表示時間を監視しています。

セキュリティ監視用の Workspace

memolog-prod-security-law の直近30日の課金対象データは、AzureDiagnostics の約 3.4 MB でした。Azure Front Door のアクセスログと WAF ログを受け取り、Microsoft Sentinel で次のような検知に使っています。

• WAF がブロックしたリクエスト
• 管理 API に対する攻撃パターン
• Front Door、WAF、Workspace などの制御変更
• RBAC の変更
• Sentinel の異常とコネクター変更
• セキュリティログ取り込み量の急増

これらは5分間隔を中心に判定しています。つまり、単に保管しているログではなく、リアルタイム検知に使うログです。

Auxiliary を適用したときのメリット

ログの取り込みコストを抑えられる

Auxiliary の最大のメリットは、Analytics や Basic より低い単価でログを取り込めることです。

大量のデバッグログ、ネットワークフローログ、監査ログなどを長期間保存する環境では、取り込み量に比例して削減効果が大きくなります。普段は集計結果だけを見て、詳細ログは問題が起きたときだけ調べるような構成と相性がよいです。

長期保管へ使える

Auxiliary でも総保持期間を最大12年まで設定できます。リアルタイム分析よりも、監査、証跡、コンプライアンスのためにデータを残すことが目的なら、低コストの保管先として利用できます。

同じ Workspace 内で使い分けられる

重要な監視データは Analytics のまま残し、低頻度の詳細ログだけを Auxiliary にできます。Workspace を用途ごとに増やさなくても、テーブル単位でコストと機能のバランスを変えられます。

Auxiliary を適用したときのデメリット

アラートが使えなくなる

Analytics から Auxiliary へ変更したテーブルでは、Azure Monitor のアラートが動作しなくなります。

Memolog では API、Storage、収集処理、WAF をログアラートと Sentinel の分析ルールで監視しています。対象テーブルを Auxiliary にすると、コスト削減と引き換えに異常検知を失う可能性があります。

Basic では Simple Log Alerts を利用できますが、Auxiliary はアラートに対応していません。リアルタイム検知が必要なら、Analytics を維持するか、Auxiliary のデータを Summary Rule で集約して、集約先の Analytics テーブルを監視する設計が必要です。

クエリが遅くなり、実行量に応じた料金が発生する

Analytics は対話的な分析向けに最適化され、通常のクエリ料金は取り込み料金に含まれます。Auxiliary はクエリ性能が最適化されておらず、スキャンしたデータ量に応じて料金が発生します。

取り込み料金が下がっても、ダッシュボードや調査で頻繁にクエリすると、待ち時間とクエリ料金が増える可能性があります。

KQL と連携機能に制約がある

Auxiliary のクエリは単一テーブルが基本です。join、find、search、クロスリソースクエリなどに制約があります。

また、Insights、データエクスポート、Restore、Workspace Replication など、Analytics で利用できる一部の機能に対応していません。対応状況は Azure Monitor Logs のテーブル機能比較で確認できます。

すべてのテーブルへ適用できるわけではない

Azure の組み込みテーブルが Basic と Auxiliary に対応しているかは、テーブルごとに異なります。

たとえば、現在 Security 用の Workspace で使っている AzureDiagnostics は、Azure Monitor Logs のテーブル機能一覧では Auxiliary 非対応です。そのため、現在の Azure Front Door 診断設定をそのまま使い、AzureDiagnostics だけを Auxiliary に変更することはできません。

元へ戻してもデータの見え方はすぐには戻らない

Analytics から Auxiliary へ変更しても、変更前のデータは削除されません。ただし、変更日をまたぐクエリでは部分的な結果になる可能性があります。

あとから Analytics へ戻した場合も、Auxiliary だった期間に取り込まれたデータは通常の対話クエリでは参照できません。その期間のデータには Search Job や Search API が必要です。また、テーブルプランの変更はテーブルごとに週1回までに制限されています。

このサイトへ適用する場合の判断

今回の調査では、Auxiliary の一般的な安さだけでなく、実際のログ量と利用目的を確認したことが判断に効きました。

このため、現時点では両方の Workspace で Analytics を維持します。

コストをさらに下げるなら、Auxiliary へ変更する前に、不要なログカテゴリーを止める、Application Insights のサンプリングを調整する、Data Collection Rule の変換で不要なレコードや列を除外するといった方法を検討します。これらは監視要件を残したまま、取り込み量そのものを減らせる可能性があります。

将来、大量に発生するものの普段は参照しないログが増えた場合は、そのログを Auxiliary 対応の専用テーブルへ分離し、必要な集計だけを Analytics テーブルへ送る構成が候補になります。

まとめ

Auxiliary は、Log Analytics Workspace 全体を安いプランへ切り替える機能ではなく、対応するテーブルごとに選ぶプランです。大量で低頻度のログを監査や長期保管のために残す用途では、大きなコスト削減につながる可能性があります。

一方で、アラートが使えず、クエリ性能、KQL、連携機能に制約があります。すべての Azure テーブルが対応しているわけでもありません。

Memolog では、直近30日の取り込み量が約 32 MB と少なく、ログをリアルタイム監視と障害調査に使っています。削減余地より失う機能の方が大きいため、今回は Auxiliary を適用しないと判断しました。

GitHub Copilot に一般論だけを聞くのではなく、Microsoft Learn、Bicep、実際の Azure リソース、直近のログ量まで確認してもらうことで、この環境に合った判断ができました。料金プランを選ぶときは、単価だけでなく、そのログを何のために保存し、どの機能で利用しているかまで確認することが重要です。

参考資料

• Azure Monitor Logs overview
• Configure a table plan in a Log Analytics workspace
• Azure Monitor Logs table feature support
• Query data in a Basic and Auxiliary table
• Run search jobs in Azure Monitor