ソフトウェアチームは、Fabric Workload Dev Kitを見る際、いつも同じカテゴリーエラーを犯している。彼らは、パブリッシング・パイプライン、認定チェックリスト、パートナーポータルを目にする。言い換えれば、彼らはそれを「マーケットプレイス」だと見なしているのだ。顧客が発見し、ダウンロードし、Microsoftスタックと並行して実行するアドインのようなものだと想像している。

それは誤った視点だ。Fabricワークロードはアクセサリではない。ネイティブなサーフェス（接点）なのだ。一度デプロイされると、アプリケーションはLakehouse、Power BI、Notebookと同じシェル内で動作する。ワークスペース内では独自のアイテムタイプを持ち、「新規」をクリックした際に表示される。UIはポップアウト式のタブではなく、FabricのUIフレーム内でレンダリングされる。その機能セットは、データチームがすでに業務時間の大部分を費やしている場所に位置する。これは単なる配布用のサイドバーではない。Microsoftのデータ・オペレーティングシステムに対する構造的なコミットメントなのだ。これを単なる「出品」として評価すると、自分では制御できないプラットフォームの中に閉じ込められてしまうことになるだろう。

ネイティブであることの優位性

Fabric向けに構築する場合、ホスト環境の信頼性とコンテキストを継承できる。ワークロードはOneLakeへの読み取りおよび書き込みアクセス権を受け取る。つまり、アプリケーションは、何十ものETLパイプラインを通じてデータをコピーすることなく、Deltaテーブルに直接クエリを実行できる。認証はMicrosoft Entra IDを通じて行われるため、アプリケーションはサインインしているユーザーとして動作する。管理すべき個別の認証情報保管庫も、維持すべきSSOブリッジも、セキュリティチームが懸念するようなフィッシングのリスクがあるパスワード入力プロンプトも存在しない。

技術的なフックと同様に、運用の重力（operational gravity）も重要だ。顧客のデータは自社のテナント内に留まるため、ほとんどのエンタープライズSaaS案件を頓挫させる「調達プロセスという名の演劇（procurement theater）」を回避できる。CISO（最高情報セキュリティ責任者）はデータレジデンシーについて議論する必要はなく、調達担当者はデータ転送コスト（egress charges）のモデリングを行う必要もない。ソフトウェアは、顧客がすでに所有している壁の中で動作するだけだ。ヘルスケアネットワーク、金融サービス、政府機関などの規制業界に販売するベンダーにとって、この単一の属性によって、12週間に及ぶセキュリティレビューを数日間の会話へと圧縮できる可能性がある。

潜んでいる罠

ネイティブであることはネイティブな依存関係を伴い、それらは制約へと変わる可能性がある。

第一に、コンピューティングの計算だ。利益率はMicrosoft Capacity Units（CU）に左右されるようになる。ワークロードが行うすべての操作は、顧客のSparkジョブ、セマンティックモデル、Power BIの更新に使用されるものと同じCUプールを消費する。Microsoftが価格を調整したり、消費倍率を変更したり、新しいキャパシティ層を導入したりすれば、同意することなくユニットエコノミクスが変化する。インフラストラクチャ層を制御できないため、最適化することもできない。できるのは、モデル化して、あとは祈るだけだ。

第二に、ロードマップのリスクは現実的なものだ。Microsoftには、有用な垂直統合型（vertical）の機能を観察した後、それと同等の水平型（horizontal）機能をコアプラットフォームに取り込むという、よく知られたパターンがある。もしあなたの価値提案が、一般的なデータタスクに対する薄いUIラッパーに過ぎないなら、あなたは最終的にRedmond（Microsoft）が自ら領有権を主張するかもしれない土地の上に家を建てていることになる。唯一の防御策は、深さとドメイン特化性だ。汎用的なデータクリーニングや単純な可視化ツールは、常に時間との戦いにさらされる。独自の機械学習モデル、業界特有の計算、あるいはカスタムテレメトリスキーマを横断して推論するオブザーバビリティ・ロジックであれば、不可欠な存在であり続けられる可能性が高い。

第三に、エンジニアリングの工数が日常的に過小評価されている。クイックスタートのチュートリアルやサンプルリポジトリを見ると、午後だけでワークロードを立ち上げられるように見える。デモが目的であれば、確かに可能だ。しかし、本番環境は別物だ。完全なバックエンド・コントラクトを実装し、アイテムのライフサイクルイベントを処理し、コントロールプレーンとFabricとの間の状態同期を管理し、キャパシティの一時停止や再接続時に適切にリカバリを行う必要がある。ユーザーが触れる表面はシンプルかもしれないが、その下にあるコントラクトは決して単純ではない。

作るべきか、それとも見送るべきか？

決断を下すべき基準は、Microsoftのエコシステムに対する熱意ではなく、あなたの価値がどこから生まれるかにある。

構築すべきケース：製品が顧客のデータに近ければ近いほど価値が高まる場合。オブザーバビリティ・プラットフォーム、業界特化型の分析エンジン、ガバナンスツールなどはすべてこれに該当する。また、買い手がすでにMicrosoftスタックを深く利用しており、新しいベンダーを導入するよりも支出を統合することを好む場合も構築すべきだ。さらに、あなたの知的財産（IP）がストレージ層の上にある場合（独自のドメインロジック、カスタムML推論、ユニークなエンリッチメント・パイプラインなど）、構築すべきである。なぜなら、それらのIPはMicrosoftが汎用的に複製することが困難だからだ。

Skip if your value has nothing to do with data locality. データ・ロカリティに関係のない価値を提供しているのであれば、この話は飛ばしてください。プロジェクト管理スイートや汎用APIゲートウェイは、ワークスペース内に存在する必要はありません。ターゲット顧客がマルチクラウド・ニュートラルであることを誇りに思っている場合も、飛ばしてください。Fabric内にデプロイすることを求めることは、彼らのアーキテクチャ上の独立性を損なうことになります。利益率を守るためにインフラコストを細かく制御する必要がある場合も、飛ばしてください。Microsoftの不透明なコンピューティング・プールを借りることは、コスト・エンジニアリングとは相容れません。

90日間のリアリティ・チェック

この3段階の実験を行うまでは、完全なロードマップにコミットしないでください。

1〜30日目：最も困難な部分のプロトタイプを作成する。 薄い垂直スライス（thin vertical slice）を構築しますが、見た目にこだわらず、ありのままの実装にしてください。1つのアイテムタイプを選び、作成（create）と削除（delete）を実装し、実際にOneLakeから読み書きを行うユーザーインタラクションを1つ実行してください。目標は綺麗なスクリーンショットを撮ることではありません。目標は、自社のバックエンドとFabricのライフサイクル・コントラクト（lifecycle contract）との間の摩擦を測定することです。

31〜60日目：実戦形式でコストをモデル化する。 トライアル容量（trial capacity）を立ち上げ、現実的な負荷パターンを実行してください。ユーザーのアクションごとのCU消費量を測定します。想定される同時実行数（concurrency）へと外挿してください。利益率を推測で決めないでください。トライアル容量は有料版とは挙動が異なることが多いため、境界条件をテスト（stress the boundary）することを忘れないでください。パイロット規模の10倍の負荷でも数値が維持できないのであれば、本番環境では破綻します。

**61〜90日目：デザインパートナーによる