TL

Cloud Service

Immersive Stream for XR

Unreal Engine 製の3D/AR体験をクラウドの GPU でレンダリングしてストリーミングし、アプリ導入なしにブラウザや URL から高品質な没入体験を届けられるマネージドサービス。

中級パフォーマンス効率コスト最適化運用上の優秀性
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.Unreal Engine の3D/AR体験をクラウド GPU でレンダリングし、端末へ映像として配信する。
  • 2.ストリームコンテンツ(ビルド)とサービスインスタンス(リージョン別のキャパシティ)の2層で構成。
  • 3.端末スペックに依存せず、URL アクセスだけで高品質な没入体験を提供できる。

解決する課題

高品質な3D/AR体験を、端末側の処理能力に頼らず幅広いデバイスへ届けたいときに使います。

  • 重い3D/ARコンテンツを低スペック端末でも動かしたい。レンダリングをクラウドの GPU に肩代わりさせ、端末には映像だけを送る
  • アプリのインストールを不要にしたい。URL やブラウザからアクセスするだけで没入体験を開始させたい
  • Unreal Engine で作り込んだ表現品質をそのまま配信したい。端末の GPU 性能差による見た目の劣化を避けたい
  • レンダリング用の GPU 基盤を自前で運用したくない。インスタンスの確保・スケール・障害対応をマネージドに任せたい
  • アクセス数の波に合わせて GPU キャパシティを伸縮させたい。常時フル稼働の固定費を避けたい

主要概念と用語

  • ストリームコンテンツ (Stream Content): 配信対象となる Unreal Engine ベースの体験ビルド。専用テンプレートで作成したプロジェクトをビルドし、サービスへ登録する。バージョンを持ち、更新時は新しいバージョンを差し替える
  • サービスインスタンス (Service Instance / Stream Instance): ストリームコンテンツを実際に配信する実行リソース。どのリージョンで、どれだけの キャパシティ(同時セッションを支える容量)を確保するかを定義する
  • キャパシティ (Capacity): そのリージョンで同時に提供できるセッションの容量。需要に対して不足すると新規セッションが受けられない
  • オートスケーリング (Autoscaling): リージョン単位でキャパシティを需要に応じて自動増減させる仕組み。最小キャパシティやバッファを指定し、急なアクセス増に備えられる
  • フォールバック URL (Fallback URL): インスタンスが利用不可・満杯のときに利用者を案内する代替の遷移先。体験が出せないときの受け皿として設定する
  • リージョン (Region): レンダリング GPU を配置する地理的拠点。利用者に近いリージョンを選ぶほど遅延を抑えられ、複数リージョンを組み合わせて配信できる
  • ストリーミング再生: 端末側ではレンダリング済みの映像を受け取り、タッチ/クリックなどの操作をクラウドへ返す。インタラクティブな操作とクラウドレンダリングを往復させる方式

仕様・制限・クォータ

  • コンテンツは Unreal Engine 製で、専用テンプレートをベースに制作したプロジェクトをビルドして登録する。任意の動画やゲームエンジンを直接流せるわけではない
  • GPU を伴うリージョナルなリソースで、利用できるリージョンは限られる。配信対象のユーザー所在地に近いリージョンを選ぶ
  • サービスインスタンスはリージョンごとにキャパシティを定義し、複数リージョンを束ねて1つのインスタンスとして運用できる。オートスケーリングはリージョン単位で設定する
  • 同時セッション数は確保したキャパシティに依存し、超過分は配信できない。需要規模に対してキャパシティやオートスケーリング設定を見積もる必要がある
  • GPU キャパシティはプロジェクト単位のクォータの影響を受ける。大規模配信ではクォータの引き上げ申請が必要になる場合がある
  • 具体的なクォータ値・対応リージョン・対応 Unreal Engine バージョンは変動するため、公式ドキュメントで最新情報を確認する

内部の仕組み

