こんばんは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

皆さん、いかがお過ごしでしょうか。最近、地震・豪雨凄いですね。。。嫌な雰囲気です。

環太平洋地震帯は今も動き続けていますね。毎年夏になれば線状降水帯が列島を縦断し、緊急地震速報が鳴ります。「今年も異常気象だ」—そう言い続けて、いつからか異常が当たり前になりました。

ITの進化も、同じかもしれません。毎年「今年は異常な変化だ」と感じながら、気づけばそのスピード自体が標準になっています。AIも、Fabricも、Copilotも—この数年で、ITとビジネスの語彙が根本から変わりました。

気象庁の予報精度が上がり続けているのは、AIモデルが賢くなったからだけではありません。センサーネットワークが緻密になり、データの収集設計が改善され、過去のデータが蓄積されてきたからです。どれだけ優秀なモデルがあっても、データの設計が悪ければ予報は外れます。地震計が壊れていれば、警報は鳴りません。

Dynamics 365のAIも、まったく同じ構造です。

このシリーズでは、#01でDynamics 365のアーキテクチャ設計パターンを地図として広げ、#02で月次・年度締め処理という「ERPの心拍数」を整理しました。今回は集大成として、締めた後のデータがどこへ行き、何になるのかを整理します。テーマは—データ基盤とAIの現在地です。

「AIを使いたい」より先に問うべきこと

「Copilotを導入したい」「AIで業務を自動化したい」—プロジェクト現場でこの言葉を聞く頻度が、ここ2年で劇的に増えました。しかし、AIをうまく活用するための重要な前提条件を整理せずに導入を始めると、必ず壁にぶつかります。

その重要な前提条件の一つが、データです。

気象予報士がどれだけ優秀でも、気象衛星が壊れていれば予報は出せません。AIエージェントがどれだけ賢くても、参照するデータが断片的・不整合・未整理であれば、回答品質を担保しにくくなります。AIの導入を考える前に、「自社のデータはどこにあり、どのような状態か」を問うことが出発点です。

Dynamics 365を使っている企業には、すでに膨大なデータがあります。Sales に顧客データがあり、Finance & Operations に財務・在庫データがあり、Microsoft Teams に会話データがあります。問題は、それらがそれぞれのシステムに分散して存在していることです。

このシリーズでは「地図を広げる」という表現を使ってきました。#03では、その地図にデータのレイヤーを重ねます。ハザードマップが地形・地質・過去の災害データを重ねて初めて「リスクの地図」になるように、Dynamics 365 のデータも、適切な基盤に統合されて初めて「AIが使えるデータ」になります。

データ × AI アーキテクチャ全体像—4つの層

Dynamics 365 の AI を正しく理解するには、Dynamics 365 単体ではなく、データ × AI アーキテクチャ全体を俯瞰する必要があります。このスタックは4つの層で構成されています。

※ 以下の「Layer 1〜4」という分類は、Dynamics 365・Microsoft Fabric・Microsoft 365・AI の関係を説明するための本稿独自の概念モデルです。Microsoft が製品仕様として定義している正式なレイヤー分類ではありません。各機能の GA/Preview 状況・連携方式は、Microsoft Learn の最新情報に基づいてご確認ください。

重要なのは、Dynamics 365 はこのスタックの「Layer 2」に位置するという理解です。Dynamics 365 は AI モデルの開発・大規模分析のための専用データ基盤ではなく、業務アプリケーションとして AI 機能を組み込みながら業務プロセスが動き、トランザクションが生まれ、データが蓄積される場所です。そのデータが Layer 3（Fabric）で統合・整備され、Layer 4（AI）で推論・自動化に活用される—この流れを設計することが、「Dynamics 365 × AI」の本質です。

Layer 1：外部データ・IoT・基幹システム—データの発生源

データは D365 の中で生まれるとは限りません。製造業なら工場のIoTセンサーが、自動車業界ならディーラーのDMSが、流通業ならWMSや物流会社のAPIが、データの最初の発生源です。Layer 1 はそうした「D365 の外側にあるデータの世界」すべてを指します。

Layer 1 に含まれる主なデータ源

Layer 1 設計の核心—「どこが SoR か」を決める

Layer 1 の設計で最も重要な問いは、「そのデータの正本（SoR）はどこか」です。同じ顧客情報が D365 Sales（Layer 2）と外部基幹（Layer 1）の両方に存在する場合、どちらが正でどちらが従か—これを決めずに連携すると、更新のたびにデータが上書き合戦になります。

連携パターンは大きく2つです。「Layer 1 → Layer 2 にマスターを持ち上げる」（外部の顧客データをD365に取り込み、D365をSoRにする）か、「Layer 1 と Layer 2 は並存させ、Layer 3 で統合する」（双方のデータをFabricで結合し、AI用の統合ビューだけを作る—この場合はどちらもSoRとして共存する設計）か。どちらが正解かはビジネスの実態によりますが、「なんとなく両方に入れておく」は最悪の選択です。

Layer 1 のデータ構造の設計は、Layer 2 のマスターデータ設計と並走して行う必要があります。「Layer 2 が固まってから Layer 1 を繋ぐ」という順序は、コード体系・エンティティキーの不一致が後から大量に発生する原因になります。

