ジオコーディングとは？座標、ジオコーディング API、逆引きの基礎

ジオコードとは、住所を地球上の一点に紐づける座標です。「10 Downing Street, London」のような人間向けの場所名と、機械可読な幾何情報（51.5034, -0.1276）をつなぐ橋の役割を果たします。これまでにクリックしたあらゆる地図ピン、タップした「ここに配達」ボタン、実行した「近くを表示」クエリは、スタックのどこかでジオコードによって支えられてきました。

このガイドでは、ジオコードが実際には何なのか、フォワードジオコーディングと逆ジオコーディングの違い、本番運用のジオコーディング API が返す内容、そしてよくある落とし穴がどこに潜んでいるかを解説します。

ジオコードとは本当のところ何か

最も厳密な意味で言えば、ジオコードとは地球表面上の単一の点であり、既知の測地系（ほぼ常に WGS84、スマートフォンの GPS が使うのと同じ測地系）上の緯度経度のペアで表現されます。緯度は -90（南極）から +90（北極）まで、経度はグリニッジ子午線を 0 として -180 から +180 までの範囲を取ります。

この厳密な定義の外側では、「ジオコード」はもう少し緩い意味で「住所をジオコーディング API に通した結果」を指して使われます。これには座標に加えて、正規化された住所、場所識別子、精度ティア、信頼度スコア、バウンディングボックスといった関連メタデータの一式が含まれるのが普通です。本番コードで実際に保存し、判断に用いるのはこの豊富なオブジェクトのほうです。

座標だけでは「どこか」しか分かりません。「その『どこか』をどれくらい信用してよいか」を伝えるのはメタデータです。

フォワードと逆ジオコーディング

方向は二つあり、同じ API エンドポイントが両方を扱うのが一般的です。

フォワードジオコーディング（Forward geocoding） はテキストを座標に変換します。入力は「Eiffel Tower, Paris」、出力は 48.8584, 2.2945、加えて一致した場所の種類（このケースでは landmark）、行政区分の内訳（Paris、Île-de-France、France）、地物のバウンディングボックスです。

逆ジオコーディング（Reverse geocoding） は座標をテキストに変換します。入力は 48.8584, 2.2945、出力は構造化された住所（Avenue Gustave Eiffel, 75007 Paris, France）、場所の種類、そして通常は近くの POI のリストです。

フォワードはチェックアウトのオートコンプリート、店舗検索、CSV から地図へのパイプラインを支える機能です。逆は「近くで受け取り」ボタン、ジオタグ付き写真、そしてユーザーが地図上にピンを落としてアプリがそのピンに名前を付ける必要があるあらゆる機能の土台になります。

ジオコーディング API が返すもの

座標だけでは機能を出荷するには足りません。本格的なジオコーディング API は、コードで判断を下せるよう構造化されたオブジェクトを返します。重要なフィールドは次のとおりです。

• latitude / longitude: WGS84 上の値
• formatted_address: 表示用に正規化された正準的な住所文字列
• place_id: 後で再解決できるよう保存可能な安定した識別子
• precision（場合により match_type や accuracy）: rooftop、street、neighbourhood、postcode、locality、country のいずれか。ビジネス判断を下す上で最も重要なフィールドです
• confidence: API がどれくらい確信しているかを示す数値スコア（多くは 0 から 1）
• bbox: 一致した地物のバウンディングボックス。地図を結果に合わせてフィットさせるのに便利です
• address_components: 番地、市区町村、地域、国、郵便番号など構造化された住所の各パート
• country_code: ISO 3166-1 alpha-2 形式

二つの実データの精度はまったく違うものになり得ます。配達を発送する前に欲しいのは、住居用住所に対する rooftop 一致です。「最寄り店舗を表示」であれば postcode レベルでも構いません。locality 一致は市区町村しか分かっていないことを意味し、確認なしに行動するには十分でないことがほとんどです。

ジオコードはどこで使われているか

