こんばんは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。皆さま、いかがお過ごしでしょうか？

いやぁ、前回のブログで「要ダイエット！」と書いた瞬間、知人から「室長、口だけじゃなくて本気で動きましょう」と、とてもヘルシーなお弁当を渡されました💦

DX365LIFEは、深夜から朝にかけて書いているので、お腹が空いてきます。。。我慢我慢

そう言えば、今年もビジネスアプリケーション領域のMicrosoft MVPを受賞（12年連続）しました。

時間が経つのは本当に早いですね。Microsoft Regional Directorも兼務して7年目に入りました。

大変光栄なことですが、責任重大、正直プレッシャーしかありませんが、引き続き、情報発信に努めますので、ご指導ご鞭撻のほど何卒宜しくお願い致します。

さて、前回の記事（データ移行とは、AIに経験・証跡を引き継ぐこと｜Microsoft Fabric IQで考える、AI時代のトランザクションデータ移行）では、日本マイクロソフトの楊（Yang）さん、帥（Sui）さんとのディスカッションを経て、「AI時代のトランザクションデータ移行は、新システムのスキーマに無理やり合わせる苦行ではなく、Fabricを通じてAIにコンテキスト（経験）を渡す設計に切り替えるべき」というテーマでお届けしました。

ここでいう「経験」とは、AIモデルに過去データを再学習させるという意味ではありません。AIエージェントが回答や判断支援を行う際に参照できる、企業の過去証跡、業務文脈、判断材料を残すという意味です。つまり、AIそのものが勝手に記憶するのではなく、AIが必要な時に正しい根拠へ到達できるように、データと意味を設計するということです。

今回の記事は、あくまでもこの7月14日のデータ移行Blogの続編です。ただし、このテーマを正しく理解するためには、過去に書いた以下2本のBlogも関係しています。

「ノックフォワード」が起きる企業はなぜ負けるのか｜CRM×ERP×AI時代のデータ設計の原則

「ノックフォワード」しないデータ連携—ERPとDataverse、パスの繋ぎ方

前者では、CRMとERPの役割分担、つまり顧客接点を広く捉えるCRMと、受注・在庫・請求・回収を支えるERPを、AI時代にどのように接続して考えるべきかを整理しました。後者では、Business Central（BC）やFO（Dynamics 365 Finance / Supply Chain Management）をシステム・オブ・レコードとした場合に、Dataverse、Virtual Tables、Dual-write、Virtual Entitiesをどう使い分けるべきかを整理しました。

そして今回の記事では、その次の問いに進みます。

すなわち、「現行システムに移行しきれない過去データや履歴データを、AI時代にどのような資産として活用していくべきなのか」という問いです。

ありがたいことに前回の記事を読んでくださった各方面から「視点は面白いが、具体的にどうシステムを切り分けるんだ？」「ライセンス（F-SKU）のコスト感はどうなる？」「実際のプロジェクトはどういう手順で進めるのか？」

という非常に鋭いフィードバックをいただきました。皆さん、さすがですね！

今回は、前回記事の続編として、5つのテーマで深掘りします。①Dataverse／Business Central／FOとOneLakeの具体的な棲み分け設計、②Fabric IQとData Agentが「翻訳機」として機能する現場シナリオ、③移行プロジェクトの現実的な5フェーズ設計、④F-SKUライセンスの規模別試算、⑤失敗しないためのリスクと注意点—の5本立てです。少し長いですが、ぜひ最後までお付き合いください。

第1章　DataverseとOneLakeの「非対称性」を活かす設計

ここでいうDynamics 365は、文脈によって意味を分けて記載します。Dynamics 365 Sales、Customer Service、Field Serviceなど、Dataverseを中核に持つ顧客接点系アプリを指す場合は、本稿では明示的に「Dynamics 365 CRM」と表記します。一方、ERP領域を指す場合は、Business Central（BC）またはDynamics 365 Finance / Supply Chain Management（いわゆるFO）と書き分けます。

