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

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

目的

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

Address Validation API は Google Maps Platform が提供するサービスで、お客様は住所が正確かどうかを検証できます。

Geocoding API による Geocoding は、住所を地理座標に変換するプロセスです。地理座標を使用してマーカーを地図上に配置したり、地図上の位置に配置したりできます。

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

Address Validation と Geocoding API のどちらを選ぶべきか

Address-Validation-vs-Geocoding

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

ユーザー操作のユースケースとは、ユーザーが存在して結果を操作する場合を指します。
Places Autocomplete は JavaScript API であるため、ユーザーインターフェースとの統合に適しています。
お客様は、既存の住所のデータ品質に問題があることにお気づきでしょうか。したがって、ジオコードだけが必要な場合は、Address Validation API を介してそれらの場所を実行し、データセットを修正することをおすすめします。

上記のディシジョンツリーに基づき、特定のプロダクトを優先して使用すべきケースは数多くあります。ただし、目標を達成するために両方のサービスを使用する場合もあります。

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

データが疑わしい場合や、不正確な住所が下流に悪影響を及ぼす可能性は高い。これは、入力が高い精度の結果が得られなかった理由について、Address Validation API がより多くのフィードバックを提供するためです。
ユーザー入力（スペルミスやフィールドの欠落など）を修正する必要があり、正確な結果が出力される可能性が高くなります。
対象地域が、Address Validation API から返されるメタデータ（建物の種類が住宅用か商業用か）など、Geocoding 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 です。Fake St に対して UNCONFIRMED_BUT_PLAUSIBLE を返すことにより、API はそれを道路名として持つ可能性はあると判断しましたが、それをサポートしている住所データとは一致させません。

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

Geocoding API でも同じ住所を使用することで、「California」をマッチングできます。ジオコーディングツールのスクリーンショットは、こちらでお試しいただけます。

alt_text

しかし、その結果は州全体のジオコードであり、入力のどのコンポーネントが欠陥の可能性があるかについてのフィードバックはほとんどありません。

スペルミスの例

76 Buckingamm Palace Road, Londn, SW1W 9TQ, 英国

上記の住所にはいくつかのスペルミスがあります。1 つは番地と、もう 1 つは地域区分のみです。

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 で番地を見つけられなかった、または番地と一致できなかったことを意味します。

注: 住所が存在するかどうかを確認するには、いずれかのパラメータ（types、partial_match, results, status) など）が Geocoding API レスポンスに設定されているかどうかを確認します。これにより、住所の存在の信頼度が徐々に高まりますが、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 を返しても、その住所が存在するとは限りません。同様に、partial_match フラグが true に設定された状態で Geocoding API が返された場合、適切な結果となる可能性があります。

このタイプの誤一致は、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 のデータベースに正確な場所として存在しない「合成」住所の場所を返すことがあります。

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

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

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

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

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

レスポンスオブジェクトの概要については、こちらをご覧ください。
レスポンスのさまざまなコンポーネントを示すデモは、こちらをご覧ください。
購入手続き時の Address Validation のドキュメントには、正しい住所と不正な住所を区別する方法が詳しく記載されています。

ベストプラクティス

地域の指定

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 を更新してください。

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

おわりに

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

特に配送サービスを提供するため、正確な送付先住所が必要です。
入力データの品質が低いことがわかっています。Address Validation API は入力エラーを許容し、検証できない住所コンポーネントをハイライト表示し、入力データを修正します。
住所には、居住用か商業用か（一部の地域のみ）などの詳細情報が必要です。

次のステップ

ホワイトペーパー「Optimizing checkout, delivery, and operations with フルアライズ」ホワイトペーパーをダウンロードし、Address Validation による購入手続き、配達、運用の改善ウェブセミナーをご覧ください。

協力者

この記事は Google が管理します。以下の寄稿者が執筆しています。

主要な著者:

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

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

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