Spatial Context Engineeringで場所を理解するAI

Spatial Context Engineering は、モデルが回答前に利用できる場所、時刻、ルート、業務上の事実を選定する実践です。プロンプトは最寄りの充電器を尋ねられます。しかし有用な回答には、ルート、現在時刻、そしてホストが共有を選んだ事実だけが必要です。地理は空間サービスが計算し、モデルはその結果を説明します。

Spatial Context Engineering とは何ですか？

2025年のサーベイは1,400本を超える研究論文を整理し、コンテキストエンジニアリングを、プロンプト設計を超えて言語モデルが受け取る情報を体系的に最適化する分野として位置づけています (Mei et al., 2025)。このサーベイは、その作業をコンテキストの検索と生成、コンテキストの処理、コンテキストの管理に分けています。Spatial Context Engineering は同じ考え方を場所に適用します。ペイロードには、対象がどこにいるか、事実がいつ有効だったか、どのルートまたはエリアが重要か、呼び出し元がどの業務レコードを利用できるかを含める必要があります。

コンテキストは多ければ自動的に良いわけではありません。Liu らは、関連情報が入力の先頭または末尾にあるときに言語モデルの性能が最も高くなることが多く、長いコンテキストの中ほどにある情報を使う必要があるときには性能が大きく低下することを示しました (Liu et al., 2024)。そのため空間パケットは小さく保つべきです。対象となる場所、計算済みの距離や包含結果、それらの結果の鮮度、呼び出し元に許可されたアクションです。現在の地図表示の全レイヤーを丸ごと渡す方法は、この基準を満たしません。

実務向けのガイドでも、この用語はすでに使われています。Vercel の開発者向けガイドは、検索、メモリ、圧縮、ツールコンテキストの4つのパターンを挙げています (Vercel, 2026)。地図製品は4つすべてを使いますが、どれも空間計算の代わりにはなりません。検索はポリシーの一節を、メモリは以前の好みを取り込めます。圧縮はカタログの残りを落とせます。ツールコンテキストはルートや包含判定の結果を保持でき、モデルは代わりの数値を作るのではなく、その結果を説明すべきです。

プロンプトとコンテキストはどう違いますか？

プロンプトは質問をします。コンテキストは回答前に組み立てられる証拠です。「配送ルート上で最寄りの充電器を探して」は指示ですが、指示だけでは車両、時刻、実際に通行可能な道路を無視した一般的な充電器一覧が返ることがあります。図では、その薄い回答と、場所、時刻、ルート、業務状態、権限、マップ状態を明示するパケットを対比しています。

左側は短い指示と近くの充電器に関する一般的な回答です。右側は、場所を理解した回答の前に、場所、時刻、ルート、業務状態、権限、マップ状態を追加しています。場所 ID、2024年6月のタイムスタンプ、5.2 km のバッジ、充電器のピンはサンプルラベルです。右のパケットは参照用スケッチであり、Kaleidr のリクエスト形式ではありません。

薄い回答は文法として間違っているわけではありません。しかし運用には使えません。「近く」に起点、最大迂回距離、フリートが利用できる充電器のルールがないからです。図の詳しい側もサンプル識別子を使っているため、それらはライブクエリの値ではありません。本番パケットにはホスト自身の ID と空間サービス自身の数値を入れます。

なぜ検索は情報源の一つにすぎないのですか？

検索は文書、ポリシー、説明、ヘルプ記事から文章を取得します。それらはルールを説明できます。しかし、ある停車地点がサービスエリア内かどうかを配車担当者に示すことはできません。ポリゴン判定は文章ではなく計算だからです。空間コンテキストは取得したテキストを残しつつ、構造化された業務上の事実、認可結果、現在のマップ状態、空間計算結果を追加します。

左列は文書、ポリシーテキスト、説明、ナレッジを文章として取得します。右列はそのテキストに構造化された業務上の事実、認可、マップ状態、空間計算を追加します。図の結果は、場所を理解した回答のための意思決定パケットです。描かれたルートとピンはサンプル図であり、計測された移動ではありません。

