このページは Cloud Translation API によって翻訳されました。

Google Maps Platform を使用してロケーション検証機能を構築する

目標

場所の位置情報を検証する必要があることはよくあります。Google Maps Platform には、このユースケースに役立つさまざまなサービスがあります。このドキュメントでは、2 つの主要な位置情報検証サービス（Address Validation API と Geocoding API）のどちらを選択すべきかについて説明します。

Address Validation API は、Google Maps Platform のサービスで、住所が正確かどうかを検証するのに役立ちます。

Geocoding API を使用したジオコーディングは、住所を地理座標に変換するプロセスです。この座標を使用して、地図上にマーカーを配置したり、地図上の位置を指定したりできます。

Address Validation API と Geocoding API の違いの概要については、こちらをご覧ください。

Address Validation API と Geocoding API の使い分け

Address-Validation-vs-Geocoding

上記のフローチャートに関する注意事項:

ユーザーインタラクションのユースケースとは、ユーザーが結果を操作するために存在する場合を指します。
Place Autocomplete は JavaScript API であるため、ユーザーインターフェースとの統合に適しています。
既存の住所のデータ品質に関する問題に気づいている可能性があります。そのため、ジオコードのみが必要な場合でも、Address Validation API を使用してこれらの位置情報を実行し、データセットを修正することをおすすめします。

上記のディシジョンツリーに基づいて、あるプロダクトを別のプロダクトよりも優先して使用する状況は数多くあります。ただし、目標を達成するために両方のプロダクトを使用する必要がある場合もあります。

次のような場合は、Geocoding API ではなく Address Validation API を使用することをおすすめします。

データに疑わしい点が多い場合や、誤った住所を取得すると下流に悪影響が及ぶ場合。これは、Address Validation API が、入力が高精度の結果を返さなかった理由に関するフィードバックをより多く提供するためです。
ユーザー入力（スペルミスやフィールドの欠落など）を修正する必要があるため、出力で正確な結果が得られる可能性が高まります。
対象地域では、Geocoding API よりも Address Validation API から多くのメタデータ（建物の種類が住宅用か商業用かなど）が返されます。

次のような場合は、Address Validation API ではなく Geocoding を使用することをおすすめします。

主な目的は住所の位置情報を取得することであり、個々の住所の精度は重要ではない。
- たとえば、大量のデータからヒートマップを生成する場合などです。
グローバルソリューションが必要ですが、Address Validation API はすべての対象リージョンで利用できるわけではありません。

次に、Geocoding API と比較した Address Validation API の機能を示す例をいくつか示します。

無効な住所の例

1 Fake St, Mountain View, CA 94043, USA

Address Validation API は、この入力を個々の住所コンポーネント（番地、市区町村、都道府県など）に分割します。また、住所が無効な理由について、PREMISE レベルまで詳細なフィードバックを提供することもできます。

Fake St はカリフォルニア州マウンテンビューには存在しません。Address Validation API は、返されたコンポーネントレベルの詳細にそのことを反映しています。

{
  "componentName": {
    "text": "Fake St",
    "languageCode": "en"
   },
   "componentType": "route",
   "confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
 }

この場合、検査する重要なプロパティは confirmationLevel です。API は、Fake St に対して UNCONFIRMED_BUT_PLAUSIBLE を返すことで、その名前の通りが存在する可能性はあるものの、サポートされている住所データと照合できないと判断しています。

API の結果をフィードバックとして使用すると、この入力の番地コンポーネント（Fake St）に問題があることがわかります。

Geocoding API で同じ住所を使用すると、ジオコーディングツールで「California」と一致させることができます。こちらで試すことができます。

alt_text

ただし、結果は州全体のジオコードであり、入力のどのコンポーネントに欠陥がある可能性があるかについてのフィードバックは最小限です。

スペルミスの例

76 Buckingamm Palace Road, Londn, SW1W 9TQ, GB

上記の住所には、町名と地域にそれぞれ 1 つずつ、2 つのスペルミスがあります。

Address Validation API と Geocoding API の両方で、これらの間違いを修正し、「76 Buckingham Palace Road, London, SW1W 9TQ」という結果を得ることができます。ただし、Address Validation API を使用すると、このプロセスに関する詳細情報を取得できます。

入力時にスペルミスがあった住所コンポーネントの 1 つを見てみましょう。

{
  "componentName": {
    "text": "Buckingham Palace Road",
    "languageCode": "en"
        },
        "componentType": "route",
        "confirmationLevel": "CONFIRMED",
        "spellCorrected": true
     }
}

