Azure Monitor Logsの2026年7月更新とは？Export jobの対象・条件・確認ポイント

2026年7月7日の公式更新で、Azure Monitor Logsに保存済みの履歴ログをAzure Blob Storageへオンデマンド出力する「エクスポートジョブ（Export job）」が、正式なエクスポート手段の一つとしてドキュメントに追加されました。

結論からいうと、既存のAzure Monitor Logs利用者全員に設定変更が必要な更新ではありません。対応を優先すべきなのは、監査対象期間のログを外部保管したい組織、過去データをSIEMやデータ分析基盤へ移したい担当者、データエクスポートルールを有効化する前のログを取り出したい利用者です。

一方、Azure Monitor Logs内での検索、アラート、ダッシュボード利用だけで運用が完結している場合、直ちにエクスポートジョブを導入する必要はありません。まずは、エクスポート対象、料金、権限、ネットワーク制約を確認し、小さな期間で検証することが重要です。(GitHub)

Azure Monitor Logsの2026年7月7日更新で何が変わったのか

今回の実質的な変更は、Azure Monitor Logs全体の仕様変更ではなく、ログの外部出力方法が整理され、履歴データ向けのエクスポートジョブが追加されたことです。

Microsoftが公開しているドキュメントの変更履歴では、2026年7月7日に「エクスポートジョブ（プレビュー）の記事追加と関連するログ記事の更新」が行われています。Azure Monitor Logsの概要ページでは、次の2点が変更されました。

変更箇所	変更前	変更後
テーブルプランの機能比較	Data export	Data export rules
Exportの利用方法	継続的なデータエクスポートとLogic Apps	データエクスポートルール、エクスポートジョブ、Logic Apps

特に重要なのは、エクスポートジョブが次の用途として追加された点です。

Log Analyticsワークスペースにすでに保存されている履歴ログを取り出す
対象期間を指定して出力する
KQLで必要なレコードだけを絞り込む
Azure Blob StorageへParquet形式で保存する
大量の履歴データを非同期処理で出力する

2026年7月7日のコミットで、Azure Monitor Logs概要ページ自体の変更は上記のエクスポート関連に限定されています。ログ収集、保持期間、アラート、KQLによる通常検索などが一斉に変更されたわけではありません。(GitHub)

ページの更新日表示と実際の変更履歴は異なる

Azure Monitor Logs概要ページのフッターには、最終更新日として「2026年4月6日」と表示されています。しかし、MicrosoftDocsの公式GitHubリポジトリでは、同じファイルに2026年7月7日のコミットが記録されています。

一方、新しく追加されたエクスポートジョブの記事には、最終更新日として2026年7月7日が表示されています。このため、今回の情報を確認するときは、概要ページのフッターだけでなく、関連ページと変更履歴まで確認する必要があります。(Microsoft Learn)

Azure Monitor Logsとは

Azure Monitor Logsは、Azure上のリソースだけでなく、オンプレミスや他クラウド、アプリケーションなどから収集したテレメトリーデータを一元的に保存・分析するサービスです。

中心となるリソースがLog Analyticsワークスペースです。収集したログはテーブルに格納され、Kusto Query Language（KQL）を使って検索できます。

主な用途には、次のものがあります。

システムやアプリケーションの障害調査
セキュリティイベントの分析
ログ検索アラートの実行
WorkbookやGrafanaによる可視化
Microsoft Sentinelとの連携
監査証跡の長期保持
Power BIや外部分析基盤へのデータ連携

Azure Monitor Logsには、Analytics、Basic、Auxiliaryの3種類のテーブルプランがあります。利用頻度、検索性能、料金、アラートやダッシュボードの必要性に応じて使い分けます。(Microsoft Learn)

Azure Monitor Logsのエクスポート方法を比較

今回の更新を理解するには、「データエクスポートルール」と「エクスポートジョブ」の違いを把握することが重要です。

両者は名前が似ていますが、利用目的が異なります。これから到着するログを継続的に外部送信するのがデータエクスポートルール、すでに保存されているログを必要なときに取り出すのがエクスポートジョブです。(Microsoft Learn)

