エンタープライズ Spatial AI アーキテクチャ

エンタープライズ Spatial AI アーキテクチャは、言語モデル、地図、業務データ、空間計算、権限、ツール、アクションを分離し、それぞれの処理を、そのルールを確実に適用できるレイヤーに置きます。流暢な回答でも、利用者を誤った支店へ案内することはあります。ホストは ID と取引を保持します。空間サービスは地理計算を担当します。言語モデルは要求を解釈し、それらのシステムによってすでに根拠付けられた結果を説明します。

以下では、所有責任、認可、認証情報、ツール、リクエスト経路、3 つのデプロイパターンを扱います。関連する記事として Spatial AI Accuracy Evaluation と An Enterprise Spatial AI Pilot があります。どの system of record にも裏付けられていないもっともらしい推薦より、正しく拒否するほうが良い結果になることがあります。

エンタープライズ Spatial AI アーキテクチャの要点

• 役割を分離する: 言語モデルは解釈と説明を担当します。在庫、権限、ルート、取引の所有者にはなりません。
• 取得前に認可する: プライベートなコンテキストがモデルに届く前に、ユーザー、テナント、オブジェクト、フィールドを解決します。
• 事実は型付きのまま保持する: 安定した ID と運用フィールドは構造化されたままにします。文章で置き換えません。
• すべてのツールを限定する: 読み取り、地図、下書き、書き込みの各アクションには異なる承認ルールを持たせます。
• ワークフローを測る: token やレイテンシだけでなく、位置に関する意思決定とホスト側の結果を観測します。

エンタープライズ Spatial AI アーキテクチャとは何か？

顧客が「今日この作業に対応でき、契約エリア内にあり、現在のルートからの追加移動時間が最も少ないサービスセンターはどこか」と尋ねることがあります。この一文には、意図レイヤー、顧客・契約レコード、施設データ、サービスエリアのルール、ルーティング計算、地図ワークフローが必要です。本番システムにはさらに、ID、テナント分離、ツール制限、アクション検証、ログ、高影響の処理を人が承認できる場所も必要です。これらすべてを 1 つの prompt に押し込むと、プロダクトは安全にしにくく、変更もしにくくなります。モデルは次に何をすべきかを示せますが、強制力を持つルールの適用はモデルの外側に置きます。

左側は 1 つのモデルをデータベース、ルーティング、取引へ直接つなぎます。右側は ID、データ、空間ツール、ランキング、検証済みアクションを別レイヤーに保ちます。この対比はアーキテクチャパターンであり、Kaleidr のベンチマークではありません。

実用的な経路は、何にでもアクセスできるモデルとユーザーが直接対話する形より、ホストが検査できる一連の処理に近くなります。アプリケーションはユーザーと現在の地図状態を保持します。ID と認可は取得前に解決します。その後、意図解釈は承認済みデータと空間計算だけを要求します。適格性判定で無効な候補をランキング前に除外します。検証済みアクションが地図またはワークフローを更新し、分析は処理が成功したかを記録します。この流れなら、1 つの不透明な依存関係を中心にプロダクトを作り直さずに、モデル、地図プロバイダー、ランキングルールを変更できます。

各事実はどのシステムが所有すべきか？

アーキテクチャの検討では、モデルを選ぶ前に、重要な事実ごとの所有者を明確にする必要があります。ホストの ID プロバイダーはユーザーを所有します。ホストアプリケーションはテナント所属、プロダクトの利用権、ワークフロー、業務結果を所有します。業務システムは施設 ID、在庫、可用性、価格、予約状態、ポリシーを所有します。承認済みの位置情報ソースは座標を所有します。空間計算レイヤーは距離、移動時間、point-in-polygon を所有します。クライアントアプリケーションは viewport と選択された場所を所有します。AI レイヤーは意図解釈と、根拠付けられた証拠に基づく説明を所有します。ホストのワークフローは最終取引を所有します。

各列には 1 つの主たる所有者があります。AI レイヤーは意図と説明を調整します。ホストと業務システムは引き続き system of record であり、この図は製品一覧ではなくフレームワークです。

