Microsoft Fabricとは？使い方や価格体系、できることを徹底解説！

ビジネスにおいてデータ分析の重要性が高まる中、企業が抱える課題は「大量のデータを効率的に分析し、迅速な意思決定につなげること」です。
この課題を解決するために開発されたのが、Microsoftの統合データ分析プラットフォーム「Microsoft Fabric」です。


本記事では、Microsoft Fabricの特徴や構成要素、Copilot・AI機能、セキュリティ・ガバナンス、料金体系、導入の流れまでを整理し、2026年3月時点の最新情報を踏まえて解説します。
FabCon 2026で発表されたFabric Graph GA・OneLake Security GA・Data Agents GAなどの新機能や、日本企業の導入事例もカバーしています。


なお、AI総合研究所ではMicrosoft Fabricの導入支援を行っており、ビジネスのデータ活用力強化をサポートしています。
無料相談も承っておりますので、お気軽にお問い合わせください。
➡️【AI総合研究所】お問い合わせページ

Microsoft Fabricとは

Microsoft Fabricは、マイクロソフトが提供する統合データ＆AIプラットフォームです。

データの収集・蓄積・加工・分析・可視化までを、一つのSaaS（クラウドサービス）上で完結できるように設計されています。

従来は「ETLはAzure Data Factory」「DWHはSynapse Analytics」「可視化はPower BI」のように、複数サービスを組み合わせて設計する必要がありました。
Fabricでは、これらの役割を**共通のデータレイク「OneLake」と共通の容量（Capacity）**の上でまとめて扱えるため、「どのサービスを選ぶか」よりも「どう活用するか」に集中しやすくなります。

Power BI / Synapse / Data Factoryとの違い・位置づけ

Microsoft Fabricは、既存のサービスを置き換えるものではなく、再編・統合したプラットフォームという位置づけです。
以下の3サービスとの関係を整理します。

• Power BI
  Fabricの中では、主に可視化・ダッシュボード・レポート共有の役割を担います。
  従来のPower BIサービスはFabricと統合されており、Fabricワークスペース上でPower BIアセットを扱えるようになっています。FabricとPower BIの連携手順についてはこちらの記事で詳しく解説しています。
  
  

• Azure Synapse Analytics
  Synapseの機能のうち、「SQL DWH」「Spark」「Data Explorer」など分析寄りの部分は、FabricのData Warehouse / Data Engineering / Real-Time Intelligenceに取り込まれてきています。
  
  

• Azure Data Factory
  データ統合やパイプライン機能は、FabricのData Factoryワークロードとして統合されています。
  Fabric側のData Factoryを使うことで、OneLakeとの連携やFabricワークスペースとの一体運用がしやすくなります。

既存のPower BIやSynapse環境をすぐに廃止する必要はありませんが、新規のデータ基盤・BIプロジェクトではFabric前提のアーキテクチャを検討するケースが増えています。

---

Microsoft Fabricの全体構成：ワークロード・OneLake・Capacity

ここでは、Fabricを構成する要素を体系立てて整理します。
「どんな部品があって、それぞれがどのフェーズを担当しているのか」を把握するイメージです。

ワークロード・OneLake・Capacityの関係

Fabricは、大きく次の3つのキーワードで捉えると整理しやすくなります。

• ワークロード（エクスペリエンス）
  Data Factory / Data Engineering / Data Warehouse / Real-Time Intelligence / Data Science / Power BI / Databases / Fabric IQ など、「何をするか」に紐づく機能群です。
  
  

• OneLake
  すべてのワークロードの下にある共通データレイクです。テナント全体で1つの論理データレイクとして機能し、Azure Data Lake Storage Gen2の上に構築されています。
  ファイルやテーブルはOneLake上に置かれ、各ワークロードがそれを共有して利用します。
  
  

• Capacity（キャパシティ）
  実行リソースやスループットを表す単位です。F2 / F4 / F8…といったSKUで課金され、ワークスペースをこのCapacityにぶら下げる形で利用します。

これら3つを組み合わせることで、「どのデータを、どのワークロードで、どのくらいの規模で扱うか」を設計していくイメージです。

データライフサイクルで見たFabricの役割

Fabricがカバーするライフサイクルを、典型的なデータ活用プロセスに当てはめてみます。

1. 収集（Ingest）
   各種SaaSやRDB、ファイルストレージからデータを取り込む（Data Factory / Real-Time Intelligence）。
   
   

2. 加工・統合（Transform）
   Notebook（Spark）やSQLでデータを整形し、共通のスキーマに統合する（Data Engineering / Data Warehouse）。
   
   

3. 保存・管理（Store）
   OneLake上でテーブルやファイルとして保存し、LakehouseやWarehouseに整理する。
   
   

4. 分析・可視化（Analyze / Visualize）
   Power BIでレポート・ダッシュボードを作成し、セルフサービスBIも展開する。
   
   

5. AI活用（AI & ML）
   Data ScienceやCopilot、AI functionsなどを用いて、機械学習モデルや生成AIを組み合わせた活用を行う。

Fabricは、この一連の流れを**「1つのSaaS体験」＋「OneLake」**という枠組みでまとめている点が特徴です。

Fabric Capacityとワークスペース／アイテムの関係

Fabric Capacityは、「どの程度のリソースを常に確保するか」を決める単位です。
AzureポータルからF2 / F4 / F8…といったSKUを購入し、テナントやワークスペースに割り当てる構成になります。

• ワークスペースは、いずれかのCapacity（または試用Capacity）に紐づいて動作します。
  
  

• LakehouseやWarehouse、Notebook、レポートなどのアイテムは、このワークスペースの中に作成されます。
  
  

• 同じCapacityに紐づくワークスペース同士でリソースを共有するため、設計次第では「本番用」「検証用」などにCapacityを分けるパターンも一般的です。

---

Microsoft Fabricの主要ワークロード