Layer 2：アプリケーション・オペレーティング層—Dynamics 365 と Microsoft 365

Layer 2 は「業務が動いているところ」です。ここには2種類のアプリケーション群があります。

#01「CRM×ERPデザインパターン」で整理したように、Dynamics 365 の組み合わせには5つの代表パターンがあります。ここで少し振り返っておきます。

どのパターンを選ぶかによって、Layer 2 で生まれるデータの構造・SoT の設計・Fabric への連携パスがすべて変わります。詳細は #01 をご覧ください。

Dynamics 365 が生むデータ

Dynamics 365 の各製品は、業務プロセスを実行しながら、膨大なトランザクションデータを生み出します。これらは単なる「記録」ではなく、顧客との関係・財務の実態・在庫の動き・プロジェクトの原価を反映した文脈のある（コンテキスト豊富な）データです。

※ 出典：Microsoft Learn（各製品 Copilot/AI ドキュメント、2026年調査時点）。Preview表記のものはGA前の機能。

帳票という名のデータ—版管理が語る顧客の特性とオペレーターの特長

Layer 2 で生まれるデータは、トランザクションデータだけではありません。帳票（見積書・注文書・請求書・作業完了報告）もまた、版管理されれば極めて重要なビジネスデータになります。

見積書の改訂履歴を見てください。改訂回数が多い顧客は価格交渉型、特記事項が増えるパターンは要求仕様が固まっていない証拠、納期変更が繰り返される案件は後工程でトラブルになりやすい—版管理・監査ログを適切に設計していれば、これらは構造化データとして帳票の変更履歴に残ります。帳票の変更履歴は、ビジネスの「プレー映像」です。ある営業担当者は平均4回改訂してから受注し、別の担当者は1回で決める—こうした履歴を十分な構造化データとして蓄積すれば、AI/分析によって交渉スタイルの違いを特徴として抽出できます。請求書の深夜・休日処理パターンや同一取引先への集中発注は、内部統制・不正検知のシグナルにもなります。

ただし、版管理がなければこれらのデータは消えます。CRMの Word Template は標準ではバージョン管理機能がなく、上書き保存した瞬間に旧版は消える。Invoice_final_final.docx 問題は笑い話ではなく、顧客との交渉履歴の消失です。BC・FO・CRM それぞれの帳票技術（RDLC・Word Layout・SSRS・ER・Word Template）と版管理の設計については、このシリーズを参照してください。

Microsoft 365 が持つデータ—標準統合機能の実際

見落とされがちですが、Microsoft 365 にも膨大なビジネスデータがあります。そして Dynamics 365 CRM には、これらのデータを CRM レコードに取り込む標準統合機能が備わっています。

Dynamics 365 App for Outlook（GA）。 Outlook のメール・会議・予定を D365 レコード（取引先・商談・ケース等）に紐付けます。Server-Side Synchronization により Exchange と D365 のメール・予定などがバックグラウンドで非同期同期され、紐付けられたメールや会議はそのまま D365 レコードのタイムラインに活動履歴として記録されます。Copilot はこの活動履歴を参照して商談サマリーや会議準備サポートを生成します。

Email Engagement（GA）。 Dynamics 365 から送信したメールの開封・リンククリック・返信・添付ファイル閲覧などのエンゲージメント情報を取得し、営業活動の判断材料として活用できます。「顧客が提案書を開封した瞬間にリアルタイム通知」「テンプレートごとの返信率・開封率の分析」—商談の温度感をデータで把握する機能です。営業担当者の感覚ではなく、行動データで商談を読む。

Teams 統合（Basic Collaboration、GA）。 D365 レコードを Teams チャネルのタブとして追加し、チャネルのファイルと D365 のドキュメントを双方向同期します。商談ごと・ケースごとに Teams チャネルを紐付けることで、TeamsチャネルとDynamics 365レコードを関連付け、Teamsで管理されるファイルをSharePoint経由でDynamics 365から参照・共同編集できます。

SharePoint / OneDrive 統合（GA）。 D365 レコードに紐付いた SharePoint ドキュメントライブラリを D365 内から直接操作できます。提案書・契約書・仕様書を D365 の商談・取引先レコードと紐付けて管理することで、ドキュメントの散在を防ぎます。OneDrive 統合は SharePoint 統合を前提とし、個人ドキュメントの管理に使います。

Dynamics 365 と Microsoft 365 が同じ Microsoft Entra ID（旧 Azure AD）で管理されているのは偶然ではありません。同じアイデンティティ基盤の上に業務アプリケーションと生産性ツールが乗っているからこそ、これらの統合を Microsoft Entra ID という共通の ID 基盤のもとで構成しやすくなっています。ただし、各サービスの認可・データアクセス権はそれぞれの製品の権限モデルを考慮した設計が必要です。「商談が停滞しているか」を判断するとき、商談ステータスだけでなく、Outlook のメール往来履歴・Email Engagement の開封データ・Teams チャネルの活動—これらを組み合わせて Copilot が推論できる基盤が、すでに標準機能として存在します。

マスターデータという名のラスボス

