ジオコーディング vs プレイス検索

ジオコーディング vs プレイス検索は、位置クエリで最初に分けるべき処理です。一方の呼び出しは地理的な対象を解決し、もう一方は候補地点を発見します。住所、座標、または場所IDはジオコーディングの対象です。店舗、ランドマーク、その他の名称付き地点を探す要求はプレイス検索の対象です。その後、空間クエリがアプリケーションですでに保持しているジオメトリを検証し、ベクトル検索が意味を照合します。ただし、ベクトル検索だけでは、そのレコードが近いことや適格であることは証明できません。

各位置クエリは何に答えるのか？

各手法は異なる問いに答えます。ベンダーのメニューで同じ製品ファミリーにまとめられていても、その違いはなくなりません。ジオコーディングはIDを解決します。プレイス検索はプロバイダーのインデックスまたは非公開インデックスから候補を見つけます。空間クエリは、アプリケーションがすでに保存しているレコードに幾何学的な関係を適用します。ベクトル検索は、意味的に近い埋め込みを持つレコードを取得します。本番の意思決定では、問いそのものが定める順序で、これらの回答を複数組み合わせることがよくあります。

4枚のカードは、解決、発見、地理的なフィルタ、意味の照合を分けています。各カードは入力と出力を対応させています。住所と座標、カテゴリと関心地点、幾何学的関係と一致するレコード、概念と意味的に近いレコードです。道路住所、座標、カフェのクエリ、ポリゴン内の地点数は図上のサンプルラベルです。これらはKaleidrインデックスへのライブクエリ結果ではありません。

この表が選択ルールです。問いではなくエンドポイント名から始めるチームは、ジオコーダに推薦を求めたり、ベクトルインデックスに包含判定を求めたりします。どちらも、システムが実行していない問いに対して自信のある回答を返す誤りです。このガイドの残りでは4つの役割を分けたままにし、その後、パイプラインのどこで結合すべきかを示します。

どのクエリがその問いに合うのか？

リクエストの冒頭の言葉で、たいてい手法が決まります。「この住所はどこ？」ならジオコーディングです。「このテキストやカテゴリに合う場所は？」ならプレイス検索です。「この地理的関係を満たす自社レコードはどれ？」なら空間クエリです。「このフレーズと意味が似ているレコードは？」ならベクトル検索ですが、厳格な地理的制約とビジネス制約を先に適用した後に限ります。こうした問いが混在するリクエストには、1つの勝者ではなくハイブリッドが必要です。

決定木は、呼び出し元が答えようとしている問いから始まり、1つの住所の解決、店舗の発見、呼び出し元自身のレコードの地理的フィルタ、意味が似たレコードの発見へ分岐します。下部の5番目の帯は、1つのクエリでは足りない場合に4つの手法を組み合わせます。サンプル住所、カフェカード、1kmの半径、引用されたデート向けのフレーズは図のラベルです。チェックマークは各手法の役割を示すもので、測定された品質スコアではありません。

ハイブリッドはAI地図アシスタントでは通常のケースであり、後のバージョンまで取っておく例外ではありません。「20 W 34th Stの近くのコーヒー」でも、近傍検索を実行する前に住所を解決する必要があります。「ホテルの近くで、9時以降も開いている静かなカフェ」なら、その解決にビジネスフィルタと意味的な好みが加わります。以下のパイプラインセクションでは、レビュー担当者が検証できる順序にこれらの処理を保ちます。

ジオコーディングは何を解決するのか？

ジオコーディングはテキストの位置表現を地理的表現に変換し、逆ジオコーディングは座標または場所IDを読みやすい住所に戻します。GoogleのGeocoding API概要は、住所、緯度と経度、またはPlace IDを受け取り、住所を座標とPlace IDへ変換する、または座標やPlace IDを住所へ変換するサービスと定義しています (Google, 2026)。同じ概要では、フォワードジオコーディングの例として「1600 Amphitheatre Parkway, Mountain View, CA」を使用し、リバースジオコーディングの用途に配送と受け取りを挙げています。成功した呼び出しの出力は、地図上に配置できる対象であり、店舗のランキング済み集合ではありません。

