施設向けAIウェイファインディングアシスタント

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

AIウェイファインディングアーキテクチャは、目的地の発見、経路計算、およびオプションの屋内位置情報を分離し、検証済みの地図案内を表示します。

AIウェイファインディングアシスタントは、自然言語によるナビゲーション要求を解釈し、信頼できる会場レコードから目的地を特定し、地図やルート案内を調整します。ただし、発見、ルーティング、位置情報を単一の機能として扱うことはありません。訪問者は、どの入口を使用すればよいか、ホールBへの行き方、最寄りのバリアフリー対応トイレの場所などを尋ねることができます。言語モデルは、これらのフィールドを検査可能なインテントとして取得できます。会場システム、ルーティングエンジン、およびあらゆる測位インフラストラクチャは、ジオメトリ、接続性、アクセス、およびリアルタイム位置情報に関して、依然として重要な役割を担っています。

以下のセクションでは、目的地解決、屋内接続性、アクセシビリティとアクセスフィルタ、発信元情報、共有ウェイファインディングの状態、Kaleidrの現在のパブリックフィット、測定、および障害モードについて説明します。関連資料として、イベント向けAI会場マップマップ認識型AIアシスタントの構築方法位置情報インテリジェンス顧客体験マップホテル向けAIゲストコンシェルジュAIマップワークフロー向けプ​​ライベート位置情報データなどがあります。

AIウェイファインディングの基本

  • 発見はルーティングではありません: ホールBを特定することと、ホールBへの接続経路を計算することは同じではありません。
  • ルーティングは位置情報ではありません: 製品が訪問者の位置を認識する前に、有効な経路が存在する場合があります。
  • フロアプラン画像はネットワークではありません: 屋内ガイダンスには、空間、ドア、廊下、フロア間のトポロジーが必要です。
  • アクセシビリティとアクセスは厳格なフィルタです: 階段、スタッフ用廊下、閉鎖されたエッジは、単にスコアを下げるだけでなく、グラフから除外する必要があります。
  • 言語モデルは意図を解釈します: 地理空間システムと会場システムは経路を計算し、ホストはマップ操作を検証します。

AIウェイファインディングアーキテクチャは、検証済みのマップガイダンスを表示する前に、目的地の発見、経路計算、およびオプションの屋内位置情報を分離します。

AIウェイファインディングアシスタントとは?

AIナビゲーションアシスタントは、複雑な場所でユーザーがどこへ行くべきか、そしてどのように移動すべきかを、会話、地図情報、信頼できる位置情報データを用いて案内する、顧客向けのレイヤーです。通常の検索では部屋名しか表示されません。静止画のポスターには建物の図面が表示されます。しかし、出発地、階数、チケットの利用可否、アクセシビリティ、閉鎖情報、現在表示されているルートといった情報を、確認可能な一つの状態として提示することはできません。会議場、キャンパス、病院、空港、リゾート、ショッピングモールなどでは、数分ごとにこのような複雑な情報検索が発生します。AIナビゲーションアシスタントは、目的地、ルート、階数を地図上に常に表示することで、訪問者が標識、PDF、カメラ操作ができないチャットパネルから情報を再構築する必要をなくします。

Kaleidrの空間AIページでは、地図体験の一つとして「ナビゲーション」が挙げられており、ユーザーの移動方法に合ったルートが説明されています(AI Map Chat for Customer Discovery)。このページは、Kaleidr独自の屋外および旅行向けナビゲーション機能に関する権威ある情報源となっています。屋内ターンバイターン方式のガイダンスは、目的地情報、ルーティング可能なネットワーク、そして実際に展開されている場合に限り位置情報システムという、別の契約に基づいています。顧客向けの位置情報情報は、引き続きDiscover → Compare → Actを使用します。Discoverは、対象となる目的地を取得します。Compareは、フロア、移動関係、アクセシビリティ、アクセス状況を確認します。Actは、ハイライト表示、フロア切り替え、ルーティングが存在する場合のルート要求、またはスタッフの引き継ぎです。

