【デモアプリあり】法人向け住所フォームをケンオールで作ろう

法人向け住所フォームのまとめ

まとめ

法人向け住所フォームは、法人向けの資料請求フォームや取引先法人登録フォームなどで使われる、法人情報の登録に特化した住所フォームです。

個人向けと異なり他社の住所を入力する場合が多いため入力ミスしやすく、オートコンプリート機能も利用できません。

契約書や請求書発送にも用いられるため、配送ミス時の影響は大きくなりがちです。

一方、法人住所はオープンデータとして公開されているため、法人住所の自動補完機能が利用可能です。

この記事では、法人向け住所フォームのデモアプリを紹介します。

法人向け住所フォームとは?

住所フォームは、ECサイトや宅配サービスなど、様々なサービスに組み込まれています。 ケンオールでも、住所フォームの作り方について紹介しました。

住所フォームは個人向けだけでなく、法人のお客様向けにも存在しています。 例えば、法人向けの製品やサービスを提供する企業では、法人のお客様向けに資料請求フォームなどを提供することがあります。 取引先法人の登録作業を行う業務システムでは、専用の登録フォームを用意していることでしょう。

法人向け住所フォームでは、他社の住所を登録するケースが多くなります。 個人向け住所フォームではほとんどの場合自宅住所などを入力するため、基本的には入力する住所のことをよく知っているはずです(もちろん、引っ越し直後などの場合は別です)。 住所フォームの作り方で紹介したオートコンプリート(オートフィル)機能も利用可能です。

法人向け住所フォームでは、初めて入力する住所を取り扱うケースが多くなります。そのため、個人向け住所フォームよりも入力ミスが発生しやすくなります。 オートコンプリート機能も使うことはできません。 一方で、個人向けのサービスに比べて住所入力ミスの影響は大きくなりがちです。例えば、契約書や請求書などの送付ができなかった場合、大きな問題となります。

このように、法人向け住所フォームでは、個人向け住所フォーム以上に正確な住所入力を求められる場面が増えてきます。

法人向け住所フォームのデモ

法人名から法人情報を検索し、法人の住所を補完するUIのデモアプリを作成しました。

ソースコードも公開しています

法人向け住所フォームデモ

使い方は以下のとおりです。

  1. 法人名を入力し、簡単入力ボタンをクリックします。
  2. 必要に応じて絞り込み検索オプション 都道府県 法人種別 部分一致あるいは完全一致 を選択します。
  3. 検索ボタンをクリックします。
  4. 目的の法人が見つかったらクリックします。
  5. 法人住所が補完されます。

簡単入力の検索結果

法人情報補完後

このようなフォームを簡単に作れるのは、法人番号データによって全ての法人住所が公開されているからです。

法人番号データを使って法人住所を補完する

法人番号は、全ての法人に付与された固有の番号です。法人版マイナンバーとも言われています。 この法人番号と法人名、法人住所を対応させたデータ(以下、法人番号データ)を国税庁が公開しています。

このデータを使えば、法人住所の補完機能を作ることができます。

法人番号データを活用する方法を3つ紹介します。

  1. 国税庁提供APIを使う
  2. 法人番号データをダウンロードし、自分でDBを運用する
  3. ケンオール法人名検索APIを使う

国税庁提供APIを使う

国税庁は公式のAPIを提供しています。このAPIを使えば無償で法人住所補完機能を開発できます。

国税庁提供APIを使う際には、以下の点にご注意ください。

  • 郵送でアカウントを取得する必要がある
  • データのレスポンスはcsvxml、エラーメッセージはcsv固定
  • 完全一致未対応で、部分一致と前方一致のみ
  • さらに前方一致の場合、株式会社等の法人種別をユーザーが削除してから検索する必要あり*1
  • はしご高などのJIS標準外文字による検索は非対応。登記通りの名前で検索できない
  • 町名・番地とビル名以下が分割されていない
  • CORSに非対応のため、APIWebブラウザから直接利用できない
  • サポートやSLAなどを提供していない

法人番号データをダウンロードし、自分でDBを運用する

法人番号データはオープンデータなので、自分でダウンロードしてDBを構築できます。

オープンデータのためデータ自体は無償ですが、DBの運用コストが発生します。

また、全データで500万件以上あり、毎営業日差分更新されるため、DBのデータをどう更新していくかを正しく設計していく必要があります。

ケンオール法人名検索APIを使う

