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

Spatial AIのための位置データガバナンス

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

Spatial AIのマップを位置データガバナンスの管理項目が取り囲み、目的、分類、精度、許可、認可、リネージ、AI境界、保持、分析、削除、レビューをカバーしている。

位置データガバナンスは、Spatial AI製品がどの地理的事実を収集できるか、どの精度でどの目的に使うか、誰が閲覧できるか、各コピーをどれだけ保持するか、どの分析経路またはモデル経路に渡してよいかを決めます。ブラウザーのプロンプトが答えるのは、そのオリジンがデバイス位置を読み取ってよいかどうかだけです。運用設計は、その後に生じるすべてのコピーを対象にします。

以下では、位置に関する事実を分類し、仕事ごとに必要最低限の精度を定め、ブラウザーのプロンプトとその後の利用を分けます。インベントリ、リネージ、アクセス制御は、モデルが非公開レコードを見る前に行います。そのうえで、保持、削除、分析にはそれぞれ独自のルールを設けます。Kaleidrは、すでにID、ポリシー、トランザクションを所有しているホストシステムの横に位置します。

位置データガバナンスの要点

  • 仕事から始める: 座標、場所、地域を選ぶ前に、なぜその位置フィールドが存在するのかを明確にします。
  • コピーする前に分類する: 公共の場所、非公開の業務レコード、デバイス位置、移動、推論は同じルールでは扱えません。
  • 機能する最小限の精度にする: ライブ運用で場所や住所が必要でも、分析は粗い粒度のままでよい場合があります。
  • 取得前に認可する: プラットフォームの資格情報はエンドユーザー権限ではなく、モデルが見た後で行を隠しても手遅れです。
  • 削除を伝播として扱う: キャッシュ、インデックス、エクスポート、テレメトリ、プロバイダーには削除の経路が必要で、バックアップは独自の保持ルールに従います。

位置データガバナンスとは何か？

位置データガバナンスとは、地理的事実をなぜ収集したのか、どれだけ正確である必要があるのか、誰が利用できるのか、どのシステムがコピーを受け取れるのか、そのコピーがいつ終了するのかを決める一連の管理策です。その事実は、選択された店舗、入力された住所、デバイス座標、ルート、サービスエリア、あるいは推定されるホームマーケットのような推論かもしれません。ガバナンスは、マップ全体を1つの塊として扱うのではなく、フィールドと目的に対して働きます。ベースマップのピンと顧客の非公開な出発地点が同じ画面に表示されても、それぞれ別のルールに従えます。

カバー図は、1つのマップワークフローの周囲に、目的、分類、精度、許可、認可、リネージ、AI境界、保持、分析、削除、インシデント対応、レビューという管理項目を配置しています。図中の吹き出しは例示として扱ってください。サンプルの場所ID、50メートル精度の線、移動時間の短縮は例示ラベルであり、Kaleidrで測定された結果ではありません。優れたプログラムは、マップが何と答えたかだけでなく、なぜその位置をそこに置くことが許されたのかを説明できます。

プライバシー、セキュリティ、AIガバナンスをどう区別するか？

プライバシー、セキュリティ、データ管理、AIガバナンスは位置レコード上で交差しますが、どれか1つが他を代替することはありません。プライバシーは人へのリスクと適切な利用を問います。セキュリティは誰がレコードにアクセスできるか、レコードの完全性が保たれるかを問います。データ管理はID、品質、リネージ、ライフサイクルを扱います。AIガバナンスは、どのモデル、ツール、プロバイダーが最小化されたコンテキストを見られるか、その利用をどう評価するかを問います。ロックされたデータベースでも仕事に対して精度が不適切なことはあり、プライバシー通知があっても、誰もインベントリ化していないコピーをモデルプロバイダーが保持している可能性があります。

プライバシー、セキュリティ、データ管理、AIガバナンスの中心に位置データガバナンスを置いた図。

