【Microsoft Fabric①】Fabricとは？ OneLake・ワークスペース・ワークロードの全体像

「データ分析をやりたいけど、Azureには Synapse・Databricks・Data Factory・Power BI と似たようなサービスが多すぎて、どれをどう組み合わせればいいのか分からない」——そう感じたことはありませんか。Microsoft Fabric は、まさにその「バラバラの分析基盤」を1つにまとめるために生まれた、SaaS型の統合分析プラットフォームです。

Fabricって名前は聞くけど、結局Synapseと何が違うの？ OneLakeってよく出てくるけど、それも正直ふわっとしてる…

この記事は、Microsoft Fabricシリーズの第1回として、Fabricの「概要」だけに絞って次の5つを順番に整理します。読み終えたときに、この5つを自分の言葉で説明できるようになることをゴールにしています。

• Fabricが何か（SaaS型の統合分析プラットフォーム）を説明できる
• OneLake の概念（テナント全体で1つのデータレイク）を理解している
• ワークスペースと容量（Capacity） の関係を理解している
• 主要なワークロード（体験）の役割を把握している
• レイクハウスとウェアハウスの違いを理解している

取り込み・メダリオン・Direct Lake・リアルタイム・運用といった具体的な話は後続の記事に譲り、ここでは「そもそもFabricとは何者なのか」という土台を固めます。各セクションの最後に「これが説明できればOK」という自己チェックの目安を置いていますので、学習の到達度確認にも使ってください。

Microsoft Fabricとは？（SaaS型の統合分析プラットフォーム）

Microsoft Fabricとは、データの取り込み・加工・分析・可視化までを1つの環境で完結できる、SaaS型の統合分析プラットフォームです。データエンジニアリング、データウェアハウス、リアルタイム分析、Power BIまでを、同じ土台の上でシームレスに扱えます。

ポイントは 「SaaS型」 という部分です。従来のAzureでデータ基盤を組もうとすると、Data Factoryでパイプラインを作り、Synapseでウェアハウスを立て、ストレージアカウントを用意し、Power BIを別で契約し……と複数のサービスを自分で繋ぎ合わせる必要がありました。リソースグループ、RBAC、ネットワーク、冗長化といったインフラの面倒も全部こちら持ちです。

Fabricは、これらを「最初から1つに束ねた完成品」として提供します。イメージとしては、部品を買ってきて自分で組み立てる「自作PC」に対して、Fabricは電源を入れればすぐ使える「一体型のオールインワンPC」のような存在です。実際、FabricはAzureアカウントすら必須ではなく、インフラの複雑さを意識せずに分析を始められます。

もう少し具体的に、Fabricが束ねているものを整理するとこうなります。

• 役割ごとのワークロード：データエンジニア・データサイエンティスト・アナリスト・DB担当それぞれに最適化された体験が、同じ環境の中に揃っている。
• OneLakeという共通ストレージ：全ワークロードが同じ1つのデータレイクを使うため、データのコピーや移動が不要になる。
• Copilot・ガバナンスが標準搭載：AIによる作成支援や、Purviewベースのガバナンス（権限・機密ラベル・監査）が最初から組み込まれている。

【ここが説明できればOK①】
「Fabricは、取り込みから可視化までを1つの環境で完結できるSaaS型の統合分析プラットフォームで、インフラの組み合わせを自分でやらずに済む」——これを自分の言葉で言えれば、1つ目のチェックはクリアです。

OneLake｜テナント全体で1つのデータレイク

Fabricを理解するうえで最重要の概念が OneLake です。Fabricを学ぶと必ず出てくるこの言葉が、Fabricの土台そのものです。

OneLakeとは、テナント全体で共有される「たった1つのデータレイク」です。組織のすべてのデータが、この単一のストレージに集約されます。

公式がよく使う例えが 「データ版のOneDrive」 です。会社でOneDriveを使うとき、私たちは「ストレージがどのサーバーにあるか」を意識しません。ただファイルを置けば、組織の誰とでも共有できます。OneLakeもこれと同じで、組織に1つだけ存在するデータの置き場所として振る舞います。

技術的には、OneLakeは Azure Data Lake Storage (ADLS) Gen2 の上に構築されており、データは Delta Lake / Parquet というオープンな形式で保存されます。ここが効いてくるのが、「1つのデータを、複数のワークロードがコピーせずに共有できる」という点です。

OneLake（テナントに1つ・組織全体の唯一のデータレイク）
│
├─ ワークスペースA
│   └─ レイクハウス（ファイル/フォルダ/テーブル）
│
├─ ワークスペースB
│   └─ ウェアハウス
│
└─ ワークスペースC
    └─ Power BI セマンティックモデル

→ どのワークロードも「同じOneLakeのデータ」を直接参照
   （データを何度もコピーしない ＝ ゼロコピー）

従来はData Factory用・Synapse用・Power BI用と、同じデータを何度もコピーして各サービスに配るのが当たり前でした。OneLakeは「データは1か所、参照するのはみんな同じ場所」という発想に変え、データのサイロ化（分断）とコピーの無駄をなくします。この「Fabricの全機能がOneLakeという1つの湖を共有する」という一枚岩の構造こそ、Fabricの心臓部です。

「OneLake＝組織にたった1つのデータの湖。全ワークロードがそこを直接見る」。この一言が腑に落ちれば、Fabricの半分は理解したようなものだよ！

【ここが説明できればOK②】
「OneLakeはテナント全体で共有される唯一のデータレイクで、全ワークロードがコピーせずに同じデータを参照する（データ版OneDrive）」——これを説明できれば、2つ目のチェックはクリアです。

ワークスペースと容量（Capacity）の関係

