これだけは押さえよう!住所フォームの作り方

まとめ

f:id:kenall:20220225163230p:plain
住所フォームの作り方

住所フォームを作るときには以下の4つを押さえましょう。

  1. オートコンプリート機能に最適化する
  2. 郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する
  3. モバイルUX優先なら郵便番号が入力されたら即座に補完。精度優先なら郵便番号補完ボタンを設置
  4. 住所フィールドは「都道府県」「市区町村」「町名以下」の3フィールドが基本。「建物」フィールドはオプション

本文

地域SNSのユーザー登録、ECサイトの配送先入力、資料請求、自治体サイトでの電子申請など、ウェブサービスを活用する上で住所入力は欠かすことができません。

住所入力をシンプルかつ正確に行えるような入力インタフェース(住所フォーム)は、離脱率を減らし、コンバージョン率を向上させる上で重要です。

郵便番号を入力すると対応する住所を自動入力する機能(郵便番号による住所補完)は、住所フォームの改善方法として最も効果的な改善策の一つです。

ユーザーが住所入力を手動で行うと、以下のような問題が発生します。

  • 入力の煩雑さにより登録をあきらめてしまう(離脱率の増加)
  • 間違った住所により配送ミスが発生(対応コストの増大、コンバージョン率の低下)

郵便番号による住所補完を使うことで、この問題の影響を大きく減らすことができます。

使いやすい住所フォームを作るには、以下の点に注意するのが基本です。

  • 入力フィールドを少なくする
  • 何をどう入力したらいいかユーザーに伝わるよう、ラベルに適切な名前と例を表示する
  • 可能な限り柔軟に入力を受けつける(全角・半角両対応、ハイフン有無両対応など)

これらの基本を踏まえた上で、住所フォームで郵便番号による住所補完を使うときのベストプラクティスを紹介します。

デモ

今回紹介するベストプラクティスを元にした、React + TypeScriptのデモアプリを用意しました。(本記事で紹介する全機能を網羅しているわけではありません)デモアプリはこちらから試せます。ソースコードこちら

住所フォームデモアプリ
住所フォームデモアプリ

2022/2/28 20時30分追記 ブックマークのコメントで「リセットボタン」に関するご指摘をいただいておりますが、これはデモで補完入力の試行を容易にするために便宜的に設置してあるもので、ケンオールの見解として住所入力フォーム一般でリセットボタンを配置することをお勧めしてはおりません。むしろ設置してはいけないものです。誤解を招くような表示となってしまい申し訳ございませんでした。

オートコンプリート機能に最適化する

オートコンプリート機能に最適化する

Google ChromeSafariFirefoxなどのWebブラウザでは、住所などのデータをフォームに自動入力するオートコンプリート機能(オートフィル機能)が備わっています。 しかし、ユーザーが適切にこの機能を使えるようにするためには、フォームがオートコンプリートに最適化している必要があります。

オートコンプリート機能に最適化されていないと、自動入力が機能しないばかりか、間違った値が入力されてしまうこともあります。 それらの訂正によって余計に手間が増えてしまい、ユーザーのストレス向上や離脱につながります。

オートコンプリート機能に最適化して、フォーム入力の手間を減らすようにしましょう。

住所フォームにおけるオートコンプリート要素

ブラウザは、HTMLフォームのオートコンプリートを実行するとき、フォーム要素のいくつかの属性をヒントとして、その要素がどの項目に該当するのかを決定します。どの属性値がどのように使われるかは最終的にブラウザの実装によりますが、属性の一つであるautocomplete属性の仕様はWHATWG HTML 標準で定義されています。 標準に含まれる属性値のバリエーションは多数にのぼりますが、Googleの開発者向けサイトでは、よく使われるautocomplete属性値を例示しています。

ここでは、さらに、それらのうち住所に関係する要素を紹介します。

  • 郵便番号: postal-code
  • 国名: country
  • 都道府県: address-level1
  • 市区町村: address-level2
  • 住所(1フィールド形式): street-address
  • 住所(2フィールド形式): address-line1 および address-line2

住所形式は、1フィールド形式か2フィールド形式のいずれか一方のみを使用します。

オートコンプリートのhtmlサンプル

<form>
  <label>
    <span>郵便番号</span>
    <input type="text" name="postal_code" minlength="7" maxlength="8" pattern="\d*" autocomplete="shipping postal-code">
  </label>
  <label>
    <span>都道府県</span>
    <select name="prefecture" autocomplete="shipping address-level1">
      <option value="北海道">北海道</option>
      ...
    </select>
  </label>
  <label>
    <span>市区町村</span>
    <input type="text" name="city" autocomplete="shipping address-level2">
  </label>
  <label>
    <span>町名・番地</span>
    <input type="text" name="address1" autocomplete="shipping address-line1">
  </label>
  <label>
    <span>建物名等</span>
    <input type="text" name="address2" autocomplete="shipping address-line2">
  </label>
</form>

郵便番号フィールドは1フィールドにまとめ、ハイフン有無に両対応する

郵便番号フィールドは1フィールドにまとめる

郵便番号入力フィールドのデザインは、大きく分けて3パターンあります。

  1. 1つだけの郵便番号フィールド、ハイフンありなし両対応
  2. 1つだけの郵便番号フィールド、数字7桁のみ受けつけてハイフン不可
  3. 郵便番号3桁のフィールド + 郵便番号4桁のフィールド

郵便番号のオートコンプリート要素はpostal-code1つのみです。 3桁-4桁の2フィールド形式ではオートコンプリートに対応できないため、なるべく採用しないようにしましょう。

オートコンプリート要素postal-codeはテキスト形式のため、郵便番号がハイフンを含んでいることもあります。 フォームではハイフンの有無に両方対応しておき、フォーム送信時にバックエンドAPIの要求する形式へ変換するようにしましょう。