Layer 2 を語るとき、避けて通れないのがマスターデータの問題です。以前このブログで「マスターデータはDynamicsなスクラムだ」というタイトルで書いたように—私はこれを「マスター界のラスボス」と呼んでいます。

典型的なグローバル企業のデータ環境を想像してください。OEM側にCRM・ERP・DMSの3システム、ディーラー側に最大5システム、合計8システムが独立稼働する。その結果、同じ顧客が異なる名義・異なるIDで複数のシステムに登録される—これが「バラバラ殺データ事件」です。AIにどれだけ高価なツールを投入しても、食わせるデータがバラバラでは回答品質を担保しにくくなります（Garbage In, Garbage Out）。

この問題の核心は名寄せ（Entity Resolution）—同一実体が複数システムに異なる形で存在する状態を統合・突合することです。マッチング判定には「高確信→自動マージ」「中確信→人間レビューキュー」「低確信→別レコード保持」の3段階が有効です。そして名寄せに完璧な終戦はありません。本稼働後も重複は日々生まれ続けます。継続的な運用プロセスとして設計することが前提です。

マスターデータのもう一つの設計軸がSoR（Source of Record）—そのデータをどのシステムが正本として管理するかです。一例として、見込み段階ではCRMが正本を持ち（不完全なデータをERPに流し込むと財務マスターが汚染される）、成約を境にERPへバトンタッチする設計があります。ビジネスや組織構造によって最適なSoR設計は異なりますが、ライフサイクルに応じたSoR設計なしに、Fabricへのデータ統合は正しく機能しません。

データの川を繋げる—Lead to Cash の設計

「ノックフォワードが起きる企業はなぜ負けるのか」でも書きましたが、CRMは「攻めのDX」、ERPは「守りのDX」です。どちらか一方だけでは現代のビジネスは完結しません。

AI Agentはデータの川の上を泳ぎます。川が繋がっていれば、Agentはリード獲得から入金・債権消込まで自由に泳げます。川がどこかで干上がっていたら—データがサイロ化していたら—Agentはそこで立ち往生します。リードから入金まで一本の川として繋げる設計、これがLead to Cashであり、Layer 2 設計の本質です。

「ノックフォワードしないデータ連携」でも詳しく書いたように、ERPとDataverse間の連携には複数のアプローチがあります。在庫数・与信枠などリアルタイム性が必要なデータにはVirtual Table、CRM/ERP間で業務トランザクションデータを双方向同期する必要がある場合にはDual-write（FO↔Dataverse）、分析・AI用途にはFabricへのデータ連携—業務要件から逆算して意図的に使い分けることが設計者の腕の見せ所です。「とりあえず全部Dual-write」も「とりあえず全部Virtual Table」も危険な設計です。

Layer 3：Microsoft Fabric—データを統合・蓄積する基盤

Microsoft Fabric は、2023年に登場した Microsoft のデータ統合プラットフォームです。一言で表現するなら—「Office がドキュメント作業を Office 製品に統一したように、Fabric はデータ関連の作業を Fabric に統一する」プラットフォームです。

これまで企業のデータ基盤は、Azure Data Factory（ETL）・Azure Synapse（分析）・Power BI（BI）・Azure Data Lake Storage（データ保存）—と、複数のサービスを組み合わせて構築するのが一般的でした。Fabric はこれらを一つのプラットフォームに統合し、SaaS として提供します。

OneLake—すべての基盤

Fabric の中心にあるのが OneLake です。OneLake は組織全体の単一のデータレイクで、Fabric のすべてのワークロードが同じ OneLake 上のデータを参照します。部門ごと・システムごとにデータレイクを作るのではなく、組織に一つの OneLake—これが Fabric の設計思想です。

OneLake 上の構造化された表形式データでは Delta/Parquet が主要なオープン形式として利用されるため、特定のベンダーにロックインされません。また、Dynamics 365・Azure・外部データが OneLake に統合されることで、不必要なデータコピーと移動を削減できます。

ETL から ELT へ—データの扱い方が変わった

かつてのデータ統合の常識は ETL（Extract → Transform → Load）でした。データを取り出し、整形・変換してから、データウェアハウスに投入する。整形が済んだ「きれいなデータ」だけを入れる設計です。

Fabric では ELT（Extract → Load → Transform）型の設計を取りやすくなります。まず OneLake に生データをそのまま投入し、必要に応じて変換・加工する。ETL/ELT のどちらが最適かは要件によって異なりますが、Fabric のアーキテクチャは ELT を選びやすい設計になっています。これを支える構造が、メダリオンアーキテクチャです。

メダリオンアーキテクチャ—Bronze・Silver・Gold

OneLake のデータは品質レベルによって3層に整理します。

Bronze は「安全網」です。ソースデータを変換せずに保存しておくことで、変換ロジックを後から修正しても Bronze に戻れます。Silver・Gold への変換計画は先に設計しておく必要がありますが、変換の実行は需要に応じて段階的で構いません—「全データを完璧に整形してからでないと使えない」という従来の発想から解放されます。