ここでは、Fabricの代表的なワークロードを紹介します。
まず全体像を一覧で押さえたうえで、それぞれの役割を掘り下げます。

各ワークロードの一覧と位置づけ

Fabricの代表的なワークロードと役割を以下の表にまとめます。
どのワークロードが自社のユースケースに関係しそうか、ざっくり当たりを付ける材料として活用してください。

ワークロード	主な役割	典型的な用途
Data Factory	データ統合・パイプライン	SaaS／DB／ファイルからのバッチ・スケジュール取り込み
Data Engineering	Lakehouse＋Sparkによる加工	大量データの前処理・特徴量作成・バッチ集計
Data Warehouse	SQLベースのDWH	共通KPI・業務指標の集約、レポーティング基盤
Real-Time Intelligence	ストリーミング分析	センサー／ログなどのリアルタイム集計・異常検知
Data Science	モデル開発・実験	機械学習モデルのトレーニングや評価
Power BI	レポート・ダッシュボード	可視化、セルフサービスBI、配信・共有
Databases	運用DB（トランザクション）	業務アプリのOLTP、分析基盤との一体運用
Fabric Activator	イベント検知・自動アクション	リアルタイムデータの閾値監視、アラート発火
Fabric Graph	グラフデータベース	エンティティ間の関係性モデリング・GQL対応
Fabric Maps	地理空間分析	リアルタイム位置情報分析・物流最適化
Fabric IQ（プレビュー）	セマンティックレイヤー	オントロジー、グラフ、AIエージェントによる意味付け

これらのワークロードは、すべて同じFabricワークスペース上に共存させることができます。
「DWHは別サブスクリプション、BIは別テナント」といった構成に比べ、可視性と運用負荷を抑えやすい構造です。

【Data Factory】データ統合・ETL/ELTパイプライン

Fabric版のData Factoryは、各種ソースからのデータ取り込みや変換処理を担います。
従来のAzure Data Factoryに近い体験を、FabricのワークスペースやOneLakeと一体化した形で提供しています。

• GUIベースでパイプラインやデータフローを定義できる
• Azure / SaaS / データベース / ファイルなど、多数のコネクタを利用可能
• スケジュール実行やエラー通知など、運用に必要な機能も揃っている

データの接続先一覧

Data FactoryでOneLakeに取り込んだデータは、そのままLakehouseやWarehouse、Power BIから参照できるため、「取り込み」と「利用」が分断されにくい点がメリットです。

なお、2026年時点ではDataflow Gen2にModern Evaluator（.NET 8ベースの新評価エンジン）がGA提供されており、80以上のコネクタ対応と処理パフォーマンスの向上が図られています。

【関連記事】
【Microsoft Fabric】Data Factoryとは？機能やADFとの違い、料金体系を徹底解説

【Data Engineering】Spark／Notebookによる加工・前処理

Data Engineeringワークロードでは、LakehouseとSparkベースのNotebookを使ってデータ加工を行います。
データサイエンティストやデータエンジニア向けの環境とイメージすると分かりやすいです。

Jupyter notebookイメージ

• Notebook上でPython / Scala / SQLなどを使い、データの前処理や特徴量作成を実施
• Deltaテーブルとして保存した結果は、WarehouseやPower BIからも利用可能
• MLflowなどと組み合わせ、モデル実験のトラッキングにも活用できる

2026年にはSpark Autoscale Billingが導入され、Sparkワークロードに対してPay-as-you-goモデルで課金する仕組みが利用可能になっています。実際に使用したコンピューティングリソース分のみ支払う形式のため、オーバープロビジョニングのコストを削減しやすくなりました。

さらに、FabCon 2026ではRuntime 2.0（プレビュー）が発表されました。Apache Spark 4.x、Delta Lake 4.x、Scala 2.13、Azure Linux Mariner 3.0を採用した大規模データ処理向けの新ランタイムで、従来比でのパフォーマンス向上が見込まれます。また、Materialized Lake Views（GA）により、Spark SQLやPySparkでのメダリオンアーキテクチャの実装がシンプルになっています。

【関連記事】
【Microsoft Fabric】Data Engineeringとは？Sparkの機能や料金体系を徹底解説

【Data Warehouse / SQL】DWH・業務指標の土台

Data Warehouseワークロードは、エンタープライズ向けのクラウドDWHです。
Lakehouse上のデータと連携しながら、業務で使うKPIやマートの土台を整える役割を担います。

DataWarehouseのクリック

DataWarehouseの画像

• T-SQLベースでテーブルやビューを定義し、Power BIのDirect Lake / DirectQueryで利用できる
• 従来のSynapse SQLと同様、DWH的なチューニングやガバナンスを意識した設計が可能
• 既存のSQLスキルを活かしつつ、OneLake上のデータと密に連携できる点が特徴

【関連記事】
【Microsoft Fabric】Data Warehouseとは？T-SQL機能や料金、移行方法を徹底解説

【Real-Time Intelligence】ログ・イベントのリアルタイム分析

Real-Time Intelligenceワークロードは、リアルタイムデータの取り込み・分析を行う機能群です。
ストリーミングデータに対するクエリやダッシュボードを、Fabric上で一貫して扱えるようにする狙いがあります。

• イベントハブやKafkaなどからのストリーミングデータ取り込み
• ストリーミングテーブルを使ったリアルタイム集計・ウィンドウ集計
• 異常検知やアラートのトリガーを組み合わせたユースケース

ログ監視やIoTデータの可視化、リアルタイムKPIの表示など、「今起きていること」をすぐに把握したいシナリオで有効です。2026年にはストリーミング仮想ネットワークデータゲートウェイが追加され、VNet統合によるセキュアなストリーミング接続も可能になっています。

FabCon 2026では**Fabric Maps（GA）**も発表されました。リアルタイム地理空間分析を提供し、物流・小売・航空などの位置情報に基づく意思決定をFabric内で完結できるようになっています。