タスクはスタックの前に記述する必要があります。会場の訪問者は座席に最も近い入口を必要とするかもしれません。会議の参加者は現在のホールから次のセッションへの経路を必要とするかもしれません。空港の乗客はゲート近くの利用可能なラウンジを必要とするかもしれません。キャンパスの利用者は教室に最も近い建物の入口を必要とするかもしれません。病院の訪問者は公共入口からの画像を必要とするかもしれません。それぞれのタスクによって、候補、厳しい制約、垂直方向の遷移、リアルタイムの位置情報が必要かどうかが変わります。「屋内AIナビゲーション」から始めると、これらの違いが無視され、会場がサポートできない製品要件につながる可能性があります。

ディスカバリー、ルーティング、ポジショニングはなぜ分離する必要があるのか​​?

目的地ディスカバリーは、どの場所が関連しているかを答えます。経路計算は、対象となる訪問者が利用できる接続された経路を答えます。ポジショニングは、訪問者が現在どこにいるか、何階にいるか、そしてハードウェアが対応していれば、訪問者がどちらを向いているかを答えます。これら3つのレイヤーは連携できますが、どれも他のレイヤーの代わりにはなりません。フロアプラン画像に204号室が表示されていても、廊下の接続、開いているドア、アクセス可能な遷移、目的の階へのエレベーターサービス、信頼できる出発点が欠けている可能性があります。「10メートル先で左折してください」といったターンバイターン方式のナビゲーションには、経路情報と、使用可能な精度と方位を備えたリアルタイムの位置情報の両方が必要です。言語モデルはこれらの要求を調整できますが、不足しているトポロジー情報や青いドット(ナビゲーションポイント)を提供することはできません。

Open Geospatial ConsortiumのIndoorGML 2.0 パート1の概念モデルは、屋内ナビゲーションネットワークに関する現在のOGC概念スキーマです。この規格では、空間と空間分割、幾何学的特性と意味的特性、接続の種類、論理的およびメトリックなナビゲーションネットワークをモデル化しています(OGC IndoorGML 2.0 Part 1 – Conceptual Model、OGC 22-045r5、2025年6月26日発行)。製品版はIndoorGMLをシリアル化する必要はありません。ただし、製品は同じ区別を尊重する必要があります。つまり、視覚的なジオメトリはナビゲーショングラフではありません。OGCの2025年8月28日付公開通知では、IndoorGML 2.0パート2エンコーディングが近日公開予定であると記載されています(OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard)。IndoorGML 1.1は、引き続き公開されているエンコーディング指向のIndoorGML標準です(IndoorGML 1.1、OGC 19-011r4、2020年11月5日)。概念的な契約についてはパート1を参照してください。パート2が実装標準として存在するまでは、GML、JSON、またはSQL IndoorGML 2.0エンコーディングを公開実装標準として扱わないでください。

屋内マッピングデータフォーマットは、空港、ショッピングモール、駅などのモデリングに関する注記を含め、方向付け、ナビゲーション、および発見に使用される屋内位置情報アーカイブのための補完的なコミュニティ標準です(Indoor Mapping Data Format、OGC 20-094、バージョン1.0.0、2021年2月18日発行)。IndoorGML 2.0パート1自体は、IMDFがアプリケーションが経路を導出できる包括的なモデルを提供すると説明していますが、IndoorGMLは統一された空間グラフアプローチを目指しています。AIウェイファインディングアシスタントの場合、運用上の教訓はより限定的です。会話でナビゲーションを約束する前に、構造化された屋内データが存在する必要があります。

屋外のウェイファインディングは、道路や歩行者ネットワーク、ルーティングAPI、およびGNSSが既に存在するため、多くの場合よりシンプルです。アシスタントは目的地をジオコーディングし、プロバイダーにルートを要求して、結果を描画できます。屋内およびハイブリッドキャンパスフローでは、通常、追加のインフラストラクチャが必要です。フロアの状態、垂直方向の遷移、アクセス制御されたエッジ、ブラウザから取得されない可能性のある起点などです。キャンパスパスは、屋外のGNSS区間を建物の入口に接続し、その後屋内のグラフに接続する場合があります。会話レイヤーは、この遷移を説明できます。ルートエンジンは、各区間を引き続き管理します。

