Amazon Entity Resolutionで日本語住所の表記揺れに対するマッチングを試してみた

本記事はアジアクエスト Advent Calendar 2025の記事です。

1. はじめに

最近「Customer 360」や「データ統合」といったワードをよく耳にします。
顧客データを複数のシステムで管理していると、同じ人が別々のIDで登録されてしまい、実は同一人物（企業）だったというケースがよくあります。

この課題を解決するための技術が Entity Resolution (ER) です。
AWSには、これを簡単に試せる Amazon Entity Resolution というサービスが提供されています。

この記事では、

• Amazon Entity Resolutionとは何か
• どんなことができるのか
• 実際に触ってみて得られた知見 をまとめます。

2. Entity Resolutionとは

一言で言うと、 似ているレコードを同じ人物としてまとめる技術 です。

例えば、同じ人物がシステムによって異なる表記で登録されているケースはよくあります。 システムAには「田中太郎」、システムBには「TANAKA TARO」と登録されている場合などです。 また、システムが変わればデータベースのカラム名も変わることがあり、 システムAでは「first_name」と「last_name」、システムBでは「full_name」といった違いもあります。

システムA（顧客マスタ）

システムB（会員マスタ）

Entity Resolutionでは、これらを「同じ人」として扱えます。

また、日本語住所でも表記揺れはよくあります。

• 「東京都港区芝公園1-1-1」
• 「東京都港区芝公園１丁目１番１号」
• 「東京都港区芝公園1-1-1」

人が見れば同じ場所ですが、システム的には異なる文字列として扱われます。 Entity Resolutionはこうした表記の違いを吸収して、同じ住所だと判断してくれます。

3. やってみたこと

1. ユーザ情報のマッチング

AWSから公式に提供されているリポジトリを使用して、Entity Resolutionを使ったユーザ情報のマッチングを試してみました。 実際の開発現場では、ユーザ情報に日本の住所が含まれることがよくあります。日本の住所は表記揺れが多いため、そのマッチング精度がどれほどかを検証しました。

テスト用ダミーデータ準備

とある企業のシステムA（顧客マスタ）とシステムB（会員マスタ）に登録されているユーザデータを模したテスト用ダミーデータを「住所なしVer」と「住所ありVer」で作成しました。 レコード数はそれぞれ1000件ずつで、600件/1000件は両方のテーブルに同一人物のデータを入れて、マッチングの精度を検証できるようにしました。 今回の検証では、この600件のうち何件を正しくマッチングできるかを確認します。 また、2つのテーブル構造も異なるように作成し、データには意図的に表記揺れを加えています。 特に日本の住所は表記揺れが大きいため、以下のようなパターンについてもテストデータに含めました。

• 番地の「-」と「丁目」「番」「号」の有無
• 全角と半角の違い
• 大字の有無
• 都道府県がある場合とない場合（例:福岡市中央区天神と福岡県福岡市中央区天神）
• 漢数字の表記方法の違い（例:福岡市中央区高雄一−二三ー三五と福岡市中央区高雄一−二十三ー三十五）

それぞれのテーブルの構造は以下の通りです。（テスト用ダミーデータは機械的に作成しているため、住所が本来存在しないはずの住所になっているのはご了承ください）

システムA（顧客マスタ）

システムB（会員マスタ）

スキーママッピングの定義

次にスキーママッピングを定義します。 スキーママッピングとは、各フィールドがどのような意味を持つかを指定するものです。 以下に住所ありVerのCDKでの定義例を示します。