取得テキストだけで止まるチームは詳しく見えても、マップについて間違えます。ポリシーには「遅い時間の配送にはスタッフのいる拠点が必要」と書けます。しかし、この拠点が今条件を満たすかを判断できるのは、営業時間フィード、包含判定、呼び出し元の権限です。図の意思決定パケットでそれらが合流します。

なぜ現在の証拠が古いメモリより優先されるべきですか？

メモリは、保存したデポや言語のような期限切れにならない好みに役立ちます。一方、交通、閉鎖、在庫、今日誰が私有拠点を見られるかの情報源としては不適切です。先週記憶した「最適な停車地点」が、空間サービスが今返したルートと矛盾することもあります。両者が食い違う場合は、現在の計算と現在の認可を優先し、メモリは事実ではなく好みとしてラベル付けしたままにします。

同じルールは、セッション前半で作った要約にも当てはまります。圧縮された要約は、閉鎖や取り消された権限を落とす可能性があります。次のターンでは変化するフィールドを読み直すか、タイムスタンプのない要約に基づいて行動することを拒否すべきです。鮮度は「前の回答がまだ正しいはず」という期待ではなく、データとしてパケットに含めます。

なぜ場所の識別が検索より先なのですか？

2つのレコードが同じ名前でも、別の場所であることがあります。「ダウンタウンの店」という検索語は ID ではありません。パケットにはホスト自身のシステムの安定した場所 ID と、空間サービスが使う座標またはジオメトリを含め、表示名はキーではなくラベルとして扱うべきです。その ID がなければ、後のターンで名称変更された店舗と別店舗を区別できず、引用も実際に対象となったレコードを指せません。

パケットにはどのジオメトリを入れるべきですか？

ジオメトリは質問に一致させる必要があります。最寄り充電器の質問にはポイントとルートが必要です。サービスエリアの質問にはポリゴンと包含結果が必要です。回廊の質問には線とその線からの距離が必要です。GeoJSON はジオメトリオブジェクトを定義し、ポイントはその形式のジオメトリ型の一つなので、形状を文章に隠すのではなく、パケットで型を明示できます (IETF, 2016)。判断がポリゴンに依存するのにポイントを送ると、テスト自体が実行されていないのに後の説明だけが精密に見えてしまいます。

なぜビューポートは権限ではないのですか？

場所がカメラ内に見えていても、利用禁止の場合があります。図では一つのビューに3つのサンプル拠点があります。呼び出し元が使える公共店舗2つと、ピンは見えていてもコンテキストから除外される私有施設1つです。可視性はユーザーが何を見ているかの手掛かりです。認可は、リクエストに何を含めてよいかを決める別のチェックです。

破線の枠は現在のマップビューで、その中に3つのサンプル場所があります。Public Store A と Public Store B は認可済みです。Private Facility C はピンが画面に見えていてもモデルコンテキストから除外されます。ビューポートは位置コンテキストを提供し、別の権限チェックが利用可能な内容を決めます。

同じ分離はホストマップにも当てはまります。Kaleidr の開発者ドキュメントによると、Chat は独自のマーカーを追加し、カメラを動かし、ルートを描画しますが、ページのレイヤー、ソース、マーカーを変更せず、それらのオブジェクトを Kaleidr に送りません (Kaleidr, 2026)。画面上のピンは許可ではありません。どの事実が境界を越えるかはホストが決め、パケットはカメラが既に決めたと仮定せず、その判断を記録すべきです。

空間サービスは最初に何を計算すべきですか？

数値は空間サービスに置き、その後モデルに説明させます。図では、ルート迂回、サービスエリア内判定、移動時間が、一つの店舗が適している理由の説明に入ります。別のボックスでは推測した移動時間を却下しています。距離、包含判定、到着予測は道路ネットワーク、ポリゴン、時刻から得るため、モデルはそれらの情報源として不適切です。

空間サービスは6分のルート迂回、真のサービスエリア内判定、14分の移動時間を返します。その後、説明は図の Store 104 が選ばれた停車地点である理由を述べます。却下されたボックスは、サービス結果を使わず言語モデルが移動時間を作る例です。分数、店舗番号、引用された推測値は図上のサンプルラベルです。

