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

目的

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

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

Geocoding と Geocoding API を組み合わせて行う処理は、住所を地理座標に変換する処理であり、これを使用して地図上にマーカーや地図上の位置を配置できます。

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

今すぐ試す: Google Cloud コンソールにアクセスし、Address Validation API と Places API を有効にします。

Address Validation と Geocoding API を選択する場合

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

• ユーザー操作のユースケースとは、ユーザーが結果を操作するために存在している状況を指します。
• Places 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 レベルまで詳細なフィードバックを提供できます。

偽の 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 と同じ住所を使用して、ジオコーディング ツールのスクリーンショットにあるように、「カリフォルニア」に一致する結果を得ることができます。これは、こちらで試すことができます。

しかし、その結果は状態全体のジオコーディングとなり、入力のどのコンポーネントに欠陥があったかについてのフィードバックは最小限に抑えられます。

スペルエラーの例

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

上記の住所には 2 つのスペルミスがあります。1 つは町名、もう 1 つは地区です。

Address Validation と 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 コマースの購入手続きの顧客など）で修正を再確認できます。

データの欠落とスペルミスの例

Bollschestragooge 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）までの住所を検証し、宿泊施設に関するメタデータ（商業施設であることなど）を提供できます。

プレミス:

"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 はこの順序で評価されます。この場合、最初の一致は Chicago（より具体的には 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 - 地域コード

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

プレイス ID の保存

今後のリクエストに備えて、Google Maps Platform から位置情報を保存するために、プレイス ID をビジネスの属性としてデータベースに無期限に保存することができます。Find Place リクエストは、場所 ID ごとに 1 回だけ実行する必要があります。ユーザーが取引の詳細をリクエストするたびにプレイス ID を検索することもできます。

常に最新の情報を保持するには、place_id パラメータを指定した Place Details リクエストを使用し、12 か月ごとにプレイス ID を更新してください。

注: ジオコーディングに関するベスト プラクティス ガイドもご覧ください。

おわりに

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

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

次のステップ

ホワイトペーパー「信頼できる住所で購入手続き、配達、業務を改善 」をダウンロードし、「Address Validation を使用して購入手続き、配達、業務を改善する 」ウェブセミナーをご覧ください。

関連資料:

• e コマース購入手続きでの住所確認
• Place Autocomplete のドキュメント
• Address Validation API ドキュメント
• Google Maps Platform のレポート

協力者

この記事は Google が管理しています。最初に書いたのは以下の寄稿者です。

主任執筆者:

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

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

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