Spatial AI のレイテンシ

Spatial AI のレイテンシとは、位置に関する質問から最初の有用な地図フィードバックまでにかかる時間であり、単一のモデル用タイマーではありません。待ち時間には、認可、取得、ルート計算、そして言語モデルが生成するトークンが含まれる場合があります。高速なモデルでも、遅いルート計算の後ろで待つことがあります。逆に、最終段落の生成がやや遅くても、適格な場所やルートが先に表示されれば、体感上は十分に応答性が高くなります。

Spatial AI のレイテンシには何が含まれるか？

位置に関する質問は複数の時計を通過します。それらを一つの「AI レイテンシ」に平均すると、ユーザーが実際に待っている段階が見えなくなります。ブラウザの応答性は、クリックに対してページがどれだけ速く反応するかです。最初の進捗までの時間は、作業が始まったことをインターフェースが示すまでの時間です。最初のトークンまでの時間は、生成が最初のトークンを返すまでの時間です。最初の空間操作までの時間は、適格な場所またはルートが見えるまでの時間です。最後のトークンまでの時間は、生成が完了するまでの時間です。完了した操作までの時間は、ユーザーが結果を信頼して行動できる状態になるまでの時間です。

最初の進捗までの時間、最初の空間操作までの時間、完了した操作までの時間は、製品体験を説明するために Kaleidr が使う名称です。この3つは Web 標準ではありません。最初のトークンまでの時間と最後のトークンまでの時間は、モデルの確立された指標です。

1つのリクエストに対する6つのタイマー: 次の描画までの操作、最初の進捗までの時間、最初のトークンまでの時間、最初の空間操作までの時間、最後のトークンまでの時間、完了した操作までの時間。

6枚のカードは、ブラウザの応答とリクエストの残りの部分を分けています。最初の進捗までの時間、最初の空間操作までの時間、完了した操作までの時間は Kaleidr の編集上の指標として示されています。最初のトークンまでの時間と最後のトークンまでの時間は、確立されたモデルレイテンシ指標として示されています。次の描画までの操作はブラウザ指標です。どのカードも Kaleidr の実測値を示していません。

Google の Web パフォーマンスガイダンスでは Interaction to Next Paint（次の描画までの操作）を実環境での応答性として扱い、ページ読み込みの75パーセンタイルで INP が200ミリ秒以下なら良好としています（web.dev, 2025）。このしきい値はクリック後の次の描画についてのもので、ルート計算や生成された段落についてではありません。ページがこの基準を満たしていても、ユーザーが取得処理を待たされることはあります。モデル呼び出しが遅いことだけで INP が悪くなるわけではありません。この2つの予算は別々に可視化すべきです。そうしないと、チームはクリティカルパスに存在しなかったクリックハンドラーを調整して「AI レイテンシを改善した」ことになりかねません。

なぜクリティカルパスが重要なのか？

クリティカルパスとは、順番どおりに完了しなければならない処理の最長チェーンです。独立した参照処理は重ねて実行できます。解決済みの場所と業務上の事実の両方を必要とするルート計算は、その両方が揃うまで開始できません。これらを直列化すると所要時間が加算されます。並列実行で減らせるのは重複部分だけであり、ルート計算自体が速くなるわけではありません。非公開レコードを表示する前には、依然として認可が必要です。

認可、場所参照、業務データ、ルート、モデルを直列に並べたチェーンと、場所参照と業務データを並列実行するグラフの比較。

上段は各ステップの完了を待ってから次へ進みます。下段は場所参照と業務データを同時に実行し、その後にルートとモデル用に結合します。図は待ち時間の構造を示すもので、計測済みの高速化を報告しているわけではありません。また、ルートは引き続き両方の参照に依存します。

有用なトレースは製品名ではなくスパンを記録します。Geocoding、業務データの読み取り、ルート、順位付け、生成は、質問によってそれぞれ遅いスパンになり得ます。Spatial AI Observability は、結果が空だった場合の構造化された理由も含め、これらのスパンを個別に記録するための関連ガイドです。この分離がないと、実際にはルートサービスが遅くなっただけでも「モデルが悪くなった」と見えてしまいます。

