「名寄せ」の試行検証(1)- 汎用アルゴリズムを活用した氏名の照合

 
重要:個人情報や機密情報の使用に関する注意喚起(必ずお読みください)
 当検証で紹介している技術やサービスの使用は、読者の皆様自身の判断と責任で行ってください。特に、個人情報や機密情報を含むデータの取り扱いについては、最大限の注意を払い、適切なセキュリティ対策を講じることが不可欠です。
 検証や実際の利用を行う際には、常にプライバシー保護の法律、規制、およびベストプラクティスを遵守するよう心掛けてください。また、第三者のデータを使用する場合は、必要な同意を得ること、及びそのデータの使用が法律に準じていることを確認することが重要です。
 本ブログや筆者、所属する団体は、紹介する技術を用いて行われるいかなる活動から生じる直接的または間接的な損害に対して、責任を負いかねます。技術を使用することによって生じ得るリスクを理解し、自己の責任で慎重にご活用ください。
 ご不明点や懸念がある場合は、クラウドベンダーや専門家に相談することをお勧めします。
 当検証の情報を活用することで、読者の皆様が新たな知識やスキルを安全に身に付け、ビジネスでの活用をすすめていただければ幸いです。
 
 
本解説の対象領域
本解説の対象領域

データ分析基盤における名寄せ

 データ分析基盤における名寄せは、異なるデータソースやデータセットに存在する同一のエンティティ(例:人物、組織、商品)に関連するレコードを識別し、統合するプロセスです。

名寄せの目的

 
データ分析基盤における名寄せは主に次の目的で行われます。
  1. データの一貫性の確保  異なるデータソースから収集された情報を統合することで、データの一貫性と完全性を保証します。これにより、正確な分析と意思決定をサポートします。
  1. 顧客管理の最適化   顧客データの名寄せにより、顧客の360度ビューを実現し、顧客満足度の向上やマーケティング戦略の最適化につながります。
  1. 法的・規制上の要件への対応  個人情報保護やデータガバナンスの観点から、データの正確性と一貫性の確保は法的な要件を満たすために重要です。
  1. 分析ユーザーの負荷軽減  分析ユーザーは多様なデータソースからデータを取得して分析しますが、全社データ分析基盤に存在するデータは、事前に適切に正規化し、名寄せを行っておくことで、分析ユーザーの前処理の負担を軽減し、分析の精度と効率を向上させることができます。
 

名寄せの手順

 
名寄せは次の手順行います。
  1. データの正規化 マッチング対象となるデータ(氏名、住所、性別、生年月日、メールアドレス、など)を同一の形式に統一します。
  1. 類似度の測定 マッチング対象の類似度(=同一人物である可能性を示すメトリクス)を測定します。
  1. 名寄せ可否の判定 類似度の測定結果を基に、システムまたは人的な判断や調査を通じて、名寄せを行うかどうかの総合判定を行います。

名寄せの実施例

 本テーマでは、サンプルデータを用いて汎用的なアルゴリズムやWEB-APIを活用した名寄せを実装することで、その可能性、課題、問題点を明らかにします。

サンプルシナリオ

 サンプルで使用するシナリオは次の通りです。
  • A社は現在、自社サイトで運営中のスポーツ用品を扱うECサイトを通じて顧客情報を保有しています。 保有しているデータのサンプルは次の通りです。名寄せには姓、名、住所を使用します。姓、名とも読み仮名は保持していません。
    • 顧客コード(A-CD)姓(A-LN)名(A-FN)住所(A-AD)
      001鈴木太郎東京都新宿区歌舞伎町1-4-1
      002菅野幸子東京都千代田区九段南1丁目2−1
  • A社は海外メーカーの製品を顧客に直送するアメリカのB会社を買収しました。この会社には日本人顧客も多く含まれており、顧客属性や購買履歴を360度ビューで分析するために、これらの情報を統合したいと考えています。 保有している顧客データのサンプルは次のものを使用します。名寄せには姓、名、住所を使用します。
    • 顧客コード(B-CD)姓(B-LN)名(B-FN)住所(B-AD)
      100SuzukiTarou1-17-1 Chuohonmachi, Adachi-ku, Tokyo
      101SuganoYukico1-2-1 Kudanminami, Chiyoda-ku, Tokyo
  • サンプルの2名「鈴木太郎」と「Suzuki Tarou」、「菅野幸子」と「Sugano Yukico」が同一人物であるか確認するプロセスを検証します。
 