説明そのものは有用です。サービスが対象となる停車地点を返した後、モデルは呼び出し元の言語で、どの計算済み事実がその地点を適合させたかを説明できます。説明はサービス結果を置き換えず、その結果を引用すべきです。図の店舗番号や分数バッジはラベルであり、Kaleidr のベンチマークではありません。

コンテキストパケットはどの程度小さくすべきですか？

パケットは読めるほど小さく、判断が隠れたテーブルに依存しない程度に完全であるべきです。図は店舗データベース、在庫、営業時間、ルーティング、権限などの生システムから始まり、短いオブジェクトに終わります。タスク、少数の候補、適格性、ルート迂回、鮮度タイムスタンプ、許可されたアクションです。適格性に影響しなかったものは元のシステムに残せます。

店舗データベース、在庫、営業時間、ルーティング、権限の生レコードがコンテキストビルダーに入ります。ビルダーはタスク、数件の候補店舗、適格性フラグ、ルート迂回、タイムスタンプ、許可されたアクションを含む短いパケットを出します。パケットは確認できるほど小さく、一つの判断に十分なほど完全であることを意図しています。店舗 ID、距離、2024年6月のタイムスタンプはサンプルラベルで、JSON は Kaleidr API ではなく参照スケッチです。

長いコンテキストに関するこの研究結果が、省略する理由です。候補検索は広く始めて絞れます。対象外の場所はモデルに見せる前に落とし、パケットには閉店時間や包含判定失敗などの理由を残します。Kaleidr の公開チャットリクエストはこのスケッチより狭い契約であり、次のセクションで実際に何を運ぶかを示します。プラットフォームがそのオブジェクトを文書化しているかのように、図の JSON を POST してはいけません。

参照パイプラインには何が含まれますか？

実用的なパイプラインは各リスクを所有する段階を明確にします。タスクを解析し、呼び出し元を識別し、認可を確認し、地理的範囲を設定し、候補を取得し、業務状態を付け、空間計算を実行し、適格性を適用し、パケットを組み立て、そのパケットをモデルに送り、マップアクションを実行し、変動フィールドを再検証し、起きたことを記録します。図の上部にはソース、鮮度ルール、ポリシー、トレース ID という4つの管理項目があります。

帯はタスク解析から呼び出し元の識別、認可、地理的範囲、候補の検索、業務状態、空間計算、適格性、コンテキストパケット、モデル、地図アクション、再検証、観測まで続きます。ソース、鮮度、ポリシー、トレース ID が各段階の管理項目として上部に置かれます。この図は独自のコンテキストビルダーを設計するチーム向けの参照パイプラインです。下に描かれたルートはサンプル図です。

この順序は設計補助であり、Kaleidr の製品シーケンスではありません。候補検索と空間計算を統合するチームもあります。見える状態にしておくべき段階は、認可、計算、適格性、そして停車地点の割り当てなどのアクション直前の再検証です。業務データのための根拠に基づく空間AI は、認可、検索、ランキングに関する Kaleidr の関連ガイドです。

Kaleidr はコンテキスト境界をどこに引きますか？

ホストマップでは境界は明示的です。対応地図ガイドは、Kaleidr Chat を Mapbox GL JS、MapLibre GL JS、Google Maps、Leaflet などに接続する方法を扱い、Google Maps キーはページと Google の間に留まり、Kaleidr はそのキーを受け取りません (Kaleidr, 2026)。ピン、場所への移動、ルート線はパネルが追加する描画です。それらはホストの非公開テーブルのコピーではありません。

ホストアプリケーションはユーザー、非公開データ、在庫、ポリシー、カスタムレイヤー、業務アクションを保持します。図で境界を越えるのは、認可済み位置、地図のズーム、セッション、承認済み事実などの明示的な一部だけです。右側の Kaleidr Chat は、その共有された一部から場所を解決し、ルートを計画し、地図アクションを実行します。フッターは図のラベルで、店舗名と車両名はサンプルです。Chat を接続しただけではホストのレイヤーや業務システムは送信されません。

Platform API はチャットリクエストに対応する制限を文書化しています。messages は会話、location オブジェクトは「この近く」を解釈するための地図の中心、map_zoom はズームレベル、lang は回答言語です。同じページは、システム指示、ペルソナ、ツール、呼び出し元独自のコンテキストのためのフィールドはなく、未知のフィールドは受け入れて無視するとしています。app_snapshot と auto_actions は受け入れられますが不要なため、ページは省略するよう案内しています (Kaleidr, 2026)。

