DAY61では、海外発送した商品が届かない・壊れた・遅れているという配送事故を整理しました。その中に「住所不備」という原因がありました。購入者がName・Address・City・ZIP・Countryまで入力し、一見問題なさそうでも、実際にはApartment：Apt 502が抜けていました。同じ建物に数百世帯が住んでいます。配送会社は建物までは到着できても、誰へ届ければよいか分かりません。購入者は「届きません」、販売者は「住所どおり送っています」、配送会社は「部屋番号がありません」――これは配送事故というより住所データの問題です。

海外住所で難しいのは、日本と住所の構造が違うことです。さらにアメリカ・ドイツ・イギリス・フランス・中国などで、住所の並び方も郵便番号の形式も違います。万国郵便連合（UPU）は、世界には200を超える住所形式があり、国ごとに住所の慣行が大きく異なると説明しています。つまり「海外住所は全部、番地→通り→市→国で入力」という世界共通ルールはありません。

重要なのは、住所を一つの文章として保存するのではなく、Recipient Name・Company・Address Line・Apartment / Unit・City・State / Province / Region・Postal Code・Country・Phone・Emailなど、住所の部品に分解して管理することです。そして販売国・配送会社・配送サービスに合わせて配送ラベルへ組み立てます。

DAY61は「事故が起きたらどうする？」、DAY62は「住所・ラベル事故をどう減らす？」です。なお、住所が正しくてもそもそも海外へ送ってはいけない商品があるため、次回DAY63で禁制品を整理します。

先に結論｜住所は「1本の文字列」で持たない

次の住所があったとします。

これを「John Smith Apt 502 123 Main Street Los Angeles CA 90001 USA」という一つの文字列だけで保存すると、配送システムへ連携しにくくなります。分けます。

この構造化された住所データを、配送サービスに合わせてラベルへ変換します。FedExの国際配送ラベルでも、発送者・受取人の氏名、住所、電話番号などを入力し、商品情報や重量等と合わせてラベルを作成する仕組みです。

住所データの解剖学｜各フィールドの役割

「Apt」「Suite」「Unit」は似ていますが、全部同じ文字へ勝手に置換しないようにします。建物名や固有名詞についても、意味だけ見て日本語へ翻訳してはいけません。住所は購入者が使用している正式な表記を基本にします。日本郵便は国際郵便について、確実な配送のため原則として英字・アラビア数字を使うよう案内していますが、中国・台湾・韓国等では現地文字の住所が現地配送で役立つ場合もあり、使える文字や入力欄はCarrierごとに確認します。

最大の罠｜Address Line 2のサイレント消失

ECには「Apt 502」が正しく保存されているのに、CSV・API連携やWMS（倉庫管理システム）を経由するうちに、Carrierへ渡るラベルからApartment情報が消えることがあります。原因はマッピング漏れや列のズレです。結果として、建物には到着するものの部屋が分からず、宛先不明で返送・紛失につながります。これは購入者の入力ミスではなく、自社システムの問題です。対策は、CSV列のズレやAPIのマッピング漏れがないか、最終的に出力されたラベルを目視確認することです。EC：address2 → WMS：address_line2 → Carrier：address2、というフィールドマッピングが正しくつながっているかを確認します（DAY21のAPI・CSV連携の知識がここにつながります）。

国ごとに違う住所ルール｜アメリカとドイツの比較

USPSはアメリカ住所について、Name／Company／Delivery Address／City, State, ZIP Codeという基本構造を示しています。一方ドイツ郵便は、氏名／Street＋House Number／Postal Code＋Cityという住所形式を案内しています。「全世界一律でStateを必須にする」とドイツの顧客が入力できず離脱したり、ダミーデータを入力したりする原因になります。フォームの必須項目（バリデーション）は、最初にCountry（国）を選択させてから動的に切り替える設計が必要です。

郵便番号（Postal Code）は「5桁の数字」とは限らない

海外の郵便番号には、数字だけでなくアルファベットを含む国があります。例えばアメリカは90001のような5桁の数字ですが、イギリスのPostcodeはSW1A 1AAのような英数字ブロック、アイルランドのEircodeは7文字の英数字（スペースを含む）です。日本郵便の海外郵便番号情報でも、国によって桁数・数字/英数字・空白・接頭辞などが異なることが示されています。

電話番号とEmailは「顧客プロフィール」ではなく「物流データ」