【関連記事】
【Microsoft Fabric】Real-Time Intelligenceとは？機能や料金体系を徹底解説

【Data Science】機械学習開発とMLOps基盤

Data Scienceワークロードでは、NotebookやMLライブラリを使ったモデル開発が可能です。
Fabricの中でデータ探索・特徴量作成・モデル訓練・評価までを一貫して行えるように設計されています。

• Notebookベースでの実験・特徴量エンジニアリング
• OneLake上のデータを直接読み、結果もOneLakeに書き戻す
• Azure Machine Learningや他のMLOps基盤と連携する構成も取りやすい

生成AIだけでなく、従来型の機械学習モデル（需要予測・スコアリングなど）との組み合わせにも向いています。

【関連記事】
【Microsoft Fabric】Data Scienceとは？MLflowやAutoML、料金体系を徹底解説

【Power BI】可視化・ダッシュボード・共有

Power BIは、Fabricにおいても可視化と共有の中核を担います。
データモデルやレポート、ダッシュボードを作成し、組織内へ配信する役割です。

Teamsへのレポート共有

• LakehouseやWarehouseをデータセットとして接続し、レポートを作成
• TeamsやPowerPoint、SharePointへの埋め込み・共有
• Direct Lakeモードにより、大規模データに対しても高パフォーマンスな分析が可能

既にPower BIを利用している組織にとっては、「データソースがFabricのOneLakeに変わる」イメージで移行・統合を検討できます。

また、Copilot for Power BIを活用すれば、自然言語でレポートの作成やデータの要約も行えます。

【Fabric Activator】リアルタイムイベント検知と自動アクション

Fabric Activatorは、ノーコードでリアルタイムデータのパターンや条件を検知し、自動的にアクションをトリガーする機能です。Real-Time Intelligenceと組み合わせて使うケースが多く、以下のようなユースケースに対応します。

• データセットやクエリ結果の閾値を監視し、アラートを発火
• 条件に応じてメール通知やPower Automateフローを起動
• ダッシュボードの数値変化をリアルタイムで追跡

「データの変化に即座に対応したい」という運用ニーズに対して、プログラミングなしで設定できる点がFabric Activatorの強みです。

【Fabric Graph】エンティティ間の関係性モデリング

FabCon 2026でGAが発表されたFabric Graphは、エンタープライズ向けのネイティブグラフデータベースです。ノード・エッジ・トラバーサルを用いて、企業内のエンティティ間の関係性をモデリングし、Graph Query Language（GQL）でクエリを実行できます。

• 顧客・製品・取引の依存関係や経路探索に活用でき、リレーショナルDBでは表現しにくい多段階の関係性分析が可能
• AIシステムと組み合わせることで、関係性の文脈を踏まえた精度の高い推論を実現し、ハルシネーション（誤回答）のリスクを軽減できる
• Fabric IQ（後述）のオントロジーと連携し、ビジネス概念の関係性をデータとして表現する基盤になる

サプライチェーンの影響分析や不正検知、ナレッジグラフの構築といったユースケースに適しています。

【Fabric IQ】セマンティックレイヤーとAIエージェント

Fabric IQは、2025年後半にプレビュー提供が始まった新しいワークロードです。OneLake上に散在するデータをビジネス用語で整理し、AI（エージェント）やアプリケーションから一貫した意味で参照できるセマンティックレイヤーを構築します。

FabCon 2026では、Fabric IQの機能が大幅に強化され、オントロジーとプランニング機能の統合により「洞察→意思決定→アクション」の一連のフローを支援できるようになりました。主要コンポーネントは以下のとおりです。

• オントロジー
  企業のビジネス用語・エンティティ型・関係性・ルールを定義し、OneLake上の実データにバインドする。部門間で異なるデータ定義を統一する役割を担います。
  
  

• Fabric Graph連携
  前述のFabric Graphと連携し、オントロジーで定義したビジネス概念の関係性をグラフデータとして表現・クエリする。経路探索や依存関係分析に活用できます。
  
  

• Operations Agent
  リアルタイムデータを監視し、ビジネスアクションを推奨するAIエージェントを作成できる。ビジネス用語を理解した状態で判断・推論を行う点が、従来のルールベースのアラートとの違いです。

Fabric IQはまだプレビュー段階のため、本番利用には慎重な評価が必要です。ただし、FabCon 2026での機能強化からも分かるように、「データの意味付け」や「AIエージェントとの統合」はMicrosoftのデータプラットフォーム戦略の中核に位置付けられています。早期にPoCで試し、自社のデータカタログやマスタデータ管理の方針と整合性を確認しておくことを推奨します。

【関連記事】
Fabric IQとは？AI連携を強化する新機能を徹底解説

---

OneLakeを軸にしたMicrosoft Fabricのデータ設計ポイント

このセクションでは、OneLakeを前提としたデータ設計の考え方を整理します。

もし自社で「部門ごとにデータマートが乱立し、"正しい数字"がどれか分からない」「同じデータをETLで何度もコピーし、ストレージコストが膨らんでいる」という状況に心当たりがあるなら、OneLakeの設計思想が直接的な解決策になります。「コピーしない」「共通の形式に寄せる」がその基本です。

OneLakeの特徴と「One Copy」の考え方

OneLakeの中心にある思想が「One Copy」です。
同じデータを用途ごとに何度もコピーせず、単一のコピーをさまざまなワークロードから参照することを目指します。

• テナント全体で1つのデータレイクという考え方で、業務アプリや部門ごとにバラバラにストレージを立てる必要がない
• 生データも、加工済みデータも、基本的にはDelta / Parquet形式で保存され、Lakehouse / Warehouse / Notebook / Power BIが同じテーブルをそれぞれの観点から利用する
• Azure上のインフラ用語（リソースグループやストレージアカウント）を意識せずに、SaaSとしてデータレイクを扱える
• コピーが必要な場合も、「明確な理由」と「ライフサイクル」を決めておく