今回調査したサービスのうち8割が1フィールドで設計していましたが、その大半はハイフンなしのみ受けつける設計でした。

1フィールドでハイフン有無両対応しているサービスは全てECサイトの配送先登録フォームでした。

住所補完は即時補完かボタン式の二択

住所補完は即時補完かボタン式の二択

郵便番号を入力した後に住所を補完するユーザーインタフェース(UI)には以下の3パターンがあります。

  1. 郵便番号を入力した後、即座に住所を補完する
  2. 郵便番号補完専用のボタンを用意し、ボタンを押下すると住所を補完する
  3. 住所補完専用の画面を開き、住所選択を完了すると元の画面に戻る

パターン3を選択することはまれで(後述)、基本的にはパターン1か2の二択となります。

郵便番号を入力した後、即座に住所を補完する

郵便番号を入力して即座に住所を補完するUIは、少ない操作で住所補完できることが特徴です。 派生型として、入力後にエンターキーを押してから補完するUIもあります。 モバイル環境では、後述するボタン押下式や別ウィンドウ式の操作は手間がかかるため、この方式を選択するのがおすすめです。

しかし、いくつか注意点もあります。

一つ目は、前述のブラウザによるオートコンプリートを邪魔するような実装にしないということです。 補完のタイミング次第ではブラウザがオートコンプリートで住所の値を入力した直後に郵便番号補完が実行されてしまい、オートコンプリートの値が上書きされてしまうことになりかねません。 これでは、せっかくのUXが台なしになってしまいます。

二つ目は、郵便番号が複数の住所に対応している場合、この方法ではユーザーの意図した住所を選択できない可能性があるということです。

例えば、以下の郵便番号は複数の都道府県にまたがっています。

4980000 愛知県 弥富市
4980000 三重県 桑名郡木曽岬町

6180000 京都府 乙訓郡大山崎町
6180000 大阪府 三島郡島本町

8710000 福岡県 築上郡吉富町
8710000 大分県 中津市

これ以外にも、大字や小字のレベルで違う住所が同じ郵便番号になっているケースが多数あります。これらのようなケースを想定して、ユーザーが手入力で補完された住所を変更できるようにしておく必要があります。

今回調査した結果では、調査対象のサービスのうち半分が入力後即時補完あるいはエンター入力後補完のUIを選択していました。

郵便番号補完専用のボタンを用意し、ボタンを押下すると住所を補完する

郵便番号補完専用のボタンを用意するUIは、ボタンを押す動作が増えるため、ユーザーは多少手間が増えます。 しかし、明示的にボタンを押す場合、ユーザーはこれから住所補完をすることがわかっています。 その場合、複数の住所候補がある場合にモーダルを表示して選択するUIなどを自然に導入できます。 極力ユーザーの手入力を減らしたい場合にはこのUIが効果的です。

選択UIを設計する場合、郵便番号レコードの最大個数に注意してください。

2021-11-30 時点のデータで最も多くの町名にまたがっている郵便番号は愛知県清須市4520961で、66件あります。

郵便番号全体の90%は8件以下のレコードしかありませんので、以下のような設計が考えられるでしょう。

  • (設計方針1) 8件まではモーダルで選択、それ以上のレコードを持つ郵便番号はスクロールバーを使って表示
  • (設計方針2) 8件までは都道府県・市区町村・町名を表示、それ以上のレコードを持つ郵便番号は都道府県・市区町村のみを表示(この場合最大でも2件)

モバイル環境の場合、ボタンを押してモーダルから選択する操作はかなり手間がかかることに注意してください。 モバイルからのアクセスが多い場合は、オートコンプリートに最適化して極力ボタンを押下する機会を減らすか、即座に住所補完するUIを選択した方がいいでしょう。

住所補完専用の画面を開き、住所選択を完了すると元の画面に戻る

住所補完専用の画面を開くUIは、ページ遷移や同時に開くウィンドウの数が増えるなど、ユーザーの負担が大きくなります。 候補が一つであっても明示的にユーザーに選択させたい、選択対象の住所候補に付加情報を表示したい、といった場合に効果的なUIです。

モバイル環境の場合、ボタンを押下するUIよりもさらに手間がかかることに注意してください。 モバイルからのアクセスが多い場合は極力このUIを避けた方が無難です。

今回調査した結果では、住所補完専用の画面を開くUIを選択していたサービスは全て金融系のサービスでした。

エラー処理は住所補完UIに応じたものを選ぶ

エラー処理は住所補完UIに応じたものを選ぶ

(2022年3月1日追記: 郵便番号データベースに登録のない郵便番号が指定された際、住所入力を先に進ませないような誤解を招きかねないメッセージ文言が上図の例にありましたが、これは意図するところではありませんので、図を修正させていただきました。ご指摘に感謝します。)

入力した郵便番号が間違っているなどの理由で住所補完に失敗した場合(クライアント側の問題)、その原因を簡潔にユーザーに伝えるべきです。

一方、APIからの応答がないなど、サーバーサイドエラーの場合、住所補完UIに応じて設計を変えていきます。

即時補完UIを採用している場合、ユーザーは意図して補完を行っているわけではないので、住所補完に失敗してもあえてエラーを出す必要はないかもしれません。 ユーザーは補完機能があることに気づかないまま、住所を手入力してくれるでしょう。

住所補完ボタンなどのUIを採用している場合、ユーザーは補完を意図して行っているので、住所補完に失敗した場合はサーバーサイドのエラーであることを表示した方が親切です。

住所フィールドはなるべくまとめ、手入力を可能に

住所フィールドは3あるいは4フィールドに分割

