このページは 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

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

ユーザー操作のユースケースとは、ユーザーが結果を操作するユースケースです。
Places Autocomplete は JavaScript API であるため、ユーザーインターフェースとの統合に適しています。
既存の住所のデータ品質に関する問題はご存じかもしれません。ジオコーディングのみが必要な場合でも、Address Validation API を使用して位置情報を取得し、データセットを修正することをおすすめします。

上記のディシジョンツリーに基づいて、どちらか一方のプロダクトを選択する状況は数多くあります。一方、目標達成のために両方のプロダクトを使用する場合もあります。

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

データに疑問がある場合や、住所が間違っているとダウンストリームに悪影響を及ぼす可能性がある場合。これは、Address Validation API が、入力が精度の高い結果を得られなかった理由について詳細なフィードバックを提供するからです。
ユーザー入力（スペルミスやフィールドの不足など）を修正する必要があります。これにより、出力結果の精度が向上します。
対象地域で、Geocoding API と比較して Address Validation API から返されるメタデータが多い（建物のタイプが住宅か商業施設かなどの分類など）。

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

主な目的は住所の位置情報を取得することであり、個々の住所の精度は重要ではない場合があります。
- たとえば、大量のデータセットからヒートマップを生成する場合などです。
グローバルなソリューションが必要であり、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 です。Fake St に対して UNCONFIRMED_BUT_PLAUSIBLE を返すことで、API は、その名前が通りに付けられている可能性があると判断しましたが、サポートされている住所データと照合することはできませんでした。

API の結果をフィードバックとして使用すると、この入力の道路コンポーネント（Fake St）に問題があることが推測できます。

Geocoding API で同じ住所を使用すると、こちらで試すことができるジオコーディングツールのスクリーンショットに示すように、「カリフォルニア」と一致させることができます。

alt_text

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

スペルミスの例

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

上記の住所には、町名と地域に誤字脱字が含まれています。

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

入力時に誤字脱字があった住所のコンポーネントの例を次に示します。

{
  "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 から ROOFTOP または RANGE_INTERPOLATED の location_type が返された場合、住所が存在することを意味するとは限りません。同様に、Geocoding API が partial_match フラグを true に設定して返しても、適切な結果が得られる場合があります。

この種の誤った照合は、Geocoding API で解決するのが非常に困難な問題です。少なくとも、リクエスト / レスポンスの国と地域に関する基本的な後処理検証を実装することを検討してください。実際の住所と照らし合わせて、住所の表記ミスや不完全な住所がないか確認することもできます。

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

部分一致と誤った一致

住所が部分一致の場合（つまり、Geocoding API が住所を正確に特定できなかった場合）、レスポンスには次の情報が含まれます。

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

上記のロケーションタイプよりもさらに重要なのは、レスポンスに partial_match = true が含まれるタイミングを検討することです。partial_match は、Geocoding 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 API または Geocoding API を呼び出す際は、その住所を検索する地域を制限することをおすすめします。2 つの API では、この処理が 2 つの異なる方法で実装されています。

Geocoding API - 地域バイアス

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

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

場所 ID の保存

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

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

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

まとめ

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

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

次のステップ

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

おすすめの関連情報:

寄稿者

この記事は Google が管理しています。以下は、このガイドを最初に作成したコントリビューターです。

主な作成者:

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

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

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