製品境界は変化していますが、名前を付けるべきなのは依然として取得の役割です。GoogleのGeocoding API v4概要は、フォワードジオコーディング、リバースジオコーディング、プレイスジオコーディングに加え、住所、Place ID、または座標を受け取る目的地検索メソッドを列挙しています (Google, 2026)。また、一般提供、プレビュー、実験的な各チャネルを分け、一般提供の経路にない目的地機能には実験的チャネルを使うよう案内しています。目的地の照合は、アプリケーションがすでに解決した場所を補強できます。しかし、それが地点発見インデックスになるわけではなく、実験的チャネルだからといって、すべてのフィールドが本番契約に対応済みとは限りません。

アプリケーションが住所を地図に置く、保存前に正規化する、地図を中央に移動する、デバイス位置を逆ジオコーディングする、または後続クエリの前に配送地点を解決する必要がある場合、ジオコーディングが適切です。ジオコーディングは、最適な近隣レストランを選びません。非公開在庫を読みません。非公開のサービスエリアポリゴンを検証しません。顧客意図で結果をランク付けしません。これらは対象が存在してから始まる処理です。地図に場所をプロットするでは、解決成功後の住所からマーカーへの工程を扱っています。

ジオコーディング vs プレイス検索はどう違うのか？

プレイス検索は、レストラン、店舗、駅、ランドマーク、その他の関心地点のような名称付き地理エンティティを発見します。Mapboxは現在のGeocoding APIで製品境界を明確にしています。このAPIはフォワードとリバースジオコーディングを行い、Geocoding v6 APIは関心地点データを提供しなくなりました (Mapbox, 2026)。Mapboxは関心地点検索をSearch Box APIへ案内しており、住所、場所、関心地点についてのインタラクティブ検索と単独検索、カテゴリ検索をサポートしています (Mapbox, 2026)。エンドポイントファミリーは1社のものです。しかし役割は2つのままです。

Googleの現在のPlaces APIも、プレイス検索の内部で同じ分離を行っています。Text Search (New)はテキスト文字列に対して場所を返し、ドキュメントの例には「shoe stores near Ottawa」や「123 Main Street」が含まれるため、住所のような文字列もプレイス検索呼び出しに入ることがあります (Google, 2026)。Nearby Search (New)は1つ以上のplace typeを受け取り、指定エリア内の一致する場所を返します (Google, 2026)。そのため、文字列が住所ならText Searchはジオコーディングのように見え、エリアが円ならNearby Searchは空間クエリのように見えることがあります。それでも結果は、そのプロバイダーのインデックスから得た候補集合です。営業中か、在庫があるか、認可されているか、移動時間はいくらか、といった点は後続の検証です。同じText Searchページでは、場所として表現されていない郵便住所形式など、曖昧なクエリを対象としていないことも説明しています。

左パネルは1つの住所がどこにあるかを問い、1つの位置IDを示します。そのパネルの住所と座標はKaleidrのforward-geocodeリファレンスのサンプルに対応しています。右側のカフェ名、距離、星評価はサンプルラベルであり、ライブのプレイス検索レスポンスではありません。フッターは「coffee near 20 W 34th St」を、住所のジオコーディング、その後のコーヒー検索という順に示します。右側の要点では結果を候補集合と呼んでおり、適格性とランキングに進む前の正しい停止地点です。

アンカーが住所で、対象がカテゴリの場合、堅牢なアプリケーションは両方を使います。「20 W 34th St」をジオコーディングし、解決した地点の近くでコーヒーを検索し、徒歩時間を計算して、適格性が残った場所だけをランク付けします。近隣地点マップは、その2段目の発見を担う画面です。プロバイダーの順序は取得上の便宜にすぎません。製品の順序は、その後の意思決定です。

空間クエリは何を検証するのか？

空間クエリは、アプリケーションがすでに保持しているレコードを、ジオメトリ間の関係でフィルタします。一般的な関係は、一定距離内、ポリゴン内、交差、包含、最寄り近傍です。レコードとそのジオメトリはクエリより前に存在します。クエリは、それらのどのレコードが関係を満たすかを判定します。プレイス検索APIは別の問いに答えます。候補集合が呼び出し元のテーブルではなく、プロバイダーのインデックスから来るためです。