// システムA（顧客マスタ）
    this.mainAddrSchema = new CfnSchemaMapping(this, 'MainBrandCustomerAddrSchema' + SCHEMA_VERSION, {
        schemaName: `${stackName}MainBrandCustomerAddr${SCHEMA_VERSION}`,
        mappedInputFields: [
            { fieldName: 'customer_id_a',    type: 'UNIQUE_ID',     matchKey: 'customer_id' },
            { fieldName: 'email',            type: 'EMAIL_ADDRESS', matchKey: 'email' },
            { fieldName: 'fullname',         type: 'NAME',          matchKey: 'fullname' },
            { fieldName: 'fullname_kana',    type: 'NAME',          matchKey: 'fullname_kana' },
            { fieldName: 'fullname_romaji',  type: 'NAME',          matchKey: 'fullname_romaji' },
            { fieldName: 'phone',            type: 'PHONE_NUMBER',  matchKey: 'phone' },
            { fieldName: 'birthdate',        type: 'DATE',          matchKey: 'birthdate' },
            { fieldName: 'gender',           type: 'STRING',        matchKey: 'gender' },
            { fieldName: 'address',          type: 'STRING',        matchKey: 'address' },
            { fieldName: "gold_person_id", type: "STRING" },
        ],
        });

    // システムB（会員マスタ）
    this.subAddrSchema = new CfnSchemaMapping(this, 'SubBrandCustomerAddrSchema' + SCHEMA_VERSION, {
      schemaName: `${stackName}SubBrandCustomerAddr${SCHEMA_VERSION}`,
      mappedInputFields: [
        { fieldName: 'customer_id_b',    type: 'UNIQUE_ID',     matchKey: 'customer_id' },
        { fieldName: 'email',            type: 'EMAIL_ADDRESS', matchKey: 'email' },
        { fieldName: 'family_name',      type: 'NAME', subType: 'LAST_NAME',  matchKey: 'fullname' },
        { fieldName: 'given_name',       type: 'NAME', subType: 'FIRST_NAME', matchKey: 'fullname' },
        { fieldName: 'family_name_kana', type: 'NAME',          matchKey: 'fullname_kana' },
        { fieldName: 'given_name_kana',  type: 'NAME',          matchKey: 'fullname_kana' },
        { fieldName: 'fullname_romaji',  type: 'NAME',          matchKey: 'fullname_romaji' },
        { fieldName: 'phone',            type: 'PHONE_NUMBER',  matchKey: 'phone' },
        { fieldName: 'birthdate',        type: 'DATE',          matchKey: 'birthdate' },
        { fieldName: 'gender',           type: 'STRING',        matchKey: 'gender' },
        { fieldName: 'address',          type: 'STRING',        matchKey: 'address' },
        { fieldName: "gold_person_id", type: "STRING" },
      ],
    });

Amazon Entity Resolutionでは、matchKeyとして指定されたフィールドを使ってマッチングを行います。

上記の例でいくと、

• システムA（顧客マスタ)のcustomer_id_aとシステムB（会員マスタ）のcustomer_id_b
• システムA（顧客マスタ)のemailとシステムB（会員マスタ）のemail

などをマッチング対象として扱い、 これらのフィールドが似ているレコードを同じ人物としてマッチングします。

           { fieldName: 'customer_id_a',    type: 'UNIQUE_ID',     matchKey: 'customer_id' },
            { fieldName: 'customer_id_b',    type: 'UNIQUE_ID',     matchKey: 'customer_id' },

そして下のようにoutputを定義することで、マッチング結果に含めるフィールドを指定できます。

      outputSourceConfig: [
        {
          outputS3Path: `s3://${dataStorage.dataBucket.bucketName}/${this.outputPrefixNoAddr}`,
          output: [
            { name: 'customer_id_a' },
            { name: 'customer_id_b' },
            { name: 'fullname' },
            { name: 'family_name' },
            { name: 'given_name' },
            { name: 'email' },
            { name: 'phone' },
            { name: 'birthdate' },
            { name: 'gender' },
            { name: 'gold_person_id' },
          ],
        },
      ],

gold_person_idは同一人物には同じidを振っています。 そのため、出力のみ利用し、マッチングキーには含めていません。

マッチングアルゴリズムの選定

Amazon Entity Resolutionでは、マッチングアルゴリズムとして以下の2つが選べます。

• ルールベースマッチング（RULE_BASED）
• 機械学習マッチング（ML_MATCHING）

今回は住所の表記揺れなどに対応するために、機械学習マッチングを選びました。 設定は以下のように行いました。

    resolutionTechniques: { resolutionType: 'ML_MATCHING'},

精度検証・評価

上記のような設定でマッチングを実行しました。

以下に住所ありVerのマッチング結果の一部を示します。（一部マスキングしています）

ConfidenceLevelはマッチングの確信度を示す値で、0から1の範囲で表され、1に近いほど、マッチングが正しいと確信していることを示します。 上に示したレコードは、どれも0.99以上の高い確信度でマッチングされていることがわかります。
MatchIDはマッチングされたレコードのペアを識別するためのIDで、この4つのレコード(2ペア)はそれぞれ同じMatchIDを持つため、同じ人物としてマッチングされたことがわかります。

