実務で急にMicrosoft Fabricを使うことになった人のためのキャッチアップガイド — 基本操作チェックリストと「初日に聞くべき質問」

はじめに

「来月からMicrosoft Fabricを使ったデータ分析基盤の案件に入ってね」——そう言われて検索を始めたエンジニアのためのガイドです。

Fabricは機能が非常に多く、公式ドキュメントを頭から読んでいると初日を迎えてしまいます。本記事では、実案件へのアサインを機にキャッチアップの手順を体系化した経験をもとに、現場で最低限押さえるべき基本操作のチェックリストと、意外と誰も教えてくれない**「アサイン初日にプロジェクトメンバーへ聞くべき質問リスト」**の2本立てで、最初の壁を越えるための道筋をまとめます。

対象読者

• 急にMicrosoft Fabricの実務案件に配属された初学者・新人エンジニア
• Azureのインフラ構築経験はないが、SQLやPythonの基礎知識はある方
• メダリオンアーキテクチャを用いたデータ処理の全体像をサクッと掴みたい方

2023年のGA(一般提供開始)以降、Fabricはデータ分析基盤の選択肢として注目されており、実務で触れる機会は今後も増えていくはずです。「そもそもどこから触り始めればいいのか分からない」という段階の方に向けて書いています。

Microsoft Fabricの全体像

Microsoft Fabricは、データ統合、データエンジニアリング、データサイエンス、そして可視化(Power BI)など、データ分析に必要なツールを一つにまとめたSaaS型の統合データプラットフォームです。

最大の特徴は、すべてのデータが「OneLake(ワンレイク)」と呼ばれる単一のストレージ——いわばデータのためのOneDrive——に集約される点です。これにより、ツール間でデータをコピーしたり移動させたりする手間が省けます。

Azureとの関係:「Azureポータルに出てこない」のはなぜか

Fabricを触り始めた人が最初に混乱するポイントがここです。筆者も「FabricとAzure Synapse / Data Factoryは何が違うのか」「なぜAzureポータルにFabricのリソースが見当たらないのか」で戸惑いました。

答えはシンプルで、FabricはAzureの「上」で動くSaaSであり、日々の操作はAzureポータルではなく専用ポータル(app.fabric.microsoft.com)で行うためです。SaaSモデルのため、AzureサブスクリプションにVMや仮想ネットワーク、ストレージアカウントといったリソースは一切現れません。それらの詳細は利用者から隠されています。

唯一Azureリソースとして現れるのが、課金単位である**Capacity(容量)**です。Capacityは名前・SKU(F2, F64など)・リージョンを持つだけのシンプルなリソースとして作成され、利用料金はAzureポータルのMicrosoft Cost Management上でサブスクリプション配下に表示されます。つまり「計算資源の購入だけAzure、仕事はFabricポータル」という関係です。

Azure SynapseやAzure Data Factory(ADF)との関係も押さえておきましょう。Fabricはこれらの機能を統合・継承した後継的な位置づけのサービスで、Microsoft自身が「Fabric Data FactoryはADFの実績ある機能をSaaSファーストな単一プラットフォームに統合したもの」と説明しています。Fabricの中に出てくる「Data Factory」や「Synapse Data Engineering」という名前は、既存Azureサービスの進化形だと理解しておくと、既存の知識やドキュメントを流用しやすくなります。

参考: What is Microsoft Fabric?(Microsoft Learn) / Fabric Capacity の Azure 請求について(Microsoft Learn)

実務で押さえるべき特性(強み・制約)

強み

• SaaSならではの手軽さ: インフラ構築(ネットワーク設定やサーバー立ち上げ)が不要で、すぐにデータ分析を始められる
• データのサイロ化解消: OneLakeにより、組織内のデータが一元管理される
• Power BIとの強力な連携: 「Direct Lake」モードにより、インポート処理なしでOneLake上のデータをPower BIから高速に読み込める

制約・注意点

• 細かなインフラチューニングができない。 SaaSである以上、コントロールできる範囲には明確な境界があります。「できること/できないこと」の境界線を下表にまとめました(詳細は折りたたみ)