パネルは、一定距離内、ポリゴン内、ゾーンと交差するルート、最寄り要素を示しています。1kmの半径、サービスエリアの輪郭、距離バッジはサンプルジオメトリであり、測定済みサービスエリアではありません。最寄りパネルでは1つの要素を除外対象としても示します。この除外は後続の適格性チェックの例です。距離述語だけでは、その場所が営業中かどうかは判定しません。

PostGISはST_DWithinを、2つのジオメトリが指定距離内にあるかを判定するテストとして定義しており、その呼び出しにはジオメトリで利用可能な空間インデックスを使うバウンディングボックス比較が含まれます (PostGIS, 2026)。geography型では距離はメートルです。そのため、geography列を持つ店舗テーブルでは、「5km以内」を言語モデルに解釈させる文章ではなく述語として保持できます。

SELECT store_id, name
FROM stores
WHERE ST_DWithin(stores.geog, user_location, 5000);

包含も同じ種類の述語です。ST_Withinは、第1ジオメトリのすべての点が第2ジオメトリ内にあり、内部同士が1点を共有するときtrueを返し、利用可能な空間インデックスも使用します (PostGIS, 2026)。ST_Within(A, B)はST_Contains(B, A)の逆です。「この住所はサービスエリア内か？」という配送の問いは、ジオコーディング、包含テスト、運用ルールの順になります。ベクトルインデックスはポリゴンの代わりにはならず、公開プレイス検索も会社が描いたサービスエリアのジオメトリの代わりにはなりません。

インデックスについての注意はアーキテクチャ制約であり、チューニングの脚注ではありません。インデックスを使えない距離式は、同じテーブル上のST_DWithinよりはるかに多くの行を比較します。位置対応アシスタントの実践的なルールは、モデルに集合を見せる前に地理的にフィルタすることです。大きなカタログのうちジオメトリを満たせるのがごく一部なら、言語モデルにはその部分と、残りが除外された理由を渡すべきです。残りまで送ると、述語がすでに除外したレコードにコンテキストを消費します。

ベクトル検索は何を照合するのか？

ベクトル検索は、ベクトル空間でクエリに近い埋め込みを持つレコードを取得します。この用途でよく使われるPostgres拡張pgvectorは、デフォルトで正確な近傍探索を行い、近似検索のためにHNSWまたはIVFFlatインデックスを追加できます (pgvector, 2026)。同じドキュメントはL2距離、内積、コサイン距離なども列挙しています。正確な検索が再現率の基準です。近似インデックスは再現率の一部と速度を交換し、インデックス導入後はクエリが異なる近傍を返すことがあります。この性質は、正確検索を使った試作とインデックスを使う本番クエリを比較するときに重要です。

ベクトル検索にコストをかける価値があるのは、リクエスト中の言葉とレコード中の言葉が一致しない場合です。「照明が暗めの親密なワインバー」という説明は、文字列として一致しなくても、「初対面の打ち合わせに向く静かな場所」にとって有用な近傍になり得ます。場所の説明、設備メモ、目的地向け文章が典型的な入力で、ライセンスがテキストの埋め込み化を許す場合に使います。既知のブランド、店舗番号、空港コード、明示的なカテゴリは、キーワード検索や構造化検索のほうが適しています。埋め込みは運用対象のシステムを1つ増やすため、意味的な取りこぼしが実在するときに追加すべきです。

ベクトル類似度は、地理的距離、ルート時間、サービスエリア包含、現在の在庫、営業時間、認可、または埋め込み化したテキストが今も正しいかどうかを記録しません。埋め込み空間で近い近傍が、呼び出し元から何百マイルも離れていることがあります。道の向かいの場所が意味的には低一致でも、運用上は正しい答えであることもあります。この2つの結果は矛盾していません。異なる空間の結果であり、パイプラインはどの空間が候補を除外できるかを明示する必要があります。

なぜ地理的距離とベクトル距離は違うのか？

どちらも「距離」という言葉を使うため、対象の違いが隠れます。地理的距離は地球上または経路上の隔たりです。直線距離、徒歩、車移動、包含結果などです。ベクトル距離は埋め込み空間での隔たりです。コサイン距離、ユークリッド距離、内積スコアなどです。ベクトル距離が小さくても2つの場所が地理的に近いとは限りません。徒歩が短くても2つの説明が同じ意味とは限りません。

