こんばんは。皆さま、いかがお過ごしでしょうか？

“室長”こと吉島良平（Microsoft MVP for Business Applications|Microsoft Regional Director）です。

「最近Blog投稿数が増えましたね」と、言われる事があるのですが、Dynamicsに関わるようになって、25年ほど書き溜めている室長ノートが80冊を超え、年齢も年齢なので、そろそろ諸々公開しとこうかなと思いまして、夜な夜ながんばっている感じです。今日は、この1－2年くらいの備忘録から、いくつか取り上げようと思っています。

いよいよ今週末、6月7日（日）にラグビーリーグワン2025-26シーズンのプレーオフトーナメント最終日が迫ってきました。決勝はコベルコ神戸スティーラーズ vs クボタスピアーズ船橋・東京ベイ。3位決定戦は、準決勝でそれぞれ惜敗した埼玉パナソニックワイルドナイツ vs 東京サントリーサンゴリアス。どの試合も目が離せません。

実はこの決勝、私にとって少し複雑な一戦でもあります。神戸大学の卒業生として、コベルコ神戸スティーラーズには思い入れがあります。一方で、クボタスピアーズは、弊社Technosoftの公開導入事例でもご紹介させていただいている大切なお客様です。どちらも全力で応援したい—そんな、ちょっと欲張りなスタンスで観戦しようと思っています。

ラグビーの醍醐味の一つが、スクラムです。8人のフォワードが肩を組み、体をぶつけ合い、一つの塊になって押し合う。そこにスクラムハーフがタイミングを計ってボールを投入する。8人が同じ方向を向き、同じタイミングで力を合わせなければ、スクラムは成立しません。一人でもズレると、あっという間に崩壊します。

さて、試合を楽しみにしながら、今日もDXの話に向かいます。実はこのスクラムという仕組み、マスターデータの管理と構造がまったく同じなのですが—その話は最後に。

ところで、この週末のメンバーを眺めながら、ふと気づいたことが2つあります。

一つ目—「同じ人物、別の名前」問題。

神戸スティーラーズのアーディ・サベア選手。オールブラックスNo.8の超大物です。しかもこれは英語と日本語の違いだけではありません。日本語同士でも表記がバラバラなのです。神戸スティーラーズの公式サイトでは「アーディ・サべア」（「べ」が小文字）、リーグワン公式では「アーディ・サベア」、J SPORTSやWikipediaでは「アーディー・サヴェア」—日本語メディアだけで3パターン。さらに英語では「Ardie Savea」。

クボタスピアーズのマルコム・マークス選手（2025年ワールドラグビー年間最優秀選手・南アフリカ代表）、バーナード・フォーリー選手（オーストラリア代表）、サントリーのチェスリン・コルビ選手（南アフリカ代表・W杯2連覇の立役者）も、当たり前ですが、日本語表記と英語表記が混在します。
見ている人間にはわかる。でもデータベースで突合しようとすると—一致しない。これが名寄せ問題です。

二つ目—「同じ名前、別の人物」問題。

準決勝でクボタに惜敗し、3位決定戦に臨む埼玉パナソニックワイルドナイツには、山沢拓也選手と山沢京平選手—兄弟が同じチームにいます。「山沢」で検索すると—2件出てくる。どちらの山沢か、確認しないといけない。これが重複レコード問題です。この2つ、実はERPとCRMのマスターデータが毎日直面している問題と、構造がまったく同じです。「同じ人物、別の名前」—名寄せ問題。 「同じ名前、別の人物」—重複レコード。

そしてもう一つ、名前だけではありません。住所・場所の表記も、同じ問題を抱えています。

今週末の決勝戦の開催地—国立競技場。

「国立競技場」「Japan National Stadium」「新国立競技場」「JSC国立競技場」—同じ場所なのに、メディアや公式サイトによって表記が微妙に異なります。住所で言えば「東京都新宿区霞ヶ丘町10番1号」と書くこともあれば、「東京都新宿区霞ケ丘町」と「ヶ」と「ケ」が混在することもある。見ている人間にはわかる。でもデータベースで突合しようとすると—一致しない。「同じ場所、別の表記」—これも名寄せ問題の一つです。

顧客マスターにおける住所も、まったく同じ構造です。「丁目・番・号」と「-」のどちらで表記するか。「ヶ」と「ケ」、「ノ」と「の」—人間には同じに見える表記が、システムには別の住所として登録される。今日はこの「マスターデータの闇」に、正面から向き合いたいと思います。

第1章|マスターデータの闇とは何か

「名寄せ」という言葉を聞いたことがあるでしょうか。データの世界では、同一の実体（人・企業・モノ）が、複数のシステムに異なる形で登録されてしまっている状態を統合・突合することを「名寄せ」と呼びます。聞けば当たり前のことのように思えます。でも、これが企業のデータ活用における最大の障壁の一つであることは、現場を知る人間なら誰もが頷くはずです。

マスターデータの問題は、大きく2種類に分類できます。

「同じ人物、別の名前」—名寄せ問題。同一の顧客が、システムごとに異なる表記で登録されている状態です。

