MENU

Azure Monitor Log Analyticsの履歴エクスポートジョブがプレビュー開始｜変更点・条件・導入判断

Azure

Azure Monitor Log Analyticsで「すでに蓄積されている過去ログを、まとめて外部へ取り出したい」という課題に対し、2026年7月8日付で履歴エクスポートジョブのパブリックプレビューが案内されました。正式な機能名は「Log Analytics Export Job」で、KQLクエリと期間を指定し、過去のログをAzure Blob StorageへParquet形式で非同期エクスポートできます。(マイクロソフト アジュール)

結論として、監査対応、法的保全、フォレンジック調査、SIEM移行、機械学習用データ作成などのために、過去ログを独自スクリプトで抽出している組織は検証する価値があります。一方、これから届くログを継続的に転送するだけであれば、既存のデータエクスポートルールやリソースの診断設定を利用すればよく、すべてのLog Analytics利用者に設定変更が必要な更新ではありません。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Azure Monitor Log Analyticsの履歴エクスポートジョブで何が変わるのか

これまでLog Analyticsのデータエクスポートルールで転送できるのは、ルールを作成した後に新しく到着するログが中心でした。ルール作成前からワークスペースに保存されている過去ログを取り出すには、Log Analytics Query API、Logic Apps、Azure Functionsなどを組み合わせ、期間を分割しながら繰り返し取得する仕組みを構築する必要がありました。

今回のExport Jobでは、対象テーブル、KQLによる抽出条件、開始日時、終了日時、出力先ストレージを指定すると、Azure Monitor側が非同期処理を実行します。処理は通常のログ取り込みや対話型クエリとは別のコンピューティングリソースで動作するため、エクスポートによってワークスペースの取り込みや通常のクエリ操作が直接圧迫されにくい設計です。(TECHCOMMUNITY.MICROSOFT.COM)

出力データはAzure Blob Storage内に、時間単位のフォルダーへ分割されたParquetファイルとして保存されます。公式ブログではgzip圧縮されたParquetとして説明されており、Azure Data Explorer、Spark、データレイク、機械学習基盤などで扱いやすい形式です。(TECHCOMMUNITY.MICROSOFT.COM)

既存のエクスポート方法との違い

用途によって、Export Jobと既存機能を使い分ける必要があります。

方法対象データ主な用途注意点
Export Jobワークスペース内の過去ログ監査、調査、移行、データレイクへの一括抽出パブリックプレビュー。1ジョブにつき1テーブル
データエクスポートルール設定後に到着する新しいログ継続的なバックアップ、Event Hubs連携設定前の履歴データは遡って転送できない
リソースの診断設定Azureリソースから今後発生するログ低遅延の継続転送Log Analyticsに蓄積済みのログは対象外
Logic AppsやQuery APIクエリで取得できる履歴データ少量データの定期処理、独自ワークフロー行数、応答サイズ、実行時間、API呼び出し数の制限を考慮する必要がある
Search Job長期保持データをワークスペース内へ検索結果テーブルとして取り込むLog Analytics内での詳細分析外部ストレージへの一括抽出を目的とした機能ではない
Restore長期保持データを一時的に復元過去ログを通常のKQLで再分析復元用ストレージなどのコストが発生する

Logic AppsのLog Analyticsコネクタには、最大50万行、64MB、クエリ実行10分、毎分100呼び出しなどの制限があります。Export Jobは、こうしたクエリ・コネクタ制限を受ける独自分割処理の代わりとして、大規模な履歴抽出向けに用意されたネイティブ機能です。(Microsoft Learn)

パブリックプレビュー時点の主な仕様と提供条件

導入前に確認しておきたい仕様は次のとおりです。(Microsoft Learn)

項目内容
提供状態パブリックプレビュー
対象テーブルプランAnalytics、Basic
非対応プランAuxiliary
ジョブ単位1ジョブにつき1テーブル
抽出条件期間と、サポート対象のKQLによるフィルター
出力先Azure Blob Storage
出力形式Parquetのみ。JSONは未対応
フォルダー構成時間単位でパーティション分割
操作方法Log Analytics REST API
Azureポータルジョブ作成画面は未提供
CLI・PowerShell専用コマンドレットではなく、az restやInvoke-AzRestMethodを利用
同時実行数ワークスペースごとに最大5ジョブ。再試行中のジョブを含む
1ジョブの期間最大1年間
最大実行時間7日間
手動再試行1つのジョブIDにつき最大5回
再試行期限最新のジョブ完了から7日以内
出力先ストレージ数1ジョブにつき最大10アカウント
Private Link現時点では未対応
Network Security Perimeter現時点では未対応
ABAC条件現時点では未対応

