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

皆さん、週末をいかがお過ごしでしょうか。

今日は、ラグビーリーグワンの試合をJ SPORTSで観戦していました。

そんな中、山口良治監督の訃報に触れる一日となりました。山口先生は、伏見工業高校ラグビー部の監督としてチームを日本一に導き、「泣き虫先生」の愛称で多くの人に親しまれ、後に『スクール☆ウォーズ』のモデルにもなられた方です。決勝戦では大阪工大高校と激闘を繰り広げ、最後は劇的なトライで僅差の勝利を収め、高校ラグビーの頂点に立たれました。心よりご冥福をお祈りいたします。

また、本日サントリーサンゴリアスは惜しくも敗れましたが、3位決定戦は中村亮土選手、流大選手、垣永真之介選手の引退試合となります。日本代表として長年にわたり体を張り続けた選手たちの最後の雄姿を、しっかり見届けたいと思います。

さて、ラグビーには「ノックフォワード」という反則があります。以前は「ノックオン」とも呼ばれていましたが、現在はワールドラグビーの規則改定により正式名称が変更されています。ボールを前方に落としてしまう反則で、せっかく繋いできたパスが一瞬で途切れてしまう、あの場面です。ラグビーはボールを前に投げることができないスポーツです。だからこそ、後ろへのパスを繋ぎ続け、最後にトライを取りに行く。その流れの中で、一度でもボールが前にこぼれてしまうと、それまで積み重ねてきた攻撃はすべて途切れてしまいます。

実は、データ連携でも同じことが起きます。ERPに蓄積された大切なデータが、システムの境界で途切れてしまう。Power PlatformやDataverseに渡したいのにうまく繋がらない。あるいは繋がったとしても、「どこにデータが存在しているのか」が見えなくなってしまう。これはまさに、データの世界における「ノックフォワード」です。

「信は力なり。」

山口先生のこの言葉が、頭を離れません。

システム間の連携も、信なくしては成り立ちません。ERPがDataverseを信じ、DataverseがERPを信じる。その信頼の経路をどう設計するか—それがそのまま、システムの力になります。Virtual Tableは、その極致とも言える存在です。データをコピーしない、移動させない。ERPにあるデータを、そのまま信じて参照する。信頼があるからこそ、複製せずに済むのです。

今日は、その「信じ方の設計」について整理してみます。

本記事では、Dynamics 365 Finance & Operations（FO）およびBusiness Central（BC）をシステム・オブ・レコードとした前提で、DataverseとVirtual Tableをどのように使い分け、どこでデータを保持し、どこで参照させるべきかという「データアーキテクチャ設計」を整理していきます。

DataverseとVirtual Table、どんな時に使うの？

ここで重要なのは、DataverseとVirtual Tableの機能比較ではなく、「ERP（FO / Business Central）を中心にしたデータの置き場所の話」です。

もう少し、DataverseとVirtual Tableについて情報を整理しておきますね。

データフロー図

機能図

ERP（FO / BC）を中心に据え、Dataverseは業務データ、Virtual Tableは参照レイヤーとして分離することが設計の基本です。

ERPとDataverse / Power Platformを繋ぐ実例 10選

いかがでしょうか。製造現場の実績入力、フィールドサービスの修理報告、倉庫での棚卸、ECからの受注、営業のCRM連携—ERPと外の世界を繋ぐシーンは、実は身近なところにたくさんあります。そしてこれらのシーンを支えているのが、Dataverseの4つの連携メカニズムです。

BCとFOのDataverse連携：4つのメカニズム

MicrosoftのERP製品であるBusiness Central（BC）とFinance & Operations（FO）、どちらもDataverseと連携できますが、その仕組みは同じではありません。

まずBCから整理します。MS Learnの統合概要ページには、BCとDataverseの連携方式として4種類が明記されています。

BCとDataverseの連携には、BCとDataverse間でデータをレプリケートするData Synchronization、Business Central APIを経由したVirtual TablesによるData Virtualization（CRUD対応）、WebhookによるData Change Events（CUD）、Business Eventsの4種類があります。

Data Synchronization — データをDataverseにコピーする

Dataverseを通じて、あるDynamics 365アプリから別のアプリへ、一方向または双方向でnear-real timeにデータを同期することができます。たとえばBCとDynamics 365 Salesを連携させる場合、Sales側で受注を作成すると、BCに同期され、逆にBC側の在庫状況をSalesから確認することができます。

データはDataverse側に永続化されます。先ほどのユースケースでいえば、「①名刺→顧客マスタ」「②D365 CRM↔ERP」「⑩Power BI・Fabric分析」がこのアプローチです。

Virtual Tables — データはERPに置いたまま、Dataverseから操作する

「Virtual EntitiesはDataverse上に「テーブルの定義（窓口）」として登録されています。Power AppsやPower Automateからは通常のDataverseテーブルと同じように見えます。