補完対象である住所フィールドに含める要素は以下のものがあります。

  • 都道府県
  • 市区町村
  • 京都の通り名
  • 町名・大字
  • 丁目・小字
  • 番地以下
  • 建物名・階層・部屋情報

「京都の通り名」と「丁目・小字」が同時に出現することはありませんので、実際には「京都の通り名 + 町名・大字」あるいは「町名・大字 + 丁目・小字」のどちらか一方の表記になります。

日本の住所構造については、ケンオール通信第7号: 日本の住所の構造と郵便番号データも参照してください。

各サイトの住所フォームを調べてみると、フィールドの構成はバラバラでした。 今回調査したサービスでは以下のように分かれていました。

  • 都道府県」プルダウン
    • 「市区町村 + 町名・大字」
      • 「番地以下」+ 「建物名・階層・部屋情報」
      • 「番地以下」
    • 「市区町村」
      • 「町名以下」
      • 「町名以下」+ 「建物名・階層・部屋情報」
    • 「市区町村」プルダウン + 「町名以下」
    • 「市区町村 + 町名以下」 + 「建物名・階層・部屋情報」
  • 「住所」フィールドのみ
  • 都道府県 + 市区町村 + 町名・大字」(ユーザー変更不可) + 「丁目・小字以下」 + 「建物名・階層・部屋情報」

住所フィールドの設計は、都道府県、市区町村、町名以下(、建物名・階層・部屋情報)に分割するのがおすすめです。

このレイアウトは、以下のようなメリットがあります。

  • 地域情報を階層的に保存できるので、地域別データ分析やユーザーの地域属性ごとのコンテンツ提供などに応用しやすい
  • フィールドごとに適した入力ルールを適用できるため、表記ゆれや誤入力を減らせる

都道府県と市区町村で表記ゆれが発生することはありません。 ユーザーがこのフィールドを操作するのはオートコンプリートや住所補完が動作しない場合だけなので、後段のフィールドと分けておくと誤入力を避けることができます。

2021年11月30日現在、郵便番号データ上の最長の自治体名は南都留郡富士河口湖町で、10文字あります。 市区町村フィールドは漢字10文字が収まるだけのスペースを確保します。

都道府県や市区町村を編集不可にすれば誤入力を防ぐ効果は高まりますが、もしオートコンプリートや住所補完UIで期待する住所が表示されなかった場合、ユーザー自身で修正する手段がなくなってしまいます。 フィールドを分けるなどにとどめ、ユーザーの手入力は許可しておきましょう。

町名以下のフィールド形式は、オートコンプリートの住所フィールドのどちらに対応するかで異なります。

  • street-addressのみの1フィールド形式に対応する場合:「町名以下」
  • address-line1 + address-line2の2フィールド形式に対応する場合:「町名以下」と「建物名・階層・部屋情報」

「町名以下」には、「京都の通り名 + 町名・大字 + 丁目・小字 + 番地以下」をまとめて格納し、必須フィールドとします。

「建物名・階層・部屋情報」を使う場合、ユーザーがマンション等の建物に住んでいるかどうかは分からないため、任意フィールドとしておきます。

かつては住所フィールドを全角固定にするUIが多数見られましたが、現在は全角・半角両対応するのが一般的です。 サーバサイドの側の要件で全角固定にせざるをえない場合でも、送信時に全角変換するなどして、UI上はなるべく全角・半角両対応にしましょう。

住所フィールドを1つにまとめる

住所フィールドを1つにまとめると、レイアウトがシンプルになりますが、デメリットもあります。

1つ目は、オートコンプリートがうまく機能しないことです。address-level1都道府県)や address-level2 (市区町村)を用いずに street-address のみを利用しなければいけません。多くのユーザーはオートコンプリート機能を使って正常に住所を補完することができないでしょう。

2つ目は、1フィールドでは住所階層ごとの入力ルールを設定できないため、誤入力や表記ゆれの問題が発生しやすくなることです。 配送ミスなど、間違った住所によるコスト増が無視できない場合には避けた方がいいでしょう。

3つ目は、都道府県や市区町村を分割保存できないため、全国地方公共団体コードなどを用いたデータの正規化・圧縮が行えなくなることです。 全国規模の大サービスなど、住所情報のデータ量が無視できないような大規模システムの場合はデータ量の増加にも注意する必要があります。

必要がない限りは、この設計を選択しないことをおすすめします。

ケンオールAPIを使う場合

これらのベストプラクティスに基づきケンオールAPIを使う場合、以下の点に注意してください。

APIについての詳細は郵便番号APIのドキュメントを参照してください。

リクエスト時の郵便番号パラメーターは数字7桁固定

サーバサイドでハイフン除去等の処理は行いませんので、クライアントサイドで数字7桁になるようにしてからリクエストしてください。

レスポンスデータは配列

レスポンスに含まれる住所データは配列で返ってきます。

クライアント側で複数の住所データに対応できるようにしておくことを推奨します。

即時型の住所補完を使う場合など、複数の住所データに対応できない場合は、配列の最初の要素を取得してください。 小字なしの住所が取得できるようになっています。

ただし、(その他)を含む町域など、一部の住所では小字なし住所が配列の最初の要素になっていないものもあります。

詳細はケンオール通信第9号:(その他)の処理を参照してください。

また、複数の町域にまたがる郵便番号の場合、2つ目以降の町域に対応する方法はありません。

データに含まれるtown_multiフラグがtrueの場合、その郵便番号は複数の町域にまたがっています。

例えば、0040000札幌市厚別区札幌市清田区にまたがっています。

  {
    "postal_code": "0040000",
    "prefecture": "北海道",
    "city": "札幌市厚別区",
    "town": ""
  },
  {
    "postal_code": "0040000",
    "prefecture": "北海道",
    "city": "札幌市清田区",
    "town": ""
  }