ELT を支えるのはコストの非対称性でもあります。Dataverse の追加容量と OneLake のストレージコストには大きな差があり、大量の履歴データや生データを OneLake 側で管理する方が経済的なケースが多いです（価格は地域・契約形態・時期によって変動するため、最新の Microsoft 価格ページでご確認ください）。「きれいになってから入れる」ために高価な計算リソースを事前に使うより、「まず入れて、必要なときに変換する」ELT の方が、運用コスト全体でも有利になります。

Gold → CDP → デジタルマーケティングへ

Gold 層のデータは、Dynamics 365 Customer Insights – Data（CDP）に連携することで、顧客との接点を変えます。以下は代表的な設計パターンの一例です（OneLake から Customer Insights – Data に直接取り込む方式など、他のパターンも存在します）。

「この顧客はそろそろ更新時期」「このセグメントにはこのキャンペーン」—Customer Insights Data で統合・分析した顧客プロファイルを基にセグメントを設計し、その結果を Journeys で活用します。Segment・Measure・Activation の設計は別途必要ですが、データ基盤が整っていれば、これらの設計を高精度で運用できます。営業担当者は判断するのではなく、CDPが提案した行動を実行する役割に変わります。これが Layer 2（D365 Sales・Marketing）と Layer 3（Fabric・CDP）が連動した設計の形です。

Fabric のワークロード

Fabric IQ—AIが「テーブル」ではなく「ビジネス」を理解する

Fabric IQ は、Fabric の中でも特に重要な新機能です。通常、AI はデータベースのテーブル名やカラム名を見て推論します。しかし「Customer」というテーブルが Dynamics 365 の Sales にあり、別の「Account」が Finance & Operations にあり、さらに「得意先マスタ」という名前の基幹テーブルがある—という状況で、AIが「これらが同じ概念か」を推測できる場合もありますが、企業システムとして保証可能な形で統一するには、セマンティック定義やマスターデータ設計が必要です。

Fabric IQ はこの問題を解決するアプローチです。AI がデータやメタデータを理解しやすくするための知識・コンテキスト層として機能し、セマンティックモデルやメタデータの整備を通じて、「Customer」「Product」「Order」といったビジネスエンティティの意味や関係性を Fabric 全体で共有できるようにします。従来型の MDM や専用オントロジープラットフォームと同義ではなく、実装方法もプロジェクトによって異なりますが、目指す方向は同じです—AIに業務の文脈を理解させること。これにより：

• AI Agent がテーブル名ではなくビジネスの意味でデータを参照できる
• 複数システムの「Customer」が統一概念として扱われる
• 分析的データ・時系列データ・地理空間データが同一の意味モデルで統合される

Fabric IQ のコンテキストや Ontology を整備することで、Copilot や Autonomous Agent がビジネス上の意味を踏まえてデータを参照しやすくなり、回答品質の向上に寄与します。逆に言えば、ビジネスコンテキストが不十分なまま AI Agent を導入すると、データの意味を十分に捉えられず、単純なデータ検索に近い利用に留まる可能性があります。

ただし、Fabric IQ の実装は一朝一夕では終わりません。オントロジーを正しく定義するには、ビジネスを理解したドメインエキスパートとデータ構造を理解したデータエンジニアが協働する必要があります。「Customer とは何か」という一見シンプルな問いが、営業・財務・マーケティング・サービスでそれぞれ異なる定義を持つことは珍しくありません。現実的なアプローチは、Customer・Product・Order などコアエンティティ数個（筆者なら5〜10個程度から着手）から段階的に拡張していくことです。この数はあくまで筆者の設計指針であり、製品公式の推奨値ではありません。また、オントロジーは一度定義すれば終わりではなく、ビジネスの変化・製品追加・組織改編のたびにメンテナンスが必要な「生きた設計資産」です。導入前に、誰がこれを維持するかを決めておくことが、長期的な成功の条件になります。

過去データをどう Fabric に持ち込むか—データ移行の再定義

Fabric の価値は「今日からのデータ」だけではありません。過去のトランザクション履歴こそが、AIが「なぜこの顧客は受注に至ったのか」「なぜこの案件は失注したのか」を推論するための根拠になります。必要な期間は予測対象・業種・データ品質によって異なります。このブログでは以前、AI時代のデータ移行をテーマに2本の記事を書きました。

データ移行は「片付け作業」ではありません。企業の過去の経験を、AIという相棒が参照できる形で残すための、最もクリエイティブな投資です。

Dynamics 365 → Fabric 連携パス

Layer 2（D365・M365）のデータを Layer 3（Fabric）に統合する方法は、製品によって異なります。連携パスを理解していないと、「データは Fabric に入れた」と思っていたのに実は断片的にしか連携されていない—という設計ミスが起きます。

連携パスを設計する際には、どのデータを、どの頻度で、どのフォーマットで Fabric に入れるかを事前に定義することが重要です。「とりあえず全部入れる」では、OneLake がデータの墓場になります。#02 で整理した月次締め処理の設計と連動させ、「いつのデータが確定済みか」を Fabric 側でも管理できる設計にしておくことが理想です。

Layer 4：AIが動く条件—Copilot と Autonomous Agent

Layer 3（Fabric）のデータ基盤が整って初めて、Layer 4 の AI が正しく機能します。2026年時点の Microsoft AI スタックには、主に3種類の AI 活用モードがあります。