左パネルは物理的な隔たりを測り、ラベル付き2地点間のサンプル徒歩移動を示します。kmと分のバッジはサンプルラベルであり、経路計算済みの移動ではありません。右パネルは埋め込み図に単語を配置し、コーヒーが電車から意味的に遠いと示しています。このコサインの表示は2つの空間の説明であり、Kaleidrインデックスから測定した埋め込みではありません。中央のラベルが図の要点です。同じ「距離」という語が2つの量を指しています。

名称の衝突は製品文言にも現れます。「最寄り」と表示された画面が、埋め込みインデックスで最も近いもの、直線距離メートルで最も近いもの、または寄り道時間が最少のものを意味する可能性があります。この3つの順序は十分頻繁に食い違うため、UIはどの量を指すかを明記すべきです。順位付けは複数を使えますが、コサイン scoreとkm値を足し、その合計を1つの距離として扱うべきではありません。

ハイブリッドパイプラインでは作業をどう並べるべきか？

本番の位置検索は通常パイプラインです。リクエストが、対象、カテゴリ、地理的制約、ビジネスルール、好みを混在させるためです。実用的な順序は、リクエストを解釈し、アンカーを解決し、候補を取得し、空間フィルタを適用し、ビジネス適格性を適用し、その後に限って適格集合の内部で意味類似度を使うことです。経路計算などの補強は残った候補に対して実行します。ランキングはその候補を並べます。説明と地図アクションは、フィルタが使用したものと同じ識別子を使います。空間コンテキストエンジニアリングは、このパイプラインの何を言語モデルへ渡してよいかという対になる問いです。

各段階には、その段階を担当する手法がラベル付けされています。ジオコーディング、プレイス検索、空間クエリ、ビジネスデータ、ベクトル検索、その後に補強、ランキング、地図アクションです。場所名、星評価、スコアバー、「100K+」のファネル、「top 3–5」という主張は説明用ラベルです。この図は処理順序の参考スケッチであり、Kaleidrのbenchmarkでもrequest形式でもありません。ビジネスフィルタ列には「営業中」や最低評価のようなサンプルルールがありますが、これらは公開プレイスインデックスではなくhostのデータに属します。

順序は再現率を変えます。埋め込みインデックス全体を先に検索し、その後短い意味リストに対して地理条件を検証すると、その短いリストに入らなかった有効なローカル地点を見落とす可能性があります。先に厳格な地理条件と厳格なビジネスルールで候補集合を制限し、その集合内で意味をランキングすれば、境界を保てます。データベースが両方のフィルタを1つのクエリで適用できる場合でも、原則は同じです。意味類似度が必須の地理制約を消してはいけません。

pgvector自身のfilteringの説明が実務上の警告です。近似インデックスではフィルタはindex scan後に適用され、ドキュメントの例では、HNSWのデフォルトef_searchが40のとき10%の行に一致する条件では平均して約4行しか残りません。この不足に対してドキュメントが導入しているiterative index scansは、十分な行が残るまで継続します。チームは、見た目のよいクエリがそのまま本番クエリだと仮定せず、現実的なデータでfiltered 再現率を検証すべきです。

なぜ厳格なフィルタを類似度より先に実行するのか？

取得は、どの候補を検討対象に入れてよいかを問います。ランキングは、有効な候補をどの順で表示するかを問います。両者を混ぜると、閉店中、未認可、在庫切れの場所が、便利または意味的に近いという理由で勝つことがあります。Kaleidrのプレイスランキングガイドでは、認可、可用性、必須能力、サービスエリアを、弱いペナルティではなくスコアリング前のフィルタとして扱います (Kaleidr, 2026)。大きな利便性項目にペナルティが負けることはあります。フィルタは負けません。

左列には4つのboolean gateが並び、最後に無効な候補を削除します。右列には、静か、家族向け、仕事向けのサンプル類似度スコアがあり、通過した場所だけをランキングします。写真と3つのスコアはサンプルラベルであり、測定済みの評価でもKaleidrスコアでもありません。矢印が順序を示します。適格性、その後に類似度です。

