はじめに

組織改編や M&A、開発・本番での厳密な分離などにより、Microsoft Fabric を複数テナントで運用するケースは十分にありえます。

そのような環境で「別テナントの Fabric にどうやってデータを渡すか」を考えると、2026年3月時点では主に次の 3 パターンが候補になります。

テナントA Fabric → Azure Data Lake Storage Gen2（ADLS Gen2）などのハブとなるストレージ → テナントB Fabric
テナントA Fabric からテナントB Fabric への直接書き込み
Fabricでの外部データ共有

本記事では、それぞれの実現イメージと、実務上気を付けたいポイントを整理します。

結論：現状のおすすめ

現時点では、個人的には ハブストレージを使うパターン が最も扱いやすいと考えています。

Fabric の外部データ共有の注意点は後述しますが、外部データ共有の有効 / 無効をテナントレベルで制御する形であり、外部データ共有を実施できるユーザーの管理や、そのユーザーが参照可能なデータ範囲を適切に整理しておかないと、セキュリティのリスクにつながる可能性があると考えています。
そのため、機密性の高いデータを扱う場合は、共有そのものを厳格に設計できる ハブストレージ型 のほうが、現実的には運用しやすいと感じます。

ハブストレージ方式は外部データ共有より一手間かかりますが、ADLS Gen2 に Delta 形式で集約しておけば、1つのテーブル実体を複数 Fabric テナントから参照しやすくなります。将来的に Fabric テナントが増えても対応可能です。さらに、Databricks など他のデータ基盤からも利用しやすい、という汎用性があります。

また、「外部に出してよいデータだけを ADLS Gen2 に配置する」という運用を徹底しやすいのも利点です。
共有対象をハブ側で明確に分離できるため、意図しないデータ共有のリスクを下げやすくなります。

▽ 関連資料

① ハブストレージを使った共有

構成は図の通りですが、

テナントA Fabricにて、共有したいデータをPipeline等でADLSに格納
どこかのテナントのADLS2にDelta Tableとして格納（これにより重複なしで別テナントFabricや別データプラットフォームサービスから参照可能）
テナントB からADLS2のテーブルに対しショートカットを作成（外部データの管理は特定のユーザーが管理する構成にする）
外部データを必要に応じて別ワークスペースにショートカットorコピーで配布

Fabric では、Lakehouse から ADLS Gen2 へのショートカットを作成できます。認証には組織アカウント、アカウントキー、SAS、サービスプリンシパル、ワークスペース ID などを利用できます。

この構成は、たとえば テナントAを本番、テナントBを開発 としたときに、本番データをマスキング・抽出したうえで開発環境へ安全に配布する用途にも向いています。

個人的には、この方式の良さは「共有するデータの境界をストレージ側で管理できる」点にあります。

② テナントA FabricからテナントB Fabricへの直接書き込み

これは「Fabric の標準 GUI 機能として簡単に実現する」というより、サービスプリンシパルと API を組み合わせて実装するパターンとして考えるのがよいと思います。
Fabric 管理者ポータルには Service principals can call Fabric public APIs という設定があり、サービスプリンシパルで Fabric public APIs を利用できます。

実装パターンとしては概ね次のようになります。

テナントB（書き込まれる側）のAzure Potralでサービスプリンシパルを作成する
テナントＢのFabricの管理者ポータル（テナント設定）にて[Service principal can call Fabric public APIs] を有効化する
テナントBのFabricの特定のワークスペースにて、該当のサービスプリンシパルにメンバー以上のワークスペース権限を付与する
テナントAのノートブックからテナントBのサービスプリンシパルのクライアントID・シークレットを用いてテナントBのレイクハウスに直接データをコピー（書き込み）する
テナントBのレイクハウスでデータ反映を確認

この方法の注意点

シークレットの直書きは避けたい

実装時はクライアントシークレットを Notebook に直書きするのではなく、Key Vault 参照などを使って管理するほうが安全です。Fabric には Azure Key Vault 参照の仕組みもあります。

汎用的なデータ配布基盤にはなりにくい

「A → B に送る」だけなら成立しても、今後テナントC、D…と増えたときに、接続関係と認証管理が複雑化しやすいです。
そのため、単発連携や特殊要件なら候補になりますが、配布先が増える前提ならハブストレージ方式のほうが拡張しやすいと思います。

サービスプリンシパルへ付与する権限が比較的大きい

この方法では、書き込み先ワークスペースに対してサービスプリンシパルへメンバー以上の権限を付与する必要があり、権限範囲はやや強めです。
そのため、対象ワークスペースは書き込み専用の用途に分離する、付与先を限定する、不要になった権限は速やかに見直す、といった最小権限を意識した運用が重要です。

③Fabricでの外部データ共有

Fabric 外部データ共有は、Fabric ユーザーがテナントのデータを別の Fabric テナントのユーザーと共有できるようにする機能です。データは物理的にコピーされず、共有元のテナント内にある元のデータを指す OneLake のショートカットが他のテナントに作成されます。

実際、ストレージコストを増やさずに共有できるのは魅力ですし、手順も比較的シンプルです。
ドキュメントからわかりにくい点をまとめました。

※前提
当然、共有先ユーザー（コンシューマー側）でもMicrosoft Fabricを開始している必要があります。

この方法の注意点

コンシューマー側のアクセス制御ポリシーが適用される

セマンティックモデルの行レベルセキュリティ (RLS)、Microsoft Purview 情報保護ポリシー、Purview データ損失防止ポリシーなど、共有元のテナントで定義されているアクセス制御ポリシーは、組織の境界を越えるデータには適用されません。
- 一方でコンシューマーのテナントで定義されているポリシーは、そのテナント内のデータに対する方法と同様に、受信した共有データにも適用されます。
- ただし、2026年3月時点ではOneLakeセキュリティは適用できない。

有効化粒度がテナントレベル

プロバイダー側で外部共有できるユーザーは指定できます。しかし、外部データ共有の有効 / 無効はテナントレベルで制御する方式です。
- なお、外部共有できるユーザーが共有できるデータはそのユーザーがアクセス権をもつデータのみです。（そのユーザーが閲覧できないデータは共有されない）
- しかし、外部共有できるユーザーが見えるデータの範囲内ですが、そのユーザー次第でどこにでも配れてしまいます。
  - なお共有リンクはメール等に添付可能ですが、Fabricポータル上で指定した相手以外はそのリンクを開くことはできません。

▽外部共有できるユーザーが共有できるデータはそのユーザーがアクセス権をもつデータのみです。（そのユーザーが閲覧できないデータは共有されない）

▽共有リンクはメール等に添付可能ですが、Fabricポータル上で指定した相手以外はそのリンクを開くことはできません。

【所感】
ワークスペースレベルで外部データ機能の有効/無効を設定できればより理想的だなと思っています。

Youtubeもやってます

FabricやDatabricksについて学べる勉強会を毎月開催しています！

次回イベント欄から直近のMicrosoft Data Analytics Day(Online) 勉強会ページへ移動後、申し込み可能です！

関連記事