Spatial AI オブザーバビリティ

Spatial AI オブザーバビリティは、位置情報を扱うシステムが、リクエストから認可済みの場所、地理計算、ランキング結果、地図アクション、ホスト側の結果へどのように進むかを追跡します。モデルのレイテンシとトークン数は、呼び出しが完了したことを示せます。しかし、その2つの数値だけでは、その場所が適格だったか、顧客が目的のタスクを完了したかは分かりません。役に立つ記録は意思決定の経路であり、プライベートな位置データを複製せずに結果を説明できる程度に小さく保つ必要があります。

以下では、システムテレメトリと地理的な意思決定を分け、何をトレースすべきか、何をログから除外すべきかを整理します。関連する記事として Spatial AI Accuracy Evaluation と An Enterprise Spatial AI Pilot があります。健全に見えるサービスグラフでも、誤った場所の選択を隠していることがあります。

Spatial AI オブザーバビリティの要点

意思決定をトレースする: 認可、取得、場所の識別、地理、適格性、ランキング、ツール、ホスト側の結果は別々の span として扱います。

コピーではなく ID を保持する: 場所、ルート、ポリシー、モデル、アクションの識別子は、貼り付けたプロンプトより多くを説明できます。

内容を最小化する: 秘密情報、生のプライベートレコード、精密な位置情報は、デフォルトでテレメトリストアに保存しません。

除外数を数える: 各候補が集合から外れた理由がなければ、結果件数だけでは不十分です。

失敗語彙を共通化する: オフラインのテストケースと本番インシデントで同じカテゴリを使用します。

Spatial AI オブザーバビリティとは何か？

顧客は「帰宅途中で、商品がまだ在庫にあり、到着時にも営業している店舗はどこか」と尋ねるかもしれません。その答えは、本人確認、現在の在庫、営業時間、ルート、適格性ルール、ランキングポリシー、地図アクション、そして実際にその人が店舗を選んだかどうかに依存します。モデル呼び出しで終わるトレースでは、トークン数とレイテンシを報告できても、これらすべての段階を見落とし得ます。ここでいうオブザーバビリティとは、すべてのプロンプトを保存することではなく、構造化されたシグナルからチームが意思決定を再構成できることです。

レイテンシ、トークン、エラー、ツール呼び出しに限定された言語モデル監視と、ユーザーから取得、地理、ランキング、検証を経て結果に至る Spatial AI トレースの比較。

左側はモデルだけを単独で監視します。右側は、取得、場所解決、適格性、ランキング、ツール検証、地図アクションの中の1つの span としてモデルを扱います。この分離はオブザーバビリティの設計パターンであり、Kaleidr のベンチマークではありません。

3種類の「真実」を結びつける必要があります。システムの真実は、レイテンシ、エラー、再試行、依存サービスの健全性を扱います。意思決定の真実は、どの場所 ID が認可されたか、どの候補がハードルールで除外されたか、どのルートが実行されたか、どのアクションが検証されたかを扱います。結果の真実は、場所が選ばれたか、ルートが開かれたか、ホスト側のワークフローが完了したかを扱います。最初の種類だけのダッシュボードは平穏に見えても、製品が閉店中の店舗を推奨している可能性があります。地図エンゲージメントだけのダッシュボードは活発に見えても、裏では高コストなツールが再試行を続けているかもしれません。

1つの Spatial AI トレースには何を含めるべきか？

1つのリクエストには、実際に実行された段階を通じて安定した request ID を持たせます。認可ではポリシーのバージョンと許可・拒否結果を記録します。取得では、プライベートな行そのものではなく、ソースと返却レコード件数を記録します。場所解決では候補 ID を記録します。ルーティングでは route ID とステータスを記録します。適格性では、残った候補数と、他の候補が外れた理由を記録します。ランキングでは、ポリシーバージョンと順序付き ID を記録します。モデル span では、プロバイダー、バージョンラベル、トークン数を記録します。ツール検証では、提案されたアクションが拒否されたか実行されたかを記録します。最後のイベントでは、選択された場所と、ホストが報告する場合は完了したワークフローを記録します。

認可、取得、場所解決、ルーティング、適格性、ランキング、モデル、ツール検証、地図実行の子 span を含む、Spatial AI のエンドツーエンドトレースの例。

