国際住所の書き方は世界共通の一枚のテンプレートには収まりません。同じ情報でも、国によって並べる順序が変わり、一つの欄が指す意味も変わります。この記事では、記載の順序、項目の呼び方の差、文字種の問題を順に確認し、データとして住所を扱うときにどこでつまずくかを整理します。
記載順はなぜ国ごとに違うのか？
住所を書く順序は、その社会が場所をどう絞り込むかという習慣を映しています。大きく二つの流れがあります。
- 大きい単位から小さい単位へ進む書き方。国、都道府県、市区町村、町名、番地の順に絞り込みます。日本や中国、韓国などで一般的です。
- 小さい単位から大きい単位へ進む書き方。番地と通り名から始めて、市、州、国へと広げます。アメリカやイギリス、ドイツなどで一般的です。
国際郵便では、宛先の最後に目的国を書くのが伝統的な習慣です。どの方式であっても、最後に国名が来る形にしておくと仕分けがしやすくなります。
同じ欄名でも指すものが違う？
違います。ここが国際化で最も混乱するところです。
「州」と訳される欄は、アメリカでは連邦を構成する州を指しますが、アラブ首長国連邦では首長国を指し、日本では都道府県に当たります。スイスやドイツのように連邦州を持つ国もあれば、行政区を住所に書かない国もあります。つまり、州という一つの欄名で全部をまかなおうとすると、意味のずれがそのままデータのずれになります。
階層の呼び方も同じです。区や郡に当たる単位、市に当たる単位、その下の町や地区の単位は、国の数だけ呼び名と役割があります。国際的なフォームでは、欄の名前を抽象度の高いものにしておき、表示するラベルだけを国ごとに差し替える設計が安全です。アメリカの住所を詳しく見たい場合はアメリカの住所の構造を参照してください。
現地語で書くべきか、ローマ字で書くべきか
両方を保持しておくのが実際的です。現地の配送では現地語表記が最も確実に読まれます。一方で、国際的なデータ交換や目視の確認ではラテン文字への転写が必要になる場面があります。
注意したいのは、転写が一対一の変換ではないことです。同じ現地語の綴りでも複数の転写方式があり、長音の扱いやアクセント記号の有無で表記が分かれます。転写した文字列は元の文字列の代わりではなく、別の表現だと考えるべきです。したがって、現地語の欄と転写の欄を分けて持つか、少なくともどちらから作られた値なのかが分かるようにしておきます。日本の住所を例にすると、都道府県から番地へ向かって絞り込む順序と、番地から都道府県へ広げる順序の両方を提示できると、海外のフォームにも組み込みやすくなります。
開発者向け: 記載順を固定しない設計
最も避けたいのは、一つの文字列テンプレートに記載順を埋め込むことです。並び順は表示の問題であって、データの構造ではありません。同じデータから複数の並び順を組み立てられるようにしておけば、国の追加のたびにテンプレートを書き直す必要がなくなります。
次に、欄の意味を一つずつ決めます。行政区は一国の第一級の単位を入れる欄、市区町村はその下の単位を入れる欄というように、抽象度で定義します。そこに国ごとの具体的な名前を当てはめるのは表示の段階に回します。
三つめは、文字の扱いです。国際化された住所では濁点やアクセント記号を含む文字が入ります。正規化の処理を入れる場合でも、元の値を失わないようにします。検索や照合のために正規化した値を持つのは構いませんが、保存する値そのものを置き換えるのは避けてください。
四つめは、記載順の差をテストで押さえることです。東アジア型の順序と欧米型の順序をそれぞれ一件ずつ用意し、表示が入れ替わっても保存された値が変わらないことを確認します。国ごとの階層の違いはISO 国家コードと行政区コードに整理があります。
フォームを組むときの確認項目
国際的な住所フォームを作るときは、次の順に決めていくと手戻りが少なくなります。まず、国ごとに必要な欄の本数を決めます。次に、各欄が必須か任意かを国ごとに決めます。最後に、その欄へどの順序で並べるかを決めます。順序を最初に決めてしまうと、あとから欄を足すたびに全体を組み直すことになります。国を切り替えたときの欄の増減は、海外向けの住所フォームのテスト観点で扱っているので、あわせて確認してください。
次のステップ
まず、自分のフォームで州という欄が何を指しているかを確かめてください。国によって意味が変わる欄なら、名前を抽象化する余地があります。次に、同じ住所データから東アジア型と欧米型の二通りの並びを出せるかを試します。各国の記載順と項目の実例が必要なときはランダム住所生成で国を切り替えて確認でき、日本の住所のように国ごとの典型例を個別に見ることもできます。