ARCore Geospatial APIのStreetscape Geometry|建物オクルージョンの実装と対応エリア・料金
Google ARCore Geospatial APIのStreetscape Geometryは、端末の周囲にある建物と地形のポリゴンメッシュを返す機能です。これを使うと、ARオブジェクトが実在の建物の陰へ隠れるオクルージョン表現を、3Dモデルを自前で用意せずに実装できます。ただし着手前に決めておくことがあります。対象エリアでVPSが効くか、使用量の上限と課金の範囲をどう見積もるか、そしてスマートフォン向けのARCoreとAndroid XR向けのARCoreで設定値が分かれ始めた点をどう扱うかです。公式リファレンスの識別子と、2026年8月時点のバージョンを基準に整理します。
まとめ
先に結論を示します。実装の可否は次の7点でほぼ決まります。
- メッシュを得るには
Config.GeospatialMode.ENABLEDとConfig.StreetscapeGeometryMode.ENABLEDの両方が必要で、後者の既定値はDISABLEDです。片方だけでは何も返りません。 - 返るのは建物と地形の2種類。建物の詳細度は2段階しかなく、上位の
BUILDING_LOD_2でも煙突や屋根の換気口はメッシュの外へ出ると公式に明記されています。 - データ元はGoogleストリートビューの画像です。対象地点で使えるかは
Session.checkVpsAvailabilityAsyncが緯度経度単位で返します。 - ARCore APIに公開の料金表はなく、Googleは提供開始時に無償と案内しています。金額が立つのはGeospatial Creatorを併用する構成だけで、対象はMap Tiles APIとPlaces APIというGoogle Maps Platform側のAPIです。
- 2026年5月のARCore for Jetpack XR 1.0.0-alpha14で
GeospatialMode.VPS_AND_GPSが非推奨になりました。一方でスマートフォン向けのARCore SDKのConfig.GeospatialModeは今も2値のままで、両者を混同するとサンプルコードが通りません。 - 屋内・私有地・撮影後に建った建物では成立しません。企画を固める前に対象エリアの実測が要ります。
- 日本語圏で参照できる代表的な検証事例も、アプリへの実装時期は未定のまま運営会社の再編を迎えています。前例に乗る前提での採用は避けてください。
以降は、この判断の根拠になったAPIの実体、エリア判定、料金、導入時の選択、版差、そして見送り条件を順に示します。
Streetscape Geometryが返すメッシュの中身と有効化の条件
Streetscape Geometry APIは、端末を中心とした一定範囲の地形・建物・その他の構造物をポリゴンメッシュとして返します。ARオブジェクトの座標だけを扱う通常のGeospatialアンカーと違い、現実の形状そのものがアプリ側に渡る点が実装上の分かれ目です。遮蔽判定も物理演算も、この形状データがあって初めて成立します。
建物と地形で分かれるメッシュ種別と2段階の詳細度
取得したオブジェクトの getType() は建物か地形かを返し、getQuality() は形状の詳細度を返します。詳細度の定数は3つだけで、値はCityGML 2.0規格が定めるLOD(詳細度)に対応します。リファレンスは、それぞれの作られ方と残る誤差まで書いています。
| Quality の値 | 対象 | 形状 | 残る誤差 |
|---|---|---|---|
| BUILDING_LOD_1 | 建物 | 平らな上面まで押し出し | 傾斜屋根の上が空洞 |
| BUILDING_LOD_2 | 建物 | 粗いハイトマップ付き | 煙突・換気口がはみ出す |
| NONE | 地形など | 定義なし | TERRAIN時の値 |
この差は用途を選びます。ARオブジェクトを建物の陰に隠すだけなら、押し出し形状のBUILDING_LOD_1でも見た目は破綻しません。屋上にオブジェクトを立たせる、屋根の傾斜に沿って何かを転がすといった演出は、BUILDING_LOD_2でも公式が認めている誤差がそのまま画面に出ます。形状精度を前提にした企画は、実機で対象の建物を確認してから固めてください。
2つのモードを同時に立てる設定とメッシュの取り出し
有効化は1行では済みません。Geospatial API自体を有効にしたうえで、Streetscape Geometryのモードを別途立てます。
session.configure(
session.config.apply {
geospatialMode = Config.GeospatialMode.ENABLED
streetscapeGeometryMode = Config.StreetscapeGeometryMode.ENABLED
}
)
この状態になると、Session.getAllTrackables と Frame.getUpdatedTrackables がStreetscapeGeometryオブジェクトを返すようになります。個々のオブジェクトからは getMesh() で頂点リストとインデックスリスト、getMeshPose() で原点の姿勢が取れ、createAnchor(Pose) でメッシュにアンカーを付けられます。
val geometries = session.getAllTrackables(StreetscapeGeometry::class.java)
for (geometry in geometries) {
if (geometry.type == StreetscapeGeometry.Type.BUILDING) {
val quality = geometry.quality
val mesh = geometry.mesh
val anchor = geometry.createAnchor(geometry.meshPose)
}
}
取得範囲について、公式リファレンスは半径の数値を示していません。NTTコノキューが2023年5月11日に公表した技術検証の資料では「ユーザの現在地から半径100m以内の建物の3Dモデルデータを取得する機能」と説明されています。設計の目安には使えますが、仕様として保証された値ではない点は押さえておいてください。
対応エリアの判定方法とストリートビュー由来の制約
Geospatial APIの位置決めは、端末のセンサーとGPSに加えてVPS(Visual Positioning System)が担います。そのVPSの基盤が、15年以上にわたって世界中で撮影されたGoogleマップのストリートビュー画像です。端末が自分で地図を作りながら位置を推定するSLAM(Simultaneous Localization and Mapping)とは出発点が違い、既存の撮影データと照合して絶対位置を出します。撮影が入っていない場所では、実装がどれだけ正しくても動きません。
緯度経度単位でVPSの可否を返すチェックAPI
対象地点が使えるかは Session.checkVpsAvailabilityAsync(double, double, Consumer) で事前に問い合わせます。Kotlinの公式サンプルは完了コールバック形で、VpsAvailability の値ごとに分岐します。
session.checkVpsAvailabilityAsync(latitude, longitude) { result ->
when (result) {
VpsAvailability.AVAILABLE -> enableStreetscapeGeometry()
VpsAvailability.UNAVAILABLE -> fallbackToPlaneDetection()
VpsAvailability.ERROR_NETWORK_CONNECTION -> retryWhenOnline()
else -> reportError(result)
}
}
ここで手を抜かないでください。ERROR_NOT_AUTHORIZED はGoogle CloudのARCore APIへの認可の問題、ERROR_RESOURCE_EXHAUSTED は要求の出しすぎ、ERROR_NETWORK_CONNECTION は外部サービスへ到達できない状態を指します。これらをまとめて「エリア外です」と表示すると、認可設定のミスを現地の電波のせいだと誤診する事故が起きます。
7つ目の値である UNKNOWN は「リモートサービスへの要求がまだ完了していない」という状態です。上の完了コールバックには届かず、Javaのサンプルのように VpsAvailabilityFuture の状態を自分でポーリングする実装で観測します。コールバック形にUNKNOWNの分岐を書いても実行されません。
ストリートビューが入っていない場所で崩れる前提
撮影データ由来という性質から、次の場所は苦手です。企画段階で外しておくと手戻りが減ります。
- 屋内。商業施設や駅構内は撮影対象になっていない区画が多く、VPSが効きません。
- 車両が入れない私道・路地・私有地。撮影経路そのものが通っていない可能性があります。
- 撮影後に建った新築、および解体・建て替えが済んだ区画。メッシュが現況と食い違います。
- 再開発中のエリア。工事の進行に合わせてメッシュが更新される保証はありません。
屋外の街区でも、対象地点が「使える」と分かるまでは机上の設計に留めるのが安全です。GPSやWi-Fi測位を組み合わせる一般的なLBS(位置情報サービス)と違い、Geospatial APIは撮影データの有無という外部条件に依存します。自社が保有する地物データと重ね合わせたい場合は、GIS(地理情報システム)側で座標系を揃えておく前提も要ります。
Geospatial APIの料金と使用量の上限
結論から言えば、ARCore APIの利用そのもので請求は立ちません。Googleは2022年5月の提供開始アナウンスでARCore Geospatial APIを「no cost(無償)」と案内しており、以後も公式ドキュメントにARCore APIの料金表は用意されていません。代わりに明示されているのは使用量の上限です。ARCore SDKは1分あたり1,000セッションの開始、または1分あたり100,000リクエストという制限を設けており、これを超えたリクエストは満たされず、iOSでは GAREarthStateErrorResourceExhausted が返ります(該当ページの更新日は2026年4月28日)。
金額が発生する境界はGeospatial Creatorです。Geospatial CreatorのcodelabはBilling設定を必須としたうえで「プロジェクトが無償枠の割り当てを超えた場合にのみ課金される」と書き、着手前にPhotorealistic 3D TilesとPlaces APIの料金ページを確認するよう指示しています。この構成ではMap Tiles APIとPlaces APIを有効化するため、見積もりの対象はGoogle Maps Platform側になります。Google Maps PlatformのAPIは従量課金で、無償枠の扱いには改定が入っているため、金額はARCore側ではなくMaps Platform側の最新の料金ページで確認してください。
見積もりの実務はこの2択で片づきます。ARCore APIだけを有効化してSDKからGeospatialアンカーとStreetscape Geometryを使う構成なら、確認すべき数字は課金額ではなく上の割り当てです。Geospatial CreatorをUnityの制作フローに入れるなら、その時点でMaps Platformの従量課金を見積もりに載せてください。
導入時に決める認可方式と主要SDKの現行版
実装の入口はコードではなくGoogle Cloudの設定です。ここを飛ばすと、ビルドは通るのに実機でアンカーが解決されないという分かりにくい失敗に落ちます。
署名サーバの有無で決まる認可方式の選択
新規または既存のGoogle Cloudプロジェクトで「ARCore API」を有効化します。認可方式は2種類です。公式が推奨するKeyless authorizationは、サービスアカウントの鍵でJWTに署名し、APIへのアクセスを制御する自前のサーバを持つことが前提になります。署名サーバを運用できる体制があるならKeylessを選んでください。バックエンドを持たない構成では現実的でないため、その場合はAPIキー方式にしたうえでキーに制限をかけます。Androidアプリ側では play-services-location のバージョン16以上を宣言する必要があります。
主要SDKの現行版と更新内容
Geospatial APIのガイドはAndroid(Kotlin/Java)、Android NDK(C)、Unity(AR Foundation)、iOS、Unreal Engineの5系統で提供されています。スマートフォン向けとAndroid XR向けで、SDKの成熟度がはっきり分かれています。
| SDK | 現行版 | 公開日 |
|---|---|---|
| ARCore SDK for Android | 1.54.0 | 2026-04-22 |
| ARCore for Jetpack XR | 1.0.0-beta02 | 2026-08-12 |
スマートフォン向けのARCore SDKは落ち着いています。1.54.0の追加はJavaとC++の間でARCoreオブジェクトの所有権を受け渡すためのArCoreNativeInteropで、Geospatial周りの仕様変更は入っていません。1.53.0はバグ修正と性能改善のみ、1.52.0はAndroid 16 MR1との互換性確認が主な内容でした。Geospatial Creatorを使う場合はUnity 2022.3が前提としてcodelabに記載されています。Unity 6.3 LTSなど新しいエディタで進めるときは、ARCore Extensions側の対応状況を先に確認してください。
Android XRで非推奨になったGeospatialModeの定数と2系統の見分け方
変化が起きているのはAndroid XR側です。パッケージ androidx.xr.arcore のARCore for Jetpack XRは、2026年8月12日に1.0.0-beta02へ到達しました。ここまでのリリースノートで、Geospatial関連は次のように動いています。
- 1.0.0-alpha08(2025年11月19日)でVPS可用性とポーズ変換のGeospatial APIを追加。
- 1.0.0-alpha10(2026年1月28日)で
Geospatial.createPoseFromGeospatialPoseがOpenXR対応端末でも動作するよう変更。 - 1.0.0-alpha13(2026年5月6日)で
TrackingStateとVpsAvailabilityResultがandroidx.xr.arcoreへ移動し、androidx.xr.runtime側の型は非推奨に。 - 1.0.0-alpha14(2026年5月19日)で
GeospatialMode.VPS_AND_GPSがGeospatialMode.SPATIALを推奨として非推奨化。あわせて、IMUとGPSだけを使う低消費電力モードGeospatialMode.INERTIALが追加。
ここで詰まる人が出ます。スマートフォン向けの com.google.ar.core.Config.GeospatialMode が持つ定数は DISABLED と ENABLED の2つだけで、SPATIALもINERTIALも存在しません(該当リファレンスの更新日は2024年10月31日)。同じ「Geospatial API」という名前のまま2系統が並走しているため、Android XR向けの記事を読んでスマートフォンのコードに書き写すと、解決できないシンボルに突き当たります。判別はパッケージ名で行ってください。com.google.ar.core ならスマートフォン向け、androidx.xr.arcore ならAndroid XR向けです。
採用を見送るべき条件と国内検証が示した限界
Streetscape Geometryは、条件が合えば少ない実装量で強い体験を作れます。同時に、合わない案件でも「AR技術で解決できます」と提案されやすい領域でもあります。次のいずれかに当てはまるなら、この機能を軸にした企画は組まないでください。
- 主戦場が屋内。VPSが効かない以上、代替手段を最初から設計する必要があります。
- オフライン動作が要件。
ERROR_NETWORK_CONNECTIONがAPIに定義されているとおり、VPSはネットワーク接続が前提です。 - 建物の形状精度に体験が依存する。BUILDING_LOD_2でも煙突や換気口はメッシュ外に出ます。
- 地図・ルート検索・トラッキングが本来の要件で、AR表現は装飾。この場合はAmazon Location Serviceのような地図基盤サービスのほうが要件に対して素直です。
国内事例の扱いにも注意が要ります。日本語圏で公表された代表的な検証は、NTTコノキューが2023年5月11日に発表したものです。ウルトラセブンとキングジョーの戦闘シーンを題材に、ARオブジェクトの一部が隠れるオクルージョン表現、現実空間の建物に跳ね返る表現、特定の建物にARオブジェクトを貼り付ける表現の3つを挙げていました。ただし同じ発表資料に「『Streetscape Geometry』の『XR City』アプリへの実装、及び、本コンテンツの一般公開時期は検討中のため、未定となります。」と明記されています。技術検証であって、商用実装の告知ではありません。
その後の動きも押さえておく必要があります。NTTドコモは2026年2月10日、NTTコノキューのXR事業をドコモへ移管し、2026年3月31日にコノキューを解散、同年6月末に清算を結了する予定だと発表しました。XR事業自体はドコモで継続されます。つまり、国内で最も参照されてきた検証事例は、アプリ実装が未定のまま運営体制の再編を挟んだことになります。この分野の前例を根拠に社内を説得するのではなく、対象エリアでVPS可用性を実測したプロトタイプを先に見せる順序で進めてください。判断材料がエリア依存である以上、そのほうが早く結論に到達します。
よくある質問
Geospatial APIとは何ですか?
ARCoreの機能の一つで、端末のセンサーとGPSに加え、GoogleのVPS(Visual Positioning System)を使って端末の位置と向きを高い精度で求めるAPIです。求めた位置を基準に、緯度・経度・高度で指定するWGS84アンカー、地面や床からの高さで指定するTerrainアンカー、建物の屋上を基準にするRooftopアンカーの3種類を配置できます。Streetscape Geometryはこの上に載る機能で、周囲の建物と地形のメッシュを追加で取得します。
Geospatial APIの料金はいくらですか?
ARCore APIの利用自体に請求は発生しません。Googleは2022年5月の提供開始アナウンスで無償と案内しており、公式ドキュメントにも料金表はなく、示されているのは1分あたり1,000セッションの開始または100,000リクエストという使用量上限だけです。金額が立つのはGeospatial Creatorを併用する構成で、この場合はPhotorealistic 3D Tiles(Map Tiles API)とPlaces APIというGoogle Maps Platform側のAPIが対象になります。料金は改定されるため、確定前に最新の料金ページで確認してください。
ARCoreとは何で、何ができますか?
ARCoreはGoogleが提供するAR開発プラットフォームで、Android(Kotlin/Java)、Android NDK(C)、Unity(AR Foundation)、iOS、Unreal Engineから利用できます。平面検出や環境光の推定といった基本機能に加え、本記事で扱ったGeospatial API、複数ユーザーで同じARコンテンツを共有するCloud Anchorsなどを提供します。Android XR向けには androidx.xr.arcore という別パッケージが用意され、2026年8月12日に1.0.0-beta02が公開されています。
対応エリアの一覧はどこかで確認できますか?
使える場所をまとめた一覧は公開されていません。判定は緯度経度単位の照会で行う設計で、Session.checkVpsAvailabilityAsync に座標を渡すと AVAILABLE か UNAVAILABLE などが返ります。エリア調査は、候補地点の座標を並べてこの照会を回し、結果を地図に落とす形になります。基盤がストリートビューの撮影データである以上、屋内や車両が入れない私道は外れやすい点も設計に織り込んでください。
Streetscape Geometryを有効にしてもメッシュが返らないときの確認点は?
最初に確認すべきは2つのモードです。Config.StreetscapeGeometryMode.ENABLED だけでは足りず、Config.GeospatialMode.ENABLED も同時に必要です。次にVPSの可用性を確認し、ERROR_NOT_AUTHORIZED が返る場合はGoogle CloudでARCore APIが有効になっているか、認可方式の設定が正しいかを見直します。play-services-location のバージョン16以上を宣言しているかも確認してください。参照するサンプルコードがAndroid XR向けの androidx.xr.arcore を前提にしていないかも、あわせて点検が必要です。