Copilot（各製品組み込み）

Copilot は Dynamics 365 の各製品に組み込まれた AI アシスタントです。Sales では商談サマリーやメール草案生成、Customer Service ではケース解決提案、Finance & Operations ではキャッシュフロー予測サマリー、Business Central では在庫補充提案や請求書処理の補助—それぞれの業務文脈に特化した形で動作します。

Dynamics 365 に組み込まれた Copilot は、基本的に各製品のデータ（Dataverse または FO/BC のデータ）と権限モデルを中心に動作します。D365 組み込み Copilot から Fabric 上のデータを利用する場合は、対応する製品・機能に応じた grounding／セマンティックモデル等の構成が必要です。一方、Fabric data agent や Microsoft 365 Copilot を活用することで、Fabric 上の OneLake・Lakehouse・Power BI セマンティックモデルなどを AI の grounding データとして利用する別のアーキテクチャも構成できます（一部 Preview）。

Autonomous Agent（Copilot Studio）

Autonomous Agent は、人の指示なしに目標に向かって自律的に動くAIです。Copilot Studio で構築し、Dynamics 365・Microsoft 365・外部システムの API を呼び出しながら、複数ステップのタスクを実行します。

#02 で紹介した Financial Close Agent・Account Reconciliation Agent・Project Variance Agent もこのカテゴリです。Agent は「何をするか」ではなく「何を達成するか」を定義する—これが Copilot との本質的な違いです。

Azure AI Foundry（カスタムAI開発プラットフォーム）

企業固有の高度なカスタムAIを構築する場合は Azure AI Foundry を使います。Azure AI Studio から発展したこのプラットフォームでは、Azure OpenAI Service を含む複数のモデルや AI サービスを利用して、AI アプリケーションの開発・評価・運用を行えます。モデル選択、エージェント/AI アプリ開発、RAG（Retrieval-Augmented Generation）、Fine-tuning、評価・デプロイなどの機能を提供します（個別機能の GA/Preview 状況は Microsoft Learn でご確認ください）。Fabric に蓄積されたデータを学習・推論の基盤として活用する点は、Copilot・Agent と変わりません。

Agentic Engineering—Autonomous Agent を設計・運用するために

Autonomous Agent は「導入すれば動く」ツールではありません。何を達成するか（目標設定）・どこまで自律させるか・必要に応じて Human-in-the-Loop を組み込むか・データをどう使うか・ログと監査をどう担保するか—これらをアーキテクチャとして設計することが、実務でのAgent活用の前提です。このブログではAgentic Engineeringをテーマに連載を書きました。Layer 4 の設計に入る前にぜひ目を通してください。

4層設計を実例で考える—自動車OEM篇、そして全業界へ

ここまで4層のアーキテクチャを整理してきました。理屈はわかった。では実際の現場では、何がどこで生まれ、どう繋がるのか—自動車OEMの事例で具体的に考えてみます。

この業界の構造的な問題については、2026年6月に開催したオンラインセミナー「顧客との絆を、データとAIで再定義する」でも詳しくお話しました。デモや事例を含む詳細は下記をご参照ください。

「誰が来店したか、誰が買ったか」—20年間、メーカー側にはよくわからなかった

（以下は説明のための想定モデルです）自動車OEM特有のデータ断絶構造の一例として、OEM側でCRM・ERP（SCM中心）・会計の3システム、ディーラー側でDMS（新車）・DMS（アフター）・CRM（新車）・CRM（アフター）・会計の5システム—合計8つのシステムが、それぞれ独自の主キーで動いているケースがあります。

その結果、「株式会社テクノソフトコンサルティング」「ﾃｸﾉｿﾌﾄｺﾝｻﾙﾃｨﾝｸﾞ（株）」「ﾃｸﾉｿﾌﾄｵｰﾄﾓｰﾃｨﾌﾞ事業部」—同一顧客が6つの異なるIDとして複数のシステムに存在します。これがLayer 2の「バラバラ殺データ事件」の典型です。

DMSはもともと「1台＝1人」という設計思想で作られており、「所有者は父・手続きは母・使うのは息子」という実態に追いついていません。「顧客のことを知りたい」と言い続けて20年以上—最終的にメーカー側は「誰が来店したのか、誰が買ったのか」がよくわからないまま今日に至ります。ゴミを入れれば、ゴミが出てくる。データが揃っていない状態でAIに渡しても、誤回答リスクが高くなります。

そのデータはどこで生まれているか

OEM本社がグローバルのNSC・ディーラーをリアルタイムで把握したいとき、各KPIの発生源はどこでしょうか。

「Fabricがなければ、どうなるか」

（以下は説明のための想定シナリオです）各NSCが独立したD365インスタンスを持ち、Fabricで繋がっていない場合—OEM本社がデータを見たいとき、各NSCに「Excelを送ってください」という依頼が走ります。データが揃うのは数週後。AIに渡せるのは「先月のスナップショット」であって「今日の現在地」ではありません。

名寄せが未整備であれば問題はさらに深刻です。日本のNSCが「トヨタ東京」と登録し、東南アジアのNSCが「Toyota Tokyo JP」と登録している—Fabric IQ の Ontology などのセマンティック定義なしでは、企業全体で保証可能な形で同一顧客として統合することは容易ではありません。Layer 3の設計が不十分なままLayer 4のAIを動かしても、「NSCごとの断片的な推論」になりやすいです。

