マスタデータガバナンス：アーキテクチャと利用

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 12, 2026 · 25 min read

本記事の位置づけ#

参考資料#

1) マスタデータガバナンスのランドスケープ#

SAP Master Data Governanceは、マスタデータライフサイクルの異なるフェーズに対応する個別の機能を組み合わせています。特定の要件にどの機能が該当するかを理解することで、スコープの誤設定を防ぐことができます。

これらの機能は、独立して動作するのではなく、ガバナンスパイプライン内で連携して機能します。互いに代替するものではありません。

2) S/4HANA への接続方法#

MDGはSAP S/4HANAに組み込まれており、後付けの独立したSaaSサービスではありません。すべての導入において、S/4HANAシステムがMDGプラットフォームとして機能し、専用（ハブ）またはトランザクション業務と併用（共同導入）のいずれかの形態をとります。

                    ┌─────────────────────────────────────┐
                    │        MDG Hub (S/4HANA)            │
                    │                                     │
  Source Systems ──►│  Consolidation  ──►  Central Gov.  │
  (ECC, legacy)     │  (dedup, match)     (CR workflow)   │
                    │                         │           │
                    │                    Activation &     │
                    │                    Staging Area     │
                    │                         │           │
                    └─────────────────────────┼───────────┘
                                              │
                            ┌─────────────────▼──────────────────────┐
                            │    Data Replication Framework (DRF)    │
                            │   IDocs / SOA / RFC / File             │
                            └─────┬──────────┬──────────┬────────────┘
                                  │          │          │
                         ┌────────▼──┐  ┌────▼────┐  ┌─▼──────────┐
                         │ S/4HANA   │  │ Legacy  │  │ Non-SAP    │
                         │ (client)  │  │ SAP ECC │  │ via MDI /  │
                         └───────────┘  └─────────┘  │ Event Mesh │
                                                      └────────────┘

クラウドシナリオでは、BTP上のSAP Master Data Integration (MDI) がMDGとクラウド基幹業務アプリケーションの間に位置し、SAP One Domain Modelを使用してインテリジェントスイート全体のデータを標準化します。SAP Cloud Integration (CPI) は、レガシーシステムや非SAPシステムとの接続をミドルウェアとして処理します。

重要なポイント: DRF は、すべてのMDG導入における配信基盤です。MDG-F（フレックスモード）を使用する共同導入シナリオでも、データを消費プロセスに配信するためにDRF設定が必要です。

3) 成熟度マップ#

クラウド対応モードは、 SAP S/4HANA 2023で導入され、クリーンコアの原則に従っています。従来のモードは、以前のリリースのすべてのドメインで引き続き利用可能です。

4) 要件チェックリスト#

MDG統合と中央ガバナンスのドキュメントでは、以下のすべてのチェックリストがスコープ設定のために設計された変更要求モデルについて説明しています。

デプロイメントモデルの前提条件#

データドメインとスコープの前提条件#

ワークフローとガバナンスプロセスの前提条件#

統合および配布の前提条件#

データ品質管理の前提条件#

5) 意思決定基準#

最初に問うべき3つの質問#

Q1. このプロジェクトを推進している、具体的で測定可能なマスタデータの問題は何ですか？

MDGの導入において、具体的な問題定義がないまま進めると、初期の設計ワークショップ後に勢いを失うことがよくあります。導入モデルを選択する前に、プロジェクトスポンサーは問題点を測定可能な形で明確に示す必要があります。例えば、重複レコードの数、月間の統合失敗件数、監査結果、データ関連の転記エラーなどです。「データ品質が全般的に低い」という回答は、調査結果であってプロジェクトのスコープではありません。

Q2. マスタデータの所有者は誰で、現在どこに存在していますか？

MDGはデータの所有権を置き換えるものではなく、それを正式化し、強制するものです。組織が各ドメインのマスターレコードとなるシステムについて合意していなければ、どのようなワークフロー設定も根本的な政治的問題を解決することはできません。データ所在地要件（GDPR、各国の規制）も、BTP上のMDG Cloud Editionが許可されるか、オンプレミス展開が必須となるかに影響を与えます。

Q3. データを所有する事業部門に対して、予算権限と組織権限を持つ指名されたスポンサーは存在しますか？

MDGは複数の事業部門にまたがります。財務部門はG/L勘定を、調達部門はベンダーデータを、営業部門は顧客データをそれぞれ管理します。各ドメインから指名されたデータ所有者と承認者をコミットできる部門横断的なスポンサーがいない導入プロジェクトは、ワークフロー設計の段階で停滞します。

プロジェクトコンテキストによるドメイン選択#

MDG S/4HANA FAQ によると、推奨される開始点は組織の状況によって異なります。

ライセンスとコスト#

注意：ハブと共同デプロイメントインフラストラクチャの詳細な価格設定は、SAPによって公開文書化されていません。具体的なコストモデリングについては、SAPライセンスチームまたはSAPパートナーにご相談ください。

6) よくある障害#

