マスターデータ管理と生成AI｜名称の揺れと誤参照を防ぐ実装手順

生成AIに正式な顧客名や商品名を答えさせるには、表記を似せるだけでなく、正規ID、採用値、利用権限、更新責任者を一組で管理する必要があります。本稿では、顧客マスターを例に、50件の固定評価セットで誤統合を抑えながら生成AIへ接続するところまで進めます。読後に作る成果物は「マスター候補評価票」です。

マスターデータ管理と生成AIは正規IDと責任者の確定から始める

開始条件は「マスターらしい表」を見つけることではありません。どの業務判断で、どの対象を、何の粒度で一意に扱うかを確定することです。

顧客なら、契約主体、請求先、納品先、担当者を同じ「顧客」と呼ぶと、AIは正しい名称を返しても別の対象を参照します。最初の対象は、国内法人の契約主体など一種類に限定し、正本候補のシステム、更新頻度、削除規則、利用目的、データ所有者を記録します。

ISOの公式規格ISO 8000-2:2022は、データ品質に関する用語を定めています^[1]。個社の正本や合格値を指定する資料ではないため、本稿では正確性や完全性を社内定義へ落とす際の用語上の基礎として参照します。

投入データには、文字コード、必須列、IDの一意性、値域、参照元、取得日時を持たせます。氏名、メールアドレス、購買履歴を含むなら、検証用コピーを作る前に個人データとしての取扱いを判定します。

欠損をAIに推測させる設計は、候補提示には使えても正本更新には使えません。開始判定は、必須条件六つのうち一つでも「不明」があれば保留とします。正本の選択を先送りしたまま、名寄せモデルを学習させないことが重要です。

完成形を正本・候補・利用面に分ける

完成形は一枚の巨大な顧客表ではなく、三つの面を分離した状態です。第一は、正規IDと現在の採用値を持つ「正本面」です。第二は、入力された別名、AIが算出した一致確率、比較根拠、承認結果を持つ「候補面」です。第三は、RAGや営業支援画面が参照できる項目だけを配布する「利用面」です。

この分離により、AIが「株式会社青空」と「（株）青空」を同じ候補として提示しても、承認前に正本を上書きせずに済みます。

ISOの公式規格ISO 8000-115:2024は、マスターデータ交換で用いる品質識別子について、所有者を曖昧にしない構文・意味・解決の要件を扱います^[2]。社内IDの採番方法そのものを定める規格ではないため、本稿では「IDの所有者と解決先を記録する」という設計根拠に限定して参照します。

生成AIの出力は正本ではなく、根拠付きの変更候補です。正本へ反映されるのは、権限を持つ担当者が対象、差分、影響先を確認した後だけです。

最低限の完成条件は、任意の表示名から正規IDへ解決できること、同じ正規IDに複数の現行レコードが存在しないこと、旧名称から現名称への履歴が追えること、利用者に許可された属性だけが返ることです。

候補を棄却した理由も保存します。棄却履歴がないと、同じ誤候補が毎回上がり、人が繰り返し判断するからです。逆に、候補面を永久保存すると個人情報や契約上の不要データが残るため、保存期間と削除処理を完成条件へ含めます。

手順1：対象範囲と正規IDを決める

業務上の同一性を文章で定義する

まず「同じ顧客」の意味を一文で書きます。想定例では「契約上の権利義務を負う法人が同一であるとき、同一顧客とする」とします。社名、電話番号、所在地が似ているだけでは統合しません。

合併、会社分割、支店移転、屋号変更は、名称変更なのか別法人への承継なのかを契約管理担当が判断します。海外法人、個人事業主、休眠顧客は初回範囲から外し、後で別ルールを追加します。この境界文を、データ辞書、評価票、承認画面の三か所で同じ内容にします。

IDを変えない条件と変える条件を分ける

正規IDは名称変更で変えず、対象の同一性が失われたときだけ新規発行します。採番値に社名や部署コードを埋め込むと、組織変更のたびにID変更が発生するため、意味を持たない内部IDを使います。

法人番号など外部識別子は照合属性として有用ですが、対象外法人や取得時差があるため、社内IDの代替と決めつけません。ISO 8000-115は識別子の作成方法を適用範囲外としているため、採番、廃番、再利用禁止は自社規程として明記します。

この段階の確認方法は、過去の難しい案件十件をルールだけで再判定し、担当者二名が同じID処理を選べるかを見ることです。一致しなければAIの精度問題ではなく、同一性定義の不足です。ルールを修正し、旧判定へ遡及するかも決めてから次へ進みます。

手順2：名寄せ候補を作り、誤統合を防ぐ

