見出し画像

Niantic Spatial「VPS 2.0」を触ってみた。都市スケールARはここまで来た

デザイニウムXR | XR体験コンテンツ開発専門

Niantic Spatialが新しいVPS、通称「VPS 2.0」を発表した。
旧Lightship VPSとWPS（World Positioning System）を統合し、Scaniverseベースの新しい開発環境へと一本化する大きなアップデートだ。

私たちDesigniumの開発チームは、発表直後から実機で検証を進めてきた。公式ドキュメントだけでは見えてこない「実際どのくらい速いのか」「どこまで正確なのか」を、体験開発スタジオの視点で確かめたかったからだ。

この記事では、VPS 2.0で何が変わったのかを公式情報ベースで整理しつつ、実際に触って見えてきたことを正直に書いてみたい。初版公開後に進めた追加検証（再現性とAR配置方法の比較）も、同じ記事内に追記した。

VPS 2.0とは何か

VPS 2.0は、Niantic Spatialが2026年に投入した新しい位置測位の仕組みだ。Niantic Spatial SDK（NSDK 4.0）から利用でき、Unity / Swift / Kotlinに対応する。

特徴は、ひとつのシステムの中に「Coarse（粗）」と「Precise（精密）」という二つのモードを持たせたことにある。

  • Coarseモード：GPSとコンパス、そしてデバイスのARトラッキングを統合したセンサーフュージョン。スキャンされていない場所でも、標準的なGPS＋コンパスより安定した位置と向きが取れる。

  • Preciseモード：従来のVPSに近い、スキャン済みメッシュと画像を照合する精密測位。サブメートル級の精度で6DoFポーズを返す。

公式ドキュメントでは、この二つが「シームレスに切り替わる」と説明されている。スキャンされていないエリアをCoarseでガイドしつつ、スキャン済みのアンカー地点に近づくと自動でPreciseに切り替わる、という動き方だ。文章で読むと地味に聞こえるが、これが体験設計の自由度を大きく変える。

旧VPSとの違い：WPSの統合とGeoreferenceツール

VPS 2.0で私たちが注目した変化は二つある。

1. WPSとの統合

これまでのLightshipでは、Geospatial的な全球測位（WPS）と、メッシュ照合のVPSは別建ての機能だった。VPS 2.0ではこれがひとつに統合され、開発者側は「常に位置が取れていて、条件が揃えば精密になる」という前提でコンテンツを組み立てられる。

「スキャン地点の外に出た瞬間に何も返ってこなくなる」という、旧VPS時代の扱いづらさが解消されたのは地味に大きい。体験設計のうえで、この断絶の処理にどれだけ頭を使ってきたか。それがなくなるだけで、コンテンツの流れ方がかなり変わる。

2. Georeferenceツール

もうひとつの目玉が、Scaniverse Web上で使えるGeoreferenceツールだ。スキャンしたメッシュを実世界の地図に対して手動で位置合わせできる。これによって、VPSがローカライズした際に返ってくる緯度・経度・高度・方位（heading）の精度が、従来より大幅に底上げされる。

ただし公式も警告している通り、回転のずれは距離が伸びるほど誤差を拡大させる。ここの調整は丁寧にやる必要があって、「なんとなく合ってればいい」という精度では使えないシーンもある。

Lightship.devからScaniverseへの移行

技術的な話と並行して、もうひとつ重要なのが開発環境の移行だ。

  • 2026年2月20日：Scaniverse（Enterprise）ローンチ、データ移行開始

  • 2026年2月28日：Lightship.devとGeospatial Browserが完全シャットダウン

  • 既存のARDK 3.xアプリは当面動作継続

  • 新規開発はNSDK 4.0 + 新ポータルAPIが推奨

運用面で気をつけたいのは、Public POIsがいったん利用不可になっている点だ。これまでスキャン貢献で公開されていたPOIは、当面「プライベートサイト」としてのみ使える。公開マップの扱いについては、今後のアナウンス待ちの状態だ。

地域と連動した公開型のAR体験を設計している場合、ここは設計を組み直す必要がある。スケジュールが詰まっている案件では、早めに確認しておいたほうがいい。

実機検証①：測位距離・速度・Georeference精度

ここからが私たちの検証結果だ。結論から言うと、速度の改善は想像以上で、精度の上限は旧VPSと同等だった。

測位可能距離：旧VPSとほぼ同じ

Preciseモードでローカライズできる距離は、スキャンメッシュからおおむね5メートル程度。ここは旧VPS時代と大きく変わらなかった。離れた場所から精密測位を期待するような設計はできない、という前提は維持される。

速度：近距離ではほぼ瞬時

一方で、ローカライズにかかる速度は体感で大幅に改善している。メッシュから数メートル以内に入れば、ほとんど瞬時にPreciseに切り替わる。旧VPSで感じていた「数秒待たされる違和感」がほぼ消えた。

体験設計の観点では、これはかなり大きい。ユーザーに「止まって端末をかざしてもらう」時間を短くできるので、歩きながら自然にAR体験に入ってもらう導線が組みやすくなる。待ち時間は、体験への没入を一番削ぐ要素のひとつだ。

