ガイド

シンプルな「最寄りのオフィス」検索を作る

オフィスがいくつかしかない会社なら、「自分に一番近いオフィスはどこか」に答えるために凝った仕組みは必要ありません。1回のジオコーディングリクエストと、めったに変わらない一覧との短い比較だけで十分です。

入力をジオコーディングする

訪問者が入力したのが住所でも郵便番号でも、ジオコーディングして座標を取得します。

GET /v1/forward?q=Berlin, Germany&limit=1
{
  "status": "ok",
  "results": [
    {"formatted": "Berlin, Germany", "lat": 52.5200, "lon": 13.4050, "type": "locality", "precision": "city", "confidence": 0.85, "place_id": "bl456", "components": {"city": "Berlin", "country": "DE"}}
  ]
}

オフィス一覧と比較する

オフィスの座標は、自社のコードや設定の中に小さな固定リストとして保持してください。めったに変わらないため、毎回それ自体を検索する必要はありません。

offices = [
  {"name": "Berlin", "lat": 52.5170, "lon": 13.3888},
  {"name": "Paris", "lat": 48.8566, "lon": 2.3522},
  {"name": "London", "lat": 51.5074, "lon": -0.1278}
]

標準的なハーバサイン公式を使って訪問者の座標から各オフィスまでの距離を計算し、距離順に並べ替えて最も近いものを返します。

2つ目の例:入力補完フィールドを追加する

ただのテキストボックスではなく、所在地フィールドの裏側で/v1/autocompleteを使えば、訪問者は入力しながら候補の場所を選べるため、入力ミスによって予期しないジオコーディング結果になる可能性を減らせます。候補が選択されたら、そのplace_idまたはテキストを同じジオコーディングの流れで解決すれば、すでに説明した距離の比較にそのまま渡せます。

市区町村レベルの一致への対応

上の例では、訪問者が都市名しか入力していないため、精度が「house」ではなく「city」になっている点に注目してください。オフィス検索ではこれで問題ありません。目的は正確な建物を特定することではなく、いくつかの選択肢の中から最寄りのオフィスを選ぶことだからです。配送先住所の場合とは異なり、ここでは粗い精度に特別な対応は必要ありません。

避けるべきよくある間違い

実際のオフィスが開設、閉鎖、移転したときには、自社コード内の固定オフィス一覧を忘れずに更新してください。この一覧はAPIではなく自社の設定の中にあるため、気づかないうちに古くなりやすく、訪問者を閉鎖した拠点へ案内し続けたり、新しい拠点をすべての比較から除外したままにしたりしがちです。一覧は一度きりの初期設定ではなく、定期的なコンテンツ見直しの一部として扱ってください。

エッジケース:あいまいな地名

短い地名は、ある国と、別の場所にある無関係な地域とで同じ名前が使われている場合のように、まれに複数の実在の場所に一致することがあります。countriesパラメーターを渡して候補を実際にオフィスを置いている国に限定すれば、この種のあいまいさによって地球の反対側の場所に解決されてしまうことを防げます。

最寄りの1件以外も表示する

最寄りの1件だけでなく近い順に2〜3件のオフィスを表示すれば、地域の境界付近にいる訪問者が、距離では少し遠くても言語やタイムゾーンがより合っている拠点など、本当に自分に合うものを選べるようになります。

コスト

検索1回につきジオコーディングリクエストは1件です。オフィス一覧との比較はその後すべて自社のコード内で行われるため、リクエスト数は増えません。このようなページであれば、安定したトラフィックがあっても、すべてのキーに含まれる1日あたりの無料リクエスト2,500件の範囲に十分収まります。

この方法で作る最寄りオフィス検索は、訪問者の検索1回につきリクエストがちょうど1件で済み、実際の比較ロジックはすべて自社側にあります。リクエスト形式の詳細はジオコーディングのドキュメントをご覧ください。