厳格なgateはbooleanのままです。認可済み、在庫あり、到着時に営業中、サービスエリア内は条件であって重みではありません。意味信号はスコアのままでよく、gateを通過した場所に適用します。同じ分離は、必須のアクセシビリティルールやtenant境界にも当てはまります。必須情報が不明なら、不明のままにするべきです。利用できない照合をfalseとして扱うと、在庫取得に失敗しただけなのに、自信を持って「在庫なし」としてしまいます。これは別の、より悪いエラーです。

なぜ「途中にある場所」の検索は半径検索ではないのか？

「近く」と「家に帰る途中」は異なるジオメトリを表します。出発点周囲の半径は、開始地点から一定距離内の場所を返しますが、進行方向と逆の場所も含みます。route-corridorクエリは、経路計算サービスがすでに計画した移動に対し、寄り道が少ない場所を返します。問いが本当に放射状なら直線距離は正当なフィルタです。しかし意思決定が移動経路に依存する場合、直線距離は誤った量です。直線で2kmでも車では長いことがあり、直線距離が長いほうが実際の移動は短いこともあります。

左パネルは単純な半径で、1マイルの円の内外にサンプル薬局を表示します。右パネルは職場から自宅へのサンプルルートに沿って、薬局に寄り道分数を付けています。マイル値、寄り道時間、場所名はサンプルラベルであり、ライブの経路ではありません。図の要点は関係です。ルートからの低い偏差は、出発点周囲の円と同じ述語ではありません。

経路計算サービスが寄り道を計算し、順位付けがその結果を受け取るべきです。言語モデルが分数を推測すると、サービスが今返したルートと矛盾する場合があります。経路呼び出しは解決と候補選択の後です。経路呼び出しはプレイス検索ではなく、経路がない場合は地図上に推測線を描くのではなく、見える失敗として残すべきです。

Kaleidrはこのパイプラインのどこに入るのか？

Kaleidrの公開Platform APIは、非公開ビジネスインデックスではなく、検索ボックスまたはFrom/Toフィールド向けのforward-geocode エンドポイントを公開しています。GET /retrieval/geocode/forwardは、場所名、番地を含む住所、または入力された緯度と経度としてqを受け取り、オプションでセット使用するnear_latとnear_lng、limit、移動modeを受け取ります (Kaleidr, 2026)。同じリファレンスには、呼び出し元がすでに持つ座標間の経路もあり、driving、walking、cycling、transitプロファイルを使用できます。経路を計画できない場合、経路ではなくbody内のエラーを伴う成功HTTPステータスとして返ります。結果には呼び出し元が引き継ぐ必要のあるattributionが含まれ、道路住所の結果にはデータ更新をまたいで安定する識別子が含まれることがあります。空のresultsリストは、内部照合失敗の場合も含め、表示できるものがないことを意味するため、住所が無効である証明にはなりません。

ドキュメントされたパラメータには、顧客の非公開カタログは含まれていません。公開ジオコーディングは、同じ地図に載っているだけでは在庫システムになりません。非公開店舗や在庫が必要な呼び出し元は、それらのシステムを直接読み、安定した識別子で解決済みの場所に結合する必要があります。geocodeレスポンスは公開対象であり、ビジネスレコードはビジネスレコードのままです。

Place detailには現在の後継があり、新しい統合を古い経路で構築すべきではありません。エンドポイントリファレンスはGET /retrieval/poi/enrichをdeprecatedとしてマークし、新規実装をPOST /spotへ案内しています。これは、その地点に何があるかを答え、説明文や写真を追加できます。deprecatedルートは2027-01-15以降に削除される可能性があります。

補強は依然として非公開の適格性を決めません。公開ソースから得た営業時間、写真、カテゴリは、そのソースが要求するattribution付きの公開情報です。在庫、アカウント権限、顧客が描いたサービスエリアは、それらを所有するシステムに残ります。ビジネスデータに基づくSpatial AIは、この境界についてのガイドです。

左列は、住所と名称付き地点を、非公開店舗、在庫、サービスエリアから分けます。中央列は、Kaleidr フォワードジオコーディング、place-detail工程、host自身の空間データベースとビジネスシステムを示します。place-detailボックスは現在POST /spotとしてドキュメントされている役割です。古いenrich エンドポイントはdeprecatedの前身であり、新規統合の開始点ではありません。右列は取得後の処理です。既知座標間の経路、適格場所のランキング、説明、地図アクションです。図の警告はエンドポイントリファレンスと一致します。公開geocodeまたはplace APIが、呼び出し元の非公開位置、在庫、サービスエリアをインデックス化することはありません。

