すべての記事 エンタープライズ

顧客意図に対応するプレイスランキングAPI

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

候補地点は認可と厳格な適格性審査を通過し、その後に空間、意図、鮮度、ビジネスのシグナルから説明可能な地図ランキングが生成されます。

プレイスランキングAPIは、特定の顧客判断に対して、空間コンテキスト、顧客意図、ビジネスルール、データの鮮度を使い、適格なロケーションを並べます。認可、空き状況、必須サービス、サービス提供区域といった厳格な制約はスコアではなくフィルターです。言語モデルは依頼を構造化された要件に変換でき、地理空間・業務システムがランキングに使う事実を供給します。

以下では、検索とランキング、プロバイダーの順位付けモード、厳格なフィルター、地理的特徴量、意図の境界、特徴量設計、認証、現在のKaleidr公開インターフェース、評価を扱います。関連記事は、ロケーションインテリジェンスによる顧客体験マップロケーションインテリジェンスAPIとは位置認識型予約地図チャット付きAI店舗検索地図認識AIアシスタントの作り方です。

プレイスランキングの要点

  • スコアより先に適格性: 認可、可用性、必須機能、サービス区域は無効な場所を除外します。
  • 空間特徴量をタスクに合わせる: 直線距離、移動時間、経路からの迂回、包含関係、複数拠点への適合は別々の問いに答えます。
  • 意図は構造化入力: 言語モデルは好みを解釈し、地点・在庫・ルーティングシステムが事実の正本であり続けます。
  • 不透明なスコアより理由: 顧客と運用者には、移動時間、営業状況、必須サービスなど確認可能なシグナルが必要です。
  • クリックだけでなく判断を測定: 候補再現率、制約違反、古いデータ、後続成果も品質契約に含めます。

候補地点は認可と厳格な適格性審査を通過し、その後に空間、意図、鮮度、ビジネスのシグナルから説明可能な地図ランキングが生成されます。

プレイスランキングAPIとは?

このAPIは、この顧客、このタスク、この時点の状態に対して、どの有効な場所を先に表示すべきかを答えます。検索・取得APIは通常、都市周辺のレストラン、表示範囲内の店舗、経路沿いのホテルといった候補を見つけます。ランキングは認可と厳格な適格性審査の後に残った場所を並べます。本番のロケーションインテリジェンスでは「取得、除外、順位付け」の3段階が必要です。無効なレコードの高得点は製品の欠陥であり、成功ではありません。

有用な出力は地図と同期した順序付きリストであり、単一の不透明な数値ではありません。各結果には地点ID、順位、実際のシグナルに基づく少数の理由を含めます。発見は適格なレコードを取得し、比較は移動関係・サービス適合・鮮度を可視化し、行動はハイライト、経路、予約・受取への引き継ぎ、保存を提供します。

ランキングは最寄り検索とどう違うのか?

顧客が最も近い適格な場所を求め、他の条件がすべて満たされているなら、距離順は妥当です。しかし最寄り店舗が受取非対応、閉店中、在庫切れ、大幅な迂回、区域外なら失敗します。強い流れは、有効な場所、必須サービス、現在の可用性、移動関係、好みを確認してから並べることです。距離は一つのシグナルにすぎません。

店舗検索、予約候補、通勤条件付き物件検索、イベント会場設備ガイドはいずれも画面上は「近く」に見えても、必要な空間特徴量が異なります。必須ルールは適格性に置き、生き残った候補だけをランク付けします。

現在の検索プロバイダーはどのように場所を並べるのか?

地図検索APIはすでに複数のモードを備えています。Google Places Nearby Search (New) は rankPreferencePOPULARITY または DISTANCE を定義しています(Nearby Search (New))。Text Search (New) は該当するカテゴリ検索で RELEVANCE または DISTANCE を提供し、都市名のような非カテゴリ検索では rankPreference を未設定にするよう推奨します(Text Search (New))。これらはプロバイダー候補を並べるだけで、ホストの非公開在庫、チケット規則、予約枠を知りません。

