ケンオールブログケンオールブログケンオールは、オープンデータを活用する際に問題となる様々な課題を解決するソリューションとして、オープンデータの利用者に使いやすい環境を提供するプラットフォーム型サービスです。ケンオールは、株式会社オープンコレクターが開発・運営しています。住所フォームを作るときには以下の4つを押さえましょう。オートコンプリート機能に最適化する郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応するモバイルUX優先なら郵便番号が入力されたら即座に補完。サイトでの電子申請など、ウェブサービスを活用する上で住所入力は欠かすことができません。住所入力をシンプルかつ正確に行えるような入力インタフェース(住所フォーム)は、離脱率を減らし、コンバージョン率を向上させる上で重要です。郵便番号を入力すると対応する住所を自動入力する機能(郵便番号による住所補完)は、住所フォームの改善方法として最も効果的な改善策の一つです。ユーザーが住所入力を手動で行うと、以下のような問題が発生します。入力の煩雑さにより登録をあきらめてしまう(離脱率の増加)間違った住所により配送ミスが発生(対応コストの増大、コンバージョン率の低下)郵便番号による住所補完を使うことで、この問題の影響を大きく減らすことができます。使いやすい住所フォームを作るには、以下の点に注意するのが基本です。ハイフン有無両対応など)これらの基本を踏まえた上で、住所フォームで郵便番号による住所補完を使うときのベストプラクティスを紹介します。TypeScriptのデモアプリを用意しました。(本記事で紹介する全機能を網羅しているわけではありません)デモアプリはこちらから試せます。ブックマークのコメントで「リセットボタン」に関するご指摘をいただいておりますが、これはデモで補完入力の試行を容易にするために便宜的に設置してあるもので、ケンオールの見解として住所入力フォーム一般でリセットボタンを配置することをお勧めしてはおりません。設置してはいけないものです。誤解を招くような表示となってしまい申し訳ございませんでした。Chrome、Safari、FirefoxなどのWebブラウザでは、住所などのデータをフォームに自動入力するオートコンプリート機能(オートフィル機能)が備わっています。ユーザーが適切にこの機能を使えるようにするためには、フォームがオートコンプリートに最適化している必要があります。オートコンプリート機能に最適化されていないと、自動入力が機能しないばかりか、間違った値が入力されてしまうこともあります。それらの訂正によって余計に手間が増えてしまい、ユーザーのストレス向上や離脱につながります。オートコンプリート機能に最適化して、フォーム入力の手間を減らすようにしましょう。住所フォームにおけるオートコンプリート要素ブラウザは、HTMLフォームのオートコンプリートを実行するとき、フォーム要素のいくつかの属性をヒントとして、その要素がどの項目に該当するのかを決定します。標準で定義されています。標準に含まれる属性値のバリエーションは多数にのぼりますが、Googleの開発者向けサイトでは、よく使われるautocomplete属性値を例示しています。ここでは、さらに、それらのうち住所に関係する要素を紹介します。address-line2住所形式は、1フィールド形式か2フィールド形式のいずれか一方のみを使用します。</label></form>郵便番号フィールドは1フィールドにまとめ、ハイフン有無に両対応する郵便番号入力フィールドのデザインは、大きく分けて3パターンあります。郵便番号4桁のフィールド郵便番号のオートコンプリート要素はpostal-code1つのみです。3桁-4桁の2フィールド形式ではオートコンプリートに対応できないため、なるべく採用しないようにしましょう。オートコンプリート要素postal-codeはテキスト形式のため、郵便番号がハイフンを含んでいることもあります。フォームではハイフンの有無に両方対応しておき、フォーム送信時にバックエンドAPIの要求する形式へ変換するようにしましょう。今回調査したサービスのうち8割が1フィールドで設計していましたが、その大半はハイフンなしのみ受けつける設計でした。1フィールドでハイフン有無両対応しているサービスは全てECサイトの配送先登録フォームでした。郵便番号を入力した後に住所を補完するユーザーインタフェース(UI)には以下の3パターンがあります。郵便番号を入力した後、即座に住所を補完する郵便番号補完専用のボタンを用意し、ボタンを押下すると住所を補完する住所補完専用の画面を開き、住所選択を完了すると元の画面に戻るパターン3を選択することはまれで(後述)、基本的にはパターン1か2の二択となります。郵便番号を入力した後、即座に住所を補完する郵便番号を入力して即座に住所を補完するUIは、少ない操作で住所補完できることが特徴です。派生型として、入力後にエンターキーを押してから補完するUIもあります。モバイル環境では、後述するボタン押下式や別ウィンドウ式の操作は手間がかかるため、この方式を選択するのがおすすめです。いくつか注意点もあります。一つ目は、前述のブラウザによるオートコンプリートを邪魔するような実装にしないということです。補完のタイミング次第ではブラウザがオートコンプリートで住所の値を入力した直後に郵便番号補完が実行されてしまい、オートコンプリートの値が上書きされてしまうことになりかねません。これでは、せっかくのUXが台なしになってしまいます。二つ目は、郵便番号が複数の住所に対応している場合、この方法ではユーザーの意図した住所を選択できない可能性があるということです。以下の郵便番号は複数の都道府県にまたがっています。中津市これ以外にも、大字や小字のレベルで違う住所が同じ郵便番号になっているケースが多数あります。これらのようなケースを想定して、ユーザーが手入力で補完された住所を変更できるようにしておく必要があります。ボタンを用意し、ボタンを押下すると住所を補完する郵便番号補完専用のボタンを用意するUIは、ボタンを押す動作が増えるため、ユーザーは多少手間が増えます。明示的にボタンを押す場合、ユーザーはこれから住所補完をすることがわかっています。その場合、複数の住所候補がある場合にモーダルを表示して選択するUIなどを自然に導入できます。ユーザーの手入力を減らしたい場合にはこのUIが効果的です。選択UIを設計する場合、郵便番号レコードの最大個数に注意してください。時点のデータで最も多くの町名にまたがっている郵便番号は愛知県清須市の4520961で、66件あります。郵便番号全体の90%は8件以下のレコードしかありませんので、以下のような設計が考えられるでしょう。表示(この場合最大でも2件)モバイル環境の場合、ボタンを押してモーダルから選択する操作はかなり手間がかかることに注意してください。モバイルからのアクセスが多い場合は、オートコンプリートに最適化して極力ボタンを押下する機会を減らすか、即座に住所補完するUIを選択した方がいいでしょう。住所補完専用の画面を開き、住所選択を完了すると元の画面に戻る住所補完専用の画面を開くUIは、ページ遷移や同時に開くウィンドウの数が増えるなど、ユーザーの負担が大きくなります。候補が一つであっても明示的にユーザーに選択させたい、選択対象の住所候補に付加情報を表示したい、といった場合に効果的なUIです。モバイル環境の場合、ボタンを押下するUIよりもさらに手間がかかることに注意してください。モバイルからのアクセスが多い場合は極力このUIを避けた方が無難です。今回調査した結果では、住所補完専用の画面を開くUIを選択していたサービスは全て金融系のサービスでした。郵便番号データベースに登録のない郵便番号が指定された際、住所入力を先に進ませないような誤解を招きかねないメッセージ文言が上図の例にありましたが、これは意図するところではありませんので、図を修正させていただきました。)入力した郵便番号が間違っているなどの理由で住所補完に失敗した場合(クライアント側の問題)、その原因を簡潔にユーザーに伝えるべきです。APIからの応答がないなど、サーバーサイドエラーの場合、住所補完UIに応じて設計を変えていきます。即時補完UIを採用している場合、ユーザーは意図して補完を行っているわけではないので、住所補完に失敗してもあえてエラーを出す必要はないかもしれません。ユーザーは補完機能があることに気づかないまま、住所を手入力してくれるでしょう。住所補完ボタンなどのUIを採用している場合、ユーザーは補完を意図して行っているので、住所補完に失敗した場合はサーバーサイドのエラーであることを表示した方が親切です。丁目・小字」のどちらか一方の表記になります。日本の住所の構造と郵便番号データも参照してください。各サイトの住所フォームを調べてみると、フィールドの構成はバラバラでした。今回調査したサービスでは以下のように分かれていました。)に分割するのがおすすめです。このレイアウトは、以下のようなメリットがあります。地域情報を階層的に保存できるので、地域別データ分析やユーザーの地域属性ごとのコンテンツ提供などに応用しやすいフィールドごとに適した入力ルールを適用できるため、表記ゆれや誤入力を減らせる都道府県と市区町村で表記ゆれが発生することはありません。ユーザーがこのフィールドを操作するのはオートコンプリートや住所補完が動作しない場合だけなので、後段のフィールドと分けておくと誤入力を避けることができます。市区町村フィールドは漢字10文字が収まるだけのスペースを確保します。都道府県や市区町村を編集不可にすれば誤入力を防ぐ効果は高まりますが、もしオートコンプリートや住所補完UIで期待する住所が表示されなかった場合、ユーザー自身で修正する手段がなくなってしまいます。フィールドを分けるなどにとどめ、ユーザーの手入力は許可しておきましょう。町名以下のフィールド形式は、オートコンプリートの住所フィールドのどちらに対応するかで異なります。使う場合、ユーザーがマンション等の建物に住んでいるかどうかは分からないため、任意フィールドとしておきます。住所フィールドを全角固定にするUIが多数見られましたが、現在は全角・半角両対応するのが一般的です。サーバサイドの側の要件で全角固定にせざるをえない場合でも、送信時に全角変換するなどして、UI上はなるべく全角・半角両対応にしましょう。住所フィールドを1つにまとめる住所フィールドを1つにまとめると、レイアウトがシンプルになりますが、デメリットもあります。1つ目は、オートコンプリートがうまく機能しないことです。利用しなければいけません。多くのユーザーはオートコンプリート機能を使って正常に住所を補完することができないでしょう。2つ目は、1フィールドでは住所階層ごとの入力ルールを設定できないため、誤入力や表記ゆれの問題が発生しやすくなることです。配送ミスなど、間違った住所によるコスト増が無視できない場合には避けた方がいいでしょう。コードなどを用いたデータの正規化・圧縮が行えなくなることです。全国規模の大サービスなど、住所情報のデータ量が無視できないような大規模システムの場合はデータ量の増加にも注意する必要があります。必要がない限りは、この設計を選択しないことをおすすめします。ケンオールAPIを使う場合これらのベストプラクティスに基づきケンオールAPIを使う場合、以下の点に注意してください。APIについての詳細は郵便番号APIのドキュメントを参照してください。リクエスト時の郵便番号パラメーターは数字7桁固定サーバサイドでハイフン除去等の処理は行いませんので、クライアントサイドで数字7桁になるようにしてからリクエストしてください。レスポンスデータは配列レスポンスに含まれる住所データは配列で返ってきます。クライアント側で複数の住所データに対応できるようにしておくことを推奨します。即時型の住所補完を使う場合など、複数の住所データに対応できない場合は、配列の最初の要素を取得してください。小字なしの住所が取得できるようになっています。(その他)を含む町域など、一部の住所では小字なし住所が配列の最初の要素になっていないものもあります。詳細はケンオール通信第9号:(その他)の処理を参照してください。複数の町域にまたがる郵便番号の場合、2つ目以降の町域に対応する方法はありません。データに含まれるtown_multiフラグがtrueの場合、その郵便番号は複数の町域にまたがっています。0040000は札幌市厚別区と札幌市清田区にまたがっています。「町名以下」には、以下のようにデータを連結して格納してください。koaza終わりに郵便番号による住所補完はシンプルなUIですが、ユーザーの離脱を減らすために考慮すべき点はいくつもあります。設計・実装して、KPIの向上につなげていきましょう。ケンオールでは住所フォームの設計や実装の相談についても承っています。ご興味のある方はこちらからお問い合わせください。APIをはじめとした、システム開発を加速する高品質で安全なAPIサービスです。kenall.jp(Shodoで執筆されました)ケンオールについてケンオールは、オープンデータを活用する際に問題となる様々な課題を解決するソリューションとして、オープンデータの利用者に使いやすい環境を提供するプラットフォーム型サービスです。ケンオールは、株式会社オープンコレクターが開発・運営しています。ケンオールAPIの開発者向けドキュメントです。ケンオールのFAQです。ケンオールを導入いただいた企業様の事例をご紹介しています。ケンオールサービスの料金一覧表です。都道府県や市区町村などの補完機能を追加しました2022-09-05提供プランをリニューアルしました2022-09-02新プランリリースの遅延について2022-08-09エクセルから祝祭日を含めた営業日の判定を簡単に行う引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。