本テーマ「「名寄せ」の試行検証」は、次の3回に分けて投稿します。
(1)汎用アルゴリズムを活用した氏名の照合(本投稿)
(2)WEB-APIを活用した住所の照合
(3)名寄せの結果と、可能性、課題、問題点
 
本投稿は(1)として、汎用アルゴリズムを活用した氏名の照合を行います。

データの正規化

 まず、名寄せプロセスの第一段階であるデータの正規化を行います。B社のデータが英語であることから、A社の日本語のデータをB社の英語のデータに寄せる方針で正規化を実施していきます。

氏名の正規化

  • A社顧客氏名の正規化
      1. 漢字→カナ文字候補
        1.  A社の顧客氏名は日本語(漢字)表記であるため、まずはそれらの読み方を明らかにする必要があります。漢字氏名には同じ漢字で複数の読み方が存在する場合がありますので、初めに読み仮名の候補を抽出します。
           読み仮名を抽出するためのツールとして、「Mecab」を使用します。Mecabはビグラム(bi-gram)マルコフモデルに基づく実績のある形態素解析エンジンですが、今回は形態素解析の用途ではなく、Mecabの辞書もとに氏名をカタカナに変換する目的で使用します。
      1. カナ文字候補→ローマ字(ヘボン式)
        1.  1でカナ文字変換した氏名をさらにローマ字に変換します。この変換にはPythonライブラリの「pykakasi」を使用します。
           
      この変換を行うためのPythonのサンプルコードです。
      Input file(cust_a.csv)
      Python source(normalizeCustA.py)
      Output file(cust_a_norm.json)
       
       上記の結果から、A-CD="001"の「鈴木 太郎」さんのローマ字名は「suzuki tarou」と一意に決定しました。一方、A-CD="002"の「菅野 幸子」さんに関しては、姓の「菅野」が「kanno」と「sugano」、名の「幸子」は「sachiko」と「yukiko」がそれぞれ候補となり、4パターンの氏名の選択肢が出現しました。
       下表は、出力されたデータを表形式で表現したものです。
      A-CDA-LNA-FNA-LN_KANAA-FN_KANAA-LN_ROMAA-FN_ROMA
      001鈴木太郎スズキタロウsuzukitarou
      002菅野幸子カンノサチコkannosachiko
      002菅野幸子カンノユキコkannoyukiko
      002菅野幸子スガノサチコsuganosachiko
      002菅野幸子スガノユキコsuganoyukiko
      A社の顧客データの氏名の正規化はここまでとします。
       
  • B社顧客氏名の正規化
    •  
      顧客コード(B-CD)姓(B-LN)名(B-FN)住所(B-AD)
      100SuzukiTarou1-17-1 Chuohonmachi, Adachi-ku, Tokyo
      101SuganoYukico1-2-1 Kudanminami, Chiyoda-ku, Tokyo
       次にB社のデータを正規化します。A社の正規化後のデータ(ローマ字、ヘボン式、小文字のみ)と照合しますが、B社のデータは先頭が大文字のため、ここでは小文字に正規化する処理を行っておきます。
       
      この変換を行うためのPythonのサンプルコードです。
      Input file(cust_b.csv)
      Python source(normalizeCustB.py)
      Output file(cust_b_norm.json)
       
       下表は、出力されたデータを表形式で表現したものです。
      B-CDB-LNB-FNA-LN_ROMAA-FN_ROMA
      001SuzukiTarousuzukitarou
      002SuganoYukicosuganoyukico
      B社の顧客データの氏名の正規化はここまでとします。