チームが重要な事実の所有者を明確にできない場合、アシスタントはその空白を隠してしまいがちです。Kaleidr の grounded Spatial AI に関するガイダンスも同じ分離を採用しています。モデルは複合的な意図を解釈し、在庫、ポリシー、権限、ルーティングは、それらの事実を保持するために設計されたシステム側に残します（Kaleidr, 2026）。retrieval はコンテキストを見つけます。authority は、どのソースが事実に関する問いへ回答してよいかを決めます。取得した文書が自動的に system of record になるわけではありません。

なぜ取得前に認可するのか？

よくある誤りは、プライベートデータを取得してモデルへ渡した後で、「この人が見てよい行はどれか」をモデルに判断させることです。順序を逆にします。ユーザーを認証し、テナントを解決し、ロールと権利を解決し、オブジェクトを認可し、フィールドを最小化し、承認済みレコードを取得してから、必要なコンテキストだけを後段へ渡します。権限境界は決定論的かつ監査可能であるべきです。地域マネージャーが施設を見てよいか、ある顧客が別の顧客の位置履歴を読めるか、従業員が制限された職場データを取得できるかを言語モデルに決めさせるべきではありません。

プライベートレコードは、テナント、ロール、オブジェクト、フィールドのチェック後にのみ境界を越えます。完全なデータベースからモデルに権限を推論させる下側の経路はブロックされます。プラットフォーム認証情報とエンドユーザー認可は、別のチェックのままです。

プラットフォーム認証情報は、アプリケーションがある機能を利用できることを示せます。しかし、その認証情報は、どのエンドユーザーがどの行を読めるかを決めません。CORS、認証情報の認証、API capability scope、アプリケーションレベルのユーザー認可は別々の問題を解きます。それらを混同すると誤った障害モードになります（Kaleidr, 2026）。したがって、プライベートデータの経路は複数のチェックを積み重ねたものであり、すべてを意味する 1 つの token ではありません。

ブラウザ用とサーバー用の認証情報はどう分離すべきか？

ブラウザは検査可能なので、そこへ配布するものは、実行している利用者に見えるものとして扱うべきです。長期秘密情報、プライベートな業務データへのアクセス、ポリシーの適用、server-to-server 呼び出しは backend に置くのが適切です。ブラウザには、範囲を限定した地図機能のための公開可能でクライアントセーフな認証情報を置けます。認証済みのプロダクト要求はホスト backend へ送り、そこでユーザーコンテキストを適用し、プライベートデータへアクセスし、サーバー認証情報を使って空間処理または AI 処理を呼び出します。2 つの実行環境で同じ秘密情報を共有すべきではありません。

ブラウザ側は露出を前提に設計され、範囲を限定したクライアント機能だけに制限されます。サーバー側は server credential、プライベートレコード、ユーザー認可を保持します。チェックマークは境界を示す概略であり、セキュリティ認証ではありません。

Kaleidr の現行の key ドキュメントは、ブラウザ利用向けの publishable key と backend 連携向けの server key を定義しています。publishable key は origin にロックされ、SDK はその文字列を恒久的な server bearer として使うのではなく、実行時に短命なセッションへ交換します。server key は信頼できるサーバーに保持されます（Kaleidr, 2026）。同じドキュメント群では Chat、Editor、Tile、Viewer を別々の surface として説明しており、attach、embed、tile の入口はすべて同じ方法で mount されるわけではありません（Kaleidr, 2026）。1 つの認証情報と 1 つの mount 方法で全スタックを覆えると仮定せず、各 surface の現行 contract に従ってください。

業務上の事実と地理情報はどこに置くべきか？

Enterprise Spatial AI が有用なのは、公開モデルが知らない事実を扱えるときです。現在の在庫、パートナーの適格性、施設能力、契約カバレッジ、一時閉鎖、リアルタイムの可用性などです。これらの事実は system of record に属します。今日の午後に変わり得る値をモデルに記憶させてはいけません。クエリで返せる運用フィールドをモデルへ fine-tune してはいけません。広範な社内データベースを system prompt に貼り付けてはいけません。要求を解釈し、必要な認可済みレコードを判断し、最小限を取得し、安定した ID と型付きフィールドを保持し、ハードフィルターを実行し、地理を計算してから、根拠付けられた結果を説明します。

