住所確認とジオコーディング

目標

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

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

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

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

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

Address Validation API と 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 を使用することをおすすめします。

• 主な目的は住所の場所を取得することであり、個々の住所の精度は重要ではない場合があります。
  • たとえば、大規模なデータセットからヒートマップを生成する場合などです。
• 建物の入口、建物の輪郭、乗車 / 降車ナビゲーション ポイントなど、地域密着型の目的地の詳細情報が必要な場合（Geocoding API v4 の SearchDestinations メソッドで利用可能）。
• グローバルなソリューションが必要だが、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 で同じ住所を使用すると、Geocoder ツールの次のスクリーンショットに示すように、「California」に一致させることができます。

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

スペルミスの例

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 が 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 に関するドキュメントには、有効な住所と無効な住所を区別する方法が詳しく記載されています。

ベスト プラクティス

地域の指定

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 は入力エラーに対してより寛容で、検証できない住所コンポーネントをハイライト表示し、入力データを修正します。
• 住所に関する詳細情報（住宅用か商業用かなど）が必要です（一部の地域で利用可能）。

次のステップ

ホワイトペーパー「信頼性の高い住所で購入手続き、配送、オペレーションを改善 」をダウンロードし、ウェブセミナー「Address Validation で購入手続き、配送、オペレーションを改善 」をご覧ください。

おすすめの関連情報:

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

寄稿者

この記事は Google が管理しています。このドキュメントは、以下のコントリビューターによって作成されました。

主な著者:

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

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

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