海外配送では、電話番号は単なる顧客プロフィールではありません。配送会社が受取人へ配送・通関・関税・住所確認等について連絡するために利用されることがあります。DHLの国際発送案内でも、受取人の氏名、完全な住所、連絡先電話番号、メールアドレス等を配送情報として必要としており、FedExの国際発送ラベル作成でも発送者・受取人それぞれのPhone Numberを入力するよう案内されています。日本郵便でもEU向け国際郵便について、事前電子データとして受取人の電話番号またはメールアドレスの送信を推奨しています。

電話番号には国・地域を識別するCountry Calling Code（国番号）があります。日本は+81です（ITUのE.164番号体系）。厳守すべきルールは3つです。①必須項目だからと「0000000000」のような架空番号を入力させない　②受取人の電話番号に販売者（自社）の番号を代用しない（現地で連絡が取れなくなります）　③国番号とセットで保存する。国内番号から国際形式への変換ルールは国によって異なるため、「先頭の0を全部削除」のような世界共通変換は作らず、国ごとの番号体系を確認します。

配送住所（Shipping）と請求住所（Billing）の分離

Shipping Addressは実際に商品を届ける住所で、配送ラベルに印字されるデータです（ギフト、勤務先、家族宅などが利用シーン）。Billing Addressは決済・請求に関係する住所で、ラベルには使用しません（自宅、クレジットカード登録住所などが利用シーン）。この2つが違っても、それだけで不正とは限りません。ただし、発送前に「別の国・住所へ変更してほしい」という依頼が来た場合は、不正注文・配送事故・決済保護等の観点からリスクがあるため、厳格な自社ルールで確認します。住所変更はOriginal Address・Changed Address・Change Date・Requested Byを履歴として残し、商品がCarrierへ引き渡された後は、EC側で住所を書き換えただけでは配送先は変わらないため、Carrier側で変更可能か確認します。

住所エラーを防ぐ「Validation（検証）フロー」

入力された住所が存在する形式か、郵便番号とCityが合うか、州が合うかなどをシステムで検証する仕組みをAddress Validationと呼びます。例えばFedExはAddress Validation APIを提供しており、国によって必要な住所フィールドが異なることを仕様として扱っています。検証がValid（正常）なら配送ラベル生成へ進み、Invalid・WarningならHOLD（自動発送停止）とします。

配送ラベルとInvoice（通関書類）のデータ整合性

Shipping Labelは荷物を「運ぶ」ための書類、Commercial Invoiceは税関へ取引・商品の情報を「説明する」ための書類です（DAY52で学んだ内容）。この2つは目的が違いますが、内容を矛盾させてはいけません。Shipping LabelのRecipientとInvoiceのConsigneeが別人になっていたら、意図した違いなのか入力ミスなのか確認が必要です。住所データが完璧でも、Invoiceの受取人情報（Consignee）と矛盾していると通関で止まります。Order・Shipping Label・Invoice・AWBのRecipient Addressが、同じ取引を示しているか確認しましょう。

配送ラベル出力後の最終目視チェック

印刷後は、Country・Postal Code・City・State・Street・House Number・Apartment・Recipient・Phoneを、Orderと比較して確認します。Tracking Numberがあるからといって、住所そのものの確認を省略しません。特に注意すべきは3点です。①Address Line 2 Check：文字数制限で「Apt 502」が途中で切れていないか　②Barcode Integrity：バーコードが印字されているか、箱の継ぎ目にまたがって貼られていないか　③Layout Check：独自のWord・Excelで作らず、Carrierの公式システム（API・マイページ）から生成された正しいレイアウトか。日本郵便は、送り主・受取人の住所配置を逆にしたり横並びにしたりすると返送や遅延につながる可能性があると注意しています。また再利用の段ボールを使う場合は、過去のTracking Barcode・Address Labelが残っていると誤スキャンの原因になるため、発送前に必ず剥がします。

注文から発送までの「データパイプライン」

Country別ルールに基づくフォームで正確なデータを取得（1. 注文）、Postal Code形式確認と住所検証を行いエラー時は購入者確認（2. 検証）、確定した住所を「Order Shipping Address」として履歴保存（3. 固定）、Carrierへ連携しラベル生成、途切れ・欠落がないか目視確認（4. 変換）、Tracking NumberをOrderへ戻し発送（Shipment）完了（5. 登録）という流れです。購入者がマイページの住所を後から変更しても、過去注文の配送住所まで書き換わってはいけません。Customer Master（現在住所）とOrder（注文当時の住所）は分けて保持し、事故調査・返品・Claimに使えるようにします（DAY61との接続点です）。

実際のケースで考えてみよう

ケース①｜アメリカ購入者へ商品を発送する