これにより、ストレージコストやデータ鮮度の管理コストを抑えやすくなります。

Shortcutsによる外部ストレージ連携

OneLakeのShortcut機能を使うと、外部ストレージ（Azure Data Lake Storage Gen2やAmazon S3など）上のデータを、「コピーせずに」OneLake配下に見せることができます。

• すでにAzure Data LakeやS3でデータレイクを構築している場合でも、Shortcutで参照を貼るだけでFabricから扱える
• 取り込み前にサンプルを見たり、一部だけをFabric側に持ってくるといった柔軟な構成が可能
• 完全移行ではなく、共存・ハイブリッド構成を取りやすい点が実務上のメリット
• FabCon 2026ではSnowflakeとの双方向Icebergデータ読み取りがGAになり、Snowflake管理のIcebergテーブルをOneLake上でネイティブに参照できるようになった。Databricksとの相互運用性も強化されている

Mirroringによる運用DB・外部DBからの継続取り込み

Mirroring機能は、特定の外部データベースのデータを、ほぼリアルタイムにOneLakeへ同期する仕組みです。

• 例として、Azure SQL DatabaseやSQL Server、Snowflake、さらにFabCon 2026で追加されたSAPやOracleなどのテーブルをミラーし、そのままFabric側でテーブルとして利用できる
• 従来の「夜間バッチで丸ごとコピー」から、更新分だけを随時反映していく構成へ移行しやすい
• リアルタイム分析やダッシュボード更新の頻度を上げたいシナリオに向いている

なお、購入済みCapacity SKUに応じた無料のMirroringストレージ枠が用意されています。たとえばF64を購入した場合、64TBまでのMirroringレプリカストレージが無料になります。この枠を超えた分はOneLakeストレージ料金として課金されます。

データのインポート

データの表示

Direct Lakeとパフォーマンス最適化

Power BIのDirect Lakeモードは、OneLake上のDeltaテーブルに直接アクセスしながら、高速なインタラクティブ分析を可能にする仕組みです。

• 従来のImportやDirectQueryに比べ、大容量データでも応答速度を維持しやすい
• WarehouseやLakehouse上のテーブル設計と合わせて、パフォーマンスチューニングを行うことで効果を最大化できる

Direct Lakeを前提にすると、「DWH側のデータ構造」と「レポート側のモデリング」の両方を意識した設計が重要になります。

OneLake Security：統一的なアクセス制御

OneLake Securityは、OneLake全体でデータアクセスを一元管理する仕組みです。FabCon 2026で**GA（一般提供）**が発表され、従来ワークロードごとに個別設定していたセキュリティルールを、OneLake Securityで統一的に定義できるようになりました。

• 行レベル・列レベルのアクセス制御をOneLake上で定義し、Spark Notebook、SQLエンドポイント、Excel Online、Direct Lake（Power BI）、AIエージェントなど複数のアクセス手段に自動適用される（「Define once, enforce everywhere」モデル）
• フォルダレベルのReadWrite権限が追加され、ワークスペースのContributor以上のロールを付与しなくても特定フォルダへの書き込みを許可できる
• Private Link、ワークスペースIPフィルタリング、カスタマーマネージドキーにも対応
• Microsoft Entra IDベースのID管理と組み合わせることで、より細かいアクセス制御が可能

GAになったことで、マルチワークロード環境でのガバナンスが大幅に簡素化されます。特に、データエンジニアリング・DWH・BIの各チームが同じデータにアクセスする構成では、セキュリティルールの二重管理を解消できる実務的なメリットが大きいです。

---

Microsoft FabricのCopilot・AI機能

Fabricは、単なるデータ基盤ではなくCopilotやAI機能と一体化されている点も特徴です。
ここでは、代表的なAI体験と、利用時の前提条件を整理します。

Copilotの主な活用シーン

Copilot in Microsoft Fabric / Copilot for Power BIでは、次のようなことが可能です。

• 自然言語からSQLやDAXのたたき台を生成する
• Power BIレポートのビジュアル配置や要約文を提案してもらう
• Notebook内でのコード補完や、データ探索ステップの提案を受ける
• Data Factoryのパイプライン定義や、変換ロジックの案を生成してもらう

あくまで「たたき台」として活用し、最終的なロジックの妥当性は人間側でレビューする前提で使うのが実務的です。Copilot in Fabricの詳細は別記事で解説しています。

Data Agent / AI Functionsなど周辺AI機能の位置づけ

Fabricでは、Copilotに加えて次のようなAI関連機能も提供されています。FabCon 2026ではData AgentsがGA（一般提供）となり、自然言語でデータにアクセスする体験が本番利用可能になりました。

• Data Agent（GA）
  OneLake内外のデータを跨いで検索・要約する会話型インターフェースです。従来のダッシュボードに代わり、自然言語で「先月の売上が前年比で落ちた地域は？」といった問いかけに即座に回答します。SAP、Oracle、Salesforceなどのクロスプラットフォーム統合にも対応し、マルチエージェントオーケストレーションもサポートされています。
  
  

• AI functions（AI関数）
  SQLやNotebookから直接、要約や分類などの生成AIを呼び出すための関数群です。
  
  

• Fabric MCP（Model Context Protocol）
  Fabric local MCP（GA）は、GitHub CopilotなどのAIコーディングアシスタントをFabricに直接接続するオープンソースのローカルサーバーです。AIによるパイプライン生成やLakehouse変更の自動化が可能になります。クラウド側のFabric remote MCP（プレビュー）も発表されています。
  
  

• Azure OpenAI Service / Azure AI Searchとの連携
  RAG（検索拡張生成）パターンでのアプリケーション開発などに活用できます。

機械学習、検索、ChatGPT api等も使用可能