• CRM側：株式会社テクノソフトコンサルティング
• ERP側：ﾃｸﾉｿﾌﾄｺﾝｻﾙﾃｨﾝｸﾞ（株）
• レガシーシステム側：ﾃｸﾉｿﾌﾄｺﾝｻﾙﾃｨﾝｸﾞｵｰﾄﾓｰﾃｨﾌﾞ事業部

同じ会社です。でもシステムは別の会社として認識しています。「同じ名前、別の人物」—重複レコード問題。

異なる人物・企業が同一のレコードとして扱われてしまっている、あるいは同一人物が複数のレコードとして存在している状態です。この2つは、似ているようで発生メカニズムも、解決アプローチも、まったく異なります。そして厄介なのは、この2つが同時に、複合的に発生するという現実です。

CDP(顧客データプラットフォーム)を構築したい。デジタルマーケティングを強化したい。AIで顧客を分析したい—そのすべての出発点に、このマスターデータの問題が立ちはだかります。

どれだけ優秀なAIも、どれだけ高価なCDPも、食わせるデータが「バラバラ」では、正しい答えを返せません。ゴミを入れれば、ゴミが出てくる（Garbage In, Garbage Out）。これはデータの世界における、永遠の真理です。

第2章｜なぜバラバラになるのか

2-1. 2層構造の現実

では、なぜこんなにデータがバラバラになってしまうのか。構造的な原因を理解するために、オートモーティブ業界を例に取り上げてみましょう。ここでいうOEMとは、メーカーおよびその販売を担う現地法人・販売会社を指します。この業界のシステム構成は、大きく2層に分かれています。OEM側には、販売・マーケティングを管理するCRM、生産・在庫・物流を管理するERP（主にSCM機能を中心に利用）、そして財務を管理する現地の会計パッケージが存在します。

ディーラー側には、新車販売とアフターサービスを管理するDMS（ディーラーマネジメントシステム）、顧客接点を管理するCRM、そして会計システムが存在します。新車販売業務、アフターセールス業務を各々別の仕組みで管理しているケース、更にはCRMも同様に、新車販売用とアフターセールス用と異なるものを利用されているケースも見受けられます。それぞれが、それぞれの業務に最適化されて、独立して動いています。

2-2. OEMは顧客を知らない

ここで重要な事実があります。OEMは、車両を実際に購入したエンドユーザーの情報を、直接持っていません。OEM側のERP（基幹統合業務パッケージ）はSCM機能が中心です。車両の生産・配送・在庫を管理するのがERPの役割であり、「誰が買ったか」はERPの管轄外です。会計も現地の別パッケージで動いています。OEMにとっての「顧客」は、あくまでディーラーです。

車両を実際に買ったエンドユーザーの情報は、ディーラー側にしか存在しない。つまり顧客データの主権は、OEMではなくディーラー側にあるのです。OEMがCDPやデジタルマーケティングで「顧客を一元的に見たい」と思った瞬間、ディーラー側の散らばったデータを掻き集めるところから始めなければならない—これが構造的な出発点です。

さらに厄介なのは、情報の流れが一方向ではないという点です。OEMがWebやデジタルマーケティングで獲得したリード（見込み客情報）を、ディーラーに渡すケースがあります。「このエリアで問い合わせがあったお客様です。フォローアップをお願いします」—OEMからディーラーへのリード渡しです。しかし、そのリードがディーラー側でどのようにマスターに登録されるか、OEMにはわかりません。

ディーラーのDMSやCRMに、OEMが渡したリードと同じ顧客がすでに登録されていたとしたら？渡されたリード情報と既存レコードが名寄せされず、別々に管理されていたとしたら？そのリードがその後どう対応されたか、OEM側には見えない。OEMがせっかく獲得したリードが、ディーラーのシステムの中で「どこに行ったかわからない状態」になる。顧客データの主権はディーラー側にある。しかしリードの起点はOEM側にある—この非対称な構造が、データ管理をさらに複雑にします。

2-3. VINの壁

さらに問題を複雑にするのが、DMSの設計思想です。DMSの多くは、「人」ではなく「車（VIN：車両識別番号）」を主キーとして設計されています。VINレベルの分析—「この車の整備履歴は何か」「この車両はいつリコール対応したか」—は非常に得意です。しかし「この人がどんな顧客か」という人軸の分析になった途端、精度が一気に落ちます。同じオーナーが車を買い替えても、VINが変わればレコードが切れる。同じ人が複数台所有していても、VINごとに別々に管理される。人が見えない。VINしか見えない。これがOEMの360度ビュー実現を阻む、構造的な壁です。

2-4. バラバラ殺データ事件（顧客データ編）

整理すると、1つのビジネスエコシステムの中に、これだけのシステムが乱立していることになります。

OEM側：CRM、ERP（SCM中心）、現地会計パッケージ
ディーラー側：DMS（新車）、DMS（アフター）、CRM、会計

そしてそれぞれが、それぞれの「顧客」を、それぞれのルールで登録している。同じ顧客が、同じ日に複数のディーラーを訪問したとします。値引き交渉をしながら、より良い条件を探している—ごく自然な購買行動です。でもその瞬間、OEM側からは「同じ人物が、複数の別人として同時に存在している」という状態が生まれます。名前の表記も、住所の形式も、顧客コードも、すべてバラバラ。