AIが動く条件—乗り換えスコアリングの例

Layer 3が整備されると、Layer 4のAIは「次の行動提案」ができるようになります。自動車の場合、その典型が乗り換えスコアリングです。

このフローの前提は、FabricにFO・CRM・DMS・テレマティクスのデータが統合されていることです。Layer 3なしにLayer 4だけ入れても、「モデル年式と車検期日が今すぐわかる」というだけの話になってしまいます。勝負はショールームの外で決まる—そのための設計がLayer 3です。

マスターデータが資産になるとき

GMのCadillac ANZでは、TASのマスターデータを軸にD2C（Direct-to-Consumer）のECサイトを構築しました。車両写真・価格・スペック・オプションがすべてDynamics 365（CRM/ERP）に格納され、WebサイトはそのデータのOutput先として機能しています。（著者が関与したプロジェクトの概要に基づく解説）

この設計が示すことは一つです—「マスターデータが正しく作られていれば、フロントエンドはいつでも載せ替えられる。」

データが資産として整備されていれば、UIを変えても、アプリを追加しても、AIを乗せても、基盤はそのまま使えます。逆に、マスターデータが8つのシステムに分散したまま名寄せもされていない状態では、EC化もAI化も「そのシステム限り」の局所解にしかなりません。

設計で変わる「AIが答えられる問い」

Fabricが正しく設計されると、AIが答えられる問いの質が変わります。

自動車OEMから、全業界へ

この構造は自動車OEMに限りません。業界が変わっても、問いの構造は同じです—「そのデータはどこで生まれ（Layer 2）、どうFabricに届き（Layer 3）、どのAIに渡るか（Layer 4）」。

「ある製造業の物語」として別途まとめた内容では、工場の品質データから始まり、財務と繋がり、最終的にAIが経営の問いに答えるまでの旅程を追っています。業界は違っても、地図の描き方は共通しています。

どのパターンであっても、データが生まれる構造は同じです—改めて、このシリーズのコアを振り返っておきます。

AIより先に、データを設計する

「AIを使いたい」という要件を受けたとき、最初に問うべきは「どんなモデルを使うか」ではありません。「AIが参照するデータはどこにあり、どんな状態か」です。

気象庁の気象スーパーコンピューターがどれだけ高性能でも、気象観測所のセンサーが壊れていれば予報は出せません。AIの精度はデータの品質・整合性・網羅性に直接依存します。実務で押さえておくべき設計原則を整理します。

データの「旅程」を設計する。 データがどのシステムで生まれ（Layer 2）、どのパスで Fabric に届き（連携設計）、どのワークロードで処理され（Fabric）、どの AI に渡るか（Layer 4）—この全行程を設計段階で明示してください。「データは Dynamics 365 にある」で止まっている設計は未完です。

Fabric IQ のビジネスエンティティ定義を先行させる。 AI Agent の導入より前に、Fabric IQ で「Customer とは何か」「Product とは何か」「Order と Invoice の関係は何か」を定義してください。これが後回しになると、Agent は異なるシステムの同一概念を別物として扱い、誤った推論を返します。

データ品質を数値化する。 ゴミが入ればゴミが出ます（Garbage in, garbage out）。Dynamics 365 のマスタデータ（取引先・品目・勘定科目）の整合性・完全性・最新性を定期的に確認する仕組みを、AI 導入前に整えてください。Microsoft Purview を使ったデータカタログとデータ品質スコアの管理が有効です。

リアルタイムとバッチを使い分ける。 Fabric の Real-Time Intelligence（秒レベルの低遅延処理）はすべての用途に適用するものではありません。IoT センサーの異常検知・在庫アラートなど即時判断が必要なシナリオにはリアルタイム連携を使い、財務分析・需要予測などはバッチ処理で十分です。コストと用途のバランスを設計段階で定義してください。

ガバナンスを後から考えない。 Microsoft Purview によるデータカタログ・機密ラベル・アクセス制御は、データ基盤構築と同時に設計します。「まず使えるようにして、ガバナンスは後で」は、グローバル環境では法的リスクに直結します。

データは Azure の中にある—コンプライアンスの現実

Dynamics 365 のすべてのデータは Azure のデータセンターに保存されます。Sales の商談データも、Finance & Operations の財務データも、Business Central の仕訳データも—例外なく Azure のクラウドインフラ上に存在します。これは利点でもあり、同時にコンプライアンス上の責任を伴います。

GDPR（EU一般データ保護規則）。 EU/EEA の個人データを扱う場合、GDPRの適用を受けます。顧客の所在地・従業員の居住地・取引パートナーの拠点がEUにあれば、自社がどの国にあっても対象です。データの処理目的の明示、削除権（忘れられる権利）への対応、個人データ侵害時の監督機関への報告義務—これらはシステム設計段階で組み込む必要があります。

