おはようございます。室長こと吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

前回第7回では、Dynamics 365 Business Centralを題材に、AI AgentのAutonomyを「Read→Summarize→Recommend→Prepare→Update→Commit→Post」という段階で整理しました。External Commitment・Master・Money・AccountingをAuthority Boundaryとして定義し、Agentや人が行った判断を後から説明できるEvidence by Designの重要性を考えました。

しかし、Evidenceを残すだけでは十分ではありません。

受注・在庫引当・出荷・請求・転記・決済・訂正といった現在のTransactionは、どこへ残すべきなのか。複数法人をまたいだ履歴・分析データ・AIが使う業務上の意味・Agentの判断根拠は、どこで管理すべきなのか。

今回は、この問いに答えます。

---

Data Responsibilityの設計から始める

第7回で扱ったApproval・Posted Entry・Correction・Agent Task・Audit Evidenceは、業務処理の中で生まれます。第8回では、そのEvidenceを単に保存するのではなく、何をOperational ERPに残し、何をFabricへ渡し、どのように再表示し、どのようにAIへ参照させるかを整理します。

大切なのは、データを「ERPかFabricか」という二択にしないことです。同じ受注でも、ERPには現在のOpen QuantityとReservation Stateがあり、Fabricにはその受注が過去にどのような納期変更・引当不足・承認・出荷遅延・訂正を経たかという履歴があります。それぞれが異なる責任を持ちます。

---

ERP Dataは六つの責任に分けて考える

ERP Dataの責任は、単一のデータベースに全部入れれば解決するものではありません。データが生まれた目的・更新主体・訂正の方法・AIからの利用方法が、責任ごとに異なるからです。

表1：ERP Data Responsibility — 六つの分類と特性

ここでいうGolden Dataは、FabricのGoldレイヤーに置かれたデータという意味ではありません。意味・品質・正本・識別子・履歴・利用条件・責任が整理され、複数用途で信頼して再利用できる状態を指します。この定義では、Golden DataがERP・Dataverse・Fabricのどこに物理配置されるかよりも、誰が何を訂正し、どの識別子と履歴を保証するかが重要です。

---

Operational TruthとAnalytical／Learning Truthは同じではない

例えば、ある販売注文に10個の在庫が必要だとします。ERPは、会社・倉庫・Site・在庫Status・Reservation Hierarchy・Credit・価格・税・会計期間などの業務ルールを評価し、何個を引き当て、いつ出荷し、どの法人で請求し、どのLedgerへ転記するかを決定します。この現在Stateを変更できるのは、ERPの業務ロジックとAuthorityを通った処理だけです。

Fabricは、その注文を他法人・他倉庫・仕入先納期・過去の欠品・販売予測・顧客優先度・出荷実績と横断して分析できます。しかし、Fabric上のGoldテーブル・Power BI Semantic Model・Direct Lakeレポートが「この注文を出荷済みにする」「Settlementを確定する」と判断してよいわけではありません。

Direct LakeはOneLake上のDelta TableをPower BI Semantic Modelから効率的に利用するためのStorage Modeです。分析性能とデータ鮮度を改善しますが、Posting Authorityや業務更新責任を提供する機能ではありません。

---

Legal EntityとEffective Dateを失うと、過去のTransactionを誤解する

ERPでは、CustomerやItemの名前が同じでも、意味が同じとは限りません。法人が違えば、Customer Account・通貨・税区分・支払条件・価格・原価・勘定科目・会計カレンダー・在庫評価・取引制限が異なる場合があります。また同じ法人でも、それらの属性は時間とともに変化します。

現在のCustomer MasterだけをEnterprise IDへ統合し「これがGolden Customer」と扱うと、過去取引を現在の属性で解釈してしまいます。3年前のInvoiceを現在のSales Region・現在のCredit Group・現在のAccount Mappingで集計すれば、当時の判断や会計責任を正しく再現できません。

Dynamics 365 finance and operations appsの日付有効Entityでは、ValidFrom／ValidToを用い、現在値・指定日時点・指定期間のQuery Modeを区別できます。ただし、すべてのEntityやOData経路が同じようにAs-of取得できるわけではないため、製品機能と分析側の履歴設計を混同してはいけません。

ERPからFabricへ渡す際は、少なくとも次の項目を区別します。

表2：ERP→Fabric間で保持すべき時点・識別子の項目

在庫や受注の「現在値」を保存するだけではAs-of再現はできません。状態変化・Mapping・時点Master・訂正関係を一緒に保持して、初めて「その時点で、なぜその結果になったか」を説明できます。

---

ERPからFabricへはどう接続するのか

2026年9月23日時点では、製品ごとにFabricへの経路と性質が異なります。接続の技術方式を最初に決めることが誤りの始まりです。Source of Truth・Data Contract・ID・Legal Entity・Effective Dateを確定してから、Latency・Correction・ReplayなどのRequirementに合う接続方式を選びます。

表3：製品別・ERP→Fabric接続方式と設計上の注意

ShortcutとMirroringは同じものではありません。Shortcutは選択したTable・Folder・FileをSourceに残したままOneLake Namespaceへ公開します。MirroringはDatabase／CatalogをFabricへ追加し、Sourceに応じて参照または継続Replicationを行います。どちらの方式を選んでも、Source側の更新責任はFabricへ移転しません。

---

Evidence ChainをFabricへ接続する