Georeferenceの精度：Geospatial APIに並ぶ

Georeferenceツールで位置合わせをしたサイトでは、ローカライズ時に返ってくる緯度・経度・高度・headingの精度が、GoogleのGeospatial APIに近いレベルで取得できた。

そして重要なのは、屋内やストリートレベル以上（上層階）でも動くという点だ。Geospatial APIは屋内や高層階での動作が弱かったので、ここはVPS 2.0ならではの強みになる可能性がある。

実機検証②：再現性とAR配置方法の比較（追記）

初版公開後、もう少し踏み込んで「同じ場所で何度計測してもブレないのか」「ARコンテンツを配置するうえで、どの方式がどの用途に向いているのか」を検証した。以下、その結果をまとめる。検証はすべて都内のテスト地点（約 35.705°N / 139.653°E 付近）で実施している。

位置の一貫性：サブメートル級の再現性

同じ地点でアプリを完全に再起動しながら複数回ローカライズし、返ってきた緯度・経度のバラつきを確認した。

  • NSDK VPS 2.0：同一地点での差分は最大約40cm

  • Google Geospatial API：同一地点での差分は最大約30cm

絶対値ではGeospatial APIの方がやや小さいものの、VPS 2.0もサブメートル級で十分に安定している。「起動するたびに数メートル動く」ようなことは起きない。AR配置のために固定アンカーを打つ用途では、この再現性で実用的に足りる。

AR配置の3方式

NSDK 4.0では、ARコンテンツの配置方法が3つ用意されている。それぞれ性格が異なるので、用途に応じて使い分ける前提だ。

  • A. アンカー相対配置：オンサイトでコンテンツを作り込み、セッションをまたいでサイトに固定したいケース。ゲームやインスタレーション向き。

  • B. 地理座標配置：緯度・経度・高度で位置が決まっているコンテンツ。ナビゲーションや地点データ可視化向き。

  • C. インポートメッシュ配置：Unity Editor上で、スキャン済みメッシュに対して丁寧に配置したいケース。

位置データ系のAPI（ナビゲーション、Google Places、リアルタイム情報など）を重ねたいならB、街の細部にピタッと合わせたい演出ならC、オンサイトで完結するゲームやインタラクションならA、という棲み分けになる。

地理座標配置（B方式） vs Geospatial API

今回いちばん関心が高かったのがB方式だ。ユーザーの立ち位置から離れた場所にもコンテンツを配置できるので、街スケールのAR体験に直結する。そして、屋内や上層階でも動く点を考えると、Geospatial APIに対する実質的な代替になる可能性がある。

近距離テスト：道路の両端に、本来なら道路の中央に来るはずの座標で2本のピンを立てた。Geospatial APIはほぼ意図通りの位置に配置された一方、NSDK VPS 2.0は意図した位置から北東方向に3〜4メートルほどオフセット。ただし重要なのは**「ずれの方向と量が毎回ほぼ同じ」**だったこと。精度（accuracy）ではGeospatial APIに劣るが、再現性（precision）は高い。Georeferenceツールで微調整すれば現場で合わせ込める。

遠距離テスト（150m）：Siteから150m離れた位置に同じコンテンツを両方式で配置し、2か所の視点から見比べた。Siteの真正面でも20m離れた視点でも、両者の差はわずかで実用上は同等。遠距離のAR配置用途ではVPS 2.0は十分に使える。

インポートメッシュ配置（C方式）

旧Lightship VPSから引き継がれた方式。Unity Editor上でスキャン済みメッシュに対してオブジェクトを直接配置できる。精度は10cm以下（sub-10cm）に乗せられる一方、ローカライズ速度はやや遅く1〜4秒ほど待つ場面があった。ビルの柱のこの位置にキャラクターを立たせるような演出ではC方式が最有力だ。

追記（2026年5月）— 高層階テスト・屋内測位・API共存

「次は上層階での高度精度テスト」と書いてから、さらに検証を続けた。今回は新たに2つのテーマを試している。

VPS2とGoogle Geospatial APIの共存確認

NSDK VPS2とGoogle Geospatial APIを同じシーンで動かしたとき、競合が起きないかを確かめた。

赤マーカーをVPS2の地理座標配置（TryGetPose）、青マーカーをGeospatial APIで表示する構成でテストした結果、両者は問題なく共存できた。

（↑ 動画：赤（NSDK TryGetPose）と青（Geospatial API）のマーカーが同一シーンに並ぶ様子。デバッグテキストで差分を確認できる。）

同一地点を示す2つのマーカーの間には、緯度経度で3.4m、高度で2.4mの差が生じていた。それぞれが独立した座標系でジオリファレンスを行っているために生じる誤差で、実用上は許容範囲だ。

実機検証③ — 渋谷スクランブルスクエア11Fでの高層階テスト

「Geospatial APIが苦手とする屋内・高層階でも動作する」というVPS2の強みを実際に確かめた。