組織固有のデータは地図ではなくプラン境界に従います。Kaleidrのアカウントドキュメントでは、組織独自のビジネスデータをAI回答用にアップロードする機能はEnterprise限定であり、そのアップロード済みデータを回答で使えるkey scopeもEnterprise限定としています (Kaleidr, 2026)。現在の公開エンドポイントリファレンスには、汎用ベクトル検索エンドポイントは記載されていません。自社説明文に対して意味取得が必要なチームは、そのインデックスをhostまたはEnterprise設計の一部として扱い、この記事で引用していないパスを呼ぶのではなく、現在の契約を確認すべきです。map-aware AIアシスタントの構築方法では、検証済み場所IDの後に続く地図アクションを扱っています。

チームは何を別々に測定すべきか？

各層は異なる形で失敗するため、1つの関連度スコアではどの層が失敗したか分かりません。ジオコーディングは、曖昧な住所、部屋番号などの欠落、座標の反転、道路レベルにとどまる一致で失敗します。プレイス検索は、プロバイダーのカバレッジ、カテゴリ、鮮度が製品と合わないと失敗します。空間クエリは、無効なジオメトリ、座標参照の不一致、運用とずれたポリゴンで失敗します。

ベクトル検索は、弱い埋め込み、古いテキスト、フィルタ後に十分な結果を返さない近似インデックスで失敗します。ビジネスデータは、在庫不明、未認可レコード、古い営業時間で失敗します。有用なログは層を名指しします。「Search failed」だけでは不十分です。

まず各層をその役割で評価し、その後に意思決定を評価します。ジオコーディングには一致品質と安定した識別子が必要です。プレイス検索には候補再現率、カテゴリprecision、古い場所の割合が必要です。空間クエリには幾何学的正確性と、クエリがインデックスを使った証拠が必要です。ベクトル検索には意味的関連性と、exact-search基準に対するfiltered 再現率が必要です。end-to-endでは、適格な場所が取得できたか、no-resultが正直な結果だったか、アクションがフィルタで承認された識別子を使ったかを確認します。認可ミスや包含ミスを平均click-through rateの中に埋もれさせてはいけません。

スタックはどこから始めるべきか？

ユーザーが求めた条件を証明できる手法を選びます。ジオコーディングは対象がどこにあるかを証明します。プレイス検索は、そのインデックス内で、どの既知地点がテキスト、カテゴリ、エリアに一致するかを証明します。空間クエリは、アプリケーションが保持するレコード上の幾何学的関係を証明します。ベクトル検索は意味の類似性を証明しますが、厳格なフィルタが残した集合内だけです。ビジネスシステムは現在の事実を証明します。経路計算サービスは移動経路を証明します。順位付けは残ったものを並べます。言語モデルはその結果を説明するもので、距離、包含テスト、在庫数の情報源であってはいけません。

公開プレイスデータは、公開発見が目的なら正しい情報源です。非公開店舗、在庫、適格性はそれぞれを所有するシステムに残し、安定した識別子でプロバイダーのplace、在庫ロケーション、地図マーカーを結びます。意味類似度は地理的境界を消せず、半径は「途中にあるか」という問いには答えません。組織固有データで取得を行う必要がある場合はKaleidr Enterpriseを確認し、上で引用したforward-geocode、spot、経路の契約はPlatform API エンドポイントを参照してください。

注: Kaleidrは、クリエイティブおよび開発ワークフロー全体で、画像作成、コンテンツ改善、調査にAI支援ツールを使用しています。

よくある質問

ジオコーディングとプレイス検索の違いは何ですか？

ジオコーディングは、住所、座標、または既知の場所参照を地理的IDに解決します。プレイス検索は、テキスト、カテゴリ、または近隣エリアに一致する店舗、ランドマーク、駅、その他の名称付き地点を発見します。一方は対象を返し、もう一方は候補を返します。

関心地点検索はジオコーディングと同じですか？

いいえ。一部のベンダーAPIは住所とplaceクエリの両方を受け取れます。対照的に、MapboxのGeocoding v6 APIは関心地点データをまったく提供しなくなりました。関心地点検索は候補を発見します。ジオコーディングは場所を解決します。