この図は位置レコードをプライバシー、セキュリティ、データ管理、AIガバナンスの間に配置しています。プライバシーは人へのリスクと適切な利用を、セキュリティは不正アクセスと完全性を、データ管理はID、品質、リネージ、ライフサイクルを扱い、AIガバナンスはモデル、ツール、プロバイダー、評価を扱います。

NISTはAI Risk Management Frameworkを、AI製品、サービス、システムの設計、開発、利用、評価に信頼性の考慮を組み込む能力を高めるための任意利用のフレームワークとして説明しています。同じページには、このフレームワークが2023年1月26日に公開されたとあります (NIST, 2023)。このフレームワークは位置データに関する法律ではなく、マップ製品の精度や保持期間を決めるものでもありません。モデル利用、プロバイダー、評価も、収集と同じレビューに含めるべきだというリマインダーとして使ってください。地理に関するルールそのものは、製品向けに別途記述する必要があります。

どの位置情報にクラス分けが必要か？

誰が見られるかを決める前に、位置を分類します。店舗、空港、公園のような公共の場所は、非公開の事業所、倉庫、制限施設と同じレコードではありません。ユーザーが入力または選択した場所は、ブラウザーやスマートフォンから得たデバイス座標と同じレコードではありません。ルートや繰り返し使われる出発地点のような移動は、各点が普通に見えてもパターンを明らかにすることがあります。推定ホームマーケットのような推定位置は派生した主張です。車両、インシデント、場所別在庫のような運用状態は、地理に結び付いた業務上の事実です。

7つの位置クラス：公共の場所、非公開の事業、ユーザー提供の場所、デバイス位置、移動、推定位置、運用状態。

7つのクラスは、公共の場所、非公開の事業、ユーザー提供の場所、デバイス位置、移動、推定位置、運用状態です。公園と倉庫には同じ管理策を適用しません。入力された住所とデバイス座標も同様です。文脈によって要件は変わり、図中のサンプル住所は例示です。

1つのマップに複数のクラスが同時に存在することがあります。店舗検索では、同じ回答の中に公共の店舗、ユーザーが選んだ出発地点、非公開の在庫フラグが表示されることがあります。ガバナンスでは画面全体に1つのラベルを貼るのではなく、各フィールドを明示すべきです。組み合わせは機微性を高めます。正確な座標に時刻とアカウントを組み合わせると、いずれのフィールド単独では表せない訪問を記述できる場合があります。クラス名だけから、個人情報・非個人情報のような普遍的な法的ラベルを付けないでください。その判断は依然として法域、契約、目的によって決まり、このガイドは法的助言ではなく運用フレームワークです。

仕事ごとにどの程度の精度が必要か？

明示した仕事を完了できる範囲で、最も粗い表現を使います。地域、市、郵便エリアで市場ビューを支えられる場合があります。近隣地域やサービスエリアで店舗選択やルート比較を支えられる場合があります。場所ID、住所、正確な座標は、ライブ運用、フルフィルメント、またはその詳細なしでは成立しない現地体験で必要になります。天気、市単位のキャンペーン、地域需要チャートが屋根の位置まで必要とすることはほとんどありません。緊急派遣やカーブサイド受け渡しでは必要な場合があります。精度は管理策であり、利用可能な中で最も精密なセンサーを使うための勲章ではありません。

地域、市、郵便エリアから、近隣地域、サービスエリアを経て、場所、住所、正確な座標へ進む精度の階段。

この階段は地域と市から、場所、住所、正確な座標へ進みます。分析は多くの場合、粗い粒度のままで構いません。店舗選択では近隣地域やサービスエリアを利用できます。ライブ運用では場所ID、住所、座標が必要になる場合があり、図中の緯度サンプルはKaleidrの結果ではありません。

入力された住所、選択された店舗、アクティブな物件だけで、デバイスを読み取らずに多くの仕事を完了できます。後から修正するときに生の緯度・経度の一致に依存しないよう、座標には必ず標準化された場所IDまたはアセットIDを併記してください。この階段のレベルは普遍的な機微性カテゴリではありません。ある文脈では市レベルが機微であり、別の文脈では目的、利用者、保持条件が明確なら正確な座標が適切な場合もあります。リスクを増やすだけで判断を変えない精度は落とします。