Address Validation API は、フィールドが修正されたことを示すフラグを返します。このフラグに対してビジネスロジックを実装して、データプロバイダ（e コマースの購入手続きの顧客など）との修正を再確認できます。

データが見つからない場合とスペルミスがある場合の例

Bollschestraße 86, 12587, DE

上記の住所では、町名にスペルミスがあり、ベルリンの市区町村がありません。

Address Validation API は、これらのエラーを両方とも修正し、PREMISE レベルのジオコードと、PREMISE レベルで検証された住所を返します。

Bölschestraße 86, 12587 Berlin, DE

この場合、Geocoding API は入力エラーを正常に克服できず、ZERO_RESULTS の結果を返します。

追加の住所メタデータの例

111 8th Avenue Ste 123, New York, NY 10011-5201, US

この住所は、建物内に存在しない部屋番号（Ste 123）を除いて正しいです。

Address Validation API は、住所を PREMISE（111 8th Ave）まで検証し、その物件が商業用であることなどのメタデータを返します。

premises:

"business": true

また、レスポンスの uspsData の一部として返される dpvConfirmation 値は S です。

"dpvConfirmation": "S"

dpvConfirmation 値が S の場合、住所は PREMISE レベルで検証済みですが、入力で指定された部屋番号はその住所に関連付けられていません。

Geocoding API ではこの情報を提供できません。

Geocoding API レスポンスについて

概要

Geocoding API を使用する場合、ジオコード結果のレスポンスには、指定された住所の詳細を把握するために使用できるさまざまな手がかりが含まれています。

Geocoding API は、階層内の住所コンポーネントを解決することで機能します。

たとえば、123 Example Street, Chicago, 60007, USA は次の順序で解決されます。

/ Example Street/ Chicago/ 60007/ USA は、その順序で評価されます。この場合、最初の一致はシカゴ、より具体的には 60007 郵便番号です。したがって、その郵便番号の次の Place_id が返されます。

ChIJwRKzf8ixD4gRHiXqucwr_HQ

Geocode API のレスポンスには、次の情報が含まれます。

        "partial_match": true,
           "place_id": "ChIJwRKzf8ixD4gRHiXqucwr_HQ",
           "types": [
               "postal_code"
           ]

Geocoding API を使用すると、この住所がどのような場所であるかを確認できます。Geocoding API から返される住所 types のリストについては、こちらをご覧ください。

入力のコンポーネントが解決されない場合、API は次の値を返します。

{
   "results": [],
   "status": "ZERO_RESULTS"
}

番地なしで町名と番地のみを指定してリクエストを行うと、次のような形式で結果が返されます。

"types": [
  "route"
]

つまり、Geocoding API が番地を見つけられなかったか、一致する番地がなかったということです。

注: アドレスが存在するかどうかを確認するには、Geocoding API レスポンスで、types や partial_match, results, status) などのパラメータが設定されているかどうかを確認します。これにより、アドレスが存在する可能性の信頼度が徐々に高まりますが、100% 正確になるわけではありません。Address Validation API が必要なのはそのためです。

上記の手法を使用すると、Geocoding API レスポンスのみから住所の精度に対する信頼性を高めることができます。ただし、Address Validation API の結果とは異なり、Geocoding API は結果の精度を判断するための正確なフィードバックを返しません。

ロケーションタイプ

このセクションを正しく理解するには、Geocoding API のレスポンスから返される可能性のあるさまざまな位置情報のタイプを理解する必要があります。

ROOFTOP は、返された結果が正確なジオコーディングであり、番地レベルまで正確な位置情報があることを示します。
RANGE_INTERPOLATED は、返された結果が（交差点などの）正確な 2 地点間で補間された近似値（通常は道路上）を反映していることを示します。補間された結果が返されるのは、番地に対してルーフトップジオコーディングが使用できない場合が一般的です。
GEOMETRIC_CENTER は、返された結果が、ポリライン（道路など）やポリゴン（地域）などの幾何学的な中心であることを示します。
APPROXIMATE は、返された結果が上記に該当しないことを示します。

Geocoding API が location_type の ROOFTOP または RANGE_INTERPOLATED を返した場合でも、住所が存在するとは限りません。同様に、Geocoding API が partial_match フラグを true に設定して返した場合でも、それが正しい結果である可能性があります。

このような誤った一致は、Geocoding API で解決するのが非常に難しい問題です。少なくとも、リクエスト / レスポンスの国と地域に関する基本的な事後処理検証の実装を検討してください。さらに、実際の番地を比較して、スペルミスや不完全な住所がないか確認します。