ルーティング前の目的地解決はどのように行うべきか?

「Hall B」という生の文字列へのルーティングは製品の不具合です。アプリケーションは、ルーティングエンジンが実行される前に、安定した目的地識別子、建物、およびフロアを解決する必要があります。表示名が衝突します。「Gate 12」と「Entrance 12」は異なるタイプのエンティティです。「Room」「Booth」「Session」の識別子は、人間が使う言語では衝突します。これは、AI会場マップがジオメトリとイベントオーバーレイを分離しているのと同じ理由です。建物、フロア、入口、部屋、ゲート、ブース、トイレ、エレベーター、階段、駐車場、サービスデスクなどの情報を入力したレコードは、ラベルが変更された場合でも、検索、地図、経路案内、アクセシビリティ、分析機能を同期させます。

{
  "destinationId": "hall_b",
  "buildingId": "expo_center",
  "floorId": "floor_1",
  "type": "hall"
}

利用資格は同じステップで処理されます。物理的に接続されたラウンジであっても、チケットの種類、セキュリティゾーン、またはスタッフ専用指定によって利用が制限される場合があります。候補となるスペースは、空間比較と説明の前に、認証と運用状況を確認する必要があります。制限付きポリゴンは取得前にフィルタリングされるため、言語モデルはどの通路がプライベートであるかを「記憶」する必要がありません。OWASP’s LLM01:2025 Prompt Injectionでは、ユーザーまたは取得されたテキストが、接続された機能への影響を含め、モデルの動作をどのように変更できるかを説明しています。OWASP Top 10 for LLM Applications 2025では、LLM06:2025 Excessive Agencyを列挙しています。これは、システムに過剰な機能、権限、または自律性が付与された場合に、予期しない、または操作されたモデル出力によって発生する有害なアクションです。経路案内アシスタントは、目的地と許可されたアクションを提案する必要があります。ホストアプリケーションは、スキーマ、アクセス、およびネットワーク状態の検証後に、カメラの移動、フロア切り替え、または経路要求を実行する必要があります。

曖昧さは、第一級の結果です。「メインエントランス」「北エントランス」「VIPエントランス」はすべて有効な解析結果となり得ます。製品は、入力された候補を地図上に表示したり、文字列の類似性から推測するのではなくタップ操作を要求したりして、ユーザーに質問する必要があります。会話が失敗した場合でも、目的地への直接検索は機能する必要があります。Hall Bと入力した訪問者は、対話を必要としません。複合質問に対する決定論的な検索、フィルタ、地図、会話は、同じ識別子を共有する必要があります。

屋内ルーティングには、フロアプラン画像ではなく、接続性が必要な理由

場所検索はジオメトリを強調表示します。屋内ルーティングは、接続されたグラフ全体にわたって計算を行います。部屋から廊下、ドア、階段、エレベーター、そして別の階へと続きます。表示ポリゴンとルーティングノードは、意図的に分離することができます。部屋のポリゴンは出入口ノードに接続できます。廊下のエッジは移動経路を示し、エレベーターと階段のエッジは階の移動、アクセシビリティ、および稼働状況を示します。装飾的なポリラインを含むラスターフロアプランは、このグラフではありません。会場マップガイドは、部屋の表示とターンバイターン方式の経路表示の間に同じ境界線を引いています。

複数階建ての会場マップとルーティンググラフを組み合わせることで、屋内ナビゲーションが空間、ドア、廊下、エレベーター、フロア間の明確な接続性に依存することを示しています。

複数階建ての状態は明示的に示す必要があります。出発地と目的地には、建物とフロアの識別子を含めるべきです。UIは、単一の2D線の中に遷移を隠すのではなく、ルートがフロアを変更する際にそれを表示するべきです。垂直方向のエッジには、階段、エレベーター、エスカレーター、スロープ、アクセシビリティ、サービスフロア、開閉状態などの属性が必要です。ルーティングエンジンはこれらの属性を使用します。言語モデルは、エンジンが構造化された手順を返した後、これらの属性を説明できます。望ましい流れは、ルーティングエンジンから構造化された手順、そしてより明確な説明文へと進むことであり、自由な方向付けではありません。「中央ロビーに向かって進み、東側のエレベーターを使用してください」といったランドマークを基準とした指示は、方位情報が利用できない場合でも引き続き使用できます。

