MS-Access 上で郵便番号を住所変換するためには、住所入力支援機能が提供されている。
しかし、元になっている辞書ファイルのアップデートが遅れたり、用途に応じてカスタマイズするには限界があるなどの理由から、日本郵政公社が配布している郵便番号データを利用して、オリジナルの郵便番号⇒住所変換機能を実装する方法も、広く知られている。
日本郵政公社（執筆当時。現・郵便事業株式会社）が配布している郵便番号データは単純な CSV 形式のため、加工がしやすく、初・中級クラスの VBA の知識があれば簡単に応用が効く、というのが、私が見聞きした範囲での一般的な認知のようだ。
しかし最近になって、ふとしたことから実際にその CSV データを見る機会が有り、いくつかの疑問点・問題点が浮かび上がってきた。
はたして日本郵政公社の CSV データは、本当に使いやすいのだろうか？
まず、仕様を確認してみたい。
日本郵政公社（執筆当時。現・郵便事業株式会社）が配布している郵便番号データは、郵便番号等のダウンロードのページからダウンロードできる。
主に使用されるのは、全国一括の郵便番号と住所等を対応させた ken_all.csv だ。
ken_all.csv には、読み仮名データの促音・拗音を小書きで表記したもの（例：ホッカイドウ）としないもの（例：ホツカイドウ）の二種類が存在する（実際には半角カタカナで収録されている）。
この他にも事業所の個別郵便番号やマニュアルなども提供されている。
CSV の仕様は、ReadMe で確認できるので、まずはそちらに目を通してみよう。
注目したいのは、「３．留意点」の第４項である。
以下に引用する。
4. 郵便データファイルの形式等
※全角となっている町域部分の文字数であれば38文字を越える場合、半角となっているフリガナ部分の文字数であれば76文字を越える場合は、複数レコードに分割しています。
- この郵便番号データファイルでは、次の順に配列しています。
- 全国地方公共団体コード(JIS X0401、X0402)……… 半角数字
- (旧)郵便番号(5桁)……………………………………… 半角数字
- 郵便番号(7桁)……………………………………… 半角数字
- 都道府県名 ………… 半角カタカナ(コード順に掲載) (注1)
- 市区町村名 ………… 半角カタカナ(コード順に掲載) (注1)
- 町域名 ……………… 半角カタカナ(五十音順に掲載) (注1)
- 都道府県名 ………… 漢字(コード順に掲載) (注1,2)
- 市区町村名 ………… 漢字(コード順に掲載) (注1,2)
- 町域名 ……………… 漢字(五十音順に掲載) (注1,2)
- 一町域が二以上の郵便番号で表される場合の表示 (注3) (「1」は該当、「0」は該当せず)
- 小字毎に番地が起番されている町域の表示 (注4) (「1」は該当、「0」は該当せず)
- 丁目を有する町域の場合の表示 (「1」は該当、「0」は該当せず)
- 一つの郵便番号で二以上の町域を表す場合の表示 (注5) (「1」は該当、「0」は該当せず)
- 更新の表示（注6）（「0」は変更なし、「1」は変更あり、「2」廃止（廃止データのみ使用））
- 変更理由 (「0」は変更なし、「1」市政・区政・町政・分区・政令指定都市施行、「2」住居表示の実施、「3」区画整理、「4」郵便区調整、集配局新設、「5」訂正、「6」廃止(廃止データのみ使用))
注1 文字コードには、MS漢字コード(SHIFT JIS)を使用しています。 注2 文字セットとして、JIS X0208-1983を使用し、規定されていない文字はひらがなで表記しています。 注3 「一町域が二以上の郵便番号で表される場合の表示」とは、町域のみでは郵便番号が特定できず、丁目、番地、小字などにより番号が異なる町域のことです。 注4 「小字毎に番地が起番されている町域の表示」とは、郵便番号を設定した町域(大字)で、複数の小字を有し、小字毎に番地が起番されていることにより、異なる小字に同一番地が付定されている場合があり、町域(郵便番号)と番地だけでは住所が特定できない町域のことです。 11.の例
<小字に同一番地が存在する住所> ○○市△△町が郵便番号の表す範囲であり、町域(郵便番号)と番地だけでは住所が特定できません。 ○○市△△町字A100番地 ○○市△△町字B100番地 ○○市△△町字C100番地 注5 「一つの郵便番号で二以上の町域を表す場合の表示」とは、一つの郵便番号で複数の町域をまとめて表しており、郵便番号と番地だけでは住所が特定できないことを示すものです。 注6 「変更あり」とは追加及び修正により更新されたデータを示すものです。 注7 全角となっている町域名の文字数が38文字を超える場合、また、半角カタカナとなっている町域名のフリガナが76文字を越える場合には、複数レコードに分割しています。
※ 2005/11/23 日時点での公開内容から引用しています。
正直言って、素人には何を言っているのかよく分からない箇所も多い。
ざっくり最初の 9 列に住所情報が含まれていることは分かるので、よく読まずにそのままインポートしてしまう人も多いような気がするが、それでは本トピックの意味が無いので、ポイントを絞って確認していきたい。
- 注1
- 文字コードには、MS漢字コード(SHIFT JIS)を使用しています。
- 注2
- 文字セットとして、JIS X0208-1983を使用し、規定されていない文字はひらがなで表記しています。
思わず目を疑う衝撃の事実である。
郵便番号データは、Shift-JIS でのみ提供されており、未定義の漢字はひらがなで表記されているという。
いまさら説明するまでもなく、日本は漢字文化の国でもあり、歴史的な経緯により地名用の特殊な漢字が使用されている名称の地域は決して少なくない。
これに従うと、たとえば岡山県岡山市の地名「さい」（「禾：のぎへん」に「最」）などは、「さい」と表記されることになる。
いや、SJIS では表記しようがないのは分かる (実際この HTML も SJIS なので、上記地名を表記できていない)。
問題は、なぜ住所を含むデータが SJIS のみでしか提供されていないのか、という点だろう。
「さい」は、Unicode であれば区点 0x7A5D に存在する。
SJIS では正確に表記できない地名のうち相当数が、Unicode であれば問題なく表記できるはずだ。
20 世紀ならいざしらず、今は Unicode 対応製品があふれている。
MS-Access 以外の Office 製品は Office 97 で Unicode 対応したし、MS-Access も 2000 で完全対応した。
外堀はすでに埋まっているのだ。
日本郵政公社さえその気になれば、Unicode 版の郵便番号データなど簡単に提供できるだろう。
地名は言うまでも無く文化の一つである。それをたかがマイナーになりつつある文字コードセットの一つに合わせて、官公庁自らが情報として劣化したデータのみしか提供してこなかったというのは、想像を絶する惨状だ。
私は国粋主義者ではないが（国粋主義者だったら MS-Access など使えない）、自国の文化を大切に出来ない国の未来は暗いと言わざるを得ない。
もし郵便番号データが、SJIS 版と、地名をより正確に表記した Unicode 版の２種類提供されていたら、あなたはどちらを利用したいと思うだろうか。
Access 2000 以降なら、インポートした時点でどのみち Unicode として格納されるに決まっているデータなのだ。
残念ながら、実際にはこの問いは無効である。
Unicode 版は存在しない。
※ 私は Unicode 信奉者では別にない。ここで Unicode を持ち出したのは、Access 2000 以降がサポートしていて、SJIS よりは よりよく日本の地名を表現できるからであり、可能であるなら日本郵政公社は超漢字用（TRONコード）など多様なプラットホーム向けのデータを提供するに越したことはないと考える。
- 注7
- 全角となっている町域名の文字数が38文字を超える場合、また、半角カタカナとなっている町域名のフリガナが76文字を越える場合には、複数レコードに分割しています。
これまた目を疑う注記である。
言うまでも無く、CSV というデータ形式そのものには、こんな文字数制限などない。
察するに、日本郵政公社が郵便番号データの管理に使っているホスト側で、当該フィールドのデータ長がそれだけしか確保されていなかったのだろう。
そのこと自体は、メモリもディスクも貴重だったその昔には、程度の差こそあれ、どこでも取られていた措置だったはずで、別に不思議なことではない。
分からないのは、なぜそれを 2005 年末の現在に至るまで放置しているのか、ということだ。
データ長を変更すれば当然影響を受ける処理もあるだろうが、それは必要な修正なのであって、チューニングしたくないから改修しないというのは明らかに本末転倒だろう。
いや、百歩譲って、骨董品をそのまま使い続けるのも日本郵政公社の自由、ということにしてみよう。
それは構わない。
だが、せめて国民向けにデータを提供するときくらい、レコードをマージしろよ。
現行の CSV データはそのレベルの加工処理すら行わずに、ホストからの出力データをそのまんま投げっぱなしジャーマン状態にしている。
魚介類なら「獲れたてをそのまま」が鮮度の良さで喜ばれることも有るだろうが、どこの世界にこんな使いにくいデータをナマのまま渡されて喜ぶユーザーが居るというのか。
その結果、日本郵政公社の手抜き作業のあおりを食らって、利用者である国民は、１レコード分のデータを複数行から復元するという余計な作業を強いられるのである。
- この郵便番号データファイルでは、次の順に配列しています。
- 全国地方公共団体コード(JIS X0401、X0402)……… 半角数字
- (旧)郵便番号(5桁)……………………………………… 半角数字
- 郵便番号(7桁)……………………………………… 半角数字
- 都道府県名 ………… 半角カタカナ(コード順に掲載) (注1)
- 市区町村名 ………… 半角カタカナ(コード順に掲載) (注1)
- 町域名 ……………… 半角カタカナ(五十音順に掲載) (注1)
- 都道府県名 ………… 漢字(コード順に掲載) (注1,2)
- 市区町村名 ………… 漢字(コード順に掲載) (注1,2)
- 町域名 ……………… 漢字(五十音順に掲載) (注1,2)
うーむ、この「〜順に掲載」というのは、いったい何を言っているのだろうか？
誰か、この意味が分かりますか？
そもそも「コード順」の「コード」が何のコードなのかも分からない。
文字コード順という意味だろうか。それとも先頭列の「全国地方公共団体コード」を指しているのだろうか。
4〜9 まで、全部 Order By を指しているのだとしたら、明らかに 7〜9 は指定する意味が無さそうだし。
私の日本語読解能力に問題があるのかもしれないが、とにかくこの仕様だけ見ていてもラチが明かないのは明白なので、あとは実データで確認するしか無さそうだ。
以下が、実際の ken_all.csv の先頭 3 行分のデータである。
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
※ 半角カタカナを全角に開いてあります。
いきなり「アオモリケン」ではなく「ホッカイドウ」から始まっているので、「コード」は「文字コード」ではなく「全国地方公共団体コード」を指していたようだ。
もっとも、それなら 4、5、7、8 に個別にわざわざ「(コード順に掲載)」と書く意味が分からないし、どのみち「全国地方公共団体コード」と明示しない段階で不親切極まりない。
さらに「町域名」の「(五十音順に掲載)」も、いきなりウソである。
「"イカニケイサイガナイバアイ"」が先頭行に来ており、次に「ア」から始まる「"アサヒガオカ"」が 2 行目に来ている。
他にも、探すと次のような例があった。
08546,"30604","3060400","イバラキケン","サシマグンサカイマチ","イカニケイサイガナイバアイ","茨城県","猿島郡境町","以下に掲載がない場合",0,0,0,0,0,0
08546,"30604","3060433","イバラキケン","サシマグンサカイマチ","サカイマチノツギニバンチガクルバアイ","茨城県","猿島郡境町","境町の次に番地がくる場合",0,0,0,0,0,0
08546,"30604","3060422","イバラキケン","サシマグンサカイマチ","イチノヤ","茨城県","猿島郡境町","一ノ谷",0,0,0,0,0,0
※ 半角カタカナを全角に開いてあります。
これを見ると、「"<市区町村名>ノツギニバンチガクルバアイ"」というのも、五十音順と関係なく優先的に配置されているようだ。
いずれも、特定の町域を指すのではない包括的な呼称が、例外的に並び順より優先されている節がある。
では、やはり特定の町域を指すのではない「"<市区町村名>一円"」も、同様の扱いなのだろうか。
23304,"48011","4801131","アイチケン","アイチグンナガクテチヨウ","ナガクテ","愛知県","愛知郡長久手町","長湫",0,0,0,0,0,0
23304,"48011","4800001","アイチケン","アイチグンナガクテチヨウ","ナガクテカイジヨウイチエン","愛知県","愛知郡長久手町","長久手会場一円",0,0,0,0,0,0
23304,"48011","4801141","アイチケン","アイチグンナガクテチヨウ","ネノカミ","愛知県","愛知郡長久手町","根の神",0,0,0,0,0,0
※ 半角カタカナを全角に開いてあります。また上記は 2005 年執筆当時のデータです。〒480-0001 は、後に廃止されています。
「"<市区町村名>イチエン"」の場合は、他の町域名と同様に、五十音順に配置されているようだ。
はっきり言って、もうムチャクチャである。
規則性を見出すのも難しい（ないのかもしらん）。
正直なところ、この「一円」というのが、地名なのか「その辺」を意味しているだけなのかすらも、この郵便番号データからでは知るすべがないのが実情である。
とにかく、以上の事実から、強引では有るが、ReadMe よりはマシな ken_all.csv の並び順を規定してみよう。
「全国地方公共団体コード」の昇順である。
1 が同値の場合、「町域名（カナ）」が「"イカニケイサイガナイバアイ"」のレコードがその範囲の先頭レコードとなり、次に「"<市区町村名>ノツギニバンチガクルバアイ"」が、それ以降は「町域名（カナ）」の五十音≒文字コードの昇順になる。
ただし 1 レコードが複数に分割されている場合、分割された 2 つ目以降の断片は、例外的に「町域名（カナ）」と関係なく先頭の断片に追随して連続的に配置される。
※ 上記は、データを見る限りではこのように見える、という私的定義であって、実際の仕様とは異なっているかもしれない。いずれにしても、日本郵政公社が仕様を明確に提示していない以上、今のところユーザーには正確な仕様を知るすべがない。
補足しておくと、やはりデータを見る限りの話だが、「全国地方公共団体コード」と「都道府県名＋市区町村名」はユニークで一対一の関係になっているようなので、「全国地方公共団体コード」の昇順に並べた時点で、「都道府県名」と「市区町村名」は並び順を気にする必要がない。
また 3 番のような例外処理があるので、これはインポートする際にオートナンバーを振っておかないと、エラい目に遭うこと必定である。
ヤレヤレ…。
※ オートナンバーを振らないと、分割されたレコードを正しくマージする順番の基準となるフィールドが存在しない。RDB の並び順は不定である。確率的には元の CSV 順に格納される場合の方が多いと期待されるが、保証はされない。特にディスクのフラグメンテーションが発生した場合などは、要注意である。
前章までは、ReadMe の記述を読んだ時点で判明する問題点を挙げてきた。
以降は ken_all.csv を実際に MS-Access にインポートして活用しようとしたときに何が起きるか、見ていきたい。
とにもかくにもインポートする必要がある。
下記のような感じでインポートしてみた。
本来 1 つのレコードが複数のレコードに分割しているケースがあるため、オートナンバーの付加は必須である。
ここで、最大の問題である、「本来 1 つのレコードが複数のレコードに分割しているケース」を何とかしよう。これさえプログラム的に処理できれば、自動更新も夢ではない。
さて、いったいそれは どのようにして見分ければよいのだろうか。
再度 ReadMe からの抜粋を再掲してみる。
- 10.
- 一町域が二以上の郵便番号で表される場合の表示 (注3) (「1」は該当、「0」は該当せず)
- 11.
- 小字毎に番地が起番されている町域の表示 (注4) (「1」は該当、「0」は該当せず)
- 12.
- 丁目を有する町域の場合の表示 (「1」は該当、「0」は該当せず)
- 13.
- 一つの郵便番号で二以上の町域を表す場合の表示 (注5) (「1」は該当、「0」は該当せず)
注3 「一町域が二以上の郵便番号で表される場合の表示」とは、町域のみでは郵便番号が特定できず、丁目、番地、小字などにより番号が異なる町域のことです。 注4 「小字毎に番地が起番されている町域の表示」とは、郵便番号を設定した町域(大字)で、複数の小字を有し、小字毎に番地が起番されていることにより、異なる小字に同一番地が付定されている場合があり、町域(郵便番号)と番地だけでは住所が特定できない町域のことです。 11.の例
<小字に同一番地が存在する住所> ○○市△△町が郵便番号の表す範囲であり、町域(郵便番号)と番地だけでは住所が特定できません。 ○○市△△町字A100番地 ○○市△△町字B100番地 ○○市△△町字C100番地 注5 「一つの郵便番号で二以上の町域を表す場合の表示」とは、一つの郵便番号で複数の町域をまとめて表しており、郵便番号と番地だけでは住所が特定できないことを示すものです。 注6 「変更あり」とは追加及び修正により更新されたデータを示すものです。 注7 全角となっている町域名の文字数が38文字を超える場合、また、半角カタカナとなっている町域名のフリガナが76文字を越える場合には、複数レコードに分割しています。
上記は、分割されたレコードの特定と関連があると思われるフラグの説明と注釈である。
それぞれ、フラグ1、フラグ2、フラグ3、フラグ4 としてインポートした。
※ 最後のフラグ5 とフラグ6 は、更新と変更に関するフラグなため、無関係と判断してここでは割愛した。
では、これを実際のデータと付け合せてみよう。
※ 平成17年 10月 31日更新版より抜粋
この図は、同一郵便番号（７桁）で複数のレコードを持つものの中から、適当にピックアップしたものである。
最初の４レコードは比較用で、同一郵便番号ではあるが、町域がそれぞれ独立しているためマージする必要はない。
５レコード目以降（色違い）は、同一町域の文言が複数のレコードに分割されている。
最後の 1 レコードは、再び比較用に、1 レコードしか持たない郵便番号を混ぜてみた。当然マージする必要はない。
さて、独立した町域と、分割された町域とを区別するフラグはどれだろうか。
フラグ3 はどれも 0 なので、明らかに関係ない。説明を読んでも、「丁目を有する町域の場合の表示」となっているので、考慮しなくてよいだろう。
後は……
あなたには、マージすべきレコードを見分けるためのフラグが見つかっただろうか？
一見フラグ1 かフラグ2 が 1 になっているレコードがマージ対象のように錯覚するかもしれないが、よく見ると「8260043」のフラグが一つも立っていないため、そうではないことが分かるだろう。
それどころか、「8260043」と、比較対照用の末尾レコード（東京都新宿区南町）は、フラグ構成が完全に同一である。
いったいどういうことなのだろうか？
実は、フラグだけ見ていても見分けることは出来ない。
正解は、フラグ4（一つの郵便番号で二以上の町域を表す場合の表示）が 0（つまり一つの郵便番号で一つの町域を表す）で、尚かつ同一郵便番号のレコードが 2 レコード以上の場合、マージする必要があるのだ。
つまり、郵便番号でグループ化したレコードのカウントを求めて比較しない限り、見分けることは出来ない。
なんと面倒なことだろう！
勘の鋭い方は お気付きかもしれない。
実は上の説明は、とりあえず機能はするのだが、問題が２つある。
一つは、サンプルの中に、明らかに分割する必要がないデータが混じっていることだ。
ReadMe の「注7」をもう一度読んでほしい。
次に、サンプルの「0285102」（岩手県岩手郡葛巻町）を見ていただきたい。
いったいこれのどこが「全角となっている町域名の文字数が38文字を超える場合」に該当するのだろうか？
実際には 2 レコード合わせても 31 文字しかない（葛巻（第４０地割「５７番地１２５、１７６を除く」〜第４５地割））。
フリガナも 44 文字しかなく、「半角カタカナとなっている町域名のフリガナが76文字を越える場合」にも該当しない。
つまり、このデータは「複数レコードに分割」する必要がまったくないにもかかわらず、なぜか分割されているのだ。
以下はまったくの推測だが、この現象を説明できそうな仮説を一つ提示できる。
「0285102」は、以前はたしかに文字数制限を越えていたために、複数レコードに分割されていた。
そして、どこかの時点で町域の統廃合が行われ、文字数制限内に収まるようになったのだ。
だが、そのときのオペレータが、不要な文字を各レコードから削除しただけで、マージを怠ったために、本来ならば 1 レコードに収まるデータが、2 レコードに分割されたまま取り残された……。
もしこの推測が当たっているとすれば、さらに 2 つの事実が示唆されることになる。
一つは、郵便番号データは、システムの仕様を知らない職員によってメンテナンスされているということ。
もう一つは、修正されたデータの妥当性をチェックする体制が存在しないということだ。
事実だとすれば、お粗末を通り越して、あきれ果てるほかない。
一つ目の問題は、マージ判定のロジックには影響を与えないのでまだマシだが、もう一つの問題はより深刻だ。
先ほど私は「フラグ4（一つの郵便番号で二以上の町域を表す場合の表示）が 0（つまり一つの郵便番号で一つの町域を表す）で、尚かつ同一郵便番号のレコードが 2 レコード以上の場合、マージする必要がある」と書いた。
現時点のデータを見る限りでは、それは機能するように見える。
だが、一つの郵便番号に二以上の町域が含まれ、なおかついずれかの町域名称が文字数制限を越えてレコード分割されるということは有り得ないのだろうか？ 今は無いとしても、今後発生しないことは保証されているのだろうか？
私自身は仕様を知らないので、この問いに答えるすべを持たない。
日本郵政公社の職員であれば、答えを知っているはずだ（少なくともそうであってほしい）。
もしそのような事態が有り得るのであれば、前述の判定方法は完全に破綻する。
すなわち、人間が目で見て判断する以外にマージする方法がなくなる、ということを意味している。
これが、郵便番号制度の根幹を握っている天下の日本郵政公社が、長年にわたって国民に提供し続けてきた CSV データの実態だ。
世の中には郵便番号から住所を検索するシステムがごまんとある。
MS-Access を利用したものもあるし、そうでないものもあるが、共通しているのはそのどれもが、日本郵政公社の ken_all.csv を元データに使用している、ということである。
しかし、そのシステムはいったいどれだけ、この世にも奇妙な ken_all.csv の構造を理解した上で構築されているのだろうか。
検証には、さきほどのサンプルでも取り上げた２つの郵便番号「028-5102」と「826-0043」を使用する。
先に正解を提示しておこう。
いずれも、一つの郵便番号に付き、住所（町域）は一つしか存在しないのが正解だ。
調査対象とその結果は、以下の通り。
| 検索システム | 028-5102 | 826-0043 |
|---|---|---|
| Access 2003 住所入力支援機能 | ○ | ○ |
| goo 郵便番号 | × | × |
| Excite エキサイト : 郵便番号検索 | ○ | ○ |
| 郵便番号検索 - infoseek 郵便番号 | × | ○ |
| ゆうびんホームページ 郵便番号検索 | ○ | ○ |
| 郵次郎 | × | × |
| 新・郵次郎 | ○ | ○ |
| Mapion [マピオン] | ○ | ○ |
※ 2005/11/23 時点での調査結果です。
住所入力支援機能以外の調査対象は、キーワード「郵便番号 検索」で Google 検索した結果の上位から適当にピックアップしたもので、他意はない。
これを見ると、さすがにアドバンス ソフトウェア株式会社が提供している住所入力支援機能は正確に結果を出している。
一方、大手ポータルサイトの検索サービスは、必ずしも良好な結果を出しているとは限らないようだ。
goo は全滅だが、これは単に何も考えずに（一切マージせずに）処理しているのだろう。
※ 本来 1 件の町域が、2 つに分割されて 2 件として表示されている。
goo は旧・郵政省寄りの電気通信事業者である NTT 系列のサイトである。いわば日本郵政公社からすると身内同然であって、そこでさえこの体たらくだから、いかに ken_all.csv の取り扱いが難しいか分かろうというものだ。
よく分からないのが infoseek で、マージ出来ているものと出来ていないものがある。マージ判定に誤ったフラグ解釈でもしているのだろうか。
平成17年 10月 31日更新版の ken_all.csv には、マージの必要のある郵便番号が 226 組 554 レコード存在している。
マージを行わなかった場合は、これらの郵便番号について不正な住所が表示される可能性があるわけだ。
これは ken_all.csv のレコード全体の 0.5% に相当する。
多いと見るか少ないと見るかは見方によるが、少なくとも当該地域に住んでいる利用者にとっては傍迷惑以外の何物でもないだろう。
実は上記以外にも、Access や Excel を使用したオリジナルの郵便番号検索ソフトもいくつか試したが、結果があまり芳しくなかったことと、善意で公開している個人の作者によるフリーウェアが多い点を鑑みて、結果を非公開とした。
関心のある方は、ご自身で確認してみていただきたい。
結局どういうことになるのだろうか。
複数町域が存在したらどうするかは、仕様によって異なるだろう。
複数の選択肢を示してユーザーに選ばせるようにすることも出来るし、あるいは市区町村までで確定することも出来る。
すでにここまで見てきたことで分かるように、ken_all.csv の構造はお世辞にも使いやすいと呼べるような代物ではない。
仕様の説明は不十分かつ不正確で、どのようにデータを再構築すればよいのかという指針は一切提供されていない。
データ構造の適切な解釈には注意が必要で、大手ポータルサイトのサービスでさえ解釈に失敗している。MS-Access 初心者が単純にインポートして終わりに出来る、と思ったら大間違いだ。
実は ken_all.csv の問題点はこれだけではない。
郵便番号⇒住所変換はかろうじて対処可能だが、住所⇒郵便番号変換しようとすると、混乱ぶりはさらにエスカレートしていく。
言いたいことはまだまだ有るが、突っ込みだすとキリがない。
機会が有れば、いずれ稿を改めて取り上げてみたいと思う。
日本郵政公社は最近、民営化を前にして、サービス向上に努めているようだ。
実際、私の周りでも対応が良くなったという声を聞くこともある。
ほとんどの職員は、おそらく優秀で真面目なのだろう。
ただ長年放置されてきたシステムは、放っておいても自動でよくなったりはしない。そこには人による指摘と介入が必要だ。
本稿が何かの機会に日本郵政公社の目に留まり、何らかの改善が行われることを期待したい。
タイミングよく、ken_all.csv を加工する新しいフリーウェアが公開された。
窓の杜 - 【NEWS】郵政公社提供の郵便番号データからMS-IME用の郵便番号辞書を作成
動作検証してみたが、ken_all.csv を正確に解釈する良質のソフトだと思う。
MDB ファイルへの変換もサポートしており、前述の「テスト」も難なくクリアした。
住所情報の展開など、独自の工夫もしてあって、よく練られている。
興味のある方はぜひ一度、使ってみていただきたい。
2009/2/27 追記。
マージの最後で危惧したように、「人間が目で見て判断する以外にマージする方法がなくなる」ケースがとうとう出現してしまったもよう。
「郵便番号データの落とし穴」に落ちてしまいました。 - 日記
経緯については、下記を参照のこと。
2010/1/23 追記。
郵便番号データを実用レベルに加工してダウンロード提供するサービスが 2009/11 に開始されていました。
郵便番号データのダウンロード - zipcloud via kiyotune (kiyotune) on Twitter
LZH 形式ではなく ZIP 形式でダウンロード可能、複数行分割データは 1 行にマージ済み、更新されたらメールでお知らせ等、もはや日本郵便が即行 業務委託すべきレベルです。
要件に適合するなら、本家よりも zipcloud の利用を検討しましょう。
2010/10/2 追記。
郵便番号神経衰弱パズルデータの問題点と対策まとめ記事が三日前にリリースされました。
非常にきれいにまとまっているので、興味のある方は下記を基点に調査を進めると、この問題に効率よく諦めをつけられるか、さもなくば一生を捧げる覚悟がつけられると思います。