テスト環境は以下の通り。

  • 場所：渋谷スクランブルスクエア 11F（高度約70m）

  • スキャン：Scaniverse（iOS端末）

  • テストアプリ実行：Android端末

TryGetPose関数で高度を指定し、ARコンテンツを配置した。


位置の再現性は高いが、高度が大きくずれる

地理座標ベースのAR配置については、建物内でGPSとコンパスの精度が落ちるため安定しなかった。意図した位置に表示されることもあれば、全く外れることもあり、再現性は低い状態だ。

Precise location tracking（スキャンメッシュ基準）の位置精度は高く、ほぼ意図した場所に表示された。ただしコンテンツが意図した高度より大幅に高い位置に表示されるという問題が出た。

原因として現時点では2つの仮説がある。

仮説1：iOS / Androidの高度取得方式の違い

ScaniverseでのスキャンはiOS、テストアプリの実行はAndroidで行った。両OSで高度の基準が異なる可能性があり、開発者コミュニティでも差異の報告が多いテーマだ。

仮説2：スキャン時のデバイスが不正確な高度を返していた

スキャン時点で、デバイスが正確な高度データを取得できていなかった可能性もある。

現時点では確定しておらず、Androidでスキャンをし直すなど追加検証が必要な状態だ。

Georeferenceツールで把握した既知問題

高層階テストと並行して、Georeferenceツールの問題点も3つ整理できた。

1. 衛星画像の斜め視点問題

斜め角度で撮影された衛星画像では、スキャンの正確な配置が難しいケースがある。Standard mapに切り替えることで対処できる。

2. Satellite mapとStandard mapの不整合

衛星画像で配置したスキャンが、Standard mapに切り替えると位置がずれて見えることがある。どちらを正として扱うべきか、判断が難しい場面が出てくる。

3. 特定エリアでの配置困難

渋谷のハチ公像エリアでは、衛星画像が木で覆われて地形を確認できず、Standard mapも情報量が少なく、正確な配置の基準を作れない状態だった。こうした場所ではCesiumのGoogle 3D map tilesが代替として有効かもしれない。

今後に期待する機能

検証を通じて、あると便利だと感じた機能を2点挙げておく。

  • 地面スナップ機能：TryGetPoseで配置する際、地面高さへ自動補正してくれる機能。高度ずれ問題の軽減に直結する。

  • Georeferenceツールの複数スキャン対応：同一サイト内の複数スキャンを1つのGeorefernceツールで一括配置できる機能。現状はスキャン単位での操作のみだ。

体験開発スタジオとしての考察

私たちは体験開発スタジオなので、技術そのものよりも「これで何が作れるか」に関心がある。VPS 2.0を触った上で、いくつか見えてきた方向性がある。

都市スケールのAR体験が、現実的な選択肢に入ってきた。 Coarseモードでエリア全体をガイドしつつ、要所のスキャン地点でPreciseに切り替えて精密なAR演出を出す、という組み立てができる。追加検証で150m離れた配置も実用レベルで動くことを確認できたので、街歩き型の観光コンテンツやイベントで、設計の自由度が上がる。

配置方式の使い分けが体験の質を決める。 B方式（地理座標）は街スケールの情報レイヤー、C方式（インポートメッシュ）はピクセル単位の演出、A方式（アンカー相対）はオンサイト完結のゲーム性。ひとつの案件の中でも、シーンごとに使い分ける設計が現実的だ。

高層階対応は可能性として確認できた。 今回のテストで「屋内・高層階で動作する」という強みは確かめられた。ただし高度精度の扱いにはまだ注意が必要で、特にiOS/Android間の差異は設計に織り込む必要がある。

公開マップの不在は当面の制約。 Public POIsが一時停止している間は、スキャン貢献型のオープンな体験は組みにくい。クローズドな案件やエンタープライズ向けの導入から着手するのが現実的だ。

まとめ

VPS 2.0は、旧VPSの延長ではなく「測位の使い方そのものが変わった」アップデートだと感じた。速度の改善と全球測位の統合で、屋外の広いエリアを体験の舞台にしやすくなった。追加検証で分かった遠距離配置の実用性と配置方式の選択肢の広さも、体験設計の自由度を大きく押し上げている。

一方で、測位可能距離や公開マップ周りの制約、そして近距離での絶対精度では依然としてGeospatial APIに一歩譲る場面がある点は、過剰な期待をせずに押さえておきたい。案件ごとに「どの方式で・どの距離で・どの精度が必要か」を切り分けて設計するのが良さそうだ。

高層階テストでは位置精度の高さを確認できた一方、高度ずれの問題（iOS/Android間の差異が主因と推測）も発見した。高度を使う体験設計では「まだ開発途上の機能」として扱い、余裕を持った設計を推奨する。

私たちDesigniumは、今後もNiantic Spatialの最新機能を検証しながら、都市や空間と接続する体験を設計していく。引き続き、複数Siteをまたいだ広域体験の設計検証にも取り組んでいく。

VPS 2.0を活用したコンテンツやシステムの企画・開発にご興味がある方は、ぜひお気軽にご相談ください。