比較項目	データエクスポートルール	エクスポートジョブ
主な用途	新しく到着するログの継続送信	保存済み履歴ログの一括出力
対象データ	ルール作成後に到着したデータ	ワークスペースに保存済みのデータ
実行方法	継続的	オンデマンド、非同期
出力単位	選択したテーブル	1ジョブにつき1テーブル
絞り込み	原則としてテーブル全体。必要に応じて収集時変換を使用	KQLクエリと期間で絞り込み可能
出力先	Azure Blob StorageまたはAzure Event Hubs	Azure Blob Storage
主な形式	StorageではJSON Lines	Parquet
ポータル操作	対応	未対応
API・コマンド	ポータル、CLI、PowerShell、REST API、Bicep、ARMテンプレート	REST API、`az rest`、`Invoke-AzRestMethod`
Analyticsプラン	対応	対応
Basicプラン	対応	対応
Auxiliaryプラン	非対応	非対応
適した場面	SIEM連携、常時保管、Event Hubs連携	監査対応、過去ログ移行、調査データの抽出

データエクスポートルールが適しているケース

次のような要件では、引き続きデータエクスポートルールが適しています。

今後到着するセキュリティログを継続的に別ストレージへ保存したい
Azure Event Hubsを経由して外部SIEMへ連携したい
Log Analyticsへの取り込みと並行して、別の保存先にもデータを送信したい
監査ログを継続的に改ざん防止ストレージへ保管したい

データエクスポートルールは、作成前にLog Analyticsへ保存された履歴データをさかのぼって出力できません。また、原則として対象テーブルに入るデータ全体が出力されます。(Microsoft Learn)

エクスポートジョブが適しているケース

次のような要件では、今回追加されたエクスポートジョブが候補になります。

監査で指定された3か月分のログだけを提出したい
インシデント発生期間のセキュリティログを外部調査会社へ渡したい
データエクスポートルールを設定する前のログを取り出したい
過去ログをデータウェアハウスやAzure Data Explorerへ移したい
機械学習モデルの学習用に履歴データを抽出したい
特定の端末、ユーザー、イベント種別だけをKQLで絞り込みたい

エクスポートジョブは、通常のログ取り込みや対話型クエリとは別のコンピューティング基盤で実行されるため、ジョブ実行によってワークスペースのログ取り込みや通常の検索体験へ影響を与えないとされています。(Microsoft Learn)

エクスポートジョブの対象ユーザーと対応要否

対応要否は、Azure Monitor Logsを利用しているかどうかだけでなく、履歴ログをワークスペース外へ取り出す要件があるかで判断します。

利用状況	対応の優先度	推奨対応
監査や訴訟対応で過去ログの提出がある	高	検証環境でエクスポート手順を確立する
インシデント調査で大量の履歴ログを外部分析する	高	対象テーブル、期間、KQL、保存先を確認する
データエクスポートルール設定前のログが必要	高	エクスポートジョブの利用を検討する
AI・機械学習・BI向けに履歴データを移行する	中～高	Parquetを利用できる分析基盤か確認する
将来の監査に備えて手順だけ整備したい	中	小規模なテストジョブを実行する
Azure Monitor内の検索とアラートだけを利用している	低	直ちに設定変更する必要はない
Auxiliaryプランのログだけを使っている	利用不可	別の出力方法を検討する
Private Link必須の閉域構成である	要精査	現時点のプレビュー制約を確認する
ワークスペースでABAC条件を使用している	要精査	403エラーの可能性を含めて事前検証する

エクスポートジョブはプレビュー機能です。本番の監査プロセスへ組み込む場合は、プレビュー機能に関する組織の利用基準、サポート条件、変更可能性も確認してください。(Microsoft Learn)

利用前に確認すべき提供条件と制限

エクスポートジョブには、通常のLog Analytics検索とは異なる制限があります。導入可否を判断する際は、少なくとも次の項目を確認してください。