{
  "branch_id": "b_1042",
  "open_now": true,
  "inventory_status": "in_stock",
  "service_eligible": true,
  "lat": 38.91,
  "lng": -77.22
}

型付きレコードなら、フィルター、ログ記録、権限確認、後続アクションへの受け渡しができます。「この支店は開いているようだ」「おそらく在庫がある」といった文章ではできません。自然言語は説明には有用ですが、アプリケーションが直接保存できるフィールドの代わりにはすべきではありません。

空間計算も同じ理由で独立したレイヤーにする価値があります。point-in-polygon、ルート距離、運転時間、徒歩時間、サービスエリア所属、ルート逸脱、指定時間内に到達可能かという分析は、プロダクトが計算できるなら地理サービスから得るべきです。AI レイヤーは「計算が必要」と判断できます。実際の計算は空間サービスが行います。その後、説明で「その関係が要求にとってなぜ重要か」を示します。言語モデルを変更しても、アプリケーションが移動時間や包含判定を測る方法まで作り直す必要はありません。

ハード制約とソフトな選好は分けておくべきです。クリニック検索なら、対応保険、18 時以降の営業時間、稼働中の施設、ユーザーがアクセスできるレコードが必須条件になることがあります。それらのルールを通過した候補だけを、運転時間、ルート逸脱、明示された選好でランキングします。順序は retrieval、認可、適格性、空間計算、ランキング、説明です。最初にランキングし、「モデルがすべての制約を覚えているはず」と期待すると、無効な候補が自然な shortlist の中に残ります。小売、不動産、予約、職場、複数拠点ネットワークでも同じ順序を使えます。制約の本質は業界用語ではなく、有効性だからです。

ツールとアクションはどう限定すべきか？

Agentic Spatial AI では、ツールカタログ自体が重要な境界になります。任意の SQL 文字列、shell command、自由形式の内部 URL のようなオープンなツールは、業務機能ではなく実行環境です。入力と出力が明確な狭いツールを優先します。たとえば、適格な場所を検索する、移動時間を計算する、支店の可用性を読む、場所を表示する、ルートを要求する、予約下書きを作成する、などです。各ツールに、独自の権限チェック、検証、rate limit、ログ行、障害モードを持たせられます。

読み取りツールと地図ツールは、呼び出し元がすでに認可されていれば実行できます。下書きはレビュー可能なオブジェクトを作成します。予約確定、作業割当、レコード変更を行う書き込みは、明示的なポリシー gate を待ちます。この階層はアーキテクチャ上の指針であり、固定された Kaleidr 権限一覧ではありません。

レコードの読み取りと業務状態の変更は、別のリスククラスです。本番カタログでは、能力を read、map、draft、write に分けられます。認可通過後、読み取りや低影響の地図アクションは自動実行してよい場合があります。draft は予約やサービス依頼をレビュー用に準備できます。予約確定、車両配車、変更公開などの write は、確認、2 回目のポリシーチェック、場合によっては人の承認を必要とします。confidence score は権限システムではありません。

OWASP の 2025 年 excessive agency ガイダンスは、過剰な機能、過剰な権限、過剰な自律性を別々の原因として扱います。エージェントが呼び出せる extension を必要最小限に制限し、オープンな機能より細粒度の関数を優先し、高影響アクションには承認を要求し、モデルに呼び出し許可を任せるのではなく downstream system で認可を強制することを推奨しています（OWASP, 2025）。それでもアプリケーションは、提案されたすべての呼び出しを検証すべきです。地図アクションなら、アクション自体が許可されているか、place ID が認可済み結果セットに属するか、ユーザーがそれらへアクセスできるか、引数が正しく形成されているかを確認します。write にはさらに厳しいチェックを適用します。prompt、取得文書、不正なツール結果が認可 bypass になってはいけません。