これが—「バラバラ殺データ事件」です。

これはオートモーティブ業界に限った話ではありません。本社と現場、メーカーと代理店、本部と加盟店—二層構造を持ち、それぞれが異なる「主キー」で動いているビジネスであれば、同じ構造が生まれます。製造業、金融、流通、医療—「この人、何人いるの？」という問いは、業種を超えて普遍的な課題です。

2-5. バラバラ殺データ事件（粗利編）

顧客データがバラバラになるのは、すでに見てきた通りです。しかし、バラバラになるのは顧客データだけではありません。粗利の定義まで、バラバラになります。自動車のアフターサービスには、サービステンプレートという概念があります。「この修理作業には何時間かかるか」「どの部品を使うか」「標準価格はいくらか」—OEMが定めた作業工数・部品・価格の標準定義です。

OEM主導でDMSが設計される場合、各社のサービステンプレートがDMSに組み込まれます。これにより作業ごとの工数や部品原価が標準化され、整備売上や粗利が共通の定義と同じメッシュで把握できるようになります。OEMにとっては、全国・全世界のディーラーの収益性を同一基準で比較できることが重要です。「どのディーラーが効率的か」「どの作業の収益性が高いか」といった、経営判断の根拠となるデータが得られます。

ところが、マルチブランドディーラー（複数のOEMブランド車を同一拠点で扱うディーラー）になると、この仕組みは崩れることがあります。たとえばブランドA・B・Cそれぞれが異なるサービステンプレートを持ち、工数定義、部品コード体系、価格計算ロジックが各社でばらばらな場合です。ディーラー側がDMSに組み込まれたテンプレートを使わず、自社運用（例：セカンド品の活用など）で対応すると、ブランドをまたいだ粗利比較ができなくなります。

結果として、ディーラーはブランド間の利益比較や経営判断が不正確になり、OEMは販売店の収益性を正確に把握できません。経営判断が「肌感覚」に頼らざるを得ない状況が生まれます。これは単なるデータの不整合の問題に留まらず、経営判断の根拠そのものを揺るがす重大な課題です。

さらに、もう一つの闇があります。ディーラーが、データを正直に入力しない問題です。新車の販売価格を例に取りましょう。OEMはディーラーに対して、販売価格や値引き額の報告を求めます。しかし現実には、実際の成約価格をそのままシステムに入力しないケースが少なくありません。（特に海外では）

値引き額が大きすぎると、OEMからの指導が入る。インセンティブの計算に影響する。競合他社に情報が漏れるかもしれない—様々な理由から、ディーラーは「都合のいい数字」を入力する誘惑にかられます。

そしてもう一つの闇が、月末入力問題です。月末になって初めて、その月のデータをまとめて入力してくる。リアルタイムのデータではなく、月次の「報告書」として入力される。
これが何を意味するか。OEM側がCRMやCDPでリアルタイムの販売動向を把握しようとしても、データが月末まで存在しない。月の途中では何も見えない。月末に一気に入ってくる数字も、本当に正しいかどうかわからない。

なるべくリアルタイムでデータを入れないと、AI Agentからのタイムリーなヘルプを得ることがほぼ不可能になります。Sales Agentが「この顧客、そろそろ買い替えのタイミングです」とアラートを出せるのは、リアルタイムのデータがあってこそです。月末にまとめて入力されたデータを見て、AI Agentが「先月の動向を分析する」と言っても、その情報はすでに古い。競合他社はすでに動いています。データの鮮度は、AI Agentの判断の鮮度に直結します。ゴミを入れれば、ゴミが出てくる。遅れて入れれば、遅れて出てくる。マスターデータの闇は、テクノロジーだけでは解決できない—この現実を、ここで直視しておく必要があります。

さらに、「バラバラ殺データ事件」はパーツ・部品の世界にまで及びます。ディーラー独自調達問題です。OEMは純正パーツに標準部品コード・標準価格・標準工数を定めています。しかし現実には、ディーラーが独自にパーツを調達するケースが少なくありません。ディーラーが独自調達したパーツには、独自の部品コードが振られます。OEMの標準コードとは紐付かない。工数定義もOEMのサービステンプレートと合わない。結果として、粗利計算がさらにバラバラになります。

OEM側の代替品突然投入問題も深刻です。ある日突然、OEMから通知が来ます。「部品Aは廃番になりました。代替品Bに変更します。」ディーラーのDMSはまだ部品Aのままです。在庫として残っている部品Aはどう処理するのか。過去の整備履歴との紐付きはどうなるのか。

Customer Insightsで車両履歴を追おうとすると、途中でデータが「？」になる。OEMが善意で標準化しようとした行為が、現場のデータを断絶させる—これも構造的な皮肉です。顧客データがバラバラ。粗利定義がバラバラ。入力タイミングがバラバラ。そしてパーツコードまでバラバラ。

これが、オートモーティブ業界のデータカオスの全貌です。「バラバラ殺データ事件」は、一つの部門・一つのシステムの問題ではありません。ビジネスエコシステム全体に、静かに、しかし確実に広がっている構造的な問題なのです。

2-6. 国境を越えると、闇はさらに深くなる