名寄せは、正規化、候補抽出、比較、判定の四段階に分けます。正規化では法人格表記、全角半角、空白、旧字体を検索用の別列でそろえ、原文は残します。候補抽出では、法人番号の一致、電話番号の一致、都道府県と名称の類似など、比較対象を絞る条件を使います。

比較段階で生成AIを使うなら、各属性の一致・不一致と根拠をJSONで返させ、最終判定を自由文だけにしません。AIが知らない会社情報を外部知識で補わないよう、与えたレコード以外を根拠にしない指示も必要です。

本稿の試算式は、候補対ごとに「名称類似度×0.35＋住所類似度×0.25＋電話一致×0.20＋法人番号一致×0.20」とします。各値は0から1で、法人番号が明示的に不一致なら総合点にかかわらず棄却します。

0.92以上を同一候補として優先表示し、0.75以上0.92未満を人の確認、0.75未満を別対象候補とする例です。この重みと閾値は実績値でもISO規格の指定でもありません。自社の重複・非重複ラベルを付けた50組以上で、誤統合と見逃しの費用を比べて調整します。

match_score =
  name_similarity * 0.35
  + address_similarity * 0.25
  + phone_exact_match * 0.20
  + corporate_number_exact_match * 0.20
if corporate_number_conflict:
    decision = "reject"
elif match_score >= 0.92:
    decision = "review_as_same"
elif match_score >= 0.75:
    decision = "manual_review"
else:
    decision = "review_as_different"

重要なのは「自動で同一候補」が正本の自動統合を意味しない点です。契約、請求、本人情報へ影響する統合は、スコアが高くても承認対象にします。自動化できるのは候補の優先順位付けまでとし、統合後に参照先が何件変わるかを承認画面へ表示します。候補が一対多になった場合、親子会社や本支店の可能性があるため、最上位だけを採用せず保留にします。

手順3：採用値と責任分担を確定する

属性ごとに「どのシステムが正しいか」を一律に決めると、更新の実態と合わなくなります。契約上の名称は契約管理、請求先住所は会計、営業上の表示名はCRMというように、属性単位で正本と更新責任者を指定します。

採用値には、値、正規ID、情報源、取得日時、有効開始日、承認者、承認日時を付けます。将来日付の変更は現在値を上書きせず、有効期間で管理します。

ISOの公式規格ISO 8000-150:2022は、データ品質管理の役割と責任を組織へ実装し、その証拠を残す際の考慮事項を示します^[3]。個社の職位名や承認額を指定する規格ではないため、表の担当名と承認範囲は本稿の運用例です。

承認者が不在のときに代理者へ無制限で回すと、責任表が形骸化します。代理承認は、別名追加など元に戻せる変更へ限定し、統合、分離、外部IDの変更は正式責任者の復帰まで停止します。月次会議で全件を見るのではなく、閾値付近、一対多、重要顧客、個人データを含む候補を重点抽出すると、判断負荷を抑えながら事故に近い変更を確認できます。

保留キューには、候補ID、比較した正規ID、保留理由、追加で必要な証拠、回答期限、担当者を持たせます。期限を過ぎた候補を自動承認せず、検索用の別名にも追加しません。

保留が30日を超えた割合を「長期保留件数÷全保留件数×100」で測ります。10％を超えた場合に、判断ルールの不足、証拠を取得できないデータ源、承認者の負荷を分けて調べる、というのは本稿の運用例です。単に担当者を増やす前に、同じ理由が集中していないかを確認します。

棄却した候補は、モデル学習へ無条件で戻しません。棄却理由が「別法人」「証拠不足」「現時点では判断不能」では、ラベルの意味が違うからです。確定した同一・別対象だけを評価用ラベルへ追加し、判断不能は別区分で保持します。

業務ルールが変わった後は過去ラベルの有効性を点検します。旧ルールで作った正解を新モデルの評価へ混ぜないよう、label_policy_versionを記録します。

保留件数の増減は週次で確認し、判断待ちの間に正式名称や契約状態が変わった候補は、古い比較結果を破棄して最新の正本版から再計算します。

手順4：生成AIへ安全に接続する

生成AIへ渡すのは正本面の全列ではなく、用途別に作った利用面です。営業支援RAGなら、正規ID、表示名、許可された別名、商品区分、回答で使用できる説明、有効期間、アクセス区分を選びます。請求先口座、個人担当者の連絡先、内部審査メモは検索対象から外します。

ベクトル化する文書にも正規IDをメタデータとして付け、検索結果の表示名を文章から再推測しないようにします。生成時にはIDで最新属性を引き直し、回答へ使った版と取得日時をログへ残します。

{
  "master_id": "CUS-0001842",
  "display_name": "青空商事株式会社",
  "aliases": ["（株）青空商事", "青空商事"],
  "valid_from": "2026-06-01",
  "source_system": "contract-db",
  "access_class": "sales-internal",
  "master_version": 17
}