Mapbox Search Box の rank_strategydistance または relevance を受け取り、近接バイアス、経路対応検索、任意の到着時刻計算も提供します(Search Box API)。入力経路がある場合、候補にはメートル単位の added_distance と分単位の added_time が含まれ、単なる近さではなく迂回を表します。Google Placesも searchAlongRouteParameters でText Searchを経路ポリラインに寄せられます(Search along route)。プロバイダー順位は候補取得に有用で、製品順位はホスト固有の事実を加えるところから始まります。

APIはどの判断を最適化すべきか?

最初にAIモデルを要求するのではなく、リストが改善すべき判断を定義します。小売なら訪れるべき適格店舗、予約なら旅程に合う空き、物件なら位置条件に合う掲載、ホテルなら依頼に便利な承認済み提携先、イベントなら次のセッション前に有用な出展者や設備、マーケットプレイスなら地理的適合が高く履行可能な提供者です。

判断が候補、厳格な制約、空間・業務特徴量、ラベル、評価指標を決めます。通勤重視の物件は複数拠点への時間、受取は利便性より先に在庫と営業状態、経路沿い設備は直線距離でなく迂回が必要です。テストできる一文でタスクを書きます。曖昧な「関連性」は、同じカタログでも顧客ごとに逆順が正しいことを隠します。

どのようなパイプラインを使うべきか?

堅牢な流れは、依頼解釈、候補取得、認可、厳格な適格性、特徴量計算、ランキング、理由生成、地図とリストの表示、成果測定です。無効な場所は採点前に除外し、便利でも未認可・閉店・区域外のレコードが上位に来ないようにします。その後、移動時間、迂回、好み、鮮度、業務方針を生存候補だけに付けます。理由は同じシグナルから導き、独立した文章として生成しません。

大規模カタログではコストを分けます。取得は候補数を制限し、安価な事前順位は概算距離、カテゴリ、粗い在庫を使い、時間行列、迂回、詳細な補完は短い候補だけに実行します。件数はアプリ固有です。段階別に遅延を測ると、「AI」よりルーティングや在庫照会が支配的なこともわかります。

厳格な適格性フィルターが無効な場所を除外してから、柔軟なランキングシグナルが残りの候補を比較します。

なぜ厳格なフィルターをランキングより先に実行するのか?

厳格なフィルターは二値です。代表的なゲートは、有効な掲載、依頼サービス、現在の在庫、予約可能な部屋、サービス区域内、チケット権限、指定時間の営業、閲覧権限です。ランキングシグナルは生き残った候補間の移動時間、迂回、距離、価格適合、カテゴリ適合、好み、鮮度、業務優先度、過去の転換を比較します。「利用不可は20点減点」では無効な場所が勝つ余地が残ります。

必須のアクセシビリティ、権限、法的区域、在庫、能力も同じです。欠損はゼロではありません。評価値がない場合、中立値、特徴量固有の代替、低信頼フラグ、または必須項目の場合だけ除外する方が安全です。欠損規則をランキング方針のバージョンに明記します。

どの地理シグナルを使うべきか?

場所に普遍的な順位はありません。道路網が重要でない場合は直線距離が安価です。予約、店舗、ホテル、通勤には移動時間が便利さをより正しく表します。旅行、配送、訪問サービスには経路からの迂回が適し、Mapboxの added_timeadded_distance がその形を示します(Search Box API)。包含関係は配送区域、学区、会場区域内かを判断します。複数拠点適合は、ホテルを空港、会議場、オフィスのすべてに対して評価するような問いです。

複数拠点の時間平均、最悪区間の最小化、すべてを閾値内にした後の価格順では、同じ特徴量でも勝者が変わります。数式の美しさではなく判断に合わせ、地図とリストで同じ方針バージョンを使います。