ここまで描いてきた「バラバラ殺データ事件」。これが国境を越えた瞬間、さらに次元が上がります。

日本のOEMが海外に現地法人を持ち、その先にディーラーネットワークを展開している—これは多くの日系自動車メーカーにとって、ごく当たり前のビジネス構造です。しかしその「当たり前」の裏側に、いくつもの闇が潜んでいます。

言語の壁

日本本社からは、現地語の顧客名が読めません。アラビア語、タイ語、インドネシア語、ベトナム語—現地語表記と英語表記とローマ字表記が混在します。同じ顧客が、現地語で登録されているシステムと、英語で登録されているシステムと、ローマ字で登録されているシステムに、それぞれ別人として存在している。さらに厄介なのが、文化的な名前の構造の違いです。

姓名の順序が日本と逆の国もあれば、父称を名前の一部として使う文化もある。部族名が入る国もある。「名前」の概念そのものが、国によって異なります。日本本社のシステムが「姓・名」という2項目でマスターを設計していると、そもそもフィールドに収まらない名前が出てきます。

税制の壁

国ごとに、税の仕組みが根本的に異なります。VAT（付加価値税）の税率・計算方式、源泉徴収の仕組み、インボイスの法定フォーマット—これらはすべて国ごとに異なります。ERPのマスター設計が国ごとに変わるため、同じ「売上」「粗利」という言葉でも、国をまたいで比較すると定義が揃っていないケースが生まれます。

車両販売・サービスレギュレーションの壁

排ガス規制、安全基準、リコール対応の法的義務—国ごとに異なります。ある国では義務であるリコール対応が、別の国では任意だったりする。アフターサービスの保証期間・保証内容の法的要件も異なります。VINの構造・ルールも市場によって微妙に異なるケースがあり、「VINで突合すれば同一車両がわかる」という前提が、グローバルでは必ずしも成立しません。

個人情報保護法の壁

「日本本社がディーラーの顧客データを見る」—これ自体が、法的にグレーになる国があります。GDPR（欧州）、PDPA（タイ）、PIPL（中国）、PDPL（サウジアラビア）—国ごとに異なる個人情報保護法が存在します。データの越境移転に制限がある国では、現地の顧客データを日本本社のサーバーに送ること自体が違法になるケースもあります。「全データを日本に集めてCDPで分析する」というアーキテクチャが、法律によって不可能になる—これはシステム設計の問題である以前に、法務・コンプライアンスの問題です。

労基・組織の壁

そして最も見落とされがちな壁が、人の問題です。現地法人は、システム導入に人・時間・カネを割く余裕がありません。彼らの本業は販売・修理であり、ITプロジェクトのリソースを確保することは構造的に難しい。にもかかわらず、「レポーティングを急げ」「データをこのフォーマットで入力せよ」という指示が降りてくる。現地からすれば、本業の邪魔をされている感覚です。現地の反発を招き、データ品質がさらに悪化する—という悪循環が生まれます。

それでも「見える化」が必要な理由—本社が関与すべき理由

では、こんなに障壁が多いなら、諦めればいいのか。そうではありません。日本のOEMにとって、海外現地法人の販売力は外貨獲得の生命線です。円安・国内市場の縮小という現実の中で、グローバルでの販売力強化は経営の最重要課題の一つです。

日本本社からディーラーまでが「見える」ようになると、世界が変わります。どの国の、どのディーラーで、誰が、何を買っているか。在庫の偏りがリアルタイムでわかる。需要の予兆が見える。クレームの傾向が国をまたいで把握できる。販売予測の精度が上がり、生産・物流・マーケティングが最適化される。

そのために、本社が関与すべき理由が4つあります。

現地にはできないから
複数国をまたぐ標準化は、現地単体では不可能です。現地が個別最適化すると、全体最適が永遠に来ない。

本社だからできることがあるから
グローバル標準のプラットフォーム選定、データガバナンスの設計、国をまたぐ名寄せルールの策定、ベンダーとのボリューム交渉—これらは本社レベルでなければできません。

投資対効果が本社レベルで初めて見えるから
1カ国だけでは投資回収が難しくても、複数国展開で初めてROIが成立します。グローバルCDPの価値は「国をまたいだ顧客理解」にあります。

現地を守るためでもあるから
個人情報保護法への対応、セキュリティ・コンプライアンスは本社が傘を広げるべき領域です。現地が知らないうちに法律違反になるリスクを、本社が防ぐ。

現地法人のスタッフは、データ入力に追われるのではなく、本来の仕事—販売・修理・顧客対応に集中できるようになる。AI Agentが現地スタッフの「デジタルな相棒」として、タイムリーな提案・アラート・サポートを届ける。現地の負担を下げながら、本社の可視性を上げる。これが、グローバルDXの本来の姿です。

しかしそこにも、名寄せという問題が立ちはだかります。日本本社には読めない名前。国をまたいだ同一顧客の突合。多言語・多文化・多法域をまたぐマスターデータの統合—これが第4章で向き合う「ラスボス」です。

第3章｜究極の問い—マスターはどこに持つべきか

第2章で「バラバラ殺データ事件」を描きました。では、実際にマスターをどこに持つべきか。