親 span はリクエストです。子 span は独立して失敗し得る段階をカバーし、最後のマークは「場所が選択された」「ワークフローが完了した」です。図中の所要時間は説明用のトレースであり、Kaleidr の実測レイテンシではありません。

すべてのリクエストにすべての span が必要なわけではありません。「この場所を表示」のようなアクションではランキングを省略できます。サービス推奨ではチェーン全体を使うことがあります。トレースには、どの段階を実行し、どれを省略したかを示すべきです。そうすれば、ルーティング span がないことをルーティング成功と誤認しません。図中のバージョンラベルやカードに記載されたモデル名はメタデータの例であり、Kaleidr のモデルカタログではありません。

トレース、メトリクス、イベント、ログはどう分けるべきか？

トレースは、1つのリクエスト内でどこに時間が使われたかを答えます。メトリクスは、p95 レイテンシ、no-result 率、ツール失敗率など、複数リクエストにわたる率が悪化しているかを答えます。イベントは、候補の除外、場所の選択、アクションの拒否など、ある時点で何が変わったかを示します。ログは、parser warning のように正式なメトリクスにする必要のない診断情報を保持します。これらを混ぜると、高コストなストアがデフォルトの保存先になります。

OpenTelemetry のイベントガイダンスも同じ境界を引いています。所要時間と意味のある境界を持つ処理は span に属します。チェックポイント、状態変更、より長い処理内の時点ベースの結果は event の候補です (OpenTelemetry, 2026)。James Newton-King による 2026年5月14日の記事は、モデル呼び出しやツール活動を含む Generative AI の処理をトレースとして記録し、プロンプト内容とツール引数は機密データを含み得るため、デフォルトではテレメトリから除外されると説明しています (Newton-King, 2026)。この記事で参照したページでは 1.44.0 と表示されていた Semantic Conventions のドキュメントは、トレース、メトリクス、ログの共通名称を定義しています (OpenTelemetry, 2026)。place-result set ID や no-result reason のような空間属性をその隣に置くことはできますが、それらはアプリケーション例であり、OpenTelemetry の公式な空間セマンティック規約ではありません。

テレメトリストアに入れないものは何か？

テレメトリシステムが顧客、位置、業務データの第2コピーになれば、オブザーバビリティは失敗です。デフォルトでは、識別子、バージョン、件数、ステータス、レイテンシ、reason code を記録します。マスキング済みの断片、サンプリングした内容、一般化した地理は条件付きとし、明確な必要性、保持期限、アクセス制御がある場合だけ使います。秘密情報、生のプライベートレコード、制限のない完全なプロンプト、質問に不要な精密座標、アクセストークンは避けます。生の住所の代わりに、市区町村コードや市場コードで運用上の問いに十分答えられることがよくあります。

識別子、バージョン、件数、reason code を優先し、マスキングされた内容を条件付きとし、秘密情報、生レコード、不要な精密位置をテレメトリストアから除外するプライバシー境界。

左列がデフォルトで記録する情報です。中央列には保護策が必要です。右列は、明確な制御で正当化されない限り保存しません。この図はデータ最小化のパターンであり、認証や認定を示すものではありません。

OpenTelemetry の Generative AI 属性レジストリは、retrieval query のテキストに機密情報が含まれる可能性があると警告し、内容を含む複数の属性について、ユーザーデータや個人データを含む可能性が高いと示しています (OpenTelemetry, 2026)。Kaleidr のプライベート位置情報に関するガイダンスでは、モデルがレコードを受け取る前に認可を行い、制限のない内部データベースをアップロードしないよう推奨しています (Kaleidr, 2026)。トレースもその境界を保つべきです。result-set ID について認可が通ったことは記録しても、その検査で許可されたプライベートな行そのものは記録しません。

候補が消えた理由をなぜ記録するのか？

結果件数だけでは、悪い推奨を説明できません。役に立つファネルでは、取得した候補数、認可後に残った候補数、ハードルール適用後に残った候補数を記録します。各除外には reason code が必要です。たとえば、閉店、在庫切れ、サービスエリア外、営業時間不明、未認可、鮮度不明です。理由がなければ、候補が20件から6件に減ったことが、実際には適格性フィルターなのにランキング判断のように見えてしまいます。

取得した24候補が認可済み20件、適格6件へ減少し、閉店、在庫切れ、サービスエリア外、営業時間不明などの除外理由を示す適格性ファネルの例。

