Dataverse標準テーブルと仮想テーブル: データのコピーをやめるタイミング

By Mirko Peters · 2026-08-22

Dataverse標準テーブルと仮想テーブルを比較します。エンタープライズデータのコピーをやめ、外部システムへのライブな窓を実装すべきタイミングを解説します。

Automatically translated with AI from the original post. Read the English original

Dataverse標準テーブルと仮想テーブルのどちらを選ぶかによって、外部データをどれだけ効率よく業務で扱えるかが決まります。標準テーブルはレコードを Dataverse 内に直接保存しますが、仮想テーブルは外部の ERP、倉庫管理、財務システムへのライブな窓を作ります。これにより、リスクの高い夜間の同期ジョブや古い情報をなくすことができます。

重要なポイント

• 標準の Dataverse テーブルはレコードをローカルに恒久的に保存します。一方、仮想テーブルは外部ソースからオンデマンドで取得したライブのレコードを表示します。
• 仮想テーブルを使えば、夜間の同期ジョブが不要になります。同期ジョブがあると、営業チームが古い在庫数に基づいて判断してしまうおそれがあります。
• アーキテクチャの選択では、中核となる業務プロセスとレコードのライフサイクル管理が本来どこにあるべきかを最優先に考えるべきです。
• 外部データへの依存があるため、仮想テーブルではパフォーマンス、セキュリティのアクセス許可、フィルター機能の動作が標準テーブルとは異なります。
• Dynamics 365 を通じてユーザーを権威ある外部アプリケーションに直接接続すれば、ストレージの負荷とデータの重複を減らすことができます。

アーキテクチャ上のジレンマ: ストレージかアクセスか

Microsoft Dynamics 365 やカスタムの Power Apps を実装する際、アーキテクトは常に根本的な設計上の問いに直面します。外部データを Dataverse にコピーすべきか、それともネイティブのシステムに残してブリッジを構築すべきか、という問いです。長年、既定の答えはレプリケーションでした。製品カタログ、在庫残高、請求履歴を Dataverse に直接取り込み、ユーザーがすべてを一箇所で扱えるように、夜間の連携処理をスケジュールしてきたのです。

しかし、このレプリケーション戦略には深刻なアーキテクチャ上の負担があります。ストレージの上限にすぐ達し、データベースは急速に肥大化します。そして何より、データの鮮度が落ちることで業務上のリスクが生まれます。倉庫作業員が昼休みに重要な品目を 10 個出荷しても、レプリケートされたテーブルは次の定期バッチ同期が実行されるまで、その 10 個を在庫として表示し続けます。その結果、営業担当者は在庫のない商品を顧客に見積もってしまい、顧客の不満を招き、注文のキャンセルや信頼の低下につながります。標準テーブルは格納するデータを完全に自分で管理することを前提としているため、専門的なエンタープライズシステムが管理する、変化の速い業務指標には不向きです。

標準テーブルと仮想テーブルの比較

標準の Dataverse テーブルと仮想テーブルの運用上の違いを理解すると、それぞれのアーキテクチャをいつ採用すべきかが明確になります。この違いは技術的な意味合いにとどまらず、システムの所有権、ユーザーの作業フロー、保守の負担を決めるものです。

標準 Dataverse テーブル

取引先企業、連絡先、商談などの標準テーブルは、Dataverse エコシステムにネイティブに属するものです。Dataverse はデータベーステーブルを作成し、物理ストレージを管理し、テーブルレベルのセキュリティモデルを適用し、レコードに対してビジネスロジック、プラグイン、ワークフローをネイティブに実行します。ユーザーがレコードを作成または更新すると、Dataverse が最終的な権威となります。アプリケーション層とストレージ層は完全に統合されています。

仮想テーブル

仮想テーブルは、ライブラリのカタログや安全なビデオ フィードに近い動作をします。Dataverse はスキーマ、列の定義、メタデータを保持し、モデル駆動型アプリ内で使い慣れたユーザー インターフェイスを表示できるようにします。ただし、実際のレコードは保存しません。ユーザーがビューを開いたりフィルターを適用したりすると、Dataverse は要求を変換し、データ プロバイダーを介して外部システムに問い合わせ、ライブの応答をその場で表示します。レコードのライフサイクルにおける唯一の正は、外部アプリケーションのままです。

運用上のトレードオフと制限の評価

仮想テーブルは同期の悩みを解決しますが、開発者と管理者が慎重に評価すべき固有の制約も生じます。基になるデータは Dataverse に存在しないため、標準のテーブルと同じようには動作しないプラットフォーム機能があります。

Advanced Find、複雑なサーバー側プラグイン、ロールアップ フィールド、バックグラウンドの非同期ワークフローは、データがローカルに永続化されることを前提としていると、予測しない動作をしたり、完全に失敗したりする可能性があります。さらに、パフォーマンスは外部 API やデータ ソースの状態と応答性に直接依存します。外部の ERP や倉庫管理アプリケーションで遅延が発生したり、オフラインになったりすると、Dynamics 365 の対応する仮想テーブルは停止するか、接続エラーをスローします。

セキュリティのモデリングにも慎重な計画が必要です。Dataverse のセキュリティ ロールでは、仮想テーブルの定義を表示または編集できるユーザーを制御できます。一方、ユーザーが許可されたレコードだけにアクセスできるようにするには、行レベルのセキュリティを外部 API 側で、またはカスタム データ プロバイダーを通じて適用する必要があることが多くあります。

まとめ

標準の Dataverse テーブルと仮想テーブルのどちらを選ぶかは、最終的にデータのライフサイクルを誰が所有しているか、そして、ユーザーに永続的なローカル ストレージが必要か、それとも単純なコンテキスト上の参照で十分かによって決まります。外部データ ソースを複製するのではなく適切にマッピングすることで、組織は重複したデータベース テーブルで Dataverse を乱雑にすることなく、Dynamics 365 でクリーンで一元的な作業環境を維持できます。この統合アプローチの基本的な構成要素を詳しく知るには、エピソード全編を聴いて、クラウドに関する実践的な情報をさらに知るために、ポッドキャストを購読してください。

よくある質問

仮想テーブルは Dataverse のストレージ容量を消費しますか?

いいえ。仮想テーブルは Dataverse 内にテーブル定義、メタデータ、スキーマのみを保存し、実際のレコードは外部システムに保持されるため、組織の Dataverse データベースのストレージ容量を消費しません。

仮想テーブルで表示されたレコードをユーザーが編集できますか?

はい。基になるデータ プロバイダーと外部システムが書き込み操作をサポートしている場合に限ります。組み込みの OData v4 プロバイダーや Finance and Operations の統合では、作成、更新、削除の操作がサポートされますが、外部システムは独自の検証ルールを引き続き適用します。

外部データ ソースがオフラインになるとどうなりますか?

外部アプリケーションまたはその API が利用できなくなると、Dynamics 365 内で仮想テーブルを表示しているユーザーには読み込みエラーが表示されるか、空のグリッドが表示されます。リアルタイムのクエリで外部レコードを取得できないためです。

仮想テーブルと virtual entities は同じものですか?

はい。virtual entities は、古い Microsoft のドキュメントや構成で使われていた旧称であり、virtual tables が現在の正式な用語です。基盤となるアーキテクチャと概念は同一です。