顧客台帳を一元化する｜重複・顧客ID・閲覧権限の整理

顧客台帳を一元化するとき、会社名が同じという理由だけで行を統合してはいけません。先に決めるのは、顧客IDをどの単位で残すか、会社と拠点・担当窓口をどう結び付けるか、誰が統合を確定するかです。

名称が一致しても別会社かもしれず、同じ法人でも支店は分けて扱う必要があります。担当者の異動や交代も、法人・拠点の重複とは分けて確認します。法人番号や所在地などで同一性を確認できた候補だけを統合し、材料が足りない候補は「統合保留リスト」に残します。

以下の公的情報と製品仕様は2026年9月24日時点で確認しています。名寄せ判定表、IDの構成、権限表は、それらを基にした架空の条件例であり、特定製品の完成済み仕様、実在の顧客事例、当社の導入実績ではありません。

顧客台帳を一元化する前に、会社・拠点・窓口を分ける

部署別の表では、会社名、支店名、担当者名が一行に収まっていることがあります。この一行をそのまま「顧客」と定義すると、どこまで一致すれば同一顧客なのかが曖昧になります。

台帳上の実体を次のように分けます。

• 法人：取引相手となる会社の単位。顧客IDを付ける
• 拠点：本店、支店、事業所などの単位。拠点IDを付け、顧客IDにひも付ける
• 担当窓口：連絡先となる人または窓口の単位。窓口IDを付け、所属する顧客IDと拠点IDにひも付ける

この分け方なら、同じ法人の複数支店を一社として集計しつつ、納品先や連絡先は混ぜずに保持できます。担当者が変わっても、法人や拠点を消して作り直す必要はありません。

法人を確認する材料には法人番号を使えます。国税庁「法人番号について」によると、法人番号を指定された法人等について公表される基本情報は、商号または名称、本店または主たる事務所の所在地、法人番号です。一方、支店・支部・事業所等には法人番号が指定されません。

つまり、法人番号は法人を確かめる材料になりますが、拠点を見分けるIDの代わりにはなりません。法人の顧客IDと、自社で管理する拠点IDを分ける理由はここにあります。

同名別会社・支店・担当者変更を分ける名寄せ判定表

表記を整えた会社名が一致した段階では、統合候補として抽出します。確定には、法人番号や本店所在地など、法人を確認できる材料が要ります。同名別会社を誤って一つにすると履歴や閲覧範囲まで混ざり、法人名が変わっただけの行を別顧客にすると一社の履歴が分断されます。

次の表は、統合前レビューに使う条件例です。「保持するID」は、統合後の関係を示しています。

会社名は似ているが法人番号が異なる候補は、同名別会社として止められます。法人番号が同じで別拠点と確認できた候補は、一つの顧客IDに複数の拠点IDをひも付けます。担当者の交代では窓口IDを追加し、旧窓口の履歴を残します。

所在地や支店名が異なる場合は、同じ拠点の移転・改称で既存の拠点IDを使い続けられるかを確認し、同一拠点か別拠点か判断できなければ保留します。

法人番号を確認できないこと自体は、同一法人でも別法人でもある証明になりません。自動統合せず、人が追加資料を確認できる状態で止めるのが安全です。

残す顧客IDを先に固定する

統合のたびに顧客IDの選び方が変わると、部署別データを再取り込みするときに同じ顧客を追えません。そこで、表示名とは別に、システム内部で重複しない顧客IDを持たせます。名称や担当窓口が変わっても、同一法人と確定できる限り顧客IDは保持し、変更履歴を別に残す設計です。

複数の顧客IDを一つにまとめる場合は、元台帳と旧ID、統合後に残す顧客IDの対応を記録します。再取り込みする行と過去の取引履歴が、同じ顧客IDへ対応付くことを確かめます。

ID同士の関係は次の形になります。