なぜ最初のトークンは最初の地図結果ではないのか？

最初のトークンまでの時間と最後のトークンまでの時間は異なる問いに答える指標であり、どちらも地図が有用になる瞬間そのものではありません。Azure OpenAI は、最後のトークンまでの時間は最初のトークンまでの時間に、トークン間の時間と生成トークン数の積を加えたものだと説明しています（Microsoft, 2026）。同じ記事では、各プロンプトトークンが加える時間は各生成トークンに比べて小さく、ストリーミングは準備できたトークンを順次返すものの、全トークンの生成に必要な時間自体は変わらないとしています。OpenAI のレイテンシガイドにも関連する経験則があり、出力トークンをおよそ半分にするとレイテンシもおよそ半分になる可能性があるとしています（OpenAI, 2026）。そのため、短い説明は早く終わります。場所、営業時間、ルートを担うべきなのは段落ではなく地図カードです。

2つの例示タイムライン。一方は最初のトークンが早く地図が遅い。もう一方は有用な地図アクションが早い。

システムAはテキストを早く表示し、地図アクションは遅く表示します。システムBはテキストがやや遅い一方、地図アクションは早く表示します。図の秒数や合計値は例示であり、ベンチマークデータではないことが明記されています。これらは Kaleidr のトレースでも、Azure や OpenAI の記事から得た結果でもありません。比較対象は順序だけです。トークンが早いことは、地図が早いことを意味しません。

この違いは、製品が何を成功として評価するかに影響します。最初のトークンまでの時間だけで順位付けするダッシュボードは、先に話し始めて地図表示が遅いシステムを好みます。地図製品は最初の空間操作までの時間も記録し、そのアクションは適格性を通過した後にのみ記録すべきです。閉店中または権限のない場所のピンが早く出るのは、単に速い間違いです。Spatial Context Engineering は、適格な集合が確定した後に、どの事実をモデルへ渡してよいかという関連ルールを扱います。

何をキャッシュでき、何を再検証すべきか？

キャッシュが往復通信を削減できるのは、保存済みの値が今も正しい場合だけです。既知の場所の安定した識別子や座標はめったに変わらないため、長期キャッシュの一般的な候補です。営業時間、計算済みルート、説明文は十分に変化するため、短い time-to-live が誠実な方針です。在庫、車両位置、認可、トランザクション状態は、意思決定時に再度読み取るべきです。今朝キャッシュした「在庫あり」は午後の証拠にはなりません。

3つの鮮度クラス: 安定した識別子と座標、短命な営業時間とルート、そしてライブ在庫・位置・認可・トランザクション状態。

左列はめったに変わらないものです。中央列は短い有効期間が必要です。右列は使用前に再検証すべきものです。図のフッターは、これらのクラスがプロバイダー条件、プライバシー、業務ルールの対象であることを示します。中央列のルートはキャッシュされた計算であり、道路がまだ通行可能であるという保証ではありません。この図の内容は Kaleidr のキャッシュポリシーを示すものではありません。

プロバイダー由来の場所データには2つ目の制約があります。レコードに付随していた条件は、attribution や利用制限を含め、コピーにも引き続き適用されます。非公開レコードには3つ目の制約があります。ユーザー間で共有されるキャッシュが認可を回避する手段になってはいけません。不明は不明のままです。在庫のタイムアウトは「在庫切れ」と表示する根拠にはならず、ルートのタイムアウトは所要分数を推測する根拠にはなりません。

説明が終わる前に地図を動かせるのはいつか？

地図上で有用な順序は、多くの場合、場所、次にルート、最後にそれらを説明する文です。言語モデルがまだ文章を書いている間でも、ユーザーは適格な候補を確認できます。このパターンは取得処理や経路計算自体を速くするものではありません。すでに完了した作業を早く見せるだけです。ストリーミング text にも同じ制約があります。Azure の説明では、ストリーミングが変えるのは最初のトークンが見える時点であり、シーケンス全体の生成に必要な時間ではありません。