改正個人情報保護法（日本）。 2022年施行の改正個人情報保護法は、外国への個人データ移転に関する規定を強化しました。Dynamics 365 のデータが日本国外の Azure データセンターで処理される場合、移転先の体制確認と本人への情報提供が求められます。Microsoft は日本リージョン（東日本・西日本）を持ちますが、どのリージョンにデータが置かれるかを確認・固定する設計が必要です。

DPA（Data Protection Agreement）。 Microsoft と契約する際、Microsoft Online Services Data Protection Addendum（DPA）が適用されます。このDPAは、Microsoftがデータ処理者として個人データをどのように扱うか—処理目的の制限、セキュリティ対策、データ移転の保護、監査権—を規定します。エンタープライズ契約では、DPA の内容と自社のプライバシーポリシーの整合性を法務部門と確認してください。

Azureリージョンが存在しない国での設計。 Microsoft Azure のデータセンターはすべての国に存在するわけではありません。東南アジア・中東・アフリカ・中米など、Azureリージョンが整備されていない国では、隣接する国のリージョン（例：シンガポール・UAEノース・南アフリカ北部・米国東部など）を使わざるを得ない場合があります。これは実務上、相当やっかいな問題です。

国によっては「データは国内に置かなければならない」という法律（データローカライゼーション規制）があり、Azureリージョンが存在しない場合に Dynamics 365 をそのまま導入すると法的リスクを抱えます。実際のプロジェクトでは、①Microsoftに対してデータ居住地（Data Residency）の保証を書面で確認する、②その国の規制当局がクラウドのクロスボーダー処理を認めているか確認する、③認めていない場合はオンプレミス・ハイブリッド構成の検討が必要になる—というステップを踏む必要があります。グローバル展開のプロジェクトでは、国別の Azure リージョン可用性と現地データ保護法の確認を、アーキテクチャ設計の最初期に行ってください。

なお、「個人データをクロスボーダーで扱えない」という制約が避けられない場合、意図的に粒度を落とした集計・匿名化分析で対応するという設計も有効な選択肢です。顧客の個人データはその国のオンプレミスに留め、地域別の集計指標・KPI・トレンド情報だけをクラウド側に送り、本社の Fabric や Power BI で横断分析する—というアーキテクチャです。AIの精度はやや下がりますが、コンプライアンスリスクを根本から回避できます。「完璧なデータ統合」を目指すより、「法的にクリーンな範囲で最大のインサイトを得る」という発想が、グローバル展開では現実的です。

「クラウドは Microsoft が守ってくれる」は半分正しく、半分誤りです。インフラとサービスのセキュリティ責任は Microsoft が持ちますが、データの分類・アクセス制御の設計・利用目的の管理・リージョン選定の責任は契約企業にあります。Microsoft Purview による機密ラベルとデータガバナンスは、コンプライアンス対応の実務ツールとしても機能します。データ基盤の設計とコンプライアンスの設計は、最初から並走させてください。

Azure セキュリティ—「データを集める」だけでは、企業AIにはならない

ここまで、Dynamics 365 の業務データを Microsoft Fabric / OneLake に集約し、Fabric IQ などによってビジネス上の意味を与え、Copilot や Agent から活用するアーキテクチャを説明してきました。しかし、企業で AI を本番利用するためには、もう一つ欠かせない視点があります。それがセキュリティとガバナンスです。

企業データを OneLake に集約すればするほど、「誰が・どのデータを・どの目的で・どの AI から利用できるのか」を明確にしなければなりません。Dynamics 365・Microsoft 365・Fabric・Azure・Copilot・AI Agent を横断して利用する場合、「データを一か所に集めること」と「誰でも一か所から見られること」は全く別の話です。企業 AI では、むしろデータを統合した後のアクセス制御が重要になります。

重要なのは、セキュリティを「Layer 5」として後付けするのではなく、全レイヤーを横断するコントロールとして考えることです。

1. Microsoft Entra ID — 「誰なのか」を確実にする

最初に考えるべきは Identity です。Microsoft Entra ID を企業の ID 基盤として利用することで、ユーザー・グループ・アプリケーション・サービスなどの Identity を統合的に管理できます。

しかし、企業 AI では「ログインできる」だけでは不十分です。営業担当者が Copilot に「この顧客の過去の取引履歴を教えて」と質問したとき、AI が答えられるかどうかはその人がそのデータを見る権限を持っているかによって決まらなければなりません。

2. Microsoft Purview — 「そのデータは何なのか」を管理する

Fabric IQ がデータのビジネス上の意味を扱うのに対して、Microsoft Purview はデータガバナンス・カタログ・分類・コンプライアンスの観点から重要になります。同じ Customer データでも、「Customer とは何か」という意味定義（Fabric IQ）と、「このデータには個人情報が含まれるか・誰が利用できるか・どこから来てどこで使われているか・保持期間はどうするか」（Purview）は別の問いです。

3. Microsoft Defender — 「攻撃されない」だけでなく「異常を検知する」

AI Agent が外部 API を呼び出し、Dynamics 365 のデータを参照し、Microsoft 365 の情報を利用し、さらに業務処理まで実行するようになると、「Agent が何を参照できるか」だけでなく、「Agent が何を実行できるか」まで管理する必要があります。Microsoft Defender の各機能により、Identity・Endpoint・Application・Cloud・Storage・Network を横断した脅威検知・防御を構成できます。