OWASP の system prompt ガイダンスも、反対側から同じ境界を示しています。system prompt は秘密情報ではなく、セキュリティコントロールでもありません。権限分離と認可チェックを、prompt 経由であれ別の方法であれ、モデルへ委任してはいけません（OWASP, 2025）。地図アクションは「場所を表示」「場所に合わせて表示範囲を調整」「場所を選択」「ルートを描画」「ルートを消去」のようなセマンティックな語彙を使い、決定論的 adapter がそれらを Mapbox、MapLibre、Google Maps、または別の renderer 向けに変換すべきです。モデルが毎ターン renderer code を出力するべきではありません。

地図状態はリクエストへどう入れるべきか？

地図状態は、「これら」「ここより北」「2 番目の候補」が何を意味するかを変えます。有用な snapshot には、viewport bounds、選択中の place ID、表示中の result ID、active filter、現在の route ID、そしてタスクに必要な精度で承認された位置情報を含められます。各フィールドが常時利用可能か、任意か、プライベートか、ユーザー承認済みか、古いか、権威ある値か、推論値かを明示します。地図が読めるからというだけで、正確な device location をすべてのリクエストに送るべきではありません。「この中でどこが最も遅くまで営業しているか」に対する最良の参照は、スクリーンショットではなく現在の結果セットの安定した ID です。Kaleidr の map-aware assistant ガイダンスも、viewport、selection、filter、result ID を共有し、ピクセルからアプリケーション状態を推測させないという境界を示しています（Kaleidr, 2026）。

オーケストレーションレイヤーは、要求に業務データ取得、ルーティング、地図アクション、確認質問、証拠の要約のどれが必要かを選べます。このレイヤーはモデル駆動でも、ルール駆動でも、その組み合わせでも構いません。ただし、唯一のセキュリティ境界にしてはいけません。オーケストレーションは「可用性を呼び出すべきか」を判断できます。認可は「この呼び出し元がこれらのレコードの可用性を取得してよいか」を答えます。オーケストレーションは「予約を開始すべきか」を判断できます。取引レイヤーは「ユーザーが確認したか」「処理が有効か」を答えます。この分離はモデルが誤っても維持されます。

テナント分離も同じ経路に置きます。クエリ前に、認証済み ID、テナント、ロール、許可されたオブジェクトを解決し、そのテナントへクエリを scope します。「他のテナントについて言及しないようモデルに指示した」という prompt に依存してはいけません。明示的な cross-tenant の目的とポリシーがない限り、モデルへ別テナントのデータを渡すべきではありません。tenant-scoped query、object check、field minimization、redacted log がコントロールです。prompt の一文はコントロールではありません。

本番リクエストはスタックをどう通るか？

完全なリクエストは 12 段階で描けますが、すべてのリクエストがすべての段階を必要とするわけではありません。認証済みユーザー、テナント、地図状態、ワークフロー状態を取得します。タスク、地理的制約、業務制約、意図したアクションを解釈します。プライベート取得の前に、許可されたソース、レコード、フィールド、ツール、アクションを解決します。

認可済みの事実と canonical place ID を取得し、その後で距離、移動時間、包含関係、サービスエリア所属を計算します。未認可、利用不可、閉鎖中、エリア外の候補を除外し、残りをランキングします。根拠付けられた結果を説明し、セマンティックな地図またはワークフローアクションを提案し、そのアクションをモデルの外で検証します。アクションを実行した後、判断と結果を記録します。

各段階は、地図状態と意図から、認可、grounding、地理、適格性、ランキングへ進み、その後、説明、提案アクション、検証、実行、測定へ続きます。「この場所を表示」のような単純な要求なら、取得とランキングを省略できます。サービス推薦では、ほぼ全経路を使う場合があります。

障害時の挙動も同じ経路の一部です。業務データが利用できない場合、可用性を捏造してはいけません。「現在は可用性を確認できない」と返します。ルーティングが停止している場合、移動時間によるランキングを行ったと主張してはいけません。直線距離による fallback を使うなら、fallback であることを明示します。ハードルールを通る候補が 1 つもない場合、重要な制約を黙って緩めるのではなく no result を返します。認可に失敗した場合、モデルへ「受け取っていないプライベート情報を説明しろ」と求めてはいけません。モデルが利用できない場合でも、決定論的な検索とフィルターで地図機能を継続できることがあります。ツール結果が不正なら検証段階で拒否します。明示的な degraded mode を持たないプロダクトでは、言語モデルが不足したインフラの偶発的 fallback になってしまいます。