出力できるのは、対象テーブルの保持期間内に残っているデータです。1年以上をまとめて移行したい場合は、年単位や月単位で複数ジョブに分割する必要があります。

また、関連する公式ブログでは、出力先ストレージアカウントをLog Analyticsワークスペースと同じAzureリージョンに配置することが前提として示されています。クロスリージョン対応は今後の計画とされているため、実行前に最新のMicrosoft Learnで条件を再確認してください。(TECHCOMMUNITY.MICROSOFT.COM)

対象ユーザーと対応要否の判断基準

Export Jobを優先的に検証したいのは、次のような組織です。

判断該当する状況
検証優先度が高い監査依頼のたびに過去ログを手作業で抽出している
検証優先度が高いLogic Apps、Functions、スクリプトで期間分割を実装している
検証優先度が高いMicrosoft Sentinelや外部SIEMから別基盤へデータを移行する
検証優先度が高いフォレンジック調査用に特定期間の大量ログを保全する
検証価値がある過去ログを機械学習、BI、データレイクで利用する
対応を急がなくてよい将来分のログを継続転送するだけである
現時点では採用を見送るPrivate Linkや閉域接続が必須である
現時点では採用を見送るAuxiliaryプランのテーブルだけを利用している
現時点では採用を見送る社内規程でプレビュー機能の本番利用が禁止されている

公式ドキュメントでは、法令・監査対応、セキュリティ調査、外部SIEMとの連携、機械学習、BIなどが主な利用シナリオとして示されています。(Microsoft Learn)

導入前に確認すべきポイント

プレビュー機能を本番標準にしてよいか

Export Jobは一般提供ではなくパブリックプレビューです。仕様、API、制限事項、提供リージョンなどが変更される可能性があります。

監査や法的保全に利用する場合は、「エクスポートできた」という事実だけで本番要件を満たすとは限りません。少なくとも次の項目を事前に整理してください。

  • プレビュー機能の利用を組織のセキュリティ規程が認めているか
  • エクスポート結果の完全性をどのように検証するか
  • 保管期間、削除防止、アクセス制御をどのように設定するか
  • ジョブ失敗時の再実行期限を誰が管理するか
  • 一般提供後にAPIや運用手順を再検証する担当者を決めているか

スキャン量とエクスポート量の両方でコストが発生する

Export Jobはプレビュー期間中でも無料機能ではありません。料金は主に次の3要素で構成されます。

  • 元テーブルを読み取ったデータ量に対するSearch Jobsメーター
  • 実際にエクスポートしたデータ量に対するLog Analytics Data Exportメーター
  • 出力先Azure Storageの容量、トランザクション、冗長化などの料金

請求情報では、Export Jobに由来するデータエクスポートにExportType:Export jobが付与され、継続データエクスポートのExportType:Data export ruleと区別できます。(Microsoft Learn)

KQLで不要なレコードや列を除けば、エクスポート量と後続処理量を減らせます。ただし、出力データを減らしても、対象期間のスキャン量が同じ割合で減るとは限りません。実行前に公式ドキュメントの推定クエリを使い、対象テーブルのデータ量を確認することが重要です。

マネージドIDとRBACを事前に整える

Export Jobでは、Log Analyticsワークスペースのシステム割り当てマネージドIDを使って、Azure Storageへデータを書き込みます。

実行者とワークスペースのマネージドIDには、それぞれ異なる権限が必要です。

対象必要な権限の例
ジョブを実行するユーザーテーブルのクエリ権限、workspaces/jobs/export/action
マネージドIDを有効化するユーザーワークスペースの書き込み権限
ワークスペースのマネージドIDStorage Blob Data Contributor
ワークスペースのマネージドIDストレージアカウントのエンドポイントを参照する権限

公式ドキュメントでは、ジョブ実行者にはLog Analytics Reader、マネージドIDの有効化にはLog Analytics Contributor、ストレージへの書き込みにはStorage Blob Data Contributorなどが例示されています。(Microsoft Learn)