Fabricでチューニング「できること/できないこと」一覧

チューニングの対象	Fabricで「できること」	Fabricで「できないこと」
マシンのスペック	処理エンジン(Spark)のサイズ(小/中/大など)の選択、ノードの増減(オートスケール)	仮想マシンの具体的なCPU型番、メモリ比率、ディスク種別(SSD/HDD)の指定
ネットワーク	プライベートエンドポイント経由でのセキュアなデータ接続	仮想ネットワーク(VNet)のサブネット分割、ルーティングテーブルの細かい制御
ソフトウェア・OS	Pythonライブラリの追加インストール、Sparkエンジンの設定値変更	OSのアップデート、セキュリティパッチの適用、ドライバーの細かいバージョン指定
ストレージ	Delta Lakeの最適化コマンド(OPTIMIZEなど)の実行	OneLakeの裏側にある物理ストレージのIOPS(読み書き速度)の割り当て
コストとリソース	ワークスペースごとのCapacity(コンピューティング容量)の割り当て変更	夜間に仮想マシンを完全に「シャットダウン」してVM料金をゼロにするような運用

• 容量(Capacity)ベースの独特な課金体系。 「CU(Capacity Unit)」という単位でコンピューティングを消費するモデルのため、コスト管理の概念を別途学ぶ必要があります
• 進化が非常に速い。 Fabricは毎週のように新機能・仕様変更が発表されており、数ヶ月前のブログ記事の手順が既に古くなっていることが珍しくありません(本記事の後半で扱う「セマンティックモデルの自動作成廃止」はその典型例です)。困ったら個人ブログより先に公式ドキュメントとFabric Updates Blogを確認する習慣をつけましょう
• 発展途上のサービスのため、枯れた技術と比べると日本語のトラブルシューティング情報が少なめ

基本操作チェックリスト

ここからが本題の前半です。実務で必ず触れることになる基本操作を、データの流れに沿ってリストアップしました。まずは各操作をUI上のどこから実行するのかを、トライアル環境で一通り確認しておきましょう。

1. ワークスペースの作成と管理

Fabricのすべての作業は「ワークスペース」という箱の中で行われます。

• ワークスペースの作成: 左側のナビゲーションバーから「ワークスペース」を選択し、新しいワークスペースを作成する
• ライセンスの確認: ワークスペースの設定から、Fabricの容量(トライアルやF SKUなど)が正しく割り当てられているか確認する
• 権限の付与: メンバーのアクセス許可(管理者/メンバー/共同作成者/閲覧者)を適切に設定する。このロールは後述のミラーリング作成可否などにも影響します

2. レイクハウス (Lakehouse) の作成

メダリオンアーキテクチャ(ブロンズ・シルバー・ゴールド層)を構築するためのデータの保存場所です。

• レイクハウスの新規作成: ワークスペース内で「+ 新規」から「レイクハウス」を作成する
• ファイル領域とテーブル領域の理解: レイクハウス内の「Files(非構造化・生データ)」と「Tables(Delta形式の構造化データ)」の違いをUI上で確認する

3. データの取り込み (Ingestion)

外部からOneLakeへデータを持ってくる操作です。Fabricには大きく3つの方式があり、「データの実体がどこにあるか」「更新にどう追従するか」で使い分けます。この概念を頭に置いておくと、既存プロジェクトの設計を読み解くスピードが大きく変わります。

方式	データの実体	更新への追従	向いているケース
① コピー(パイプライン)	OneLakeにコピーされる	バッチ実行のたびに反映	ファイル・API・加工前提の取り込み全般
② ショートカット	ソース側のまま(参照のみ)	常に最新(実体は動かない)	S3やADLS Gen2など、既存データレイクを動かせない/動かしたくない場合
③ ミラーリング	OneLakeに複製される	CDCでほぼリアルタイムに同期	運用DB(OLTP)のデータを分析に使いたい場合

「データの実体がどこにあるか」だけを図にすると、3方式の違いは一目瞭然です。