アップロード済みの業務データは、そのリクエストとは別の提供形態です。組織独自の業務データを AI 回答用にアップロードすることは Enterprise のみであり、そのアップロードデータを使うキーを使った回答も Enterprise のみだと How Kaleidr works は記載しています。関連ページの 地図を理解するAIアシスタントの作り方 は、同じ境界の周囲にチームが構築するアシスタントを扱います。

同じページを見つけやすく、引用しやすくするには？

この実践を扱うページは引用しやすくあるべきです。図では、その役割を通常の検索、回答エンジン、生成AIによる引用に分けています。検索には正規のフレーズ、関連手法のクラスター、補助ガイドへのリンクが必要です。回答エンジンには直接的な定義、いくつかの具体的な質問、検索と空間パケットの比較のような対比が必要です。

図の中央は Spatial Context Engineering で、その周囲に検索、回答エンジン、生成AIによる引用という3つの面があります。検索は正規キーワード、トピッククラスター、内部リンクを扱います。回答エンジンは直接的な定義、よくある質問、比較を求めます。生成AIによる引用は独自のフレームワーク、説明付きのスキーマ、失敗例の一覧、引用元を求めますが、どのボックスもランキングの保証ではありません。

この図のボックスは執筆用チェックリストであり、トラフィックの保証ではありません。Kaleidr がページを順位付けするわけではなく、図は測定値を報告していません。ページにできることは、定義を一か所で明示し、パケットを通信形式ではなく参照スケッチとして示し、主張が依存する標準とドキュメントを引用することです。そうすれば読者は、どの文が定義で、どの文が製品の制約かを見分けられます。

チームは次に何をすべきですか？

プロンプトを変える前に、一つの実タスク用のパケットを書いてください。場所 ID、時刻、ジオメトリ型、空間計算の結果、それぞれの事実を許可した権限を含めます。その後、そのリストを現在ホストが送れるチャットリクエストと比較します。会話、地図の中心、ズーム、言語であり、ホストの非公開のコンテキストのフィールドはありません。回答にアップロード済み業務データが必要なら、Kaleidr Enterprise から始めてください。

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

よくある質問

Spatial Context Engineering はプロンプトエンジニアリングと同じですか？

いいえ。プロンプトエンジニアリングは指示の文言を変えます。Spatial Context Engineering は、その指示が利用できる証拠を変えます。場所、時刻、ルートまたはエリア、呼び出し元が見られる業務上の事実などです。より良い文章にしても、空間サービスが計算していない包含結果を供給することはできません。

Kaleidr Chat を接続するとホストマップのレイヤーを読みますか？

いいえ。Chat がホストドキュメント内で動くページでは、Chat は独自のマーカーを追加し、カメラを動かし、ルートを描きます。Chat はページのレイヤー、ソース、マーカーを変更せず、それらのオブジェクトを Kaleidr に送りません。アップロード済み業務データを扱う別の Enterprise 提供形態がない限り、非公開テーブルは境界のホスト側に残ります。

公開 Chat リクエストにカスタムコンテキストパケットを含められますか？

文書化されたリクエストが運ぶのは会話、地図の中心用位置、任意のズーム、言語です。システム指示、ペルソナ、ツール、呼び出し元独自のコンテキスト用フィールドはありません。app_snapshot と auto_actions は受け入れられますが不要なので、このガイドで描いたパケットとして扱うべきではありません。未知のフィールドは受け入れられて無視されます。

なぜ移動時間は空間サービスに置くべきですか？

移動時間は道路ネットワークと時刻に依存し、推測した分数はサービスが今計算したルートと矛盾する可能性があります。計算図の却下ボックスは、ライブ結果ではなくサンプルの引用でその失敗モードを示しています。数値は空間サービスに保持し、モデルには説明させてください。

References