多くの現場でよく聞く答えがあります。

「ERPに一本化すればいい」 「CRMをマスターにすればいい」

どちらも間違いではありません。でも、どちらも正解ではありません。なぜか。データにはライフサイクルがあるからです。

3-1. データにはライフサイクルがある

顧客データは、ビジネスの進行とともに「性質」が変わります。見込み客の段階では、データに求められるのはスピードと情報の豊かさです。営業担当者が商談の中で得た断片的な情報—名刺の情報、Web上の行動履歴、展示会での会話—これらを素早くCRMに登録し、次のアクションに繋げることが優先されます。この段階で財務システムの厳密なルールを適用しようとすると、営業の動きが止まります。

しかし、成約して請求・入金のフェーズに入った瞬間、データに求められるものが変わります。正確性と法的な担保が絶対条件になります。住所の表記ゆれも、名前の微妙な違いも、財務・法務の世界では許されません。つまり「どのシステムがマスターか」という問いは、「今、データはどのフェーズにあるか」という問いと切り離せないのです。

3-2. ライフサイクル別SoR設計

AI時代の理想的な設計—それは「Dataverseを共通のマスターハブとし、ライフサイクルに応じてSoR（Source of Record：データの所有権）をバトンタッチする」という考え方です。昔ながらの「ERPが絶対」や「CRMが正義」という一元論ではなく、データのステータス（ライフサイクル）で所有権を切り替えます。

「ERPを汚さない」—この発想が、設計の起点になります。

見込み段階の不完全なデータをERPに流し込んでしまうと、財務マスターが汚染されます。逆に、成約後のデータをCRMだけで管理し続けると、請求・債権管理に支障が出ます。バトンタッチのタイミングと、バトンの渡し方—ここの設計が、Lead to Cashの品質を決めます。

3-3. アンチパターン：密結合の悲劇

では、このバトンタッチをどう実装するか。ここでやってはいけない設計があります。FOの「Dual-write」などで安易に双方向・リアルタイム同期をかけることです。Dual-writeは非常に強力な仕組みです。FOとDataverseの間でデータ変更に応じてほぼリアルタイムで双方向に書き込みが行われる—前回の記事でもご紹介した通りです。しかし、この強力さが諸刃の剣になります。

CRM側で営業担当者が「（株）〇〇」とノリで入力した文字が、Dual-writeを通じて、ERP側の厳密な財務マスターに即座に反映される。財務マスターが、営業の「ノリ」で上書きされる。これがデータの世界における「ノックフォワード（データの衝突）」です。

さらに、Dual-writeにはもう一つの深刻なリスクがあります。一度有効化すると、簡単には止められないということです。FOとDataverseの接続は密結合になります。「やっぱり繋ぐのをやめよう」という判断が、後になればなるほど難しくなる。初期設定時に既存データの整合性を確保しておかないと、FOとCRMにそれぞれ存在するマスターデータが衝突し、どちらが正しいのかわからない状態に陥ります。

「繋ぐ前の設計」が、すべての品質を決める。Dual-writeは「使うかどうか」ではなく、「どこに使い、どこには使わないか」を慎重に選択する技術です。

3-4. Virtual Entities／Virtual Tablesという選択肢

では、密結合を避けながらERPのデータをCRM側から活用するにはどうすればいいか。ここで強力な選択肢として登場するのが、Virtual Entities（FO）およびVirtual Tables（BC）です。仕組みはシンプルです。DataverseにERPのテーブルの「定義（窓口）」だけを登録し、実際のデータはERP側に置いたまま、アクセスのたびにリアルタイムで取得する。Dataverseにデータのコピーは作られません。

これにより

• ERPはSingle Source of Truthのまま守られる—財務マスターが外部から書き換えられるリスクがない
• CRM・Power Apps側からはDataverseの通常テーブルと同じように見える—開発者の学習コストが低い
• データの二重管理が発生しない—同期ズレや整合性問題が構造的に起きない

Dual-writeとの最大の違いは「書き込みの制御」です。Virtual Entities／Virtual Tablesは基本的に読み取り中心の設計です。ERPのデータをCRM側から参照したい—与信残高、在庫数量、請求ステータス—こうした「今この瞬間の値」を確認したいだけであれば、Dual-writeの密結合リスクを負う必要はありません。

ただし、Virtual Entities経由でのトランザクション処理（受注作成など）は、API設計の品質に依存します。「読み取りはVirtual、書き込みはルールに従って昇格」—この使い分けが、マスターデータを守りながらLead to Cashを実現するスマートな設計です。

だからこそ、Dataverseというハブを間に挟み、そこでデータの「昇格ルール」を制御することが重要です。

見込み客がどの条件を満たしたら「正式顧客」に昇格するか

昇格時にどのデータ項目を検証・クレンジングするか

ERPへの書き込みは誰がどのタイミングで承認するか

この昇格ルールの設計こそが、マスターデータの品質を守る「ゴールキーパー」です。

ラグビーで言えば、ボールをトライゾーンに運ぶ前に、ノックフォワードが起きていないかを確認するプロセス。それがDataverseを介した昇格ルールの役割です。

3-5. BCとFO、どちらのERPを選ぶか