候補エリア、場所のピン、ルート、短い説明の4段階を、地図を表示したまま示す。

シーケンスは候補エリア、ピン、ルート、短い説明の順です。店舗数、徒歩2分、評価、住所、営業時間は図上のサンプルラベルであり、ライブクエリではありません。このパターンのピンとルートは、すでに適格性を通過した場所に対するものです。早い marker はその確認の代わりにはなりません。

Kaleidr の公開ストリームは Server-Sent Events の text/event-stream であり、契約では文章が終わる前に到着し得る内容が定義されています（Kaleidr, 2026）。phase イベントはリクエストが受理され作業が始まったことを意味し、そのフェーズ値は常に thinking です。10秒間何も送られないと : keep-alive コメントが届きます。難しい質問では最初の文章まで数十秒かかる場合があり、そのためフェーズイベントとハートビートが存在します。経路案内の質問では文章より先に route が届くことがあり、テキストがストリームしている間に線を描けます。early_actions は回答完了前に適用できる地図アクションを含み、2つ以上の場所に座標があると送信されます。end イベントが正式な結果であり、そのアクションが早期アクションを置き換えます。すべてのイベントがすべてのリクエストで現れるわけではありません。

リクエストグラフはどう描くべきか？

依存関係を描き、その後、回答を変えないステップを削除します。場所解決と業務データ読み取りは、認可後に並列実行できます。適格性が結合です。経路計算や他の空間処理はその結合を使います。順位付けは残った候補を並べます。生成はそれらを説明します。地図は同じ識別子を表示します。適格性より前に生成を置くと、製品が推奨できない場所にトークンを費やします。Grounded Spatial AI for Business Data は、この適格性を事実を所有するシステム内に保つ方法を扱います。

認可後に場所解決と業務データを並列実行し、その後に適格性、経路計算、順位付け、モデル、地図へ進むリクエストグラフ。

最初に認可があります。場所解決と業務データ読み取りが並列のペアです。その後に適格性、ルート、順位付け、生成、地図が続きます。実線がクリティカルパス、破線が重複して実行される読み取りです。図はグラフ全体を描くことの重要性を示しています。計測済みの削減量を報告するものではなく、非公開レコードが認可を越える様子も示していません。

同じグラフは、言語モデルが不適切な道具である場所も示します。包含判定、認可確認、「営業中」フィルター、距離しきい値は決定論的です。モデルは、リクエストを読み、サービスがすでに計算した結果を説明し、適格な場所の中でソフトな好みを順位付けする用途に向いています。OpenAI のレイテンシガイドも一般論として同じ切り分けを示し、言語的な推論が不要なタスクでは従来手法の方が高速だとしています。また、すべての言語処理ステップを1回のプロンプトで返す方が、モデル呼び出しのチェーンより速い場合があります。追加の呼び出しごとに別の round trip が発生するためです。ルート、在庫、権限は引き続きそれぞれのサービスから取得します。

なぜ平均値は遅いリクエストを隠すのか？

平均値は待ち時間の要約として弱い指標です。少数の遅いリクエストが、人が記憶する体験を支配するからです。各スパンについて中央値、95パーセンタイル、99パーセンタイルを、リクエスト種別ごとに報告してください。経路案内の質問と短い場所質問を同じバケットに入れるべきではありません。長いテールは、複数ツールへのファンアウト、再試行、大きなプロンプト、プロバイダー差、長い生成回答などから生じます。Azure の式が示すとおり、最後の要因は出力トークン数とともに増えます。その他はトークン数には現れないため、スパンを分けて見る必要があります。

概念的なレイテンシ曲線に中央値、95パーセンタイル、99パーセンタイルと長いテールを示す。

この曲線は形状の例であり、Kaleidr のトレースでもプロバイダーのダッシュボードから抽出したサンプルでもありません。ラベルはパーセンタイルの一般的な読み方を示しています。リクエストの半分が中央値以下、大半が95パーセンタイル以下、ほぼすべてが99パーセンタイル以下です。グラフ下の5つの原因は調査箇所のチェックリストであり、Kaleidr トラフィックの実測割合ではありません。