Dynamics 365 CRM（Sales、Customer Service、Field Serviceなど）のようにDataverseを中核に持つアプリケーションを使っている企業が直面しやすいのが、Dataverseのストレージコスト問題です。Dataverseは「今動いている業務」のための高性能なリレーショナルデータ基盤ですが、その分、容量追加にはコストがかかります。商用価格の一例としてDataverse Database Capacity Add-onは1GBあたり月額約40米ドルとされることがありますが、実際の価格は契約形態、地域、CSP/EA条件により異なるため、正式見積もりで確認が必要です。

一方、Business Centralの場合は注意が必要です。Business Centralの業務データは通常、Dataverseそのものに保存されているわけではありません。Business CentralはBusiness Central側のデータベースを持ち、Dataverseとは連携、同期、仮想テーブル、Power Platform連携などを通じて接続します。

FO（Dynamics 365 Finance / Supply Chain Management）でも考え方は同じです。財務、購買、在庫、生産、倉庫、サプライチェーンといった業務の事実はFO側で管理され、DataverseやPower Platformは顧客接点、承認、拡張アプリ、参照・入力画面、ワークフローのために使われることが多くなります。つまり、BCでもFOでも、ERP側をシステム・オブ・レコードとし、DataverseやVirtual Tablesをどう組み合わせるかが設計上の肝になります。

過去5年・10年分のトランザクションデータをすべて現行業務システムやDataverse側に抱え込もうとすると、容量コスト、性能、データ整形負荷が一気に膨れ上がります。かといって、旧システムのデータを捨ててしまうと、AIが参照できる「過去の経験」を持てません。このジレンマこそが、多くのプロジェクトで「データ移行はコスト的に無理」と判断されてきた根本原因です。

ホットデータとコールドデータを完全に分ける

解決策は、データを「温度」で分けることです。頻繁にアクセスされ、常に最新状態を保つ必要がある「ホットデータ」は現行業務システム、Business Central、FO、Dynamics 365 CRM、Dataverseに。めったにアクセスされないが、AIの参照元として価値がある「コールドデータ（過去の経験）」はFabricのOneLakeに——という棲み分けです。

現行業務システム／Dataverse（ホットデータ層）に置くもの：

• 現在進行中の案件・受注・サービスオーダー（未完了のもの）
• 名寄せが完了した最新の顧客マスター（Account、Contact、Customer）
• 現在有効な製品・品目マスター（Product、Item）
• 過去12〜24ヶ月分のクローズ済みトランザクション（参照頻度が高い直近データ）

ポイントは「極限までスリムに保つ」ことです。現行業務システムには今日のオペレーションに必要なものを置く。Dataverseを利用する場合も、容量を最小化することでランニングコストを抑えつつ、クエリパフォーマンスを高く維持します。「データは多いほどいい」という発想を捨て、「業務実行に必要なデータ」と「AIが参照する過去データ」を分けることが重要です。

OneLake（コールドデータ・履歴層）に置くもの：

• 旧システムの過去5〜10年分のトランザクションデータ（見積、受注、請求、サービス履歴など）
• 旧システムの原構造を残した、生データに近いBronze層
• 用途別に整形したSilver層、分析や業務参照に使うGold層
• 保存形式はDelta Parquetを基本とし、分析・参照・AIグラウンディングに使いやすくする

ここで重要なのは、「生データをそのまま置く」とは、意味を失ったCSVやテーブルを単に保存することではない、という点です。後からAIや人間が正しく解釈できるように、旧システムのテーブル定義、コード体系、ステータスの意味、通貨・単位、税区分、抽出日時、抽出元、履歴時点のマスター参照関係、業務ルールといった”解釈に必要なメタデータ”も合わせて保存する必要があります。

コスト試算：100GBのデータを持つ場合

「100GBのトランザクションデータ」を保持する場合の概算比較です。実際の価格は契約形態・地域・為替・販売チャネルにより変動するため、正式な見積もりで確認してください。