直線距離、移動時間、経路迂回、複数の地理拠点のどれを最適化するかで、同じ適格候補の順位が変わります。

顧客意図をランキングへどう入れるべきか?

自然言語は必須条件と好みを混ぜます。「会議場の近くで静かで、空港へ向かう途中にも便利なカフェ」は、種別、暗黙の営業時間、会話向けの好み、近接拠点、経路条件を含みます。構造化解釈では必須項目と好みを分離します。言語モデルが解釈し、地点システムが候補を解決し、ルーティングサービスが関係を計算し、ランカーが検証済みシグナルを組み合わせます。

意図モデルを事実レイヤーにしないでください。カフェが営業中、商品が在庫あり、部屋に空きあり、迂回11分という生成文は、承認済みシステムが値を供給しない限り特徴量ではありません。OWASP Top 10 for LLM Applications 2025 は、モデルが提案しただけで連携機能を実行する危険を LLM06:2025 Excessive Agency と呼びます。地図認識アシスタントと同様、モデルは構造化要件を提案し、決定論的コードが認可済み特徴量を組み合わせ、ホストが地図操作を検証します。

パーソナライズには、徒歩、駐車場、静かさ、保存カテゴリ、好みの地域など明示された設定を使えます。顧客が編集、リセット、無視できるようにします。正当な根拠なく機微な属性を推測せず、派生特徴量で足りるなら生の機微入力を記録しません。NIST Privacy Framework はプライバシーを企業リスク管理として扱います。AI地図ワークフローの非公開位置データも同じホスト境界を扱います。

特徴量をどう組み合わせ、説明するか?

特徴量はタスクに有意で、利用可能で、十分新しく、正しく正規化され、許可され、テスト可能であるべきです。メートル、星評価、通貨、好みの値は直接足せません。各シグナルを比較可能な適合値に変換し、正規化を製品方針として扱います。移動、意図、鮮度、業務適合の透明な加重和は、調査・デバッグ・説明・変更がしやすいため、学習モデルより良い初版になることがあります。重みは方針であって証拠ではありません。

内部スコア 87.4 を意味として公開せず、「徒歩12分」「指定時間に営業」「必要サービスあり」「選択した好みに一致」と説明します。提携先、会員、容量、広告在庫、契約順位、運用分散による調整は地理的関連性と分離します。商業的掲載が影響するなら、適用される開示規則に従います。

営業時間、在庫、会場室、入口状態、提供者の可用性は劣化するため、鮮度は第一級の特徴量です。古い重要事実は再検証または除外します。人気度はフィードバックループです。似た5店舗や狭い地点群が選択肢にならない場合は、多様性と地理的範囲を次段階で追加できます。

プロバイダー順位と製品順位の違いは?

取得されなかった場所をランカーは戻せません。候補再現率と順位品質を別に評価します。Googleの rankPreference、Mapboxの rank_strategy、近接・経路フィールドは各社のインデックス上の順序です(Nearby Search (New)Text Search (New)Search Box API)。ホストは候補を在庫・適格性・経路で補完し、製品タスク向けに再順位付けできます。

抽象的な place ではなく、ユーザー、タスク、現在状態を条件に place を並べます。事前順位、順位、再順位は、判断を変える場所にだけ高価な特徴量を使うための設計です。

ランキング要求はどう認証・設計すべきか?

設計上の要求にはタスク、起点、候補ID、厳格な要件、好み、上限を含め、応答は順序付き placeId と確認可能な理由を返せます。これは設計例であり、Kaleidrの文書化済みルートではありません。ブラウザーから非公開レコード全体を送るより、IDを使い認可済みバックエンドで補完します。利用者をホストが認証し、許可候補を取得し、その集合だけをランキングします。