バトンタッチ先のERPについても、一言触れておきましょう。マスターデータの観点でも、BCとFOの特性は異なります。BCの場合は、Data SyncとVirtual Tablesを組み合わせた設計が基本です。定期同期でマスターを連携しつつ、与信残高や在庫のようなリアルタイム性が必要なデータはVirtual Tables経由で参照する。データのコピーを最小化し、BCをSingle Source of Truthとして守る設計です。

FOの場合は、Dual-writeによる常時同期が基本構成です。ただし前述の通り、Dual-writeは密結合になるため、どのエンティティをDual-write対象とし、どのエンティティは一方向に留めるか—この設計判断が品質を左右します。

どちらのERPを選ぶかは、企業の規模・業務要件・グローバル展開の有無によって異なります。しかしどちらの場合も、「どのタイミングで、どのデータを、誰の責任でERPに渡すか」という昇格ルールの設計は共通して必要です。

第4章｜ラスボス—名寄せという難題

第2章で「バラバラ殺データ事件」を描きました。第3章でマスターの設計論を整理しました。

では、実際に名寄せをどうやって解決するのか。ここからが本当の難題です。室長は、この問題を「マスター界のラスボス」と呼んでいます。ダンジョンの最後に待ち構えている、最も強く、最も手強い敵。システムを導入しても、設計を整えても、最後に必ずこいつが立ちはだかる。

4-1. ルールベースマッチングの限界

従来、名寄せはルールベースのマッチングで対応してきました。完全一致——名前が完全に同じなら同一人物。前方一致—「株式会社テクノソフト」で始まるレコードは同じ会社。正規化—「（株）」を「株式会社」に統一してから突合する。一見、合理的に見えます。しかし現実の名寄せ問題の前では、あっという間に限界が来ます。

• CRM側：株式会社テクノソフトコンサルティング
• ERP側：ﾃｸﾉｿﾌﾄｺﾝｻﾙﾃｨﾝｸﾞ（株）
• レガシーシステム側：ﾃｸﾉｿﾌﾄ ｵｰﾄﾓｰﾃｨﾌﾞ事業部

これを完全一致で突合しても、一件もマッチしません。正規化しても、略称・事業部名・全角半角の混在—ルールの組み合わせは無限に増え続け、メンテナンスコストが爆発します。そしてグローバルになると、ルールベースは完全に崩壊します。アラビア語とローマ字表記の同一人物を、ルールで突合することはほぼ不可能です。タイ語の顧客名を正規化するルールを、日本本社が書けるでしょうか。ルールベースには、構造的な限界があります。

4-2. AI（LLM）の出番

ここで、AI—特にLLM（大規模言語モデル）の出番です。LLMは、文字列の「意味的な近さ」を理解できます。「株式会社テクノソフトコンサルティング」と「ﾃｸﾉｿﾌﾄｺﾝｻﾙﾃｨﾝｸﾞ（株）」が同じ会社である可能性を、ルールではなく文脈と意味から判断できます。
従来のファジーマッチングと比べて、LLMベースのマッチングは：

• 略称・通称・事業部名の揺れに強い
• 多言語をまたいだ突合が可能
• 住所・電話番号・業種などの補助情報を組み合わせて精度を上げられる
• 「同一人物である確率」をスコアとして出力し、人間のレビューに回すことができる

AIは「これは同じ人物ですか？」という問いに、確率で答えてくれます。100%の確信がある場合は自動マージ。確率が高いが断言できない場合は人間のレビューキューに入れる。確率が低い場合は別レコードとして保持する—この3段階の設計が、実務的な名寄せの現実解です。

4-3. Customer Insightsでどうマージするか

Dynamics 365のエコシステムでは、Customer Insightsがこの名寄せ・マージの中心的な役割を担います。Customer Insightsは、複数のデータソース（CRM、ERP、DMS、Webログ、コールセンター履歴など）を統合し、顧客の360度ビューを構築するプラットフォームです。名寄せの観点では、以下の機能が特に重要です。

マッチングルールの設定
—どのフィールドを、どの重みで突合するかを設定できます。名前・住所・電話番号・メールアドレス—複数フィールドの組み合わせでマッチング精度を上げます。

マージポリシーの設定
—複数のレコードが同一人物と判定された場合、どのフィールドをどのソースから優先して採用するかを設定できます。「住所はERPを優先、メールアドレスはCRMを優先」という細かい制御が可能です。

AIによる重複検出
—ルールベースでは検出できない微妙な重複を、AIが補完します。

ただし、Customer Insightsを導入すれば名寄せが「解決する」わけではありません。マッチングルールとマージポリシーの設計品質が、そのまま出力の品質になります。ここでも「設計と覚悟」が問われます。

4-4. グローバルの名寄せ—多言語・多文化の壁

Customer Insightsのようなツールを使っても、グローバルの名寄せには追加の難題があります。文字コードの問題。アラビア語は右から左に書きます。タイ語には単語の区切りがありません。中国語の簡体字と繁体字は別の文字として扱われます。これらを同一システムで正規化するだけで、相当な工数がかかります。