Fabricを触り始めると、必ず出てくるのが ワークスペース と 容量（Capacity） の2つです。この2つの役割分担を分けて理解しておくと、後の料金・運用の話がスッと入ってきます。

• ワークスペース＝成果物を入れる「フォルダ・作業部屋」。レイクハウス、ウェアハウス、パイプライン、Power BIレポートなどのアイテム（成果物）を置く入れ物です。チームやプロジェクト単位で分けるのが基本。
• 容量（Capacity）＝処理を動かす「エンジン・計算リソース」。ノートブックの実行、パイプラインの処理、クエリの計算などに使うCPUパワーを供給する契約です。F SKU（F2〜F2048） という単位で契約し、大きいほど強力。

両者の関係を図にするとこうなります。ワークスペース（部屋）が容量（エンジン）に紐づいて、初めて処理が動くという構造です。

容量（Capacity: F64 など）  ← 計算パワーを供給するエンジン
│
├─ ワークスペースA（部門1の作業部屋）
│   ├─ レイクハウス
│   └─ パイプライン
│
└─ ワークスペースB（部門2の作業部屋）
    └─ Power BI レポート

→ どのワークスペースの処理も、紐づいた「容量」の
   CU（Capacity Unit）を消費して動く

大事なのは、「成果物を置く場所（ワークスペース）」と「処理を動かす力（容量）」は別物だということです。1つの容量に複数のワークスペースをぶら下げて共有することもできます。この分離があるからこそ、後の記事で扱うコスト管理（＝容量の使用量をどう監視・制御するか）が独立したテーマになるわけです。

【ここが説明できればOK③】
「ワークスペースは成果物を置く入れ物、容量（F SKU）は処理を動かす計算リソース。ワークスペースが容量に紐づいて処理が動く」——これを説明できれば、3つ目のチェックはクリアです。

主要なワークロード（体験）を把握する

Fabricは、役割ごとに最適化されたワークロード（体験）の集合体です。全部を今すぐ使いこなす必要はありませんが、「どれが何のためのものか」の地図を持っておくと、学習でも実務でも迷いません。主要なものを一覧にします。

この一覧を見て「多いな」と感じるかもしれませんが、実は流れは一本です。Data Factoryで取り込み → Data Engineeringで加工 → Data Warehouseに整理 → Power BIで可視化、というのが王道のパイプラインで、Real-Time Intelligenceは「リアルタイム版の取り込み〜分析」、Databasesは「業務データをそのままFabricに取り込む入口」というふうに、それぞれが役割分担しています。

さらに2026年時点では、これらに加えて Fabric IQ というAI向けの新しいワークロード（データに自然言語で問い合わせるData Agentを含む）も登場しています。このAI連携は本シリーズの第4回で扱います。まずはここで「主要なワークロードの地図」を頭に入れておけば十分です。

【ここが説明できればOK④】
「Fabricには Data Factory / Data Engineering / Data Warehouse / Data Science / Real-Time Intelligence / Databases / Power BI という役割別のワークロードがあり、取り込み→加工→整理→可視化の流れで繋がる」——これを説明できれば、4つ目のチェックはクリアです。

レイクハウスとウェアハウスの違い

最後に、Fabric初心者が最も混乱しやすい レイクハウス（Lakehouse） と ウェアハウス（Warehouse） の違いを整理します。どちらもOneLake上の「データの入れ物」ですが、得意な扱い方が違います。

選び分けの目安はシンプルです。SparkやPythonでファイルベースの柔軟な加工をしたいならレイクハウス、慣れたT-SQLで構造化データをきっちり扱いたいならウェアハウス。どちらもデータの実体はOneLake上の同じDelta/Parquet形式なので、後から相互に参照することもできます。「まず倉庫（レイクハウス）に何でも入れて、整った部分を図書館（ウェアハウス）に並べる」——先ほどのメダリオン的な流れとも自然に繋がります。

迷ったら、「チームがSpark寄りかSQL寄りか」で決めるのが実務的です。Python/Sparkに慣れたデータエンジニア中心ならレイクハウス、SQLに慣れたメンバー中心ならウェアハウス、という判断で大きく外しません。

【ここが説明できればOK⑤】
「レイクハウスはSpark/ファイル中心で柔軟、ウェアハウスはT-SQL/構造化中心。どちらもOneLake上のデータで、チームがSpark寄りかSQL寄りかで選ぶ」——これを説明できれば、5つ目のチェックはクリアです。

まとめ

今回のポイントを振り返りましょう。この5つを自分の言葉で説明できれば、Fabricの「概要」はバッチリです。

• Microsoft Fabric は、取り込みから可視化までを1つで完結するSaaS型の統合分析プラットフォーム
• OneLake は、テナント全体で共有される唯一のデータレイク（全ワークロードがコピーせず参照）
• ワークスペース＝成果物の入れ物、容量（F SKU）＝処理を動かすエンジン
• 主要ワークロードは Data Factory / Engineering / Warehouse / Science / Real-Time / Databases / Power BI
• レイクハウス＝Spark中心、ウェアハウス＝T-SQL中心。データの実体は同じOneLake

概要がつかめたら、次は実際に データをOneLakeに取り込み、レイクハウスを組み立てる手順 に進みましょう。パイプライン・メダリオン構成・ショートカット・ミラーリングといった「データを集める技術」を第2回で整理します。手を動かすと、今回のOneLakeとワークロードの関係が一気に「腑に落ちる」はずです。

あわせて読みたい

• Azure入門｜クラウドとは・VMかApp Serviceか（はじめの地図）
• 【Azure AI入門①】Azure AI Foundry / Azure OpenAIとは？