ブラウザーのプロンプトはその後のすべての利用を統制するか？

ブラウザーの位置情報プロンプトが答えるのは狭い問いです。このオリジンはデバイス位置を受け取ってよいか。2026年3月24日のW3C Geolocation Recommendationは、位置情報を強力な機能と位置付け、位置データがWebアプリケーションと共有される前に明示的な許可が必要だとしています (W3C, 2026)。同勧告は、受領者は必要なときにのみ位置情報を要求し、提供された目的のタスクにだけ利用すべきだとも述べています。ユーザーが保持を明示的に許可していない限り、タスク完了後には破棄し、保存された位置情報を不正アクセスから保護する必要があります。保存する場合、ユーザーが更新・削除できるようにし、ユーザーの明示的な許可なしに再送信すべきではありません。

左側にブラウザーの位置情報プロンプト、右側に保持、共有、AI利用、CRM結合、分析、学習、削除に関する組織上の問いを示した図。

左側は、オリジンがデバイス位置を受け取ることを許可するブラウザープロンプトです。右側には、保持、共有、モデル利用、CRM結合、分析、学習、削除に関する後続の選択肢があります。ブラウザーの許可はこれらの判断には答えません。出典行は2026年3月24日のW3C Geolocation Recommendationを引用しています。

こうしたプラットフォームのシグナルは、組織が座標を1年間保持してよいか、CRMレコードに結合してよいか、モデルプロバイダーに送ってよいか、広告に使ってよいか、別の従業員に開示してよいか、モデル学習に使ってよいかを決めません。これらの判断にはそれぞれ製品上の目的、契約、その導入に適用されるルールが必要です。プロンプトは1つの技術的ゲートとして扱います。ユーザーが「許可」を押した後に存在するコピーについては、インベントリ、保持スケジュール、プロバイダー一覧で引き続き明示する必要があります。

正確な位置に特別な注意が必要なのはいつか？

正確な位置は、個人の活動に結び付いた移動や訪問を明らかにするとき、より機微になります。2026年5月4日、Federal Trade Commissionは、数億台のモバイルデバイスから得た位置データを販売し、個人の移動追跡に利用できる状態にしていたとの申し立てを解決するため、データブローカーKochavaとその子会社に対し、消費者の明示的な積極的同意なしにセンシティブな位置データを販売、共有、開示することを禁止すると発表しました (FTC, 2026)。これはデータブローカーに関する事案です。顧客が選択した店舗を中心に地図を表示するすべてのファーストパーティ製品に適用される普遍的なルールだと解釈しないでください。

それでも、この慎重さは設計レビューに含めるべきです。ワークフローに座標が必要なのか、場所IDで足りるのか、あるいはホストがすでに計算した移動時間だけでよいのかを確認します。第三者が転送データを保持できるのか、別目的で利用できるのか、後の削除を拒否できるのかも確認します。移動分数やルート迂回量のような派生値なら、顧客の正確な出発地点を送らずに説明を支えられる場合があります。置き換えは管理策です。「注意する」というポリシー文は、ペイロードが変わるまでは管理策ではありません。

位置インベントリには何を記録すべきか？

インベントリには、スライドで収集したいと考えたフィールドではなく、製品が実際に保持しているすべての位置フィールドを記載します。各フィールドについて、クラス、目的、ソースシステム、標準ID、必要な精度、存在するコピー、ルールを変更できる責任者を記録します。コピーには、プライマリストア、キャッシュ、検索インデックス、エクスポート、prompt、embedding、分析テーブル、プロバイダーログが含まれます。目的のないフィールドは削除候補です。2つの目的を持つフィールドは両方を明記する必要があります。不正検知とマーケティング集計は1つの判断ではないからです。

