すべての記事 開発者

緯度・経度で場所を検索する方法

作成者 The Kaleidr Team · 公開日 2026年8月10日 · 16 分で読了

検証済みの緯度・経度入力から地図上の正確な地点を表示し、必要に応じて逆ジオコーディングした場所名を添える画面。

緯度・経度で場所を検索するには、座標の組を検証し、値の順序を確認して地図を中央に移動し、必要に応じて逆ジオコーディングで場所名を追加します。最も多い誤りは座標順です。Googleは名前付きのlat/lngフィールドを使う一方、GeoJSON、Mapbox GL JS、MapLibre GL JSの配列は経度が先です。本番用ツールでは範囲を検証し、入力値を保持し、逆ジオコーディングが空の場合にも対応し、返された住所の精度を実際以上に見せないことが重要です。

以下では、検証、座標順の契約、Google Maps・Mapbox・MapLibreの例、逆ジオコーディング、GeoJSON、典型的な障害を扱います。製品情報はKaleidr Spatial AIと開発者ドキュメントを参照してください。地点を確定した後は、周辺スポット地図の検索起点として利用できます。

座標検索の要点

  • 先に検証： 緯度は-90〜90、経度は-180〜180です。
  • 順序を明示： 名前付きフィールドは曖昧さを減らし、配列には明確な契約が必要です。
  • 先に地点を表示： 正確な点を配置してから、必要に応じて逆ジオコーディングします。
  • 入力値を保持： 住所ラベルと並べて、利用者が入力した座標を残します。
  • APIに合わせる： Googleはlat/lng、GeoJSON・Mapbox・MapLibreは[lng, lat]です。

検証済みの緯度・経度入力から地図上の正確な地点を表示し、必要に応じて逆ジオコーディングした場所名を添える画面。

緯度・経度で場所を検索するには？

座標検索は短く決定的な手順で実装できます。緯度と経度を受け取り、小数点区切りと空白を正規化し、緯度が-90〜90、経度が-180〜180の範囲内か検証します。次に、使用する地図ライブラリの順序へ変換して地図を中央に移動し、マーカーを追加します。必要であれば逆ジオコーディングを行い、返された場所名と元の座標を併記します。逆ジオコーディングは座標の解釈であり、座標そのものの代替ではありません。Googleは、最も近い住所付与可能な位置に基づく推定と説明しています（逆ジオコーディング）。Mapboxも、テキストを座標へ変換する順ジオコーディングと、座標を説明文へ変換する逆ジオコーディングを区別しています（Geocoding APIの解説）。

緯度は赤道から北または南の位置を、経度は本初子午線から東または西の位置を表します。一般的な十進度の地理座標では、緯度は-90〜90、経度は-180〜180です。たとえばワシントンD.C.のある地点は、緯度38.8977、経度-77.0365と表せます。数値だけでなく、どちらが先かをアプリケーションが把握する必要があります。

座標の順序を誤ると検索が壊れるのはなぜ？

座標順は、地図検索が誤る最も一般的な原因の一つです。人向けの表記では緯度を先に書くことが多く、Google MapsのLatLngLiteralは名前付きのlatとlngフィールドを使います（座標リファレンス）。一方、GeoJSON Point、Mapbox GL JS、MapLibre GL JSの中心座標は経度・緯度の配列です。GeoJSONのRFCは位置配列を経度・緯度順とし、十進度のWGS 84地理座標を使います（RFC 7946）。名前付きフィールドは曖昧さを減らしますが、配列には明示的な座標順の契約が必要です。

緯度・経度の人向け入力、Googleの名前付きフィールド、GeoJSON・Mapbox・MapLibreの経度先行配列を比較した図。

システム 一般的な表現 順序
人向けの緯度・経度 38.8977, -77.0365 緯度、経度
Google Maps LatLngLiteral { lat: 38.8977, lng: -77.0365 } 名前付きフィールド
GeoJSON Point [-77.0365, 38.8977] 経度、緯度
Mapbox GL JSの中心 [-77.0365, 38.8977] 経度、緯度
MapLibre GL JSの中心 [-77.0365, 38.8977] 経度、緯度

多くのWeb地図は、WGS 84の経度と緯度を十進度で扱います。EPSGレジストリはWGS 84の2次元地理座標参照系をEPSG:4326とし、その軸を緯度・経度として示しています（EPSG:4326）。一方、GeoJSONの位置配列は経度が先です。したがって「EPSG:4326は緯度・経度」と「GeoJSONは経度・緯度」は、それぞれの仕様では両立します。実装では「lat/lon」という記憶ではなく、実際のAPIまたはデータ形式の契約に従ってください。