テールポリシーは、スパンが予算を外したとき製品が何をするかを定義すべきです。ルートのタイムアウトは不明のままとし、説明でルートが利用できなかったと伝えます。在庫のタイムアウトも不明のままで、「在庫切れ」に変換してはいけません。再試行はトレースに残し、一時的な障害を遅いモデルと誤認しないようにします。中央値だけを最適化して、99パーセンタイルではユーザーがスピナーを見続ける状態なら、パフォーマンス改善は完了していません。

どの段階を予算に含めるべきか？

目標を割り当てる前に段階を名前付けします。実用的な予算は7行です。インターフェースでリクエストを受け付ける、本人確認と認可を行う、コンテキストを取得する、ルートまたは距離を計算する、説明を生成する、地図アクションを適用する、業務アクションを完了する、です。リクエストグラフが示すように、一部は重なります。また、予約や引き継ぎまで到達しないリクエストもあります。この一覧はどの行が変化したかを見るためのもので、すべての質問が7段階を直列実行するという主張でも、ミリ秒単位の目標値でもありません。

リクエスト受け付けから認可、取得、空間計算、モデル推論、地図アクション、業務アクションまでの7つの予算段階。

各段階には1つの役割があり、時間は設定されていません。リクエスト受け付けはブラウザの仕事です。認可は非公開データより先です。取得、空間計算、生成は別々の行です。地図アクションはピン、ルート、またはフィットしたビューを表示します。業務アクションは引き継ぎであり、質問がそれを求めない場合は存在しません。図は数値目標を設定していません。

ある段階に目標を置くのは、トレースがユーザーの待ち時間の原因としてその段階を示した後にしてください。「2秒で回答」のような普遍的な数値はクリック、ルート、段落を混ぜてしまい、この文章はそのような値を引用していません。上の INP しきい値はブラウザ目標です。上のトークン式はモデル時間の内訳です。最初の空間操作までの時間は地図目標であり、チームが自分たちのトレース上で定義するまでは編集上の指標です。

チームはどこから始めるべきか？

まず待ち時間を分解します。ページの次の描画までの操作、最初の進捗までの時間、最初のトークンまでの時間、最初の空間操作までの時間、最後のトークンまでの時間、完了した操作までの時間を記録します。3つの編集上の名称は製品指標として明示してください。リクエスト種別ごとに p50、p95、p99 を読みます。地図が詳細をすでに表示しているなら生成回答を短くします。依存関係のない参照だけを重ねて実行します。意思決定を変え得るものは再検証します。そして最初のピンではなく end イベントを、ユーザーが行動できる正式な結果とします。

組織固有の場所やルールをこの経路に含める必要がある場合は、Kaleidr Enterprise を確認してください。SSE wire contract は、フェーズイベント、キープアライブ、初期の地図アクション、最終結果を含む、上記で引用したイベント順序を定義しています。

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

よくある質問

Spatial AI のレイテンシとは？

Spatial AI のレイテンシとは、位置に関する質問から有用な地図フィードバックまでにかかる時間です。インターフェース、認可、取得、空間計算、生成、地図アクション、必要な業務引き継ぎを含みます。モデル時間と同じ数値ではありません。

次の描画までの操作はモデルレイテンシと同じですか？

いいえ。次の描画までの操作は、クリックに対してページがどれだけ速く応答するかを測ります。ページ読み込みの75パーセンタイルで200ミリ秒以下という良好な値は、ルートや段落がいつ完了するかについては何も示しません。

最初のトークンまでの時間とは？

最初のトークンまでの時間は、プロンプトを送信してから最初の生成トークンが返るまでの時間です。Azure OpenAI はこれを、トークン間の時間と生成トークン数と組み合わせて最後のトークンまでの時間を説明しています。

なぜ最初のトークンだけでは地図に十分ではないのですか？

地図が有用になるのは、適格な場所またはルートが見えるときです。その瞬間は最初のトークンより前に来ることも、かなり後に来ることもあります。最初の空間操作までの時間は地図の瞬間を記録し、最初のトークンまでの時間はテキストの瞬間を記録します。