Evidence Chainは、単なるAudit Log一覧ではありません。

次の9段階で構成されます。

Source → Interpretation → Suggestion → Action → Reviewer → Posted Entry → Correction → Outcome → Learning

この連鎖を、Transaction ID・Document ID・Ledger Entry ID・Agent Task ID・Approval ID・Actor・Timestamp・Legal Entity・Rule Version・Model／Prompt Version・Before／After・Reason Codeによって関連付けます。

原本となるPosted Document・Ledger Entry・Approval履歴・監査ログは、それぞれのSource Systemに残します。Fabricは、それらを置き換えるのではなく、業務・Agent・Telemetry・Outcomeを横断して調査・分析・長期再利用する場所として使います。

FabricのLineage ViewはWorkspace内のItem間の関係と一段上流のSourceを表示します。一方、PurviewへFabricをScanした場合、Power BI以外のFabric ItemはItem LevelのMetadata／Lineageであり、LakehouseのTable／FileのSub-item MetadataはPreview、Sub-item Lineageは未対応です。したがって、Lineage表示だけでEvidence Chainが自動完成すると考えてはいけません。

---

Semantic ModelとFabric IQ／Ontologyは何を担うのか

Power BI Semantic Modelは、FactとDimension・Relationship・Measure・KPI・Securityを通じて分析の意味を提供します。しかし、Semantic ModelがERPの失われた業務ルールを自動的に復元するわけではありません。

Fabric IQのOntologyは、2026年9月23日時点ではPreviewとして扱うのが安全です。Customer・Vendor・Item・Order・Invoice・Ledger・Projectなどの業務概念・Properties・Relationships・Rules・MetricsをData SourceへBindingし、人・Application・AI Agentが共有するBusiness Contextを提供する方向性が示されています。

これは非常に重要な進化です。しかし、Ontologyへ「Order」「Inventory」「Available-to-Promise」と書いただけで、ERPのReservation Policy・Credit Check・Posting Group（Business Central）やPosting profiles（FO系）・Tax・Period Closeが再現されるわけではありません。Semantic／Ontologyは意味と関係を提供します。実行可否とCommit／PostのAuthorityはOperational ERPに残ります。

なお、SQL database in Microsoft FabricはGAとなり、Azure SQL Database Engineを基盤とするOperational Databaseとして利用できます。しかし、Fabric上のOperational Databaseが存在することと、Dynamics 365やBusiness CentralのLedger・Settlement・Inventoryを代替できることは別問題です。

---

AI Groundingは「データを全部見せること」ではない

AIへ経験を渡すとは、過去データでModelを勝手に再学習させることではありません。AIが、現在のTransaction State・過去のException・当時のDecision・Authority・Correction・Outcomeへ、根拠と権限を伴って到達できるようにすることです。

Fabric Data Agentは、Lakehouse・Warehouse・Power BI Semantic Model・KQL Database・Mirrored Database・Ontology等に接続し、利用者の権限に基づいてSQL・DAX・KQLを生成・実行できます。一方、Data Modificationは許可されていません。

例えば納期例外では、AIは次のように参照を分けます。

OutcomeとCorrectionは、次回の検索・評価・Rule・Prompt・Example Queryを改善するために使います。これがLearningであり、無条件の自動再学習ではありません。

---

実案件で使う設計チェックリスト

ERPとFabricを接続できることは、Data Productが本番運用可能であることを意味しません。Copy／Pipeline・Mirroring・Shortcut・Linkなどの接続手段を最初に決めることが誤りの始まりです。まずSource of Truth・Data Contract・ID／Legal Entity・Effective Dateを確定し、その後でLatency・Correction・Replay・Security・Evidenceの要件に合う接続方式を選びます。

表4：AI Native ERP Data Design — 13の設計チェックリスト

---

ここまでのData Responsibility設計を、シリーズ全体のPromise to Outcomeの流れと、Dynamics 365エコシステム全体の文脈で改めて確認します。

---

まとめ—OneLakeを「すべての正本」にしない

Fabric／OneLakeの価値は、すべてを一つの更新Databaseへ統合することではありません。Operational ERPが現在のTransactionとPosting Responsibilityを持ったまま、Fabricが履歴・横断分析・Semantic・Evidence・AI Grounding／Learningを接続できることに価値があります。

Agentへ自律性を与える前に、何を読ませ、どのTruthを根拠にし、どのAuthorityで動かし、どのEvidenceを残すかを決めなければなりません。その設計が整って初めて、AgentのOperational Autonomyが機能します。

※「Operational Truth」「Analytical／Learning Truth」「Evidence Chain」「AI Grounding Canvas」「AI Native ERP Data Design Canvas」「Data Responsibility Map」はDX365Lifeの編集概念・編集モデルです。Microsoft Fabric・OneLake・Lakehouse・Warehouse・Direct Lake・Semantic Model・Shortcut・Mirroring・SQL database in Microsoft Fabric・Microsoft Purview・Fabric Data Agent・Fabric IQ・OntologyはMicrosoftの製品・機能名称です。Fabric IQ OntologyはPreview機能として、提供範囲・Region・Capacity・制限を採用時点で再確認してください。Posting profiles（FO系）とPosting Group（Business Central）は異なる用語です。

---

次回は、データ設計の先へ進みます。AgentをOperational Autonomyとして設計するとはどういうことか。

---

Let’s Enjoy our DX365LIFE!

---