人による承認は、すべてのボタンに同じルールを適用するのではなく、影響度に従います。公開された 3 つの場所を表示するのは低影響です。予約を確定する、車両を配車する、施設レコードを変更する、有料予約を送信する、といった処理はそうではありません。検索、取得、ルートプレビューを低影響と分類します。保存済み選好や下書きを中影響とします。購入、配車、運用書き込み、権限変更を高影響とします。そのうえで、自動実行、ユーザー確認、別承認をクラスに合わせます。NIST の AI Risk Management Framework は任意のフレームワークで、AI プロダクトの設計、開発、利用、評価に trustworthiness を取り込むことを目的としています。同じ NIST ページには AI RMF 1.0 が改訂中であることも記載されています（NIST, 2023）。このフレームワークはプロダクト独自のリスク判断の文脈であり、Kaleidr のコントロール一覧ではありません。

コントロールプレーンはどこに置くか？

リクエスト経路は、ユーザー、認可、取得、空間ツール、モデル、アクション、レスポンスというライブ処理を扱います。コントロールプレーンは、その経路をどのように実行してよいかを決めます。認証情報、scope、モデル選択、prompt、ツールポリシー、データソース設定、rate limit、環境、評価スイート、feature flag、監査設定をそこに置きます。両者を分離すれば、各会話フローを書き直さずにポリシーを変更できます。write tool を無効化するために、新しいインターフェースを作るべきではありません。コントロールプレーンはこれらの設定に対するアーキテクチャパターンであり、図は「1 つの製品がすべての箱を提供する」と主張するものではありません。

上段には、認証情報、scope、モデル、prompt、ツールポリシー、データソース、limit、評価、flag、監査設定があります。下段はライブリクエストです。ポリシーは制御対象の段階を指し、チームは経路を書き直さずにルールを変更できます。

observability は token コストだけでなく、意思決定そのものを追うべきです。有用なイベントには、意図解決、認可成功・拒否、取得完了、適格性による候補除外、空間計算完了、ランキング完了、no-result 応答、ツール提案、ツール拒否、地図アクション実行、場所選択、ワークフロー完了などがあります。これらの名前は設計すべきパターンであり、プラットフォームが自動的に出す固定リストではありません。答えたい問いは実務的です。エラーは場所解決から来ているのか、ランキングから来ているのか。利用者は有効な shortlist を拒否しているのか。特定市場だけ空結果が多いのか。ツール呼び出しは権限で失敗しているのか、不正な引数で失敗しているのか。場所選択後にホスト側のタスクは完了したか。NIST の AI RMF core は、test、evaluation、verification、validation で使った test set、metric、tool の詳細を文書化するとしています（NIST, 2023）。Spatial AI では、文書化するテストは生成文だけでなく、地理的・業務的な意思決定をカバーすべきです。

空間分析とホスト側成果は別の問いに答えるため、アーキテクチャでは安定した ID で両者をつなぐべきです。Kaleidr Analytics は現在、reach、view、engagement、オーディエンスの位置と活動、マップごとの session・view・interaction、空間パターンの dashboard を説明しています（Kaleidr, 2026）。予約、購入、qualified lead、配車、完了サービスは、それらを所有するホストシステムに残ります。recommendation ID は selected place ID を指し、そこから host workflow ID、最終成果へつなげられます。公開されている Analytics の説明は、すべての業務 conversion が自動取得されるとは述べていません。

3 つのデプロイパターンとは？

3 つのパターンで多くのエンタープライズ導入をカバーできますが、どれか 1 つが常に最良というわけではありません。公開地図アシスタントは、観光、発見、編集地図、イベント探索に向きます。ブラウザ地図は publishable な client capability、map-aware AI、公開または承認済みの place data、空間ツールを使い、地図アクションを返します。ワークフローの大半が公開情報なので、データ境界は単純です。認証済み業務アシスタントは、顧客ポータル、在庫を考慮した店舗選択、不動産、パートナーネットワーク、非公開施設に向きます。ブラウザはホストログインとホスト backend に到達し、プライベートデータ、空間ツール、説明が地図へ戻る前に tenant と object の認可を適用します。業務アクションを持つ spatial agent は、予約、配車、運用ワークフローに向きます。経路には型付き tool proposal、決定論的 validation、影響度に応じた confirmation、transaction system、結果 audit が追加されます。この 3 つ目のパターンは業務状態を変更するため、最も厳格な governance が必要です。