ケンオール法人名検索APIなら、上記の問題を解決できます。

  • ユーザー登録が簡単。全てWeb上で完結し、ユーザー登録したその日から利用可能
  • REST APIとして提供。レスポンスはJSONに統一
  • JavaScript SDKの提供
  • 部分一致の他、法人種別を含めた法人名の完全一致検索に対応
  • 株式会社込みで完全一致検索が可能。法人種別なしの完全一致検索も提供
  • はしご高など、JIS標準外の文字での検索に対応。登記通りの名称をコピー&ペーストしても検索が可能
  • 町名・番地とビル名以下を分割して提供。様々な住所フォームの形式に対応可能
  • CORS対応のため、フロントエンドのみで住所検索UIを実現可能
  • サポート、SLA、専用テナントなどの高度な非機能要件が必要なお客様向けに、エンタープライズプランの提供*2

終わりに

法人向け住所フォームは個人向けと違った課題がある一方、住所補完に利用可能なオープンデータがあるなどの利点もあります。 ケンオールを使えば簡単に導入できますので是非試してみてください。

ケンオールについて

「かゆいところにケンオール」

ケンオールは、郵便番号検索API、郵便番号逆引きAPI、住所正規化API、法人名検索API、日本の祝日APIなど、システム開発を加速する高品質で安全なオープンデータAPIサービスです。

kenall.jp

Shodoで執筆されました

*1:部分一致検索では法人種別込みの検索が可能です

*2:別途有償契約が必要となります

一部郵便番号が正常に検索できなかった問題を修正しました

ケンオールを2022/03/18(金)にアップデートしました。

アップデート内容は以下のとおりです。

  • 郵便番号検索API: 一部郵便番号が正常に検索できなかった問題を修正

郵便番号検索API: 一部郵便番号が正常に検索できなかった問題を修正

区画整理扱いとなっていた郵便番号のうち、一部の郵便番号が検索できない状態となっていました。 ご迷惑をおかけして申し訳ありません。

本問題が発生していたバージョンは以下のとおりです。

  • 2022-01-31
  • 2022-02-28

対象の郵便番号は以下のとおりです。

以下、6691313: 兵庫県三田市福島 を例にとって説明します。

兵庫県三田市福島は、2022年1月に区画整理された、新しい住所です。

神戸新聞の記事(2020/12/12)では、この地域の区画整理について紹介しています。

JR新三田駅周辺(兵庫県三田市)の地名が2021年夏、福島から「福島1~3丁目」に変更される。 (中略) 区画整理中の地域は現在、大字「福島」の中に大田▽道野上▽堀雲▽家成▽宮野前-の各字(あざ)がある。この一部を大字の福島1~3丁目に変える。

三田市のサイトによると、この変更は2022年1月26日(水)に行われるとあります。神戸新聞の記事では2021年夏とありましたが、何らかの理由で延期になったものと思われます。

三田市のサイトを読むと、住所変更は行いますが、郵便番号6691313は変更しないと書かれています。

2022-01-31ではなく2022-02-28から郵便番号レコードが変更された理由については分かっておりません。

日本郵便様が公開している郵便番号データは、最新の郵便番号を掲載したデータだけではありません。 前のバージョンから追加されたレコードの一覧と削除されたレコードの一覧も別に公開しています。

郵便番号データでは、6691313のような郵便番号を区画整理の郵便番号として扱っています。 このような郵便番号を扱う場合、同一のレコードを更新するのではなく、古い住所のレコードを削除してから新規追加しています。 このようなケースでは、追加データと削除データのどちらにもレコードが存在しています。

ケンオールでは、近日公開予定の「郵便番号更新情報取得API(仮称)」のため、追加データと削除データの両方を保持する変更を行っていました。

今回の問題は、区画整理の郵便番号について、削除レコードのみの保持を行っていたことが原因でした。

今回のアップデートではこの問題を修正しました。

ケンオールについて

「かゆいところにケンオール」

ケンオールは、郵便番号検索API、郵便番号逆引きAPI、住所正規化API、法人名検索API、日本の祝日APIなど、システム開発を加速する高品質で安全なオープンデータAPIサービスです。

kenall.jp

Shodoで執筆されました

日本の祝日APIをリリースしました

f:id:kenall:20220316090140p:plain
アップデートのお知らせ(2022/03/15)

2022/03/15(火)にケンオールをアップデートしました。