姓名構造の問題。日本では「姓・名」の順ですが、欧米では「名・姓」の順です。インドネシアでは一名制（姓がない）の人も多い。アラブ圏では父称を含む長い名前が一般的です。「First Name」「Last Name」という2フィールドの設計が、そもそもグローバルに通用しません。翻字の問題。同じ人物の名前が、アラビア語からローマ字に翻字される際に、複数のスペルが生まれます。「Muhammad」「Mohammed」「Mohamed」—これらはすべて同じ名前の翻字ですが、文字列としては別物です。

これらの問題に対して、LLMは強力な武器になります。しかしLLMも万能ではありません。精度を上げるためには、現地のデータ品質向上と、現地スタッフによるレビュープロセスの設計が不可欠です。

4-5. ベンダー提供マスターデータという選択肢

名寄せの難題に対して、全く異なるアプローチがあります。「自分たちで作る」のではなく、「買う」という発想です。

先進市場では、マスターデータそのものを販売しているベンダーが存在します。複数のOEMブランド・複数のディーラーをまたいで、同一顧客のデータを統合・クレンジングした状態で提供してくれるなら、自社で名寄せに膨大なコストをかける必要がなくなります。

ただし、ベンダー提供データにも課題があります。品質の問題。ベンダーが提供するデータが常に最新・正確とは限りません。更新頻度、カバレッジ、精度—これらを慎重に評価する必要があります。

依存リスクの問題。ベンダーへの依存度が高まると、価格交渉力が失われます。ベンダーが事業撤退した場合のリスクも考慮が必要です。

プライバシーの問題。そのデータはどのように収集されたか。現地の個人情報保護法に準拠しているか—法務レビューが必須です。

それでも、「ゼロから名寄せを構築するコスト」と「ベンダーデータを購入するコスト」を比較した時、後者の方が合理的なケースは確実に存在します。

「自前主義」にこだわらず、使えるものは使う—これもAI時代のデータ戦略の一つです。

第5章｜本稼働前・後の闇

名寄せの難題に向き合う方法を整理しました。では実際にシステムを本稼働させる時、何が起きるのか。ここには、また別の闇があります。

5-1. 本稼働前：データ移行・クレンジングの現実

新しいシステムを本稼働させる前に、必ず「データ移行」というプロセスがあります。既存システムのデータを、新しいシステムに移し替える作業です。このタイミングで、データのクレンジング（洗浄）も行います。重複レコードを統合し、表記を統一し、欠損項目を補完する—理論上はそういう話です。

しかし現実は、こうなります。「どこまでやれば十分か」がわからない。

クレンジングを始めると、問題が次々と出てきます。直せば直すほど、新しい問題が見つかる。完璧を目指すと、本稼働の日程が延び続けます。「80‐90点で本稼働、残りは運用で直す」—これが現実的な判断です。

完璧なデータで本稼働することは、ほぼ不可能です。重要なのは、「どの項目は必ず正確でなければならないか（財務・法的に影響するもの）」と「多少の揺れは許容できるか（マーケティング用途のもの）」を事前に明確に分けておくことです。優先度の設計なしにクレンジングを始めると、重要でない項目の修正に膨大な時間を使い、本当に重要な項目が手つかずのまま本稼働する—という最悪のパターンに陥ります。

5-2. 本稼働後：新たな重複・誤りをどう検知するか

本稼働したら、データの問題は解決するか。

しません。。。

本稼働後も、新たな重複は日々生まれ続けます。新しい顧客が登録されるたびに、既存レコードとの重複チェックが必要です。住所変更・社名変更・担当者交代—マスターデータは生き物であり、常に変化し続けます。データの品質管理は、本稼働後も永遠に続く運用です。

Customer Insightsを使った継続的なマージ運用、AIによる自動重複検出、定期的なデータ品質レポートの確認——これらを「運用プロセス」として設計しておかないと、本稼働直後はきれいだったデータが、半年後には再びカオスに戻ります。

「システムを入れれば終わり」ではない。「システムを入れてからが始まり」—これがマスターデータ管理の現実です。

5-3. 切り戻しと証跡設計

名寄せ・マージには、避けられないリスクがあります。間違えて、別人をマージしてしまう可能性です。

「山田太郎（東京都）」と「山田太郎（大阪府）」が同一人物と判定されてマージされた。しかし実際は別人だった—こういうことが起きます。

この時、どうするか。切り戻せる設計になっているか。マージした記録が残っているか。どのルールで、いつ、誰がマージしたかの証跡があるか。マージ前の状態に戻せるか—これらが設計段階で考慮されていないと、間違いが起きた時に取り返しがつかなくなります。

Dataverseには監査ログ機能があります。しかし「監査ログがある」と「切り戻しの運用が設計されている」は別の話です。ログは残っている。でも、誰がどう使って切り戻すかのプロセスが決まっていない—これがよくある現場の姿です。切り戻しのプロセスと、証跡の保管ルールは、本稼働前に必ず設計しておくべき「地味だが重要な」設計項目です。

5-4. 誰がマスターデータを「守る」のか

最後に、最も根本的な問いがあります。誰がマスターデータを守るのか。

システムは道具です。道具は、使う人間の設計と意志がなければ、正しく機能しません。マスターデータの品質を守るためには、データスチュワードという役割が必要です。データの標準を定め、重複を検知し、クレンジングを推進し、現場への啓発を行う—この役割を担う人間・組織が存在しないと、どれだけ優れたシステムも形骸化します。

