AddressLab · ガイド
米国ZIPコードの入力テスト：9例の整形と拒否結果
初回公開: · Chrome · 2026-10-24
米国 ZIP は日本の7桁郵便番号へ変換せず、文字列として検証します。標準形だけを受け付けるのか、整形して受け付けるのかも先に決めてください。今回のチェッカーでは9入力のうち6つが整形後に合格し、3つが拒否されました。ZIP+4 の割当や配達先を確認した結果ではありません。
米国向け入力欄とAPIの受入条件を定める開発者向けです。ローカルの Chrome 本番ビルドで米国を選び、表の生文字列を入力しました。JSON 表記で空白と空欄を区別しています。ZIP+4 は手書きの構文ケースです。
9入力を同じ設定で比べる
郵便番号形式チェッカーで米国を選択し、値を置き換えて形式を確認します。テスト用文字列を実注文の宛先に使わないでください。
| 元の入力（JSON表記） | 整形後の出力 | 構文チェック結果 |
|---|---|---|
"02108" | 02108 | 受け入れ |
"02108-1234" | 02108-1234 | 受け入れ |
"021081234" | 02108-1234 | 受け入れ |
" 02108 " | 02108 | 受け入れ |
"02 108" | 02108 | 受け入れ |
"０２１０８" | 02108 | 受け入れ |
"2108" | 2108 | 拒否 |
"0210A" | 0210A | 拒否 |
"" | （空欄） | 拒否 |
このツールは空白を除去し、Unicode 互換正規化を行い、連続9桁にハイフンを挿入します。02 108 の合格はその製品判断によるもので、内部空白を USPS の標準表示として推奨するものではありません。
全角を受け入れても保存形式は別に決める
全角・半角の入力方法が混在する日本語環境では、どの変換を許可するかを明示してください。受入後はサーバーの保存値と再表示値を比較し、フロントだけが整形していないか確認します。
専用チェッカーの処理を、別の住所フォームテスターや自社APIも実装していると仮定しないでください。
4桁だからといって0を補わない
2108 は 02108 の0が落ちた値かもしれませんが、入力途中の値かもしれません。信頼できる元レコードに 02108 がある場合は変換不具合を追跡できますが、すべての4桁に0を足す修正はできません。元の入力を残し、利用者が確認できる説明を出してください。
空欄はこのチェッカーでは不合格です。下書き保存など別の業務で空欄を認める場合は、その契約の期待結果を別に定義します。
入力・保存・住所照合の契約を分ける
| 判断 | 確認内容 |
|---|---|
| 入力型 | 文字列。必要なら数字キーボードを促すが、数値計算用に変換しない。 |
| 受入形 | 5桁、対応する場合のZIP+4、明示した全角・空白の整形。 |
| 保存値 | 先頭0と必要なハイフンを保持した文字列。 |
| エラー | 対象項目の理由と編集可能な元入力。 |
| 住所照合 | 実配送で必要なら、別の適切な住所サービスで実施。 |
USPS の末行規則は住所表示、HTML はブラウザーの入力動作を説明します。ローカルの正規表現は郵便番号の割当を照会しません。受入後の保存確認はコピー・保存・出力の実測へ進んでください。
形式の合格から配達を推測しない
今回 USPS 照会、受取人確認、郵送はしていません。都市・州との整合、部屋番号、居住者、配送サービスの受付可否は判定対象外です。入力欄を通すために ZIP+4 の末尾を作っても、実在する宛先の修正にはなりません。
CSV の取り込みで値が変わった場合は元ファイルの文字列から調べます。表計算ソフトの型推定と、このブラウザーの形式テストを同じ結果として扱わないでください。
検証範囲と参照資料
AddressLab が AI の補助を使って構成し、実際のブラウザー操作記録と以下の一次資料を照合しました。2026年10月24日、ローカルの本番ビルドを独立した Chrome で検証し、機能テスト中は外部の広告・解析リクエストを遮断しました。結果は住所の割当、実際の配達、メール所有権、税額を証明するものではありません。