座標を解析・検証する方法

小さなパーサーで入力障害の大半を防げます。38.8977, -77.0365のような組、空白区切り、または別々の緯度・経度欄を受け付けます。有限数を必ず二つ要求し、緯度が-90〜90、経度が-180〜180を外れた場合は拒否し、アプリケーション内部では名前付きの{ latitude, longitude }を返します。先頭値が緯度範囲外という理由だけで自動的に入れ替えると、上流のデータ誤りを隠すおそれがあります。補正する場合は、値が逆かもしれないという明示的な候補として提示してください。

function parseCoordinatePair(input) {
  const parts = input
    .trim()
    .split(/[\s,]+/)
    .filter(Boolean);

  if (parts.length !== 2) {
    throw new Error("Enter exactly two coordinate values.");
  }

  const latitude = Number(parts[0]);
  const longitude = Number(parts[1]);

  if (!Number.isFinite(latitude) || !Number.isFinite(longitude)) {
    throw new Error("Coordinates must be valid numbers.");
  }

  if (latitude < -90 || latitude > 90) {
    throw new Error("Latitude must be between -90 and 90.");
  }

  if (longitude < -180 || longitude > 180) {
    throw new Error("Longitude must be between -180 and 180.");
  }

  return { latitude, longitude };
}

基本的なアクセシブルフォームでは、プレースホルダーだけでなく可視ラベルを使い、両方の入力にinputmode="decimal"を設定します。送信ボタンとrole="status"の状態領域を用意し、キーボードやスクリーンリーダーの利用者にもマーカーを見る利用者と同じフィードバックを届けます。座標テキストは地図キャンバスの外にも表示し、コピー完了を知らせ、マーカーのドラッグだけを編集手段にしないでください。

Google Maps、Mapbox、MapLibreの違い

Google Maps JavaScript APIは地点をLatLngまたはLatLngLiteralで表すため、名前付きのlatとlngを使えば配列順の曖昧さを避けられます。現在のGoogleドキュメントは新しいマーカーワークフローにAdvanced Markersを推奨しています（マーカーを追加）。検証後、{ lat, lng }で地図を中央に移動し、マーカーを作成または移動します。デモ設定は、プロジェクト用に制限したキーと必要な本番用マップIDへ置き換えてください。

Mapbox GL JSは地図の中心とマーカー座標に[longitude, latitude]を使います（Mapbox GL JS、マーカー）。配列を[longitude, latitude]で作り、setLngLatを呼んで同じ地点へflyToします。住所検索には認可されたMapboxのジオコーディング製品を使ってください。Mapboxは逆ジオコーディングを、地理座標をテキスト説明へ変換する処理と説明しています。

MapLibre GL JSも経度・緯度配列を使います（LngLat、Marker）。ドキュメントはGeoJSON仕様に合わせてこの順序を採用すると明記しています。MapLibreは描画エンジンであり、汎用ジオコーディング事業者ではありません。承認済みのサービスを別途接続し、そのライセンス、帰属表示、保存、認証情報の要件に従ってください。

地図の中央移動とマーカー配置に使う名前付きフィールドと経度・緯度配列の比較。

function showGoogleCoordinate(latitude, longitude) {
  const position = { lat: latitude, lng: longitude };
  map.setCenter(position);
  map.setZoom(16);
  marker.position = position;
}

function showLngLatCoordinate(latitude, longitude) {
  const lngLat = [longitude, latitude];
  marker.setLngLat(lngLat);
  map.flyTo({ center: lngLat, zoom: 16, essential: true });
}

逆ジオコーディングはいつ行うべきか？

マーカーは座標の位置を示します。地点を表示した後に逆ジオコーディングを行えば、近隣の読みやすい住所や行政区域を追加できます。元の座標と最も近い返却住所を両方表示し、結果が空でもマーカーは残してください。Googleは逆ジオコーディングが厳密ではなく、道路住所、地区、市、郡、州など複数レベルの結果を返し得ると説明しています（Maps JavaScriptの逆ジオコーディング例）。

正確な座標検索と、近隣住所や地理的背景を得る任意の逆ジオコーディングを分離した流れ。

これらは反対の問題を解きます。順ジオコーディングは住所や場所名を座標候補へ変換し、逆ジオコーディングは座標を読みやすい文脈へ変換します。直接座標検索は正確な地点を表示し、周辺検索は座標または場所を起点に条件に合う近隣スポットを返します。すでに座標があるなら、表示前にジオコーディングしないでください。正確な地点を先に表示し、逆ジオコーディングは任意の補足にします。その座標を起点として周辺スポットを取得し、距離や移動時間で順位付けできます。