経済産業省・総務省の公式資料「AI事業者ガイドライン」第1.2版は、AI開発者、提供者、利用者という主体ごとにリスク対応を整理した政府指針です^[4]。

本稿の権限分離、ログ、変更管理は、このガイドラインを民間企業の法的義務として扱うのではなく、AI利用者が自社ガバナンスを組み立てる参考枠として用いています。利用サービスの契約で入力データの学習利用、保存地域、再委託、削除方法が確認できない場合、利用面を作れていても外部AIへの送信は開始しません。

接続確認では、旧名称、略称、同名別法人、権限外属性、廃止済みIDの五種類を質問します。回答本文だけでなく、取得した正規ID、マスター版、拒否理由を照合します。権限外の質問に「情報がない」と答えるだけでは、アクセス制御が効いたのか検索に失敗したのか区別できないため、監査ログには拒否コードを残し、画面には必要以上の内部情報を出さない設計にします。

権限・契約・法的適用範囲を確認する

マスターデータの利用権限は、閲覧、候補作成、承認、正本更新、出力、削除に分けます。データベース管理者であることと、顧客統合を承認できることは別です。

サービスアカウントには利用面の読取権限だけを与え、モデルや検索基盤から正本へ直接書き込ませません。変更APIは、承認済み変更番号、実行者、対象版を必須にし、同じ変更番号の再実行を拒否します。外部委託先へ評価作業を出すなら、対象列を縮小し、契約目的、再委託、保存期間、返却・消去証明まで確認します。

顧客マスターに生存する個人の氏名、連絡先、取引履歴が含まれる場合は、個人情報保護法上の個人情報・個人データに該当するかを法務または個人情報保護責任者が判断します。

個人情報保護委員会の公式ガイドライン（通則編）は、2026年6月一部改正版が現行で、安全管理措置、従業者監督、委託先監督などについて法令の解釈を示しています^[5]。これは日本法の適用対象となる事業者の個人情報取扱いに関する公的資料です。

法人情報だけのマスターへ同じ義務が当然に及ぶと一般化はできません。一方、法人名だけでも契約上の秘密や営業秘密に当たる情報はあり得るため、個人情報でないことを無制限利用の根拠にしないでください。

法的評価は国、業種、契約、データ内容で変わります。本稿は法的助言ではなく、確認順序を示す実務設計です。医療、金融、通信、公共分野の追加規律、外国法、労務監視を伴う用途は、一般の顧客名寄せと同じ承認経路へ入れず、専門部署の判断が終わるまでデータ搬出を止めます。

50件の評価票で動作を検証する

評価セットは、同一対象25組、別対象15組、一対多または判断保留10組の計50組を想定します。通常案件だけを無作為抽出すると、同名別法人や会社分割のような事故につながる条件が不足するため、難例を意図的に含めます。

正解ラベルは、モデルの出力を見ない二名が契約資料などの根拠から作り、不一致をデータオーナーが確定します。評価後に閾値を変える場合は同じ50組を学習用に使い続けず、別の回帰確認セットを用意します。50組という内訳は、進め方を示す本稿の試行条件です。

再現率は「正しく同一候補にできた組数÷実際に同一である組数」、適合率は「正しく同一だった組数÷同一候補にした全組数」です。誤統合率は「別対象を同一候補にした組数÷実際に別対象である組数」とします。

本稿の想定合格基準は、誤統合率0％、適合率98％以上、再現率90％以上、権限外属性の返却0件、変更履歴の欠落0件です。50組で誤統合0件でも母数が小さいため、本番の安全を証明したとは言えません。高影響の誤統合を一件も許容しない初期ゲートとして使い、運用中の母数を増やします。

総合点で重大欠陥を相殺しないため、点数とは別に必須ゲートを置きます。本稿の想定総合式は「適合率×0.30＋再現率×0.15＋権限一致率×0.25＋履歴完全率×0.20＋反映時間達成率×0.10」です。

誤統合、権限外返却、履歴欠落のいずれかを一件でも検出したら、総合点に関係なく不合格です。評価票には入力版、ルール版、モデル版、実行日時も記録し、変更前後を同じ条件で比較できるようにします。

業務影響が異なる誤りは、件数と別に費用加重で見ます。想定例として、別法人の誤統合を100、同一法人の見逃しを20、旧名称の表示を5、確認待ちの増加を1とし、「Σ（誤り件数×影響係数）」を影響損失点とします。係数は金額そのものではなく、優先順位を固定する本稿の評価値です。

営業担当だけで決めず、請求、契約、個人情報保護、システム復旧の担当が、誤り一件から起こる作業と顧客影響を列挙して合意します。損失点が下がっても、誤統合0件の必須ゲートは緩めません。