レスポンスを住所文字列に変換するときのデータの順序

「町名以下」には、以下のようにデータを連結して格納してください。

kyoto_street + town + koaza

終わりに

郵便番号による住所補完はシンプルなUIですが、ユーザーの離脱を減らすために考慮すべき点はいくつもあります。

正しく設計・実装して、KPIの向上につなげていきましょう。

ケンオールでは住所フォームの設計や実装の相談についても承っています。

ご興味のある方はこちらからお問い合わせください。

ケンオールについて

「かゆいところにケンオール」 ケンオールは、郵便番号住所検索APIをはじめとした、システム開発を加速する高品質で安全なAPIサービスです。 サービスを試してみたい方はこちらから: kenall.jp

Shodoで執筆されました

新プラン「郵便番号APIプラス」を正式リリースしました

前回の記事でお伝えした通り、本日2022/02/21(月)にケンオールのアップデートを実施しました。

アップデート内容についてもう一度ご紹介します。

  • 郵便番号逆引きAPIの正式版リリース: フリーテキスト検索機能の追加
  • 住所正規化機能のリリース: 郵便番号逆引きAPIに同梱
  • 法人番号API: 法人住所の住所要素分割フィールドを追加
  • 郵便番号API: 個別事業所番号の住所要素分割フィールドを追加

郵便番号逆引きAPIや住所正規化機能は、こちらのデモからお試しいただけます。

APIのリファレンスは以下のとおりです。

郵便番号逆引きAPI

法人番号APIのレスポンス

郵便番号APIのレスポンス

郵便番号APIプラス

郵便番号逆引きAPIは、新プランの「郵便番号APIプラス」の中に含まれます。

郵便番号APIプラスには、郵便番号から住所を検索する郵便番号正引きAPIも含まれております。

また、法人番号APIプランをご購入のお客様は、郵便番号APIプラスの全機能をご利用いただけます。

価格とトライアル

「郵便番号APIプラス」の価格は、33,000円/月(税込)となります。*1 APIリクエスト数に制限はありません。 アカウントを作成してから60日間はトライアルとして無償利用できますので、まずはアカウント登録してお試しください。

サポート、SLA、専用テナントなどの非機能要件は付属しておりません。もしそういった要件がございましたらエンタープライズプランをご検討ください。

ケンオールについて

「かゆいところにケンオール」 ケンオールは、郵便番号住所検索API、郵便番号逆引きAPI、住所正規化API、法人番号APIなど、システム開発を加速する高品質で安全な住所オープンデータAPIサービスです。 kenall.jp

Shodoで執筆されました

*1:2022/02/21時点。金額は予告なく変更する場合があります

リリース一周年とアップデートのお知らせ

ケンオールは2022年2月8日でリリースから一周年になりました。 いつもご利用いただいているユーザーの皆様、本当にありがとうございます。

この一周年という節目に、ケンオールは大きな機能追加を実施いたします。 変更予定日は2/21(月)となります。

重要 ケンオールユーザーはシステム側の対応が必要となりますので本記事をご一読ください。同様の案内をメールでも送付させていただいております。

郵便番号逆引きAPI(正式版)

2021年5月にベータリリースした郵便番号逆引きAPIを正式版としてリリースします。 郵便番号逆引きAPIは、住所から郵便番号を検索する機能を提供するAPIです。

正式版では、以下の機能が追加されています。

  • フリーテキスト検索
  • 住所正規化

郵便番号逆引きAPIは、新プランの「郵便番号APIプラス」でご利用いただけます。

法人番号APIプランをご購読のお客様は、郵便番号APIプラスの全ての機能をご利用いただけます。

フリーテキスト検索

ベータ版では東京都 千代田区 麴町のようにユーザーが自分で住所要素(都道府県、市区町村など)ごとにスペースで区切らなければいけませんでした。 また、3丁目12-14麹町駅前ヒルトップ8階のような番地やビル名の情報が入っているとうまく検索できないという問題がありました。

正式版では東京都千代田区麹町3丁目12-14麹町駅前ヒルトップ8階と文字列をそのまま入力するだけで検索できます。

https://api.kenall.jp/v1/postalcode/?t=東京都千代田区麹町3丁目12-14麹町駅前ヒルトップ8階

実行すると、以下のようなレスポンスが返ります。(一部のみ表示)

{
  "version": "2021-12-28",
  "data": [
    {
      ...
      "postal_code": "1020083",
      ...
      "prefecture": "東京都",
      "city": "千代田区",
      "town": "麹町",
      ...
    },
    ...
   ],
 ...
}

住所正規化

フリーテキスト検索で入力した住所を住所要素ごとに分割して出力します。 例えば、東京都千代田区麹町3丁目12-14麹町駅前ヒルトップ8階と入力すると、以下のように分割します。

  • 都道府県 東京都
  • 市区町村千代田区
  • 町名 麴町
  • 丁目・番地 3-12-14
  • ビル名 麹町駅前ヒルトップ
  • 階層・部屋番号 8階

分割するだけでなく、丁目・番地については「半角数字・ハイフン区切り」に整形しています。例えば、以下の丁目・番地文字列は全て同じ結果3-12-14を出力します。

  • 3丁目12-14
  • 3丁目12番14号
  • 3-12番地14

実際のレスポンス例は以下の通りです。qtは検索時に入力されたクエリ文字列です。

  "query": {
    "q": null,
    "t": "東京都千代田区麹町3丁目12-14麹町駅前ヒルトップ8階",
    "prefecture": "東京都",
    "county": null,
    "city": "千代田区",
    "city_ward": null,
    "town": "麹町",
    "kyoto_street": null,
    "block_lot_num": "3-12-14",
    "building": "麹町駅前ヒルトップ",
    "floor_room": "8階"
  }