図中の件数は説明用のリクエストであり、Kaleidr の測定結果ではありません。サイドカードは候補が集合から外れた理由を示します。本番トレースでは、最終件数だけでなく reason code も保存すべきです。

Kaleidr の grounded Spatial AI ガイダンスも、単なる failure flag ではなく、閉店、在庫切れ、対象エリア外、営業時間不明、未認可といった構造化された no-result reason を推奨しています (Kaleidr, 2026)。正しい no-result は、すべての候補がハードルールに違反したことを意味します。システム障害は、ソースが利用できない、または古すぎて判断できないことを意味します。この2つは別のアラートが必要です。重要な制約を黙って緩和すると、正しい空集合が誤った推奨に変わります。

ツール呼び出しはどうトレースすべきか？

モデルはツール呼び出しを提案できます。しかし、提案は承認ではなく、承認は実行ではなく、実行は業務アクションの完了ではありません。ツール名、schema validation の結果、認可判断、ポリシーチェック、実行ステータス、レイテンシ、失敗理由を記録します。拒否経路も成功経路と同じくらい重要です。無効な引数、未認可の呼び出し元、ポリシーによるブロック、実行エラーなどがあります。完了した予約などのホスト側の結果は、取引を所有するシステムに残します。

モデル提案から schema validation、認可、ポリシーチェック、実行を経て結果に至り、各ゲートに拒否出口があるツールオブザーバビリティのフロー。

各ゲートは実行前に呼び出しを停止できます。最後に問うべきことは、ツールが payload を返したかではなく、ホスト側の仕事が完了したかです。ステータスチップはアーキテクチャの概念図であり、Kaleidr の固定権限リストではありません。

地図アクションも同じパターンに属します。場所表示、bounds 調整、ルート描画はセマンティックなアクションです。renderer と通信する adapter は、executed または rejected のイベントを出すべきです。ピンが表示された事実をモデル span だけに依存してはいけません。アシスタントが、地図に一度も表示されなかった場所を説明した場合、トレースでその不一致を可視化すべきです。

本番の挙動を場所ごとにどう読むべきか？

全体平均はローカルな失敗を隠します。市場、言語、データソース、タスク種類、システムバージョンごとに品質を分け、質問に答えられる範囲で最も粗い地理粒度を使います。市区町村コードや市場 ID で十分なことが多く、ある地域で空集合が増えている、特定のルーティングプロバイダーが失敗している、といったことを見るために精密な端末座標は不要です。新市場、場所データプロバイダーの変更、新しい言語、ユーザー質問の変化はいずれも drift の形であり、モデル drift はその1つにすぎません。

NIST Measure 2.4 は、環境の変化に伴って新たな問題やリスクが生じ得るため、AI システムとその構成要素の機能と挙動を本番で監視するとしています。同ページはこの効果を drift と呼び、drift とはシステムが当初の設計前提や制約を満たさなくなることだと説明しています。推奨アクションの1つは、本番で観測されたメトリクスが、デプロイ前テストで収集した同じメトリクスとどう異なるかを文書化することです (NIST, 2026)。同ページは AI RMF 1.0 が更新中であり、その改訂後に playbook も更新されるとしています。このページは何を監視するかの背景情報であり、Kaleidr のコントロールリストではありません。

評価と本番運用はどうつながるか？

オフライン評価は、既知の正解を持つ統制されたケースでシステムがどう動くかを問います。本番監視は、実ユーザー、リアルタイムデータ、実際の地理環境でどう動くかを問います。両者は、解釈、grounding、空間計算、ランキング、アクション、リカバリといった失敗カテゴリを共有すべきです。そうすれば、本番インシデントがテストケースになり、ベンチマークの回帰がローンチ後に本番ダッシュボードで検知できるものになります。Kaleidr の精度ガイドも、単一のモデルスコアではなく、この意思決定チェーンを評価しています (Kaleidr, 2026)。

オフライン評価と本番オブザーバビリティを共通の失敗語彙で結び、本番インシデントをテストに、テストを将来のリリース保護に変えるループ。

評価はケース、ground truth、回帰スイートを提供します。本番は実際のリクエスト、インシデント、drift、結果を提供します。中央の共通カテゴリが両者の契約になります。このループは方法論であり、Kaleidr の公表スコアではありません。