もちろん、OneLakeのデータを処理するためにはFabricの容量（F-SKU）コストが別途かかります。しかしF2〜F8レベルのスモールスタートを前提にすると、過去データをすべて現行業務システムやDataverseに押し込むより、はるかに現実的な構成を作れる可能性があります。

SQL database in Microsoft Fabricという第三の選択肢

なお、「Dataverseでもなく、単なるOneLakeでもなく」という第三の選択肢として、SQL database in Microsoft FabricのようなFabric上のオペレーショナルデータベースを検討する余地もあります。SQL database in Microsoft Fabricは、Azure SQL DatabaseをベースにしたFabric上のトランザクション用データベースであり、データがOneLakeへ自動的に複製され、分析やPower BI連携に使いやすくなる点が特徴です。旧システムそのものをFabric側に段階的に移行する設計も、将来的な選択肢として検討できます。ただし今回のシナリオでは、Business Central、FO、Dynamics 365 CRMのいずれかが中心業務システムであり、旧データはAI参照用という前提で話を進めます。

BC、FO、Dynamics 365 CRM、Dataverseの役割を改めて整理する

ここまで読んで、「Dataverseがあるなら、なぜOneLakeが必要なのか？」と思われた方もいるかもしれません。その疑問は非常に自然です。ここは、5月に書いた「CRM×ERP×AI時代のデータ設計」と「DataverseとVirtual Tablesの使い分け」の内容とも直結します。今回の議論を理解するために、BC、FO、Dynamics 365 CRM、Dataverse、OneLakeの責任分界点を一度整理しておきます。

Dynamics 365 CRMは、顧客接点を動かすためのアプリケーション群です。Sales、Customer Service、Field Serviceなどでは、Account、Contact、Opportunity、Case、Work Orderといった業務データがDataverseを中心に扱われます。つまり、CRM領域ではDataverseが現在進行形の顧客接点データを支える中心的な場所になります。

Business Centralは、Dataverseに全てを持たせるのではなく、BC側の業務データベースをシステム・オブ・レコードとして保ちつつ、Data Synchronization、Virtual Tables、Webhook、Business Eventsなどを使ってDataverseやPower Platformとつなげる思想です。マスターや一部の業務データは同期し、在庫や受注残など、常にERP側の最新状態を見るべきデータはVirtual TablesやAPI経由で参照する。すなわち、「同期＋参照」の設計です。

FO（Dynamics 365 Finance / Supply Chain Management）は、さらに連携思想が異なります。FOとDataverseの間ではDual-writeにより、顧客、担当者、製品、価格、販売情報などを双方向・準リアルタイムに同期できます。これにより、Prospect to CashやLead to Cashのように、CRMからERPまでを横断する業務プロセスを一貫して扱いやすくなります。一方で、在庫トランザクションや顧客残高のように、ERP側のビジネスロジックで確定すべき情報はVirtual Entitiesを通じて参照する設計が有効になります。

この整理から見えてくるのは、Dataverseは万能の保管場所ではない、ということです。DataverseはCRMやPower Platformの現在業務を動かすために非常に強力ですが、過去10年分の受注、請求、在庫移動、保守、問い合わせ、商談履歴を全て持たせる場所ではありません。BCにもFOにも、それぞれが守るべき業務事実があります。Dataverseにも、CRMとして持つべき顧客接点があります。そしてOneLakeには、それらをまたいだ過去の経験を保存する役割があります。

Lead to Cashで考えると、「履歴」は資産になる

この役割分担は、Lead to Cashで考えると非常に分かりやすくなります。リードを獲得し、育成し、商談化し、見積を出し、受注し、在庫を確認し、出荷し、請求し、入金を確認し、さらに継続提案やアップセルにつなげる。この一連の流れは、CRMとERPのどちらか一方だけでは完結しません。