公開パターンは承認済みの公開場所だけを扱います。認証済みパターンはプライベートレコードをホストの背後に保持します。アクションパターンは取引前に validation と confirmation を追加します。図中のサンプル place card は例示であり、Kaleidr の測定結果ではありません。

このアーキテクチャで Kaleidr はどこに位置するか？

Kaleidr は現在、Enterprise をプロダクトチーム向けの location-intelligence infrastructure と説明しており、inference API、ranking、Analytics、ホストが追加できる SDK surface を提供するとしています（Kaleidr, 2026）。開発者ドキュメントは 1 つの SDK に 4 つの surface を挙げています。Chat はホストがすでに動かしている地図に AI interaction を追加します。Editor はプロダクト内に地図編集を mount します。Tile は設計された basemap を配信します。Viewer は埋め込み用に地図を公開します。現行 Chat ドキュメントは、ホスト所有の地図に対する統合経路として Mapbox、MapLibre、Google Maps を挙げています（Kaleidr, 2026）。ホストはエンドユーザー、認証、tenant 認可、プライベート業務システム、workflow rule、transaction、業務成果を保持します。Kaleidr は選択した空間 surface を追加しますが、ホストスタック内で権威あるままのシステムを置き換えるものではありません。

ホスト行は、ユーザー、tenant 認可、ワークフロー、プライベートシステム、取引、成果を保持します。Chat、Editor、Tile、Viewer は platform API と Analytics の横に置かれます。認証情報のラベルは公開ブラウザ／サーバー分離に従い、図には実際の秘密情報を示していません。

本番まで隠れやすい誤りは何か？

モデルをすべてのシステムへ直接接続すると、過剰な権限が生まれ、どのレイヤーが失敗したのか特定しにくくなります。prompt を認可レイヤーとして扱うのも同じ理由で失敗します。prompt は表現を誘導できますが、レコードを決定論的に許可・拒否できません。内部データベース全体を context に送ることは minimization に反します。ハードフィルターとランキングを混ぜると、不適格な場所が平均値の中に残ります。空間サービスが計算できる距離をモデルに推定させることは、計算を流暢さで置き換えることです。無制限の 1 つのツール、あるいは read tool の policy を引き継いだ write tool は、推薦に取引の権限を与えてしまいます。地図を単なる画像として扱うと、次のターンに必要な安定 ID を失います。レイテンシと token cost だけを監視すると、場所解決、適格性、ルーティング、ランキング、ツール失敗、ホスト成果を見逃します。モデル benchmark だけでは、組み上げたワークフローが本番準備済みか判断できません。

NIST の TEVV-Athlon framework、NIST AI 200-2 の initial public draft は 2026 年 8 月 7 日に発表され、コメントは 2026 年 10 月 6 日まで受け付けられています。この文書は、評価を「システムが個人または組織の目標を満たしていることの証拠」と説明し、agentic system を含むアプリケーションと実世界の影響に合わせて測定を調整するとしています（NIST, 2026）。これは意見募集のための草案です。Kaleidr の control list ではありません。このアーキテクチャにおける評価コンテキストは、位置依存の意思決定、すなわち意図、認可、grounding、地理、適格性、ランキング、ツール、アクション、障害処理、ホスト成果です。

エンタープライズ Spatial AI アーキテクチャをリリースゲートにするには？