Kaleidr Analytics はどこに位置づくか？

Kaleidr Analytics は現在、リーチ、ビュー、エンゲージメント、オーディエンスの位置と活動、地図ごとのセッション・ビュー・インタラクション、場所比較、空間パターンのダッシュボードを説明しています (Kaleidr, 2026)。これらのシグナルは、人々が地図や場所をどう利用しているかを示しますが、認可、取得、ルーティング、モデル呼び出し、ホスト取引の分散トレースではありません。ホストは、プライベートサービスや、予約、購入、その他の結果を記録するシステムの instrumentation を続ける必要があります。安定した map ID、place ID、workflow ID があれば、すべての内部レコードを Analytics 層にコピーせずに両者を結び付けられます。

安定した map、place、workflow ID を使って、Kaleidr の地図エンゲージメントとホスト側の認可、業務システム、取引結果を結ぶホストオブザーバビリティアーキテクチャ。

Analytics は文書化された地図・場所エンゲージメントを扱います。ホスト列はプライベートトレースと取引結果を扱います。結合キーは識別子であり、予約・購入のチップはホスト側レコードです。Kaleidr Analytics がこれらの取引を保存するという意味ではありません。

Kaleidr Enterprise は、プロダクトチームがホストスタックの横に追加できる Spatial Intelligence レイヤーで、inference APIs、ランキング、Analytics などを含みます (Kaleidr, 2026)。地図やアシスタントのシグナルだけでは、ホストが所有する結果や財務部門が承認した単位価値の代わりにはなりません。Kaleidr の ROI ガイドはこの分離を明確にしており、先行シグナルは経路を説明し、ホスト側レコードが価値を保持します (Kaleidr, 2026)。

Spatial AI オブザーバビリティをリリースゲートにするには？

位置情報ワークフローをスケールする前に、チームはトレースだけから短い質問一覧に答えられるべきです。どのポリシーバージョンがレコードを認可したか。どの place ID を取得し、どの reason code が残りを除外したか。どのルートとランキングポリシーが実行されたか。どのモデルとツールのバージョンが有効だったか。どの地図アクションが実行され、ホスト側の仕事は完了したか。機密内容は最小化し、バージョンは記録し、本番インシデントはオフラインスイートと同じ失敗語彙に分類すべきです。Kaleidr Analytics を見る と、文書化された地図・場所エンゲージメントを確認できます。Kaleidr Enterprise を見る と、ユーザー、データ、結果を既に所有するシステムの横に空間機能を追加できます。

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

よくある質問

Spatial AI オブザーバビリティは言語モデル監視と同じですか？

いいえ。モデルのレイテンシ、トークン、ツールエラーは1つの span をカバーするだけです。場所の識別、権限、業務データ、地理サービス、ランキング、地図状態、ホスト側の結果はすべて、結果が正しかったかどうかを左右します。

ユーザーのプロンプトはログに保存すべきですか？

明確な必要性、保持期限、アクセス制御がある場合だけ記録します。位置関連のリクエストには、トレース全体に保存する必要のない個人住所や業務上の事実が含まれることがあります。

ユーザーの精密な位置をトレースに保存すべきですか？

市場コード、place ID、route ID など、運用上の問いに答えられる最も粗い地理情報を使います。

監視と評価の違いは何ですか？

監視は本番の実挙動を見ます。評価は定義済みケースを ground truth と比較します。強いプログラムは共通の失敗語彙を使い、インシデントをテストに変え、回帰をローンチ後にも見つけられるようにします。

最も重要なメトリクスは何ですか？

万能なメトリクスはありません。適格結果の品質、場所解決、no-result の正しさ、ルート成功、認可の正しさ、タスク完了など、仕事に結び付けて測ります。

ツール呼び出しはどうトレースすべきですか？

ツール名、schema validation、認可、ポリシー結果、実行ステータス、レイテンシ、失敗理由を記録します。提案されたアクション、実行されたアクション、完了したホスト側の結果を分けて扱います。

Kaleidr Analytics はアプリケーションのオブザーバビリティを置き換えますか？

いいえ。公開 Analytics ページは、地図・場所エンゲージメント、セッション、ビュー、インタラクション、オーディエンス活動、空間パターンを説明しています。プライベートサービスのトレース、内部認可、取引結果は、特定の統合が別途示さない限りホスト側に残ります。