BCの場合、Virtual TablesはBC側のAPI Pagesを通じて公開されたAPIを使用します。Dataverse側からはVirtual Tablesは通常のテーブルと同様に見えます。Dataverseにデータのコピーはつくられず、データはBC側で完全に管理され続けます。

*FOの場合、Virtual EntitiesはFO側のData Entitiesを通じて公開されたAPIを使用します。Dataverse側からはVirtual Entityは通常のテーブルと同様に見えます。Dataverseにデータのコピーはつくられず、データはFO側で完全に管理され続けます。

ERPがSingle Source of Truth（データの一元管理）のまま、Power AppsやPower AutomateからERP側のデータを操作することができるのです。

注意）CRUDの可否はERP側のエンティティ設計や公開方式に依存します。

Read:OK

Write（CUD）：プロバイダ依存

BCの場合は、API PageのInsertAllowed・ModifyAllowed・DeleteAllowedプロパティ設定に依存します。

*F&Oの場合は、Data EntityのアクセスレベルプロパティとODataの公開設定に依存します。

データの二重管理が発生しないのが最大のメリットで、「③ECからの受注（受注登録はAPI等、Virtual Tableは参照用途）」「④タイムシート」「⑤製造実績」「⑥修理実績」「⑦棚卸」がこのアプローチです。

Webhook（Data Change Events）— ERPのイベントをリアルタイムにキャッチする

ERPでデータが作成・更新・削除されたタイミングをWebhookで通知し、Power Automateのフローを起動します。

「⑧請求書確定→承認フロー自動起動」がこのアプローチです。

ERPの処理が完了した瞬間に外部システムを動かしたい場合に有効です。

Business Events — ERPのアクションをDataverseに伝播する

Business EventsはWebhookよりも「業務アクション」に近い粒度で、イベントを発火させる仕組みです。

「⑨在庫アラート→連鎖処理」のように、ERPのビジネスプロセスの結果をDataverseを介して、他のDynamics 365アプリやPower Appsに伝播できます。

では、FOは何が違うのか

Dual-writeはCustomer EngagementアプリとFOアプリ間のほぼリアルタイムな双方向連携を提供する「すぐに使えるインフラ（out-of-box）」です。

FOでのデータ変更はDataverseへの書き込みを引き起こし、Dataverseでの変更もFOへの書き込みを引き起こします。

BCのData Synchronizationに対応する仕組みがFOのDual-writeですが、自動・双方向・密結合という点でその性格が異なります。

そしてVirtual Entitiesについては、BCのVirtual Tablesと同様に、データをFO側に置いたままDataverseから操作できますが、技術的な経路が違います。

DataverseからFO Virtual Entitiesへの呼び出しは、Virtual Entities Plugin → CDSVirtualEntityService Web API → FOのData Entity→物理テーブルという経路を通ります。

すべての操作でFOのエンティティが直接呼び出されるため、そのエンティティや背後のテーブルのビジネスロジックを確実に実行できる構成になっています。

BCはAPI Pagesが直接の入口なのに対し、FOはData Entitiesという抽象レイヤーを経由します。FOのビジネスロジックが呼び出される設計になっているわけです。

もう一点、FOとDataverseの接続には重要な注意点があります。

FOとDataverseの接続は強く結合されるため、無効化（切断）や再構成には注意が必要です。

特にDual-writeを無効化・アンインストールした場合、Dataverse側のデータやマッピングが課題となる可能性があり、実運用では「戻す前提」での設計はお勧めできません。

BCとFOのDataverse連携の違い

整理すると、こうなります。

BCはメカニズムが4種類と明確に整理されており、用途に応じて選択できる柔軟な設計です。 Virtual TablesでSingle Source of Truth（唯一の情報源→データの一元管理）を守りながら、Power Platformと繋ぐか、Data Syncでデータをコピーしてより広いPower Platform活用を目指すか—それぞれの業務要件に合わせて使い分けができます。

一方、FOのDual-writeはエンタープライズ規模でのCEアプリとのシームレスな統合を前提とした密結合アーキテクチャです。 接続やデータ同期が強く結びつくため、無効化や再構成時にはデータやマッピングに影響が出る可能性があり、導入前に設計をしっかり固めることが求められます。

勘のいい方は、気付きましたね。そうです。そうなんです！

「データをDataverse側にコピーして持たせるべきか（同期）、それともERP側にあるデータをそのまま見に行くべきか（仮想テーブル）」

という判断基準を、お伝えしたかったのです。

＜Dataverseへの同期（Data Sync / Dual-write）を選ぶべきケース＞

データを使ってゴリゴリ分析・処理をしたい時：