一時的な閉鎖は、地図上の装飾ではなく、運用上の記録です。エスカレーターの故障、通路の閉鎖、入口の閉鎖、立ち入り禁止階、エレベーターの故障などが発生した場合、該当の経路は閉鎖状態としてマークされ、経路の再計算が強制されます。訪問者が読む説明文は、現在の経路バージョンを反映している必要があります。会話調の文章で描かれた古いジオメトリは、実際の会場ではコピーの問題ではなく、安全上の問題となります。経路の再計算はエンジンに任せるべきです。始点が変更されたり、経路が閉鎖されたりすると、以前の経路は無効になり、新しい経路が計算されます。言語モデルに座標の修正を依頼するのは、適切な制御方法ではありません。

アクセシビリティ、アクセスルール、閉鎖状態はどのように経路をフィルタリングするのか?

必須のアクセシビリティは、経路設定における厳密な制約です。訪問者がバリアフリー経路を要求した場合、階段の経路は除外される可能性があります。完全なバリアフリー経路には、段差のない移動、正常に動作するエレベーター、バリアフリーの入口、そして会場が実際に記録している出入口の幅などが含まれる場合があります。アクセシビリティをソフトな優先順位付けに組み込むと、バリアフリーではない経路が優先される可能性があります。アクセシビリティデータが不足しているからといって、完全にバリアフリーな経路を捏造してよいというわけではありません。システムがバリアフリー対応の入口とエレベーターしか認識していない場合、地図上にそれらの設備が表示されているだけで、完全なバリアフリー経路が認証されているとは言い切れません。法的なアクセシビリティに関する義務は、資格のある弁護士と施設運営者の判断に委ねられます。この記事では、データ契約について説明します。

3つの候補ルートは、アクセス可能性、アクセス権限、および現在の運用状況に基づいてフィルタリングされ、有効なルートのみが残ります。

物理的な接続性は、適格性の軸の一つにすぎません。スタッフ通路、VIPゲート、セキュリティゾーン、チケット制エリア、従業員入口などは、グラフ上では通行可能であっても、この訪問者にとっては通行禁止となる場合があります。ルートの適格性は、物理的な接続性、アクセス権限、および運用状況によって決まります。アクセス制御が適用される前に、制限された経路が会話レイヤーに到達してはなりません。安全な手順は、認証、アクセス権限の判定、許可されたスペースの取得、許可されたルートの計算、そして説明です。すべてのスペースを横断する経路を計算し、その後で制限されたステップを非表示にすると、トポロジーが漏洩します。マップAPI認証では、会話をホストマップに添付するKaleidrサーフェスの公開キーとサーバーキーについて説明します。会場のアクセスルールは、ホストのIDおよびチケットシステムに保持されます。

緊急時および安全時のルーティングは、非常に重要な役割を担います。生成型アシスタントは、一般的なモデル知識から避難経路、緊急手順、または限定的な安全ガイダンスを生成すべきではありません。会場が承認した緊急時対応情報、公式計画、現場スタッフ、および運用アラートを活用してください。ウェイファインディング製品は、承認された救護所や出口の場所を、それらの情報が信頼できる場合に限り表示できます。重要な経路案内は、その任務のために設計された運用システムに委ねられます。

ウェイファインディングに位置情報が必要な場合と不要な場合

すべての経路には起点が必要です。起点は、明示的な地図選択、メインエントランスなどの既知のランドマーク、最後に指定したエリア(「私はホールAにいます」)、屋外デバイスの位置、または屋内測位インフラストラクチャから取得できます。自動測位が可能な場合でも、手動で起点を設定できる機能は維持する必要があります。信頼性はデータによって決まります。数メートルの精度で位置情報が取得できれば、廊下規模の案内には役立ちます。屋内で数十メートルの誤差がある位置情報では、間違った廊下や階を選択してしまう可能性があります。ウェイファインディング製品は、屋内の位置が不確実であることを伝え、訪問者に現在地を選択するよう促す必要があります。誤った情報源からの自信満々な経路案内は、簡単な説明よりも悪い結果を招く。