CRMには、リード、商談、見積、顧客対応、活動履歴があります。ERPには、受注、在庫、出荷、請求、入金、原価、収益があります。CRMとERPがつながることで、データは一本の川のように流れます。しかし、システムの境界でデータが途切れると、AIは顧客の本当のストーリーを理解できません。これは、以前の記事で書いた「ノックフォワード」にも近い状態です。

AI時代に重要なのは、単にデータが存在していることではなく、データ同士が業務文脈としてつながっていることです。「なぜこの顧客は受注に至ったのか」「なぜこの案件は失注したのか」「なぜこの製品は保守契約につながったのか」「なぜこの顧客は長期間離脱しなかったのか」。こうした問いにAIが答えるためには、営業履歴だけでも、ERP伝票だけでも足りません。見積、受注、在庫、出荷、請求、入金、問い合わせ、保守履歴、継続提案の結果までがつながって初めて、AIは企業の経験を理解できます。

だからこそ、Dataverseは「現在進行形の業務を実行する場所」、BCやFOは「基幹業務の事実を確定する場所」、OneLakeは「Lead to Cash全体の経験を保存する場所」として設計する必要があります。そしてFabric IQは、その経験をAIが理解できる業務言語へ翻訳する役割を担います。

言い換えると、Dataverseは現在、OneLakeは経験です。DataverseやERPが現在の業務の記録だとすれば、OneLakeは企業の経験の記録であり、Fabric IQはその経験をAIが理解するための翻訳機です。この関係性を理解すると、今回のテーマである「データ移行はAIへの経験伝承である」という意味が、より具体的に見えてくると思います。

第2章　翻訳機としての「Fabric IQ」と「Data Agent」―機器保守業のシナリオ

「整形なしでOneLakeに投入したデータは、どうすれば使えるようになるのか」。これが前回記事への最も多かったフィードバックでした。答えは、Fabric IQ（オントロジー／セマンティック層）が「翻訳機」として機能する、ということです。

概念だけではイメージしにくいと思いますので、実際の業務シナリオで説明しましょう。舞台は、Business Centralを基幹システムとして使っている「機器保守会社」です。なお、同じ考え方はFOを中心とした大規模ERP環境にも適用できます。たとえば、FO側で保守部品、在庫、購買、原価、請求を管理し、Dynamics 365 CRM側で顧客対応やフィールドサービスのタッチポイントを管理する構成でも、過去履歴をOneLakeに置き、Fabric IQで意味付けする考え方は変わりません。

シナリオの前提：機器保守会社のデータ構造

• 現在の業務システム：Business Central。現在のサービスオーダー、顧客マスター、機器台帳、直近2年分の履歴を管理
• Power Platform連携：必要に応じてDataverse連携、仮想テーブル、Power Apps、Power Automate、Copilot Studioとの連携を利用
• 旧システム：OneLakeに移行済み。2015〜2022年の保守記録・作業報告書・見積書（約8年分、約60GB）を保持
• FO版の構成例：Dynamics 365 Finance / Supply Chain Managementで在庫、購買、原価、請求を管理し、Dynamics 365 CRMで顧客接点や作業受付を管理する

旧システムのデータは、Business CentralやFOのスキーマとは全く異なる構造で保存されています。たとえば、顧客を識別するキーがBusiness Centralでは「顧客番号（Customer No.）」、旧システムでは「得意先コード」という名前で存在している。機器を識別するキーがBusiness Centralでは「サービス品目番号（Service Item No.）」、旧システムでは「設備管理番号」という名前で存在している。FOの場合も、品目番号、倉庫、在庫分析コード、原価、請求、プロジェクトなどの軸が加わるため、過去データの意味をどう保持するかがより重要になります。

Fabric IQのオントロジー定義：具体例

多くの定義作業はGUIベースで進められますが、実案件ではデータバインド、キー設計、Semantic modelとの整合、権限設計が必要になるため、業務担当者とデータエンジニアの共同作業として進めるのが現実的です。Fabric IQのOntologyはGold層そのものではありません。Bronze／Silver／Goldの各データ層を横断し、業務概念として意味付けするセマンティック層として捉えるのが適切です。