Kaleidrはブラウザーでpublishable key、信頼済みバックエンドでserver keyを使います(Auth & Scopes)。前者は短時間・オリジン限定セッションに交換され、後者はバックエンドに留まります。非公開在庫、チケット状態、ランキング資格情報をページソースに置きません。対応プロバイダーでは候補ごとの経路呼び出しではなく時間行列をまとめて要求します。

Kaleidrは現在ランキングをどう位置付けているか?

Kaleidr Enterpriseは、現代の空間製品向けに推論API、ランキングシステム、分析を備えたロケーションインテリジェンス基盤としてプラットフォームを説明しています(Location Intelligence APIs and Map SDK)。これはKaleidr自身の位置付けには正式な情報ですが、現行エンドポイント一覧の代替ではありません。

公開Platform APIリファレンスは https://api.kaleidr.com/inference-api/b2b/v1/ 配下でチャット、経路、POI補完、デザインを文書化しています。POST /chat/control/streamPOST /chat/control/routeGET /retrieval/poi/enrichdesign スコープのデザインエンドポイントが含まれます(Endpoints)。専用の公開 /rank ルートは記載されていません。カスタムランキングはEnterprise統合要件として扱い、現在の契約が提供しない限り POST /rank を実装しないでください。

公開インターフェースは会話意図、経路計算、POI補完を入力として提供できますが、単独のランカーではありません。想定経路を実装する前に対応統合を確認します(Location Intelligence APIs and Map SDK)。

ランキング方針を再現率、制約、品質、地理的偏りについてオフライン評価し、顧客成果と診断障害をオンライン測定して次版へ進めます。

ランキング品質をどう評価するか?

オフライン評価には、クエリ、起点、厳格な規則、好みのシグナルを固定したタスク集合が必要です。候補再現率、適格性精度、Top-K品質、制約充足率、説明の正確性、地理的偏りを測ります。「このタスクでAはBより上か」というペアラベルは絶対点より集めやすく、後の学習型ランカーにも使えます。営業中、受取可、区域内が必須なら、一つでも違反する上位結果はクリック率に関係なく失敗です。

オンラインでは、選択、経路表示、予約・受取開始、保存、問い合わせ、再検索を測れます。クリックは表示位置の偏りを受け、最初の結果が最良だった証拠ではありません。結果なし、厳格ルール違反、古いデータ、段階別遅延、必須特徴量欠損を診断として残し、ロールバック可能なバージョン方針へ反映します。空間分析KPIガイドも操作数よりタスク完了を優先します。

20分前に閉店した店舗、無効な入口、停止済み掲載、売切れ在庫が昨日の人気だけで上位に残らないよう、鮮度テストも含めます。

製品チームが想定すべき失敗は?

誤り 結果 より良い方法
適格性より先にランキング 無効な場所が上位になる 厳格な制約を先に除外
最寄りを最良とみなす タスク文脈を無視 判断に合う空間特徴量を使う
必須規則を重みにする 無効な候補が勝つ 厳格フィルターに保つ
モデルに事実を作らせる 根拠のない順位になる 時間、在庫、経路を正本から読む
欠損をゼロにする 疎なレコードを罰する 欠損方針を定義
プロバイダー順だけに依存 製品文脈が失われる ホスト事実で再順位付け
クリックだけを最適化 表示位置偏りを品質と誤認 成果と違反を測る
理由をすべて隠す 信頼とデバッグ性が低下 確認可能なシグナルを示す
バージョンを無視 実験を追跡できない 方針を版管理しロールバック
Kaleidr /rank を想定 存在しない統合になる 現在のEnterprise契約を確認

モバイルでは大きい操作対象、読みやすい理由、モデルや高価な特徴量がタイムアウトしても使える地図が必要です。店舗名の直接検索も残します。基本形状とラベルをキャッシュし、補完を制御して縮退します。曖昧な名称、逆向きの起点、閉店、古い在庫を、地図・一覧・理由が同時更新するまでテストします。

製品にプレイスランキングAPIを組み込む