2026年3月26日付けの勧告候補スナップショットである仕様W3CGeolocationでは、明示的な許可を得た場合にのみデバイスの位置情報へのアクセスを許可し、APIはデバイスの実際の位置を保証するものではないと明記している。ブラウザの位置情報による位置特定は、屋内の青い点のようなものではない。Bluetoothビーコン、Wi-Fi測位、ultra-wideband視覚測位、および施設固有のシステムはインフラストラクチャであり、言語モデルの機能ではない。「左折」指示には、方向情報も必要となる。地図は方位情報がなくても正しい経路を示すことができる。方位情報が利用できない場合は、方位を示す表現の代わりに、ランドマークまたは地図上の位置関係を示す表現を用いるべきである。

多くの施設では、継続的な屋内トラッキ​​ングなしでも、有用な経路案内を提供できる。訪問者がランドマークを選択すると、エンジンが経路を返し、地図上には静的なステップが表示され、訪問者は手動で進む。会議場、キャンパス、リゾート、美術館などでは、リアルタイムの青いドットよりも、こうしたパターン表示の方が必要とされる場合が多い。パターン表示はプライバシー保護とインフラコストの削減にもつながる。ウェイファインディングでは、現在の屋内位置、経路、繰り返し訪れた目的地、職場、医療機関、イベント参加状況など、詳細な移動履歴を作成できる。NIST Privacy Framework (NIST.CSWP.01162020、2020年1月16日) では、プライバシーを企業リスク管理として扱い、収集する情報、目的、期間を明確にする。永続的な移動プロファイルよりも、一時的な出発地、目的地、経路のコンテキストを優先する。AIマップワークフローのためのプライベート位置情報データ は、ホストが所有する境界内をカバーする。

対話型ウェイファインディングは、マップとどのように状態を共有すべきか?

目的地やルートが既に地図上に表示されている状態では、会話はより有効になります。現在の経路沿いのトイレ、階段を避けるリクエスト、選択した出発地からより近い入口などのフォローアップは、共有された状態に基づいて行われ、非公式な結果リストには依存しません。地図、リスト、指示、チャットは、出発地、目的地、アクティブなフロア、ルート識別子、ルートバージョン、アクセシビリティモード、位置情報システムが利用可能な場合は位置の信頼度といった、単一の経路案内レコードを読み取る必要があります。目的地を選択するとルートが表示されます。アクセシビリティモードを変更すると、現在のバージョンが無効になり、再計算が要求されます。アシスタントの結果は、利用者が既に利用している地図上に表示される必要があります。

共有された経路案内状態は、会話リクエスト、ルートデータ、フロアコンテキスト、施設情報、および検証済みの地図アクションを同期します。

{
  "routeId": "route_north_to_hall_b",
  "originId": "entrance_north",
  "destinationId": "hall_b",
  "mode": "accessible",
  "activeFloorId": "floor_1",
  "routeVersion": 4
}

セマンティックアクションは、出発地の設定、目的地のフォーカス、ルートの表示、フロアの切り替え、遷移のハイライト表示、目的地レコードの開き、ルートのクリア、再ルートのリクエストなど、簡潔にする必要があります。ホストは、レンダラーアダプタの実行前に、各ペイロードを現在の識別子、アクセス権限、およびネットワークバージョンに対して検証します。任意のマップJavaScriptは制御契約ではありません。これらのアクションの権限はアプリケーションとインフラストラクチャに属し、言語モデルには決して属しません。マップ対応アシスタントガイドでは、共有マップの状態と、そのハンドオフにおける検証済みアクションについて説明しています。

