Microsoft FabricのLakehouseアーキテクチャをマスターする：ブロンズ、シルバー、ゴールド

By Mirko Peters · 2026-08-28

ポッドキャスト関連ブログへようこそ！最新エピソードでは、Micro…の中での機械学習エンジニアリングの実践的な現実について深く掘り下げました…

Automatically translated with AI from the original post. Read the English original

ポッドキャスト・コンパニオン・ブログへようこそ！最新エピソードでは、Microsoftのエコシステムにおける機械学習エンジニアリングの実践的な現実を深く掘り下げました。まだお聴きでない方は、「Build Machine Learning Models in Microsoft Fabric」をぜひチェックしてください。今回は、そこで扱った内容をさらに広げ、Microsoft Fabric Lakehouseでメダリオンアーキテクチャによってデータを構造化することが、成功し拡張可能な機械学習運用の土台になる理由を解説します。

本番環境に対応する機械学習モデルの構築は、適切なアルゴリズムを選んだりハイパーパラメーターを調整したりするだけではありません。予測モデルの成否は、多くの場合、データの品質、再現可能なパイプライン、そして堅牢なガバナンスによって決まります。Microsoft FabricでLakehouseアーキテクチャを使いこなす方法を見ていきましょう。

アーキテクチャの概要

Microsoft Fabricでエンドツーエンドのデータ／機械学習プラットフォームを設計する際は、データの流れを理解することが欠かせません。すべては統合ストレージレイヤーであるOneLakeから始まります。そこからデータはLakehouseに取り込まれ、ブロンズ、シルバー、ゴールドのDeltaテーブルを経て変換されていきます。

コンピュートについては、Fabric ノートブックにより、Spark、Python、Rを搭載した、事前構成済みのデータサイエンス環境をデータサイエンティストが利用できます。実験の追跡は組み込みのMLflow実行で自然に行え、外部の追跡サーバーを用意しなくてもメトリック、パラメーター、アーティファクトを記録できます。モデルのトレーニングが終わると、バージョン管理、承認、完全なデータリネージを備えた統合レジストリに登録されます。最後に、モデルはマネージドバッチジョブまたはリアルタイムのHTTPエンドポイントとして提供され、Power BI、Power Apps、カスタムAPIクライアントなどのコンシューマーに届けられます。

Lakehouse: 入力を整え、コントロールを保つ

Lakehouseの中核となる考え方は、データレイクの柔軟性とデータウェアハウスの信頼性を組み合わせることです。これを効果的に機能させるには、データを明確に区分された層に構造化する必要があります。

テーブルを層ごとに分ける

• ブロンズ: ここが生データの取り込み層です。データはスキーマオンリード（読み取り時スキーマ）の原則に従ってここに格納され、監査や再処理のために変更不可のまま保持されます。
• シルバー: この層では、データのクレンジング、型の付与、結合を行います。PIIは最小限に抑えられ、初期の品質チェックが適用されます。
• ゴールド: ゴールド層には、明確で文書化されたデータコントラクトに基づく、機械学習モデルがそのまま利用できる機能対応の集計データが含まれます。

目的に応じたアクセス制御

ワークスペースのロールベースアクセス制御とテーブルレベルのアクセス制御リストを組み合わせて使用してください。データサイエンティストにはシルバーテーブルとゴールドテーブルへの読み取りアクセスを与え、書き込みアクセスは機能テーブルと実験用ディレクトリに限定します。

データ品質のガードレール

NULL禁止、値の範囲、参照整合性に対する厳格な期待値を実装してください。チェックに失敗した行は直接 _quarantine テーブルにルーティングします。そうすることで、下流のパイプラインが黙って失敗したり、破損したデータを取り込んだりすることを防げます。

軽量な機能ストア

再利用可能な機能はゴールドテーブルとして扱います。たとえば feat_customer_rolling_90d のようにします。そのうえで、各機能が何を表しているかをチーム全員が理解できるよう、YAML形式のデータディクショナリを添えてください。