以下の障害は、要件段階で文書化されたパターンであり、実装上のバグではありません。追加の統合およびスコープ設定のガイダンスについては、 S/4HANA FAQのMDGを参照してください。

障害 1: スコープの前提 — MDGをデータ移行ツールとして扱う

MDGの統合機能は重複排除と最適レコードの選択を処理するため、データ移行フェーズで有用です。MDGを単なる移行ツールとして扱うプロジェクトでは、継続的な価値を提供する中央ガバナンス層と配信層のスコープ設定に失敗します。MDGを設定し、移行を完了した後、MDGは実質的に放棄されます。移行後の運用に対するビジネスケースが確立されていないため、ガバナンスワークフローが本稼働することはありません。常にMDGを初期ロードだけでなく、定常状態のガバナンス向けにスコープ設定してください。

障害 2：ワークフロー設計開始前にデータオーナーが確定していない

変更要求ワークフローには、指名された承認者が必要です。ワークショップの参加者は、誰が何を承認すべきかについて概念的に合意することがよくありますが、事業部門の管理者からの明示的なコミットメントがない場合、ワークフローの設計には、実際には割り当てられることのないプレースホルダーのロールが含まれます。これは、承認ステップに割り当て者がおらず、変更要求が停滞するテスト中に表面化します。BRFplusワークフロー設定を開始する前に、指名されたデータ所有者とそのバックアップ体制を文書で確認してください。

障害 3: ワークフロー設計における例外処理の欠落

BRFplusワークフローは、ハッピーパス（標準変更リクエストの作成と承認）向けに設定されています。却下パス、エスカレーションタイマー、不完全な提出の処理は、定期的にスキップされています。本番環境では、エスカレーションパスがない却下された変更リクエストがキューに無期限に滞留し、マスタデータ配信をブロックします。すべてのワークフローは、本番稼働前に、却下、タイムアウト、エスカレーションの各ブランチを明示的に設計する必要があります。

障害4: DRF設定範囲の過小評価

プロジェクトではMDGハブと主要な受信システムを特定するものの、追加のターゲット（レポートシステム、アーカイブされたレガシーECCインスタンス、サードパーティミドルウェア）を見落としています。DRFでは、フィールドマッピングやエラーハンドリングを含む、ターゲットごとに個別のレプリケーション設定が必要です。要件定義ではなく統合テスト中に追加のターゲットシステムを発見すると、タイムラインが延長され、レプリケーション設計のやり直しが必要になります。DRF設計を開始する前に、完全なシステムランドスケープインベントリを実行してください。

障害 5: データガバナンスの遅延 — 品質ルールの定義が遅すぎる

BRFplusのデータ品質ルールには、ビジネス側からの具体的な定義が必要です。有効な住所とは何か、どのビジネスパートナー役割に対してどの項目が必須か、財務勘定属性の許容範囲などです。これらの定義はデータチームが代わりに決めることはできず、ビジネスからのインプットに依存します。品質ルールの定義をシステム設定後に行うと、稼働開始日が遅延するか、実際のガバナンスを適用しない仮のチェックでシステムが稼働することになります。品質ルールのワークショップは、技術設計と並行して開始し、その後に行うのではありません。

障害6：クラシックモードとクラウド対応モードの共存管理の不備

S/4HANA 2023 にアップグレードし、ビジネスパートナーにはクラウド対応モードを採用しつつ、他のドメインではクラシックモードを維持する組織は、2 つの並行したガバナンス設定を維持する必要があります。この共存はサポートされていますが、明確なカットオーバー基準を伴う明確な移行計画が必要です。クラシックからクラウド対応への移行境界を文書化せずにクラウド対応モードの採用を開始したプロジェクトでは、ガバナンス動作に一貫性が生じず、一部のレコードはクラウド対応ワークフローで管理され、他のレコードはクラシックモードでルーティングされ続けることになります。

障害7: MDI統合アーキテクチャが本番稼働後までスコープ化されていない

組織がオンプレミスのMDGとSAPクラウドLoBアプリケーション（SuccessFactors、Ariba、フィールドサービス）の両方を運用する場合、BTP上のMDIがこれらのシステム間でマスタデータを同期するための統合ハブとなります。DRFのみのレプリケーションで本番稼働し、MDIアーキテクチャを設計しなかったプロジェクトは、後になってクラウドLoBアプリケーションがアドホックなポイントツーポイント接続でマスタデータを受信しているか、まったく受信していないことに気づきます。実装が段階的であっても、要件定義時にMDIのスコープを評価する必要があります。

FAQ#

Q: MDGはSAP S/4HANA Cloud（パブリッククラウド）で動作しますか、それともS/4HANAオンプレミスでのみ動作しますか？

MDG クラシックモードとクラウド対応モードは、SAP S/4HANA オンプレミスおよび SAP S/4HANA Private Cloud Edition で利用可能です。これらは SAP S/4HANA Cloud（パブリッククラウド / マルチテナント）では利用できません。S/4HANA パブリッククラウドをご利用の組織には、 SAP Master Data Governance Cloud Edition（BTP ABAP 環境上の SaaS）が該当するオプションであり、現在はビジネスパートナー領域に限定されています。