マッチングの精度はRecall,Precision,F1-scoreで評価しました。 一言で簡単に説明すると、

• Recall: 高いほど拾い漏れが少ない
• Precision: 高いほどマッチングミスが少ない
• F1-score: 高いほど全体的に精度が高い です。 それぞれの詳細な説明についてはAccuracy Recall Precision F1スコアによる評価を参照してください。

住所なしVer/住所ありVerの2パターンのそれぞれの結果は以下です。

住所なしVer

住所ありVer

両方ともに非常に高い精度が出ました。 今回の検証では日本の住所の表記揺れによって、どれくらいマッチング精度が変わるかを確認したかったのですが、 住所以外のカラムのマッチング精度が非常に高かったため、住所の有無による差は出ませんでした。 そこで、住所のカラム以外についても表記揺れを大きくなるようにテストデータを作成し直し、住所の有無によりどれくらいマッチングの精度に差が出るのかを確認しました。 結果は以下の通りです。

住所なしVer

住所ありVer

住所カラムを追加することで、日本語の住所特有の表記揺れによりマッチング精度が下がることが確認できました。 数値について考察してみると、 Recallが下がった理由としては、同じ人物であるにもかかわらず、日本語住所の表記揺れがあるため、別人物として扱われてしまったケースが増えたためと考えられます。 Precisionが上がった理由としては、住所カラムを追加することで、完全に別の人物と判断されるケースが増えたためと考えられます。

2. 日本語住所に特化したデータマッチング

ユーザ情報のマッチングでは、住所以外にも多くの特徴量を使ってマッチングを行うため、住所の表記揺れの影響は小さくなります。 しかし、顧客企業のマスタデータなどを統合したいケースでは、住所以外の特徴量が少なく、住所の影響が大きい場合も考えられます。 そこで、次に会社名と住所のみを使ったマッチングを試してみました。

テスト用ダミーデータ準備

先ほどと同じ要領で、会社名と住所のみを持つテスト用ダミーデータを作成しました。 レコード数はそれぞれ1000件ずつで、600件/1000件は両方のテーブルに同一企業のデータを入れて、マッチングの精度を検証できるようにしました。 具体的なテーブル構造は以下の通りです。

システムA（企業マスタ）

システムB（取引先マスタ）

今回は以下のようなパターンでテストデータを作成しています。

パターン1: 会社名と住所の揺れがある場合
会社名には以下のような表記揺れを入れています。

• 「グロースデザイン98」
• 「グロースデザイン98(株)」

住所には以下のようなパターンで表記揺れを入れています。

• 「大字」の有無

  • 福岡市中央区大字天神
  • 福岡市中央区天神

• 都道府県の有無

  • 福岡市中央区天神
  • 福岡県福岡市中央区天神

• 漢数字の表記方法の違い

  • 福岡市中央区高雄一−二三ー三五
  • 福岡市中央区高雄一−二十三ー三十五

• 記号の全角/半角、文字違い

  • 福岡市中央区天神1−2‐3
  • 福岡市中央区天神1ー2ー3

パターン2: 会社名の表記揺れのみ
こちらはパターン1のテストデータに対して、住所の表記揺れをなくしたパターンです。

精度検証・評価

実験1: パターン1のデータを使用してマッチングを試す

まずは、パターン1の会社名と住所の両方に表記揺れがある場合において、マッチングを試しました。 結果は以下の通りです。

前回のユーザ情報のマッチングと比べると、非常に精度が低いことがわかります。 原因としては明白で以下のような理由が考えられます。

• 会社名と住所の2つのカラムしかないため、マッチングに使える情報が少ない
• 住所の表記揺れが非常に多いため、同じ住所であると認識されないケースが多い

また実際のマッチング結果を確認したところ、以下のようなケースが多く見られました。

• 住所が完全に異なるにも関わらず、会社名が似ているもしくは同じであるため、誤ってマッチングされてしまったケース
• 会社と住所が同じにも関わらず、会社名の表記揺れによりマッチングされなかったケース

感想として、ほとんどが会社名だけで判断されている印象で、どれだけ住所が異なっていたとしても会社名が同じであればマッチングされてしまうように感じました。