注: Geocoding API を使用する場合は、定期的に初回リクエストと Geocoding API レスポンスの間でデータ品質チェックを行うことをおすすめします。

部分一致と誤った一致

住所が部分一致の場合（ジオコーディング API が住所を正確に特定できなかった場合）、レスポンスには次のものが含まれます。

"partial_match": true,
"types": [
           "locality",
           "political"
         ]

上記のロケーションタイプよりも重要なのは、レスポンスに partial_match = true が含まれるタイミングを考慮することです。 partial_match は、ジオコーディング API によって、元のリクエストに完全一致する住所は見つからなかったものの、部分一致する住所は見つかったことを示します。

元のリクエストで住所が不完全である可能性があります。多くの場合、リクエストで指定された地域に番地が存在しないために部分一致が発生します。また、同じ地域内に複数の場所があるリクエストを行った場合も部分一致が返されます。

たとえば、「21 Henr St, Bristol, UK」の場合は、Henry Street と Henrietta Street の両方の部分一致が返されます。リクエストに表記が間違った住所コンポーネントが含まれている場合、Geocoding API が別の住所を提示することもある点に注意してください。この場合、部分一致として結果が返されることはありません。

合成アドレス

Geocoding API は、Google のデータベースに正確な位置情報として存在しない「合成」住所の位置情報を返すことがあります。

このようなシナリオでは、レスポンスオブジェクトに長いプレイス ID と geometry.location_type=APPROXIMATE プロパティが含まれていることがよくあります。

レスポンスでこれらのインジケーターが検出された場合は、入力された住所を無効としてマークし、別の方法で再検証することを検討してください。

注: これは、Address Validation API を使用して、住所が存在しない場合に直接フィードバックを取得する別の例です。

Address Validation API のレスポンスについて

Address Validation API からのレスポンスを理解する方法については、すでに優れたドキュメントが用意されているため、ここでは詳細を説明しません。

レスポンスオブジェクトの概要については、こちらをご覧ください。
レスポンスのさまざまなコンポーネントを示すデモはこちら
Address Validation for checkout document に、有効な住所と無効な住所を区別する方法の詳細な説明が記載されています。

ベストプラクティス

地域を指定する

Address Validation API または Geocoding API を呼び出す際は、その住所を検索する地域を制限することをおすすめします。この 2 つの API は、これを 2 つの異なる方法で実装します。

Geocoding API - 地域バイアス

ジオコードが特定の国内にあることがわかっている場合は、地域バイアスを使用すると、より適切な結果が得られます。たとえば、カナダでジオコーディングを行う場合は、リクエストに &region=ca を追加してカナダにバイアスをかけることをおすすめします。なお、地域バイアスでは、その地域内の結果のみが優先されます。地域外の結果も表示されることがあります。
Address Validation API - 地域コード

同様に、Address Validation API は、regionCode フィールドを使用してリクエストで ISO2 コードが渡されると、より正確な結果を生成します。

場所 ID の保存

今後のリクエスト用に Google Maps Platform の場所情報を保管しておくには、場所の属性として、プレイス ID を保存することをおすすめします。Find Place リクエストは placeID ごとに 1 回のみ実行する必要があります。ユーザーが取引の詳細をリクエストするたびにプレイス ID を検索することもできます。

常に最新の情報にアクセスできるように、Place Details リクエストと place_id パラメータを使用し、12 か月ごとにプレイス ID を更新します。

注: ジオコーディングのベストプラクティスガイドも必ずご確認ください。

まとめ

このドキュメントでは、住所確認 API と Geocoding API の主な違いについて説明します。まとめると、次のような場合は Address Validation API の使用を検討してください。

特に配信可能性の観点から、正確な郵送先住所が必要です。
入力データの品質が低いことがわかっている。Address Validation API は入力エラーに対して寛容で、検証できない住所の構成要素をハイライト表示し、入力データを修正します。
住所には、住宅用か商業用かなどの追加情報が必要です（一部の地域で利用可能）。

次のステップ

確実な住所で購入手続き、配送、オペレーションを改善するホワイトペーパーをダウンロードし、Address Validation で決済、配送、オペレーションを改善するウェビナーをご覧ください。

参考資料:

寄稿者

この記事は Google が管理しています。このコンテンツは、以下の投稿者が作成しました。

主な著者:

Henrik Valve | ソリューションエンジニア

Thomas Anglaret | ソリューションエンジニア

Sarthak Ganguly | ソリューションエンジニア