空間クエリとは何ですか？

空間クエリは、一定距離内、ポリゴン内、交差、最寄り近傍などの幾何学的関係で地理レコードをフィルタします。レコードとそのジオメトリはすでにアプリケーションのものです。述語は決定的です。

ベクトル検索とは何ですか？

ベクトル検索は、query 埋め込みに近い埋め込みを持つレコードを取得します。意味や、元テキストと表現が一致しないフレーズに有効です。ただし、距離、包含、適格性は証明しません。

ベクトル検索は空間クエリを置き換えられますか？

いいえ。埋め込み空間での類似度は、地理的距離、包含、ルート適合、サービスエリア所属を証明しません。地理的な真実には空間述語を使い、その述語が許可した集合内の意味的関連性にベクトル検索を使います。

ベクトル検索の前に地理条件で集合をフィルタすべきですか？

はい。地理条件が厳格な制約なら、その順序が必要です。グローバルな埋め込みインデックスを先に検索し、短いリストで後から場所を確認すると、そのリストに入らなかった有効なローカル地点を落とす可能性があります。実装はデータベースとインデックスが決めます。境界そのものは変わりません。

近隣検索の前にジオコーディングすべきですか？

はい。アンカーが住所や未解決の場所であれば、まずアンカーを解決し、その地点周辺でplace 取得または空間クエリを実行します。アンカーなしのカテゴリ検索は、すでにプレイス検索の問いです。

製品はPlaces APIと自社データベースのどちらを使うべきですか？

公開発見には、カバレッジ、ライセンス、attributionが製品に合う場合にPlaces APIを使います。自社店舗、在庫、非公開施設、適格性、現在のビジネス状態には自社データベースを使います。公開placeレコードで店舗を識別することはできますが、その店舗に今日何があるかの権威にしてはいけません。

ハイブリッド位置検索とは何ですか？

ハイブリッド位置検索は、1つの意思決定のために、これらの手法を2つ以上組み合わせます。典型的な流れでは、アンカーを解決し、候補地点を取得し、空間述語とビジネスルールを適用し、その後、適格集合内で意味的な好みをランキングします。言語モデルが残った候補を説明します。

Kaleidrは公開ベクトル検索エンドポイントをドキュメントしていますか？

ここで引用しているPlatform API エンドポイントリファレンスには、汎用ベクトル検索エンドポイントは記載されていません。この記事で利用するドキュメント済み取得 surfaceは、フォワードジオコーディング、地点に何があるかを返すPOST /spot、およびすでに分かっている座標間の経路呼び出しです。製品計画に意味インデックスを組み込む前に、現在のEnterprise契約を確認してください。

References