運用上の更新では、ネットワークとルートの両方をバージョン管理する必要があります。エレベーターの閉鎖は、ネットワークバージョン18上のルートバージョン4を無効にし、バージョン5を必要とする場合があります。バージョン管理により、古いガイダンスのデバッグが可能になります。ルートを適用する前の検証では、出発地、目的地、権限、ルートの鮮度、閉鎖状況、および移動モードが一致していることを確認する必要があります。ライブ会場では、経路探索の状態が急速に変化します。屋内では、オフラインまたは接続が不安定な状態も一般的です。必要に応じて、会場のジオメトリ、ラベル、最終階、および最後に有効だったルートをキャッシュしてください。会話レイヤーが失敗した場合でも、直接的な場所検索は機能する必要があります。空間分析ダッシュボードのKPIは、チャット量を成功の指標とするのではなく、製品の測定に関するものです。

Kaleidrは既存のウェイファインディングスタックにどのように適合しますか?

Kaleidrの現在の開発者向けドキュメントでは、チャットはホストが既に実行しているマップにアタッチされた会話型レイヤーとして位置づけられています。Quickstartでは、ライブのMapbox、MapLibre、Google Maps、またはLeafletインスタンスにチャットをマウントする方法を示しています。Chat attachでは、コントロールタワーはチャット駆動型のナビゲーション、概要表示、ホストマップへのピン配置を行うものとして説明されています。公開可能なキーはブラウザのオリジンにロックされています。サーバーキーはページ外に表示されません(Auth & Scopes)。スニペットでは、ライブ形式のキーではなく、分かりやすいプレースホルダーを使用する必要があります。

const handle = Kaleidr.mount("#chat", {
  product: "chat",
  publishableKey: "YOUR_PUBLISHABLE_KEY",
  map: myMap,
});

これらのサーフェスは、自然言語による目的地検索、地図認識型会話、場所に関する回答、ライブマーカー、カメラ更新をサポートします。ホストは、レンダラー、会場データ、ルートエンジン、屋内トポロジー、測位、アクセス制御を引き続き所有します。Kaleidrの公開ドキュメントには、AIマップチャット、公開マップ、設計済みベースマップ、マップ編集について記載されています。これらのドキュメントには、専用の屋内測位エンジンや、ターンバイターン方式の屋内ナビゲーション製品に関する記述はありません。したがって、適切なアーキテクチャは、Kaleidr上で会話型かつ地​​図認識型のインタラクションを実現し、展開時に必要に応じて会場またはナビゲーションシステムに専用の屋内ルーティングまたは測位機能を持たせることです。Location Intelligence APIs and Map SDKは、推論API、ランキングシステム、分析、展開サポートのための現在の商用サーフェスです。ランキングと屋内ルーティングは依然として異なる製品です。マーケティング用語から架空の屋内ナビゲーションルートをエンコードしないでください。

ハイブリッドプレイスもこの区分に当てはまります。屋外区間はルーティングプロバイダを使用できます。屋内ルートでは会場図を利用できます。イベントオーバーレイを使えば、会場マップの記事で説明されているように、壁を再構築することなくブースやセッションを変更できます。病院や空港からのリクエストは、経路描画よりも目的地の特定とアクセス権限の点で最初に失敗することがよくあります。「イメージング」や「42番ゲート付近で利用できるラウンジ」といったリクエストは、幾何学的な問題になる前に、まず利用資格の問題です。言語モデルはリクエストを解釈できます。承認されたビジネスデータと地理空間サービスは、依然として事実を提供します。

AIウェイファインディングアシスタントをチームはどのように評価すべきか?

チャット量ではなく、経路案内機能そのものを測定してください。目的地解決率、結果なし率、経路成功率、階間違いの修正、経路変更率、アクセス拒否、経路案内完了までの時間、目的地確認、経路放棄率といった指標は、利用者が実際に目的地に到達したかどうかを示します。位置情報機能がある場合は、経路外れイベント、位置情報の信頼性エラー、階検出エラーも追加してください。経路探索とナビゲーションは区別してください。経路が失敗したものの目的地が解決された場合は、経路検索の失敗とは異なる不具合です。目的地解決、経路要求、経路失敗、階変更、経路変更といった編集上のイベント名は、製品分析であり、文書化された自動イベント(Kaleidr Analytics)ではありません。