ポリシー文書が再公開されたときだけでなく、製品が変わったときにインベントリを見直します。新しいモデルツール、新しい分析チャート、新しいコネクターによって、前回のレビューでは存在しなかったコピーが生まれることがあります。promptとembeddingは、誰もデータベースと呼ばなくても位置コンテキストのコピーです。ここでも統合境界が重要です。データ統合ガイドは、各運用上の事実を所有するシステムに残し、回答で一部の行を隠したとしても、すべての非公開レコードを空間結合した時点で開示が発生するとしています (Kaleidr, 2026)。ソースのように見えたテーブルだけでなく、結合そのものをインベントリ化してください。

位置をソースから分析まで追跡できるか？

ガバナンス対象のレコードは、入力からマップ、集計まで追跡できる必要があります。経路は、入力された住所、デバイス座標、業務マスターなど信頼できるソースから始まります。正規化によって、それらの入力を標準の場所IDまたはアセットIDに解決し、重複を除きます。その後、空間変換によって、ジオコード、ルート、地域など、仕事に必要な表現を生成します。この段階を経てから、生の出発地点ではなく派生フィールドを含む最小化されたコンテキストをモデルへ渡します。マップ結果と分析抽出は最後に来て、分析抽出にはチャートが実際に必要とする粗い地理だけを含めるべきです。

入力された住所、デバイス座標、業務マスターから、標準ID、空間変換、最小化されたモデルコンテキスト、マップ結果、分析へ至るリネージ。

経路は、入力された住所、デバイス座標、業務マスターから標準の場所IDまたはアセットIDへ進みます。その後、空間変換によってジオコード、ルート、地域を生成し、最小化されたコンテキストがマップと分析に届きます。図中のサンプルID、座標、精度ラベルは例示です。本番レコードは、ソース、観測時刻、変換バージョン、精度、リネージIDを保持すべきです。

メタデータをレコードとともに保持します。ソースID、観測時刻、変換バージョン、使用した精度、リネージIDです。そうすれば、後の修正で、古い座標に依存したままのすべての派生コピーを見つけられます。「不明」は「偽」とは別の状態です。観測時刻がないことは、その場所が最新である証拠ではありません。再現可能な変換とバージョン管理されたエンリッチメントによって説明可能性が生まれます。ソース行のない座標が分析に現れたら、そのレコードはチームがもはや正当化できません。

なぜアクセス制御をAIコンテキストより先に行う必要があるのか？

非公開の空間レコードが計算やモデルに届く前に、ユーザー、tenant、ロール、オブジェクト、フィールドを解決します。正しい経路では、許可された場所を先にフィルタリングし、その集合だけで空間処理を行います。ブロックすべき経路では、非公開データセット全体を送信し、モデルがすでに受け取った後でユーザーに見せてはいけない行を隠そうとします。隠すことは認可ではありません。AIマップの非公開位置ガイドでも同じ順序を明記しています。認証し、認可し、その後で最小化されたスライスを取得し、制限のない内部データベースをアップロードしないことです (Kaleidr, 2026)。

ユーザー、tenant、ロール、オブジェクト、フィールドから空間計算へ進む正しい経路と、非公開データセット全体をモデルに送って後から行を隠そうとするブロックすべき経路。

正しい経路では、非公開位置が計算やモデルに届く前に、ユーザー、tenant、ロール、オブジェクト、フィールドを確認します。ブロックすべき経路では、非公開データセット全体を送り、その後で行を隠そうとします。この順序自体が失敗です。認可は取得より前に行うべきで、モデルが行を見た後ではありません。

プラットフォーム資格情報は統合を識別します。エンドユーザー権限は、その人がどのtenant、オブジェクト、フィールドを利用できるかを識別します。これは別々の確認であり、有効な組織キーがあるからといって、顧客Aが顧客Bの店舗、アセット、出発地点を読む権利を得るわけではありません。キャッシュやretrieval storeにも、プライマリクエリと同じtenant境界が必要です。クロステナントの失敗を意図的にテストしてください。ログイン中の1人のユーザーには正しく見えるマップでも、共有cache keyを通じて別の顧客のレコードを漏らしている可能性があります。