実況中継：フィールドサービス担当者がBusiness Centralのサービスオーダー画面で体験すること

――午前10時。顧客から「先週点検したばかりなのに、また同じ警告アラームが出た」という電話が入ります。フィールドサービス担当者は、Business Centralのサービスオーダー画面を開き、顧客名と機器番号を入力します。FOを中心にした企業であれば、同じ場面でDynamics 365 CRM側の作業受付画面、Field Serviceの作業指示、またはPower Appsで作られた現場アプリからエージェントを呼び出すことも考えられます。

そこで、業務画面から呼び出せるエージェント導線を通じて、Data Agentの応答が表示されます。これは標準画面に自動的に埋め込まれるという意味ではありません。Copilot Studio、Power Apps、Teams、カスタムアプリ、またはBusiness Central／FO／Dynamics 365 CRM側の拡張ポイントを使って、ユーザーが迷わず使える導線を設計する必要があります。

フィールドサービス担当者はこの応答をそのまま顧客に伝えるのではなく、必要に応じて根拠を確認したうえで説明します。「過去にも同じ症状があり、根本原因はセンサーの接触不良でした。今回もセンサーユニットの交換をお勧めします」と。顧客は安心し、その場で修理の予約を入れます。

このやり取りの裏側では、Data AgentがFabric IQのオントロジーやSemantic modelを参照し、Business CentralまたはFOにある現在の業務データと、OneLakeに格納されている旧システムの作業報告フリーテキストを根拠データとして参照します。そして、Dynamics 365 CRMやPower Apps側の顧客接点画面で、現場が使える形に翻訳して提示します。なお、Data AgentはAIモデルを再学習させているのではなく、SQL／DAX／KQLを生成してデータに問い合わせ、根拠として参照できる証跡にアクセスする仕組みです。

Copilot Studio経由でのData Agent連携

上記のシナリオで使われるエージェント導線は、Copilot StudioやPower Platform、Teams、カスタムアプリなどを組み合わせて設計します。Copilot Studioはノーコード／ローコードでエージェントを設計できる強力な環境ですが、ライセンス表現には注意が必要です。

第3章　移行プロジェクトの5フェーズ設計

「概念はわかった。では実際どういう手順でプロジェクトを進めるのか」という質問に答えます。このアーキテクチャを実現するプロジェクトは、5つのフェーズで構成するのが現実的です。

フェーズ0：データプロファイリング・現状分析

このフェーズが全体の品質を左右する最重要フェーズです。「とりあえず旧システムのデータをOneLakeに入れればいい」という発想は危険で、まず「何がどこにあり、どういう意味で使われていたのか」を徹底的に棚卸しする必要があります。

• 旧システムのテーブル構造・データ件数・更新頻度のマッピング
• NULLの割合・重複件数・コード体系の揺れなどのデータ品質プロファイリング
• Business Central、FO、Dynamics 365 CRMとの紐付けに使えるキーの特定
• 旧システムの業務ルール、ステータス意味、税区分、単位、通貨、履歴時点のマスター参照関係の保存
• AIに参照させる価値があるデータと不要なデータの仕分け

Fabricを活用する場合、Notebook（PythonやSpark）でデータプロファイリングを自動化できます。ydata-profilingなどのライブラリを使えば、テーブルごとの品質サマリーレポートを短時間で生成できます。ただし、ライブラリの利用可否は環境、セキュリティポリシー、データサイズにより確認が必要です。

フェーズ1：Bronze層構築・データ取り込み

フェーズ0の成果物をもとに、OneLakeのBronze層にデータを投入します。Bronze層はあくまで「生データの安全網」です。このフェーズでは変換・クレンジングを最小限に抑え、「旧システムのデータを原構造に近い形で保存した」という証跡を残すことが目的です。ただし最低限のこととして、文字コードの統一（例：Shift-JISからUTF-8）と、タイムスタンプのタイムゾーン統一は検討します。