評価項目には、曖昧さ、階をまたぐ経路、閉鎖されたエッジ、アクセス制限、アクセシビリティデータの欠落、低接続時のフォールバックなどを含める必要があります。地図、リスト、音声またはテキストによる手順が同じ経路バージョンを示していることを確認してください。遅延は段階ごとに特定する必要があります。「AI」のせいにするチームは、ルーティングや出発地解決が主な原因であることが多いことに気づくでしょう。タスク完了はインタラクション数よりも重要です。チャットせずに検索でホールBを見つけた訪問者は成功です。間違った階で終わってしまう長い会話は成功ではありません。

ウェイファインディング製品が避けるべき障害モードとは?

繰り返し発生する障害は、3つのシステムを1つの生成された段落に統合してしまうことです。フロアプラン画像がルーターとして扱われ、言語モデルが位置情報システムとして扱われます。フロアが表示されなくなります。アクセシビリティが優先順位の重みになります。制限されたエッジが漏れます。方向指示のないターンバイターン方式の案内が表示されます。会話が必須になります。移動履歴がデフォルトで保持されます。以下の各行は、具体的な修正方法とともに製品の欠陥を示しています。

間違い 結果 より良いアプローチ
地図画像をナビゲーションネットワークとして扱う ルートが信頼できない 接続性をモデル化する
言語モデルを位置情報システムとして扱う 出発地が信頼できない 明示的な出発地ソースを使用する
フロアを無視する 間違った階への案内 共有状態でフロアを追跡する
モデルに経路を生成させる 安全でない経路または古い経路 経路エンジンを使用する
アクセシビリティを優先する アクセスできない経路が優先される可能性がある 厳しい制約を使用する
一時的な閉鎖を無視する 古い経路 エッジの状態を更新して再計算する
制限区域を通過する経路 アクセスリーク 経路設定前にグラフをフィルタリングする
方向指示なしでターンバイターン方式を約束する 誤解を招く指示 ランドマークまたは地図上の相対的な表現を使用する
会話を必須にする チャットが失敗すると基本的なナビゲーションが失敗する 決定論的な検索を維持する
デフォルトで移動を保持する プライバシーリスク 一時的な経路コンテキストを保持する

モバイル経路案内には、大きな目標、読みやすい手順、そしてモデルや高負荷な経路がタイムアウトしても使用可能な地図が必要です。基本ジオメトリをキャッシュします。エンリッチメントを制御された方法で劣化させます。会話が利用できない場合でも、入力された検索から経路を保持してハイライト表示します。

対話型ウェイファインディング体験の構築

信頼性の高いアーキテクチャは、意図、目的地解決、承認済みルーティング、経路計算、説明、および検証済みマップアクションで構成されます。屋内測位はオプションのレイヤーであり、会場が適切なシステムを運用している場合にのみ追加されます。Kaleidrは、ホストが既に実行しているマップに対話型空間AIを付加できます。一方、真の屋内ナビゲーションが必要な場合は、会場のトポロジと専用ルーターが権威的な役割を果たします。

現在のAPI、SDKインターフェース、導入支援については、Kaleidr Enterpriseをご覧ください。統合方法を実装する前に、Kaleidr開発者ドキュメントで接続パターンとキーの種類を確認してください。

よくある質問

AIウェイファインディングアシスタントとは?

AIウェイファインディングアシスタントは、自然言語によるナビゲーションの質問を解釈し、信頼できるレコードから目的の目的地を解決し、マップまたは経路案内を調整します。ルーティングと測位は別々のシステムとして扱われます。

AIによる経路案内は屋内ナビゲーションと同じですか?

いいえ。AIはナビゲーション要求を解釈できますが、屋内ナビゲーションには構造化されたルーティングネットワークが必要であり、屋内測位も必要となる場合があります。

フロアプラン画像だけでターンバイターン方式の経路案内は可能ですか?

それだけでは不可能です。信頼性の高い経路案内には、空間、ドア、廊下、階段、エレベーター、その他の遷移間の接続性が必要です。

IndoorGMLとは何ですか?

IndoorGMLは、屋内空間データおよびナビゲーションデータに関するOGC規格です。IndoorGML 2.0 パート1は、空間、接続性、およびナビゲーションネットワークに関する現在の概念モデルです(OGC 22-045r5)。OGCでは、IndoorGML 2.0のエンコーディングスキーマが2025年8月時点で公開予定であると説明されています。IndoorGML 1.1は、現在も公開されているエンコーディング指向のバージョンです。