Power BIで大量データを可視化したり、AI（Copilotや自律型エージェント）にデータを読み込ませて高度な推論をさせたりする場合は、Dataverse側にデータが「実体」として存在している方が圧倒的にパフォーマンスが良いです。

アプリの応答速度（UX）を最優先する時：

スマホアプリ（Power Apps）から瞬時にデータを呼び出したい場合、ERPのAPIを毎回叩くより、Dataverse内にある同期済みデータにアクセスする方がサクサク動きます。

＜仮想テーブル（Virtual Table / Entity）を選ぶべきケース＞

「今」のリアルタイム性が絶対条件の時：

在庫数や利用可能な与信枠など、1秒でもズレると業務に支障が出るデータは、コピーを持たずにERPを直接見に行くべきです。

データの二重管理・容量（ストレージコスト）を抑えたい時：

Dataverseのストレージ容量（Dataverse Capacity）は貴重。ERP側にある膨大な明細データをわざわざDataverseにコピーして格納するのはコストの無駄になります。

BCとFOの「裏側の仕組み」の違い、ここが肝

表でも少し触れましたが、Business Central（BC）とFinance & Operations（FO）では、仮想テーブルや同期の「信頼性」のレベルが違います。

＜FOのDual-writeとVirtual Entitiesは「エンタープライズ用途において非常に強力な構造」＞

FOは、仮想テーブル（Data Entity）を通した時でも、背後にある複雑な「ビジネスロジック（検証ルールや自動計算）」がしっかり走る仕組みになっています。Power AppsからFOのデータを操作した場合でも、すべての操作でFOのエンティティが直接呼び出されるため、そのエンティティや背後のテーブルのビジネスロジックを確実に実行できる構成になっています。これにより、トランザクション整合性が保たれるように設計されています。ただし、設計や使い方次第では、パフォーマンスやデータ整合性に影響が出るため、その点には注意が必要です。

＜BCのVirtual Tablesは「設定次第」＞

BCの場合は、API Pageという仕組みを経由します。これの InsertAllowed などのプロパティ設定や、背後のAL言語のコードの書き方次第で動きが変わるため、「ただ繋げばいい」わけではなく、開発者・アーキテクトが意図を持って設計しないと予期せぬ挙動になるリスクがあります。

「BCとFOは同じMicrosoft ERPファミリーでも、Dataverse連携の設計思想は別物」—これがエンジニア・アーキテクトとして押さえておくべき重要なポイントです。

2026年現在、ERPの世界にも「AIエージェント（Sales Agent・Payable Agent・Expense Agentなど）」がどんどん組み込まれてきています。AIやPower Appsを賢く動かすためには、「どのデータをDataverseに置いてAIに食わせ、どのデータをERPの中に安全に閉じ込めておくか」という『データの配置・パスの設計』が、DXプロジェクトの成否を分けるということです。

「とりあえず繋がるから仮想テーブルで」とか「なんとなく全部同期で」という安易な設計ではなく、業務要件（リアルタイム性、コスト、AI活用、UX）から逆算して、4つのアプローチをプロとして「意図的に使い分けて欲しい」という、メッセージが込めました。

最後に｜室長からひと言

いかがでしたでしょうか。

ERPとDataverse、そしてVirtual Tableの連携は、単なる技術的な接続の話ではありません。どこにデータを置き、どこから参照し、どこで確定させるのか。その一つひとつの設計が、業務全体の流れを左右します。

社内の勉強会やプロジェクトのキックオフなどで、このテーマを共有される際は、「AI活用を見据えたデータの置き場所の最適化」という文脈で伝えると、皆さまのチームにもかなり刺さるのではないかと思います。

ラグビーにおいて、ボールを後ろへつなぎ続けることでチャンスが生まれるように、システムにおいても、データを“正しくつなぎ続ける”ことでしか、本当の価値にはたどり着けません。そして、一度のノックフォワードが流れを止めてしまうように、わずかな設計の誤りが、データの流れを断ち、全体の価値を失わせてしまうことがあります。だからこそ重要なのは、「何を信用し、どこを信じるのか」を明確にすることです。

ERPが持つべきデータはERPに任せる。Dataverseが展開すべきデータはDataverseに任せる。その信頼関係を崩さずにつなぐことが、システム全体の力になります。

その上で、もう一つ大切な視点があります。データを“持たない”という選択も、設計です。

Virtual Tableは、その思想を最も純粋な形で示しています。データをコピーせず、移動させることもなく、「そこにあるものをそのまま信じて使う」という選択です。

まさに、「信は力なり」です。

この“信頼の設計”と、それを実現するアーキテクチャこそが、これからのDynamics 365とPower Platformを扱う上で、最も重要なポイントになるはずです。

今日の記事が、皆さんのデータ設計における“次のパス”につながれば嬉しいです。

それでは、また次回。Let’s Enjoy our DX365Life! 🚀