• Copy Job／Data Factory系の取り込み機能：バッチコピーや増分コピーの候補
• 既存のAzure Data Factory資産：継続活用できる場合は移行リスクを下げられる
• CSVエクスポート＋Notebookロード：旧システムがCSV出力しかできない場合の現実解
• CDC／増分同期：プロジェクト中に旧システムが更新される場合に検討

フェーズ2：オントロジー構築（Fabric IQ設計）

このフェーズが「今回の記事の核心」であり、最も創造的な作業です。Bronze層、必要に応じてSilver／Gold層に入ったデータの「意味を定義する」作業を行います。

• エンティティ定義：顧客、機器、作業履歴、品目、倉庫、請求、原価などの業務概念を定義する
• フィールドマッピング：BC／FO／Dynamics 365 CRMのフィールドと旧システムのフィールドを意味的に紐付ける
• 関係性定義：顧客は複数の機器を持つ、機器は複数の作業履歴を持つ、といった関係を定義する
• ルールと制約：AIが誤解しやすい条件、参照してはいけないデータ、判断に使ってはいけない項目を定義する
• 検証：実際のクエリを投げてData Agentが正しく応答するかをテストする

重要なのは、このフェーズに「業務を知っている人間」が必ず関与することです。オントロジーの定義を間違えると、AIが自信満々に間違った答えを返します。データエンジニアだけに任せず、業務コンサルタントやスーパーユーザーがレビューに参加する体制が必須です。

フェーズ3：Data Agent開発・テスト

フェーズ2で構築したオントロジーやSemantic modelをベースに、実際にユーザーが使うData Agent／エージェント導線を設計します。このフェーズで最も重要なのがUAT（ユーザー受入テスト）です。機器保守業のシナリオで言えば、実際のフィールドサービス担当者に「よくある質問」を30〜50パターン用意してもらい、Data Agentが正しく応答するかを検証します。

• 正確性：過去データの事実と回答が一致しているか
• 完全性：参照すべきデータが欠落していないか
• ハルシネーション：存在しない情報を「ある」と答えていないか
• 根拠提示：回答の背景にあるデータや証跡へ辿れるか
• 有用性：現場の業務判断に実際に役立つ情報が含まれているか

UAT結果をフィードバックしてオントロジー、Semantic model、プロンプト、権限、データ品質を修正し、再テストするというイテレーションを2〜3回繰り返すことで、回答精度と現場の信頼が高まります。

フェーズ4：本番稼働・運用体制構築

• 監視ダッシュボード：利用状況、応答時間、エラー、ユーザーフィードバックを可視化する
• オントロジーのメンテナンス体制：BC、FO、Dynamics 365 CRMや旧システムのデータ構造変更時に更新できる担当者・手順を決める
• コスト監視：Fabric容量、OneLakeストレージ、Copilot Studio／Copilot Credits、Power BIライセンスを継続的に監視する
• ガバナンス：Purview、ワークスペース権限、データ分類、監査ログ、アクセスレビューを運用に組み込む

第4章　F-SKUライセンスの規模別試算

「結局いくらかかるのか」。これが最も実務的な質問です。ここでは組織の規模別に3パターンの概算を示します。数値はすべて後述の「試算の前提条件」に基づく概算です。実際の見積もりはMicrosoft担当者またはパートナーを通じて取得してください。

試算の前提条件