重要なのは、AI を導入することで新しい攻撃面が増えるという認識です。セキュリティは AI 導入後に考えるものではなく、アーキテクチャ設計と同時に検討すべきものです。

4. Azure Key Vault — 「秘密情報をコードに書かない」

AI Agent やデータ連携では、API Key・Connection String・Certificate・Secret などの機密情報を扱う場面があります。これらをソースコードや設定ファイルに直接記述することは、Git リポジトリや CI/CD パイプラインを通じた情報漏洩につながります。Azure Key Vault で機密情報をアプリケーションコードから分離し、Managed Identity を利用できる場面では「アプリケーション自身に Identity を持たせ、必要な Azure リソースへ権限を与える」設計にします。これは AI Agent を本番運用する場合にも特に重要です。

5. Azure Policy — 「作ってから確認する」のではなく、最初からルールを適用する

「開発者が作った Azure リソースを後からセキュリティ担当者が確認する」だけでは、グローバル展開する企業環境ではスケールしません。Azure Policy を利用して、許可するリージョン・暗号化要件・ネットワーク設定・タグ・特定サービスの利用条件などを組織のポリシーとして継続的に適用します。セキュリティを人手によるチェックから、継続的なポリシー適用へ変えるという考え方です。

6. Microsoft Sentinel — 「ログを見る」から「セキュリティ運用」へ

Dynamics 365・Fabric・Microsoft 365・Azure・Identity・ネットワークを横断する企業 AI 環境では、ログも分散します。Microsoft Sentinel（SIEM/SOAR）で複数環境からセキュリティ関連データを集約し、「誰が Agent を利用したのか」「Agent は何を呼び出したのか」「異常なアクセスが発生していないか」という観点まで監視対象に含めます。

7. ネットワーク — 「AIからデータへ」の経路そのものを制御する

Identity だけを見てはいけません。Virtual Network・Private Endpoint・Network Security Group・Firewall などを組み合わせて、データへのネットワーク経路そのものを制御します。企業の基幹データを扱う場合、「そもそもインターネットから直接到達できる必要があるのか」を最初に問うことが重要です。

8. AI 時代のセキュリティで最も重要なのは「Agent の権限」

従来のアプリケーションでは User → Application → Database という関係を設計すれば済むケースが多くありました。しかし Agent 時代には、Agent が Dynamics 365・Fabric・SharePoint・外部 API・Azure サービスを横断して呼び出します。ここで最も重要な原則が、

「データ基盤」と「セキュリティ基盤」はセットで考える

このアーキテクチャが示すのは、OneLake にデータを集めることがゴールではないということです。企業 AI の本当のゴールは「必要なデータを、必要な人・AI が、必要な範囲だけ、安全に利用できる状態」を作ることです。

データ統合・意味付け・AI、そして Security。この 4 つを別々のプロジェクトとして考えるのではなく、一つの企業アーキテクチャとして設計することが、AI を「デモ」から「本番の業務基盤」へ移行するための条件になります。

落とし穴—Layer別に整理する

失敗パターンはどの層で起きているかによって、対処方法が変わります。同じ「AIの精度が出ない」という症状でも、根本原因がLayer 1にあるケースとLayer 4にあるケースでは、解決策がまったく異なります。

落とし穴の多くは「下の層の問題を上の層で解こうとする」パターンです。Layer 1のデータ品質問題をLayer 3のFabricで補正しようとし、Layer 3の設計不備をLayer 4のAIプロンプトで誤魔化そうとする—その連鎖が「AIの精度が出ない」という症状として表れます。設計の順序は変えられません。

まとめ

気象衛星ひまわりは、毎日何十億ものデータポイントを地球に送り続けています。それを受け取る地上局があり、処理するスーパーコンピューターがあり、モデルが継続的に学習し、予報が生まれます。どれか一つが欠けても、今日の天気予報は存在しません。

Dynamics 365 が生み出すデータも、同じ構造です。

Sales が商談データを生み、Finance & Operations が財務データを確定し、Field Service が現場の作業実績を記録する—これが「センサーネットワーク」です。Microsoft Fabric の OneLake がそれらを統合し（「地上局」）、Fabric IQ・セマンティックモデル・マスターデータ設計がビジネスの意味を支え（「気象モデルの設計」）、Copilot や Autonomous Agent が推論・自動化を実行する（「天気予報」）。

このスタック全体を設計することが、2026年の「Dynamics 365 × AI」の本質です。AIツールの選定より先に、データの旅程を設計してください。ハザードマップが地形・地質・過去データを重ねて初めてリスクを可視化するように、Dynamics 365 のデータも Fabric で統合され、Fabric IQ で意味が定義されて初めて「AIが使えるデータ」になります。

異常気象が当たり前になったように、ITの異常な進化も当たり前になっていきます。変わらないのは—良いデータ設計が、良いAIを生むという原則です。

皆さんの環境では、どの層の設計が一番の課題ですか？Fabric 連携で困っていること、Copilot の精度が思ったより出ない経験—ぜひコメントや SNS で教えてください。

それでは今日はこのくらいで。Let’s Enjoy our DX365Life!