検証済みの座標をGeoJSON Pointにすると、多くのWeb地図間で移動できる汎用的な地理オブジェクトになります。配列は[longitude, latitude]です。実用的なツールでは、緯度・経度または経度・緯度でのコピー、GeoJSONとしてのコピー、共有URL、現在の地図で開く、逆ジオコーディング、プロジェクトへの追加などを提供できます。

function toGeoJSONPoint(latitude, longitude) {
  return {
    type: "Feature",
    geometry: {
      type: "Point",
      coordinates: [longitude, latitude]
    },
    properties: {
      source: "coordinate-search"
    }
  };
}

DMS、UTM、精度、AIをどう扱うか？

多くの検索は十進度を使いますが、度・分・秒（DMS）で入力されることもあります。変換は「度 + 分÷60 + 秒÷3600」で、西と南は負にします。本番ツールでDMSを受け付けるなら、方位文字、Unicodeの度記号、秒の省略、負号と方位接尾辞の併用、60以上の分・秒、地域化を十分にテストしてください。座標を黙って誤読するパーサーより、範囲が狭くても信頼できる十進度ツールが適切です。

UTMは緯度・経度ではなく、投影された東距と北距を使います。EPSGレジストリはWGS 84 / UTMを、複数ゾーンに分かれたメートル単位の投影座標参照系として定義しています。そのため、検索にはゾーンと半球、または明確なCRS識別子が必要です。東距・北距をそのまま緯度・経度として扱わないでください。小数桁が多いほど表現は細かくなりますが、測定精度が高い保証にはなりません。保存値は完全に保持し、桁数だけを根拠にセンチメートル精度をうたわないでください。

座標検索そのものにAIは不要です。解析、検証、表示、任意の逆ジオコーディングは決定的な処理です。AIは地点確定後に、周辺の情報、車で行ける食料品店、地域の文脈、地点と空港の間のホテル、候補地の比較などを尋ねる際に役立ちます。Kaleidr Spatial AIは質問形式の場所探索を支援します。既存のMapbox、Google Maps、MapLibre地図にKaleidr Chatを接続して座標を自然言語探索の文脈にすることもできます（地図にAIチャットを追加）。地図は既存の描画エンジンが所有し、事実は信頼できる場所・経路サービスが担います。

特に重要な誤りとエッジケース

誤り 起きること 推奨する対処
すべてのAPIで緯度が先だと考える 別の国に表示されるか検証に失敗する 境界ごとに座標順を明記する
入力を黙って入れ替える 上流のデータ誤りが見えなくなる 明示的な入れ替え候補を提示する
表示前に逆ジオコーディングする 曖昧な住所が正確な座標を置き換える 先に表示し、後から補足する
逆ジオコーディングを正確とみなす 近隣住所を正確な地点だと誤解される 元の座標と返されたラベルを併記する
整形済み住所だけを保存する 精度と相互運用性が失われる 元の座標と安定したIDを保持する
無効な範囲を受け入れる 描画エンジンが丸めたり折り返したりする 提供元を呼ぶ前に検証する
MapLibreをジオコーダーとして扱う 住所検索の情報源がない 承認済みのサービスを別途接続する
GeoJSONで[lat, lng]を使う データが別の場所へ移動する GeoJSONでは[lng, lat]を使う
出力をすべてキャンバス内に隠す アクセシビリティと検索性が低下する 地図の横にテキスト結果を表示する
過度な精度を主張する UIが情報源の精度を誇張する 数値の桁数と測定精度を分ける

逆順の入力には明示的な入れ替え候補を示し、範囲外の値は拒否します。0,0は有効なままにしつつ、データ品質処理では注意対象にできます。逆ジオコーディングが空でも地点を消さず、海上や遠隔地の座標を無理に道路住所へ当てはめないでください。日付変更線付近でも元の値を保持し、座標が同じだけで同一の実体とみなさず、安定したレコードIDを使います。公開ページはクロール可能なテキストで機能を説明し、同じ目的の薄い言い換えページを量産するより、強いツールと信頼できるガイドを一つずつ用意する方が有効です。

結論

緯度・経度による地図検索は単純な空間処理ですが、数値の意味は周囲の契約によって決まるという重要な原則を示します。値を検証し、順序を明示し、最初に正確な地点を表示し、逆ジオコーディングは座標の代替ではなく補足情報として扱ってください。Google Mapsは通常latとlngの名前付きフィールドを使い、GeoJSON、Mapbox、MapLibreの配列は経度・緯度順です。

