Microsoft Fabricの「Reliability in Microsoft Fabric」で重要なのは、Fabricがすべてのデータ・設定・処理を自動的に完全復旧してくれるわけではないという点です。可用性ゾーンによるリージョン内の保護、OneLakeデータのリージョン間レプリケーション、Power BIのBCDR、障害時の手動復旧手順を組み合わせて、管理者と開発者があらかじめ復旧設計を作る必要があります。
特に確認すべきなのは、ホームリージョン、容量リージョン、DR容量設定、OneLake外のデータ、Notebook・Pipeline・KQL Databaseなどの復旧方法です。この記事では、2026年5月時点の公式情報をもとに、Microsoft Fabricの信頼性設計で何が変わるのか、どの範囲に影響するのか、管理者・開発者が今すぐ確認すべきポイントを実務目線で整理します。
Microsoft Fabricの「Reliability in Microsoft Fabric」で押さえるべき結論
Reliability in Microsoft Fabricは、Microsoft Fabricの信頼性を「可用性ゾーン」「リージョン間のディザスターリカバリー」「事業継続」の観点で整理した公式ガイダンスです。Fabricでは、Azure Availability Zonesを使ってFabricとPower BIの項目・データをデータセンター障害から保護し、Fabricリソースは顧客側の追加設定なしで複数ゾーンに自動分散されます。(Microsoft Learn)
ただし、ここでいう信頼性は「何もしなくても全ワークロードが復旧する」という意味ではありません。OneLakeに保存されたLakehouseやWarehouseのデータはDR容量設定の対象になりますが、OneLake外のデータ、KQL Database、Notebookのコード、Pipelineの設定、Dataflow Gen2のテンプレート、ML実験のメタデータなどは、別途バックアップや再作成手順を用意する必要があります。(Microsoft Learn)
実務上の結論は、次の3点です。
| 観点 | 管理者・開発者が取るべき対応 |
|---|---|
| 可用性ゾーン | Fabric側は自動対応。ただしADLS Gen2など外部データソースはZRS設定を確認する |
| リージョン間DR | 容量単位のDR設定、OneLake geo-replication状態、リージョンペア対応を確認する |
| 復旧手順 | 新しい容量・ワークスペース・項目の再作成、Gitやスクリプトによる復元手順を準備する |
2026年5月19日の更新で何が変わったのか
MicrosoftDocsのGitHub履歴では、reliability-fabric.mdに対して2026年5月19日に2件の更新が確認できます。内容としては主にPower BIのBCDR説明に関連する参照リンクの修正です。大きな機能追加というより、公式ガイダンスの記述を正確に保つためのメンテナンス更新と見るのが適切です。(GitHub)
実務上、より重要なのは直前の2026年5月13日の更新です。この更新では、Power BIのBCDRが「常に無条件で既定提供される」という表現ではなく、Power BIをサポートするリージョンとペアになっている場合に既定で含まれるという条件が明確化されています。(GitHub)
つまり、今回確認すべき変更点は「新しいスイッチをオンにすればよい」という単純な話ではありません。自社のホームリージョンと容量リージョンが、FabricおよびPower BIのDR条件を満たしているかを確認することが最も重要です。
対象者は管理者だけではない
Reliability in Microsoft Fabricの対象者は、Fabric管理者やPower BI管理者だけではありません。データ基盤を構築する開発者、BIレポートを運用する担当者、セキュリティ・コンプライアンス担当者にも影響します。
| 対象者 | 確認すべきこと |
|---|---|
| Fabric管理者 | ホームリージョン、容量リージョン、DR容量設定、容量管理者権限、コスト監視 |
| Power BI管理者 | フェールオーバー時の読み取り専用動作、更新停止、オンプレミスゲートウェイの可用性 |
| データエンジニア | Lakehouse、Warehouse、Notebook、Spark Job Definitionの復旧方法 |
| データサイエンティスト | Notebook、ML Model、Experimentのコード・メタデータ保全 |
| アプリ開発者 | Warehouse接続文字列、OneLake API経由のアクセス、再デプロイ手順 |
| セキュリティ担当者 | Multi-Geo時に残るホームリージョンのメタデータ、データ所在地、権限管理 |
特に開発者は「Fabricのデータが複製されるならコードや設定も戻る」と誤解しがちです。公式ガイダンスでは、Notebookのコードはセカンダリリージョンへ複製されず、Git連携や手動バックアップが推奨されています。(Microsoft Learn)
可用性ゾーンで守られる範囲と、守られない範囲
FabricはAzure Availability Zonesを利用し、リージョン内のデータセンター障害に備えます。ゾーン全体の障害が発生しても、Fabric機能は正常なゾーンを使って自動的に自己修復・再調整され、通常は顧客側の操作は不要です。(Microsoft Learn)
ただし、進行中の処理は例外です。たとえばSpark Jobのマスターノードが障害ゾーンにある場合、実行中のSpark Jobが失敗し、再送信が必要になる可能性があります。また、Data WarehouseやSQL Analytics Endpointのクエリも、フロントエンドノードの影響で失敗する場合があり、その場合は安全に再実行する必要があります。(Microsoft Learn)
外部データソースはFabric任せにしない
Data EngineeringではOneLakeを使う場合に可用性ゾーンがサポートされます。一方、ADLS Gen2などの外部データソースを使っている場合は、Fabric側ではなく、そのストレージ側でZone-redundant storage、つまりZRSが有効かを確認する必要があります。(Microsoft Learn)
実務では、次のように切り分けて確認します。
| データの場所 | 確認ポイント |
|---|---|
| OneLake | Fabricの可用性ゾーン、DR容量設定、OneLake Geo-replication状態 |
| ADLS Gen2 | ストレージアカウントの冗長性がZRSまたは要件に合う構成か |
| オンプレミスDB | ゲートウェイ、バックアップ、別リージョン・別環境への復旧手順 |
| 外部SaaS | FabricではなくSaaS側のSLA、エクスポート、代替接続方法 |
「Fabricで使っているデータだからFabricのDR対象」と考えるのは危険です。DR対象は、どこに保存されているデータかで判断します。
リージョン間ディザスターリカバリーの中心はOneLakeデータ
FabricのDR容量設定を有効にすると、OneLakeデータのリージョン間レプリケーションが有効になります。対象はLakehouseやWarehouseなどのOneLakeデータで、容量レベルで設定します。利用できるのは容量管理者以上のロールを持つユーザーで、Premium容量とFabric容量の両方が対象です。(Microsoft Learn)
一方で、このDRスイッチはOneLake外のデータには影響しません。また、Power BIのBCDRはこのスイッチのオン・オフに関係なくサポートされますが、リージョンペアやPower BI対応リージョンなどの条件を確認する必要があります。(Microsoft Learn)
DR容量設定で確認すべき項目
| 項目 | 確認内容 |
|---|---|
| 権限 | 容量管理者以上のロールを持つユーザーが操作する |
| 設定単位 | テナント全体ではなく容量単位で確認する |
| 対象データ | Lakehouse、Warehouseを含むOneLakeデータが中心 |
| 対象外 | OneLake外のデータ、外部ストレージ、外部DB、各種設定・コード |
| 変更頻度 | DR容量設定を変更すると、再変更まで30日待つ必要がある |
| 状態確認 | 容量設定ページのOneLake Geo-replication列で確認する |
DR設定を有効にした直後や、新しいワークスペースを容量に作成した直後は、データレプリケーションの開始まで時間がかかる場合があります。運用開始前に、各ワークスペースのOneLake Geo-replication状態を必ず確認してください。(Microsoft Learn)
日本リージョン利用者が特に注意すべき点
OneLakeの公式ガイダンスでは、East US 2、Japan East、Japan WestでDR有効化時に問題が発生する可能性があるため、容量設定でWorkspaces assigned to this capacityを開き、OneLake Geo-replication列の状態を確認するよう案内されています。日本の利用者にとっては、Japan EastとJapan Westが明記されている点を見落とさないでください。(Microsoft Learn)
これは「日本リージョンが使えない」という意味ではありません。重要なのは、DRを有効化したつもりで終わらせず、ワークスペース単位でレプリケーション状態を確認することです。特に本番ワークロードでは、設定変更後に次の確認を行います。
| 確認タイミング | 確認内容 |
|---|---|
| DR設定を有効化した直後 | OneLake Geo-replicationが開始されているか |
| 新しいワークスペース作成後 | 対象容量に割り当てられ、レプリケーション対象になっているか |
| 本番移行前 | 重要なLakehouse・Warehouseのデータが対象に含まれているか |
| 定期監査時 | 無効化、容量移動、リージョン変更により保護対象から外れていないか |
フェールオーバー時にできること・できないこと
大規模障害でプライマリリージョンが回復不能になった場合、Microsoft Fabricはリージョンフェールオーバーを開始します。フェールオーバー完了までFabricポータルにはアクセスできず、完了後は読み取り中心の動作になります。公式情報では、フェールオーバー完了までの時間は状況により異なるものの、通常は1時間未満とされています。(Microsoft Learn)
フェールオーバー後の代表的な動作は次のとおりです。
| 項目 | フェールオーバー後の動作 |
|---|---|
| Fabricポータル | 既存ワークスペースや項目の閲覧など読み取り操作は可能。作成・変更など書き込み操作は停止 |
| Power BI | レポートやダッシュボード表示は可能。更新、発行、編集、メタデータ変更は不可 |
| Lakehouse / Warehouse | 項目自体は開けないが、OneLake APIやツール経由でファイルにアクセス可能 |
| Spark Job Definition | 項目は開けないが、コードファイルはOneLake APIやツール経由でアクセス可能 |
| Notebook | 開けない。コードコンテンツは障害後に保存されない |
| ML Model / Experiment | 開けない。コード、実行メトリック、構成などのメタデータは保存されない |
| Dataflow Gen2 / Pipeline / Eventstream | 項目は開けない。復旧先としてLakehouseやWarehouseを使う設計が必要 |
| KQL Database / Queryset | フェールオーバー後にアクセスできない。別途DR手順が必要 |
この表から分かるように、FabricのDRは「業務を完全に通常運転し続ける仕組み」というより、データを失わず、復旧作業に進むための土台です。業務継続要件が厳しいシステムでは、平常時から別リージョンに容量・ワークスペース・デプロイ手順を用意する設計が必要です。
OneLakeのデータ保護で知っておきたいポイント
OneLakeは、利用可能な場所ではZRSを使い、それ以外ではLRSを使います。ZRSはプライマリリージョン内の3つの可用性ゾーンに同期コピーすることでデータセンター障害への耐性を高めます。一方、LRSは単一データセンター内の冗長化であり、データセンター災害への保護としてはZRSより範囲が限定されます。(Microsoft Learn)
また、OneLakeのDRでは、セカンダリリージョンへのレプリケーションは非同期です。そのため、障害発生時点でセカンダリリージョンへコピーされていなかったデータは失われる可能性があります。フェールオーバー後の新しいプライマリデータセンターは、当初はローカル冗長のみになります。(Microsoft Learn)
削除ミス対策としてのソフトデリート
OneLakeには、削除されたファイルを完全削除前に7日間保持するソフトデリート機能があります。これはリージョン災害対策というより、誤削除やユーザー操作ミスからの復旧に役立つ保護です。(Microsoft Learn)
DRとソフトデリートは目的が異なります。
| 仕組み | 主な目的 |
|---|---|
| 可用性ゾーン / ZRS | データセンター障害への耐性 |
| リージョン間DR | リージョン規模の障害への備え |
| ソフトデリート | 誤削除・操作ミスからの短期復旧 |
| Git / スクリプト管理 | コード・設定・定義の再作成 |
ホームリージョンと容量リージョンを混同しない
FabricのDR計画では、ホームリージョンと容量リージョンの関係を正しく理解する必要があります。Fabricのホームリージョンはテナントに紐づくAzureデータセンターリージョンであり、ワークロードと機能の可用性、データ所在地、パフォーマンス、コンプライアンスを判断するうえで重要です。(Microsoft Learn)
Fabric上では、ヘルプウィンドウから「バージョン情報」を開き、「データの保存先」に表示される値で既定のデータ保存リージョンを確認できます。ただし、ワークスペースが異なるリージョンの容量を使っている場合もあります。(Microsoft Learn)
Multi-Geoを使っても全データが移動するわけではない
Multi-Geoは、ホームリージョン以外のリージョンにコンテンツを展開し、データ所在地要件に対応するための機能です。ただし、別リージョンの容量を選んでも、すべてのデータが完全にそのリージョンへ移動するわけではありません。権限、セマンティックモデル資格情報、レポート・ダッシュボードのメタデータ、Purview Data Mapに関連するメタデータなど、一部のテナントメタデータはホームリージョンに残ります。(Microsoft Learn)
また、非Power BIのFabric項目を含むワークスペースはリージョン間で移動できません。移動するには、非Power BI Fabric項目を削除する必要があり、移動後に再作成できるようになるまで時間がかかる場合があります。(Microsoft Learn)
管理者が今すぐ確認すべき設定
Fabric管理者は、まず「どの容量が、どのリージョンで、どのワークスペースを保護しているか」を棚卸しします。容量設定ページでは、DR設定、容量管理者、割り当てワークスペース、容量メトリックなどを確認できます。(Microsoft Learn)
| 確認項目 | 実務での見方 |
|---|---|
| ホームリージョン | テナントの既定データ保存先を確認する |
| 容量リージョン | 本番容量がFabric対応リージョンにあるか確認する |
| リージョンペア | DRやPower BI BCDRの前提を満たすか確認する |
| DR容量設定 | 重要容量で有効になっているか確認する |
| OneLake Geo-replication | ワークスペース単位の状態を確認する |
| 外部データ | ADLS Gen2、オンプレミスDB、外部SaaSの保護方法を別途確認する |
| 容量管理者 | DR設定を変更できる管理者を最小権限で割り当てる |
| コスト | BCDR Storage、BCDR Operationsの増加を監視する |
DR機能は追加のストレージとトランザクションを消費し、BCDR StorageとBCDR Operationsとして課金されます。これらはMicrosoft Fabric Capacity Metrics appで個別項目として確認できます。(Microsoft Learn)
開発者が準備すべき復旧設計
開発者にとって重要なのは、データだけでなく、コード・定義・接続・権限を復旧できる状態にすることです。Fabricのワークロードは画面操作で簡単に作成できるため、開発初期はGitやスクリプト管理が後回しになりがちです。しかし、DRの観点ではそれが最大のリスクになります。
Lakehouse
Lakehouseは、障害後に新しいワークスペース上で再作成し、OneLakeパスやAzure Storage Explorer、カスタムスクリプトを使ってDeltaテーブルやファイルをコピーして復旧します。Delta形式のテーブルはデータとメタデータがOneLake内に共存するため復旧しやすい一方、CSVやParquetなどをSpark DDLで作成している場合は、DDLスクリプトの保管と再実行が必要です。(Microsoft Learn)
Notebook
Notebookのコードはセカンダリリージョンへ複製されません。最も実用的な対策は、Fabric Git integrationを使ってAzure DevOpsリポジトリと同期し、障害後に新しいワークスペースで再同期することです。Notebook Resource Explorer内のファイルやスナップショットはGit同期対象外のため、別途保存が必要です。(Microsoft Learn)
Warehouse
Warehouseは、復旧先で新しいWarehouseを作成し、Lakehouseを経由してDeltaテーブルからT-SQLでデータを投入する流れが想定されています。スキーマ、テーブル、ビュー、ストアドプロシージャ、関数、セキュリティ関連コードは、Gitなど安全な場所でバージョン管理しておくべきです。(Microsoft Learn)
Dataflow Gen2とPipeline
Dataflow Gen2は、Power QueryテンプレートとしてPQTファイルをエクスポートし、Gitなどに保存しておくと復旧しやすくなります。Pipelineは構成がペアリージョンに複製されないため、重要なPipelineは複数リージョンのワークスペースに構築することが推奨されています。(Microsoft Learn)
KQL Database / Queryset
KQL DatabaseとQuerysetはOneLake外に保存されるため、OneLakeのDRだけでは保護できません。公式ガイダンスでは、複数リージョンの専用Fabric容量上に独立したKQL Databaseを構成し、テーブル、マッピング、ポリシー、権限、データ取り込みを並行して維持する考え方が示されています。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
Reliability in Microsoft Fabricを確認するタイミングは、障害対策だけではありません。容量移行、リージョン変更、Multi-Geo展開、本番移行でも同じ論点が出ます。
| よくある失敗 | 回避策 |
|---|---|
| 容量を別リージョンに作れば全データが移動したと思い込む | ホームリージョンに残るメタデータを確認する |
| DR設定をオンにして確認を終える | OneLake Geo-replication列でワークスペース単位の状態を確認する |
| NotebookやPipelineを画面上だけで管理する | Git、PQT、DDL、接続設定一覧を残す |
| 容量移行中に元容量を削除・停止する | 移行完了までソース・宛先容量を削除または一時停止しない |
| 大容量セマンティックモデルを別リージョンへ移動する | 元リージョン依存の制約を確認し、必要なら新規デプロイとして扱う |
| フェールオーバー時も更新処理が続くと思い込む | Power BIの更新・発行・編集が停止する前提で運用手順を作る |
Multi-Geoの公式ガイダンスでは、同一リージョン内でワークスペースを別容量へ移動する場合でも、移行中に新しいセマンティックモデルの発行やスケジュール更新など一部操作が失敗する可能性があると説明されています。また、移行中にソースまたは宛先容量を削除・一時停止すると、項目が欠落する可能性があります。(Microsoft Learn)
Power BI利用者が確認すべきこと
Power BIはFabricの一部としてBCDRの仕組みを持ちますが、フェールオーバー時は読み取り中心の動作になります。リージョンペアがある場合、Power BIはバックアップインスタンスにフェールオーバーしますが、失敗後のPower BIサービスインスタンスでは更新、発行、レポートやダッシュボードの変更、コメント挿入などメタデータ変更を伴う操作はサポートされません。(Microsoft Learn)
Power BIのバックアップインスタンスは定期的に同期され、アップロードまたは変更されたコンテンツについて15分を目標とするポイントインタイム同期が示されています。ただし、これは実務上「最大15分まで必ず戻せる」という保証として扱うのではなく、RPO設計の参考値として確認するのが安全です。(Microsoft Learn)
オンプレミスデータソースをDirectQueryやLive Connectで使っている場合、フェールオーバー時にゲートウェイが機能しないため、対象レポートやダッシュボードは動作しない可能性があります。ゲートウェイ構成の高可用性、代替データソース、障害時の利用停止案内を準備しておきましょう。(Microsoft Learn)
実務で使える確認チェックリスト
本番環境でMicrosoft Fabricを使っている場合は、次のチェックリストを定期的に確認してください。
| チェック | 確認内容 |
|---|---|
| ホームリージョンを確認した | Fabricの「バージョン情報」でデータの保存先を確認した |
| 容量リージョンを確認した | 本番容量がFabric対応リージョンにあるか確認した |
| リージョンペアを確認した | FabricとPower BIのDR条件を満たすか確認した |
| DR容量設定を確認した | 重要な容量でDR設定が有効か確認した |
| OneLake Geo-replicationを確認した | ワークスペース単位で状態を確認した |
| 外部データのDRを確認した | ADLS Gen2、オンプレミスDB、外部SaaSを別途保護した |
| コードをGit管理した | Notebook、Warehouse定義、Pipeline相当の構成を管理した |
| Dataflow Gen2をエクスポートした | PQTファイルを安全な場所に保存した |
| KQLの二重化を検討した | 必要に応じて複数リージョンに独立構成を用意した |
| 復旧手順を文書化した | 新容量、ワークスペース、項目、接続、権限の再作成手順を用意した |
| コストを監視した | Capacity Metrics appでBCDR StorageとBCDR Operationsを確認した |
| 関係者に制限を共有した | 障害時は読み取り専用や項目利用不可になることを共有した |
まず何から対応すべきか
最初に行うべきことは、DR設定を急いで変更することではありません。まず、現在のFabric環境を棚卸しして、どのデータ・項目・設定がどの保護に依存しているかを明確にします。
優先順位は次の順番がおすすめです。
| 優先度 | 対応 |
|---|---|
| 高 | ホームリージョン、容量リージョン、Fabric対応リージョン、リージョンペアを確認する |
| 高 | 重要なLakehouse・WarehouseがDR容量設定の対象になっているか確認する |
| 高 | OneLake外のデータ、KQL、Notebook、Pipeline、Dataflow Gen2の保護方法を決める |
| 中 | Git連携、PQTエクスポート、DDL管理、接続文字列の再設定手順を整備する |
| 中 | Capacity Metrics appでBCDR関連コストを監視する |
| 中 | 障害時の読み取り専用運用、ユーザー通知、復旧担当者を決める |
| 低 | 机上演習や小規模な復旧テストを行い、手順の抜けを修正する |
Microsoft Fabricの信頼性を高めるには、公式機能を理解するだけでは不十分です。どのデータがOneLakeにあり、どの設定が複製されず、誰がどの順番で復旧するのかまで決めておく必要があります。
Reliability in Microsoft Fabricの更新は、Fabric運用を「作って終わり」から「止まる前提で設計する」段階へ進める合図です。まずは本番容量のDR設定とOneLake Geo-replication状態を確認し、次にNotebook・Warehouse・Pipeline・KQL Databaseの復旧手順をGitやスクリプトで管理してください。
コメント