法人番号API: 法人住所の住所要素分割フィールドを追加

従来の法人番号APIでは、法人番号データに記載されている住所データをそのまま出力していました。 法人番号データでは、町名以下の住所は1つのフィールドに格納されています。

{
      ...
      "prefecture_name": "東京都",
      "city_name": "千代田区",
      "street_number": "麹町3丁目12-14麹町駅前ヒルトップ8階",
      ...
}

しかし、住所フォームで住所補完UIを作成する際に、ビル名以下が分割されていないと不便だという要望をお客様からいただきました。 そこで、住所フィールドを「町名」「京都の通り名」「号番地」「ビル名」「階層・部屋番号」の5つの住所要素に分割するように変更しました。

以下は、法人番号APIのレスポンスの例です。(一部のみ表示)

{
      ...
      "prefecture_name": "東京都",
      "city_name": "千代田区",
      "street_number": "麹町3丁目12-14麹町駅前ヒルトップ8階",
      "town": "麹町",
      "kyoto_street": null,
      "block_lot_num": "3-12-14",
      "building": "麹町駅前ヒルトップ",
      "floor_room": "8階",
      ...
}

郵便番号API: 個別事業所番号の住所要素分割フィールドを追加

個別事業所番号データには丁目・番地以下を格納するblock_lotというフィールドが存在します。

        "block_lot": "2丁目8-1",

このフィールドに対しても正規化処理を行い、住所要素に分割して出力するようにしました。 例えば、上記住所は新たに追加されたblock_lot_numというフィールドで以下のように正規化されます。

        "block_lot": "2丁目8-1",
        "block_lot_num": "2-8-1",

リリースのスケジュールとシステム対応のお願い

このアップデートは2/21(月)に実施予定です。

ケンオールユーザーの皆様は以下の対応をお願いいたします。

APIに対して直接リクエストしている場合、あるいは内製クライアントライブラリを開発している場合

APIのレスポンスに追加されるフィールドを問題なく受け付けることができるかどうか、ご自身のシステムあるいはライブラリをご確認ください。 既存のフィールドに変更はありません。

公式JavaScript SDK kenall-js をご利用されている場合

公式 JavaScript SDK kenall-jsをご利用の場合は、既にリリース済みの kenall-js 1.6.0以上にアップグレードをお願いいたします。

ケンオールについて

「かゆいところにケンオール」 ケンオールは、郵便番号住所検索APIをはじめとした、システム開発を加速する高品質で安全なAPIサービスです。 サービスを試してみたい方はこちらから: kenall.jp

Shodoで執筆されました

2022年1月21日の接続障害に関するお知らせ (第1報)

日本時間の2022年1月21日9時23分ごろから10時36分ごろまで、ケンオールの提供するAPIサービスが正しくない応答を返す事象が発生しておりました。原因については引き続き調査中ですが、対応の経緯および現在明らかになっている内容を技術的な部分も含めお伝えいたします。

この度は大変ご迷惑をおかけし、誠に申し訳ございませんでした。

障害の発生していた時間

  • 開始: 2022/1/21 9:23 JST ごろ
  • 終了: 2022/1/21 10:36 JST ごろ

影響範囲

ケンオールの提供するAPIサービスとなります。

問題の発生していた箇所

  • 郵便番号API
  • 郵便番号逆引きAPI
  • 法人番号API

問題の発生していなかった箇所

タイムライン

日時 イベント
2022/01/21 09:36 JST 弊サービスを担当するエンジニアに対して、外形監視による最初のアラートが発報される
2022/01/21 09:37 JST 対応を開始。郵便番号APIで断続的に404が返却される事象を確認
2022/01/21 09:48 JST 自己IPアドレス確認APIを除く全APIで問題が発生していることを確認
2022/01/21 09:59 JST 最初の障害報をTwitterにて行う https://twitter.com/kenalljp/status/1484329763510824963
2022/01/21 10:20 JST リクエストログの調査の結果、2022/01/21 9:23 JSTごろに、弊サービスが利用するIaaSの設定の一部が、弊社設計とは異なる内容となっていることが確認される
2022/01/21 10:28 JST 状況を保全し、設計と異なる設定を含むリソースを削除する
2022/01/21 10:36 JST 問題が継続しなくなっていることをを確認。しばらく状況を静観する
2022/01/21 10:45 JST 回復報をTwitterにて行う https://twitter.com/kenalljp/status/1484341235628539904

発生原因

発生当時のエンジニアの作業内容を監査ログも含め確認しましたところ、試験環境も含めIaaSに関連する操作を行なっていないことが判明したため、現時点では人為的なものが起因ではないと判断されます。 IaaSのサポートに状況をエスカレーションするとともに、引き続き原因の究明を行ってまいります。

徹底解説!郵便番号データの処理方法

日本郵便様が公開している郵便番号データを利用しやすくするには、複雑な加工処理が必要になります。

ケンオール通信では、過去数回に渡り、郵便番号データの処理方法を解説してきました。

本シリーズの締めくくりとして、今までの解説をまとめて紹介します。

データは、記載がない限り2021-11-30のデータを用いています。

郵便番号データの処理方法まとめ

f:id:kenall:20220112114413p:plain
郵便番号データ処理で押さえるポイントは4つ

郵便番号データを処理するには、以下の4つのポイントを押さえてください。

  • 複数行に分割されたレコードを1行にまとめる
  • 括弧つきのレコードを括弧の外側と内側で分割する
  • 括弧内の文字列を処理する
  • ビル郵便番号を処理する