面倒なく使えるノートブック

開発者それぞれが異なる環境に依存すると、共同でのコーディングはすぐに収拾がつかなくなります。Fabricでは pandas、PySpark、scikit-learn、PyTorch を含む事前インストール済みのカーネルが提供されており、全員が完全に同じ基準から作業できます。

探索用ノートブック、特徴量エンジニアリングのスクリプト、モデルのトレーニングルーチン、構成ファイルを分けた、構造化されたプロジェクトレイアウトを採用してください。再現性はUIでの手作業のクリックに頼らず、コードで担保します。Spark SQLでLakehouseからデータを読み取り、最終的な機能はDeltaテーブルとして書き出します。また、チームがすべての完全なデータセットへのクエリを待たずに素早く反復できるよう、開発用の小さなサンプルテーブルを常に用意してください。

MLflow（組み込み）ですべてを追跡する

手作業でモデルの実験を記録すると、結果を再現できなくなります。Fabric に組み込まれている MLflow 連携を使えば、実行ごとの比較可能性、完全な監査可能性、そして新しくデプロイしたモデルの性能が低い場合の簡単なロールバックを確保できます。

すべてのハイパーパラメーター、評価メトリック、学習済みモデルの成果物を、トレーニングスクリプトの中で直接記録してください。実行には、データ期間、特徴セットのバージョン、コードのコミットハッシュなどのコンテキスト メタデータでタグを付け、学習用テーブルを特定の Delta スナップショット バージョンに固定してください。

レジストリ、承認、およびリネージ

実験から本番環境へのモデルの移行は、勘に頼るものであってはなりません。性能の高い実行を、1.0.0 のようなセマンティック バージョニングを使って登録モデルに昇格させてください。データサイエンスの責任者とビジネスの責任者の両方による承認を必要とする 2 段階の承認プロセスを実装してください。最後に、モデルの目的、データの範囲、公平性に関する注記、監視のサービス レベル目標を詳しく記載した、包括的なモデル カードのメタデータを作成してください。

提供オプション(ワークロードに応じて選択)

バッチ スコアリング(低コストで信頼性が高い)

1 秒未満の即時応答を必要としないワークロードでは、バッチ スコアリングが最適です。スケジュールされた Fabric ジョブまたはノートブックを使用して、レジストリから本番モデルを読み込み、バッチ データセットに適用して、予測結果を Lakehouse に書き戻してください。

リアルタイム エンドポイント(対話型アプリ)

フォームの検証やクリック時のリスク スコアリングなど、ユーザーに即時のフィードバックが必要な場合は、登録済みモデルを Fabric のユーザー インターフェイスから直接、マネージド リアルタイム エンドポイントとしてデプロイしてください。予測可能な JSON コントラクトを公開し、Power Apps や外部アプリケーションに安全に接続してください。

監視と再トレーニング

モデルをデプロイしただけでは、半分の作業が終わったにすぎません。学習時のベースラインに対してリアルタイムの特徴量分布を比較し、カルバック・ライブラー ダイバージェンスまたは母集団安定性指標(PSI)のしきい値を用いて、データ ドリフトを継続的に監視する必要があります。エンドポイントのレイテンシ、エラー率、1,000 スコアあたりのコストなどの運用状態のメトリックも追跡してください。時間ベースのトリガーとイベントベースのドリフト アラートを組み合わせて再トレーニング パイプラインを自動化し、モデルが長期にわたって正確さを保てるようにしてください。

セキュリティとコンプライアンス

エンタープライズ データを扱う際は、セキュリティの維持が最優先事項です。最小特権の原則を徹底し、データ サイエンティストにはシルバー層とゴールド層への読み取りアクセスのみを付与し、書き込み権限は指定された特徴量およびexperimentディレクトリに限定してください。すべての資格情報の保管には、マネージド ID と Azure Key Vault を利用し、シークレットがノートブックにハードコードされることがないようにしてください。機密情報は、シルバー層の早い段階でハッシュ化またはトークン化し、特徴量ストアに伝播しないようにして、PII の露出を最小限に抑えてください。

