Log AnalyticsワークスペースのテレメトリをPower BIやSparkで分析したいものの、エクスポート先のストレージ、データ移送パイプライン、二重保存のコストまで管理するのは負担です。
この課題に対する新しい選択肢として、2026年7月29日、Azure Monitor LogsをMicrosoft Fabricへミラーリングする機能がパブリックプレビューになりました。Log Analyticsのデータをコピーするのではなく、FabricからDelta Parquet形式のデータを参照し、Eventhouse、Power BI、Sparkなどでほぼリアルタイムに利用できます。Analytics、Basic、Auxiliaryのすべてのログプランが対象です。
ただし、パブリックプレビュー時点では、ミラーリング開始前の履歴データが取り込まれない、Log Analytics側のアクセス制御がそのまま引き継がれないといった重要な制約があります。導入手順だけでなく、認証方式、コスト、セキュリティ、失敗しやすいポイントまで確認してから検証を始めることが重要です。(Microsoft Learn)
Azure Monitor LogsをFabric OneLakeへミラーリングする機能とは
Azure Monitor Logsのミラーリングは、Log Analyticsワークスペース内のテーブルを、Microsoft Fabricの各ワークロードから利用できるようにする機能です。
一般的なデータベースミラーリングのように、データをFabric側へ継続的に複製する仕組みではありません。Log AnalyticsのデータはAzure Monitor側に残り、Fabricのミラー項目とOneLakeショートカットが、Azure Monitorで使用されているDelta Parquetストレージを参照します。同期用パイプラインや複製先ストレージを別途用意する必要はありません。(Microsoft Learn)
構成を簡略化すると、次のようになります。
Log Analyticsワークスペース
↓
Azure Monitor側のDelta Parquetデータ
↓ 参照
Mirrored Azure Monitor項目
├─ Eventhouseエンドポイント
├─ 既存EventhouseへのOneLakeショートカット
└─ LakehouseへのOneLakeショートカット
├─ Spark
├─ Power BI
└─ データエンジニアリングFabricからの読み取りはショートカット経由で行われ、ミラーリングされたテーブルは読み取り専用です。新しいログの取り込みは、従来どおりAzure Monitor側で継続します。(Microsoft Learn)
従来のエクスポート構成との違い
| 比較項目 | 典型的なエクスポート構成 | Fabricへのミラーリング |
|---|---|---|
| データ移動 | エクスポートやETLが必要 | データを複製せず参照 |
| 保存先 | 別のストレージを用意 | Azure Monitor側のデータを参照 |
| パイプライン管理 | スケジュール、障害、再実行を管理 | 同期パイプラインは不要 |
| データ形式 | 出力先や処理ごとに設計 | Delta Parquetとして利用 |
| 更新頻度 | バッチ間隔に依存しやすい | Azure Monitorの遅延に追従し、通常は数分単位 |
| 保持期間 | 複製先でも管理が必要 | Azure Monitorの保持・ライフサイクル設定が継続 |
| 主な用途 | 外部保管、個別システム連携 | Fabric内での横断分析、BI、機械学習 |
ミラーリングの強みは、単にログを別の場所で閲覧できることではありません。テレメトリをERP、CRM、売上、契約、顧客、コストなどの業務データと同じ分析基盤で扱える点にあります。(Microsoft Learn)
Analytics・Basic・Auxiliaryの全ログプランを利用できる
Azure Update 568322では、次のAzure Monitor Logsプランがすべてサポート対象とされています。
- Analyticsログ
- Basicログ
- Auxiliaryログ
そのため、Fabricで利用するためだけに、すべてのテーブルをAnalyticsログへ変更する必要はありません。既存のログプランを維持したまま、必要なテーブルをミラーリング対象として選択できます。
ただし、「すべてのログプランをサポートする」ことと、「すべての既存データを即座にFabricから参照できる」ことは別です。パブリックプレビューでは、ミラーリング設定後に到着した新しいデータだけがFabricに表示されます。
Fabricで利用できる3つの主なアクセス方法
ミラーリング項目を作成すると、選択したLog Analyticsテーブルを利用するためのEventhouseエンドポイントも作成されます。さらに、既存のEventhouseやLakehouseからOneLakeショートカットを作成できます。(Microsoft Learn)
| アクセス方法 | 向いている用途 | 主な機能 |
|---|---|---|
| 付属のEventhouseエンドポイント | ミラーリングしたログを単独で分析 | KQL、リアルタイムダッシュボード、アラート |
| 既存Eventhouseへのショートカット | 業務データとテレメトリのリアルタイム結合 | KQL、クエリアクセラレーション、Real-Time Intelligence |
| Lakehouseへのショートカット | バッチ分析、BI、機械学習 | Spark、ノートブック、Power BIセマンティックモデル |
Eventhouseが向いているケース
EventhouseではKQLを使用できるため、障害件数、応答時間、依存関係の失敗、仮想マシンの稼働状況などを時系列で分析できます。
既存のEventhouseに売上や注文のデータがある場合は、Azure Monitor Logsへのショートカットを追加し、システム障害と売上減少の関係を同じクエリ環境で調べられます。
Lakehouseが向いているケース
Lakehouseへショートカットを作成すると、ミラーリングされたテーブルはDelta Lakeテーブルとして表示されます。
Sparkノートブックで大量のログを加工したり、Power BIセマンティックモデルで業務テーブルと関連付けたりする場合に適しています。長期的な傾向分析、異常検知用データの作成、機械学習モデルへの入力にも利用できます。(Microsoft Learn)
ミラーリングを始める前の前提条件
設定を始める前に、次の項目を確認します。
| 確認項目 | 必要な内容 |
|---|---|
| Log Analytics | 対象テーブルを持つ既存のワークスペース |
| ログの状態 | 対象テーブルへ最近のデータ取り込みがあること |
| Fabric容量 | Fabric容量またはFabric試用版 |
| Fabricワークスペース | 「マイ ワークスペース」ではない通常のワークスペース |
| テナント設定 | Mirrored catalog itemが有効 |
| Azure権限 | 接続作成に必要なカスタムロールまたは特権ロール |
| クロステナント | サービスプリンシパルとクライアントシークレット |
Fabricの新規項目一覧にMirrored Azure Monitorカードが表示されない場合は、Fabric管理者が管理ポータルのテナント設定でミラー化されたカタログ項目を有効にする必要があります。(Microsoft Learn)
接続作成に必要なAzure権限
新しい接続を作成するユーザーまたはIDには、Log Analyticsワークスペースに対して次のアクションが必要です。
Microsoft.Authorization/roleAssignments/write
Microsoft.OperationalInsights/workspaces/query/read
Microsoft.OperationalInsights/workspaces/readこれらを含むカスタムロールのほか、Owner、User Access Administrator、Role Based Access Control Administratorなど、必要な操作を実行できる組み込みロールも利用できます。(Microsoft Learn)
注意したいのは、Log AnalyticsワークスペースのContributorや、Fabricワークスペースの管理者であるだけでは、新しい接続を作成できない場合があることです。特にMicrosoft.Authorization/roleAssignments/writeがなく、403エラーになるケースが想定されます。(Microsoft Learn)
一度接続が作成されれば、同じFabricワークスペースの別ユーザーは、その接続を再利用できます。再利用するユーザーにAzure側のロールを個別に付与する必要はありません。
認証方式は運用形態に合わせて選ぶ
接続作成時には、主に3つの認証方式を選択します。認証方式は接続作成後に変更できないため、検証用と本番用を分けて考える必要があります。(Microsoft Learn)
| 認証方式 | 適した構成 | 判断基準 |
|---|---|---|
| Workspace identity | 同一テナントの継続運用 | 個人アカウントに依存させたくない |
| Organizational account | 同一テナントの検証や個人利用 | 手早く試したい |
| Service principal | FabricとLog Analyticsが別テナント | クロステナント接続が必要 |
同一テナントの継続運用はWorkspace identityを優先する
FabricとLog Analyticsが同じMicrosoft Entraテナントにある場合、継続運用ではFabricワークスペースIDを使用する方式が適しています。
担当者の異動、退職、アカウント無効化によって接続が止まるリスクを抑えられるためです。ワークスペースIDに対して、Log Analyticsワークスペース側で必要なロールを付与します。(Microsoft Learn)
初期のパブリックプレビューに関する公式トラブルシューティングでは、Workspace identityの検証に失敗する既知の問題も記載されています。正しい権限を付与しても失敗する場合は、同一テナントでは組織アカウントを一時的に利用し、修正状況を確認してからWorkspace identityへ切り替える方法を検討します。(Microsoft Learn)
組織アカウントは検証用途に向いている
Organizational accountでは、接続を作成したユーザーのOAuth資格情報が継続的に使用されます。
設定は簡単ですが、そのユーザーがテナントから離脱したり、Log Analyticsへのアクセス権を失ったりすると、接続が停止する可能性があります。個人所有の検証環境には適していますが、長期間運用する共有基盤では避けるのが安全です。(Microsoft Learn)
クロステナントではService principalを使用する
FabricテナントとLog Analyticsテナントが異なる場合は、Log Analytics側のテナントにサービスプリンシパルを作成し、次の情報を使用します。
- Log Analytics側のテナントID
- Log AnalyticsワークスペースID
- アプリケーションのクライアントID
- クライアントシークレット
クライアントシークレットは平文で長期間管理せず、Azure Key Vaultなどで保護し、定期的にローテーションする運用が必要です。(Microsoft Learn)
Azure Monitor LogsをFabric OneLakeへミラーリングする手順
Fabric管理ポータルで機能を有効にする
Mirrored Azure Monitorカードが表示されていない場合は、Fabric管理者が次の設定を確認します。
Fabric管理ポータル
→ テナント設定
→ Mirrored catalog item設定名や日本語表示はプレビュー期間中に変更される可能性があります。新規項目の一覧でMirrored Azure Monitorを検索できるかどうかを、最終的な確認基準にします。(Microsoft Learn)
Log AnalyticsワークスペースIDを確認する
Azureポータルで対象のLog Analyticsワークスペースを開き、概要画面に表示されるワークスペースIDを控えます。
必要なのはAzureリソースIDではなく、GUID形式のワークスペースIDです。入力形式を間違えると400エラー、異なるテナントのIDを指定すると401や404エラーになることがあります。(Microsoft Learn)
Fabricワークスペースでミラー項目を作成する
Microsoft Fabricで、ミラー項目を配置するワークスペースを開きます。
+ New itemを選択します。Mirrored Azure Monitorを選択します。- 新しいAzure Monitor接続を作成するか、既存接続を選びます。
- Log AnalyticsワークスペースIDを入力します。
- 認証方式を選択します。
- 認証を完了して接続します。
接続名は、対象環境と認証方式が分かる名称にしておくと管理しやすくなります。
例
azmon-prod-workspace-identity
azmon-dev-oauth
azmon-cross-tenant-spミラーリングするテーブルを選択する
接続に成功すると、Log Analyticsワークスペース内で利用可能なテーブルが一覧表示されます。
最初の検証では、対象を数テーブルに絞るのが安全です。
AppRequests
AppDependencies
AppExceptions
HeartbeatApplication Insightsのアプリケーション監視なら、要求、依存関係、例外を組み合わせて分析できます。仮想マシンやエージェントの接続状況を確認する場合は、Heartbeatが分かりやすい検証対象です。(Microsoft Learn)
パブリックプレビューでは、最近データが流れているテーブルだけが選択一覧に表示される場合があります。必要なテーブルが見つからない場合は、Log Analytics側で新しいレコードが取り込まれているか確認し、後からEdit data selectionで追加します。(Microsoft Learn)
1つのミラー項目で扱えるテーブル数は、プレビュー時点で約500テーブルです。大規模なワークスペースでは、用途や部門ごとに複数のミラー項目へ分割します。(Microsoft Learn)
内容を確認して作成する
接続、対象テーブル、項目名を確認し、Createを選択します。
ミラー項目自体はすぐにFabricワークスペースへ表示されますが、テーブルがEventhouseやLakehouseから利用可能になるまで、通常は約15分かかります。これは初期セットアップ時の目安であり、正式なサービスレベル保証ではありません。(Microsoft Learn)
Eventhouseエンドポイントで確認する
作成したミラー項目を開き、次のメニューからEventhouseエンドポイントへ移動します。
Analyze data with
→ Eventhouse endpointテーブルが表示されたら、まず最新時刻とレコード数を確認します。
AppRequests
| summarize
LatestRecord = max(TimeGenerated),
RecordCount = count()さらに、要求件数、失敗件数、95パーセンタイルの応答時間を確認する例は次のとおりです。
AppRequests
| where TimeGenerated >= ago(24h)
| summarize
RequestCount = count(),
FailureCount = countif(Success == false),
P95DurationMs = percentile(DurationMs, 95)
by bin(TimeGenerated, 15m)
| extend FailureRate =
iif(RequestCount == 0, 0.0, todouble(FailureCount) / RequestCount)
| order by TimeGenerated asc実際の列名や型はテーブルのスキーマに合わせて調整してください。Eventhouseからは、KQLクエリのほか、リアルタイムダッシュボードやActivatorによるしきい値通知も利用できます。(Microsoft Learn)
LakehouseへOneLakeショートカットを作成する
Power BIやSparkから使用する場合は、Lakehouseにショートカットを作成します。
- 同じFabricワークスペースでLakehouseを作成または開きます。
TablesからNew shortcutを選択します。Microsoft OneLakeを選択します。- 作成したMirrored Azure Monitor項目を選択します。
- 利用するテーブルを選択します。
- ショートカットを作成します。
作成後は、ミラーリングされたログがLakehouseのテーブル一覧にDelta Lakeテーブルとして表示されます。Sparkノートブックによる集計、Power BIセマンティックモデルとの接続、業務テーブルとの結合に利用できます。(Microsoft Learn)
Azure Monitor Logsと業務データを組み合わせる活用例
アプリケーション障害と売上への影響を調べる
AppRequestsやAppExceptionsと注文データを時刻単位で結合すれば、エラー率が増加した時間帯に、注文完了率や売上金額がどの程度低下したかを分析できます。
IT部門には「HTTPエラーが増えた」という情報でも、経営部門には「注文完了数が15％低下した」という形で示せます。障害の技術的な深刻度だけでなく、事業への影響を判断しやすくなります。(Microsoft Learn)
インフラ利用量とコストを比較する
仮想マシンやコンテナの使用状況を示すテレメトリと、請求・予算データを組み合わせれば、実際の利用量に対して支出が妥当かを確認できます。
単純な月額費用だけでなく、サービス単位、顧客単位、処理件数単位のコスト分析へ発展させられます。
長期的な傾向をSparkで分析する
Sparkでは、曜日や時間帯ごとの負荷傾向、障害発生前後の特徴、複数サービス間の依存関係などを大規模に分析できます。
ただし、パブリックプレビューでは過去データのバックフィルがありません。長期傾向分析を目的とする場合は、ミラーリング開始日以降のデータが十分に蓄積されるまで待つか、既存の履歴データを別経路でFabricへ取り込む必要があります。(Microsoft Learn)
Eventstreamとの使い分け
Microsoft Fabricには、Azureの診断ログやメトリックをEventstreamへストリーミングする方法もあります。ミラーリングとEventstreamは、目的が異なります。(Microsoft Learn)
| 比較項目 | Azure Monitor Logsミラーリング | Eventstream |
|---|---|---|
| 主な入力 | 既存のLog Analyticsテーブル | Azureリソースの診断ログやメトリックなど |
| データ移動 | Azure Monitor側のデータを参照 | イベントをストリームとして取り込む |
| 変換 | Fabricで参照後に分析・加工 | ストリーム途中で変換やルーティングが可能 |
| 適した用途 | 既存ログ資産の横断分析 | 到着イベントの即時処理や振り分け |
| 主な利用先 | Eventhouse、Lakehouse、Power BI、Spark | Eventhouseなどのストリーミング先 |
すでにLog Analyticsへ集約されているログを、複製せずFabricで使いたい場合はミラーリングが適しています。
一方、Azureリソースから届くイベントをリアルタイムにフィルタリングし、加工してから複数の宛先へ振り分けたい場合は、Eventstreamを検討します。
ミラーリングの料金とコスト構造
ミラーリングではストレージや同期パイプラインが追加されないため、ミラーリング自体による重複ストレージ料金やパイプライン料金は発生しないとされています。
ただし、Fabricでの分析が無料になるわけではありません。(Microsoft Learn)
| 課金対象 | 内容 |
|---|---|
| Azure Monitor | ログの取り込み、保持、Azure Monitor内でのクエリ |
| Microsoft Fabric | Eventhouse、Spark、Power BI更新などの計算処理 |
| 追加ストレージ | ミラーリングによる重複保存分は原則なし |
| データ転送 | リージョンをまたぐ構成ではネットワーク送信料金の可能性あり |
Eventhouseエンドポイント、Eventhouseショートカット、Lakehouseショートカットを経由したクエリは、Azure MonitorのクエリコンピューティングではなくFabric容量を使用します。
大量の分析クエリをAzure Monitor側で直接実行している環境では、処理をFabricへ移すことでAzure Monitorのクエリ負荷を抑えられる可能性があります。一方で、Fabric容量の消費量は別途監視する必要があります。(Microsoft Learn)
パブリックプレビューで特に注意すべき制約
過去データは自動的に取り込まれない
ミラーリング開始前にLog Analyticsへ保存されていたデータは、Fabricへバックフィルされません。
作成直後にテーブルは表示されても、設定後の新しいデータが到着するまでクエリ結果が0件になる場合があります。既存の30日分、90日分、1年分をすぐにPower BIで分析できるわけではありません。(Microsoft Learn)
Log Analytics側のアクセス制御は引き継がれない
Azure RBACとFabricワークスペースの権限は別々に管理されます。
Log Analytics側で特定ユーザーにテーブルへのアクセスを許可していなくても、FabricワークスペースやOneLake側で権限を持つユーザーは、ミラー項目を通じてデータを閲覧できる可能性があります。行レベル、列レベル、テーブルレベルの保護設定も、そのままミラー項目へ引き継がれるわけではありません。(Microsoft Learn)
そのため、ミラーリング設定前に次の点を確認します。
- Fabricワークスペースに誰が参加しているか
- 閲覧者、共同作成者、管理者の役割が適切か
- 個人情報や認証情報を含むテーブルがないか
- OneLake securityで必要な範囲だけを公開できているか
- 検証用と本番用のワークスペースが分離されているか
パブリックプレビューではミラー項目の共有機能にも既知の問題があるため、細かなアクセス制御にはOneLake securityを使用する方法が案内されています。(Microsoft Learn)
一部のシステム列は利用できない
プレビュー時点では、ミラーリングされたテーブルに次のシステム列が含まれません。
_ResourceId
_SubscriptionId
Type既存のKQLやPower BIモデルがこれらの列に依存している場合、そのままではエラーになります。代替となる列があるか確認するか、別のマスターテーブルと結合してリソース情報を補完します。(Microsoft Learn)
Fabricから書き戻すことはできない
ミラーリングされたログは読み取り専用です。
Fabricからレコードを更新したり、Log Analyticsへ結果を書き戻したりする用途には使えません。加工後の結果を保存したい場合は、LakehouseやEventhouseに別テーブルを作成します。(Microsoft Learn)
データ削除手順を事前に確認する
公式ドキュメントでは、ミラーリング開始後のデータを完全に消去する場合、Azure Monitor側とOneLake側で別々の削除処理が必要になると説明されています。
個人情報、機密情報、保存期限が厳密に定められたログを対象にする場合は、パブリックプレビュー環境へ接続する前に、削除手順とサポート体制を確認しておく必要があります。(Microsoft Learn)
テーブルが表示されないときの確認ポイント
Mirrored Azure Monitorカードがない
Fabric管理ポータルのテナント設定で、ミラー化されたカタログ項目が有効か確認します。
接続時に403エラーが発生する
接続に使用したIDに、Log Analyticsワークスペースの読み取り権限だけでなく、接続作成に必要なMicrosoft.Authorization/roleAssignments/writeがあるか確認します。
一部のテーブルしか表示されない
次の順番で確認します。
- Log Analyticsで対象テーブルが存在するか
- 最近のデータが取り込まれているか
- テーブル作成後にレコードが1件以上到着しているか
- 接続IDにワークスペースの読み取り権限があるか
- 検出やメタデータ同期の時間を置いたか
新しく作成したカスタムテーブルは、レコードが取り込まれるまで選択一覧に出ない場合があります。(Microsoft Learn)
テーブルは表示されるがデータが0件
ミラーリング開始前の履歴データを確認していないか調べます。
Log AnalyticsとFabricの両方で、TimeGeneratedの最大値を比較してください。初期構成後は約15分待ち、それでも新しいデータが表示されない場合は、1つのテーブルだけの問題か、すべてのテーブルに共通する問題かを切り分けます。(Microsoft Learn)
Lakehouseだけでエラーになる
ミラー項目やEventhouseでは正常に参照でき、Lakehouseだけでテーブルが展開できない場合は、Azure Monitorの問題ではなくOneLakeショートカット側の問題として調査します。
ショートカットの再作成、対象テーブルの状態、Deltaメタデータの解決状況を確認します。(Microsoft Learn)
実務では小規模な検証から始める
最初からワークスペース内の全テーブルを選択するより、業務価値を確認できる少数のテーブルから始める方が安全です。
推奨する検証手順は次のとおりです。
- 専用の検証用Fabricワークスペースを作成する
- 同一テナントではWorkspace identityを基本に設計する
AppRequests、AppDependencies、AppExceptionsなど数テーブルを選ぶ- 設定後に新しいログを発生させる
- Eventhouseで到着時刻と件数を確認する
- Lakehouseへショートカットを作成する
- Power BIまたはSparkで業務データと結合する
- Fabric容量、鮮度、アクセス権、削除手順を評価する
Azure Monitor LogsのFabric OneLakeミラーリングは、ログの保存場所を増やす機能ではなく、既存のテレメトリを業務データと同じ分析基盤へ開放する機能です。
導入判断では、「ログをFabricで見られるか」だけでなく、「どの業務判断に結び付けるか」を先に決めることが重要です。まずは障害件数と売上、応答時間と注文完了率、リソース利用量とコストなど、効果を説明しやすい1つの分析テーマから検証を始めてください。
コメント