pilot が本番へ進む前に、所有者を確認します。ワークフローが必要とする箇所でユーザーを認証し、テナント所属はモデル外で解決します。すべての重要フィールドに権威あるソースを持たせ、プライベート retrieval は推論前に行い、フィールドを最小化し、安定 ID を受け渡し後も維持します。地理サービスが、プロダクトが提供するとする計算を実行し、評価で使う tolerance は文書化します。ツールは狭くし、read と write を分離し、引数を検証し、高影響アクションは確認・監査できるようにします。ブラウザとサーバーの認証情報を分離し、scope を限定し、環境を分けます。チームは意思決定チェーンを観測でき、場所選択をホスト成果へ結び付けられる必要があります。利用不可データ、空候補セット、degraded mode を明示し、重要処理は事実を捏造するのではなく fail closed します。Kaleidr Enterprise を見る と、プロダクトがすでに運用するスタックの横で使える spatial intelligence API、ranking、Analytics、SDK surface を確認できます。実装前には、Kaleidr の開発者ドキュメント で Chat、Editor、Tile、Viewer、key、scope の現行 contract を確認してください。

よくある質問

エンタープライズ Spatial AI アーキテクチャとは何ですか？

エンタープライズ Spatial AI アーキテクチャは、言語モデル、地図、地理サービス、業務データ、権限、ツール、アクション、分析を接続し、それぞれの責任をそのルールを強制できるレイヤーに保つシステム設計です。

言語モデルは業務データベースへ直接アクセスすべきですか？

通常、無制限のインターフェースとしては避けるべきです。現在のユーザーを認可し、タスクに必要な最小限のレコードを取得し、フィールドを構造化されたまま保持し、狭いツールを公開します。自由なデータベースアクセスはモデルを権限エンジンにしてしまいます。

言語モデルは何を担当すべきですか？

モデルは、自然言語の意図、承認済み能力間のオーケストレーション、根拠付けられた結果の説明に適しています。認可、取引、業務上の真実、地理計算は、それらの目的に設計されたシステムに残します。

プラットフォーム認証とユーザー認可の違いは何ですか？

プラットフォーム認証は、アプリケーションがプラットフォーム機能を使えることを確認します。ユーザー認可は、どの人またはテナントがレコードへアクセスしたり、業務アクションを実行したりできるかを決めます。一方のチェックで他方を代替できません。

Spatial AI は retrieval-augmented generation を使うべきですか？

retrieval は関連文書やレコードを提供できます。しかし retrieval だけでは authority は確立されません。在庫、可用性、価格、権限、サービスエリア所属は、system of record と決定論的なルールに結び付けたままにすべきです。

Spatial AI のツールはどう保護すべきですか？

狭い関数、最小権限、ユーザーコンテキストでの認可、引数検証、rate limit、監視、高影響アクションへの独立承認を使います。モデルや system prompt を認可メカニズムとして扱ってはいけません。

Spatial AI のアクションには人の承認が必要ですか？

承認は影響度に応じます。場所表示のような低リスクの地図アクションは自動実行できる場合があります。購入、予約、配車、管理上の書き込み、権限変更は明示確認または別承認を必要とする場合があります。

地図アシスタントは現在の地図をどう利用すべきですか？

viewport bounds、選択された place ID、active filter、表示中 result ID、route ID、タスクに必要な精度の位置情報など、構造化状態を渡します。構造化状態が存在するのに、スクリーンショットからアプリケーション状態を推測させるべきではありません。

Spatial AI は既存の地図と連携できますか？

はい。Spatial AI レイヤーは、ホストがすでに運用している地図とアプリケーションに接続できます。Kaleidr の現行 Chat ドキュメントでは、ホストが運用する Mapbox、MapLibre、Google Maps インスタンスへ conversational Spatial AI を接続する方法を説明しています。

スケール前にチームはアーキテクチャをどう評価すべきですか？

組み上げたワークフロー全体を評価します。意図、認可、grounding、地理計算、適格性、ランキング、説明、ツール、アクション、障害処理、業務成果です。一般的な言語モデル benchmark はこの評価の代わりにはなりません。

参考文献