複数行の結合

郵便番号データでは、1レコードが複数レコードに分割されて格納されている場合があります。

一般的なテーブル形式で扱うために、まず複数レコードを結合します。

詳細は複数行のレコードの結合処理を参照してください。

括弧つきのレコードの分割

郵便番号データ120,372件のうち全体の8.2%、10,551件に括弧がついています。

括弧つきの住所は以下の5パターンがあります。

  • 町名 + 括弧(丁目、小字、番地など)
  • 町名 + ビル名 + 括弧(階層)
  • 町名 + 番地 + 括弧
  • 町名、町名 + 括弧
  • 町名 + 地割 + 括弧

上記パターンのうち町名 + 番地 + 括弧町名、町名 + 括弧町名 + 地割 + 括弧は例外的なパターンです。

処理方法の詳細はケンオール通信第11号:括弧つきの町域(1) 括弧の内側と外側の分割を参照してください。

括弧内の処理

ケンオールでは、括弧内の丁目、小字、京都の通り名は可能な限り保持します。

範囲が指定されている場合や複数併記される場合は複数レコードに展開します。

丁目

2080032 東京都 武蔵村山市 三ツ木(1~5丁目)

「丁目」の他、「丁」「地割」などが出現した場合はそれらを複数レコードに展開します。

詳細はケンオール通信第12号:括弧つきの町域(2) 丁目や番地の処理を参照してください。

小字

0580343 北海道 幌泉郡えりも町 東洋(油駒、南東洋、132~156、158~354、366、367番地)

括弧内に「数字でない、かつ京都の通り名でない文字」が出現した場合は基本的に「小字」として保存します。

ただし、(丁目)(その他)といったコメント文字列は除外します。

詳細はケンオール通信第13号:括弧つきの町域(3) 小字、かぎ括弧、区切り文字の処理を参照してください。

京都の通り名

京都府京都市の一部の郵便番号レコードには、京都の通り名が付与されています。

6028064 京都府 京都市上京区 一町目(上長者町通堀川東入、東堀川通上長者町上る、東堀川通中立売通下る)

ケンオールではこれらの通り名を展開し、可能な限り上記のような元データに記載されている住所を復元できるようにしています。

詳細はケンオール通信第14号:括弧つきの町域(4) 京都の通り名を参照してください。

(その他)

ケンオールでは、意図しない小字・丁目が表示されてしまう場合に備え、小字を含まないレコードも出力するようにしています。

しかし、(その他)が含まれている町域の場合、(その他)をそのまま削除してしまっては小字なしのレコードが二重に出力されてしまいます。

そうした問題を避けるため、(その他)を含む郵便番号を持つ町域については小字なしのレコードを出力しないようにしています。

詳細はケンオール通信第9号:(その他)の処理を参照してください。

かぎ括弧

郵便番号データ内の括弧は丸括弧()だけではありません。かぎ括弧「」や甲括弧〔〕も存在します。

9996652 山形県 鶴岡市 添川(渡戸沢「筍沢温泉」)

ケンオールでは、「」内が数字以外で始まっている場合は便宜上小字の一部として残し、その他のケースは全て削除しています。

詳細はケンオール通信第13号:括弧つきの町域(3) 小字、かぎ括弧、区切り文字の処理を参照してください。

区切り文字

住所を併記する場合、ほとんどのケースでは読点「、」を区切り文字としていますが、中黒「・」や「及び」を使う場合もあります。

9401172 新潟県 長岡市 釜ケ島(土手畑・藤場)

詳細はケンオール通信第13号:括弧つきの町域(3) 小字、かぎ括弧、区切り文字の処理を参照してください。

ビル郵便番号

郵便番号データの大半は、ある郵便区画に対して番号を割り当てたレコードとなっていますが、一部の高層ビルでは階層ごとに郵便番号が割り振られています。

ケンオールではこのような郵便番号をビル郵便番号と呼んでいます。

ビル郵便番号は町名 + ビル名 + 括弧(階層)のパターンで記載されています。

1066101 東京都港区六本木六本木ヒルズ森タワー(1階)

このレコードを町名六本木とビル名六本木ヒルズ森タワーに分割する場合、データを遡って以下のレコードを見つけ出し、町名を抽出する必要があります。

1060032 東京都 港区 六本木(次のビルを除く)

詳細はケンオール通信第8号: ビル名の処理を参照してください。

まとめ

郵便番号データは複雑ですが、一つ一つ丁寧に処理していけば決して難しいものではありません。

是非皆さんも挑戦してみてください。

「自分では難しい!」と思った人は、ぜひケンオールを使ってみてください。 60日間無料で試せます。アカウント登録はこちらから!

ケンオールについて

「かゆいところにケンオール」 ケンオールは、郵便番号住所検索APIをはじめとした、システム開発を加速する高品質で安全なAPIサービスです。 サービスを試してみたい方はこちらから:

kenall.jp

Shodoで執筆されました

ケンオール通信第14号:括弧つきの町域(4) 京都の通り名

ケンオール通信第13号:括弧つきの町域(3) 小字、かぎ括弧、区切り文字の処理では、括弧内の処理のうち、小字、かぎ括弧、区切り文字の処理方法について紹介しました。

今回は京都の通り名の処理を紹介します。

データは、記載がない限り2021-11-30のデータを用いています。

処理結果を確認してみたい方はこちらのデモから試してみてください。

京都の通り名

京都府京都市の一部の郵便番号レコードには、京都の通り名が付与されています。(例1)

6028064 京都府 京都市上京区 一町目(上長者町通堀川東入、東堀川通上長者町上る、東堀川通中立売通下る)

京都の市街地には278の町が存在しますが、同一区で同一町名を持つ町が120組もあります。