この原因として考えられるのがスキーママッピングの設定です。

        this.companyAddrSchema = new CfnSchemaMapping(this, 'CompanyAddrSchema' + SCHEMA_VERSION, {
            schemaName: `${stackName}CompanyAddr${SCHEMA_VERSION}`,
            mappedInputFields: [
                { fieldName: 'company_id',      type: 'UNIQUE_ID',     matchKey: 'company_id' },
                { fieldName: 'company_name',    type: 'NAME',          matchKey: 'company_name' },
                { fieldName: 'company_address', type: 'STRING',        matchKey: 'company_address' },
            ],
        });

私は上記のような設定を行いましたが、住所をSTRING型で定義しているため、正規化が十分に行われていない可能性があります。Amazon Entity Resolutionでは、住所をADDRESS型で定義することも可能なため、ADDRESS型で定義した場合にどれくらい精度が変わるのかを試してみる価値はあると思いました。

実験2: 住所のtypeをADDRESS型に変更する

次に住所のtypeをSTRING型からADDRESS型に変更してマッチングを試しました。

            mappedInputFields: [
                { fieldName: 'company_id',      type: 'UNIQUE_ID',     matchKey: 'company_id' },
                { fieldName: 'company_name',    type: 'NAME',          matchKey: 'company_name' },
                { fieldName: 'company_address', type: 'ADDRESS',       matchKey: 'company_address' },
            ],

結果は以下の通りです。

実験1と比較すると、RecallもPrecisionも向上しました。 Entity Resolutionの内部がどのように動いているかはブラックボックスのため、正確な理由はわかりませんが、 しかし、公式ドキュメントに「ADDRESS型は住所の正規化に役立つ」と記載されていることから、ADDRESS型による定義によって住所の表記揺れが正規化され、精度向上につながったと考えられます。 逆に言えば、今まで使用していたSTRING型では住所の正規化が不十分であったか、あるいは住所情報がマッチング要素として重要視されず、主に会社名だけで判断されていた可能性も考えられます。

マッチングが失敗した箇所も何が原因で失敗しているのかを確認しました。

最もRecall率が低いのは「漢数字の違い」でした。また、大字の有無、都道府県の有無もRecall率が低いことがわかります。 これらの結果から、ADDRESS型で定義した場合としても、住所の正規化を完全に行うことはできず、住所の表記揺れによってマッチングが失敗するケースが多いことがわかります。

実験3: 住所の正規化を行う

次にパターン2の会社名の表記揺れのみを持つテストデータを使ってマッチングを試しました。 実際の開発現場では住所揺れを完全に無くすことはなかなか難しいですが、生成AIの力を借りて、住所の完全な正規化(システムAの住所とシステムBの住所を一致させる)を行い、マッチングを試しました。 結果は以下の通りです。

実用可能なラインに乗ってきた印象です。 ただConfidenceLevelを確認したところ、ほとんどが0.6程度でマッチングされていました。これは、ユーザ情報の統合の際に記録した0.99以上という高いConfidenceLevelと比較すると、特徴量が少ない場合のマッチングには、まだまだ課題が多いと感じました。

4. まとめ

今回初めてAmazon Entity Resolutionを触ってみましたが、非常に簡単にデータマッチングが試せることがわかりました。 当初、住所の表記揺れによる精度を懸念していましたが、他のカラムが一致すれば、想定以上に高い精度でマッチングが可能であることも確認できました。 日本語の住所揺れは非常に複雑なので、実際に高いマッチング精度を出せるかは実データで試す必要がありますが、PoCや検証には十分使えるサービスだと感じました。 また、今回は試しませんでしたが、データの正規化やルールベースファジーマッチングなどを使うことで、さらに精度を上げられる可能性もあると思いますので興味のある方はぜひ試してみてください。

なお、本記事の検証結果はあくまでサンプルデータを用いた一例であり、すべてのケースで同様の結果を保証するものではありません。特にML系のマッチングはデータの特性や前処理方法に強く依存するため、実際のユースケースに適用する際には、必ずご自身のデータで検証することをおすすめします。

参考

• Amazon Entity Resolution とは - Amazon Entity Resolution
• AWS Entity Resolution の機械学習を用いたマッチングを試してみました
• AWS Entity Resolution【AWS Black Belt】
• Accuracy Recall Precision F1スコアによる評価
• AWS Entity Resolution の高度なルールベースファジーマッチングを使用して不完全なデータを解決する