本番の基本は、取得、認可、厳格な制約の除外、空間特徴量の計算、順位付け、説明、測定です。距離、人気、意味的関連性は有用でも、どれも常に正しくはありません。顧客の判断を反映し、地図上で確認できる理由を示す方針にします。

ロケーションインテリジェンスAPI、ランキングシステム、導入支援については、**Kaleidr Enterpriseを見る**をご覧ください。統合経路を固定する前に、Kaleidr開発者ドキュメントで現在の推論、取得、認証、SDKインターフェースを確認してください。

よくある質問

プレイスランキングAPIとは何ですか?

厳格な適格性審査の後、地理、業務、顧客コンテキストのシグナルを使って特定タスクの候補地点を並べるAPIです。

最寄り検索と同じですか?

いいえ。最寄り検索は主に距離順ですが、ランキングは移動時間、迂回、可用性、適格性、好み、鮮度、業務ルールも考慮できます。

利用できない場所は低い点数にすべきですか?

可用性が必須なら、他のシグナルで逆転し得る減点ではなく、ランキング前に除外します。

取得とランキングの違いは?

取得は候補を見つけ、ランキングは有効候補を並べます。取得されなかった関連場所をランカーは戻せません。

プロバイダー順位の後に再順位付けできますか?

できます。関連性、人気、距離、近接、経路で得た候補を、アプリが補完・除外し、業務タスク向けに再順位付けします。

どの空間シグナルを使うべきですか?

判断に合うものを使います。単純な近さは直線距離、実際の利便性は移動時間、経路上は迂回、サービス区域は包含関係です。

複数拠点ランキングとは?

ホテルを空港と会議場の両方に対して評価するように、複数の重要地点に対して候補を評価します。

言語モデルがスコアを計算すべきですか?

自然言語の好みは解釈できます。検証済み特徴量は決定論的コードか管理されたモデルが組み合わせ、時間、在庫、可用性は正本システムから取得します。

ランキングはどう説明しますか?

内部スコアではなく、移動時間、受取可、指定時間に営業など、実際のシグナルに結び付く短い理由を返します。

どう評価しますか?

候補再現率、厳格制約の充足、Top-K品質、ラベルが対応する場合のNDCGやMRR、後続の顧客成果で評価します。

Kaleidrに公開ランキングエンドポイントはありますか?

Kaleidr Enterpriseはランキングと分析を返すシステムとAPIを説明していますが、現在の公開Platform APIには独立した /rank エンドポイントが記載されていません。対応するEnterprise統合を確認してください。

参考文献

@misc{google_nearby_search_2026_08_26,
  title  = {Nearby Search (New)},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/nearby-search}
}

@misc{google_search_along_route_2026_08_26,
  title  = {Search along route},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/search-along-route}
}

@misc{google_text_search_2026_08_26,
  title  = {Text Search (New)},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/text-search}
}

@misc{kaleidr_auth_scopes_2026_08_26,
  title  = {Auth \& Scopes},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 26 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

@misc{kaleidr_endpoints_2026_08_26,
  title  = {Endpoints},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 26 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

@misc{kaleidr_enterprise_2026_08_26,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  note   = {Accessed 26 August 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{mapbox_search_box_2026_08_26,
  title  = {Search Box API},
  author = {{Mapbox}},
  note   = {Accessed 26 August 2026},
  url    = {https://docs.mapbox.com/api/search/search-box/}
}

@techreport{nist_privacy_framework_2020,
  title       = {NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0},
  author      = {{National Institute of Standards and Technology}},
  number      = {NIST.CSWP.01162020},
  institution = {National Institute of Standards and Technology},
  year        = {2020},
  month       = jan,
  url         = {https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf}
}

@misc{owasp_llm_top10_2025,
  title  = {OWASP Top 10 for LLM Applications 2025},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 26 August 2026},
  url    = {https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf}
}