ケンオールブログ

ケンオールは、オープンデータを活用する際に問題となる様々な課題を解決するソリューションとして、オープンデータの利用者に使いやすい環境を提供するプラットフォーム型サービスです。ケンオールは、株式会社オープンコレクターが開発・運営しています。 https://kenall.jp/

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

まとめ

住所フォームの作り方

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

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

本文

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

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

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

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

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

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

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

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

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

デモ

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

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

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

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

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

Google Chrome、Safari、Firefoxなどの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で執筆されました