項目	現時点の条件	実務上の確認ポイント
提供状態	プレビュー	本番利用に関する社内ルールを確認
対応プラン	Analytics、Basic	Auxiliaryは利用不可
出力先	Azure Blob Storage	容量、アクセス制御、保存期間を確認
出力形式	Parquetのみ	JSONを前提にした処理は修正が必要
対象テーブル	1ジョブにつき1テーブル	複数テーブルはジョブを分ける
期間	1ジョブにつき最大1年間	1年を超える場合は期間を分割
同時実行数	1ワークスペースにつき最大5ジョブ	大量処理は順番に実行
タイムアウト	最大7日	大容量の場合は期間や条件を細分化
手動再試行	1つの`jobId`につき最大5回	最新の完了時刻から7日以内に実行
保存先数	1ジョブにつき最大10ストレージアカウント	ストレージ側のスロットリング対策に使用
ポータル	未対応	REST API経由の操作手順が必要
Private Link	未対応	閉域接続必須環境では利用可否を精査
Network Security Perimeter	未対応	組織のネットワークポリシーを確認
ワークスペースレプリケーション	フェールオーバーで実行中ジョブが終了する可能性	セカンダリリージョンでは新規ジョブを作成不可
ABAC条件	未対応	条件付きロール割り当てがあると403になる可能性

開始時刻と終了時刻はいずれも現在時刻より前である必要があります。進行中の時間帯や未来の期間を指定して出力する機能ではありません。(Microsoft Learn)

プレビューAPIのバージョンを固定しすぎない

2026年7月7日時点の公式サンプルでは、エクスポートジョブAPIに2025-06-01-previewが使われています。

ただし、プレビューAPIは更新される可能性があります。自動化スクリプトへ組み込む場合は、サンプルのAPIバージョンを無条件にコピーするのではなく、実装時点の公式ドキュメントを確認してください。(Microsoft Learn)

KQLには利用できる演算子の制限がある

エクスポートジョブでは、任意の複雑なKQLをそのまま実行できるわけではありません。クエリは1つのテーブル名から開始し、Search jobsでサポートされるKQLの範囲に収める必要があります。

代表的な対応演算子は次のとおりです。

where
extend
project
project-away
project-keep
project-rename
project-reorder
parse
parse-where

高度な文字列検索であるcontainsはSearch jobsでは使用できず、代わりにhasの利用が案内されています。joinや複数テーブルのunionを前提としたクエリは、エクスポート設計を見直す必要があります。(Microsoft Learn)

実行前に通常のLog Analyticsで結果を確認する

エクスポート用のKQLは、事前に通常のLog Analytics画面で実行し、次の点を確認します。

対象テーブルが正しいか
必要な期間のレコードが存在するか
個人情報や秘密情報を必要以上に含んでいないか
where条件で意図したデータだけに絞れているか
projectで不要な列を除外できているか
レコード数が想定を大きく超えていないか

ただし、通常の対話型クエリで動作するKQLでも、エクスポートジョブの対応範囲外であれば実行できない点に注意してください。

必要な権限とマネージドID

エクスポートジョブでは、操作するユーザーの権限だけでなく、Log Analyticsワークスペースのシステム割り当てマネージドIDにも権限が必要です。

操作ユーザーに必要な権限

操作ユーザーには、主に次の権限が必要です。

対象テーブルを検索する権限
エクスポートジョブを実行する権限
必要に応じてワークスペースのシステム割り当てマネージドIDを有効化する権限

公式ドキュメントでは、ジョブの実行とテーブル検索にはLog Analytics Reader、マネージドIDの有効化にはLog Analytics Contributorが組み込みロールの例として示されています。

ワークスペースのマネージドIDに必要な権限

ワークスペースのシステム割り当てマネージドIDには、保存先ストレージアカウントに対して次の権限を付与します。

Storage Blob Data Contributor
ストレージアカウントのエンドポイントを解決するための読み取り権限

公式手順では、読み取り権限の例としてLog Analytics Readerロールが示されています。カスタムロールを使用する場合は、必要なアクションを満たしているか個別に確認してください。(Microsoft Learn)

403エラーを単純なRBAC不足と決めつけない