さらに、正しい変更を取り込めるかを「ゴールデン変更セット」で確認します。商号変更三件、統合二件、分離二件、外部ID訂正一件、失効一件、権限区分変更一件の計十件を用意します。

候補作成、承認、正本更新、利用面反映、検索回答、切り戻しまでを通し、各段階の件数と版を照合します。一致しなければ、名寄せ精度が合格でも運用は不合格です。この十件という内訳も本稿の検収例であり、自社の変更種別に合わせて差し替えます。

更新、切り戻し、停止条件を運用へ入れる

更新は、定期更新と緊急更新に分けます。定期更新では、正本の差分を取得し、候補面で検証し、承認後に利用面を版上げします。緊急更新は、誤統合、権限設定ミス、廃止IDの再利用など、利用継続の影響が大きい場合に限ります。

切り戻しの単位はデータベース全体ではなく、マスター版と利用面版の組です。生成AIが古いインデックスを参照し続けないよう、インデックス版も同じリリース記録へ含めます。

定期見直しは月次を基本とし、名称変更件数、保留件数、誤候補、同期遅延を確認します。臨時見直しは、正本システムの変更、属性定義の変更、AIモデルまたは埋め込みモデルの変更、利用目的の追加、外部サービスの契約改定で開始します。

評価セットは四半期ごとに運用で見つかった難例を追加し、追加前の結果も保存します。正解ラベル自体が変わった案件は、モデル不良と業務ルール変更を分けて集計します。月次・四半期という間隔は本稿の運用例であり、更新頻度と影響度に合わせて短縮または延長します。

停止後は、誰がいつ止めたか、処理中の候補が何件あるか、どの版へ戻したかを一つのインシデント記録へまとめます。再開を急いで未処理候補を再投入すると二重更新が起きるため、変更番号で実行済みを照合します。復旧後の最初の一日は全候補を人が確認し、問題がなければ段階的に通常の閾値へ戻します。

本番更新の前には、変更影響を読み取り専用で試算します。統合候補ごとに、契約、請求、案件、問い合わせ、RAGチャンクへ紐付く件数を出し、更新後の正規IDと表示名を仮想表へ書きます。

影響先が事前申告より多い、更新不能なシステムがある、同じ外部IDが二つの正規IDへ残る場合は、承認済みでも実行を保留します。影響0件という結果も連携取得失敗の可能性があるため、直近の正常取得件数と比較します。

複数システムを一度に更新できない場合は、正本の版を先に発行し、各利用先の反映状態をpending、applied、failedで管理します。全利用先がappliedになるまで、旧IDから新IDへの解決表を維持します。

最大反映時間を超えた利用先は隔離し、片方の名称だけを生成AIが参照しないようにします。成功済みの更新を一律に元へ戻すのではなく、業務影響と二重処理の可能性を見て切り戻し単位を決めます。

この方法が向かないケースと次の判断

正本を決める業務責任者がいない、同一性の定義を契約や業務資料で確認できない、更新先を切り戻せない場合は、MDMと生成AIの接続を先に行うべきではありません。

名前検索の補助だけが目的で、回答が意思決定や顧客処理へ使われないなら、別名辞書と全文検索で足りる場合もあります。逆に、統合結果が請求、与信、本人対応へ波及する用途は、50件の試行だけで自動更新へ進めず、対象部門と評価期間を広げます。

次に取る行動は、国内法人の顧客レコードから、同一25組、別対象15組、保留10組を選び、本稿の「マスター候補評価票」を埋めることです。正規ID、正解根拠、利用目的、閲覧権限、承認者の五項目がそろわない組は、AIへ渡す前に除外します。そのうえで候補提示だけを動かし、誤統合率0％と権限一致率100％を確認できた範囲から、利用面への読取接続を始めます。

初回評価の日程を決めたら、データオーナーが正解根拠、契約担当が同一性、情報セキュリティ担当が閲覧権限、基盤担当が切り戻しをそれぞれ確認します。50組の評価票に未記入欄が残る場合は候補生成を始めず、正本と責任分担の確定へ戻ります。

参考文献・出典

1. ISO「ISO 8000-2:2022 Data quality — Part 2: Vocabulary」（第5版、2022年9月発行。改訂予定表示を含む現行ページ、2026年7月30日参照）
2. ISO「ISO 8000-115:2024 Data quality — Part 115」（第2版、2024年6月発行、2026年7月30日参照）
3. ISO「ISO 8000-150:2022 Data quality management: Roles and responsibilities」（第1版、2022年5月発行、2026年7月30日参照）
4. 経済産業省・総務省「AI事業者ガイドライン」（第1.2版、2026年3月31日公表、掲載ページ最終更新2026年4月1日、2026年7月30日参照）
5. 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（令和8年6月一部改正、2026年7月30日参照）