• データパイプライン (Data Factory) の作成: 「データのコピー」アクティビティを使って、外部のデータベースやAPIからレイクハウスのFiles領域にデータをインポートする
• ショートカットの作成: データを実際にコピーせず、AWS S3やAzure Data Lake Storage (ADLS) Gen2のデータをOneLake上にあるかのように見せる「ショートカット」機能の場所を確認する
• ミラーリングの作成場所の確認: ワークスペースの「+ 新規」から「ミラーデータベース」を選び、Azure SQL DatabaseなどのソースDBを継続レプリケーションできることを確認する。ソースDBへの接続を作成し、DB全体か個別テーブルかを選ぶだけで、変更が自動的にOneLakeへ同期され続けます
• ミラーリングに必要な権限の確認: 接続の「両端」でそれぞれ許可が必要です。Fabric側では、ミラードデータベースを作成するためにワークスペースのAdminまたはMemberロールが必要(共同作成者以下では作成できません)。ソースDB側では、接続に使うアカウントに ALTER ANY EXTERNAL MIRROR 権限(CONTROL権限やdb_ownerロールに含まれる)が必要です。実務では最小権限のアカウントを使うことが多いため、DB管理者への権限付与依頼が発生しがちなポイントです

ミラーリングの具体的な設定手順(接続作成やゲートウェイ構成など)は本記事のスコープ外とします。手を動かしたい方は公式チュートリアル Azure SQL Databaseのミラーリング構成(Microsoft Learn) と、日本語の実践例として Microsoft Fabric のミラーリング:Azure SQL Database(DOORS DX) を参照してください。

4. データの加工 (Transformation)

取り込んだ生データを加工し、分析しやすい形に変換します。実務ではノートブックがよく使われます。

• ノートブックの作成とアタッチ: ノートブックを作成し、対象のレイクハウスをアタッチ(接続)する
• PySparkでのデータ読み書き: Files領域のCSVやJSONをPySparkのデータフレームとして読み込み、加工後、Tables領域にDelta形式として保存する。最小の流れは次の通りで、このままノートブックに貼って動きを確認できます

from pyspark.sql import functions as F
 
# ① Files領域(生データ)のCSVをデータフレームとして読み込む
df = (
    spark.read.format("csv")
    .option("header", "true")
    .option("inferSchema", "true")
    .load("Files/raw/sales.csv")
)
 
# ② 簡単な加工(列の選択と型変換の例)
df_clean = (
    df.select("order_id", "order_date", "amount")
      .withColumn("order_date", F.to_date("order_date"))
)
 
# ③ Tables領域にDelta形式のテーブルとして保存(シルバー層の例)
df_clean.write.format("delta").mode("overwrite").saveAsTable("silver_sales")

• SQLでのデータ加工: PySparkだけでなく、Spark SQLを使ってデータの集計や加工ができることを確認する

5. データの確認 (SQL分析エンドポイント)

保存したデータをSQLでサクッと確認するための機能です。

• ビューの切り替え: レイクハウスの画面右上から、表示モードを「レイクハウス」から「SQL分析エンドポイント」に切り替える
• SQLクエリの実行: T-SQLを使って、テーブル化されたデータに対してSELECT文を投げ、データが正しく加工されているか確認する

6. Power BI連携への準備 (セマンティックモデル)

加工したデータ(ゴールド層)をPower BIで可視化するための下準備です。

ここは古い記事に要注意のポイントです。 以前は、レイクハウスを作成すると「デフォルトセマンティックモデル」が自動的に作られていました。しかし2025年9月5日以降、この自動作成は廃止され、既存のデフォルトセマンティックモデルも2025年11月末までにアイテムから切り離されて独立したモデルになりました。ガバナンス強化(モデルの所有者と責任を明確にする)のための変更です。「自動的に作成されるモデルを確認しましょう」と書かれている記事は、現在の仕様より古い情報だと判断できます。