1. Google Maps Platform. Geocoding API overview. The service accepts an address, coordinates, or a Place ID, and converts an address into coordinates and a Place ID, or coordinates or a Place ID into an address. Accessed October 27, 2026. https://developers.google.com/maps/documentation/geocoding/overview
2. Google Maps Platform. Geocoding API v4 overview. Documents forward geocoding, reverse geocoding, place geocoding, and destination search, and separates generally available, preview, and experimental channels. Accessed October 27, 2026. https://developers.google.com/maps/documentation/geocoding/geocoding-v4-overview
3. Mapbox. Geocoding API. Forward and reverse geocoding. The Geocoding v6 API no longer provides point-of-interest data and directs that job to the Search Box API. Accessed October 27, 2026. https://docs.mapbox.com/api/search/geocoding/
4. Mapbox. Search Box API. Interactive and stand-alone search for addresses, places, and points of interest, including category search. Accessed October 27, 2026. https://docs.mapbox.com/api/search/search-box/
5. Google Maps Platform. Text Search (New). Returns places for a text string. Documented examples include "shoe stores near Ottawa" and "123 Main Street." Accessed October 27, 2026. https://developers.google.com/maps/documentation/places/web-service/text-search
6. Google Maps Platform. Nearby Search (New). Takes one or more place types and returns matching places within a specified area. Accessed October 27, 2026. https://developers.google.com/maps/documentation/places/web-service/nearby-search
7. PostGIS. ST_DWithin. Tests whether two geometries are within a given distance. The call includes a bounding-box comparison that uses available spatial indexes. Geography distance is in meters. Accessed October 27, 2026. https://postgis.net/docs/ST_DWithin.html
8. PostGIS. ST_Within. Tests whether every point of one geometry lies in another and the interiors share a point. The function uses available spatial indexes. Accessed October 27, 2026. https://postgis.net/docs/ST_Within.html
9. pgvector. pgvector. Exact and approximate nearest-neighbor search in Postgres, including HNSW and IVFFlat indexes, cosine and other distances, and iterative scans when a filter leaves too few approximate results. Accessed October 27, 2026. https://github.com/pgvector/pgvector
10. Kaleidr Developer Docs. Platform API endpoints. Documents forward geocoding for a search box or From/To field, POST /spot as the successor to the deprecated POI enrich endpoint, and a route call between known coordinates. Accessed October 27, 2026. https://docs.kaleidr.com/platform-api/endpoints
11. Kaleidr. Place Ranking API for Customer Intent. Hard filters such as authorization, availability, required capability, and service area run before scoring. Accessed October 27, 2026. https://kaleidr.com/blog/place-ranking-api
12. Kaleidr Developer Docs. How Kaleidr works. Uploading an organization's own business data for AI answers is Enterprise only, as is the key scope that lets answers draw on that data. Accessed October 27, 2026. https://docs.kaleidr.com/concepts/how-kaleidr-works
13. Kaleidr. Plot Places on a Map. A related guide for turning resolved places into markers. Accessed October 27, 2026. https://kaleidr.com/blog/plot-places-on-a-map
14. Kaleidr. How to Build a Nearby Places Map for Near Me Search. A related guide for nearby discovery. Accessed October 27, 2026. https://kaleidr.com/blog/how-to-build-a-nearby-places-map-for-near-me-search
15. Kaleidr. Spatial Context Engineering for Map-Aware AI. A related guide for what reaches the model after retrieval. Accessed October 27, 2026. https://kaleidr.com/blog/spatial-context-engineering
16. Kaleidr. Grounded Spatial AI for Business Data. A related guide for keeping business facts in the systems that own them. Accessed October 27, 2026. https://kaleidr.com/blog/grounded-spatial-ai-business-data
17. Kaleidr. Map-Aware AI Assistant: How to Build One. A related guide for map actions around a validated place. Accessed October 27, 2026. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant

References in BibTeX

@misc{google_geocoding_overview_2026,
  title  = {Geocoding API overview},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/geocoding/overview}
}

@misc{google_geocoding_v4_overview_2026,
  title  = {Geocoding API v4 overview},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/geocoding/geocoding-v4-overview}
}

@misc{mapbox_geocoding_api_2026,
  title  = {Geocoding API},
  author = {{Mapbox}},
  year   = {2026},
  url    = {https://docs.mapbox.com/api/search/geocoding/}
}

@misc{mapbox_search_box_api_2026,
  title  = {Search Box API},
  author = {{Mapbox}},
  year   = {2026},
  url    = {https://docs.mapbox.com/api/search/search-box/}
}

@misc{google_places_text_search_2026,
  title  = {Text Search (New)},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/text-search}
}

@misc{google_places_nearby_search_2026,
  title  = {Nearby Search (New)},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/nearby-search}
}

@misc{postgis_st_dwithin_2026,
  title  = {ST_DWithin},
  author = {{PostGIS}},
  year   = {2026},
  url    = {https://postgis.net/docs/ST_DWithin.html}
}

@misc{postgis_st_within_2026,
  title  = {ST_Within},
  author = {{PostGIS}},
  year   = {2026},
  url    = {https://postgis.net/docs/ST_Within.html}
}

@misc{pgvector_2026,
  title  = {pgvector},
  author = {{pgvector}},
  year   = {2026},
  url    = {https://github.com/pgvector/pgvector}
}

@misc{kaleidr_platform_api_endpoints_2026,
  title  = {Platform API endpoints},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

@misc{kaleidr_place_ranking_api_2026,
  title  = {Place Ranking API for Customer Intent},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/place-ranking-api}
}

@misc{kaleidr_how_kaleidr_works_2026,
  title  = {How Kaleidr works},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/concepts/how-kaleidr-works}
}