アップデート内容は以下のとおりです。

  • API: 日本の祝日API
  • 郵便番号逆引き検索API: 品質の改善

祝日や休日のAPIについて、機能要望アンケートを募集中です!

API: 日本の祝日API

日本における祝日は、内閣府が毎年CSVデータを公開しています。 しかし、システムで祝日データを利用するとき、CSVをダウンロードし、それをシステムにロードするというのは意外と手間がかかります。

手動で更新する場合、手順自体を検証した上で運用ドキュメントを執筆する必要があります。 さらに、手動運用によるオペレーションミスのリスクも毎年つきまとうことになります。

自動化する場合、特別に祝日が移動するケースなどに対応できるようにしなければいけません。結局のところ手動でも更新できるようにしておく必要があるでしょう。

そうした悩みを解決するため、ケンオールは日本の祝日を提供するAPIをリリースいたしました。

以下のように、祝日が必要な年を指定して実行するだけで簡単に取得できます。

curl -s -H "Authorization: Token $YOUR_API_KEY" \
"https://api.kenall.jp/v1/holidays?year=2022"

レスポンスは以下のようになります。

{
  "data": [
    {
      "title": "元日",
      "date": "2022-01-01",
      "day_of_week": 6,
      "day_of_week_text": "saturday"
    },
    {
      "title": "成人の日",
      "date": "2022-01-10",
      "day_of_week": 1,
      "day_of_week_text": "monday"
    },
    ...
  ]
}

詳細はAPI紹介ページを参照してください。

日本の祝日APIは、郵便番号APIプランで利用可能です。ドキュメントの製品とプランのページも参照してください。

アンケート募集中!

ケンオールでは、郵便番号検索APIや法人番号検索APIを始めとして、主に住所オープンデータを取り扱ってきました。

しかし、お客様の声を聞いている中で、住所だけでなく祝日や休日を扱うのも意外と大変であると分かってきました。

今後は住所だけでなく祝日や休日を扱うAPIも提供していく予定です。

かゆいところに手が届くAPIサービスを目指して、ケンオールはこれからもアップデートを続けていきます。

祝日や休日のAPIについて、機能要望アンケートを募集中です。

ぜひご回答ください!

郵便番号逆引き検索API: 品質の改善

2月21日のリリース後、お客様よりいただいたフィードバックに基づき、郵便番号逆引き検索APIの品質改善を行いました。

主要な改善をいくつか紹介いたします。

デモページより、改善された結果をお試しください。

龍ケ崎市など、一部の市区町村を検索できなかった問題を修正

郵便番号逆引き検索API法人名検索APIと同様、非標準文字でも検索できるようになっています。

しかし、この処理が正しく動作しておらず、龍ケ崎市竜ケ崎市と誤変換してしまう問題が発生していました。

今回のアップデートではこの問題を修正しました。

東京など、都道府県や市区町村の接尾辞がなくても補完するよう修正

以前のバージョンでは、東京都のように都道府県や市区町村の接尾辞(この場合は)を入力しないと正しく検索することができませんでした。

今回のアップデートで、このような接尾辞がない場合に自動的に補完するよう変更しました。

"query": {
    "q": "_structure:1",
    "t": "東京",
    "prefecture": "東京都",
    "county": null,
    "city": null,
    "city_ward": null,
    "town": null,
    "kyoto_street": null,
    "block_lot_num": null,
    "building": null,
    "floor_room": null
  },

北海道の一部住所における正規化処理を改善

北海道札幌市における北37条東のようなで表される住所要素について、以前のバージョンでは丁目と同等に扱っていて、番地フィールド block_lot_num に組み込んでいました。

しかし、北海道在住の方にとっては北37条東は町名として扱われる方が自然であるというご指摘をいただきました。

今回のアップデートでは、北海道ので表される住所要素を町名として扱うように修正しました。

  "query": {
    "q": "_structure:1",
    "t": "北海道札幌市東区北37条東",
    "prefecture": "北海道",
    "county": null,
    "city": "札幌市",
    "city_ward": "東区",
    "town": "北三十七条東",
    "kyoto_street": null,
    "block_lot_num": null,
    "building": null,
    "floor_room": null
  },

ケンオールについて

「かゆいところにケンオール」

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

Shodoで執筆されました

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

まとめ

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のサポートに状況をエスカレーションするとともに、引き続き原因の究明を行ってまいります。