• セマンティックモデルの明示的な作成: レイクハウスを開き、リボンから「新しいセマンティックモデル」を選択して、モデルに含めるテーブルを選んで作成する
• リレーションシップの設定: モデリングビューを開き、ファクトテーブルとディメンションテーブルの間でリレーションシップ(スタースキーマ)を線で結んで作成する
• Power BIレポートの新規作成: セマンティックモデルの画面から「新しいレポート」を選択し、Direct Lakeモードでレポート作成画面が立ち上がることを確認する。なお、現在のDirect Lakeには「Direct Lake on OneLake」と「Direct Lake on SQL」の2形態がありますが、最初は「OneLakeから直接読む高速モード」という理解で十分です

参考: Sunsetting Default Semantic Models(Microsoft Fabric Blog) / Power BI セマンティックモデルの作成(Microsoft Learn)

プロジェクト固有の確認事項:初日に聞くべき質問リスト

ここからが本題の後半です。基本操作は独習できますが、プロジェクトの設計方針は聞かないと分かりません。ここでは、アサイン初日〜1週目にプロジェクトメンバーへ確認しておくと立ち上がりが速くなる質問を、意図とセットでまとめました。

1. 全体アーキテクチャとデータソース

• Q. 元データ(ソースデータ)はどこにあり、どのような頻度・規模で連携されてきますか?
  • 意図: オンプレミスか、他クラウド(GCP/AWS)か。バッチ(日次/時次)かストリーミングか。データボリュームによってSparkのチューニング方針が変わるため
• Q. 外部データは「コピー」「ショートカット」「ミラーリング」のどれで取り込んでいますか?
  • 意図: 前章の3方式のどれを採用しているかで、データ鮮度・障害時の切り分け方・ネットワーク要件が変わる。セキュリティ制約でショートカットが使えないケースもあるため、設計方針の背景ごと確認する
• Q. メダリオンアーキテクチャの3層(ブロンズ・シルバー・ゴールド)は、物理的にどう分割されていますか?
  • 意図: 「1つのレイクハウス内でスキーマを分けている」のか、「層ごとにレイクハウス(またはワークスペース)自体を分けている」のか、環境の全体図を把握するため

2. データエンジニアリング(ETL処理)

• Q. データ加工のメインツールは「ノートブック(PySpark/SQL)」と「Dataflow Gen2」のどちらが主軸ですか?
  • 意図: コードベース(PySpark)を好むか、GUIベース(Dataflow)を好むかはプロジェクトによって方針が分かれるため
• Q. データの差分更新(Upsert)や冪等性の担保は、どのような実装パターンですか?
  • 意図: テーブルの洗い替え(Overwrite)で済ませているのか、MERGE INTO などで厳密に状態管理しているのかを確認し、実装の複雑さを測るため
• Q. パイプラインのオーケストレーションにおける、エラー時のリトライや通知のルールはどうなっていますか?
  • 意図: どこまでをパイプライン側で制御し、失敗時にどうリカバリするかの運用ルールを把握するため

3. データモデリングとPower BI(可視化)

• Q. ゴールド層のデータは、厳密な「スタースキーマ(ファクトとディメンション)」でモデリングされていますか?
  • 意図: Power BIのパフォーマンスを最大限に引き出すための前提条件が満たされているか確認するため
• Q. Power BIからの接続はすべて「Direct Lakeモード」ですか?一部「インポートモード」にフォールバックしているものはありますか?
  • 意図: Direct Lakeは強力だが、一部の複雑なDAXや特定の条件下ではフォールバックする制約があるため、現状の課題を把握する
• Q. 複雑なビジネスロジック(計算)は、加工側(PySpark/SQL)と可視化側(DAX)のどちらに寄せる方針ですか?
  • 意図: 「どこで計算させるか」はBI基盤の永遠のテーマ。可能な限り上流(ゴールド層)で済ませるのがセオリーだが、プロジェクトの設計思想を確認する

4. CI/CD・IaC(運用)

• Q. 開発・テスト・本番のワークスペースはどのように分離されていますか?
  • 意図: 環境分離の方式(ワークスペース分離+デプロイパイプライン等)を把握するため
