1. 質問と背景
この質問は、データエンジニアリングにおけるエンティティ解決（entity resolution）またはレコードリンケージ（record linkage）の能力を評価するものです。面接の公開課題として、複数のソースから得られるノイズの多い人物レコードの名寄せ（reconcile）を求め、正規化、競合解決、データ品質、適合率（precision）、再現率（recall）について掘り下げます。データプラットフォーム、マスターデータ管理、顧客データ統合などの職種に適した内容です。
2. 面接官がチェックしているポイント
- シグナルを選択する前に、「同一人物」の定義とビジネス上のエラーコストを明確にしているか。
- 候補生成（candidate generation）によって全ペア比較の処理量を削減し、ブロッキングによる再現率低下リスク（blocking recall risk）を説明できるか。
- 自動マージ、人手によるレビュー、不一致の各バンドを用いて誤ったマージを制御しているか。
- マスターの各フィールド選択において、ソース、根拠、バージョン履歴が保持されているか。
- 正解率（accuracy）の報告のみにとどまらず、ラベル付けされたペアを用いて適合率と再現率を評価しているか。
3. 最初に明確にすべき質問
- どのフィールドが安定した識別子ですか？メールアドレスや電話番号は検証済みですか？また、氏名には翻字（transliteration）やエイリアスが存在する可能性がありますか？
- 誤ったマージ（false merge）とマージ漏れ（missed merge）のどちらがよりコストが高いですか？結果はマーケティング、決済、コンプライアンス、サポートのいずれで使用されますか？
- これは過去データのバックフィルですか、それとも日次の増分ストリームですか？ソースから更新や削除のイベントは発行されますか？
- フィールドが競合した場合、どのソースが信頼されますか？レビュー担当者はすべての元の値とその来歴を確認できる必要がありますか？
4. 30秒で答える要約
まず、マッチングの単位、エラーコスト、監査可能な出力形式を定義します。フィールドを決定論的に正規化し、メール、電話番号、または複合キーを使用して候補ブロックを生成し、全ペアの総当たり比較を回避します。各候補に対して肯定的・否定的な根拠をスコアリングし、自動マージ、人手レビュー、不一致のしきい値を個別に設定します。ソースの信頼性、検証状態、鮮度に基づいてすべてのソース値を保持しながらマスターレコードを構築します。最後に、ラベル付きペアでキャリブレーションを行い、適合率、再現率、レビュー量を報告し、増分処理でのドリフトや誤ったマージを監視します。
5. ステップ別の解決策
ステップ 1: レコードの定義と正規化
すべての入力に対して、source、source_id、到着時刻、元の生フィールドを保持します。Unicode、大文字小文字、空白、句読点のルールに従って氏名を正規化します。メールアドレスはトリム処理して明確な大文字小文字ポリシーを適用し、電話番号は国番号付きの正規形式に変換します。正規化された値は、元の生データを上書きすることなく再現可能である必要があります。欠損値は「未知」を意味すべきであり、2つの空文字列が一致しているという根拠にしてはなりません。
ステップ 2: 候補の生成とマッチングのスコアリング
正規化されたメール、電話番号、または「氏名＋郵便番号」キーにインデックスを作成し、欠損データのパターンに応じて複数のブロッキングパスを実行します。次に、編集距離、共有フィールド、検証状態、否定的根拠を比較します。例えば、検証済みの異なる2つの電話番号がある場合、信頼度を下げる必要があります。ブロック内でスコアリングを行うことで、処理量は O(n²) ではなく候補数に近くなりますが、ブロッキングによるマッチ漏れはサンプリングして測定する必要があります。
ステップ 3: しきい値の設定と安全なマージ
スコアを自動マージ、人手レビュー、不一致の各バンドに分割します。ラベル付きの正例・負例ペアとビジネス上のエラーコストからしきい値を調整（キャリブレーション）します。自動マージごとにルールとスコアをログに記録し、競合するフィールドと根拠をレビュー担当者に提示し、却下理由を保持します。Union-Find や連結成分（connected components）を使用する場合は、弱いエッジの連鎖によって別人がマージされてしまうのを防ぎます。
ステップ 4: マスターレコードの構築と増分監視
検証済みソース、ビジネス上の優先順位、鮮度に基づいて各マスターフィールドを選択し、同時に来歴、以前の値、有効期間を保存します。新しいレコードは関連するブロックとのみ比較し、ソースやルールの変更後のリプレイ（再実行）をサポートします。定期的にレビュー結果をサンプリングし、ソース、言語、地域、時間枠ごとに適合率、再現率、レビュー率、コンポーネントサイズ、ドリフトを監視します。誤ったマージが増加した場合は、自動公開を一時停止し、影響を受けるキーを追跡します。
6. 優れた回答例
各入力を、生データと正規化された値に加えて、ソース、ソースキー、検証状態、イベント時刻を持つモデルとして設計します。説明可能なルールを使用して氏名、メール、電話番号を正規化し、メール、電話番号、氏名＋地域などの複数のブロックを通じて候補を生成します。候補スコアには、共有フィールド、編集距離、検証状態、競合ペナルティを組み合わせ、ラベル付きペアとビジネスコストで調整された自動マージ、人手レビュー、不一致のバンドを生成します。
マージ処理を単一の生き残り行に集約することはしません。各マスターフィールドには、選択されたソース、ルールバージョン、有効期間、破棄された値が保持されます。強固な根拠のみが連結成分を作成し、弱いエッジはレビューに回されます。オフライン評価では、適合率、再現率、F1スコア、レビュー率、誤ったマージの例を報告します。増分実行ではソースと時間枠のドリフトを監視するため、新しいソースを安全に追加でき、不適切なルールは追跡、分割、リプレイが可能です。
7. よくある間違い
- エイリアス、翻字、共有の連絡先、同姓同名を考慮せず、氏名の完全一致を同一性の証明として扱う。
- 候補生成について説明せず、またはブロッキングの再現率を測定せずに、すべてのペアを比較する。
- レビュー用バンドや競合ペナルティを設けずに、あいまい一致スコア（fuzzy score）をそのまま真実として扱う。
- 1つのマスター行のみを保持し、ソース値、ルールバージョン、根拠を破棄してしまう。
- 適合率、再現率、ビジネス重視のエラーを無視して、正解率（accuracy）のみを報告する。
- 1つの弱いエッジによって巨大な連結成分が形成され、不可逆な過剰マージ（over-merge）が発生するのを許してしまう。
8. フォローアップ質問
フォローアップ 1: 分類器（Classifier）を直接学習させないのはなぜですか？
十分なラベルがあれば、モデルはマッチングスコアを学習できますが、それでも説明可能な特徴量、しきい値の調整、人手によるレビュー、バージョン管理されたリプレイが必要です。ルール、モデル、レビュー担当者のすべてが、新しいソースやコンプライアンス上の質問に対応するための根拠を出力すべきです。
フォローアップ 2: 適合率と再現率のトレードオフをどのように取りますか？
誤ったマージとマージ漏れのコストを比較可能な客観的指標に換算し、検証セット上でしきい値曲線を検証します。決済やコンプライアンスでは通常、適合率を最優先で保護します。重複排除（deduplication）ではより高い再現率を許容する場合がありますが、いずれの場合もレビューとサンプリングは維持します。
フォローアップ 3: 過剰マージ（Over-merging）をどのように検知しますか？
コンポーネントサイズ、低スコアエッジの割合、ソース間の競合、手動分割率を監視します。異常に大きなコンポーネントに対しては根拠グラフを展開します。自動マージを一時停止し、影響を受けるエンティティをルールバージョンごとに分割して、増分結果をリプレイします。