ストリーミングは経路計算を速くしますか？

いいえ。ストリーミングは完了した作業が見える時点を変えるだけです。ルート、取得、または完全な生成に必要な時間は短縮しません。Azure のレイテンシ記事では、ストリーミングは全トークンを生成するために必要な時間を変えないとしています。

回答が終わる前に Kaleidr は何を送りますか？

公開ストリームは、値が thinking の phase イベント、無通信時のキープアライブ、経路案内質問で文章より先に来る route、2つ以上の場所に座標があると送られる early_actions を返す場合があります。end イベントが正式な結果で、早期アクションを置き換えます。すべてのイベントがすべてのリクエストに現れるわけではありません。

レイテンシ削減のために非公開在庫をキャッシュすべきですか？

いいえ。在庫、認可、ライブ位置、トランザクション状態は意思決定時に再検証すべきです。Timeout は不明のまま扱います。安定した場所識別子は長期キャッシュの一般的な候補ですが、プロバイダー条件の範囲内に限ります。

チームはどのパーセンタイルを見るべきですか？

各スパンについて中央値、95パーセンタイル、99パーセンタイルを、リクエスト種別ごとに確認してください。中央値が改善しても、ユーザーが記憶する遅いテールが変わらないことがあります。

References

web.dev. Interaction to Next Paint (INP). A good INP is at or below 200 milliseconds at the 75th percentile of page loads recorded in the field. An INP above 200 milliseconds and at or below 500 milliseconds needs improvement. Updated September 2, 2025. https://web.dev/articles/inp
Microsoft. Azure OpenAI in Microsoft Foundry Models performance & latency. Time to last token equals time to first token plus the time between tokens multiplied by tokens generated. Streaming returns tokens as they are ready and does not change the time required to produce all of them. Accessed October 31, 2026. https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/latency
OpenAI. Latency optimization. A stated heuristic: cutting about half of the output tokens may cut about half of the latency. Accessed October 31, 2026. https://developers.openai.com/api/docs/guides/latency-optimization
Kaleidr Developer Docs. SSE wire contract. Documents text/event-stream, a phase event that is always thinking, a keep-alive after 10 seconds of silence, tens of seconds before first prose on a hard question, early_actions once two or more places have coordinates, a route before the prose on a directions question, and end as the authoritative result. Accessed October 31, 2026. https://docs.kaleidr.com/platform-api/sse-wire-contract
Kaleidr. Spatial AI Observability. A related guide for recording each stage, including a structured reason when the result is empty. Accessed October 31, 2026. https://kaleidr.com/blog/spatial-ai-observability
Kaleidr. Spatial Context Engineering for Map-Aware AI. A related guide for which facts reach the model after eligibility. Accessed October 31, 2026. https://kaleidr.com/blog/spatial-context-engineering
Kaleidr. Grounded Spatial AI for Business Data. A related guide for keeping business facts in the systems that own them. Accessed October 31, 2026. https://kaleidr.com/blog/grounded-spatial-ai-business-data

References in BibTeX

@misc{webdev_inp_2025,
  title  = {Interaction to Next Paint (INP)},
  author = {{web.dev}},
  year   = {2025},
  url    = {https://web.dev/articles/inp}
}

@misc{microsoft_azure_openai_latency_2026,
  title  = {Azure OpenAI in Microsoft Foundry Models performance \& latency},
  author = {{Microsoft}},
  year   = {2026},
  url    = {https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/latency}
}

@misc{openai_latency_optimization_2026,
  title  = {Latency optimization},
  author = {{OpenAI}},
  year   = {2026},
  url    = {https://developers.openai.com/api/docs/guides/latency-optimization}
}

@misc{kaleidr_sse_wire_contract_2026,
  title  = {SSE wire contract},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/platform-api/sse-wire-contract}
}

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

@misc{kaleidr_spatial_context_engineering_2026,
  title  = {Spatial Context Engineering for Map-Aware AI},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-context-engineering}
}

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