2026年の住所パーサー：トークン化、曖昧性、フォールバック

解析はテキストに存在していた構造を復元します。郵便番号、地域コード、市区町村、番地行を、その信頼性の順に復元します。しかし、書かれていない情報は復元できません。ユニット番号の指定がない文字列にはユニット番号は含まれておらず、どれだけ推論しても捏造すべきではありません。

また、フィールドが真実であることを確認することもできません。「123 Main St, Springfield, IL 62701」を解析すると一貫したフィールドが得られますが、その住所が架空である可能性や、市区町村がZIPと一致しない可能性もあります。解析はテキスト操作です。検証はデータ操作であり、この2つは関数名や成功メッセージを共有すべきではありません。

第1段階は正規化です。前後の空白を除去し、内部の空白をまとめ、ノーブレークスペースを置換し、句読点の異体を正規化し、大文字化するかどうかを決定します。フォールバック用に元の文字列はそのまま保持します。第2段階は分割です。カンマがあればカンマで分割し、なければ国の文法で分割します。第3段階は分類です。国のルールセットを使って各セグメントを郵便番号、地域、市区町村、番地、ユニットとしてラベル付けします。第4段階は割り当てです。ラベルをフィールドにマッピングし、競合を解決し、結果にスコアを付けます。

各段階を分離しておくことで、失敗モードも分離できます。分割のバグは分類のバグとは異なる見え方をし、各段階を独自のコーパスで単体テストできます。また、早期に停止することも可能です。国が不明な場合は分類を完全にスキップし、各フィールドの信頼度を不明としてセグメントを返します。

フィールド順序は誤解析の最大の原因です。同じトークンが場所によって移動するからです。米国、カナダ、英国、オーストラリアでは郵便番号が市区町村の後に来ます。ドイツ、フランス、オランダ、ベルギーでは市区町村の前に来ます。日本では都道府県の前に最初に来ます。ブラジルでは州の後に区切り文字を挟んで郵便番号が来ます。

だからこそ、パーサーは何かを分類する前に国を知っている必要があります。文字列自体から国を推測するのは循環論法です。郵便番号のパターンから示唆されることはありますが、多くのパターンが重複しています。フォーム、ロケール、または明示的なセレクターから国を取得し、州や国のどちらかである可能性のある2文字のトークンから推測するのではなく、国が欠落している場合は解析を低信頼度としてマークしてください。

二次ユニット指定子は最も一般的な曖昧性です。「Apt」「Ste」「Unit」「Fl」「Rm」は識別子が続く場合は信頼できますが、「Unit 5」は通りの名前であることもあり、「Building 3」はキャンパスの主住所であることもあります。パーサーは、指定子の後に数字または短い英数字トークンが続き、番地番号の後に現れる場合にのみユニットを抽出すべきです。

通りの接尾辞は2つ目の罠です。「Way」「Court」「Park」のようなトークンは、接尾辞、通りの名前、または市区町村になり得ます。方向指示語も同じ問題を抱えています。「N」は前置方向指示語、通りの名前の略語、または地域になり得ます。番地番号とカンマ構造に対する位置を使用し、2つの読み方が両方とももっともらしい場合は、選択するのではなく元のセグメントを保持して信頼度を下げてください。

各フィールドにスコアを付け、次にレコードにスコアを付けます。フィールドは、国の固定パターンに一致し、その位置が期待される順序と一致した場合に高信頼度です。パターンは一致したが位置が推測された場合は中程度、消去法で割り当てられた場合は低信頼度です。レコードは、すべての必須フィールドが高信頼度で、未配置のセグメントがない場合にのみ高信頼度となります。

しきい値を設定し、それを強制します。しきい値を超えた場合は受け入れて保存します。下回る場合は、推測を構造化カラムに書き込むのではなく、元の文字列を保持してレコードをレビュー用にフラグ付けします。APIレスポンスでスコアと理由を公開してください。レビュー担当者は何かが失敗したことだけでなく、どのフィールドが失敗したかを知る必要があるからです。

解析結果にはブール値ではなく、明示的な結果が必要です。国が欠落している場合は文法を実行できません。郵便番号の欠落は、郵便番号がある国では問題であり、香港やUAEでは正常です。配置できないセグメントは、カンマ構造と文法が一致していないことを意味し、レコードには人間の目が必要です。

各結果に安定したコードを付与し、呼び出し元が散文を解析せずに分岐できるようにします。正規化された入力、元の入力、信頼度付きのフィールド値、および未配置セグメントのリストを返します。このペイロードにより、UIはフォームの上部に一般的なエラーを表示するのではなく、失敗した正確なトークンをハイライトできます。

国ごとに1〜3件の手動検証済み住所からなる小さなコーパスから始めます。各住所には、その国の郵便物を読める人が書いた期待フィールド値が付きます。20〜40件のケースで構造的なリグレッションを捉えるのに十分であり、プルリクエストでレビューするのに十分小さいです。テストコードに埋め込まれたアサーションではなく、データとして保存してください。

次に、各ケースを機械的に変異させます。カンマを削除し、大文字小文字を変更し、二重スペースをまとめ、ノーブレークスペースを挿入し、2行を入れ替え、接尾辞を省略し、ユニットを追加します。変異に対する期待出力は常に同一とは限りませんが、定義された許容範囲内に収まるべきであり、フィールドが黙って変わるのではなく信頼度が下がるべきです。フィールドごとに適合率と再現率を追跡し、市区町村の修正が郵便番号を静かに壊さないようにします。

自由形式のメモ、配達指示、または人間が散文として書いたものは解析しないでください。「Leave at the side gate, second house after the blue one」にはフィールドがなく、そこからトークンを抽出すると自信に満ちたゴミが生成されます。注文に添付されたテキストブロブとして保持してください。

ルールセットが対応していないスクリプトは解析しないでください。漢字の日本の住所には日本語の文法が必要です。ラテン文字のトークナイザーを実行すると誤った境界で分割され、都道府県が失われます。番地番号がない住所や、アジアの一部やキャンパスの住所で一般的な建物名を主要な位置指定子として使用する住所は解析しないでください。これらすべての場合において、正しい出力は元の文字列と明確な「未解析」ステータスです。