日本における「名寄せ」と「照合」の黒歴史
健康保険証、銀行口座、年金記録――個人のマイナンバーに別人の情報がひも付けられるトラブルが後を絶たない。多くの事案に共通するのは、自治体や関係機関の職員が氏名や生年月日などを基にマイナンバーや住民データを照会した際に、誤って同姓同名の人の情報を引き出してひも付けてしまうというケースだ。 こうした情報のひも付けをする際、職員が住民データの照合や突合、本人確認に使うのが「氏名」「生年月日」「性別」「住所」、いわゆる基本4情報といわれるものだ。 だがこの4情報は、コンピューターによる自動処理とは絶望的に相性が悪い。例えば氏名は「邊」「邉」など旧字・異体字の揺らぎや外字の処理が煩雑なうえ、婚姻による改名もある。よくある氏名の場合、氏名も生年月日も同一というケースが頻発する。住所は時期によって変わるうえ、人によって書き方が「一丁目四番」から「1―4」まで一意ではない。 こうした曖昧な識別符号を代替す
基本4情報での名寄せは難しい｜MORIDaisuke
先日は住所の件でお楽しみでしたね。 私も楽しくなってしょうもないツイートをしたところ、@masanorkさんから有用な情報をいただいてしまいました。 異体字に加えて外字も根深いですし、日付型に収まらない住基の生年月日とか、屋号を含んだ個人事業主の口座名義とか、外国人氏名における住民登録のアルファベットと口座名義のカタカナとの解離とか、旧姓併記の例外処理とか、文字列型に刻まれたバッドノウハウの塊ですね https://t.co/GOaytijfst — Masanori Kusunoki / 楠 正憲 (@masanork) June 6, 2023 このとき、私はごく簡単な「名寄せの難しさ」の社内研修資料を作っている最中だったのですが、この情報が大変参考になりました。 一方、私だけが得をしているのがなんとなくムズムズしてきたので、ここにアウトプットしてスッキリしようと思います。 なお、住所
構文のことは忘れて、JSON, S式, XMLのデータモデルを比較する
データをシリアライズするには、独自のフォーマットを定めるよりも、基本的な定義済みの構造を組み合わせてフォーマットを作るほうが望ましい場合が多いです。 そのような仕組みとしてJSON, S式, XMLなどが存在しますが、これらは 「基本的な構造」として何を選ぶか、という観点からそれぞれに個性を持っています。 本記事では、具体的な構文のことは基本的に忘れて、各フォーマットが採用するデータモデルの違いに焦点を絞って比較します。 JSON data JSON = Value data Value = -- Compounds Array [Value] | Object (Map String Value) -- Scalars | Null | Boolean Boolean | String String -- UCS-2 | Number IntegerOrFloat -- no NaNs
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