類似度の測定

 類似度の測定に3つの尺度を指定します。
  1. レーベンシュタイン距離  レーベンシュタイン距離(Levenshtein distance)、または編集距離(edit distance)は、二つの文字列間の類似度を測定するために使用されるメトリックです。この距離は、一方の文字列を他方の文字列に変換するために必要な最小の単一文字編集(挿入、削除、置換)の数として定義されます。(以下、L距離)
  1. ジャロ・ウィンクラー距離  ジャロ・ウィンクラー距離(Jaro-Winkler distance)は、二つの文字列間の類似度を測定するために使用されるメトリックです。この距離は、ジャロ距離(Jaro distance)をベースにしており、文字列の先頭部分が一致している場合に類似度スコアを増加させる拡張が加えられています。(以下、J距離)
  1. ダブルメタフォン (Double Metaphone)符号化の比較  ダブルメタフォン (Double Metaphone)は、英語の単語や名前をその発音に基づいて符号化するアルゴリズムです。ここでは、符号化された氏名のL距離を計測することにより、名前の類似性を評価します。(以下、DM距離)
A社とB社の氏名を上の3つの距離で測定します。
測定を行うためのPythonのサンプルコードです。
Input file(cust_a_norm.csv)
 
Input file(cust_b_norm.csv)
 
Python source(calculateNamesDistance.py)
 
Output file(calcResult.json)
 

名寄せ可否の判定

 
結果(氏名の必要部分のみ抜粋)は次の通りとなりました。
 
【列の説明】
列名説明
a-cdA社の顧客コード
b-cdB社の顧客コード
a-fullNmA社顧客の読み仮名(候補)をローマ字に変換・正規化した文字列
b-fullNmB社顧客の読み仮名を正規化した文字列
ldistレーベンシュタイン距離の値 0が完全一致、数値が大きいほど差異が多い
jdistジャロ・ウィンクラー距離 1が完全一致、数値が小さいほど差異が多い
a-dmCode(①)A社の顧客名をダブルメタフォン符号化した値
b-dmCode(②)B社の顧客名をダブルメタフォン符号化した値
dmDist①と②のレーベンシュタイン距離 0が完全一致、数値が大きいほど差異が多い
【結果】
Noa-cdb-cda-fullNmb-fullNmldistjdista-dmCodeb-dmCodedmDist
1001100tarou suzukitarou suzuki0(*1)1(*2)TRSSKTRSSK0(*3)
2001101tarou suzukiyukico sugano100.533761TRSSKAKKSKN4
3002100sachiko kannotarou suzuki120.463675SXKKNTRSSK5
4002101sachiko kannoyukico sugano90.701923SXKKNAKKSKN3
5002100yukiko kannotarou suzuki120.472222AKKKNTRSSK5
6002101yukiko kannoyukico sugano50.888462AKKKNAKKSKN1
7002100sachiko suganotarou suzuki100.47619SXKSKNTRSSK4
8002101sachiko suganoyukico sugano50.846986SXKSKNAKKSKN2
9002100yukiko suganotarou suzuki100.533761AKKSKNTRSSK4
10002101yukiko suganoyukico sugano1(*4)0.969231(*5)AKKSKNAKKSKN0(*6)
 
【総括】
No結果
1(*1)が0であり、(*2)が1であること、そして翻訳の候補が1つのみであることから、これらは同一の氏名とみなして問題ないと判定できます。
2~9いずれの指標も類似度が低く、同一の氏名と判定するには至りませんでした。
10(*4)が1であることと、(*5)の値が高いことから、類似性が認められます。名前のローマ字表記において、A社では「yukiko」と記録されているのに対し、B社では「yukico」とされているため、差異が生じています。一方で、発音に基づく判定指標である(*6)は一致しており、この候補は同一の氏名である可能性が極めて高いと判定できます。

(1)のおわりに

 
 今回は、日本語名と英語名を用いて照合の可否を検証しました。実際のケースではメールアドレス、住所、性別、生年月日など多様な要素を活用して照合の精度を高めることになります。
 次回(2)では、「住所」を対象にWEB-APIを活用して、日本語表記と英語表記の住所の照合を検証する予定です。