Immersive Stream for XR は、重い3D/ARレンダリングをクラウド側の GPU で実行し、その結果を映像ストリームとして端末へ送り届けるサービスです。端末は受け取った映像を表示し、ユーザーの操作(タップ・ドラッグなど)をクラウドへ返します。これによりレンダリング負荷を端末から切り離し、端末スペックに依存せず一定の品質を提供できます。

配信の構成は大きく2層に分かれます。1つは ストリームコンテンツで、Unreal Engine の専用テンプレートで作った体験をビルドしたもの。もう1つは サービスインスタンスで、そのコンテンツをどのリージョンでどれだけのキャパシティで動かすかを定義します。利用者がアクセスすると、インスタンスは近いリージョンのキャパシティからセッションを割り当て、GPU 上でコンテンツをレンダリングしてストリーミングを開始します。

需要の波に対しては オートスケーリングでリージョンのキャパシティを増減させ、最小キャパシティやバッファを設定して立ち上がりの遅延を抑えます。万一インスタンスが満杯・利用不可のときは フォールバック URL へ利用者を誘導し、体験が出せない場面の受け皿にします。GPU 基盤の確保・スケール・冗長性は Google 側が管理するため、利用者はコンテンツとインスタンス設定に集中できます。

端末スペックに依存しない品質

レンダリングをクラウド GPU 側に寄せるため、ハイエンド GPU を持たない端末でも Unreal Engine の作り込んだ表現をそのまま体験させられます。配信品質は端末性能ではなく、選んだリージョンの近さとネットワークのレイテンシに左右されると考えると設計しやすいです。

設計パターン / ベストプラクティス

  • ユーザーの所在地に近いリージョンを選ぶ。クラウドレンダリングはネットワーク往復の遅延が体感を左右するため、対象ユーザーが多い地域のリージョンを優先する
  • 需要が読みにくい配信はオートスケーリングを有効化し、最小キャパシティとバッファで立ち上がり遅延を抑える。キャンペーンやイベントの開始時刻に合わせてキャパシティを見積もる
  • フォールバック URL を必ず用意する。満杯・障害時に「体験が始まらない」だけで終わらせず、案内ページや代替手段へ誘導する
  • コンテンツ更新はバージョンで管理し、新バージョンをビルドして差し替える運用にする。検証用と本番用を切り分けると安全
  • アクセス導線は URL ベースで設計する。アプリ導入なしに到達できる利点を活かし、QR コードや短縮 URL からの流入を想定する

運用・監視

  • Cloud Monitoring / Cloud Logging でインスタンスの状態、セッションの割り当て状況、エラーを監視する。キャパシティ不足で新規セッションが弾かれていないかを重点的に見る
  • 需要に対するキャパシティの過不足を主要指標として追う。満杯による取りこぼしが増えたらキャパシティやオートスケーリング設定を見直す
  • 配信していない期間はインスタンスのキャパシティを抑える運用が、GPU コストを抑える実用的な手段になる。常時フル稼働は必要な時間に絞る
  • リージョン設定・キャパシティ・コンテンツのバージョンを再現可能な手順として標準化し、障害時に素早く同等構成を復元できるようにする

コスト

  • 課金は概ね確保した GPU キャパシティと、それを稼働させている時間に依存する。高い同時セッション容量を常時確保するほど費用が増える
  • 配信しない時間帯のキャパシティを抑えることが最も効くコスト最適化。需要のピークに合わせてオートスケーリングで伸縮させ、谷の固定費を削る
  • リージョンを増やすほど可用性と低遅延は得られるが、その分のキャパシティ確保が積み上がる。配信品質とコストのトレードオフでリージョン構成を決める
  • 具体的な単価は変動するため、断定せず料金ページで最新の体系を確認する
確保しっぱなしの GPU に注意

GPU キャパシティを高めに確保したまま放置すると、アクセスが無くてもコストが発生し続けます。イベント終了後はキャパシティを下げる、オートスケーリングの最小値を必要最小限にするなど、確保量を需要に合わせて見直してください。

