Dynamics 365 デュアルライト テーブルマップとデータ所有権ルール

By Mirko Peters · 2026-08-22

Dynamics 365 のデュアルライト テーブルマップの構成方法、データ所有権の境界の設定方法、そして一方向と双方向の同期ルールの管理方法を解説します。

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

Dynamics 365 のデュアルライトを使いこなすには、明確なデータ所有権ルールを確立し、Finance and Operations と Microsoft Dataverse の間でテーブルマップを正しく構成することが必要です。本ガイドでは、データのずれを防ぐ方法、システム オブ レコードの境界の決め方、そして共有ビジネス エンティティに対する一方向と双方向の同期フローの管理方法を解説します。

重要なポイント

• テーブルマップは、Finance and Operations と Dataverse の間で特定のテーブルとフィールドを結び付ける「変換表」の役割を果たします。
• 競合する更新によって有効な業務レコードが上書きされないよう、データ所有権は厳密に定義する必要があります。
• 製品は、運用部門がマスターカタログを管理し、販売部門がそれを利用する一方向の同期モデルが適していることが多いです。
• 顧客、住所、連絡先は、部門間でほぼリアルタイムに更新できるよう、通常は双方向同期を利用します。
• 初回の同期では、重複レコードや古いレコードが接続先の環境に伝播しないよう、データを慎重にクリーンアップする必要があります。

デュアルライトにおけるテーブルマップの仕組み

Dynamics 365 Finance and Operations のアプリと Microsoft Dataverse をデュアルライトで接続する場合、システムはすべてのデータを自動的に同期するわけではありません。代わりに、テーブルマップと呼ばれる構造化された接続を利用します。テーブルマップは、バックオフィス環境のどのテーブルが Dataverse の特定のテーブルに対応するかを統合エンジンに伝え、名前、電話番号、住所行などのフィールドを変換します。

こうした明示的な変換表がなければ、アプリケーションごとにラベルが食い違ったり、重要な業務情報が別々の場所に保存されたりする可能性があります。テーブルマップは、データがどのように移動するかについて厳格なルールを定めることで、手作業による解釈の必要をなくします。ただし、マップを構成するのは最初の一歩にすぎません。管理者は、個々のデータ項目について最終的な権限をどのアプリケーションが持つのかについても、厳密なガバナンスを確立する必要があります。

フィールド レベルのマッピングと変換

すべてのテーブルマップは、データの流れを規定する対になった列で構成されます。顧客に面したアプリケーション側でユーザーがフィールドを変更すると、デュアルライト エンジンはマップの定義を評価し、バックオフィス データベース内の対応するフィールドを特定します。同期の健全性を保ち、エラー キューの発生を防ぐためには、これらのフィールド間でデータ型の互換性と書式ルールを確実に揃えることが重要です。

データ所有権の境界を厳密に定める

デュアルライトの同期を有効にする前に、組織は次の3つの基本的な問いに答えなければなりません。このレコードはどこで作成されたのか。誰が編集する権限を持つのか。競合が発生した場合、どのシステムの内容が優先されるのか。データ所有権が明確でなければ、ほぼリアルタイムの統合は、Microsoft 365 のビジネス エコシステム全体に誤りを広げる仕組みになりかねません。

営業チームと経理チームの両方が、顧客の請求プロファイルを変更する権限を持っているケースを考えてみてください。営業担当者が Dynamics 365 Sales で電話番号を更新し、同時に経理担当者が Finance and Operations で与信限度額を変更した場合、調整されていない更新によってデータが破損したり、予期しない上書きが発生したりする可能性があります。所有権モデルを定義しておくことで、こうした摩擦を防げます。

部門別の所有権モデル

一般的なエンタープライズのデータガバナンス構造では、部門ごとに所有権を論理的に分けるのが一般的です。

• 営業と CRM: 顧客との関係に関する詳細情報、主要な連絡先、リード、パイプラインのメモを管理します。
• 財務: 法人、請求条件、税務の参照データ、請求書の構成を管理します。
• 運用とサプライ チェーン: 製品マスター、在庫単位、倉庫の場所、フルフィルメントのパラメーターを管理します。

一方向と双方向の同期戦略

dual-write に関してよくある誤解は、構成されたすべてのマップが双方向に動作しなければならないというものです。このフレームワークは双方向のデータフローに対応していますが、多くのビジネス エンティティは厳密な一方向の同期から大きなメリットを得られます。

製品情報は、一方向のマッピングが適している典型的な例です。運用チームは、Finance and Operations 内で在庫単位、寸法、運用上の制約を設定しながら、新製品の作成を管理します。製品の市場投入準備が整うと、dual-write によってそれらの詳細が Dataverse に送信されます。営業ユーザーは、基になる製品マスターを変更する権限がなくても、顧客とのやり取りでそれらの商品を選択して見積もりに含めることができます。

一方、顧客レコードや住所は、双方向の同期モデルを必要とすることが多くあります。フロントオフィスの担当者とバックオフィスの経理担当者の双方が、アクティブな取引中に連絡先情報を維持・更新する正当な理由があるためです。

エラー ログの監視と同期の中断への対処

dual-write は通常の日常業務中に更新を同期的に処理し、顧客対応チームとバックオフィスの担当者が同一の情報に基づいて作業できるようにします。更新がしきい値を越えられなかった場合、システムは不整合を遅延バッチ ジョブの裏に隠すのではなく、即座にアラートを生成します。

管理者は、変換の失敗、必須フィールドの欠落、検証ルール違反を特定するために、統合アクティビティとエラー ログを積極的に監視する必要があります。一時停止と追いつき処理などの機能により、技術チームは保守作業時間帯を安全に実行し、受信した変更を一時的にキューに入れ、後続の業務プロセスを壊さずにバックログ データを再処理できます。

まとめ

dual-write を成功させるには、技術的な構成だけでなく、データ ガバナンス、テーブル マップの設計、所有権の境界について深い合意形成が必要です。顧客向けアプリと業務システムの間で情報がどのように流れるかについて明確なルールを定めることで、手作業によるデータ入力をなくし、信頼できるインサイトを従業員に提供できます。

クラウド アーキテクチャの計画や Microsoft エコシステムの効率化に関するより幅広い議論については、エピソード全編を聴いて、最新の IT 管理者およびクラウド アーキテクトのための専門的な戦略をご覧ください。

よくある質問

dual-write のテーブル マップとは何ですか?

テーブル マップとは、dual-write エンジンに対して、Finance and Operations のどのテーブルとフィールドが Microsoft Dataverse の対応するテーブルとフィールドに対応するかを指定する、事前定義された接続ルールです。

すべての dual-write マップを双方向同期に設定する必要がありますか?

いいえ。双方向同期は顧客のような共有エンティティにはうまく機能しますが、製品や在庫マスターのような多くのレコードは、運用チームが厳格に管理する一方向の同期から大きなメリットを得られます。

dual-write はアプリ間の競合する編集をどのように処理しますか?

dual-write は、事前に定められたデータ所有権のルールに依存します。組織は、自動化が実行される前に競合を解決するため、特定のフィールドについてどのシステムを主要なシステム オブ レコードとするかを定義しておく必要があります。

ライブ運用中に dual-write の同期が失敗した場合はどうなりますか?

dual-write は、日常の業務タスクの更新を同期的に処理します。更新が失敗した場合、遅延バッチ キューに隠れたままにするのではなく、管理者の対応のためにアクティビティとエラー ログに即座に表示されます。