例えば京都府京都市上京区一町目は、先の例の他にもう一つあります。(例2)

6028134 京都府 京都市上京区 一町目(大宮通椹木町下る、大宮通丸太町上る、椹木町通大宮西入、丸太町通大宮東入)

京都の郵便局(東山郵便局様、下馬郵便局様)に確認したところ、郵便番号さえ合っていれば通り名を書かなくても荷物は届くとのことです。

しかし、ケンオールではこれらの通り名を展開し、可能な限り元のレコードの住所を復元できるようにしています。

京都の通り名の展開

展開方法そのものは簡単です。

小字だけを併記するパターンと同じく、単に複数行に展開するだけです。

例1を展開すると以下のようになります。

6028064 京都府 京都市上京区 一町目 上長者町通堀川東入
6028064 京都府 京都市上京区 一町目 東堀川通上長者町上る
6028064 京都府 京都市上京区 一町目 東堀川通中立売通下る

住所表記における京都の通り名

京都の通り名は小字と住所表記の順序が異なるため、独立したフィールドに格納する必要があります。

ケンオールでは、小字や丁目を格納するフィールドkoazaとは別に、京都の通り名専用のフィールドkyoto_streetに格納しています。

出力結果から住所文字列を作成する場合、以下の順序で組み立てます。

都道府県 + 市区町村 + 京都の通り名 + 町名 + 小字

京都の通り名と小字が同時に出現することはありませんので、条件分岐を行う必要はなく、上記の式のみで文字列を組み立てられます。

ケンオールAPIのレスポンスを使う場合は以下のようになります。

prefecture + city + kyoto_street + town + koaza

上記の式を例1の結果に適用すると、以下のようになります。

京都府京都市上京区上長者町通堀川東入一町目
京都府京都市上京区東堀川通上長者町上る一町目
京都府京都市上京区東堀川通中立売通下る一町目

ケンオールAPIレスポンスの詳細についてはドキュメントを参照してください。

京都の通り名における「丁目」

京都の通り名には、「丁目」を含むものがあります。

6050874 京都府 京都市東山区 常盤町(東大路通渋谷上る、渋谷通東大路東入、渋谷通東大路東入2丁目、東大路五条下る)

多くの地域において丁目とは町のある区画を指しますが、今尾恵介著「番地の謎」(光文社知恵の森文庫)によれば、京都の通り名で使われる丁目は距離を示すためのものです。

この例の場合、渋谷通東大路東入2丁目とは「渋谷通(しぶたにどおり)を進み、東大路通り(ひがしおおじどおり)からさらに東に2丁(約218m)分進む」という意味となります。

そのため渋谷通東大路東入2丁目全体で京都の通り名に相当する住所表記であるというのが正しい解釈となります。2丁目を他の地域における「丁目」と同列に扱わないよう注意してください。

なお、下馬郵便局様に確認したところ、渋谷通東大路東入2丁目常盤町という表記が正しく常盤町2丁目は間違いとの回答をいただきました。

京都の通り名では、半丁という表現も登場します。

6028414 京都府 京都市上京区 西北小路町(猪熊通上立売上る、猪熊通寺之内下る、大宮通寺之内下る東入、大宮通寺之内半丁下る東入、大宮通寺之内下る東入1丁目、寺之内通大宮東入下る、寺之内通大宮東入1丁目下る)

区画としての「丁目」の場合は半丁という表現は意味が通りませんが、距離を表しているのなら意味は通ります。

大宮通寺之内半丁下る東入は、「大宮通り(おおみやどおり)を進み、寺之内通り(てらのうちどおり)を半丁(約54m)下がってから東に入る」という意味となります。

「番地の謎」はケンオール通信第7号: 日本の住所の構造と郵便番号データでも紹介させていただいきましたが、素晴らしい本です。 未読の方は是非お読みください。

次回予告

次回は、郵便番号データ処理編の最終回として、郵便番号データ処理のまとめを公開する予定です。

ケンオールについて

「かゆいところにケンオール」 ケンオールは、郵便番号住所検索APIをはじめとした、システム開発を加速する高品質で安全なAPIサービスです。 サービスを試してみたい方はこちらから: kenall.jp

Shodoで執筆されました

ケンオール通信第13号:括弧つきの町域(3) 小字、かぎ括弧、区切り文字の処理

ケンオール通信第12号:括弧つきの町域(2) 丁目や番地の処理では、括弧内の処理のうち、丁目や番地などの数字情報を処理する方法について紹介しました。

今回は、小字、かぎ括弧、区切り文字の処理を紹介します。

データは、記載がない限り2021-11-30のデータを用いています。

処理結果を確認してみたい方はこちらのデモから試してみてください。

小字の処理

数字でない文字列で、一部の例外(後述)を除いた文字列は全て小字として解釈します。

0580343 北海道 幌泉郡えりも町 東洋(油駒、南東洋、132~156、158~354、366、367番地)

展開すると以下のようになります。 番地は前回説明した通り削除します。

0580343 北海道 幌泉郡えりも町 東洋 油駒
0580343 北海道 幌泉郡えりも町 東洋 南東洋

小字と数字の混在

小字が単独で出現することは少なく、ほとんどのケースで数字と混在して登場します。

以下の2パターンが存在します。

  • 小字 + 数字
  • 数字 + 小字

いずれの場合も、単位のない数字は全て番地以下の住所であると解釈して削除しています。

例えば、以下は数字 + 小字の一例です。かぎ括弧の処理については後述します。

3842304 長野県 北佐久郡立科町 茂田井(1~500「211番地を除く」「古町」、2527~2529「土遠」)

展開すると以下のようになります。

3842304 長野県 北佐久郡立科町 茂田井 古町
3842304 長野県 北佐久郡立科町 茂田井 土遠

