---
title: "マスターデータ管理（MDM）とは？4つの実装方式と導入を見送る条件を解説"
url: "https://www.issoh.co.jp/column/details/19536/"
published: 2026-11-10
updated: 2026-11-10
categories: ["DX"]
publisher: "株式会社一創"
---

# マスターデータ管理（MDM）とは？4つの実装方式と導入を見送る条件を解説

取引先の社名が販売管理と会計で食い違い、請求の前に毎月確認の電話を入れている。マスターデータ管理（MDM：Master Data Management）は、こうしたずれを都度の修正で終わらせず、顧客・商品・取引先の基準データを一つの正として保つ取り組みです。この記事では、ゴールデンレコードの作り方、4つの実装方式の違い、名寄せと項目ごとの優先順位の決め方を整理しました。マスタそのものの意味ではなく、複数システムをまたいだ管理の進め方と、専用ツールを入れない判断までを扱います。

## まとめ：マスターデータ管理は製品選びより正の置き場所と変更の責任を先に決める

マスターデータ管理で最初に決めるのは製品ではありません。どのデータをどのシステムの値で正とするのか、誰が変更を認めるのかです。ここが曖昧なまま製品を入れても、統合したレコードの値に誰も責任を持てず、現場は元の台帳へ戻ります。

実装方式は、既存システムの改修が小さいレジストリ型や統合型から始め、登録の入口を変える共存型や集中管理型へは効果を確かめてから進むのが安全な順序です。対象は取引先か商品のどちらか一領域に絞ります。

対象が2〜3システムで、マスタの追加が月に数件なら、専用ツールは要りません。共有マスタのテーブル設計と入力制約の見直しで足ります。5システムを超える、あるいは新規登録が月に数百件ある組織は、登録時点で正を参照させる仕組みへの投資が見合います。

## マスターデータ管理（MDM）の定義と複数システムの基準データをそろえる範囲

### マスタの修正作業とマスターデータ管理を分ける複数システムをまたぐ範囲