エクスポートジョブが403 Forbiddenで失敗した場合、一般的なロール不足以外にも次の可能性があります。

ワークスペースにABAC条件付きロール割り当てがある
保護されたテーブルへアクセスできない
ストレージアカウントの読み取り権限が不足している
マネージドIDにBlob書き込み権限が付与されていない
REST API用のアクセストークンが期限切れになっている

ABACや保護テーブルが原因の場合、詳細なエラーメッセージを伴わず、ワークスペースレベルで403が返ることがあります。権限設定だけを繰り返すのではなく、条件付きアクセス制御やテーブル単位の権限も確認してください。(Microsoft Learn)

エクスポートジョブの料金構造

エクスポートジョブは無料のデータ移動機能ではありません。主に次の3種類の費用を考慮します。

費用	課金対象
Search Jobs	ソーステーブルでスキャンしたデータ量
Log Analytics Data Export	Azure Storageへ出力されたデータ量
Azure Blob Storage	保存先ストレージの容量

エクスポートジョブとデータエクスポートルールは、どちらもLog Analytics Data Exportメーターを使用します。Cost analysisや請求明細では、Additional infoフィールドの値で区別できます。

エクスポートジョブ：ExportType:Export job
データエクスポートルール：ExportType:Data export rule

ジョブをキャンセルした場合でも、キャンセル前にスキャン・出力された分は課金対象になります。(Microsoft Learn)

実行前にデータ量を見積もる

公式ドキュメントでは、過去30日間のUsageテーブルを使い、対象期間のデータ量を概算する方法が示されています。

基本的な考え方は次のとおりです。

過去30日間のデータ量 ÷ 30日 × エクスポート対象日数

ただし、これは一定のデータ量が続くと仮定した概算です。月末処理、障害発生、セキュリティインシデントなどでログ量が急増する環境では、実データと大きくずれることがあります。

最初から1年分を実行するのではなく、1日または1週間分をテスト出力し、次の値を実測する方法が安全です。

スキャンされたデータ量
出力されたデータ量
Parquetファイルの合計容量
実行時間
ストレージアカウントのIngress
想定レコード数との差

公式ドキュメントでは、プレビュー期間中の評価値として1日当たり10,000GBを用いたタイムアウト見積もり例も示されています。ただし、保証された処理性能として扱わず、実環境で検証してください。(Microsoft Learn)

導入前に行うべき確認手順

エクスポートジョブを利用する場合は、次の順番で進めると失敗を抑えられます。

利用目的と対象データを決める

最初に、エクスポートの目的を明確にします。

監査証跡の提出
セキュリティ調査
外部SIEMへの取り込み
BI分析
機械学習
長期保管
システム移行

目的が曖昧なまま「念のため全ログを出力する」と、料金や情報漏えいリスクが大きくなります。必要なテーブル、期間、列、レコード条件を先に決めてください。

テーブルプランと保持期間を確認する

対象テーブルがAnalyticsまたはBasicプランであることを確認します。Auxiliaryプランはエクスポートジョブの対象外です。

また、対象期間のログがワークスペースの保持期間内に存在する必要があります。すでに削除されたデータを復元する機能ではありません。(Microsoft Learn)

保存先ストレージを準備する

保存先のAzure Blob Storageでは、次の点を確認します。

想定データ量を保存できる容量
ストレージアカウントのIngress上限
ライフサイクル管理
暗号化設定
ネットワーク設定
RBAC
保持期間
データ所在地に関する社内規程
監査証跡の管理方法

大量出力では、他のアプリケーションと共有していない専用ストレージアカウントを用意すると、スロットリングや権限管理の問題を切り分けやすくなります。

システム割り当てマネージドIDを有効化する

Log Analyticsワークスペースでシステム割り当てマネージドIDを有効化します。その後、保存先ストレージに必要なロールを付与します。

ロール割り当ての反映には時間がかかる場合があります。設定直後にジョブを実行して403が返った場合は、設定内容を確認したうえで少し時間を置いて再試行します。

KQLと期間を小さくして検証する

本番対象が90日分であっても、最初は1時間または1日分でテストします。

検証では、次の点を確認してください。