ジオコードは、ロケーション対応のプロダクト機能のほとんどで静かに動いています。

• 住所オートコンプリート: チェックアウトフォームのキー入力ごとにフォワードジオコードが実行され、ランク付けされた候補が返されます
• 店舗・会場検索: ユーザーの現在地（ジオコード）を、保存済みの店舗一覧（こちらもジオコード）と照合し、ハバーサイン距離で並べ替えます
• 配達と配車: 顧客住所のフォワードジオコードによって、ドライバーアプリが正確なルート計算用の座標を得られます
• 物件・在庫リスティング: 不動産、バケーションレンタル、ホテルのプラットフォームは、各リスティングを取り込み時に一度だけジオコーディングして座標を保存し、「このエリアで」検索に利用します
• アナリティクスとダッシュボード: 入ってくるレコード（注文、サポートチケット、IoT イベント）をジオコーディングし、地域別の集計や地図上での可視化を可能にします
• AI エージェントとアシスタント: LLM に「近くのレストランを探して」と問いかけられたとき、ジオコーディングのステップでユーザーの位置と候補地を座標に変換し、モデルが距離について推論できるようにします

これらすべてにおいて、ジオコードは結合キーとして機能します。住所文字列が「Street」と「St」のどちらで綴るかで揉めていても、同じ場所についての二つのレコードを同じ地図の上に並べられるのは、ジオコードのおかげです。

本番運用での落とし穴

ジオコーディングは、初日には簡単に見えて、毎週のように難しさが増していくタイプの問題です。

住所の曖昧さ。 「Springfield」はアメリカの 41 州に存在します。国、地域、郵便番号といった文脈なしのフォワードジオコードは、ほとんど運任せです。常に持ち得るかぎりの文脈を渡し、country_code をバイアスパラメータとして含めましょう。

古くなった座標。 通りは番地が振り直され、地区名は変わり、新しい建物が現れます。2 年前に保存したジオコードは、もう同じ建物を指していないかもしれません。鮮度が重要なレコード（配達、配車、規制業種）では、定期的に再ジオコーディングし、保存済み座標と比較してください。

精度のロンダリング。 雑な UI は、precision が locality のときでも結果を「✓ 住所が見つかりました」と表示してしまいます。ユーザーは緑のチェックを見て住所が確認済みだと思い込みますが、実際には API は市区町村しか一致させていません。チェックアウトや KYC のような重要なフローでは、必ず precision ティアを UI に表示してください。

クォータとレート制限。 ジオコーディング API はリクエスト課金で、秒間レート制限があります。バルク処理にはバッチ化が必要ですし、ユーザー向けのオートコンプリートにはクライアント側のデバウンスが欠かせません。

プライバシー。 座標とタイムスタンプの組は個人データです。他の PII と同じくジオコードを扱い、ストレージを厳格に保護し、アクセスをログに残し、運用先のロケールに合わせて GDPR のルールを尊重してください。

MapAtlas でのジオコーディング

MapAtlas Geocoding API は、フォワードジオコーディングと逆ジオコーディングを単一のエンドポイントで処理します。上記の標準フィールド（formatted address、place ID、precision、confidence、bounding box、address components）を返し、数百万行を処理する取り込みパイプライン向けにバッチジオコーディングもサポートします。国と言語のバイアスパラメータにより、ロケールごとに別リクエストを発行することなく、欧州および世界の利用者に関連性の高い結果を返せます。

ジオコーディングと所要時間分析を組み合わせるワークロードでは、Geocoding API は Isochrone API や Distance Matrix API と連携します。これにより、一回の住所検索がそのまま「15 分以内のすべてを表示」や「これらの候補を所要時間で並べ替える」へと流れていきます。

ジオコードは華やかな存在ではありません。ただの座標です。しかし、テキストの文字列を、アプリケーションが推論できる「場所」に変える座標であり、この一片のデータを正しく扱えるかどうかが、本物のロケーション対応機能と、誤った大陸に立てられたピンとを分けるのです。