Fabricはこれらをデータ基盤のすぐそばに配置することで、「データを動かさずにAIを呼べる」構造を目指しています。Data AgentsのGAやMCP統合により、従来は「BIチームがダッシュボードを作り、ビジネス部門がそれを見る」という一方通行だったデータ活用が、「ビジネス部門が自分で質問し、AIが回答する」双方向の体験に変わりつつあります。

また、Microsoftは2025年にデータエンジニアリング企業Osmosを買収しており、自己修復パイプラインやインテリジェントデータ変換、AIによるデータ品質モニタリングなどの機能が順次Fabricに統合される予定です。

Copilot利用時の前提条件（2026年3月時点）

Copilot in Fabric / Copilot for Power BIの利用要件は、2025年4月に大きく変更されました。

以前はF64以上のCapacityが必須でしたが、現在はF2以上の全有償SKUでCopilotおよびAI機能が利用可能になっています。この変更により、中小規模の組織でもCopilotを活用しやすくなりました。

現在の主な前提条件は以下のとおりです。

• 有償のCapacity（Fabric F2以上）に紐づくワークスペースが必要
• 試用（trial）SKU／試用CapacityではCopilotはサポートされない
• テナントのリージョンやデータ境界、ネットワーク構成（Private Linkなど）によっては利用制限が生じる場合がある

Fabric Copilot Capacity（既存の容量をCopilotの課金先として指定する機能）を使えば、Copilot利用に必要なリソースを分離して管理できます。Fabric Copilot CapacityもF2以上のSKUから利用可能です。

---

Microsoft Fabricの料金・ライセンス体系

ここでは、Fabricのコスト構造を大きく捉えます。

実際にはAzure料金ページや見積もりツールでの確認が必須ですが、「何に対してお金がかかるのか」を押さえておくことが重要です。

【課金の全体像】Fabric Capacity + OneLake Storage + ライセンス

Microsoft Fabricのコストは、おおまかに次の3レイヤーで考えます。

1. Fabric Capacity（F SKU）
   分析ワークロードの実行リソースに対する料金です。
   F2 / F4 / F8… といったSKUごとに、月額または時間単価が設定されています。
   
   

2. OneLake Storage
   OneLake上に保存したデータ量に応じたストレージ料金で、Capacityとは別に発生します。
   Pay-as-you-goで約$0.023/GB/月が目安です（2026年3月時点の参考価格）。KQLキャッシュやBCDRバックアップを追加する場合は別途料金がかかります。
   
   

3. ユーザーライセンス（Power BI / Fabric）
   Power BI Pro / Premium Per User、Fabric関連のユーザーライセンスなどです。
   レポート作成・共有の要件によって最適な組み合わせが変わります。

ワークスペースの作成

Fabric Capacity（F SKU）のラインナップ・選び方の目安

Fabric Capacityは、F2（2 CU）からF2048（2,048 CU）まで幅広いSKUが用意されています。
SKUの数字が倍になるとCU（Capacity Unit）も倍になる構成で、以下のような使い分けが目安になります。

SKU	CU数	主な用途の目安
F2	2	小規模PoCや部門内での検証環境
F4	4	小〜中規模のPoC、個人開発
F8	8	部門単位の本番環境（エントリー）
F16〜F32	16〜32	中規模の本番環境、複数チームの共有利用
F64以上	64〜	全社横断のデータ基盤、大規模DWH・リアルタイム分析

「まずはPoCで動かす」段階ではF2〜F4から始め、負荷に応じてスケールアップするパターンが多いです。
全社展開やリアルタイム分析の比重が大きい場合は、最初からF32以上を想定した設計が検討対象になります。

Fabricの支払い方法は2種類あります。Pay-as-you-goは時間課金でいつでも一時停止でき、PoCや開発環境に向いています。予約（1年 / 3年）は固定容量を事前に確保する方式で、Pay-as-you-goに比べて最大約40%のコスト削減が見込めます。本番環境で安定した利用が見込める場合は予約が有利です。

OneLake Storageの課金イメージ

OneLakeのストレージ料金は、基本的に「保存しているデータ量」に比例します。

参考価格として、標準ストレージは約$0.023/GB/月（約$23/TB/月）です。
KQLキャッシュ（高速クエリ用）は約$0.246/GB/月、BCDRバックアップは約$0.041/GB/月と、用途によって単価が異なります。

ライセンス構成の考え方

ユーザーライセンスについては、次のような観点で整理します。

• レポートの閲覧のみが必要なユーザーは、Power BI Pro / PPU / Fabricライセンスのうち、既存環境との兼ね合いで選択
• レポートの作成・共有を行うユーザーは、Pro以上が前提になることが多い
• 開発者やデータエンジニアは、FabricワークスペースやNotebookを扱えるライセンスが必要

組織規模や既存のPower BI契約状況によって最適解が変わるため、既存契約を棚卸ししたうえでFabric容量と組み合わせるのが現実的です。

【重要】「Power BI Premium P SKU」からの移行

Power BI Premium P SKU（容量ライセンス）は段階的に販売終了が進行しています。

• 非EA（Enterprise Agreement）契約の顧客 2026年1月1日で販売終了済み
• EA契約の顧客 2028年1月1日で販売終了予定

非EA契約の組織ではすでにP SKUの新規購入ができない状態です。P SKUの契約終了後は、Microsoftから90日間のデータアクセス猶予期間が設けられます。最初の30日間はP SKU相当のFabric Capacityが無料で提供されますが、30日を超えると操作にスロットリング（20秒の遅延）が適用され、90日以降は容量全体が凍結される可能性があります。

移行先はFabric Capacity（F SKU）です。Microsoftは大規模環境向けの自動移行ツールを提供しており、ワークスペースの再割り当てを効率化できます。
新規顧客はP SKUを購入できないため、容量ベースのBI運用はFabric Capacity（F SKU）一択です。EA契約のある組織も、2028年の期限に向けて早めに移行計画を立てることを推奨します。

無料トライアル（60日）の位置づけと制約

