郵便番号住所検索APIサービス「ケンオール」、住所自動補完機能の福音となるか 63
ストーリー by nagazou
維持するの大変だわ 部門より
維持するの大変だわ 部門より
オープンコレクターは8日、クラウド郵便番号住所検索APIサービス「ケンオール」を発表した。ケンオールは、郵便番号データベースをクラウド上に置くことにより、常に最新の情報を持った郵便番号住所検索が行えるAPIを提供するサービス（ケンオールブログ、プレスリリース）。
製品名の通り日本郵便の提供しているKEN_ALL.csvのかかえる様々な問題をクリアするために作られたサービスだそうだ（KEN_ALL.CSV (郵便番号検索)の落とし穴、KEN_ALL.csv のどこがだめなのかまとめてみる）。リリースによれば、
従来製品ではほぼ未対応だった、京都市の通り名や岩手県の地割、ビル名と町名の分割などに対応。例えば、郵便番号「6020842」と「6028202」を入力すると、多くの従来製品は「京都府京都市上京区栄町」のように全く同じ住所を出力しますが、ケンオールでは、前者は「京都府京都市上京区河原町通今出川下る栄町」、後者は「京都府京都市上京区大宮通中立売下る栄町」として、完全に区別して出力できるようになります。
としている。一方でTwitter上などでは対応し切れていない特殊な事例も指摘されている。ただこうした指摘に関してはオープンコレクターの担当者からリプがついており、特殊な事例も対応していく方針ではあるようだ。
あるAnonymous Coward 曰く、
郵便番号→住所変換の強要だけは止めてくれ (スコア:2, 参考になる)
たまに郵便番号→住所変換の変換を強制するシステムがあって積むことがある。勤務先の郵便番号入力でエラーになって申し込めない糞みたいなクレジットカードの申し込みサイトがあったりしてね。
沢山郵便物を受け取るような大企業だと専用郵便番号が日本郵便株式会社によって割り当てられていて、そういう特殊な郵便番号は日本郵便株式会社が公開するCSVに載らないのであわゆるAPIでは存在しない郵便番号として扱われてしまう。
その他、自衛隊関係の郵便番号なども一般公開されていないので、自衛隊宿舎に住んでいる人は自宅の郵便番号があちこちでエラーになるなどの被害が生じているとのこと。
あと、郵便番号の自動変換後の住所が編集できない（そのあとに追記することしかできない）ような糞システムもあるけど、その自動変換の住所が正しい保証は何もない。
郵便番号変換は信頼できないシステムなので、自動変換は入力補助のみとして使うべき。
Re:郵便番号→住所変換の強要だけは止めてくれ (スコア:2)
どのサイトだったか覚えていないけど、経験があります。
そのときは、個別郵便番号を使わず、その地域の通常の郵便番号を使うことで回避しました。
住所表記は正しいし、郵便物が届けば問題ないでしょう、たぶん。
Re:郵便番号→住所変換の強要だけは止めてくれ (スコア:1)
大口事業所の個別郵便番号なら公開されていますが、それとは別物ですか？
自衛隊の基地、駐屯地なども含まれています。
https://www.post.japanpost.jp/zipcode/dl/jigyosyo/index-zip.html [japanpost.jp]
KEN_ALL.csv レコードの複数行分割 (スコア:1)
なんで自分で自分を破壊するようなことをするの？そして日本郵政の中の人はなぜこれを直そうとしないの？
Re: (スコア:0)
なんで自分で自分を破壊するようなことをするの？そして日本郵政の中の人はなぜこれを直そうとしないの？
その上のお偉いところはさらに
一セル一文字のEXCELを使っている
から十分改善している
とかだったりして
Re: (スコア:0)
紙版の番号簿を印刷するためのデータだからなんでしょうかね？
Re: (スコア:0)
多分1366x768のモニタのPCを使っている
#これをWindows7の時に規定したMicrosoftの中の人はサティア・ナデラの前で腹を切ってわびるべき
Re: (スコア:0)
Re: (スコア:0)
そんなことしたらクロネコヤマトのような競業に塩を送ることになっちゃうだろ
Re: (スコア:0)
伝統ある76文字制限をなぜ直そうとする必要がある？
まして今さらKEN_ALL.csvの書式を変えようとか、まともな技術者なら絶対考えないだろうな
Re: (スコア:0)
KEN_ALL.csvは今のままでいいから、新たにまともな住所-郵便番号のデータを提供してくれればそれでいい。
住所表記の闇は深い (スコア:0)
住民票に記載の住所と慣用的に使われる住所表記はフォーマットからして異なるんじゃなかったですっけ？
例えば住民票には部屋番号などは記載されないので、そのままだと配達人が困るっていう。
どっちを正とみなして提供するんだろう。それとも両方のフォーマットで提供するのかな。
Re:住所表記の闇は深い (スコア:2)
今は部屋番号も住民票に書かれることが多いと思いますよ。
「住民票 方書き」で検索すると、近年に記載するようにした自治体の案内が出てきますね。
マンション・アパートだらけの都市部で記載しない自治体は、ないんじゃないかなあ、ないといいなあ。
Re:住所表記の闇は深い (スコア:1)
昔元下宿だったみたいな古いアパートに住んでましたが住民票には方書きで登録
郵便局の配達原簿 [wikipedia.org]にはアパート名と部屋番号が登録されてるって状況になってました
どちらの住所でも届くんですが「本人限定受取郵便（特定事項伝達型）」これだけは素直には届けてくれませんでしたね
方書きでは宛先不明扱いで返送
→アパート名で再送してもらうと今度は本人確認書類と宛先が違うから渡せない
→集配局まで赴いて責任者の名刺貰って発送元に掛け合って方書きで再送
→やっと受け取り
郵便物の宛先、配達原簿の住所、本人確認書類の住所が一致しないと本当は駄目らしいです
Re: (スコア:0)
もう郵便番号+番地までは全部数字にしちゃってくれてもいい気が
# だがしかしハイフンあり/なしのシステム超えの闇は続く
Re: (スコア:0)
うちの会社、郵便番号割り振られてるから、部署名だけで届くはずなんだけど、実際に試そうとしたら窓口で止められた。
Re: (スコア:0)
いや番地まで行かないと郵便番号が確定しないところが(も)住所表記の闇なんだよ。
実際にはビルの階数まで確定しないと駄目だったりもするけど。
Re: (スコア:0)
このサービスは日本郵便が提供しているもの以上の精度で郵便番号と住所表記の対応付けを提供するもので、配達可能なレベルまで詳細な住所表記を目的としたものじゃないですよ。
Re: (スコア:0)
むしろ日本郵便がシステム売り出すのが順当だったのでは？web検索だけでなく。
配布されてる郵便番号データには確かに字とか入ってるんだよ。
注釈混ざって使い物にし辛いけど。
Re: (スコア:0)
一言書いときゃいいんですよ：誤配防止のためマンション名は必ず住所に入れてください
本当に望まれてるのは全角・半角変換 (スコア:0)
未だに「全角で入力してください」というように全角・半角指定してくるサイトの多いこと。
もうクラウド変換でもいいからｗ自動変換してよ！
Re:本当に望まれてるのは全角・半角変換 (スコア:2)
ド素人でもできる作業なので、海よりも深い理由があるんだよ、きっと。
Re: (スコア:0)
次段に送るデータに半角数字を入れるのは許されない
という仕事でユーザ入力の自動変換を入れましたところ、怒られました
「ユーザの入力を勝手に変換するのは許されない」だそうで
「ダイアログ出してから変換とか難しくて理解できんかもしれないからダメ」だそうで
かなり戦ったんですが受け入れられませんでした。
おそらく責任回避のためだと思います
Re: (スコア:0)
言われるままを受け入れず、陰口で忖度するだけの墓守
Re: (スコア:0)
余程捻って分かりにくいダイアログでもない限り、
半角で入力しろの方が百倍分かりにくいだろうに。
バカが責任回避に走っているにしても、
そんなツッコミやすい言い訳されちゃうようでは
説得の仕方もイマイチだったんじゃないのと思わなくもない。
まぁそこまで手間掛ける義理もなかったと言うならそれはそれだが。
Re:本当に望まれてるのは全角・半角変換 (スコア:2)
「入力者の入力を書き換えない」という理由は、やらない理由を探しただけだと思う。
確かに、もっともらしい理由ではあります。
紙の文書でいえば、文書の名義人の意思を離れたところで、文書の内容を書き換えるのは、文書変造という不正行為になりえてしまいます。
役所の手続きで、ちょっとした記入漏れ、例えば元号の選択し忘れで、「50年」という昭和以外ありえないものでも、申請者に修正を求めたりする。
（実際には、受付担当者が勝手にチェックして済ましちゃうこともある。その方が早いから。）
そういう、文書手続きで叩き込まれた原理主義に従っている人もいるのかもしれない。
しかし、役所の文書手続きでも、文書内容の全てを申請者が記入することが求められているわけではありません。
役所が記入済み申請書を用意することもあります。
最近の事例では、特別定額給付金でありました。
申請内容である世帯構成を、あらかじめ役所が記入しておき、その書類に申請者が署名や押印することで、事前に記入済みの内容も含めて、申請者の意思による、申請者名義の文書が完成します。
つまり、最終的に名義人の意思が文書に反映されればそれでよいのです。
これをネット手続きに当てはめると、受付側が自動変換したのちに、最後の確認画面で変換後の情報を表示して、申請者が申請ボタンクリックを行えば、確認画面で表示した内容をもって、申請者の意思による、申請者名義のデータが完成します。
原理主義となんら齟齬はありません。
Re: (スコア:0)
未だに「全角で入力してください」というように全角・半角指定してくるサイトの多いこと。
もうクラウド変換でもいいからｗ自動変換してよ！
では全て1バイト文字に統一しろ！とか鶴の一声でやりかねない危険性が。。。
Re: (スコア:0)
このまえ、全角→半角変換してくれるフォームあったけど、ーと－と―で結果が違ってそれはそれでアレだった。
Re: (スコア:0)
ちなみに出前館は「ー(長音)」を半角にするから、片仮名のマンション名に長音が入ってるとなんかおかしくなる。
その他出前館は同一ID(メールアドレス)で複数アカウント作れて、パスワードリマインダーはどれか一つのIDにしか反応しないとかいろいろおかしい。
Re: (スコア:0)
何でだろうね、あれ。番地ぐらい勝手に全角に変換してくれりゃいいのに。
関係ないけど、何故振り仮名はカタカナ指定が多いんだろう。
Re:本当に望まれてるのは全角・半角変換 (スコア:1)
ヷヸヹヺがひらがなに無いから、とか？
#「ゔ」はある
Re: (スコア:0)
x-x-x 建物名 xx棟 xxx号 みたいな番地・建物名・棟番号・部屋番号混じりだと全角・半角強制は出来ないんですよね
かといって、番地欄、建物名欄、部屋番号欄のように入力欄を分けると実際の住所と異なる並びで入力されたりする…困ったクマー
Re: (スコア:0)
関係ないけど、何故振り仮名はカタカナ指定が多いんだろう。
起源的なことを言えば、カタカナは漢文訓読のための補助として漢文の行間の狭いところに書き加えられるようにカクカクした字体として生まれ、ひらがなは日本語を連綿と綴るために生まれた、という違いからかなぁ
まあそうじゃないだろうけど
Re: (スコア:0)
コンパクトに半角に収まったからじゃね
Re: (スコア:0)
それならオープンコレクターに対抗してオープンドレインという
会社を立ち上げてサービスを提供するのだっっっ！
Re: (スコア:0)
立ちはだかるトーテムポール
Re: (スコア:0)
オープンソース派との間にゲートが…
Re: (スコア:0)
未だに「全角で入力してください」というように全角・半角指定してくるサイトの多いこと。
恐らく
「入力者の入力を勝手に改ざんするなど許されない」
ってどこかのお偉いさんが言って
それが不可侵のスタンダードになっちゃったんじゃないかな
# 日本だと稀でもなくよくある馬鹿げたケース
Re: (スコア:0)
ここ数年ぐらいは、半角でもJavaScriptか次のページで勝手に全角に変換されて半角入力のままでもなんの問題なかったサイトだらけだったが。
むしろそんなサイト今あるのか。
Re:本当に望まれてるのは全角・半角変換 (スコア:2)
小さい会社だとメンテするやつがいねえ、
大きい会社ならいちいち稟議と仕様案件まとめて…とやることが多すぎる
ので、見ないフリしてることも多そうだけど。
Re: (スコア:0)
NTT東日本のWebフォームとかそうだよ
全角強制は正しい (スコア:0)
住民基本台帳もそうだしあらゆるお役所関係の住所の電子化規則（法令や内規等）で、算用数字を用いる場合は、いわゆる全角文字に統一されています。
○丁目を漢数字にするのか、算用数字にするのかでさえ、市区町村（場合によっては同一の市区町村でも統一されていない場合がある）で統一できていない中、算用数字は全角で全国綺麗に統一できているのです。
綺麗に正規化できているので、半角を使うのは止めてください。
勝手に変換すればいい？
ユーザが入力した個人情報を勝手に変更するのは問題があると考える人もいます。
Re:全角強制は正しい (スコア:2)
それは、申請者の入力を、受付側のルールで自動変換することを容認する理屈ですよね。
自治体は、住民の住所の届け出に対して、記載ルールに反するからと修正を要求するのではなく、そのまま受け付けてから、内部で記載ルールに沿って修正しているわけですから。
Re: (スコア:0)
一応補足しておくと、内部のデータベースのレコードとか管理用システムがどうなっているかいう話じゃなくて、住民に対して発行する印刷物（住民票の写し、戸籍の附票、各種証明書など）など見える場所をどうするかです。
見える場所の住所表示の算用数字はいわゆる全角に統一されています。
Re: (スコア:0)
昔の「OS毎に文字コードが違っていた名残り（コード変換にシビアだった時代のトラウマを上層部が持っている）」説はいかがでしょう？
＃ホスト機（各メーカー別）、VAX、UNIX、MAC、MS-DOS、OS/2、で差があった時代
＃半角カナ問題があったり、Lynx [browser.org]からのアクセス対応が必要だった時代とか、実際に自分は文字コード対応で苦労したし
本当に望まれてるのは全角・半角変換？ (スコア:0)
一応補足しておくと、振り込みなどで使用される口座名義（カナ）には、小文字のカナ文字、一部の
記号が使用できません。また現在の多くのデータベースはUnicodeを特定のUTF-8にエンコードして
永続化できますが、少し昔のデータベースは基本はMS-SJISを前提に作られています。また、多くの
ライブラリで全角・半角変換？があるような言語ライブラリを見たことがありません。
本当に必要とされているのが全角・半角変換？だとすれば当然ながら、ウェブ系のフルスタックである
フレームワークには開発者が書かなくても呼び出すことが可能なライブラリが搭載されていると思う。
また現在のブ
Re: (スコア:0)
>> もちろん使用者の利便性を考えれば、自動変換の方が大変優れて便利でしょうし、パスワードの画面で
>> 2回入力させるのも本来であれば手間だけで、一部の誤入力を防止する効果はあるものの、多くの人が
>> コピーペーストを使用していたりします。
わざわざコピペできなくしてるところがあるよね。
キー入力をスクリプトで抑止して。
しかし、選択してCTRL+ドラッグでコピペできてしまうのであった。
ただ乗りできてしまいそう (スコア:0)
ユーザー（WEB閲覧者）が郵便番号を入力 → WEBサーバー → 変換サービス → WEBサーバー → ユーザー
というような通信に無駄のある変換だけでなく、
ユーザーが郵便番号を入力 → 変換サービス → ユーザー
とユーザーのブラウザーから変換サーバーに直接アクセスして変換できるみたいだけど、
APIのスタートガイドを見るとクロスオリジンするドメインをAPI設定画面で指定するだけクロスオリジンリソース共有が有効になるっぽい？
アクセス権限管理のためのトークンをやりとりする仕組みがなさそうだから、
> Access-Control-Allow-Origin: （誰か契約してる人のドメイン）
をつけたhttpリクエストを発行すれば、この変換サービスにお金を払わなくても使えてしまうという穴がありそう。対策できてるのかな。
＃アクセス数制限なしの定額制だし他人事ながらこれでやっていけるのかちょっと心配
Re:ただ乗りできてしまいそう (スコア:1)
いや、それじゃ無理でしょ。どういう想定よ。
そもそもAccess-Control-Allow-OriginはHTTPリクエストじゃなくてHTTPレスポンスに使うヘッダーだが。
何か勘違いしとりゃせんか？
Re: (スコア:0)
サーバ介するのを無駄とかいっちゃってる時点で。
穴があるとすれば通常のブラウザ以外のプログラムからのリクエストは防ぎようがなさそうというところだろうが、
ブラウザから直でアクセス可能にしてる時点で構造上そうなる。
おそらくそういった利用者は最初から見込んでるんだろう。
住所を入れたい普通のネット利用者を相手にするアプリで利用してくれればOKと。
会社によっちゃ企業が提供していない無料のAPIはしれっと閉じるリスクから使えないところもあるのでそういう需要はありそう。