グローバル展開においては、本社レベルのデータスチュワードと、各国・各現地法人レベルのデータスチュワードの両方が必要です。本社が方針を決め、現地が実行し、その結果を本社がモニタリングする。この仕組みなしに、グローバルのマスターデータ品質は維持できません。

マスターデータの闇と向き合うとは、テクノロジーを導入することではなく、組織として「データを大切にする文化」を作ること—それが、この章を通じて最も伝えたかったことです。

室長まとめ｜終戦のプロトコル—そして、次の戦いへ

本稿は少し長い旅になりました。いや、これからも続く旅です。

マスターデータの闇を、冒頭のラグビーネタから始まり、オートモーティブ業界の2層構造、VINの壁、バラバラ殺データ事件、粗利定義の崩壊、月末入力問題、国境を越えた闇—一つひとつ、丁寧に見てきました。

読んでいただいた方の中には、「これ、うちの話だ」と感じた方もいるかもしれません。あるいは「思っていたより、ずっと深い問題だ」と感じた方もいるかもしれません。どちらの感想も、正しいと思います。

データの品質は、文化が決める

この記事を通じて、一貫してお伝えしてきたことがあります。マスターデータの問題は、テクノロジーだけでは解決できない。

Customer Insightsを導入しても、Dataverseを整備しても、AIで名寄せを自動化しても—データを入力するのは人間であり、入力のタイミングと正確さを決めるのは組織の文化とインセンティブ設計です。なるべくリアルタイムでデータを入れないと、AI Agentからのタイムリーなヘルプを得ることがほぼ不可能になる。

これは技術論ではなく、行動論です。

日本のOEMがグローバルに横展開するために—車・交通ルール・運転手

日本のOEMがグローバル市場でデータを武器にするためには、3つのものが必要です。

車（データ基盤・プラットフォーム）。 Dataverseを共通のマスターハブとし、Customer InsightsでCDPを構築し、Power BIとFabricで可視化する—このプラットフォームが
「車」です。どれだけ優秀なドライバーでも、車がなければ走れません。

交通ルール（データガバナンス・標準化）。 マスターの定義、名寄せのルール、マージのポリシー、証跡の保管方法—これらを標準化し、全世界の現地法人・ディーラーに展開する「交通ルール」が必要です。ルールなき道路では、事故が起きます。

運転手（データスチュワード・推進体制）。 本社と現地の両方に、データを守る役割を持つ人間が必要です。システムは道具であり、道具を使いこなす「運転手」がいなければ、車はただの鉄の塊です。

認定ソリューション戦略—本社の最大の貢献

そして、もう一つ。

現地法人がITの知識のないメンバーを巻き込みながら、数ヶ月かけてRFPを作り、ベンダーを評価する—体力を物凄く消費するこの時間を、本社が解消できます。

OEMとして、推奨する認定ソリューションをあらかじめ持っておく。

現地のRFPプロセスを大幅に短縮し、OEMのデータ標準・APIに対応済みのシステムを現地に提供する。

ベンダーとのボリューム交渉も本社が担う。横展開・アップデート管理も本社が傘を広げる。

「現地に任せる」から「本社が傘を広げる」へ

これが、グローバルDXにおける本社の最大の貢献です。

現地法人のスタッフは、システム導入の泥沼から解放され、本来の仕事、「販売・修理・顧客対応」に集中できるようになります。

名寄せに、完璧な終戦はない—でも、スクラムは組み直せる。

皆さんが、この記事を読んでいる頃、6月7日の決勝のホイッスルはもう鳴ったでしょうか。

コベルコ神戸スティーラーズとクボタスピアーズ船橋・東京ベイ、どちらが頂点に立ったのか—結果がどうであれ、素晴らしい試合だったと信じています。

そして試合を振り返りながら、ふと思うのです。

スクラムは、組み直すたびに強くなる。

選手たちは、崩れたスクラムを何度でも組み直します。前の組み方が悪ければ修正し、角度を変え、タイミングを合わせ直す。

完璧なスクラムが最初から組めるチームは存在しません。組み直し続けることが、チームを強くするのです。

マスターデータも、まったく同じです。

顧客は引っ越し、社名を変え、担当者が変わり、新しい重複が日々生まれ続けます。

ディーラーは独自にパーツを調達し、OEMは突然代替品を投入する。

国境を越えれば、言語も税制も個人情報保護法も変わる。

完璧なマスターデータが最初から揃っている企業は、存在しません。

名寄せは「終わらせるもの」ではなく、「組み直し続けるもの」です。

でも、組み直し続けることが、競争優位になります。

データの川が繋がっている企業と、繋がっていない企業では、AI Agentが見える世界がまったく違います。

名寄せが整っている企業と、整っていない企業では、CDPが返す答えの精度がまったく違います。

スクラムを組み直す意志を持った8人が揃っているか。

それが—Dynamicsなスクラムの、本当の強さです。

この記事が、皆さんの組織で「名寄せにどう向き合うか」を考えるきっかけになれば、これ以上嬉しいことはありません。

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