Microsoft Fabricには、一定期間利用できる**無料トライアル（試用Capacity）**が用意されています。

• 小規模なPoCや機能検証には有効だが、Copilotはサポート対象外などの制限がある
• 本番利用を前提とする検証では、早い段階で有償Capacityに切り替え、実際の制約に近い環境の検証が推奨

---

Microsoft Fabricの使い方

ここからは、PoCレベルでFabricを試すときの「最小限の流れ」を5ステップで整理します。

1.ワークスペースとLakehouse / Warehouseを用意する

最初のステップは、Fabricワークスペースとデータ格納先を用意することです。

Microsoft Fabric利用画面

• Fabricポータルから、新しいワークスペースを作成する
• ワークスペースにCapacity（試用または有償）を割り当てる
• LakehouseまたはWarehouseを新規作成し、OneLake上のデータ格納先を確保する

Lakehouseを軸にするか、Warehouseを軸にするかは、チームのスキルセットや既存DWHとの整合性で選ぶとスムーズです。

2.データを取り込む（Get data / Data Factory）

つづいて、ソースシステムからOneLakeにデータを取り込みます。

データの接続先一覧

• 最初はCSVやExcelなどのファイルアップロードから始めても構わない
• 本格的には、Data Factoryのコネクタを用いてSaaSやRDBからの取り込みパイプラインを構築する
• MirroringやShortcutを併用することで、「コピーしすぎない」構成も検討可能

3.NotebookやSQLで加工・分析する

データを取り込んだら、NotebookやSQLを使って加工・分析を進めます。

Notebookでの利用画面

• Data EngineeringのNotebookで前処理や特徴量を行う
• Data WarehouseのSQLエディタでビューやマートを定義し、Power BIから使いやすい形に

この段階からCopilotを活用し、「たたき台としてのコード生成」を試してみると、Fabricならではの体験がしやすくなります。

4.Power BIでレポート化し、Teamsなどに共有する

整形したデータをもとに、Power BIでレポートやダッシュボードを作成します。

Teamsへのレポート共有

• Lakehouse / Warehouseをデータセットとして接続し、基本的なメジャー・ディメンションを定義する
• グラフやテーブル、カードビジュアルを使って、KPIを可視化する
• 作成したレポートは、TeamsのタブやPowerPointへの埋め込み、メール配信などで共有できる

5.最小限の運用ルールを決める

PoCの段階から、次のような最低限のルールを決めておくと、後からの拡張が楽になります。

• ワークスペースの役割（本番／検証／個人）と命名規則
• ワークスペース・アイテムの権限設計（閲覧／編集／管理）
• 環境ごとのデータソースやパイプラインの切り替え方

---

Microsoft Fabricの構成パターン

ここでは、Fabricを使った代表的なアーキテクチャ構成を4つ紹介します。自社のユースケースに近いパターンを参考にしてください。

1. BIレポーティング基盤

最も分かりやすいパターンが、BIレポーティング基盤としてFabricを利用する構成です。

• OneLake＋Data Warehouseを軸に、部門横断のKPIを集約
• Power BIによるダッシュボード・レポートを、全社で共有
• 一部の高度な分析はNotebookやCopilotを併用

既存のPower BI環境を強化する形で、徐々にFabricへ移行していくケースも多いです。

2. 複数SaaS・DBを統合するデータハブ

CRMやMAツール、コアシステムなど、複数SaaS・DBに散らばったデータを統合するハブとしてFabricを使うパターンです。

• Data Factoryで各システムからデータをOneLakeへ取り込み
• 共通の顧客IDや製品コードなどで統合し、データマートを設計
• Power BIや外部アプリケーションから、このデータハブを参照

ShortcutやMirroringを組み合わせることで、既存データレイクとの共存も可能です。

3. リアルタイム分析・アラート基盤

リアルタイム性が求められるユースケースでは、Real-Time IntelligenceとFabric Activatorを中心に構成します。

• センサーやログストリームを取り込み、ストリーミングテーブルで集計
• Fabric Activatorで閾値や異常パターンを検知して、アラートやワークフローを起動
• バックグラウンドでは、集計結果をOneLakeに蓄積し、後日分析にも活用

運用監視やIoT、デジタルマーケティングのリアルタイム指標などに適したパターンです。

4. 検索・生成AI（RAG）と組み合わせた応用

Fabric上のデータと、Azure AI SearchやAzure OpenAI Serviceを組み合わせてRAG（検索拡張生成）の基盤にするパターンも増えています。

• OneLake上のドキュメントやログを、Azure AI Searchでインデックス化
• 検索結果とともにLLM（大規模言語モデル）へ渡すことで、根拠付きの回答を生成
• ダッシュボードやチャットボット、社内ポータルなどに組み込む

Fabric側でデータ品質やアクセス制御を整えたうえでRAGに接続することで、「データ基盤＋生成AI」の安全性と再現性を高めやすくなります。
Fabric IQ（プレビュー）が本格化すれば、オントロジーやData Agentを介してRAGパイプラインをさらに高度化できる可能性もあります。

導入事例から見る構成パターンの実際

実際にMicrosoft Fabricを導入した企業の事例を紹介します。

福祉用具レンタル・販売事業の株式会社ヤマシタは、Microsoft Fabric日本初期導入企業の一つです。2023年10月にプレビュー版から導入を開始し、パートナー企業のジールとともにデータ基盤を構築しました。従来はExcelで部門ごとにデータを管理していましたが、OneLakeへの統合により、営業部門向けダッシュボードの提供を実現。週次・月次だったデータ確認がリアルタイムに変わり、意思決定のスピードが大きく向上しています。全国70以上の拠点すべてにDX人材を配置する目標を掲げ、「市民データサイエンティスト」の育成も進めています。

上記の「複数SaaS・DBを統合するデータハブ」パターンの実例であり、「まずは一部門の可視化から始めて段階的に全社展開する」アプローチは、多くの企業で参考になるモデルです。

