日本には同姓同名・同誕生日の人がどれだけいるのだろうか？

（注: 以下にタイトルの答えはありませんのでご了承下さい。）
みなさまこんにちは。「名寄せ」という単語に背筋がゾワっと来る方がいらっしゃるかもしれません。この記事は名寄せ実務がほぼゼロの人間が取り掛かり始めて気づいた備忘録です。名寄せプロの方々から見れば常識すぎるかもしれませんが、ど素人が感じた闇深さを記録していきたいと思います。

動機

簡便的に個人名寄せをする際に使われる要素の第一位は「氏名」であることは、誰もが否定できないと思います。ところで、これを読んでいるあなたの、学生時代、社会人と人生を通じて、自分の同姓同名の方に出会うことはありましたでしょうか。私の苗字は苗字ランキング200位約10万人程度なので、ありませんでした。ネットで検索すると同姓同名の年配の方が1名いるようです。なお、対面で全く同じ生年月日の方は一人だけ出会ったことがありました。

なお、日本で一番多い同姓同名は 田中実 さんの5,700人らしいです。

さて、同姓同名・同生年月日についてですが、もし仮にマイナンバーのデータベースというものが存在していてアクセスできれば、雑な推計であれば次のようなクエリで瞬殺ですかね。

select 
   (full_name || cast(birthdate as text) as key
   count(full_name || cast(birthdate as text)) as _count
from maina_table_asof_yyyymmdd
group by 1
having _count > 1

もちろんこんなデータにアクセスできる人はいないので、となるとフェルミ推定の出番です。

名寄せムズいよ問題

まずは日経xtechのこの記事を読んでください。ここに名寄せの難しさの問題が凝縮されています。必読です。

また以下の記事を読んで、人名用漢字に興味を持たれたら、次のblogが大変面白いです。興味深く時間があっという間に過ぎていきます。

一般的に名寄せには個人情報４要素（氏名、生年月日、性別、住所）が使われますが、住所はそれだけで重い問題なので、本編では氏名と生年月日のみ言及していきます。なお住所の正規化は民間提供でいくつかコード体系&正規化があるのでそれを利用するか、経済産業省提供の IMIコンポーネントツール 住所変換コンポーネント を使うのが無難ではないかとの感想です（この領域に踏み入れたくない）。

氏名の名寄せの難しさ

1. 氏名（漢字表記）には旧字体や異字体や外字（鬼門の「渡辺」「斎藤」の表記揺れなど）が存在するため、入力者の非一貫性により、同一人物または本人による入力でも異なる入力がありうる。
2. データベース上、苗字・名前に分割して持つか、氏名だけで持っているか
3. 読み方（カタカナまたはひらがな）をデータで持っているか

一つ一つ関連するトピックを取り上げていきます。

1-1 下の名前も旧字体・異字体は法律上認められたものは使える。

苗字に関してはすでに多くの考察や言及があるので下の名前に関しての気づきを記していきます。

日本の法律上で下の名前に使える文字は、以下のように常用漢字といわゆる人名漢字に限定されています。なので旧字体や異字体の心配はないです。とは 全く言えません。

戸籍法施行規則第60条において、①常用漢字表（平成22年内閣告示第２号）に掲げる漢字（括弧書きが添えられているものについては、括弧の外のものに限る。）、②別表第二に掲げる漢字、③片仮名又は平仮名（変体仮名を除く。）、と規定されています

出所 https://houseikyoku.sangiin.go.jp/column/column057.htm

私自身完全に勘違いしていたことであり、いわゆる旧字体や正字の文字も登録されています。
次のサイトにあるように「櫻子」の「櫻」は、実際に人名漢字表に記載されています。

出所: 人名用漢字表（別表第二 漢字の表（第六十条関係）
https://www.moj.go.jp/MINJI/minji86.html

1-2 人名登録漢字は、法規則の改正により変更され続けている。

人名に使える「凜」「凛」について、実は最近登録され利用可能となった漢字なので、年配の方には存在しないはずです（戦前までは調査していません）。

旧字の「凜」は、平成2年3月1日の戸籍法施行規則改正で、人名用漢字になりました。新字の「凛」は、平成16年9月27日の戸籍法施行規則改正で、人名用漢字になりました。

さらにややこしいことに ちなみに「凛」と「凜」は、実は新字旧字の関係ではないのですが、 とあり、もはや踏み入れたくない領域です。（正確には正字・俗字の関係）

なお戸籍上使える漢字の検索は法務省が用意していますので、こちらで確認できます。
https://houmukyoku.moj.go.jp/KOSEKIMOJIDB/M01.html

変体仮名は使えないが、次の6つは使える

「ヰ」、「ヱ」、「ヲ」、「ゐ」、「ゑ」、「を」は、ひながら、カタカナに含まれます。

とのことです。超高齢のおばあちゃんなどでたまに見かけたりするくらいではないでしょうか。うかつに入力validationで弾いてはいけません。

2-1 氏名のデータの持ち方

余談ですが、氏、姓、名字、苗字の違いを理解していますでしょうか。私は今でもググって調べないと人には説明できるほど理解はできていません。特にオチも示唆もないので進みます。

まず、氏名の入力には氏名を一つのinputboxで入力と、氏名を二つのinputboxで入力するケースがあると思います。それに対応してデータ側も氏名で1カラムの場合と氏で1カラム名で1カラムの場合の二通あると思います。

	proc	cons
氏名一つ	外国人等のイレギュラーも対応可能	氏と名の区切り文字を必要とするか
氏名分割	ほぼ大多数で問題なし	名字のない国の人やミドルネーム持つ人などが入力迷う

一般的な日本のサービスでは、氏名分割の入力inputでデータベース側も姓・名で分割しているケースが多いのではないでしょうか。一方でUXの観点からは分割せず一つが良いという意見が最近では上がってきています。氏名一つ入力の際は、氏名の区切り（たいていは全角空白）を入れるサービス（もちろんフロント側で半角空白を全角に変換やvalidation必須）も多いと思います。

参考資料

3-1 ヨミガナの有無。

ヨミガナのデータが存在する場合は、一次スクリーニングとしてヨミガナ（フルネーム）&生年月日をkeyとすれば、異字体問題も吸収できると思います。また、サービス管理上のユーザー検索でも使えるので、カスタマーサポート等での利便性は上がります。

余談1

氏名分割の場合、プログラミングの変数やデータベースカラム名で first_name last_name ではなく family_name given_name としておくのが無難との意見もあります。国際化時代において first が何を指すかは文化によって異なるので。

余談2

外国人の名前ってどうするの問題。住民票は原則アルファベットだが、漢字圏出身者は漢字も併記できるらしい。アルファベットって全角半角どうする問題だが、住民基本台帳は全角なのでそれに寄せておくのがよさそう。マイナ表記でも姓名に全角空白一文字入っているので、これに準じるのが無難っぽい。

疑問1: 全角アルファベットは英語26文字のみに制限なのか。全角制限であれば全角キリル文字も受け入れられる？
疑問2: 中華圏の簡体字、繁体字は原則常用漢字への変換らしいがどこまで守られる？（日本語に存在しない簡体字はどうするんだ？）

参考資料

その他: 入力者の意図なのか偶発なのかは判別できない。

サービスによっては、そのサービスのグレーゾーンを利用するために名寄せされると困るユーザーが一定いると聞きます。（転売ヤーなど）。新字体・旧字体の対応であれば超コストを掛けて変換表を用意し、そこで第一名寄せすることで対応もできると思います。一方で、結婚前の旧姓や新姓を使い分けられると、下の名前でしか突合できません。さらに本物の詐欺師は養子縁組をして戸籍・住民票ごと苗字を変更するという荒業があるそうです。怖い世界ですね。

生年月日

データの整合性という意味では日付型が一番望ましいと考えられます。文字列の場合、入力時のvalidationを相当厳しくしないとその後のクレンジングtransform層で劇苦労するでしょう。

個人的にはDX人材育成の教科書の一ページ目に用意して欲しい話題です。（特にExcelで日付型のデータ自体とformatの見え方は分離できる概念ということを叩き込んでほしい）

これまた余談ですが、 日付型に収まらない住基の生年月日 という恐ろしX投稿を見かけてしまいました

住基ネットの仕様書は見つけられませんでしたが、間接的に見つけました。 不詳の場合は 00 で埋められるようです。

出所: https://www.applic.or.jp/2018/stand/APPLIC-0002-2017/APPLIC-0002-2017-02/APPLIC-0002-2017-02-01.pdf

データ型（日付・整数・文字列）の違い

日付型

• 任意時点の年齢の計算が容易
• ただし Excelの datedif 関数は月末処理とうるう年の2/29に絡んだバグがあるので要注意 => EXCELで日付の差を計算するDATEDIF関数の落とし穴と回避方法
  

整数型

• 8ケタ保持が必須
• 20231232 など存在しない日も入力できてしまうので入力側でvalidationが必要
• 日付型が使えれば特段メリットはない

文字型

ともかく柔軟に受け入れるが、その後の検証や再利用に使うには地獄。絶対に受け入れてはいけない。

• 年を元号で持っているケースなど。元号も漢字であったりアルファベット一文字であったり。
• 区切り文字の有無や種類（スラッシュ、漢字）
• 月日の1ケタ入力の許容または混在

新しく作る際にはどうあるべきか？

この辺が無難じゃないでしょうか。

• 氏名は入力一つとする。
  • 外国人などアルファベット許容
  • 姓と名の間にスペースを入力するかは要件次第
    • スマホでの入力では全角スペースの入力は困難なので、フロントエンド側で半角スペース->全角スペース変換が望ましい
• 生年月日は日付型

その他

同一人物判定であれば携帯番号 or email が無難です。ただし、複数台持ちの場合、本人と携帯電話番号には1:nの関係があるので必ずしも同一性を特定できないことや、emailも複数持てるため、異なるemail、異なる携帯電話番号でも同一人物である可能性は排除できません。

また、解約した携帯番号は最短で3か月程度で再利用されてしまうので照合に不具合も起こりえます。

名寄せのアルゴリズム

hokan さんのこちらのアルゴリズムがとても参考になります。

最後に

• そういえばですが、フェミル推定はあきめました。
• 生まれながらにUUID4を付与してほしいです。