Microsoft FabricでSnowflake、Databricks、Google BigQuery、Salesforceなど複数クラウドのデータを扱っている場合、今回確認すべきポイントは「新しい個別機能の追加」よりも、Fabric Data Factoryをマルチクラウド連携の中核として使う設計パターンがGA扱いで整理されたことです。すぐに既存環境が壊れる変更ではありませんが、接続設定、認証、パイプラインの再試行、トリガー、OneLakeへの取り込み方を見直すきっかけになります。
2026年6月に公開・更新された「Multi-cloud data architecture patterns using Fabric Data Factory」は、Fabric Data Factoryで複数クラウドのデータソースをつなぎ、パイプライン、Copy job、ショートカット、ミラーリング、Microsoft Purviewによる系譜管理を組み合わせる考え方を示したものです。Microsoft Fabricの「What’s New」でも、Data Factoryのマルチクラウド設計パターンとしてGA分類で掲載されています。(Microsoft Learn)
Multi-cloud data architecture patterns using Fabric Data Factory は何が変わった？影響範囲と確認ポイント
今回の変更点は、Fabric Data Factoryを「Azure内のデータ移動ツール」としてだけでなく、Snowflake、Databricks、Google BigQuery、Salesforceなどをまたぐマルチクラウドデータ基盤のオーケストレーション層として位置付けている点です。
Microsoft Fabric Blogでは、Fabric Data FactoryがSnowflake、Databricks、Google BigQuery、Salesforceなど主要なクラウドデータ基盤やSaaSと接続し、パイプラインから抽出、ロード、Notebook実行、SFTP連携などをまとめて設計できると説明しています。([Microsoft Fabric Community][2])
特に重要なのは、次の3点です。
| 確認項目 | 変更の意味 | すぐ確認すべきこと |
|---|---|---|
| GA分類で整理された | マルチクラウド連携パターンを本番利用の設計候補として検討しやすくなった | 既存のETL/ELT構成をFabric Data Factoryへ集約できるか確認する |
| 複数クラウドの接続が前提になった | Snowflake、BigQuery、Databricksなどを個別ツールでつなぐ構成から、Fabric中心の設計へ寄せられる | 接続先ごとの認証方式、権限、転送量、リージョンを棚卸しする |
| OneLake、ショートカット、ミラーリングとの組み合わせが明確化 | データを必ずコピーする設計だけでなく、ゼロコピーや近リアルタイム連携も選択肢になる | 「移動するデータ」と「参照するだけのデータ」を分けて設計する |
ここで注意したいのは、GAといっても「関連するすべての周辺機能が無条件でGA」という意味ではないことです。コネクタ、認証方式、Copy job、ミラーリング、ショートカットなどは機能ごとに対応範囲や制約が異なります。導入前には、利用する接続先ごとにMicrosoft Learnのコネクタ対応表を確認する必要があります。
何ができるようになるのか
Fabric Data Factoryでは、データ移動、データ変換、制御フローをパイプラインとしてまとめられます。Microsoft Learnでは、Copy dataやCopy jobのようなデータ移動、Dataflow Gen2やNotebookなどの変換、If condition、ForEach、Untilなどの制御フローがData Factoryの活動として整理されています。(Microsoft Learn)
今回のマルチクラウド設計パターンで想定される代表的な構成は、次のようなものです。
BigQueryから取り込み、Databricksで処理し、Snowflakeへ連携する
たとえば、マーケティングデータをGoogle BigQueryに保持し、機械学習や大規模変換をDatabricks Notebookで実行し、集計結果をSnowflakeに格納して既存BIで使う構成です。
従来は各サービスごとにジョブスケジューラ、認証、ログ監視を別々に管理しがちでした。Fabric Data Factoryを使うと、パイプライン上で依存関係を管理し、失敗時の再試行や分岐処理もまとめやすくなります。
SalesforceのデータをSFTPやLakehouseへ連携する
営業や顧客管理データがSalesforceにあり、基幹システムや外部ベンダーとの連携でSFTPを使っている企業では、Salesforceからの抽出、ファイル配置、Lakehouseへの格納を同じスケジュールで制御できます。
この場合は、Salesforce側のAPI制限、SFTP側の接続方式、Fabric側の権限を分けて確認することが重要です。
OneLakeショートカットでコピーせずに参照する
すべてのデータをFabricへ物理コピーする必要はありません。Fabric Blogでは、OneLakeのショートカットを使うことで、Snowflake、S3、Google Cloud Storage上のデータを実際に移動せず分析できるパターンにも触れています。([Microsoft Fabric Community][2])
ただし、ゼロコピーは「コストが必ず下がる」という単純な話ではありません。参照先クラウドの読み取り課金、ネットワーク、権限管理、性能要件によって最適解が変わります。頻繁に使う集計済みデータはOneLakeやLakehouseに取り込み、低頻度の参照データはショートカットにする、といった使い分けが現実的です。
影響を受けやすい利用者
今回の内容は、すべてのMicrosoft Fabric利用者に同じ影響があるわけではありません。特に確認が必要なのは、次のような環境です。
| 対象者・環境 | 影響度 | 確認ポイント |
|---|---|---|
| Snowflake、BigQuery、Databricksを併用している企業 | 高 | データ移動ジョブをFabric Data Factoryに集約できるか |
| Azure Data FactoryやSynapse PipelineからFabricへ移行中のチーム | 高 | 既存パイプラインの再設計範囲、接続マッピング、運用監視 |
| SalesforceなどSaaSデータをFabricへ取り込む部門 | 中 | API制限、増分取得、認証情報の管理 |
| Power BI中心でFabricを使っている部門 | 中 | OneLakeやLakehouseに置くデータの整理 |
| 単一のAzure SQLやExcel取り込みだけの小規模利用者 | 低 | すぐの変更は少ないが、将来の拡張候補として把握 |
特にデータ基盤担当者は、単に「Fabric Data Factoryで接続できるか」だけで判断しないほうが安全です。実務では、接続可否よりも、誰の資格情報で動くのか、失敗時にどこまで自動復旧するのか、監査ログやデータ系譜を追えるのかが運用品質を左右します。
まず確認したい設定と運用項目
Microsoft Fabric利用者が最初に見るべき場所は、既存パイプラインそのものではなく、接続、認証、監視、コストの4つです。
接続先ごとの対応範囲を確認する
Microsoft Learnのコネクタ一覧では、Dataflow Gen2、PipelineのCopy activity、Copy jobごとにサポートされる接続先が整理されています。Snowflake、Google BigQuery、Salesforce objects、SFTP、Google Cloud Storageなども一覧に含まれていますが、対応する機能は接続先ごとに異なります。(Microsoft Learn)
たとえば、ある接続先ではDataflow Gen2のソースとして使えても、Copy jobの宛先としては使えない場合があります。画面で接続できることだけを確認して本番設計を進めると、後で「増分コピーにしたいのに対応していない」「宛先として使えない」といった手戻りが起きます。
確認時は、次のように整理すると実務で使いやすくなります。
| 確認する項目 | 見るべき内容 |
|---|---|
| ソース対応 | そのサービスから読み取れるか |
| 宛先対応 | そのサービスへ書き込めるか |
| 利用できる方式 | Dataflow Gen2、Pipeline、Copy jobのどれで使うか |
| 認証方式 | ユーザー認証、サービスプリンシパル、キー、OAuthなど |
| 本番制約 | API制限、同時実行、データ型、ネットワーク要件 |
認証情報を個人アカウントに依存させない
マルチクラウド連携では、接続先が増えるほど認証情報の管理が複雑になります。個人ユーザーの資格情報でパイプラインを動かしていると、担当者の異動、退職、MFA変更、パスワード更新で処理が止まる可能性があります。
本番運用では、可能な範囲でワークスペースID、サービスプリンシパル、管理された接続を使い、接続ごとに所有者と更新手順を明確にしておくべきです。
特に確認したいのは次の3点です。
| 項目 | 確認内容 |
|---|---|
| 接続の所有者 | 個人ではなく運用管理用の主体になっているか |
| 権限の範囲 | 読み取りだけでよい接続に書き込み権限を与えていないか |
| 資格情報の更新手順 | 期限切れやローテーション時に誰が対応するか |
パイプラインの再試行とタイムアウトを見直す
マルチクラウド連携では、ネットワーク遅延、一時的なAPI制限、外部サービス側のメンテナンスが原因でジョブが失敗することがあります。Fabric Data Factoryの活動には、タイムアウト、再試行回数、再試行間隔、セキュア入力・出力などの設定があります。Microsoft Learnでは、既定のタイムアウトや再試行設定、Secure input/outputなどの一般設定が説明されています。(Microsoft Learn)
運用上は、すべての失敗を同じ扱いにしないことが重要です。たとえば、429のようなレート制限や一時的なネットワークエラーは再試行で回復する可能性があります。一方、認証エラーや権限不足は何度再試行しても失敗するため、早く検知して通知したほうがよいケースが多いです。
推奨される考え方
| エラーの種類 | 対応方針 |
|---|---|
| 一時的なネットワーク障害 | 再試行を設定する |
| APIレート制限 | 再試行間隔を長めにする |
| 認証エラー | 再試行よりも通知を優先する |
| スキーマ変更 | 取り込み前の検証処理を追加する |
| データ欠損 | 後続処理を止める条件分岐を入れる |
既存環境で確認すべきチェックリスト
すでにMicrosoft Fabric Data Factoryを使っている場合は、次の順で確認すると短時間で影響範囲を把握できます。
接続とパイプラインの棚卸し
まず、Fabricワークスペース内のData Factoryパイプライン、Copy job、Dataflow Gen2を一覧化します。次に、Snowflake、Databricks、Google BigQuery、Salesforce、SFTP、Amazon S3、Google Cloud Storageなど、外部クラウドやSaaSへ接続しているものを抜き出します。
この時点では細かい修正に入らず、次の情報だけをまとめるのがコツです。
| 棚卸し項目 | 例 |
|---|---|
| パイプライン名 | salesforce-to-lakehouse |
| 接続元 | Salesforce objects |
| 接続先 | Fabric Lakehouse |
| 実行頻度 | 1時間ごと、毎日深夜など |
| 認証方式 | OAuth、サービスプリンシパルなど |
| 失敗時の通知先 | Teams、メール、監視ツール |
| 業務影響 | レポート更新、AIモデル学習、外部連携など |
データ移動かゼロコピーかを分ける
すべてをCopy jobで移動する構成にすると、ストレージ費用や転送コストが増えます。一方で、すべてをショートカットや外部参照に寄せると、性能、可用性、権限管理が接続先に依存します。
判断基準は次のようにすると分かりやすくなります。
| 判断軸 | データをFabricへ取り込むべきケース | ショートカットや外部参照を検討するケース |
|---|---|---|
| 利用頻度 | 毎日・毎時使う | たまに参照する |
| 性能要件 | Power BIやAIで高速に使いたい | 遅延が許容できる |
| ガバナンス | Fabric内で統一管理したい | 元システム側の管理を維持したい |
| コスト | 外部読み取り課金を抑えたい | コピーや重複保管を避けたい |
| 障害影響 | 元システム停止時も分析したい | 元システム停止時は利用不可でもよい |
トリガーとスケジュールを見直す
マルチクラウド構成では、毎時バッチを増やすだけでは無駄な実行が増えます。Fabric Data Factoryでは、イベントベースのトリガーや条件分岐を組み合わせることで、ファイル到着やデータ更新を起点に処理を開始する設計も可能です。Fabric Blogでも、LakehouseやBlob Storageへのファイル到着をきっかけに処理を開始するイベントベースのトリガーが例示されています。([Microsoft Fabric Community][2])
ただし、イベント駆動にすれば必ず運用が楽になるわけではありません。ファイルが分割到着する、外部システムの更新順序が保証されない、深夜に大量イベントが集中する、といったケースでは、イベント駆動と定期バッチを組み合わせるほうが安定します。
導入時に失敗しやすいポイント
接続できることだけを成功条件にしてしまう
PoCでは接続できたのに、本番ではデータ量、API制限、権限、ネットワーク、スキーマ変更で失敗することがあります。マルチクラウド連携では、最初の成功よりも、毎日失敗せずに動くことのほうが重要です。
本番化前には、少なくとも次のテストを行ってください。
- 最大データ量に近い状態でコピー時間を測る
- 接続先のAPI制限に近づいた場合の挙動を確認する
- 認証情報をローテーションした場合の復旧手順を確認する
- スキーマ変更時に後続処理がどう失敗するか確認する
- 失敗通知が運用担当者に届くか確認する
すべてをFabricへ集約しようとする
Fabric Data Factoryはマルチクラウド連携の中心にできますが、既存のDatabricksジョブ、Snowflakeタスク、SaaS側のエクスポート機能をすべて置き換える必要はありません。
現実的には、次のような分担が向いています。
| 処理内容 | 向いている場所 |
|---|---|
| 複数システムの依存関係管理 | Fabric Data Factory |
| 大規模なSpark変換 | DatabricksまたはFabric Notebook |
| Fabric内の分析用データ管理 | Lakehouse、Warehouse、OneLake |
| 既存DWH内のSQL変換 | SnowflakeやFabric Warehouse |
| レポート・AI活用 | Power BI、FabricのAI関連機能 |
重要なのは、ツールを1つに寄せることではなく、運用責任とデータの流れを1枚の設計図で説明できる状態にすることです。
コスト見積もりを後回しにする
マルチクラウド構成では、Fabric側の容量だけでなく、外部クラウド側の読み取り、書き込み、データ転送、API呼び出し、DWHのコンピュート費用が発生します。
特に注意したいのは、同じデータを何度も読み直す設計です。毎回BigQueryやSnowflakeから全件取得するより、初回のみ全件コピーし、その後は増分連携にするほうが適している場合があります。逆に、月に数回しか参照しないデータなら、物理コピーよりショートカットや外部参照のほうが合理的な場合もあります。
管理者が今すぐやるべきこと
今回のGA分類を受けて、Microsoft Fabric管理者やデータ基盤担当者は、まず既存の構成を壊さずに確認できる範囲から着手するのが安全です。
最初の一歩は、次の5つです。
| 優先度 | やること | 目的 |
|---|---|---|
| 高 | 外部クラウド接続を一覧化する | 影響範囲を把握する |
| 高 | 認証方式と接続所有者を確認する | 個人依存や期限切れを防ぐ |
| 高 | パイプラインの再試行、タイムアウト、通知を確認する | 障害時の復旧性を高める |
| 中 | データ移動とゼロコピーの使い分けを決める | コストと性能のバランスを取る |
| 中 | Purviewや系譜管理の確認範囲を決める | AI・BI活用時の説明責任を確保する |
小さく始めるなら、最も業務影響が大きい1本のパイプラインを選び、接続、認証、再試行、監視、コストを点検してください。その結果をテンプレート化すれば、他のパイプラインにも横展開できます。
今回の更新をどう受け止めるべきか
「Multi-cloud data architecture patterns using Fabric Data Factory」は、Fabric Data Factoryに突然大きな破壊的変更が入ったというより、Microsoft Fabricをマルチクラウドデータ基盤の中心として設計する方向性を明確にした更新です。
すでにSnowflake、Databricks、Google BigQuery、Salesforceなどを使っている企業にとっては、個別に散らばったデータ連携を見直す良いタイミングです。一方で、単一のデータソースだけを使っている環境では、すぐに大きな作業が必要になるケースは多くありません。
次に取るべき行動は、既存のData Factoryパイプラインと外部接続を棚卸しし、接続方式、認証、再試行、通知、データ移動量を確認することです。そのうえで、Fabricへ物理コピーするデータ、OneLakeショートカットで参照するデータ、既存クラウド側に残す処理を分けて設計すると、運用しやすいマルチクラウドデータアーキテクチャに近づけます。
[2]: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/Multi-cloud-data-architecture-patterns-using-Fabric-Data-Factory/ba-p/5217279 “
Multi-cloud data architecture patterns using Fabri… – Microsoft Fabric Community
“
コメント