OpenTelemetry は Spatial AI に使えますか？

はい。OpenTelemetry は、トレース、メトリクス、ログ、イベント、現在の Generative AI 規約の実用的な基盤になります。共有規約にまだ名称がない場合、チームは place ID、route ID、適格性、ランキング、地図アクション、no-result reason などの属性を文書化して追加できます。

参考文献

Kaleidr. Spatial AI Accuracy Evaluation. https://kaleidr.com/blog/spatial-ai-accuracy-evaluation
Kaleidr. An Enterprise Spatial AI Pilot Before Scaling. https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling
OpenTelemetry. Semantic Conventions for Events. Operations with a duration belong in spans. Checkpoints and point-in-time outcomes are event candidates. Accessed October 1, 2026. https://opentelemetry.io/docs/specs/semconv/general/events/
OpenTelemetry. Inside the LLM Call: GenAI Observability with OpenTelemetry. James Newton-King, May 14, 2026. https://opentelemetry.io/blog/2026/genai-observability/
OpenTelemetry. Semantic Conventions. Documentation labeled 1.44.0. Accessed October 1, 2026. https://opentelemetry.io/docs/specs/semconv/
OpenTelemetry. Generative AI Semantic Convention Attributes. Registry warns that retrieval query text may contain sensitive information. Accessed October 1, 2026. https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/
Kaleidr. Private Location Data for AI Map Workflows. https://kaleidr.com/blog/private-location-data-for-ai-map-workflows
Kaleidr. Grounded Spatial AI for Business Data. https://kaleidr.com/blog/grounded-spatial-ai-business-data
National Institute of Standards and Technology. AI RMF Playbook, Measure. Production monitoring, drift, and the difference from pre-deployment testing. Notes that the AI RMF 1.0 is being updated and that the playbook will be revised afterward. Accessed October 1, 2026. https://airc.nist.gov/airmf-resources/playbook/measure/
Kaleidr. Map Engagement and Location Analytics. Accessed October 1, 2026. https://kaleidr.com/analytics
Kaleidr. Location Intelligence APIs and Map SDK. Accessed October 1, 2026. https://kaleidr.com/enterprise
Kaleidr. Spatial AI ROI Business Case. https://kaleidr.com/blog/spatial-ai-roi-business-case

@misc{kaleidr_accuracy_observability_2026,
  title  = {Spatial AI Accuracy Evaluation},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-ai-accuracy-evaluation}
}

@misc{kaleidr_pilot_observability_2026,
  title  = {An Enterprise Spatial AI Pilot Before Scaling},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling}
}

@misc{otel_events_2026,
  title  = {Semantic Conventions for Events},
  author = {{OpenTelemetry}},
  year   = {2026},
  note   = {Accessed October 1, 2026},
  url    = {https://opentelemetry.io/docs/specs/semconv/general/events/}
}

@misc{otel_genai_observability_2026,
  title  = {Inside the LLM Call: GenAI Observability with OpenTelemetry},
  author = {Newton-King, James},
  year   = {2026},
  note   = {May 14, 2026},
  url    = {https://opentelemetry.io/blog/2026/genai-observability/}
}

@misc{otel_semconv_2026,
  title  = {Semantic Conventions},
  author = {{OpenTelemetry}},
  year   = {2026},
  note   = {Documentation labeled 1.44.0. Accessed October 1, 2026},
  url    = {https://opentelemetry.io/docs/specs/semconv/}
}

@misc{otel_genai_attributes_2026,
  title  = {Generative AI Semantic Convention Attributes},
  author = {{OpenTelemetry}},
  year   = {2026},
  note   = {Accessed October 1, 2026},
  url    = {https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/}
}

@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_grounded_observability_2026,
  title  = {Grounded Spatial AI for Business Data},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}

@misc{nist_rmf_playbook_measure_2026,
  title  = {AI RMF Playbook, Measure},
  author = {{National Institute of Standards and Technology}},
  year   = {2026},
  note   = {Accessed October 1, 2026. Page states the playbook will be updated after the AI RMF revision},
  url    = {https://airc.nist.gov/airmf-resources/playbook/measure/}
}

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

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

@misc{kaleidr_roi_observability_2026,
  title  = {Spatial AI ROI Business Case},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-ai-roi-business-case}
}