ジョブが正常に受理されるか
Parquetファイルが作成されるか
スキーマが想定どおりか
日時がUTCとして正しく扱われているか
レコード件数が元データと一致するか
個人情報が過剰に含まれていないか
下流システムがParquetを読み込めるか

本番ジョブを期間分割して実行する

大容量の場合は、月単位や週単位でジョブを分割します。1年間を一度に実行できる場合でも、処理途中の失敗、再試行、コスト確認を考えると、小さく分割した方が運用しやすくなります。

また、各ジョブで返されるoperationIdは、ステータス確認、キャンセル、再試行に使うjobIdです。必ず記録してください。(Microsoft Learn)

最小構成のリクエスト例

次は、CommonSecurityLogテーブルから特定ベンダーのログだけを抽出するリクエスト本文の例です。

{
  "startTime": "2026-01-01T00:00:00Z",
  "endTime": "2026-02-01T00:00:00Z",
  "query": "CommonSecurityLog | where DeviceVendor == \"Contoso\" | project TimeGenerated, DeviceVendor, DeviceProduct, Activity",
  "destinationStorageAccounts": [
    "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>"
  ],
  "containerName": "security-audit-2026-01",
  "outputDataFormat": "Parquet",
  "dateTimeFormat": "year=yyyy/month=MM/day=dd/hour=HH"
}

すべてのレコードを出力する場合は、queryにテーブル名だけを指定できます。

{
  "query": "CommonSecurityLog"
}

実際の送信では、Log AnalyticsのデータプレーンAPIへRESTリクエストを行います。専用のAzure CLIコマンドやAzure PowerShellコマンドレットは現時点で用意されていないため、Azure CLIではaz rest、PowerShellではInvoke-AzRestMethodを使います。(Microsoft Learn)

ジョブの監視と監査を設定する

エクスポートジョブは非同期処理です。APIが202 Acceptedを返した時点では、出力が完了したわけではありません。

本番利用では、APIのステータス確認だけに依存せず、Log Analyticsワークスペースの診断設定を構成します。

Jobsカテゴリを有効化する

ワークスペースの診断設定でJobsカテゴリを有効化すると、ジョブの状態がLAJobLogsテーブルへ記録されます。

確認できる主な情報は次のとおりです。

フィールド	内容
`JobId`	ジョブを識別するGUID
`JobType`	エクスポートジョブでは`Export`
`SourceTable`	出力元テーブル
`Status`	Started、Succeeded、Canceled、Failed
`ResultsRecordCount`	出力されたレコード数
`ResultsGB`	保存先へ出力されたデータ量
`Destination`	保存先ストレージとコンテナー
`Message`	処理内容やエラー情報

失敗したジョブは、次のようなKQLで確認できます。

LAJobLogs
| where TimeGenerated > ago(7d)
| where Status == "Failed"
| sort by TimeGenerated asc

ストレージ側のIngressも監視する

保存先ストレージがスロットリングされると、一部の処理単位が失敗し、再試行が発生します。

公式ドキュメントでは、ストレージアカウントのIngressが上限の80％未満に収まるようアラートを設定する考え方が示されています。上限へ近づく場合は、次の対策を検討します。

エクスポート専用ストレージへ分離する
期間を細かく分ける
実行タイミングをずらす
最大10個のストレージアカウントへ分散する
必要に応じてストレージ上限の引き上げを検討する

操作とクエリを監査する

エクスポートジョブの作成、キャンセル、再試行はAzure Activity Logへ記録されます。

また、ワークスペースの診断設定でAuditカテゴリを有効化すると、ジョブで使用されたクエリをLAQueryLogsテーブルから監査できます。機密ログを外部出力できる機能であるため、誰が、どのクエリで、どの期間を出力したかを追跡できる状態にしておくことが重要です。(Microsoft Learn)

失敗時の再試行とキャンセルに注意する

エクスポートジョブには自動再試行機能があります。それでも処理単位の一部が失敗した場合は、同じjobIdを使って手動再試行できます。