必要以上にサブスクリプション全体へ権限を付けず、可能な限り対象ワークスペースと出力先ストレージにスコープを限定するのが安全です。

通常のKQLをそのまま使えるとは限らない

Export Jobのqueryには、Search JobsでサポートされるKQLの範囲が適用されます。クエリはテーブル名から開始し、主に次のような抽出・加工演算子を利用します。

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

一方、現行の公式サポート一覧にはjoin、union、summarizeなどは含まれていません。また、文字列検索のcontainsは制限され、代わりにhasの利用が案内されています。複数テーブルの結合や複雑な集計結果を直接書き出す処理ではなく、単一テーブルから必要な行と列を抽出する機能として設計するのが適切です。(Microsoft Learn)

履歴エクスポートを災害対策と混同しない

Export Jobは、すでにLog Analyticsへ保存されたデータを外部へ取り出す機能です。ログの収集元で障害が起きてデータが送信されなかった場合や、取り込みパイプラインでデータが失われた場合に、そのデータを復元するものではありません。

また、ワークスペース自体が利用できなくなった際に、クエリ、アラート、ダッシュボードなどを別リージョンで継続する機能でもありません。サービス継続性が必要な場合は、ワークスペースレプリケーションなど別の可用性設計を検討する必要があります。(Microsoft Learn)

Export Jobを導入する基本手順

実務では、最初から全期間をエクスポートせず、短期間・少量データで検証してから対象範囲を広げるのが安全です。

対象テーブルと期間を決める

最初に、次の項目を明確にします。

  • 対象テーブル名
  • テーブルプランがAnalyticsまたはBasicであること
  • データが保持期間内に残っていること
  • エクスポート開始日時と終了日時
  • 必要な列とレコードの条件
  • エクスポート後の利用目的

複数テーブルが必要な場合は、テーブルごとに別ジョブを作成します。

データ量を見積もる

Usageテーブルなどを使って、対象テーブルの過去30日間の取り込み量からエクスポート規模を推定します。

大量データを1年分まとめて指定すると、7日間のジョブタイムアウトに達する可能性があります。データ量が大きい場合は、月単位や週単位に分けてください。Microsoft Learnでも、推定結果が大きい場合は期間を分割して複数ジョブを送信する方法が案内されています。(Microsoft Learn)

Azure Blob Storageを準備する

ストレージ側では、次の項目を確認します。

  • 必要容量
  • ストレージアカウントのリージョン
  • 冗長化方式
  • ライフサイクル管理
  • 削除防止や不変ストレージの要否
  • 他の大量書き込み処理との競合
  • エクスポート後の読み取り権限

出力先が他の高帯域処理と共有されていると、ストレージのスロットリングによって一部の時間単位処理が失敗する可能性があります。大規模処理では専用ストレージを用意するか、最大10個までのストレージアカウントに分散する方法を検討します。(Microsoft Learn)

マネージドIDと権限を設定する

Log Analyticsワークスペースでシステム割り当てマネージドIDを有効にし、出力先ストレージで必要なロールを割り当てます。

ロール割り当ての反映には時間がかかることがあります。権限設定直後に403エラーが出た場合は、スコープと対象IDを再確認したうえで、反映を待って再試行します。

診断設定を有効にする

ワークスペースの診断設定でJobsカテゴリを有効にし、ジョブ情報をLog Analyticsへ送信します。これにより、LAJobLogsテーブルで次の情報を確認できます。

  • ジョブID
  • 対象テーブル
  • 開始日時
  • Started、Succeeded、Canceled、Failedなどの状態
  • エクスポート件数
  • 出力データ量
  • 出力先情報
  • エラーメッセージ

KQLの監査も必要な場合は、Auditカテゴリを有効にします。ジョブで使用されたクエリはLAQueryLogsへ記録されます。ジョブの作成、キャンセル、再試行といった操作はAzure Activity Logでも監査できます。(Microsoft Learn)

REST APIでジョブを作成する

2026年7月時点のMicrosoft Learnでは、Export Jobの例に2025-06-01-previewのAPIバージョンが使用されています。

リクエスト本文は次のような構成です。

{
  "startTime": "2026-01-01T00:00:00Z",
  "endTime": "2026-03-01T00:00:00Z",
  "query": "CommonSecurityLog | where DeviceVendor == 'Contoso' | project TimeGenerated, DeviceVendor, DeviceProduct, Message",
  "destinationStorageAccounts": [
    "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>"
  ],
  "containerName": "common-security-log-export",
  "outputDataFormat": "Parquet",
  "dateTimeFormat": "yyyy-MM-ddTHH"
}