• Q. リソース作成や権限管理にIaC(Terraformなど)は導入されていますか?
  • 意図: Fabricには公式のTerraformプロバイダーや、デプロイ自動化ツール(fabric-cicd等)が整備されてきている。手作業での環境構築を避ける仕組みの有無と、使っているツールを確認する
• Q. ノートブック等のコードのバージョン管理・デプロイは「Fabric Git統合」を使用していますか?
  • 意図: CI/CDパイプラインの構成と、どのリポジトリ(Azure DevOps / GitHub)を見ればよいかを把握するため

5. セキュリティ・ガバナンス

• Q. 個人情報や機密データはどの層に、どのような形(マスキング/仮名化など)で保持されていますか?
  • 意図: 誤って機密データを閲覧・出力・共有してしまう事故を防ぐため、扱いのルールを最初に把握する
• Q. 行レベルセキュリティ(RLS)や列レベルの制御は、どのレイヤーで実装していますか?
  • 意図: RLSはSQL分析エンドポイント側とセマンティックモデル(Power BI)側のどちらでも実装でき、管理方法が異なる。またミラーリングではソースDB側のRLS設定がOneLakeへ伝播しないなどの制約もあるため、どこで守っているかを確認する
• Q. Microsoft Purviewなどのガバナンスツールや秘密度ラベルは運用されていますか?
  • 意図: ラベル付けやカタログ登録が必須のプロジェクトでは、成果物を作るときの作法が変わるため

6. コスト・Capacity運用

• Q. CU(Capacity Unit)の消費はどうやって監視していますか?
  • 意図: Fabric Capacity Metricsアプリの導入有無と、誰が日常的に見ているかを確認する。自分の処理がどれだけCapacityを食っているか把握できる状態にするため
• Q. スロットリング(容量超過時の処理遅延・拒否)が発生した場合の対応ルールはありますか?
  • 意図: Capacityはワークスペース間で共有されるため、自分の重いノートブック実行が他チームのレポートを遅くする事故が起こり得る。重い処理を流してよい時間帯や事前連絡のルールを確認する
• Q. Capacityの管理責任者は誰で、一時停止・スケール変更の権限は誰が持っていますか?
  • 意図: コストに直結する操作の責任範囲を知り、自分が誤って触ってはいけない領域を認識するため

まとめ

Microsoft Fabricは機能が非常に多いため、最初はその巨大さに圧倒されるかもしれません。しかし、キャッチアップは次の2本柱で考えれば十分です。

1. 一般的な基本操作: 「ワークスペース作成 → レイクハウス作成 → データ取り込み(コピー/ショートカット/ミラーリング) → ノートブックで加工 → セマンティックモデル作成」という一連のルートをトライアル環境で一巡する
2. プロジェクト固有の設計方針: 本記事の質問リストを持って、初日にメンバーへ確認する

インフラ構築の泥臭い作業がない分、データの中身(SQLやPySparkでの加工、DAXを使った分析)に集中できるのがFabricの魅力です。一方で進化が速いサービスでもあるので、公式ドキュメントとFabric Updates Blogを一次情報として追いかける習慣もセットで身につけていきましょう。

参考文献

• What is Microsoft Fabric?(Microsoft Learn)
• Fabric Capacity の Azure 請求について(Microsoft Learn)
• ミラーリングの概要(Microsoft Learn)
• チュートリアル: Azure SQL Database のミラーリング構成(Microsoft Learn)
• Sunsetting Default Semantic Models(Microsoft Fabric Blog)
• Power BI セマンティックモデルの作成(Microsoft Learn)
• Fabric Updates Blog(公式・毎月の機能アップデートまとめ)
• Microsoft Fabric利用の第一歩:必要な準備について(DOORS DX)
• Microsoft Fabric のミラーリング:Azure SQL Database(DOORS DX)
• Microsoft Fabric徹底入門 〜 Microsoft Fabricとは?(Zenn)
• Microsoft Fabric 始め方(Qiita)