• Fabric OneLakeの通常ストレージ単価：0.023米ドル／GB／月を仮置き
• F-SKUの従量課金価格を基準に記載。1年予約では約41%の割引が見込まれる場合がある
• Power BI閲覧ライセンス：F64未満では共有コンテンツの閲覧ユーザーにProまたはPPUが必要になる場合があります。本稿の試算では、Power BI Proをドル建て14米ドル／ユーザー／月（年払い表示の公開価格）で仮置きします。ただし実際の価格は契約・地域・時期により変動します
• F64以上では、コンテンツがFabric F64+またはPremium容量に完全にホストされ、適切な権限がある場合、Freeユーザーでも閲覧できる可能性がある
• Fabric IQ、Ontology、Data Agentなどの機能は、テナント設定、リージョン、プレビュー機能の有効化状況、ライセンス条件により利用可否が変わる可能性があります。PoC時点で必ず実環境で確認してください
• Copilot Studio：Microsoft 365 Copilotライセンス、Copilot Credits、Pay-as-you-go課金、利用機能、利用量により変動する

パターンA：小規模（〜20ユーザー・データ量50GB未満）

パターンB：中規模（20〜100ユーザー・データ量200GB）

パターンC：大規模（100ユーザー以上・データ量1TB以上）

ポーズ＆レジューム（一時停止）の効果試算

Fabric容量はAzureリソースとして、従量課金の場合に「使っていない時間は止める」という運用が可能です。ただし、リアルタイム業務で使う場合は、容量の再起動タイミングやユーザー体験に注意が必要です。

ただし、ポーズ＆レジュームは「今すぐ答えが欲しい」リアルタイム業務と相性が悪い場合があります。容量の再起動には一定の時間がかかるため、朝の業務開始時に「容量が起動していない」という状況が発生しないよう、スケジュール設定を丁寧に行う必要があります。

第5章　リスクと失敗パターン――やってしまいがちな落とし穴

失敗パターン①：オントロジー定義の精度不足

「Fabric IQにオントロジーを定義すればAIが何とかしてくれる」という過信から、検証を省略したり、業務知識のないエンジニアだけで定義したりするケースです。Data Agentが「それらしい答え」を返すが、実際には間違っている、または参照すべきデータが欠けている。対策は、業務を知っている人を必ず巻き込み、間違いを発見する前提で検証することです。

失敗パターン②：Bronze層のデータ品質を過信する

「とりあえず旧システムのデータを全部入れてしまえ」と急いだ結果、NULLだらけのフィールド、重複レコード、文字化けデータ、意味不明なコードが大量に混入するケースです。対策は、フェーズ0のプロファイリングに十分な時間をかけ、何をSilver層で補正するか、何を原本として残すかを業務側と合意することです。

失敗パターン③：F-SKUのサイジングミス

本番稼働後に容量が足りず、応答遅延やジョブ制限が発生するパターンです。対策は、パイロット期間中にFabric Capacity Metrics Appなどで消費量を計測し、ピーク時の負荷を見たうえでF-SKUをサイジングすることです。公式表現や段階的な制限仕様は変更される可能性があるため、「段階的に遅延・制限・拒否が発生し得る」という前提でバッファを持ったサイジングを行うことをお勧めします。

失敗パターン④：Purview（データガバナンス）の後回し

「データはOneLakeに入った、Fabric IQも動いた、Data Agentも使えるようになった」という状態で本番稼働させた後、「このデータ、誰でも見ていいのか？」という問いに答えられないケースです。OneLakeに個人情報、給与情報、契約情報、機密情報が混在していた場合、Data Agent経由で本来参照権限のない情報が返るリスクがあります。対策は、フェーズ0からMicrosoft Purview、データ分類、アクセス権限、監査ログを設計に組み込むことです。

失敗パターン⑤：プロジェクト体制の問題

技術的には成功したのに、現場に定着しなかったというパターンです。「ITが作ったツールを押し付けられた」と感じたフィールドサービス担当者が、Data Agentを使わずに従来通りの作業を続けてしまう。対策は、フェーズ3のUATを「ITによる品質確認」ではなく「現場のフィールドサービス担当者が自分で試して育てる」プロセスとして設計することです。現場担当者が「このツールは自分が育てた」と感じた時、定着率は劇的に上がります。

エピローグ