小字 + 丁目

小字 + 丁目の場合、どちらも残すようにしています。

9390321 富山県 射水市 流通センター(青井谷1、2丁目)

展開すると以下のようになります。

53078 9390321 富山県 射水市 流通センター 青井谷1丁目
53079 9390321 富山県 射水市 流通センター 青井谷2丁目

富山県射水市流通センター青井谷について

この住所について、射水市市役所様と水戸田郵便局様に確認してみました。

流通センター青井谷は一見通称のように見えますが、正式な住所です。

昭和58年10月に青井谷と水戸田という地域で企業団地の分譲が始まりました。 流通センター青井谷だけでなく流通センター水戸田という住所も別に存在します。 おそらくその時期にこの住所ができたものと思われますが、正式な利用開始時期はわかりません。

流通センター青井谷のどこからどこまでが大字で、どこからが小字なのかは特に意識していないそうです。

実用上問題ないため、ケンオールでは流通センターを町名、青井谷1丁目を小字として扱っています。

コメント文字列

括弧内の数字でない文字列には、コメントの意味を持つものが存在します。

以下のような文字列のみが書かれている場合はコメント文字列とみなして削除しています。

  • 丁目
  • 大字
  • 番地
  • 無番地
  • 無番地を除く
  • その他

他にもいくつかありますが省略しています。

(その他)は、削除した後にもう少し複雑な処理を行っています。詳細についてはケンオール通信第9号:(その他)の処理を参照してください。

(丁目)

(丁目)と書かれている郵便番号は、その郵便番号が○○町X丁目の郵便番号であることを明示的に示す必要がある場合に使われます。

例えば、青森県弘前市で町名が中野になっている郵便番号は以下の2レコード存在しますが、これらは全く別の地域です。

0368155 青森県 弘前市 中野(丁目)
0361451 青森県 弘前市 中野(その他)

中野(丁目)弘前学院大学前駅がある市街地のエリアで、中野1丁目~5丁目まであります。

中野(その他)弘前市西部にある小さな集落です。 こちらの住所では番地のみが用いられ、丁目は存在しません。

かぎ括弧の処理

郵便番号データ内の括弧は丸括弧()だけではありません。かぎ括弧「」や甲括弧〔〕も存在します。

甲括弧を使っている郵便番号は以下の1件のみです。

9790622 福島県 双葉郡富岡町 毛萱(前川原232~244、311、312、337~862番地〔東京電力福島第二原子力発電所構内〕)

甲括弧内の情報は住所補完に必要ないと判断して削除しています。

かぎ括弧が使われている郵便番号は20件あります。

「」内が数字以外で始まっている場合は、便宜上小字の一部として残しています。

9996652 山形県 鶴岡市 添川(渡戸沢「筍沢温泉」)

展開すると以下のようになります。

9996652 山形県 鶴岡市 添川 渡戸沢筍沢温泉

上記以外のパターンは番地か「その他」しかないため、全て削除します。

区切り文字

住所を併記する場合、ほとんどのケースでは読点「、」を区切り文字としています。

6660006 兵庫県 川西市 萩原台西(1、2丁目、3丁目1番~282番)

中黒「・」区切りを使う場合もあります。

9401172 新潟県 長岡市 釜ケ島(土手畑・藤場)

展開すると以下のようになります。

9401172 新潟県 長岡市 釜ケ島 土手畑
9401172 新潟県 長岡市 釜ケ島 藤場

「及び」を使う場合もあります。

5220239 滋賀県 彦根市 宇尾町(897番地及び中島505~518番地)

展開すると以下のようになります。

5220239 滋賀県 彦根市 宇尾町 中島

区切り文字が混在する場合もあります。

8700924 大分県 大分市 牧(1~3丁目、白滝B・C、高見)

この郵便番号には以下の特徴があります。

  • 範囲指定の「丁目」と小字の混在
  • 区切り文字「、」「・」の混在

詳細は後述しますが、B・Cは現在使われていない番地情報と思われるため削除します。

展開すると以下のようになります。

8700924 大分県 大分市 牧 1丁目
8700924 大分県 大分市 牧 2丁目
8700924 大分県 大分市 牧 3丁目
8700924 大分県 大分市 牧 白滝
8700924 大分県 大分市 牧 高見

大分県大分市牧(白滝B・C)について

大分県大分市牧1~3丁目は、昭和60年(1985年)3月25日に住居表示が刷新された際に誕生した地名です。 1 この際に字白滝という名前は廃止され、牧3丁目に統合されました。

字高見については記載がありませんが、高見児童公園という公園が牧3丁目にあることから、おそらく牧3丁目に統合されたものと思われます。

昭和43年(1968年)から大分臨海工業地帯萩原地区土地区画整理事業が始まりました。 2 その過程で区画整理が完了したため、昭和60年に住居表示が変更されました。

牧ではなくその隣の高城西町には、白滝南児童公園という公園があり、当時の地名の名残を見ることができます。

B・Cという表記については現在のところ調査中です。

アルファベットの番地を持つ地域として有名なのは大阪府大阪市中央区上町です。

こちらの記事によると「アルファベットを街区符号に使うところは、他に聞いたことがない」とあり、大分市でアルファベットの番地が使われていたという情報は現在のところ見つかっておりません。

心当たりのある方がいましたら情報をお待ちしています。

次回予告

次回は括弧内の処理のうち、京都の通り名について書く予定です。

ケンオールについて

「かゆいところにケンオール」 ケンオールは、郵便番号住所検索APIをはじめとした、システム開発を加速する高品質で安全なAPIサービスです。 サービスを試してみたい方はこちらから: kenall.jp

Shodoで執筆されました