手動再試行は、すでに正常出力されたデータを飛ばし、不足している部分だけを処理する設計です。そのため、同じジョブを最初から作成し直すより、重複を抑えられます。

ただし、次の制限があります。

手動再試行は最大5回
最新のジョブ完了時刻から7日以内に実行する
キャンセル済みジョブは再試行できない
キャンセル前に出力されたデータは保存先に残る
キャンセル前に発生した処理は課金対象になる

誤った条件で大規模ジョブを開始した場合でも、キャンセルすれば完全に元の状態へ戻るわけではありません。保存先の不完全なデータを識別し、必要に応じて削除する運用も準備してください。(Microsoft Learn)

導入時に失敗しやすいポイント

データエクスポートルールと混同する

最も多い間違いは、過去ログを取り出したいのにデータエクスポートルールを設定することです。

データエクスポートルールは、原則として設定後に到着するログが対象です。過去ログはエクスポートジョブを使います。

Auxiliaryプランを出力しようとする

エクスポートジョブはAuxiliaryプランに対応していません。対象テーブルのプランを確認せずにAPIを実行しても、目的の出力はできません。

複数テーブルを1つのクエリで結合する

エクスポートジョブは1テーブル単位です。複数テーブルの結合結果が必要な場合は、テーブルごとに出力して後段で結合するなど、処理方式を見直します。

いきなり長期間を指定する

1年間まで指定できますが、1年分を一度に実行することが最適とは限りません。大量データでは処理に数日かかる可能性があり、最大7日でタイムアウトします。

Parquetを読み込めないシステムへ渡す

エクスポートジョブの出力形式はParquetのみです。外部システムがJSONやCSVだけに対応している場合、変換処理が必要です。

Private Link環境で利用できると判断する

エクスポートジョブは、現時点でAzure Private LinkとNetwork Security Perimeterに対応していません。閉域接続が必須の組織では、本番導入前にネットワーク・セキュリティ担当者を含めて判断してください。

エクスポート後のデータ管理を決めていない

Azure Monitor Logsからログを出力すると、同じ情報のコピーが別のストレージに作成されます。

出力後は、次の管理が必要です。

閲覧可能な担当者
保存期間
削除手順
暗号化
バックアップ
監査ログ
法令や契約上の保管要件
個人情報や認証情報の取り扱い

エクスポートの成功だけでなく、出力後のデータライフサイクルまで設計してください。

対応要否を判断するチェックリスト

次の質問に1つでも該当する場合は、エクスポートジョブの検証を進める価値があります。

過去のAzure Monitor Logsを外部へ提出する可能性がある
データエクスポートルール設定前のログが必要になる
大量の履歴データを外部分析基盤へ移したい
KQLで絞り込んだログだけを保存したい
Parquet形式を活用できる分析基盤がある
監査やインシデント対応の時間を短縮したい

一方、次の条件では、現時点で導入を見送る判断も妥当です。

履歴ログを外部へ出力する要件がない
Auxiliaryプランのログが対象である
Private Link必須で例外を認められない
プレビュー機能を本番利用できない
Blob StorageやParquetを扱う運用基盤がない
ABAC条件を外せず、検証でも利用できない

Azure Monitor Logs利用者が次に行うべきこと

今回の更新は、Azure Monitor Logsの既存運用を強制的に変更するものではありません。重要なのは、保存済みログを外部へ取り出す新しい選択肢が追加されたことです。

対応が必要な組織は、次の順番で進めてください。

履歴ログの外部出力要件を整理する
対象テーブルのプランと保持期間を確認する
Private Link、Network Security Perimeter、ABACの利用状況を確認する
出力データ量と料金を見積もる
専用のAzure Blob Storageを準備する
マネージドIDとRBACを設定する
1時間または1日分の小規模ジョブで検証する
LAJobLogsとストレージIngressの監視を設定する
本番対象を期間分割して実行する
出力後のアクセス権、保持、削除方法を文書化する

監査やセキュリティ調査で履歴ログの外部出力が必要になる組織は、実際の依頼が発生してから手順を調べるのではなく、事前に小規模な検証を済ませておくと対応時間を大幅に短縮できます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。