Kaleidrで価値が高い次の段階は、この決定的な検索自体をAIタスクにすることではありません。まず座標を信頼できる地理的な基準点にし、その後Spatial AIで周辺地域、近隣スポット、経路、空間関係についてより豊かな質問を可能にします。

座標の周辺を探索する

地点を特定したら、Kaleidr Spatial AIで周辺スポットや地理的関係について質問できます。Kaleidr Spatial AIを開く から確定した座標の周囲を探索し、ホスト側が地図を管理する場合は開発者ドキュメントで統合を進めてください。

よくある質問

緯度・経度で場所を検索するには？

緯度は-90〜90、経度は-180〜180の有効な値を入力し、地図APIが求める順序に変換して、地点を中央に表示しマーカーを追加します。読みやすい住所も必要な場合は、逆ジオコーディングを任意で行います。

緯度と経度はどちらが先？

インターフェースによります。人向けの表記では緯度を先に書くことが一般的です。Google Maps JavaScriptはlatとlngの名前付きフィールドを使い、GeoJSON、Mapbox GL JS、MapLibre GL JSの配列では経度が先です。

座標が別の場所を示すのはなぜ？

最も多い原因は座標順の逆転です。UTMの東距・北距などの投影座標を十進度の緯度・経度と誤認するなど、座標参照系が違う場合もあります。

逆ジオコーディングとは？

逆ジオコーディングは、地理座標を人が読める住所や地理的な説明に変換します。結果は提供元のデータと照合ロジックに基づく推定です。

GeoJSONは緯度・経度順か、経度・緯度順か？

GeoJSONの位置配列は、経度が先、緯度が後です。

EPSG:4326とGeoJSONは同じか？

同じではありません。EPSG:4326はWGS 84の2次元地理座標参照系です。GeoJSONはWGS 84座標を使うデータ形式ですが、位置配列を経度・緯度順で定義します。

UTM座標も同じ方法で検索できるか？

直接はできません。UTMにはゾーン、半球またはCRS識別子と、投影された東距・北距が必要です。検証済みのCRS変換を行ってから経度・緯度として扱います。

MapLibreに逆ジオコーディングは含まれるか？

MapLibre GL JSは主に描画エンジンです。逆ジオコーディングには、ホストアプリが選んだ別のサービスを接続します。

座標検索にAIを使うべきか？

基本的な座標検索には不要です。解析、検証、表示、逆ジオコーディングは決定的な処理です。地点確定後の文脈的・複合条件の探索でAIが役立ちます。

Kaleidrは座標中心の地図に対応できるか？

対応できます。まずホスト地図を確定した座標に移動し、その後Kaleidr Chatを対応するライブ地図に接続して、地図を踏まえた位置質問を扱えます。正確な座標と場所情報には、引き続きホスト地図と信頼できるサービスが責任を持ちます。

参考文献

@misc{ietf_geojson,
  title  = {RFC 7946: The GeoJSON Format},
  author = {{Internet Engineering Task Force}},
  note   = {Accessed 10 August 2026},
  url    = {https://datatracker.ietf.org/doc/html/rfc7946}
}

@misc{epsg_wgs84,
  title  = {WGS 84 -- EPSG:4326},
  author = {{EPSG}},
  note   = {Accessed 10 August 2026},
  url    = {https://epsg.org/crs_4326/WGS-84.html}
}

@misc{google_coordinates,
  title  = {Coordinates -- Maps JavaScript API},
  author = {{Google}},
  note   = {Accessed 10 August 2026},
  url    = {https://developers.google.com/maps/documentation/javascript/reference/coordinates}
}

@misc{google_reverse_geocode,
  title  = {Reverse geocode a location},
  author = {{Google}},
  note   = {Geocoding API; accessed 10 August 2026},
  url    = {https://developers.google.com/maps/documentation/geocoding/reverse-geocoding}
}

@misc{mapbox_geocoding,
  title  = {Understanding the Geocoding API},
  author = {{Mapbox}},
  note   = {Accessed 10 August 2026},
  url    = {https://docs.mapbox.com/help/dive-deeper/geocoding/}
}

@misc{maplibre_lnglat,
  title  = {LngLat -- MapLibre GL JS},
  author = {{MapLibre}},
  note   = {Accessed 10 August 2026},
  url    = {https://maplibre.org/maplibre-gl-js/docs/API/classes/LngLat/}
}

関連コンテンツ

地図を成長のエンジンに変える