Subscribe
Share
Share
Embed
Fabric ML ModelはMLflowレジストリをワークスペースに統合し、バッチスコアリングからPower BIへのゼロリフレッシュ連携を実現します。しかしリアルタイムエンドポイントはプレビュー、Gitはメタデータのみ、GPUはなし。Azure MLを本当に置き換えられるのか、それとも併用すべきなのか。判断の分かれ目を掘り下げます。
Episode 22 • 2026-05-29 Duration: 11:08
Fabric ML ModelはMLflowレジストリをワークスペース内に組み込み、バッチスコアリングからPower BIへの表示まで更新なしで完結する。しかしリアルタイムエンドポイントはプレビュー、Gitはメタデータしか追跡せず、GPUもない。Azure MLを本当に置き換えられるのか、それとも共存させるべきなのか。
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
このポッドキャストは AI によって生成されています。どちらの音声も合成です。Matthias はクローン音声、Fabia は設計された AI 共同ホストです。
Brand design based on fabricperiodictable.com.
Microsoft Fabric のア���キテクチャ意思決定。匿名化された実際の顧客シナリオ、コストのリアリズム、反論を含む。Fabric Friday の録画に合わせた週刊エピソード。AIにより生成。
5分で眠る推論環境
Episode 22 | 2026-05-29
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: バッチのフレーバーが11種類。リアルタイムが4種類。そしてリアルタイムエンドポイントは、アイドル状態5分で自動スリープに入ります。
[00:12] Matthias: 5分。コーヒーを淹れる時間すらないですね。
[00:13] Fabia: それが、Fabricの中でMLモデルを運用するためにMicrosoftが構築したスコアリング基盤です。
[00:17] Matthias: となると、どのチームも同じ問いにたどり着きます。モデルをFabricに移すのか、今の場所に残すのか。
[00:20] Fabia: Fabric ML Modelは、ワークスペース内に組み込まれたMLflowレジストリです。ノートブックでトレーニングします。sklearn、LightGBM、XGBoost、問題に合うものを使います。MLflow autologがパラメータ、メトリクス、そして決定的に重要なモデルシグネチャを記録します。ベストなランを選んで、バージョン管理されたモデルとして登録する。4つの階層があります。実験がランを含み、ランが登録済みモデルバージョンを生成します。
[00:35] Matthias: シグネチャの話がよく出てきますね。実際、未設定でトラブルになるケースはどのくらいあるんですか。
[00:38] Fabia: コミュニティフォーラムで初回デプロイ失敗の原因、第1位です。PREDICTにはMLflowシグネチャが必須です。入力カラムと出力カラムのマッピングですね。これがないとPREDICTは動きません。修正はたった1行。mlflow.autologにexclusive=Falseを渡すだけです。トレーニングデータからシグネチャを自動で取得してくれます。
[00:50] Matthias: 1行なのに、初回で書く人がいない。
[00:51] Fabia: この統合が真価を発揮するのはここです。PREDICTの予測結果はLakehouseのDeltaテーブルに書き込まれます。Direct Lakeモードのセマンティック モデルがそのテーブルを直接読みます。データ移動ゼロです。ノートブックでスコアリングし、予測結果がOneLakeに格納され、Power BIは更新をスケジュールせずにそれを参照できます。
[01:03] Matthias: 更新が一切不要？ それは経済性を根本から変えますね。私がこれまで関わったバッチスコアリングパイプラインは、どれも最後に同じETLの手間がありました。スコアリングして、エクスポートして、ステージングテーブルにロードして、更新をスケジュールして、朝のスタンドアップまでに終わるよう祈る。大抵、誰かの週末がそこで消えます。
[01:14] Fabia: ループ全体が1つのワークスペース、1つの容量、1つのガバナンス体系で完結します。予測データもソースデータも同じOneLakeにあります。
[01:18] Matthias: スキーマ変更はどうなりますか。予測ノートブックがカラムを追加したら、Direct Lakeはそのまま拾ってくれるんですか。
[01:22] Fabia: スキーマ変更のときはセマンティック モデル側で手動リフレッシュが必要です。データリフレッシュではなく、スキーマリフレッシュです。Power BIでワンクリック、カラム構造を再読込して完了。データ自体は一切動きません。
[01:30] Matthias: このループが、チームを引き寄せ続けるんですよね。データエンジニアがワークスペースを離れずに、トレーニング、登録、スコアリング、Power BIでの確認まで完結できる。このクローズドループだけを理由にFabricへ移行したチームに、実際何度も出会っています。
[01:38] Fabia: ただし、要件が2つの境界線の内側にある限りです。テーブル形式のモデルとバッチスコアリング。どちらか一方でも外れると、制約が積み重なり始めます。
[01:43] Fabia: ちょうどその境界線がどこにあるか試されるような質問が届いています。 私たちのチームはAzure Machine Learningを2年間使ってきました。今、経営層がFabricへの統合を求めています。Fabric ML Modelは本当に代替になりますか？何を失い、何を得るのでしょうか？
[01:53] Matthias: この問いに、きれいな答えはありません。モデルが実際に何を必要としているか、チームが実際に何をサポートできるか。その棚卸しが終わる前に、経営層が「統合しろ」と言い出すケースがほとんどです。
[02:00] Fabia: まずコンピューティングの話からです。FabricのノートブックにはネイティブGPUがありません。テーブル形式を超えるもの、画像認識、NLP、Transformerのファインチューニング。こうしたモデルはここではトレーニングできません。設計上の恒久的な境界です。
[02:09] Matthias: 画像系もファインチューニングも全部——
[02:10] Fabia: Azure MLかDatabricksに残ります。
[02:11] Matthias: ほとんどのチームが想定するより、ずっと大きな除外範囲ですね。
[02:13] Fabia: そして運用レイヤーではさらに制約が明確になります。MLモデルのGit統合はプレビューで、追跡されるのはメタデータだけです。リポジトリに入るのは表示名とリネージポインタ。トレーニング済みの重みや実験のアーティファクトはワークスペースストレージに残ります。git pullでモデルを取得することはできません。
[02:24] Matthias: え、アーティファクトがリポジトリに入らない？ それはCI/CDの前提を書き換えますね。私が一緒に仕事をしたMLチームはどこも、モデルアーティファクトをデプロイ可能な単位として扱っていました。デプロイ対象がバージョン管理の外にあるということは、レシピだけバージョン管理して、ケーキは手渡しで届けているようなものです。
[02:35] Fabia: さらにModel Endpointsもプレビューで、実質的な制約があります。4つのフレーバー、Keras、LightGBM、Sklearn、XGBoost。AutoMLサポートはその後追加されました。モデルあたりアクティブバージョンは最大5つ。アイドル5分で自動スリープ。ブルーグリーンデプロイやオートスケールが必要なら、見ているプラットフォームが違います。
[02:47] Matthias: つまり冒頭の5分という数字は、本番エンドポイントがAPIコールの合間にコールド状態になる、という話ですね。
[02:50] Fabia: Azure MLのチームがあまり口にしないことがあります。独立したマネージドMLプラットフォームを立ち上げて、専用のコンピューティングライフサイクルを管理して、分析レイヤーへのコネクタ配管を整備する。誰かがモデルをトレーニングする前に、何週間ものエンジニアリングが必要です。しかもGPUが稼働していようがアイドルだろうが、そのコンピューティング費用は発生し続けます。
[03:02] Matthias: それは確かにそうです。Fabric ML Modelが本当に勝つのは、成熟したMLプラットフォームを持つチームではありません。データエンジニアがJiraチケットで「チャーンモデルを作れ」と言われて、GPUクラスタのプロビジョニング経験がないようなチームです。使い慣れたワークスペースにとどまることが、本番投入への唯一の現実的な道になります。
[03:14] Fabia: コストについてです。トレーニングもスコアリングもFabricの容量、つまりF-SKUを消費します。ML専用のコンピューティング課金は別途ありません。一見お得に聞こえますが、トレーニングジョブが同じ容量上の他のすべてのワークロードと競合するということです。小さめのSKUだと、長時間のトレーニングがワークスペース全体を圧迫する可能性があります。
[03:25] Matthias: しかもそれが発覚するのは、容量に余裕のある火曜の午後ではありません。金曜日、12本のレポートが更新中で、同時にチャーンモデルが再トレーニングを始めたときです。
[03:30] Fabia: Azure MLならジョブの実行中だけトレーニングクラスタを立ち上げて、完了後に削除できます。Fabricの容量は共有で常時稼働です。MLワークロードが使えるのは、残りのヘッドルームだけです。
[03:37] Matthias: 私が自信を持って言える推奨はこうです。モデルがテーブル形式で、データがOneLakeにあり、利用者がPower BIを使っているなら、移行してください。Direct Lakeのループだけで移行の労力に見合います。ただしGPUトレーニングと本番レベルのリアルタイムエンドポイントにはAzure MLを残す。このハイブリッドが成立するのは、両方がMLflowを共通言語としているからです。同じレジストリプロトコルで、デプロイ先だけが違います。
[03:52] Fabia: リスクとして明記すべき点があります。Model Endpointsはプレビューです。今日リアルタイム連携をこの上に構築して、GA時にMicrosoftがAPIの仕様やアクティベーション挙動を変更したら、本番コードの改修が必要になります。バッチデプロイは特定のモデルバージョンに固定してください。プレビュー機能を耐力壁として扱ってはいけません。
[04:03] Fabia: クエリパターンがすべてを語ります。バッチからPower BIへ？ それはFabricの領域です。SLA付きのリアルタイムREST？ それはまだAzure MLです。
[04:09] Matthias: 両方あるなら、両方動かせばいい。どちら側も同じMLflowプロトコルです。
[04:11] Fabia: 今どこかで、データエンジニアが初めてregister_modelを実行しています。バージョン番号が上がりました。シグネチャフィールドは空のままです。 PREDICTがこれから、そのエンジニアと対話を始めます。
[04:19] Matthias: 短い対話ですけどね。
[04:19] Matthias: この判断で迷っている方、LinkedInでDMをください。Matthias Fallandで検索してください。
[04:23] Fabia: アーキテクチャは宗教ではありません。
---
End of episode. ~04:24 estimated.