SAPはマスターデータ管理を、[システム全体の重要なビジネスデータから信頼できる単一のビューを作成して管理する取り組み](https://www.sap.com/japan/resources/what-is-mdm)と説明しています。対象の代表は顧客、製品、サプライヤー、品目、資産です。

1つのシステムの中で重複を消す作業は、データの修正にとどまります。マスターデータ管理と呼べるのは、販売管理・会計・CRMのように別々の台帳を持つシステムの間で、同じ取引先を同じものとして扱える状態を維持するところまでです。一度そろえて終わりにはならず、登録と変更の経路まで管理の対象に入ります。

マスタとトランザクションの違いや、マスタの種類、コード設計の基本は[マスタ（マスターデータ）とは？トランザクションデータとの違いと管理・MDMの進め方](https://www.issoh.co.jp/column/details/11085/)で解説しています。

### ゴールデンレコードを作り配信するまでの収集から監視までの6段階の流れ

各システムの情報を結合してできる、必要な項目を備えた単一のレコードをゴールデンレコードと呼びます。[IBMも複数の情報源を統合した単一の参照先として説明](https://www.ibm.com/think/topics/master-data-management)しており、MDMの成果物そのものです。SAPの解説では、次の順でライフサイクルが回ります。

1. 収集：ERPやCRMなど関連システムからデータを集める
2. 標準化：形式、定義、業務ルールを統一する
3. 突合と統合：同一の実体を特定して一つにまとめる
4. 承認：変更内容をワークフローで確認する
5. 公開：業務システムや分析基盤へ配信する
6. 監視：品質と利用状況を追い続ける

手間が集中するのは3番目と4番目です。ツールが候補を出せても、同じ会社かどうかの最終判断と、どの値を残すかの合意は人の仕事として残ります。

### データガバナンス・データ統合・CDP・PIMとMDMの守備範囲を比べる対応表

似た言葉が並ぶと、稟議の段階で目的がぼやけます。違いは対象の範囲と、誰の業務を支えるかで切り分けられます。

| 取り組み     | 主な対象          | MDMとの関係     |
| -------- | ------------- | ----------- |
| データガバナンス | データ全般のルールと責任  | ルールを定める側    |
| MDM      | 顧客・商品などの基準データ | ルールを日々運用する側 |
| データ統合    | 連携・分析用のデータ全般  | 基盤の作り方を扱う   |
| CDP      | 顧客の属性と行動の履歴   | 施策への利用が中心   |
| PIM      | 商品の説明文・画像・仕様  | 販売情報の管理が中心  |

ETLや仮想統合といった基盤の方式を比べたい場合は[データ統合とは？種類・方式の違いと名寄せの壁から導入判断まで解説](https://www.issoh.co.jp/column/details/18977/)が参考になります。顧客データに限った話なら、CDPの要否まで踏み込んだ[顧客データ統合の進め方｜名寄せのキー設計とCDPを入れずに済む条件](https://www.issoh.co.jp/column/details/18983/)のほうが近いはずです。

## 4つの実装方式を既存システムの改修量と正の置き場所で比較する選定手順

### レジストリ・統合・共存・集中管理の4方式の違いと改修量を比べる一覧表

方式の差は、正のデータをどこに置き、既存の登録画面をどこまで変えるかに表れます。[SAPが整理する4つの実装スタイル](https://www.sap.com/japan/resources/what-is-mdm)を、改修の視点で並べました。

| 方式     | 正の置き場所      | 登録経路の改修     | 向く場面         |
| ------ | ----------- | ----------- | ------------ |
| レジストリ型 | 各システムのまま    | ほぼ不要        | 重複の実態をまず知りたい |
| 統合型    | 中央の複製（分析用）  | 不要          | 集計の数字をそろえたい  |
| 共存型    | 中央と各システムの双方 | 同期の範囲に応じて発生 | 現場の入力画面を残したい |
| 集中管理型  | 中央のハブのみ     | 全登録経路で発生    | 登録を全社で一本化する  |

呼び名は資料によって揺れ、レジストリ型を参照統合型、集中管理型を統合ハブ型と書く例もあります。製品カタログを読むときは名称より、登録画面がどこに移るのかを確かめてください。

### 最初の導入でレジストリ型か統合型から始める企業の条件と効果が届かない範囲

既存システムの改修予算が取れない企業、あるいは重複がどれほどあるのかをまだ数字で説明できない企業は、この2方式から始めます。レジストリ型は同一レコードの対応表を中央に持つだけなので、基幹システムに手を入れません。統合型は複製を中央に集めるため、BIの売上集計を顧客単位でそろえる用途に向いています。

限界もはっきりしています。どちらも入力の時点では何も止めないので、重複は発生し続け、照合を繰り返す運用が残ります。業務画面に表示される社名も、元の誤ったままです。分析の数字が合えば目的を達する場合はここで止めてかまいません。

### 共存型と集中管理型で登録画面を変えるときに発生する改修範囲と調整事項

共存型の難所は、中央と各システムの両方で同じ項目が更新されたときの扱いです。どちらの値を勝たせるかを項目ごとに決め、同期に失敗した場合の再実行まで設計する必要があります。

集中管理型では、画面入力だけでなくCSVの一括取込、EDI、外部サービスからの自動登録まで、すべての入口を中央へ切り替えます。パッケージやSaaSでは登録機能を止められない製品もあり、1つでも抜け道が残ると重複はそこから戻ります。最初の導入で集中管理型は選びません。全社の登録業務を同時に変える負荷に対し、効果を確かめる材料がまだ無いからです。

## 名寄せと項目別の優先ルールで統合レコードの正しい値を決める実務手順

### 完全一致と類似度の照合を併用し自動統合と人の確認へ振り分ける判定基準

照合は、法人番号やメールアドレスなど同じ値なら同一とみなせる完全一致を先に当て、残りを社名や住所の類似度で判定する二段構えが基本です。[AWS Entity Resolutionもルールベースと機械学習の照合を別の方式として提供](https://aws.amazon.com/jp/entity-resolution/)しており、製品側でも役割が分かれています。

類似度の結果は1つのしきい値で切らず、次の3つに振り分けます。

- 高いスコア：自動で統合する
- 中間のスコア：担当者の確認待ちに回す
- 低いスコア：別のレコードとして残す

統合の取り消しができる設計にしておくことも条件です。統合前の元レコードIDとの対応を残さないと、誤統合に気づいても分離できず、取引履歴が混ざったままになります。照合アルゴリズムの種類は[データマッチング技術とは？名寄せ・類似検索の3系統とツールの選び方](https://www.issoh.co.jp/column/details/2377/)に詳しくまとめています。

### 項目ごとに採用元を決める生存ルールの例と更新日時だけで決めない理由

同一と判定した複数のレコードから、どの値を残すかを定めたものが生存ルール（サバイバーシップ）です。レコード単位ではなく項目単位で決めます。取引先マスタなら次のような形になります。

| 項目        | 採用元       | 理由          |
| --------- | --------- | ----------- |
| 法人名・本店所在地 | 法人番号の公表情報 | 国が管理する公的データ |
| 請求先の部署と宛名 | 会計システム    | 請求の実務で確認される |
| 営業担当・商談状況 | CRM       | 営業が日々更新している |
| 与信限度額     | 与信管理の台帳   | 承認を経た値に限る   |

「更新日時が新しい値を採用する」という単純なルールは危険です。夜間バッチや一括取込は内容を確かめないまま日時だけを新しくするため、古い住所が最新の値として勝ってしまいます。日時を使うのは、採用元の優先順位が同じ場合の決着に限ってください。

### 法人番号を照合キーにするときの処理区分と差分取得で押さえる公表仕様

国内の法人を扱うなら、[デジタル庁がベース・レジストリの整備済みデータに挙げる法人番号・商号・所在地](https://www.digital.go.jp/policies/base%5Fregistry)が外部の基準になります。取り込みを実装する段になると、[国税庁のWeb-API解説（Ver.4.0）](https://www.houjin-bangou.nta.go.jp/documents/k-web-api-kinou-ver4.pdf)にある次の仕様が設計に影響します。

- 1回の応答は2,000件が上限で、超えると分割して返る
- 処理区分の「21」「22」は清算の結了や合併による解散など登記記録の閉鎖等を示す
- 処理区分の「99」は指定の撤回などによる削除で、法人番号と更新年月日などを除き空欄になる
- 承継先法人番号の項目があり、合併後の統合先をたどる手がかりになる

閉鎖の通知を受けて自社マスタを即座に消すと、過去の請求データの参照先が失われます。無効フラグを立て、新規の受注だけを止める扱いが無難です。[公表機能の仕様](https://www.houjin-bangou.nta.go.jp/setsumei/pamphlet/images/k-specifications.pdf)では差分データのダウンロードは40稼働日分、全件データは月末時点の内容を翌月1日から1か月の提供です。ダウンロードで取り込む運用なら、連携が40稼働日より長く止まった場合に全件データから取り直す手順を運用書に入れておきます。

## 対象を一領域に絞って始める導入手順と品質指標で定着を確かめる運用設計

### 取引先か商品の1領域と2システムから始める導入の5段階と各段階の成果物

全社一斉の導入は、部門間の調整だけで止まりがちです。参照するシステムが多い領域を一つ選び、次の順で進めます。

1. 対象の決定：領域と連携する2システムを決め、対象範囲の定義書を作る
2. 現状の測定：重複と欠損を数え、基準値の一覧を作る
3. 項目の合意：項目定義と生存ルールを文書にして各部門の承認を得る
4. 初回の整備：クレンジングと名寄せを行い、確認済みの対応表を作る
5. 配信と運用：配信を始め、変更の申請先と責任者を公開する

3番目を飛ばすと、4番目の名寄せが何度もやり直しになります。「取引先」に支店を含むのか、個人事業主を含むのかが部門で違うだけで、統合の単位が変わるためです。登録・変更・廃止の承認フローの組み方は、先に挙げたマスタの解説記事に書いたとおり、責任者を明確にするところから始めます。

### 重複率・必須項目の欠損率・登録から反映までの日数で効果を測る指標設計

「統合した件数」は成果の指標になりません。多く統合しても、翌月に同じだけ重複が増えていれば状況は変わっていないからです。導入前に基準値を取り、毎月同じ定義で測る指標は次の3つに絞ります。

- 重複率：同一と判定された余剰レコード数を全件数で割った値
- 必須項目の欠損率：法人番号や請求先など業務で使う項目の空欄の割合
- 反映の日数：登録の申請から全システムで使えるまでの日数

たとえば1万件の取引先のうち余剰が600件なら、重複率は6%です。監視すべきは、この値が整備後に再び上がるかどうかにあります。上がる場合は名寄せの精度ではなく、管理外の登録経路が残っていることを疑ってください。

## 専用MDMツールへ投資する組織と見送ってテーブル設計で済ませる組織の境界

### 専用ツールへ投資すべき組織に共通するシステム数と登録頻度と監査の条件

次のいずれかに当てはまるなら、専用ツールの検討に進んでください。

- 同じマスタを参照するシステムが5つを超える
- 取引先や商品の新規登録が月に数百件ある
- 買収や海外拠点の追加で、コード体系の違う台帳が増え続けている
- 変更の履歴と承認者を監査で提示する必要がある

この規模になると、照合画面、承認ワークフロー、変更履歴を自前で作り続ける負担が重くなります。製品費と内製の保守費を、同じ期間で並べて比べる段階です。システム数の目安は、データ統合の基盤を検討する際の判断とも共通しています。

### 専用ツールを見送りマスタテーブルとAPIの設計見直しで足りる場面の判断

対象が2〜3システムで、マスタの追加が月に数件の組織に専用ツールは過剰です。導入しても照合の対象がほとんど無く、ライセンスと運用の負担だけが残ります。この場合に選ぶのは、共有マスタを1つのデータベースに置き、各システムがAPIか参照ビューで読みに行く形へ変更する方法です。一意制約、必須項目の制約、コードの外部キー制約を入れるだけで、入力時点の重複と表記揺れの多くは止まります。

迷いやすいのは3〜5システムの中間層です。ここでは製品の選定に入らず、取引先の1領域で対応表と簡易な確認画面を内製し、重複率がどれだけ下がるかを半年ほど測ります。判断材料が揃ってから製品に移っても、整備した対応表と生存ルールはそのまま引き継ぐことが可能です。ERPの刷新を控えている場合は、[システム移行の方式と進め方](https://www.issoh.co.jp/column/details/15261/)と同じ計画に組み込むと、整備を二度行わずに済みます。

### 製品を先に決めて責任者を置かないまま始めて頓挫する失敗パターンと対策

避けたいのは、製品の比較から始める進め方です。項目の定義が部門間で合意されていないと、導入後に統合ルールが決まらず、基盤だけが空のまま残ります。

クレンジングを一度きりの作業として外注するのも同じ結果を招きます。納品時はきれいでも、登録経路が変わっていなければ元に戻るからです。見積もりを依頼する前に、対象領域、正の置き場所、変更の承認者の3点を社内で決めてください。テーブル設計や既存データの移行を含めて外部に相談するなら、一創の[データベース設計・移行支援](https://www.issoh.co.jp/service/system/database/)で支援内容を確認できます。

## よくある質問

マスターデータ管理の検討で、担当者から挙がりやすい質問に回答します。

### マスターデータ管理とモバイル端末のMDMは別のものですか？

別のものです。この記事のMDMはMaster Data Managementの略で、顧客や商品などの基準データを扱います。スマートフォンの設定や紛失時の遠隔ロックを担うのはMobile Device Managementで、略称だけが同じです。製品を調べるときは「マスターデータ管理」と正式名で検索すると混ざりにくくなります。端末管理のほうを調べている場合は[MDMとは？モバイルデバイス管理の仕組みとEMM/UEMの違い・選び方【情シス向け】](https://www.issoh.co.jp/column/details/13276/)をご覧ください。

### ERPを導入していればマスターデータ管理は不要ですか？

ERPの中だけで業務が完結しているなら、ERPのマスタ機能で足ります。ただ実際には、CRMやECサイト、物流システムなどがERPの外で独自のマスタを持っていることが多く、その間のずれはERPだけでは解消しません。判断の分かれ目は、ERPをすべての登録の入口にできるかどうかです。外部システムの登録を止められないなら、別途の管理が必要になります。

### マスターデータ管理ツールは何を基準に比較すればよいですか？

対応する実装方式、照合の方法と確認画面の使いやすさ、承認と履歴の機能、既存システムとの連携手段の4点が基本です。特に連携手段は、APIで受けられるかファイル連携のみかで開発量が大きく変わります。多言語や複数ドメインへの対応は、将来の計画がある場合だけ評価に入れてください。使わない機能に対価を払う事態を避けられます。

### マスターデータ管理にかかる費用はどのように見積もればよいですか？

海外製の専用製品は個別見積もりが中心で、公開価格から総額を見通すのは困難です。費用は製品のライセンス、初期構築、既存データの整備、導入後の運用の4つに分けて確認します。見落とされやすいのは既存データの整備で、件数と重複の状況を測っていない場合は、見積もりの幅が大きく開きがちです。事前に対象件数と重複率を提示できれば、各社の金額を同じ条件で比べられます。

### 生成AIを使えば名寄せは自動化できますか？

候補の抽出や表記の正規化では工数を減らせますが、すべてを任せる運用は勧めません。取引先の統合を誤ると、請求先や与信の情報が別の会社に混ざるからです。実務では、確信度の高い候補のみを自動で統合し、残りは担当者が確認する形が現実的です。統合の判断理由と元レコードの対応を記録し、後から取り消せるようにしておくことが前提になります。

## 関連記事

- [マスタ（マスターデータ）とは？トランザクションデータとの違いと管理・MDMの進め方](https://www.issoh.co.jp/column/details/11085/)：マスタの種類とコード設計の基本を確認できます。
- [データ統合とは？種類・方式の違いと名寄せの壁から導入判断まで解説](https://www.issoh.co.jp/column/details/18977/)：ETLや仮想統合など基盤の方式を選ぶ手順です。
- [顧客データ統合の進め方｜名寄せのキー設計とCDPを入れずに済む条件](https://www.issoh.co.jp/column/details/18983/)：顧客マスタに限った名寄せキーの決め方です。
- [データマッチング技術とは？名寄せ・類似検索の3系統とツールの選び方](https://www.issoh.co.jp/column/details/2377/)：照合アルゴリズムの種類と選び方を扱います。
- [システム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準を解説](https://www.issoh.co.jp/column/details/15261/)：マスタ整備と同時に進める移行計画の立て方です。

---

出典: [マスターデータ管理（MDM）とは？4つの実装方式と導入を見送る条件を解説](<https://www.issoh.co.jp/column/details/19536/>)（株式会社一創）