IMDFとは?

屋内マッピングデータフォーマットは、方向付け、ナビゲーション、および発見に使用される屋内位置アーカイブに関するOGCコミュニティ標準(OGC 20-094、バージョン1.0.0)です。

Kaleidrは現在、屋内測位機能を提供していますか?

Kaleidrの現在の公開ドキュメントには、空間AI、マップチャット、カスタムマップ、公開、既存マップとの統合について記載されています。専用の屋内測位システムについては記載されていないため、ホストアプリケーションが屋内測位システムを統合しない限り、屋内測位は別の展開機能として扱う必要があります。

Kaleidrは屋内マップと連携できますか?

Kaleidrは、互換性のある既存のマップ実装に対話型AIを接続できます。マップデータ、ルートネットワーク、および屋内測位は、ホストアプリケーションが引き続き責任を負います。

アクセシブルな経路案内はどのように機能するべきですか?

アクセシビリティ要件は、検証済みの施設データを使用して、厳密なルート制約としてエンコードする必要があります。アシスタントは、不完全な情報からアクセシブルなルートを生成してはなりません。

AIマップアシスタントは訪問者のルートを変更できますか?

アシスタントは、新しいルートを要求または説明できます。権威ルーティングエンジンは、現在のネットワーク状況とアクセスルールを使用して再計算する必要があります。

経路案内機能はユーザーの位置情報を継続的に追跡すべきでしょうか?

製品が必要とし、かつユーザーに適切な通知または同意を与えている場合に限ります。多くの経路案内機能は、継続的な追跡を行わなくても、選択した出発地またはランドマークに基づいて動作します。

参考文献

@misc{kaleidr_wayfinding_ai_2026_08_27,
  title  = {AI Map Chat for Customer Discovery},
  author = {{Kaleidr}},
  note   = {Accessed 27 August 2026},
  url    = {https://kaleidr.com/ai}
}

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

@misc{kaleidr_chat_attach_2026_08_27,
  title  = {Chat attach},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/sdk/chat-attach}
}

@misc{kaleidr_docs_intro_2026_08_27,
  title  = {Introduction},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/}
}

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

@misc{kaleidr_quickstart_wayfinding_2026_08_27,
  title  = {Quickstart},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/quickstart}
}

@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}
}

@techreport{ogc_indoorgml_1_1,
  title       = {IndoorGML 1.1},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 19-011r4},
  institution = {Open Geospatial Consortium},
  year        = {2020},
  month       = nov,
  url         = {https://docs.ogc.org/is/19-011r4/19-011r4.html}
}

@techreport{ogc_imdf_1_0_0,
  title       = {Indoor Mapping Data Format},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 20-094},
  institution = {Open Geospatial Consortium},
  year        = {2021},
  month       = feb,
  note        = {OGC Community Standard, version 1.0.0},
  url         = {https://docs.ogc.org/cs/20-094/index.html}
}

@techreport{ogc_indoorgml_2_0_part1,
  title       = {OGC IndoorGML 2.0 Part 1 – Conceptual Model},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 22-045r5},
  institution = {Open Geospatial Consortium},
  year        = {2025},
  month       = jun,
  url         = {https://docs.ogc.org/is/22-045r5/22-045r5.html}
}

@misc{ogc_indoorgml_2_0_announcement_2025_08_28,
  title  = {OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard},
  author = {{Open Geospatial Consortium}},
  year   = {2025},
  month  = aug,
  note   = {Accessed 27 August 2026},
  url    = {https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/}
}

@misc{owasp_llm01_prompt_injection_2025,
  title  = {LLM01:2025 Prompt Injection},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://genai.owasp.org/llmrisk/llm01-prompt-injection/}
}

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

@misc{w3c_geolocation_2026_03_26,
  title  = {Geolocation},
  author = {{W3C}},
  note   = {W3C Candidate Recommendation Snapshot, 26 March 2026; accessed 27 August 2026},
  url    = {https://www.w3.org/TR/geolocation/}
}