1. Mei, L., et al. A Survey of Context Engineering for Large Language Models. A review of more than 1,400 papers that treats context engineering as more than prompt design and splits it into retrieval and generation, processing, and management. arXiv:2507.13334. 2025. https://arxiv.org/abs/2507.13334
2. Liu, N. F., et al. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12, 157–173. Performance is often highest when relevant information is at the start or end of the input and degrades significantly in the middle of long contexts. 2024. https://doi.org/10.1162/tacl_a_00638
3. Vercel. What is context engineering? A developer's guide. A practitioner guide naming four patterns: retrieval, memory, compression, and tool context. Accessed October 22, 2026. https://vercel.com/i/context-engineering
4. IETF. RFC 7946: The GeoJSON Format. GeoJSON defines a geometry object, and a Point is one of the geometry types. 2016. https://www.rfc-editor.org/info/rfc7946
5. Kaleidr Developer Docs. How Kaleidr works. Chat adds its own markers, moves the camera, and draws routes, and does not change the page's layers, sources, or markers or send them to Kaleidr. Uploaded business data for AI answers, and key-backed answers that draw on that data, are Enterprise only. Accessed October 22, 2026. https://docs.kaleidr.com/concepts/how-kaleidr-works
6. Kaleidr. Grounded Spatial AI for Business Data. A related guide covering authorization, retrieval, ranking, evaluation, and a narrow pilot. Accessed October 22, 2026. https://kaleidr.com/blog/grounded-spatial-ai-business-data
7. Kaleidr Developer Docs. Supported maps. Attach targets include Mapbox GL JS, MapLibre GL JS, Google Maps, and Leaflet. A Google Maps key stays between the page and Google; Kaleidr does not receive it. Accessed October 22, 2026. https://docs.kaleidr.com/chat/supported-maps
8. Kaleidr Developer Docs. Platform API endpoints. The chat request carries the conversation, a map-center location, optional zoom, and a language. There is no field for system instructions, a persona, tools, or the caller's own context. app_snapshot and auto_actions are accepted and not needed. Accessed October 22, 2026. https://docs.kaleidr.com/platform-api/endpoints
9. Kaleidr. Map-Aware AI Assistant: How to Build One. A companion guide for building the assistant around a map. Accessed October 22, 2026. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
10. Kaleidr. Kaleidr Enterprise. The enterprise page for spatial AI integrated with a customer's own data. Accessed October 22, 2026. https://kaleidr.com/enterprise

References in BibTeX

@misc{mei_context_engineering_survey_2025,
  title         = {A Survey of Context Engineering for Large Language Models},
  author        = {Mei, Lingrui and others},
  year          = {2025},
  eprint        = {2507.13334},
  archivePrefix = {arXiv},
  url           = {https://arxiv.org/abs/2507.13334}
}

@article{liu_lost_in_the_middle_2024,
  title   = {Lost in the Middle: How Language Models Use Long Contexts},
  author  = {Liu, Nelson F. and Lin, Kevin and Hewitt, John and Paranjape, Ashwin and Bevilacqua, Michele and Petroni, Fabio and Liang, Percy},
  journal = {Transactions of the Association for Computational Linguistics},
  volume  = {12},
  pages   = {157--173},
  year    = {2024},
  doi     = {10.1162/tacl_a_00638}
}

@misc{vercel_context_engineering_2026,
  title  = {What is context engineering? A developer's guide},
  author = {{Vercel}},
  year   = {2026},
  url    = {https://vercel.com/i/context-engineering}
}

@misc{ietf_rfc7946_2016,
  title  = {RFC 7946: The GeoJSON Format},
  author = {{IETF}},
  year   = {2016},
  url    = {https://www.rfc-editor.org/info/rfc7946}
}

@misc{kaleidr_how_it_works_2026,
  title  = {How Kaleidr works},
  author = {{Kaleidr Developer Docs}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/concepts/how-kaleidr-works}
}

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

@misc{kaleidr_supported_maps_2026,
  title  = {Supported maps},
  author = {{Kaleidr Developer Docs}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/chat/supported-maps}
}

@misc{kaleidr_platform_api_endpoints_2026,
  title  = {Platform API endpoints},
  author = {{Kaleidr Developer Docs}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

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

@misc{kaleidr_enterprise_2026,
  title  = {Kaleidr Enterprise},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/enterprise}
}