作成要求が受け付けられると、202 AcceptedとともにoperationIdが返されます。この値がジョブの状態確認、キャンセル、再試行に使用するjobIdです。紛失しないよう、運用記録やジョブ管理台帳に保存してください。(Microsoft Learn)

なお、公式告知ブログに掲載されたサンプルと、更新後のMicrosoft LearnではAPIバージョンの例が異なります。プレビュー中は古い記事のコードをそのままコピーせず、実装時点のMicrosoft Learnに掲載されているAPIバージョンを優先してください。(TECHCOMMUNITY.MICROSOFT.COM)

完了状態と出力データを検証する

ジョブのステータスAPIでは、進捗率、出力件数、スキャン量などを確認できます。完了後は、次の順序で検証します。

  1. ジョブ状態がSucceededになっているか確認する
  2. LAJobLogsの件数と出力データ量を記録する
  3. Blob Storageに対象時間分のフォルダーが存在するか確認する
  4. 複数の時間帯からParquetファイルを抽出して内容を確認する
  5. 元のLog Analyticsクエリ結果と件数や代表レコードを比較する
  6. 必要に応じて保持ポリシーや削除防止設定を適用する

少量の出力結果はLog Analyticsのexternaldata演算子で確認できます。大量データを繰り返し分析する場合は、Azure Data Explorerの外部テーブルとして参照する方法が適しています。(Microsoft Learn)

失敗しやすいポイントと対処方法

症状主な原因対処
403エラーになる実行者の権限不足テーブルクエリ権限とExport Job実行権限を確認する
403エラーになるマネージドIDのストレージ権限不足Storage Blob Data Contributorなどの割り当て先とスコープを確認する
詳細のない403が返るABAC条件、保護テーブル、テーブル権限不足ABACやテーブルレベルのアクセス制御を確認する
403 UnauthorizedになるREST API用トークンの有効期限切れトークンを再取得する
クエリが受け付けられない未対応のKQL演算子を使用しているwhereやproject中心の抽出クエリへ修正する
JSONで出力できないプレビュー時点ではParquetのみ後続処理をParquet対応にする
1年以上を指定できない1ジョブの期間上限年、四半期、月などに分割する
7日でタイムアウトするデータ量または期間が大きすぎる対象期間を分割し、不要な行や列を除外する
一部時間帯が欠落するストレージのスロットリングや一時障害ストレージのIngressメトリックを確認し、失敗したジョブを再試行する
複数テーブルを一度に出力できない1ジョブ1テーブルの仕様テーブルごとに個別ジョブを作成する
キャンセル後に再試行できないキャンセル済みジョブは再試行対象外新しいジョブとして作成し直す
API呼び出しが失敗する古いプレビューAPIバージョンを使用最新のMicrosoft LearnでAPIバージョンを確認する

ジョブが失敗またはタイムアウトした場合、7日以内であれば最大5回まで手動再試行できます。再試行では正常に完了した時間単位のデータを飛ばし、未完了または失敗した部分だけが処理されます。失敗した時間単位の不完全な出力は再書き込み前に整理されるため、同じレコードが重複して出力されるリスクを抑える仕組みになっています。(Microsoft Learn)

対応が必要かを判断するための最終チェック

まず、自社で「過去ログを外部へ取り出す処理」が存在するか確認してください。

独自スクリプト、Logic Apps、Functions、手作業のCSV分割などを使っている場合は、Export Jobによって運用負荷を減らせる可能性があります。対象テーブルと短い期間を選び、テスト用ストレージへの小規模なエクスポートから検証を始めるのが現実的です。

検証時は、機能が動作するかだけでなく、スキャン料金、出力料金、Storage料金、RBAC、閉域接続要件、再試行期限、監査ログ、出力データの完全性まで確認します。

一方、必要なのが将来分の継続転送だけであれば、既存のデータエクスポートルールや診断設定を継続すれば問題ありません。Export Jobは、通常のデータエクスポートを置き換える機能ではなく、これまで弱かった「すでに保存されている履歴データの大規模な取り出し」を補う選択肢です。

Azure
Azure Blob Storage Azure Monitor Log Analytics Export Job

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次