1. Kaleidr. Grounded Spatial AI for Business Data. https://kaleidr.com/blog/grounded-spatial-ai-business-data
2. Kaleidr. Map API Authentication. https://kaleidr.com/blog/map-api-authentication
3. Kaleidr. Get an API Key. Publishable browser keys and server keys. Accessed September 30, 2026. https://docs.kaleidr.com/get-an-api-key
4. Kaleidr. Introduction. Chat, Editor, Tile, and Viewer in one SDK. Accessed September 30, 2026. https://docs.kaleidr.com/
5. OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
6. OWASP Gen AI Security Project. LLM07:2025 System Prompt Leakage. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/
7. Kaleidr. How to Build a Map-Aware AI Assistant. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
8. National Institute of Standards and Technology. AI Risk Management Framework. Voluntary framework for trustworthiness in design, development, use, and evaluation. Released January 26, 2023. Page states that AI RMF 1.0 is being revised. Accessed September 30, 2026. https://www.nist.gov/itl/ai-risk-management-framework
9. National Institute of Standards and Technology. AI RMF Core. Measure 2.1: test sets, metrics, and details about the tools used during TEVV are documented. Accessed September 30, 2026. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
10. Kaleidr. Map Engagement and Location Analytics. Accessed September 30, 2026. https://kaleidr.com/analytics
11. Kaleidr. Location Intelligence APIs and Map SDK. Accessed September 30, 2026. https://kaleidr.com/enterprise
12. Kaleidr. Chat. Attach AI to a host-run Mapbox, MapLibre, or Google Maps instance. Accessed September 30, 2026. https://docs.kaleidr.com/chat
13. National Institute of Standards and Technology. The TEVV-Athlon Framework for Evaluating AI Systems. NIST AI 200-2, initial public draft. Announced August 7, 2026; comments through October 6, 2026. https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems
14. Kaleidr. Spatial AI Accuracy Evaluation. https://kaleidr.com/blog/spatial-ai-accuracy-evaluation
15. Kaleidr. An Enterprise Spatial AI Pilot Before Scaling. https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling

@misc{kaleidr_grounded_architecture_2026,
  title  = {Grounded Spatial AI for Business Data},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}

@misc{kaleidr_map_api_auth_2026,
  title  = {Map API Authentication},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/map-api-authentication}
}

@misc{kaleidr_get_api_key_2026,
  title  = {Get an API Key},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://docs.kaleidr.com/get-an-api-key}
}

@misc{kaleidr_docs_intro_2026,
  title  = {Introduction},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026. Chat, Editor, Tile, and Viewer},
  url    = {https://docs.kaleidr.com/}
}

@misc{owasp_llm06_2025,
  title  = {LLM06:2025 Excessive Agency},
  author = {{OWASP Gen AI Security Project}},
  year   = {2025},
  note   = {Accessed September 30, 2026},
  url    = {https://genai.owasp.org/llmrisk/llm062025-excessive-agency/}
}

@misc{owasp_llm07_2025,
  title  = {LLM07:2025 System Prompt Leakage},
  author = {{OWASP Gen AI Security Project}},
  year   = {2025},
  note   = {Accessed September 30, 2026},
  url    = {https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/}
}

@misc{kaleidr_map_aware_2026,
  title  = {How to Build a Map-Aware AI Assistant},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant}
}

@misc{nist_ai_rmf_2023,
  title  = {AI Risk Management Framework},
  author = {{National Institute of Standards and Technology}},
  year   = {2023},
  note   = {Released January 26, 2023. Accessed September 30, 2026. Page states AI RMF 1.0 is being revised},
  url    = {https://www.nist.gov/itl/ai-risk-management-framework}
}

@misc{nist_ai_rmf_core_2023,
  title  = {AI RMF Core},
  author = {{National Institute of Standards and Technology}},
  year   = {2023},
  note   = {Measure 2.1. Accessed September 30, 2026},
  url    = {https://airc.nist.gov/airmf-resources/airmf/5-sec-core/}
}

@misc{kaleidr_analytics_architecture_2026,
  title  = {Map Engagement and Location Analytics},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://kaleidr.com/analytics}
}

@misc{kaleidr_enterprise_architecture_2026,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{kaleidr_chat_docs_2026,
  title  = {Chat},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://docs.kaleidr.com/chat}
}

@techreport{nist_ai_200_2_2026,
  title       = {The TEVV-Athlon Framework for Evaluating AI Systems},
  author      = {{National Institute of Standards and Technology}},
  institution = {National Institute of Standards and Technology},
  number      = {NIST AI 200-2},
  year        = {2026},
  note        = {Initial public draft, announced August 7, 2026},
  url         = {https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems}
}