Q: MDGにはどのようなライセンスが必要ですか。また、標準のS/4HANA契約に含まれていますか。

MDG on SAP S/4HANA は、通常、ほとんどのパッケージにおいて標準ドメイン向けに S/4HANA ライセンスに含まれていますが、正確な権利は特定のエディションおよび契約に依存します。MDG Cloud Edition には別途 SaaS サブスクリプションが必要です。BTP 上の SAP Master Data Integration (MDI) は別のサービスです。スコープ設定の前に、必ず SAP 担当営業責任者に権利を確認してください — 明示的な確認なしに MDG が含まれていると想定しないでください。

Q: プロジェクトからMDGをスコープ外とするのはどのような場合ですか？

MDGは、組織がゴーライブ後にガバナンスワークフローを運用するための指名されたデータオーナーや承認者を確約できない場合、対象範囲から除外すべきです。確約された人的ガバナンスがなければ、MDGは誰も処理しない高額な変更要求キューと化します。また、マスタデータドメインがサードパーティシステムによって完全に管理されており、一元化されたS/4HANAガバナンスが不要な場合や、正式なデータガバナンスを実践する組織の成熟度がまだ整っていない場合も、対象範囲から除外すべきです。

Q: ハブデプロイメントと共同デプロイメントの違いは何ですか？また、どのように選択すればよいですか？

ハブデプロイメントは、MDGプロセスのみを実行する専用のSAP S/4HANAインスタンスをプロビジョニングします。これにより、ガバナンスとトランザクション業務を明確に分離し、大規模なマルチシステム環境をサポートします。共同デプロイメントは、既存のS/4HANAトランザクションインスタンス上でMDGを有効化し、別システムを不要にするとともに、システム間のレプリケーション遅延を排除します。組織が単一のS/4HANAインスタンスに標準化する場合は共同デプロイメントが推奨され、ガバナンスを特定のトランザクションシステムから独立させる必要がある複雑なマルチシステム環境ではハブデプロイメントが推奨されます。

Q: MDG要件はビジネスケースやスコープ文書にどのように文書化すべきですか？

MDG要件には以下を文書化する必要があります：(a) 対象となる特定のマスタデータドメイン、(b) 測定可能な現状メトリクスとして表現されたガバナンス上の課題、(c) 指名されたデータオーナーとその組織上の役職、(d) DRF を介してガバナンスされたマスタデータを受信するターゲットシステム、および (e) 選定された導入モデルとその根拠。「マスタデータ品質のためにMDGを導入する」とだけ記載されたスコープ文書では、設計ワークショップを開始するための具体性が不足しています。

Q: MDGは、クラシックモードとクラウドレディモードを同時に共存させることができますか？

はい、SAP S/4HANA 2023では、クラシックモードとクラウドレディモードの共存がサポートされています。ビジネスパートナーにクラウドレディモードを採用する組織は、製品および財務ドメインではクラシックモードを引き続き同時に運用できます。この共存には、変更要求を正しいモードにルーティングするための明示的な設定が必要であり、移行計画にはクラシックモードの設定をいつ廃止するかを文書化する必要があります。

Q: フェデレーションマスタデータガバナンスは、集中型MDGハブガバナンスとどのように異なりますか？

集中型ハブガバナンスでは、単一のMDGインスタンスが信頼できるマスタとなり、すべての変更リクエストはそのインスタンスを通じて配信される前に処理されます。 連携型ガバナンス（S/4HANA 2023以降で利用可能）では、データの所有権が分散されます。コアデータ所有者はコア属性（名前、住所、識別子）を管理し、アプリケーションデータ所有者はアプリケーション固有の属性を個別に管理します。コアデータ所有者がプロセスを調整し、最終状態を配信します。連携型ガバナンスは、異なる事業部門が正当に異なる属性セットを所有する大企業に適しています。

概要#

SAP Master Data Governanceは、マスタデータ管理を単なる目標から運用プロセスへと変えるために必要なワークフロー、品質、および配信インフラストラクチャを提供します。アーキテクチャの選択肢（ハブ型と共同デプロイ型、クラシックモードとクラウド対応モード、集中型と連邦型ガバナンス）は、要件として明確にすべき組織、ランドスケープ、およびロードマップ上の制約を反映しています。

MDG導入における最も危険な前提は、テクノロジーがガバナンスの問題を解決するというものです。MDGは、人間が定義し、コミットしなければならないガバナンスを運用可能にします。単一のワークフローを設定する前に、プロジェクトには指名されたデータオーナー、定義された変更プロセス、スコープされたドメイン、そして配信データを受け取るシステムの完全なインベントリが必要です。 SAP MDG製品ドキュメントには機能の詳細が記載されていますが、設計前にこれら4つの組織的インプットを整えることが、コンサルタントがMDGエンゲージメントで実行できる最も価値の高い活動です。

次に読むべきもの#