各位置コピーをどのくらい保持すべきか？

保持期間は目的に従います。1つの共通日数では、リクエスト中だけ使う出発地点、アカウントに保存した場所、車両やインシデントの履歴、市場レベルの分析抽出を同時に扱えません。リクエスト限定の座標はリクエスト終了時に消せます。アカウントに紐づく場所は、その機能またはアカウントが有効な間保持できます。運用状態は、イベント終了後も安全、サポート、契約記録のために現在値とガバナンスされた履歴を保持する場合があります。分析は、分析ポリシーに従って精度を落とし、集約または非識別化したデータをライブ座標より長く保持できる場合があります。

リクエスト限定、アカウント連携、運用状態、集約分析という4つの保持パターンと、それぞれのライフサイクル。

保持は仕事に従い、1つの共通日数には従いません。リクエスト限定の出発地点はリクエスト終了時に期限切れにできます。アカウント連携の場所は機能とともに保持でき、運用状態はイベント終了後もガバナンスされた履歴を保持できます。分析はより粗い地理を長く保持でき、具体的な期間は組織ごとに異なります。

製品がその瞬間に必要とする位置と、分析が保持する位置を分けてください。ライブの引き渡しには住所が必要な場合があります。リーチ、セッション、場所エンゲージメントのダッシュボードには、市場、市、商圏で十分な場合が多いです。この分離を文書化し、製品が一度だけ使った屋根レベルの位置をチャートが黙って保存しないようにします。具体的な期間は組織と文脈に依存します。図は4つのライフサイクルの形を示すものであり、そのままポリシーへ貼り付けられる保持スケジュールではありません。

位置レコードを削除するとき、何を動かす必要があるか？

削除は伝播のワークフローです。レコードの削除または取消し要求は、プライマリストア、メモリ内・エッジキャッシュ、検索インデックス、embeddingを保持するベクターストアへ届く必要があります。分析テーブル、エクスポート、プロバイダーシステムには独自の処理が必要で、削除、ガバナンスされた期限切れ、識別子からの文書化された切り離しなどが考えられます。observability storeも同じレビューが必要です。テレメトリでは、識別子、バージョン、件数、reason codeを優先し、秘密情報、生の非公開レコード、不要な正確座標をそのストアに入れないでください (Kaleidr, 2026)。

中央レコードから、プライマリデータベース、キャッシュ、検索インデックス、ベクターストア、分析、observability、エクスポート、プロバイダーシステム、バックアップのライフサイクルへ削除と取消しが広がる図。

削除または取消しは、プライマリストア、キャッシュ、検索インデックス、ベクターストアに届く必要があります。分析、observability、エクスポート、プロバイダーシステムには、削除、期限切れ、文書化された切り離しなど、それぞれの処理が必要です。バックアップは独自の保持ポリシーに従い、個々のレコードをすぐに削除できない場合があります。この図は伝播マップであり、1つのdeleteコマンドではありません。

バックアップ、スナップショット、アーカイブはバックアップのライフサイクルに従います。すべてのバックアップから個別レコードをオンデマンドで消去できると主張しないでください。削除済みレコードがスナップショットにどれだけ残り得るかを含め、実際のバックアップポリシーを説明します。プロバイダー契約も同じマップに含めます。promptを保持するモデルまたはエンリッチメントプロバイダーは、プライマリ行が消えた後も位置コピーを保持している可能性があります。アクセス取消しは関連しますが、削除と同一ではありません。ロールを失ったユーザーは、古い集計がまだ分析期間内に残っていても、新しいレコードを直ちに受け取れなくなるべきです。

Kaleidrの横で位置データガバナンスをどこに置くべきか？