【関連記事】
Microsoft Fabric導入事例6選！国内企業の成果と導入パターンを解説

---

Microsoft Fabricのセキュリティとガバナンス

エンタープライズでFabricを導入する際には、セキュリティとガバナンス設計が不可欠です。

ここでは、責任分界・ID管理・データ保護・ネットワーク・ガバナンスの観点で整理します。

Shared Responsibility Model（責任分界）の整理

FabricはSaaSであり、インフラ層のセキュリティ（物理・ホストOS・サービス継続性など）はMicrosoftの責任範囲です。
一方、利用者側には次の責任が残ります。

• ユーザー・グループ管理（Microsoft Entra ID）の設計
• ワークスペースやアイテムごとのアクセス権限設計
• データ分類や感度ラベル、DLPポリシーの設定
• 開発・検証・本番などの環境分離

Fabric導入にあたっては、既存のMicrosoft 365 / Azureセキュリティポリシーと整合性をとることが重要です。

参考：Security in Microsoft Fabric / Fabricセキュリティの基礎

ID/アクセス管理とロール設計（Entra ID・RLS/CLS/OLSなど）

Fabricでは、Entra ID（旧Azure AD）ベースの認証・認可モデルが採用されています。

• ワークスペース単位で「閲覧者」「メンバー」「管理者」などのロールを割り当てる
• Power BIのRLS（Row-Level Security）やCLS（Column-Level Security）を使い、データレベルのアクセス制御を行う
• 組織やテナント跨ぎの共有範囲を明示的に設計する

特に、個人情報や機微データを扱う場合は、最低限でもRLS＋感度ラベルの組み合わせを検討したいところです。

前述のとおり、OneLake SecurityはFabCon 2026でGAとなりました。OneLake上で行レベル・列レベルのアクセス制御を一元定義し、Spark・SQL・Power BI・AIエージェントなど全ワークロードに自動適用する構成が取れるようになっています。ワークロードごとにセキュリティルールを個別管理する負担が大幅に軽減されました。

参考：OneLake Security（プレビュー） / OneLakeのアクセス制御モデル

データ保護：暗号化・情報保護ラベル・DLP・監査ログ

Fabricは、暗号化やコンプライアンス対応といった基盤機能を持っていますが、
利用側での設定と運用も同じくらい重要です。

• 機微データに対する感度ラベル（Sensitivity Label）の付与
• Microsoft PurviewのDLPポリシーによるデータ持ち出しの抑制
• アクセスログや操作ログを監査し、定期的なレビューを行う仕組み

こうした設定により、「誰がどのデータにアクセスしているのか」を説明できる状態を作ることが大切です。

参考：Fabricの情報保護 / FabricのDLPポリシー設定

ネットワーク制御：Managed VNet / Private Endpoint等の考え方

Fabricでは、一部のワークロードでManaged Virtual NetworkやPrivate Endpointを利用できます。
一方で、Copilotや一部クラウドサービス連携との相性も考慮しなければなりません。

• Private Link／閉域ネットワーク構成では、現時点ではCopilotがサポートされないケースがある
• 逆に、インターネット経由のアクセスを許しすぎると、データ漏えいリスクが高まる

そのため、「どのワークスペースはManaged VNetで閉じるのか」「どこまでCopilotや外部連携を許容するのか」といったゾーニング設計が重要になります。

参考：Managed VNetの概要 / Private Linkの概要

Microsoft Purviewとの連携でできること（カタログ・リネージ・ポリシー）

Microsoft Purviewと連携することで、次のようなガバナンス機能をFabricに適用できます。

• データ資産のカタログ化（どこにどんなデータがあるかの可視化）
• データリネージ（どのソースからどのレポートに至るか）の可視化
• 感度ラベルとポリシーの一元管理

複数部門でFabricを利用する場合は、Purviewを使って「企業全体のデータ辞書＋ガバナンス基盤」を整備するイメージが現実的です。

参考：PurviewによるFabricガバナンス / FabricのPurviewハブ

---

Microsoft Fabricに関するよくある質問（FAQ）

最後に、導入検討時によく挙がる質問をQ&A形式で整理します。
詳細は本文の該当セクションや公式ドキュメントも併せてご確認ください。

Q. Fabricと従来のSynapse / Power BI単体はどう違いますか？

A. 大きな違いは、OneLakeとSaaSとしての一体感です。
SynapseやPower BIでは、サービスごとにリソースや設定が分かれていましたが、Fabricでは「ワークスペース＋Capacity＋OneLake」という共通の枠組みで運用できます。

既存環境をすぐに廃止する必要はありませんが、新規プロジェクトではFabric前提のアーキテクチャを検討するケースが増えています。

Q. 小規模・スモールスタートでも導入メリットはありますか？

A. あります。
特に次のような状況では、F2〜F4クラスのCapacityでのスモールスタートが現実的です。

• これからデータ基盤を整備しようとしている中小規模組織
• 既存のBI環境を整理しながら、生成AIとの連携も視野に入れたいチーム

OneLake＋Power BIの組み合わせだけでも、既存の「Excel＋オンプレDB」構成に比べて、運用の見通しを立てやすくなります。

Q. どの程度のデータ量・組織規模から検討するとよいですか？

A. 明確な閾値があるわけではありませんが、次のような兆候が見えてきたら検討のタイミングです。

• 部門ごとにデータマートが乱立し、「どれが正しい数字か分からない」状態になりつつある
• 個別システム間のデータ連携に時間がかかり、分析より連携作業の方が負荷になっている
• 生成AIの活用を検討しているが、そもそもデータの所在や品質が整理されていない

こうした状況では、「データ基盤＋AIプラットフォーム」としてFabricを位置付ける価値が高くなります。

Q. 既存のDWHやデータレイクとどう共存させればよいですか？