購入者入力：Emily Brown、Address Line 1「500 Market Street」、Address Line 2は空欄、City「San Francisco」、State「CA」、Postal Code「94105」、Country「United States」。Address Line 2が空欄でも、それだけでエラーにはしません。一戸建てやオフィス単独など追加住所が不要な場合もあるからです。Address Validationで住所候補を確認すると、注文画面のCompany「ABC Inc.」が複数テナントの入るビルだと判明しました。受取担当者Emily Brownは分かっていますが、Suite番号が必要か購入者へ確認したところ「Suite 1200」が必要と判明。Address1「500 Market Street」、Address2「Suite 1200」と修正し、受取人の有効な電話番号も保存します。注文時住所（旧）と確認後発送住所（新）を履歴として残し、Name・Company・Address1・Address2・City・State・Postal・Country・PhoneをCarrierへ連携。生成されたShipping Labelが「Emily Brown／ABC Inc.／500 Market Street Suite 1200／San Francisco CA 94105／United States」という内容になっていることを確認し、InvoiceのConsignee情報も同じ配送先を示しているか確認してから発送します。

ケース②｜郵便番号形式を数字限定にした失敗

ECフォームのPostal Codeを「数字のみ」に設定していたところ、英数字を含むPostal Codeを持つ国から購入者が注文しました。入力できず、購入者は仕方なく「00000」と入力。決済は成功しましたが住所は不正確なままです。Carrier側でPostal Code Errorとなり配送保留となりました。原因は購入者ではなくECフォーム設計です。世界の郵便番号には英数字形式もあり、日本郵便も国ごとに異なる郵便番号形式を案内しています。改善策は、Countryを先に選択させ、Country別Postal Code Validationへ変更することです。「住所エラー」を購入者の入力ミスだけにしないことが重要です。

アクションプラン｜自社システムを見直す3つの問い

1. フォーム設計｜「Country（国）」の選択によって、Stateの必須／任意や、Postal Codeの入力制限が動的に切り替わる設計になっているか？
2. データ連携｜ECカートで入力された「Address Line 2（部屋番号）」が、WMSや配送ラベル出力システムまで一切欠落せずに連携されているか？
3. 運用ルール｜住所エラー（Validation不一致）が発生した際、担当者が推測で修正せず、自動保留して購入者に確認するフローが確立されているか？

この3つの問いに「はい」と答えられない項目があれば、そこが自社の越境ECにおける住所事故の発生源である可能性があります。

やってみよう｜海外住所ラベル組み立てツール

受取人情報を入力し、国を選ぶと、その国の一般的な並び順でShipping Labelのプレビューを組み立てます。国によってState欄の要否や並び順が変わることを体感してみてください。

アウトプットワーク｜海外住所・配送ラベル確認シート

実際に販売したい国を一つ選び、下の欄を埋めてみてください。入力内容はこのブラウザにのみ保存され、外部へは送信されません。

理解度チェッククイズ

よくある質問

今回のまとめ

DAY62では、海外住所・電話番号・配送ラベルを整理しました。今回覚えておきたいポイントは、次の5つです。

1. 海外住所に世界共通の一つの並び順はない
2. 住所をStreet・City・State・Postal Code等へ分解して保存する
3. Postal Codeの形式は国によって違う
4. 電話番号・Emailも配送・通関に使われる重要情報
5. EC画面だけでなく最終Shipping Labelまで確認する

最も重要なのは、住所を文章ではなくデータとして見ることです。UPUは世界には200を超える住所形式があるとしています。つまり「海外住所テンプレート」を一枚作り全世界へ当てはめるのではなく、Countryを最初に決め、その国に必要な住所要素を表示します。USはStateあり・ZIP Codeあり、GermanyはStreet＋House Number・Postal Code＋Cityというように、必要な項目も並び順も違います。Postal Codeも数字5桁とは限らず、英数字を使う国もあります。

さらに、住所だけではありません。Phone・Emailも配送データとして扱います。DHL・FedExでは国際配送情報として受取人電話番号を使用し、日本郵便でもEU向け事前電子データとして電話番号またはメールアドレスの送信を推奨しています。そして住所を入力したら終わりではなく、Order→Address Validation→Shipment→Carrier→Shipping Labelまで確認します。EC画面にはApt 502があるのに、Shipping Labelでは消えている――なら、配送事故の原因は購入者ではなくシステム連携かもしれません。住所品質は、購入者入力＋EC＋CSV/API＋WMS＋Carrier＋Labelの品質です。最後は、実際に印刷されたShipping Labelを確認してください。

海外住所 確認チェックリスト

発送前に、次の6項目を確認しましょう。タップでチェックできます。

確認した項目：0 / 6

獲得バッジ

文：横田和也／解決ドットコム編集部