顧客IDは法人を示し、送り先や連絡先は拠点IDと窓口IDで示します。IDごとの対象を固定することが、会社・支店・担当者変更を区別する条件になります。

ファイル移行時にも、一意なIDは重要です。kintoneの公式ヘルプでは、ファイル読み込み時の更新キーは既存レコードと読み込む行をひも付けるフィールドで、値が一致すれば更新、一致しなければ新規登録になると説明されています。ただし、レコード番号を更新キーにして存在しない番号を指定した場合はエラーになります。また、更新キーに指定するフィールドの値は、ほかのレコードと重複できません。これはkintone固有の仕様です。一意なIDで既存行との対応を決める設計を検討する材料になります。

元表の洗い出しや移行単位から整理したい場合は、Excelから業務システムへ移行する進め方も参照できます。ただし、ファイルを取り込める状態に整えることと、顧客の同一性を確定することは別の作業です。

判定できない候補は統合保留リストで止める

「統合する」「統合しない」の二択だけでは、確認材料が足りない候補を無理に確定することになります。統合保留リストには、保留した理由と、何が分かれば判定を再開できるかを記録します。

最低限、次の項目を持たせます。

保留理由と再確認条件は対にします。「要確認」だけでは、別の担当者が見たときに何を調べればよいか分かりません。統合を確定できる役割も先に決めておけば、候補を見つけた人の判断だけで履歴が混ざるのを防げます。

閲覧権限は統合後の台帳から逆算する

顧客台帳を一元化しても、全員に全レコードを公開する必要はありません。会社・拠点・窓口をまとめて見られる利便性を保ちながら、担当範囲外の情報を隠す条件を決めます。

権限条件は、扱う情報と業務上の責任に合わせて定義します。

権限条件には、担当者本人だけでなく、担当組織、対象地域、共有可否、統合保留中かどうかといった台帳側の項目を使えます。まず「誰が何を見られるか」を表で決め、それから利用する製品で実現できるかを確認します。

kintoneの公式ヘルプでは、レコードのアクセス権について、レコード条件とユーザー・組織・グループを組み合わせ、レコードごとに閲覧・編集・削除を許可する対象を制限できると説明されています。設定が複数行ある場合や一人に複数の権限が該当する場合は、上の行が優先されます。これもkintone固有の仕様です。条件が正しくても優先順で見え方が変わり得るため、権限表から設定へ移す際は重なりを検証する必要があります。

既製SaaS、kintone、独自開発のどれを選ぶかによって、名寄せの確定フローや権限条件を実装できる範囲は変わります。SaaS・kintone・独自開発の比較で、業務への合わせ方を検討できます。

一元化を始める順序

部署別の顧客表を結合する前に、次の順序で受入条件をそろえます。

1. 各部署の列を、法人・拠点・担当窓口のどれに属するか分類する
2. 顧客ID、拠点ID、窓口IDの関係と、統合後に保持するIDを決める
3. 名寄せ判定表で、統合候補、統合保留、統合しない条件を決める
4. 統合保留リストの項目、再確認条件、統合確定者を決める
5. 役割ごとの閲覧・編集・名寄せ権限を決める
6. 一意なIDで移行データと既存レコードを対応付ける
7. 保留候補と権限条件を検証してから本台帳へ反映する

部署別の台帳から、同名の会社、同一法人の別支店、担当者が交代した行を取り出し、判定表に当てはめます。残す顧客ID・拠点ID・窓口IDが決まらない候補は、本台帳へ反映する前に保留します。保留理由と確定担当まで記録できれば、判断を次の担当者へ引き継げます。

自社の業務に合わせたWebアプリでは、受発注、申請承認、作業報告など、困っている業務一つから設計できます。初期開発と運用保守は個別見積もりで、連携、移行、権限、データ出力の範囲は契約前の確認が必要です。顧客IDの持ち方や名寄せの確定手順まで整理したい場合は、業務アプリの相談をご利用ください。