ID、tenant認可、非公開業務データ、CRM、在庫、予約、保持ポリシー、法務・プライバシー判断、トランザクションはホスト組織内に残します。認可されたレコードがKaleidrのサーフェスへ届く前に、目的、精度、認可、最小化、リネージを適用します。Kaleidr Enterpriseは、最新の空間製品向けに構築されたinference APIs、ranking systems、analyticsを備えるlocation intelligence infrastructureです (Kaleidr, 2026)。開発者ドキュメントでは、Chatをホストマップ内のSpatial AI、Viewerをマップ公開、Tileをデザイン済みベースマップ、Editorを描画・編集として説明しています (Kaleidr, 2026)。Viewerは公開マップをshare idで埋め込み、その埋め込みにpublishable keyは必要ありません (Kaleidr, 2026)。

左にホスト所有のID・業務システム、中央にガバナンス管理、右にKaleidr Enterprise、Chat、Editor、Tile、Viewer、Analyticsを置いた図。

左列はホスト側に残ります。ID、tenant認可、非公開業務データ、CRM、在庫、予約、保持ポリシー、法務・プライバシー判断、トランザクションです。中央は、レコードが境界を越える前にホストが適用する管理策、つまり目的、精度、認可、最小化、リネージを示します。右列は文書化されたKaleidrサーフェス、Enterprise、Chat、Editor、Tile、Viewer、Analyticsを示します。Kaleidrは左列のホストシステムを置き換えません。

ドキュメントでは、バックエンドから使用するserver credentialと、SDKが短時間セッションと交換し、raw bearerとして送信しないpublishable browser credentialを区別しています (Kaleidr, 2026)。どちらもエンドユーザー権限ではなく、server credentialをブラウザーコードに置いてはいけません。Kaleidr Analyticsは、リーチ、ビュー、エンゲージメント、複数マップにわたるオーディエンスの位置と活動、マップごとのセッション、ビュー、インタラクションに加え、クラスター、ギャップ、ルートなどの空間パターンを文書化しています (Kaleidr, 2026)。どのシグナルに細かな位置を持たせてよいか、どれをホストのウェアハウスで粗い粒度に保つべきかを決めてください。この文章から推測するのではなく、導入における契約上の保持と処理条件を確認してください。

Kaleidr Enterpriseを見る と、すでにユーザーとレコードを所有しているシステムの横にspatial intelligenceを追加できます。Kaleidr Analyticsを見る と、ガバナンスレビューが許容する精度の範囲で、文書化されたマップと場所のエンゲージメントを確認できます。両方のページをインベントリと照合し、チャートが必要としない細かな位置はホストシステムに残してください。

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

よくある質問

ブラウザーの位置情報許可は、その後のすべての利用を認可しますか？

いいえ。プロンプトが決めるのは、オリジンがデバイス位置を受け取ってよいかどうかだけです。保持、共有、モデル利用、CRM結合、分析、学習、削除は別々の組織判断です。

分析はライブ製品と同じ精度を保持すべきですか？

デフォルトではありません。ライブの仕事には場所や住所が必要な場合があります。市場チャートであれば、独自の保持ルールのもとで、市、商圏、その他の粗い地理を保持すれば十分なことが多いです。

Kaleidrは企業の位置データガバナンスプログラムを置き換えますか？

いいえ。Kaleidrは、文書化されたSpatial AI、マップ、SDK、API、分析の機能を提供します。特定の契約で別途定めない限り、ユーザー権限、非公開業務システム、分類、保持、法務・プライバシー判断は引き続きホスト組織が所有します。

削除要求はどこまで届く必要がありますか？

コピーを保持するプライマリストア、キャッシュ、検索インデックス、ベクターストア、分析抽出、エクスポート、テレメトリ、プロバイダーシステムです。バックアップは独自のライフサイクルに従うため、個々のレコードをすぐに削除できない場合があります。