A. いきなり完全移行するのではなく、ShortcutやMirroringを使った共存構成から始めるのがおすすめです。

• 既存データレイクの一部をShortcutで参照し、Fabric側で分析・可視化を試す
• 運用DBはMirroringで一部テーブルから同期し、リアルタイム分析の候補を探る

徐々にOneLake側に主軸を移していくことで、リスクを抑えながら移行できます。

Q. CopilotなしでFabricだけ導入することは可能ですか？

A. 可能です。
CopilotはあくまでオプションのAI機能であり、Fabricのデータ基盤としての価値はCopilotがなくても成立します。

一方で、2025年4月以降はF2以上の全有償SKUでCopilotが利用可能になったため、追加コストなく試せる環境が整っています。「まずはCopilot抜きで基盤を整え、あとからCopilotを段階的に解放していく」という段階的な導入パターンも考えられます。

Q. Power BI Premium P SKUの契約終了後はどうすればよいですか？

A. P SKUの契約終了後は、Fabric Capacity（F SKU）への移行が必要です。Microsoftは大規模環境向けの自動移行ツールを提供しており、ワークスペースの再割り当てを効率化できます。

移行後はF SKUの容量に応じてワークスペースを運用する形になります。P SKUとF SKUでは課金モデルが異なるため（F SKUはPay-as-you-goまたは予約の2方式）、既存の利用パターンを分析したうえで最適なSKUサイズと支払い方法を選定することが重要です。

---

Fabricで統合したデータをAIエージェントが業務に活かすなら

Fabricでデータ基盤を整備した次のステップは、そのデータを実際の業務アクションにつなげることです。「分析して終わり」ではなく、データ取得から報告・申請・承認までをAIエージェントが一気通貫で実行する仕組みが求められています。

AI Agent Hubは、Microsoft Fabric（OneLake）をデータ基盤として活用し、Zero ETLで仮想統合されたデータにAIエージェントが直接アクセスして業務を自動実行するエンタープライズAI基盤です。

• Fabric × AIエージェントでデータの民主化
  SAP・Salesforceなどの基幹システムデータをFabric OneLakeに仮想統合。Teamsチャットから自然言語で問い合わせ、取得した結果をそのまま報告・申請・承認に変換します。
  
  
• Agentが動くほどデータが蓄積される好循環
  AIエージェントの実行ログ・承認履歴・ROIデータがすべてFabricに集約。ビッグデータ分析やエージェント改善に自社データを活きた資産として活用できます。
  
  
• 構築基盤が違っても管理は1つ
  Microsoft FoundryでもN8nでも、どこで構築したAgentも1つの管理ダッシュボードに集約。実行ログ・権限・セキュリティチェックを一元管理します。

AI総合研究所の専任チームが、設計から運用まで伴走支援します。まずは無料の資料で、自社の業務にどう活用できるかご確認ください。

まとめ

本記事では、Microsoft Fabricの概要から構成要素、OneLakeの設計思想、CopilotやAI機能、料金・ライセンス体系、使い方と構成パターン、セキュリティとガバナンスまでを整理しました。

• Microsoft Fabricは、OneLake＋複数ワークロード＋Capacityという枠組みで、データ収集から可視化・AI活用までをSaaSとして一気通貫に提供するプラットフォームです
• FabCon 2026ではFabric Graph・OneLake Security・Data AgentsのGAが発表され、「データ基盤」から「インテリジェンスプラットフォーム」への進化が加速しています
• データ複製を前提にしないOne Copyの設計や、Shortcut / Mirroringを通じた既存環境との共存が大きな特徴です。Snowflakeとの双方向Icebergデータ読み取りもGAとなり、マルチクラウドでの柔軟な構成が取りやすくなりました
• 2025年4月のCopilot全SKU開放により、F2以上のCapacityがあればすぐにAI支援を試せる状態です
• Power BI Premium P SKU（非EA契約）は2026年1月に販売終了済み。新規のBI・分析基盤はFabric前提で設計すべきタイミングに入っています

「データマートが部門ごとに乱立し、正しい数字がどれか分からない」「生成AIを活用したいが、そもそもデータの所在や品質が整理されていない」——こうした状態にあるなら、Fabricはその構造的な課題を解決するための選択肢になります。

次のステップとして推奨するのは、まず1つのユースケース（営業ダッシュボード、ログ分析、ナレッジ検索など）に絞ってF2でPoCを始めることです。60日間の無料トライアルでも機能検証は可能ですが、CopilotやAI機能を試す場合はF2以上の有償Capacityが必要な点に注意してください。PoCで効果を実証してから、F8→F32→F64とCapacityを段階的に拡大していくのが、コストリスクを抑えた現実的な導入パターンです。

---

Microsoft Fabricの導入支援はAI総合研究所へ

Fabricは機能が広く、Capacity設計・OneLake構成・セキュリティ・コスト管理まで含めた全体設計が求められます。社内だけで検証・運用まで完結させるのは大きな負担になるケースも少なくありません。

AI総合研究所では、Microsoft FabricとAzure AIを組み合わせたデータ基盤＋生成AIの設計・導入支援を行っています。

• PoC支援
  既存環境のヒアリングからスコープ整理、ワークスペース／Capacity構成の初期設計まで、小さく試すところから伴走します。
  
  

• 本番導入・運用設計支援
  Capacity・OneLake設計、ID・権限設計、コスト管理・運用ルールの整備など、全社展開を見据えたアーキテクチャを一緒に作り込みます。
  
  

• 生成AI統合支援
  OneLake／Azure AI Search／Azure OpenAI Serviceを組み合わせたRAGやAIエージェントのアーキテクチャ設計・業務組み込みを支援します。
  
  

• マルチプラットフォーム対応
  Microsoft Fabric、Snowflake、Databricks、AWS、GCPなど、ビジネス要件に最適なデータプラットフォームを選定・構築します。

ご相談・お問い合わせフォーム（AI総合研究所）