AWS Entity Resolution

解決する課題

同じ顧客の情報が、CRM・購買履歴・問い合わせ・マーケティングツールなど複数のシステムにバラバラに存在することはよくあります。「田中 太郎」と「田中太郎」、表記ゆれのあるメールアドレスや住所が同じ人物を指しているかどうかを判定し、ひとつのエンティティとしてまとめる作業は、いわゆる名寄せ・突き合わせ（マッチング）と呼ばれます。これを自前で作ると、表記の正規化や照合ロジック、機械学習モデルの整備に大きな工数がかかります。AWS Entity Resolution は：

• 複数ソースに散らばったレコードを、ルールベースまたは機械学習ベースの手法で照合し、同一エンティティを束ねる
• データを中央に集約せず、S3 などに置いたまま読み取ってマッチング結果を生成するため、データの所在を保ちやすい
• 自社データ同士の突き合わせに加えて、サードパーティのデータプロバイダーとの照合メニューも提供し、属性の補完や統合を支援する

「重複した顧客レコードを名寄せしたい」「複数システムをまたいで一人の顧客像を作りたい」という要件に向きます。

主要概念と用語

• マッチングワークフロー: 入力データの読み取りから照合、結果の出力までを定義する一連の処理。どのソースを、どの手法で、どこへ出力するかを設定する
• スキーママッピング: 入力データの各列が、氏名・メール・住所・電話番号などのどの属性タイプに当たるかを対応づける定義。照合精度はこのマッピング品質に依存する
• ルールベースマッチング: ユーザーが定義した一致条件（例: メールが完全一致、氏名と住所が一致など）に基づいて突き合わせる決定的な手法
• 機械学習マッチング: あらかじめ用意されたモデルを使い、表記ゆれや部分的な一致を含めて確率的に同一エンティティを推定する手法
• データプロバイダーサービス（サードパーティ照合）: AWS Data Exchange 経由などで提供される外部データと突き合わせ、属性を補完・照合するメニュー
• マッチID（一致グループID）: 同一エンティティと判定されたレコード群に割り当てられる識別子。これを使って横断的にレコードを名寄せできる
• 入力ソース / 出力先: 照合の対象となる S3 上のデータや Glue テーブルと、結果を書き出す先

仕様・制限・クォータ

• 入力は主に S3 上のデータで、列と属性タイプの対応はスキーママッピングで定義する
• 照合方式は、ルールベース・機械学習ベース・サードパーティのデータプロバイダー照合といったメニューから選ぶ
• 出力には、レコードに割り当てられた**マッチID（一致グループID）**が付与され、これを使って名寄せ結果をたどれる
• マッチングワークフロー数、1ワークフローあたりの入力ソース数、処理できるレコード件数などにサービスクォータがあり、必要に応じて引き上げを申請できる
• 変動しうる上限値や対応リージョンは更新されるため、最新の値は公式ドキュメントで確認する

内部の仕組み

Entity Resolution は、データを保管・複製するのではなく、入力データを読み取って照合し、一致グループの識別子を付けて返す処理層として動作します。

• スキーママッピングで各列を属性タイプへ対応づけ、氏名・メール・住所などを照合に使える形に正規化する
• マッチングワークフローが入力ソースを読み取り、選択した手法（ルール／機械学習／サードパーティ照合）でレコード同士を突き合わせる
• ルールベースでは定義した一致条件を順に評価し、機械学習ベースでは確率的に同一エンティティらしさを推定する
• 同一と判定したレコード群へマッチIDを割り当て、結果を S3 などの出力先へ書き出す

設計パターン / ベストプラクティス

• ルールベースから始める: まずはメール完全一致など説明しやすい決定的ルールで土台を作り、取りこぼしを機械学習で補う
• 属性の正規化を前段に: Glue などで大文字小文字・全角半角・空白の正規化を済ませてから投入し、照合の安定性を高める
• 段階的なルール設計: 強い一致条件から弱い条件へ優先度をつけて評価し、誤って別人をまとめないようにする
• 結果の検証ループ: マッチIDの結果をサンプリングして人手で確認し、過剰一致・過小一致を見ながらルールやマッピングを調整する
• サードパーティ照合は目的を絞る: 外部データとの突き合わせは属性補完など狙いを明確にし、必要な範囲に限定する

運用・監視

• マッチングワークフローの実行や設定変更などの操作は CloudTrail で監査できる
• ワークフローの実行状況や処理件数を確認し、想定どおりの件数が照合・出力されているかを定期的に点検する
• スキーママッピングと照合ルールの対応関係をドキュメント化し、どの属性で何を一致とみなすかを明確にしておく
• 入力データの傾向が変わったときは、照合結果の品質が落ちていないかを再評価する

コスト

• 課金は主に、処理したレコード件数など照合の処理量に応じて発生する
• 機械学習ベースの照合やサードパーティのデータプロバイダー照合は、手法に応じた費用が加わる
• 入力元・出力先となる S3 のストレージや、テーブル定義を管理する Glue データカタログなど周辺サービスの利用量も合わせて見積もる
• 変動しうる単価や課金区分は更新されるため、最新の料金は公式の料金ページで確認する

セキュリティ

• データを中央に集約せず、S3 などに置いたまま読み取るため、データの所在と統制を保ちやすい
• 入力・出力データへのアクセスは IAM ロールで制御し、ワークフローに必要最小限の権限だけを与える
• 保管時の暗号化は S3 と KMS、通信は TLS で保護し、操作監査は CloudTrail で行う
• 氏名・メール・住所などの個人情報を扱うため、照合の目的と利用範囲を明確にし、出力先のアクセス権限も絞る
• サードパーティ照合を使う場合は、外部データの取り扱い条件と社内のデータガバナンス方針との整合を確認する

関連サービス・比較

データの突き合わせという点で AWS Clean Rooms とよく対比されます。Clean Rooms は組織をまたいで生データを開示せずに共同分析する場であるのに対し、Entity Resolution は自社が統制するレコードの名寄せ・統合そのものに焦点を当てる点が異なります。

ハンズオン / CLI例

# スキーママッピングを作成（列を属性タイプに対応づける）
aws entityresolution create-schema-mapping \
  --schema-name "customers-schema" \
  --mapped-input-fields '[
    {"fieldName":"email","type":"EMAIL_ADDRESS"},
    {"fieldName":"full_name","type":"NAME"},
    {"fieldName":"id","type":"UNIQUE_ID"}
  ]'

# ルールベースのマッチングワークフローを作成
aws entityresolution create-matching-workflow \
  --workflow-name "customer-dedup" \
  --input-source-config '[{"inputSourceARN":"arn:aws:glue:ap-northeast-1:111122223333:table/db/customers","schemaName":"customers-schema"}]' \
  --output-source-config '[{"outputS3Path":"s3://my-bucket/er-output/"}]' \
  --resolution-techniques '{"resolutionType":"RULE_MATCHING"}' \
  --role-arn arn:aws:iam::111122223333:role/EntityResolutionRole

# ワークフローを実行して名寄せを開始
aws entityresolution start-matching-job \
  --workflow-name "customer-dedup"