References

  1. National Institute of Standards and Technology. AI Risk Management Framework. Intended for voluntary use, to improve trustworthiness considerations in the design, development, use, and evaluation of AI products, services, and systems. Released January 26, 2023. Accessed October 5, 2026. https://www.nist.gov/itl/ai-risk-management-framework
  2. World Wide Web Consortium. Geolocation. W3C Recommendation, March 24, 2026. Express permission before a web application receives device location, with guidance on necessity, purpose, disposal, protection, update, deletion, retransmission, and disclosure. Accessed October 5, 2026. https://www.w3.org/TR/2026/REC-geolocation-20260324/
  3. Federal Trade Commission. FTC to Ban Kochava and Subsidiary from Selling Sensitive Location Data. May 4, 2026. Accessed October 5, 2026. https://www.ftc.gov/news-events/news/press-releases/2026/05/ftc-ban-kochava-subsidiary-selling-sensitive-location-data-settle-charges-they-sold-location-data
  4. Kaleidr. Spatial AI Data Integration. Each operational fact stays with the system that owns it, and a spatial join of private records is already a disclosure. https://kaleidr.com/blog/spatial-ai-data-integration
  5. Kaleidr. Private Location Data for AI Map Workflows. Authorize before retrieval, and do not upload an unrestricted internal database to a map or a language model. https://kaleidr.com/blog/private-location-data-for-ai-map-workflows
  6. Kaleidr. Spatial AI Observability. Prefer identifiers, versions, counts, and reason codes, and keep unneeded precise location out of telemetry. https://kaleidr.com/blog/spatial-ai-observability
  7. Kaleidr. Location Intelligence APIs and Map SDK. Inference APIs, ranking systems, and analytics for spatial products. Accessed October 5, 2026. https://kaleidr.com/enterprise
  8. Kaleidr Developer Docs. Products. Chat is Spatial AI in the host map, Editor is draw and edit, Tile is designed basemaps, and Viewer publishes a map. Accessed October 5, 2026. https://docs.kaleidr.com/
  9. Kaleidr Developer Docs. Viewer. Embeds a published map by its share id, and that embed does not require a publishable key. Accessed October 5, 2026. https://docs.kaleidr.com/viewer
  10. Kaleidr Developer Docs. Auth & Scopes. Distinguishes a backend server credential from a publishable browser credential with a different runtime. Accessed October 5, 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
  11. Kaleidr. Map Engagement and Location Analytics. Reach, views, engagement, audience location and activity, sessions, and spatial patterns. Accessed October 5, 2026. https://kaleidr.com/analytics
@misc{nist_ai_rmf_2023,
  title  = {AI Risk Management Framework},
  author = {{National Institute of Standards and Technology}},
  year   = {2023},
  url    = {https://www.nist.gov/itl/ai-risk-management-framework}
}

@misc{w3c_geolocation_2026,
  title  = {Geolocation},
  author = {{World Wide Web Consortium}},
  year   = {2026},
  url    = {https://www.w3.org/TR/2026/REC-geolocation-20260324/}
}

@misc{ftc_kochava_2026,
  title  = {FTC to Ban Kochava and Subsidiary from Selling Sensitive Location Data},
  author = {{Federal Trade Commission}},
  year   = {2026},
  url    = {https://www.ftc.gov/news-events/news/press-releases/2026/05/ftc-ban-kochava-subsidiary-selling-sensitive-location-data-settle-charges-they-sold-location-data}
}

@misc{kaleidr_data_integration_2026,
  title  = {Spatial AI Data Integration},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-ai-data-integration}
}

@misc{kaleidr_private_location_2026,
  title  = {Private Location Data for AI Map Workflows},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/private-location-data-for-ai-map-workflows}
}

@misc{kaleidr_observability_2026,
  title  = {Spatial AI Observability},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-ai-observability}
}

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

@misc{kaleidr_docs_home_governance_2026,
  title  = {Kaleidr Developer Docs},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/}
}

@misc{kaleidr_docs_viewer_2026,
  title  = {Viewer},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/viewer}
}

@misc{kaleidr_auth_scopes_2026,
  title  = {Auth and Scopes},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

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

関連コンテンツ

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