測定すべき指標(価値を素早く示す)

機械学習の取り組みの価値を迅速に示すには、適切な指標に注目することが重要です。モデルの性能はランキングについて AUC と precision-at-k で測定し、増分収益や解約率の低下を通じてビジネスへの影響を追跡してください。データの準備完了から本番デプロイまでのスピードを監視し、1,000 予測あたりのインフラストラクチャの信頼性とコスト効率を評価してください。

14 日間の展開計画

ゼロの状態から本番環境対応の Fabric デプロイメントへ迅速に移行したい場合は、次の 2 週間の展開計画に従ってください。

• 1～2 日目: Lakehouse の整理、ブロンズ/シルバー/ゴールド構造、ACL、品質チェック。
• 3 日目: ノートブックの骨組み作成、データ ヘルパー、開発用サンプル テーブル。
• 4～5 日目: 特徴セット v1、ベースライン モデルのトレーニング、MLflow によるログ記録。
• 6 日目: 評価スイート、モデル カードの作成、モデルの登録(v0.1)。
• 7 日目: バッチ スコアリング ジョブの作成と Power BI ダッシュボードの統合。
• 8 日目: 監視の最小実装(MVP)、ドリフト チェック、運用ログ記録。
• 9 日目: 承認ワークフローの実装と本番への昇格。
• 10 日目: リアルタイム エンドポイントの設定、スロットリング、要求ログ記録(該当する場合)。
• 11～12 日目: A/B テスト、バックテスト、ビジネス KPI の定義。
• 13 日目: コスト ガバナンス、自動スケーリングのガードレール、カナリア デプロイメント計画。
• 14 日目: ランブック ドキュメントの作成、チームへの引き継ぎ、バックログの計画。

よくある落とし穴(と簡単な対処法)

経験豊富なチームでも、思わぬ障害にぶつかることがあります。ノートブックの「ルーレット」を避けるには、環境を標準の Fabric カーネルに固定してください。小さなサンプルだけでテストしないでください。フルデータセットにスケールしたときに動かなくなることがあります。本番環境で「幽霊モデル」が生まれないよう、レジストリへの昇格ワークフローを厳格に適用してください。可能な限りバッチ処理を既定にし、派生特徴量をキャッシュすることで、クラウドのコストを抑えられます。

すぐに使えるスニペット

次のプロジェクトを始める際の参考として、Delta テーブルの特定のバージョンを読み込む方法を示す簡単なスニペットを紹介します。

sales_v = spark.read.option("versionAsOf", 123).table("lakehouse.gold.sales_txn")

scikit-learn で特徴量の重要度を抽出し、MLflow に直接記録したい場合は、次の方法を使用してください。

import pandas as pd
fi = pd.Series(clf.feature_importances_, index=feature_cols).sort_values(ascending=False)
mlflow.log_artifact(fi.head(30).to_frame("importance").to_csv("fi.csv", index=True))

ドリフト検出のために Population Stability Index (PSI) を計算する場合は次のとおりです。

import numpy as np
def psi(expected, actual, bins=10):
    e, b = np.histogram(expected, bins=bins, range=(np.min(expected), np.max(expected)))
    a, _ = np.histogram(actual,   bins=b,     range=(np.min(expected), np.max(expected)))
    e = np.clip(e / e.sum(), 1e-6, None); a = np.clip(a / a.sum(), 1e-6, None)
    return np.sum((a - e) * np.log(a / e))

現在の Lakehouse のテーブル名と、顧客離反（チャーン）、リードスコアリング、需要予測などの対象ユースケースを、コメント欄に書き込むか直接ご連絡ください。最小限の特徴量セット、ベースラインモデルの選定、バッチまたはリアルタイムの具体的な接続方法をまとめ、最初の Microsoft Fabric デプロイを迅速に進められるようお手伝いします。