セキュリティ

  • API 呼び出しやインスタンス操作は IAM で最小権限に制御する(AWS の IAM ロール相当)。コンテンツやインスタンスの作成・更新を担うサービスアカウントには必要な権限のみを付与する
  • コンテンツのビルド成果物(Unreal Engine ビルド)の保管先を保護し、未公開の体験や検証中のビルドが外部に露出しないようにする
  • アクセス導線となる URL の取り扱いに注意する。限定公開の体験は、URL の配布範囲や前段の認証・認可の設計で到達範囲を制御する
  • 保存データは Google 管理鍵で既定暗号化される。組織のポリシーに応じて鍵管理やアクセス監査の要件を満たす構成を検討する

関連サービス・比較

Immersive Stream for XR は「3D/AR体験のクラウドレンダリング&ストリーミング」を担います。同じ動画系メディアでも、撮影済み映像のファイル変換を行う Transcoder API とは目的が大きく異なります。前者はインタラクティブな3D体験のリアルタイムレンダリング、後者は VOD 用のファイルトランスコードです。

観点Immersive Stream for XRTranscoder API
処理対象Unreal Engine の3D/AR体験アップロード済みの動画ファイル
処理内容クラウド GPU でレンダリングしストリーミング解像度・ビットレートへのファイル変換
双方向性操作を返すインタラクティブ配信一方向の VOD 向け変換
主なリソースストリームコンテンツ/サービスインスタンスジョブ/ジョブテンプレート
主な用途没入型の3D・ARプロモーション体験オンデマンド配信用の事前変換
役割で使い分ける

「インタラクティブな3D・AR体験を端末スペックに依存せず届けたい」なら Immersive Stream for XR、「録画済み動画を各種フォーマットへ変換したい」なら Transcoder API、と目的で切り分けると整理しやすいです。

ハンズオン / CLI例

# 前提: Immersive Stream for XR API を有効化し、Unreal Engine テンプレートで
#       作成した体験をビルド済み(ビルド成果物の場所を content 登録に使う)

# 1) ビルド成果物からストリームコンテンツを作成(バージョンを付与)
gcloud immersive-stream xr contents create my-content \
  --content-build-source-uri=gs://my-bucket/builds/v1/ \
  --async

# 2) コンテンツを配信するサービスインスタンスを作成
#    リージョンごとにキャパシティとオートスケーリングを指定
gcloud immersive-stream xr instances create my-instance \
  --content=my-content \
  --version=v1 \
  --add-region="region=us-west4,capacity=5,enable_autoscaling=true,autoscaling_buffer=2,autoscaling_min_capacity=3" \
  --add-region="region=us-central1,capacity=3" \
  --async

# 3) インスタンスの状態・配信用 URL・リージョン構成を確認
gcloud immersive-stream xr instances describe my-instance

# 4) キャパシティや満杯時のフォールバック URL を更新
gcloud immersive-stream xr instances update my-instance \
  --update-region="region=us-west4,capacity=8" \
  --fallback-url="https://example.com/unavailable"

# 5) 実行中の操作(作成・更新)を一覧して進捗を追う
gcloud immersive-stream xr operations list --location=us-west4

Google Cloud Service

Immersive Stream for XRを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

メディア

比較で見る軸

クラウド: Google Cloud / カテゴリ: メディア / 難易度: intermediate

導入後に効く点

ストリームコンテンツ(ビルド)とサービスインスタンス(リージョン別のキャパシティ)の2層で構成。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Google Cloud
カテゴリ
メディア
難易度
intermediate
関連資格
設計柱
performance / cost / operational

判断チェックリスト

  • 自社の用途が「メディア / performance」に近いか確認する。
  • 強みである「Unreal Engine の3D/AR体験をクラウド GPU でレンダリングし、端末へ映像として配信する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

メディアperformancecostoperational