Twitter で以下のツイートを見かけました。
まじか。あの郵便番号データ「KEN_ALL.CSV」がバージョンアップして、人の形をしたデータになってる。今後も改善予定のようで楽しみ。
— にゃんこそば🌤データ可視化 (@ShinagawaJP) June 30, 2023
・町域名が長い場合に複数レコードに分割するのをやめた
・半角カナをやめた
・UTF-8形式に変更
🔗郵便番号データダウンロード｜日本郵便https://t.co/OgElcsc5Xc pic.twitter.com/a9AjUdAwSJ
マジか! ということで早速日本郵政のサイトを確認してみました。
従来の「住所の郵便番号（CSV形式）」に加えて「住所の郵便番号（1レコード1行、UTF-8形式）（CSV形式）」が掲載されていますね。
郵便番号のデータ利活用の観点から2023年6月更新より新たな形式でのデータを追加で公表します。
読み仮名データは全角カタカナとなっています。
従前公表のデータについては、全角となっている町域名の文字数が38文字を超える場合、また、半角カタカナとなっている町域名のフリガナが76文字を超える場合には、複数レコードに分割していましたが、今回追加公表するデータについては、1郵便番号データに対し、1行で記載しています。
UTF-8形式で記載しています。
都道府県別のデータ掲載はありません。
なお、従前から公表している形式のデータについても継続して、掲載いたします。
おおー、いい感じですね。大事なのは従来の KEN_ALL も引き続き配布されている点ですかね。バッチで KEN_ALL を自動取得して更新してるシステムなんて山のようにあるわけで、いくらいい方向でも配布形式がいきなり変わってしまったら大問題ですよね。そこもちゃんとケアされていますと。
ちなみにツイートに貼られていた画像は日本郵政のサイトにあるものではなく、総務省の「郵便局データの活用とプライバシー保護の在り方に関する検討会」-「データ活用推進WG」の資料、「郵便局データ活用推進ロードマップ」関連検討状況についてのようです。データ活用推進WGの詳細は非公開になってるのですが、なぜか資料だけはググったら出てくるという。
KEN_ALL の何が問題か
「ケンオール」というだけで通じるほど界隈の人には常識なのですが、KEN_ALL の何が問題か振り返ってみましょう。と言ってもここで全部を書くのも大変なので Qiita 内で見つけた参考になる記事をリンクします。
ざっくり要約すると、以下の点が問題なわけです。
- 文字コードが Shift-JIS
- カナが半角
- 町域が38文字を超えると1レコードが複数行にまたがる
- 同じ町域が複数の郵便番号に割り当てられる
- 一つの郵便番号が複数の町域に割り当てられる
- 「以下に掲載がない場合」で複数の町域がまとめられる
などがあります。後半の三つはそもそも郵便番号であることに起因する問題ですので解決が難しいですが、前半についてはシステムとして扱いやすい形式になっているといいですよね。それが今回 utf_all で解消されたというわけです。
実際のデータをみてみる
さっそくデータがどうなっているか見てみました。2023年7月3日にダウンロードしたデータですので、おそらく2023年6月末更新分だと思われます。このあたりの更新情報もどこかに情報としてあるといいですね。
$ ls -l
合計 29940
drwxr-xr-x 2 saoyagi2 saoyagi2 4096 7月 3 08:56 ./
drwxr-xr-x 18 saoyagi2 saoyagi2 4096 7月 2 15:31 ../
-rw-r--r-- 1 saoyagi2 saoyagi2 12339292 7月 3 08:27 KEN_ALL.CSV
-rw-r--r-- 1 saoyagi2 saoyagi2 18305986 7月 3 07:50 utf_all.csv
KEN_ALL の約 12MB に対して、utf_all は約18MB。UTF-8 になりましたから、当然ながらファイルサイズは増えていますね。
$ file -i *
KEN_ALL.CSV: application/csv; charset=unknown-8bit
utf_all.csv: application/csv; charset=utf-8
utf_all の文字コードは UTF-8 になってますね。
$ file -e encoding utf_all.csv
utf_all.csv: UTF-8 Unicode text, with CRLF line terminators
BOM は付いていませんでした。
文字コード以外の部分もみていきましょうか。
01101,"060 ","0600000","ﾎｯｶｲﾄﾞｳ","ｻｯﾎﾟﾛｼﾁｭｳｵｳｸ","ｲｶﾆｹｲｻｲｶﾞﾅｲﾊﾞｱｲ","北海道","札幌市中央区","以下に掲載がない場合",0,0,0,0,0,0
01101,"064 ","0640941","ﾎｯｶｲﾄﾞｳ","ｻｯﾎﾟﾛｼﾁｭｳｵｳｸ","ｱｻﾋｶﾞｵｶ","北海道","札幌市中央区","旭ケ丘",0,0,1,0,0,0
01101,"060 ","0600041","ﾎｯｶｲﾄﾞｳ","ｻｯﾎﾟﾛｼﾁｭｳｵｳｸ","ｵｵﾄﾞｵﾘﾋｶﾞｼ","北海道","札幌市中央区","大通東",0,0,1,0,0,0
01101,"060 ","0600042","ﾎｯｶｲﾄﾞｳ","ｻｯﾎﾟﾛｼﾁｭｳｵｳｸ","ｵｵﾄﾞｵﾘﾆｼ(1-19ﾁｮｳﾒ)","北海道","札幌市中央区","大通西（１～１９丁目）",1,0,1,0,0,0
01101,"064 ","0640820","ﾎｯｶｲﾄﾞｳ","ｻｯﾎﾟﾛｼﾁｭｳｵｳｸ","ｵｵﾄﾞｵﾘﾆｼ(20-28ﾁｮｳﾒ)","北海道","札幌市中央区","大通西（２０～２８丁目）",1,0,1,0,0,0
01101,"060 ","0600031","ﾎｯｶｲﾄﾞｳ","ｻｯﾎﾟﾛｼﾁｭｳｵｳｸ","ｷﾀ1ｼﾞｮｳﾋｶﾞｼ","北海道","札幌市中央区","北一条東",0,0,1,0,0,0
01101,"060 ","0600000","ホッカイドウ","サッポロシチュウオウク","イカニケイサイガナイバアイ","北海道","札幌市中央区","以下に掲載がない場合",0,0,0,0,0,0
01101,"064 ","0640941","ホッカイドウ","サッポロシチュウオウク","アサヒガオカ","北海道","札幌市中央区","旭ケ丘",0,0,1,0,0,0
01101,"060 ","0600041","ホッカイドウ","サッポロシチュウオウク","オオドオリヒガシ","北海道","札幌市中央区","大通東",0,0,1,0,0,0
01101,"060 ","0600042","ホッカイドウ","サッポロシチュウオウク","オオドオリニシ（１−１９チョウメ）","北海道","札幌市中央区","大通西（１〜１９丁目）",1,0,1,0,0,0
01101,"064 ","0640820","ホッカイドウ","サッポロシチュウオウク","オオドオリニシ（２０−２８チョウメ）","北海道","札幌市中央区","大通西（２０〜２８丁目）",1,0,1,0,0,0
01101,"060 ","0600031","ホッカイドウ","サッポロシチュウオウク","キタ１ジョウヒガシ","北海道","札幌市中央区","北一条東",0,0,1,0,0,0
半角カナは全角カナに改められています。
一方で「大通西（１〜１９丁目）」と、機械可読でない形式で複数の丁目がまとめられているのは変わっていません。このあたりは今後に期待ですかね。
01224,"066 ","0660005","ﾎｯｶｲﾄﾞｳ","ﾁﾄｾｼ","ｷｮｳﾜ(88-2､271-10､343-2､404-1､427-","北海道","千歳市","協和（８８－２、２７１－１０、３４３－２、４０４－１、４２７－",1,0,0,0,0,0
01224,"066 ","0660005","ﾎｯｶｲﾄﾞｳ","ﾁﾄｾｼ","3､431-12､443-6､608-2､641-8､814､842-","北海道","千歳市","３、４３１－１２、４４３－６、６０８－２、６４１－８、８１４、８４２－",1,0,0,0,0,0
01224,"066 ","0660005","ﾎｯｶｲﾄﾞｳ","ﾁﾄｾｼ","5､1137-3､1392､1657､1752ﾊﾞﾝﾁ)","北海道","千歳市","５、１１３７－３、１３９２、１６５７、１７５２番地）",1,0,0,0,0,0
01224,"066 ","0660005","ホッカイドウ","チトセシ","キョウワ（８８−２、２７１−１０、３４３−２、４０４−１、４２７−３、４３１−１２、４４３−６、６０８−２、６４１−８、８１４、８４２−５、１１３７−３、１３９２、１６５７、１７５２バンチ）","北海道","千歳市","協和（８８−２、２７１−１０、３４３−２、４０４−１、４２７−３、４３１−１２、４４３−６、６０８−２、６４１−８、８１４、８４２−５、１１３７−３、１３９２、１６５７、１７５２番地）",1,0,0,0,0,0
複数行にまたがっていたレコードは1行にまとめられるようになってます! 正直、これだけでも KEN_ALL のパースのしんどさがだいぶ解消されますからありがたいですね。
今後の住所データの選択肢
記事タイトルに「これからは KEN_ALL.CSV ではなく utf_all.csv を使おう」と書きましたが、実際に utf_all.csv に移行できるかっていうと正直微妙なところではあります。
既存のシステムでは KEN_ALL の問題点は自前実装かライブラリを使って解消していますから、今すぐに utf_all に乗り換える必要はありません。
では新規システムやフルリプレース時に utf_all を採用するかというと、現在はなんといってもアドレス・ベース・レジストリがありますのでそちらを採用した方がいいケースが多そうです。
日本では長らく「全国をカバーして」「町字、丁目小字レベルをサポートして」「無料で」使える住所コードは KEN_ALL しかありませんでした。なのでみんな使いにくいなと思いつつ、KEN_ALL を使っていたのです。でも2023年現在では他の選択肢も存在しますので、用途に応じて使い分けるということになりそうです。その際に KEN_ALL のままでは選択するのは難しかったわけですが、utf_all となったことで有力な選択肢として生まれ変わったと言えそうです。中の人、お疲れ様でした。ありがとうございます！
(2023/12/1追記)
いつの間にか utf_all.csv から utf_ken_all.csv に変わったという話を聞いてちょっとびっくり。どこが変わったかはまとめてくださっている方がいらしたのでそちらにリンクしておきます。
でも今確認したら zip ファイル内はディレクトリ階層付いてなかったし、ファイル名も utf_all.csv のままでした。まだまだ仕様変更中なのですかね。これでは自前のシステムに組み込むのはちょっと怖いですね。
あと、データの説明ページが出来てました。あれ、これ以前からありましたっけ。だとしたら見落としてたなぁ。この仕様ページがあるってことは、データ形式として安定したってみなしていいのかな。