動く3DGSは「変わった所だけ」送れば軽くなる?〜4D Gaussian Splatting の配信の形式と使われている例を調べた
ふだん、ローカルでの生成AIの話をメインに記事にしていますが、今回は写真から立体を作る技術 3D Gaussian Splatting の、動く版の話です。人が歌ったり踊ったりする場面を、好きな角度から眺められる映像が出てきています。こうした映像を、ライブのように配信することはできるのでしょうか?
ステージの背景はほとんど動かず、動くのは人と照明くらいです。それなら、最初の1コマを丸ごと送り、あとは変わった所だけを送れば、データを小さくできそうです。本記事では、この「基準の1コマ+変わった所だけ」で送る方式について、研究の論文とファイル形式の標準化、実際に使われている例を調べました。
2026年9月28日時点の内容です。
3DGS と 4DGS とは?〜言葉の定義
3DGS〜ぼかしの粒で作る立体
3D Gaussian Splatting(スリーディー・ガウシアン・スプラッティング、以下 3DGS)は、写真から立体の場面を作る手法です。いろいろな角度から撮った写真をもとに、場面を小さな色付きのぼかし(ガウシアン)の集まりとして組み立てます。1つの粒は、位置や向き、大きさ、透け具合、色の情報を持っています。できあがった場面は、写真に近い見た目のまま、好きな位置から眺められます。
4DGS〜時間の向きに伸ばした 3DGS
3DGS は止まった場面を表します。これに時間の軸を足し、動く場面を表せるようにしたものが 4D Gaussian Splatting(以下 4DGS)と呼ばれます。縦、横、奥行きの3つに時間を足して4D、という名前です。作るには、場面を囲むように何十台ものカメラを並べ、同時に撮影します。
フレームと差分
フレームは、動画の1コマのことです。1秒間に何コマを表示するかを FPS(フレーム毎秒)で表し、30 FPS なら1秒に30コマです。差分は、前のコマから変わった所だけを取り出したデータを指します。今回の方式では、最初のコマ(基準フレーム)だけを丸ごと作り、2コマ目からは差分だけを作ります。
コーデック
コーデックは、動画を小さく縮めて送り、受け取った側で元に戻すための決まりごとです。H.264(エイチ・ニーロクヨン)はその代表で、スマホやパソコンには、これを専用の回路で速く戻す仕組みが入っています。ふつうの動画も、実は毎コマを丸ごと送ってはおらず、前のコマとの差を使って縮めています。
背景も人も丸ごと(重い)
動いた粒の差分だけ
動いた粒の差分だけ
新しく現れた物は粒を足す
何をどう調べたのか
「基準フレーム+差分」で動く 3DGS を送る方式について、次の3つを調べました。当ブログでは動かしておらず、論文と公式の発表、報道を読んだ調査です。
- 研究の論文で、どんな形のデータを作り、1コマあたり何MBになっているか。毎コマ丸ごと作った場合と比べてどれだけ小さいか
- 静止した 3DGS と動く 4DGS で、ファイル形式の標準がどこまで決まっているか。形式ごとにファイルがどれだけ小さくなるか
- 実際の作品やサービスで、どこで使われているか
論文は、2024年に発表された4本(3DGStream、QUEEN、HiCoM、V³)を取り上げました。数値は論文の本文かアブストラクト(要旨)で確かめたものだけを載せています。論文の数値は、場面やカメラの台数、GPU といった条件がそれぞれ違うため、横に並べても勝ち負けは決められません。
差分として何を送るのか〜論文4本が持つデータの形
4本とも、基準になる 3DGS を作り、続くコマはそれとの違いで表す点は共通です。違うのは、コマ間の違いをどんな形で持つかでした。
3DGStream(CVPR 2024)〜粒の動かし方を小さなネットワークで持つ
3DGStream は、2コマ目以降で粒そのものは作り直さず、既にある粒を「どれだけ動かし、どれだけ回すか」だけを学習します。この動かし方は、NTC(Neural Transformation Cache)と呼ぶ小さなニューラルネットワークに覚えさせます。前のコマに無かった物が現れたときだけ、そのコマ専用の粒を足します。
送るデータは「最初のコマの 3DGS」+「コマごとの NTC」+「足した粒」という組み合わせです。
QUEEN(NeurIPS 2024・NVIDIA)〜粒ごとの差を間引いて持つ
QUEEN は、前後のコマで各粒の値(位置・色など)がどれだけ変わったかを、そのまま学習します。位置の差は、動いていない粒の分をゼロにして間引きます。位置以外の差は、少ない段階の値に丸めて(量子化して)小さくします。
論文の要旨には、場面のうち止まっている部分と動いている部分を見分ける信号を使う、と書かれています。背景のように止まっている部分を見分けて差を間引く、という考え方です。
HiCoM(NeurIPS 2024)〜まとまった動きとして持つ
HiCoM は、隣り合うコマの間の動きを、近くの粒はまとまって動くという性質を使い、少ない数の値で表します。論文名の「階層的でまとまった動き(Hierarchical Coherent Motion)」がこの仕組みを指しています。
V³(SIGGRAPH Asia 2024)〜ふつうの動画に置き換えて持つ
V³ は、動く 3DGS を「2Dの動画」として扱い直します。粒の値(位置や色など)を、値の種類ごとに画像のマス目へ並べます。コマごとにこの画像を作れば、値の種類ごとの動画ができます。
その動画を H.264 で縮めて送るため、スマホやパソコンに入っている動画用の回路で元に戻せます。コマ間の差を使って縮める作業は、既存のコーデックに任せる形です。
1コマあたり何MB?〜論文が示した大きさと速さ
論文に書かれた値を並べました。学習時間は、1コマ分の差分を作るのにかかる時間です。表示の速さ(FPS)は、できたデータを画面に描く速さを指します。
| 方式 | 1コマあたりの大きさ [MB] | 1コマの学習時間 [秒] | 表示の速さ [FPS] | 論文に書かれた条件 |
|---|---|---|---|---|
| (比べる基準)毎コマ丸ごと 3DGS を作る | 47.1 | 約498(8.3分) | 390 | 3DGStream の論文の比較表。N3DV・RTX 3090 |
| 3DGStream | 7.6 | 約12 | 215 | N3DV(カメラ21台)・RTX 3090 |
| QUEEN | 0.7 | 5未満 | 約350 | 動きの大きい複数の場面。GPU の記載は要旨に無し |
| HiCoM | (最新の手法より約85%小さい) | 平均2未満 | (要旨に記載無し) | 複数のコマを並べて同時に学習した場合 |
| V³ | 0.51〜0.53 | 約49〜53(0.82〜0.89分) | 435(RTX 3090)/96(iPad・M2)/27(iPhone・A15) | 1920×1080 で表示 |
同じ条件で比べられる組は2つあります。3DGStream の論文では、研究でよく使われる評価用の多視点動画 N3DV で、毎コマ丸ごと 3DGS を作ると1コマ47.1MBで、3DGStream は7.6MB でした。約6分の1です。V³ の論文では、別のデータで3DGStream と V³ を同じ条件で並べています。V³ は0.51〜0.53MB と、3DGStream(7.6MB)の約14〜15分の1でした。
学習時間は逆の順になっています。V³ の論文の表では、3DGStream が1コマ約7〜11秒(0.12〜0.19分)、V³ が約49〜53秒でした。3DGStream 自身の論文の約12秒とは、使ったデータが違います。小さく縮めるほど、作るのに時間がかかる形です。
3DGStream と V³ は、表示の速さを RTX 3090 で測っています。3DGStream は、一般向けでは上位の GPU である RTX 3090 で、1コマの差分を十数秒以内で作り、1秒に200コマ以上描けると報告しています。V³ は iPhone(A15 Bionic、iPhone 13 などに搭載)でも1秒に27コマを描いたと書かれており、スマホで見られる所まで来ています。
回線に流すとどのくらい?
1コマあたりの大きさに、1秒のコマ数を掛けると、回線に流す量の目安が出ます。仮に30 FPS で流すとして、当ブログで計算しました(1MB(メガバイト)=8Mb(メガビット)として計算)。比べる目安として、ふつうの動画のライブ配信で YouTube が推奨している値も並べます。
| 方式 | 1コマあたり [MB] | 30 FPS で流した場合 [Mbps] |
|---|---|---|
| 毎コマ丸ごと 3DGS | 47.1 | 約11,304 |
| 3DGStream | 7.6 | 約1,824 |
| QUEEN | 0.7 | 約168 |
| V³ | 0.51〜0.53 | 約122〜127 |
| (参考)DNE × Gracia「Open」の配信 | — | 17〜75(公表値) |
| (参考)YouTube のライブ配信 1080p・30fps | — | 10(H.265・AV1 の推奨値。H.264 は 14) |
| (参考)YouTube のライブ配信 4K・30fps | — | 30(H.265・AV1 の推奨値。H.264 は 42) |
論文の中で最も小さい V³ でも、YouTube の 4K ライブの推奨値の約4倍です。後で紹介する DNE と Gracia の配信は17〜75 Mbps と公表されており、論文の値をそのまま流すより小さく、4K ライブの推奨値の0.6〜2.5倍ほどでした。製品でどう縮めているのかは、公開された情報からは分かりませんでした。
ファイル形式は決まっている?〜静止用と動く用の標準化
静止した 3DGS を入れるファイル形式は、ここ1年ほどで固まってきました。一方、動く 4DGS をどう入れるかを決めた公開の標準は、調べた範囲では見つかりませんでした。論文4本も、それぞれ自前の形でデータを持っており、互いに読み合える形ではありません。
| 形式 | 作ったところ | 中身 | .ply と比べた大きさ | 動く場面 |
|---|---|---|---|---|
| .ply | — | 粒の値をそのまま並べた形。1粒に59個の数値 | 基準(1粒 約240バイト) | 1コマ1ファイルの連番で使われる例がある |
| .splat | antimatter15(個人の開発者) | 見る角度で色が変わる情報を捨て、1粒32バイトに詰めた形 | 約7〜8分の1 | 記載無し |
| .spz | Niantic | 値を丸めて、圧縮方式 ZSTD で縮める。2026年5月5日に SPZ 4 を公開 | 約10分の1 | 公式の説明に記載無し |
| .sog | PlayCanvas | 値を WebP 画像に並べて保存 | 約15〜20分の1 | 公式の説明に記載無し |
| KHR_gaussian_splatting | Khronos Group | 3Dデータの共通形式 glTF の拡張。2026年2月3日にリリース候補を発表、現在は承認済み | — | 仕様書に記載無し |
| Gaussian Splat Coding | MPEG | 圧縮方式の標準化を検討中 | — | 当面は静止。動く方は長い目での検討対象 |
数字にすると、100万個の粒でできた場面は、.ply で約240MB、.spz で約24MB、.sog で約12〜16MB ほどです(当ブログの計算)。実際の例として、SuperSplat の開発元は、440万個の粒の場面が .ply で990MB だったと書いています。1粒あたり約225バイトで、計算とおおむね合います。
この数字を 4DGS に当てはめると、静止用の形式だけで縮める限界も見えてきます。3DGStream の論文の47.1MB を .sog で20分の1にしても、1コマ約2.4MB です。差分方式の QUEEN(0.7MB)や V³(0.51〜0.53MB)より大きいままでした(当ブログの計算)。
V³ が画像と動画に並べ直したのと、SOG が画像に並べて保存するのは、よく似た発想です。粒の値を画像のマス目に置けば、長年磨かれてきた画像や動画の圧縮をそのまま使えます。
MPEG の動き
MPEG は、H.264 などの動画の規格を決めてきた国際的な会議です。公式ページでは、3DGS の圧縮について「当面は静止した場面の相互運用に集中し、動く場面は長い目で検討する」としています。
一方、3DGS 関連の報道サイト Radiance Fields(2026年8月4日)は、動く 3DGS の試験用素材の募集が決まったと伝えています。決まったのは、ジュネーブでの第155回会合です。締切は2026年10月15日で、圧縮技術そのものの募集(Call for Proposals)は準備中と伝えています。標準の形式ができるのは、その先の話です。
動く 3DGS はどこで使われている?〜作品とサービスの実例
動く 3DGS が使われた例は、いくつか確認できました。ただし、どれも「収録してから配信」か「撮影の実演」で、生中継で配信した例は見つかりませんでした。
| 例 | 中身 | 生中継か | 出どころ |
|---|---|---|---|
| A$AP Rocky「Helicopter」MV | Evercoast が RGB-D カメラ56台で人物を撮影。約30分ぶんの映像を .ply の連番で書き出し、CG と合成 | いいえ(制作に使用) | 報道(Radiance Fields) |
| DNE × Gracia「Open」 | 歌手 Amy May の4分の演奏。ブラウザやスマホ、Meta Quest 3 でアプリ無しで再生。17〜75 Mbps | いいえ(収録済み) | 報道(CG Channel、2026年4月27日) |
| 4DV.ai × OBSBOT | NAB Show 2026 で OBSBOT Tail 2 約60台の撮影の仕組みを展示。来場者は VR ゴーグルで見た | いいえ(撮影と復元の実演) | OBSBOT 公式/報道(CineD) |
| SplatLabs | ライブや競技を 60fps・遅延50ミリ秒未満で配信できると案内 | 案内のみ。導入先の記載無し | 自社サイト |
A$AP Rocky「Helicopter」
ミュージックビデオの人物のほぼすべてを、Evercoast の仕組みで立体として撮影したと報じられています。カメラは RGB-D(色と奥行きを同時に撮るもの)56台です。Dell のワークステーション2台で同期させました。書き出しは .ply の連番で、1コマごとに丸ごとのファイルです。映像制作の素材として 4DGS を使った例で、差分で配信した例とは別物と考えられます。
DNE × Gracia「Open」
撮影スタジオの DNE と Gracia が公開した、4分の音楽演奏です。CG Channel は「ブラウザで再生できる、リアルタイムに配信される初の 4DGS の音楽演奏」と紹介しています。再生には WebGPU(ブラウザで GPU を使う仕組み)を使い、パソコンやスマホ、Meta Quest 3 で見られます。
ここでの「リアルタイムに配信」は、収録済みの演奏をその場で流しながら再生する、という意味です。演奏そのものは事前に撮影されています。Gracia は 3DGS のビューアーも無料で配信しており、関連記事で触れています。
4DV.ai × OBSBOT
2026年の放送機器の展示会 NAB Show で、4DV.ai と OBSBOT が、持ち運べる撮影の仕組みを展示しました。OBSBOT の発表では、カメラは約60台で、本番では200台以上まで増やせる設計とされています。使い道として、競技場やコンサートのステージ、映画の撮影現場が挙がっています。
CineD の記事では、4DV.ai の Jiaming Sun 氏が、1コマずつ別々に作る 4DGS の弱点を語っています。「時間をまたいで情報を共有せず、場面の大半がある瞬間から次の瞬間へほとんど変わらないという事実を無視している」という指摘です。今回の「変わった所だけ送る」という発想と、向いている方向は同じです。
SplatLabs
ライブやスポーツ、カンファレンスを、ブラウザで立体のまま生中継できると案内しているサービスです。サイトには、60fps、遅延50ミリ秒未満、1コマの描画3ミリ秒と書かれています。一方で「最初の協力先を募集中」「early Alpha(初期の試用版)」とあり、導入先の記載はありません。数値の測り方も公開されておらず、第三者の検証は見つかりませんでした。
背景が動かないライブなら差分方式は有利?
ここからは、調べた内容をもとにした当ブログの考察です。
ステージの背景は、1コマ目で丸ごと作ってしまえば、2コマ目以降はほとんど送る必要がありません。4本の論文も「最初のコマを1回だけ重く作り、以降は違いだけを作る」形なので、背景が動かない場面とは相性が良いと考えられます。QUEEN が止まっている部分と動いている部分を見分けて差を間引くのも、同じ考え方の上にあります。
ただし、ライブでは背景の形は動かなくても、照明で色が変わります。色が変われば、背景の粒も「変わった所」に数えられるはずです。照明が大きく動く演出ほど、差分は小さくならないと考えられます。
この考えが正しいなら、同じステージでも、照明を固定した場面のほうが1コマあたりの大きさは小さくなるはずです。照明を固定しても大きさが変わらなければ、差分の大きさを主に決めているのは、人の動きのほうだと考えられます。今回読んだ論文には、この比べ方をした結果はありませんでした。
もう1つの壁は、作る速さです。1秒に30コマを生中継するには、1コマの差分を30分の1秒(約0.033秒)で作る必要があります。今回の論文で学習時間が最も短い HiCoM でも平均2秒未満です。2秒なら約60倍、QUEEN の5秒なら約150倍、3DGStream の12秒なら約360倍の開きがあります(当ブログの計算)。いま使われている例が「収録してから配信」に集まっているのは、この差が理由の1つと考えられます。
2026年10月の追記:9月に出た配信の実例
記事を書いたあと、動く 3DGS の配信で動きがありました。NEXIA Entertainment がライブ・スポーツ映像向けの商用 4DGS 配信を始め、ByteDance の Multimedia Lab がライブと見逃し配信の両方に対応する 6DoF 映像の 4D メディアシステムを公開しました。IBC 2026 では Nokia が、MPEG の V3C・GS4 で符号化した動くスプラットを MPEG DASH で配信し、Samsung と XREAL の端末で描画するデモを見せています。研究側では、Media over QUIC で 3DGS を段階的に配る MoQSplat(arXiv 2609.18624)も出ました。いずれも試しておらず、Radiance Fields の月次まとめと各社の発表を読んだ範囲です。 出典: Radiance Fields「Gaussian Splatting in September 2026」ほか各社発表(2026年9月)この記事で言えないこと
- 論文の数値は、当ブログでは再現していません。論文ごとに場面やカメラの台数、GPU が違い、横に並べても優劣は言えません
- QUEEN の GPU とデータセット名、HiCoM の比較相手は、今回読んだ要旨に書かれておらず確認できていません
- 30 FPS で流した場合の Mbps と、形式ごとの100万粒あたりの大きさは、当ブログの単純な計算です。実際の配信では、さらに圧縮や間引きが入ると考えられます
- DNE と Gracia の配信が、どんな形式・どんな差分の持ち方をしているかは公開されていませんでした
- ライブを 4DGS の差分方式で生中継し、商用で運用している例は見つかりませんでした。調べた範囲で見つからなかった、という意味です
- 照明の変化で差分が大きくなる、という点は当ブログの推測で、実測や論文の裏付けはありません
まとめ〜「変わった所だけ送る」はどこまで来ている?
動く 3DGS を「基準の1コマ+変わった所だけ」で送る方式は、2024年の論文で形が見えてきました。差分の持ち方は論文ごとに違い、次の4つに分かれています。
- 粒の動かし方を小さなネットワークで持つ(3DGStream)
- 粒ごとの差を間引いて持つ(QUEEN)
- まとまった動きとして持つ(HiCoM)
- ふつうの動画に置き換えて持つ(V³)
1コマあたりは0.5〜7.6MB ほどと報告されています。同じ条件で比べた例では、3DGStream が毎コマ丸ごと作る場合(47.1MB)の約6分の1、V³ はその 3DGStream のさらに約14〜15分の1でした。30 FPS で流すと約122〜1,824 Mbps で、ふつうの動画の 4K ライブ(30 Mbps)より、まだ4倍以上大きい計算です。
ファイル形式は、静止した 3DGS 向けが固まりつつある段階で、動く 4DGS 向けの標準はまだありません。使われている例は、ミュージックビデオの制作や、収録した演奏の配信までで、ライブの生中継の実運用は確認できませんでした。
| こんな人は | 次にできること |
|---|---|
| まず動く 3DGS を見てみたい | DNE と Gracia の「Open」を、ブラウザや Meta Quest 3 で再生してみる |
| 自分の GPU で作る側を試したい | 論文のうち 3DGStream と V³ は RTX 3090 で測っている。まずは2本の論文で、自分の GPU に近い条件の数値を確かめる |
| ライブ配信の仕事で使えるか見極めたい | いまは標準も実運用の例も無い段階。MPEG の募集(締切2026年10月15日)以降の動きを待つのが無難 |
| 静止した 3DGS で十分 | 動く方を追う必要はない。.spz や .sog で十分に小さくできる |
動く 3DGS の差分を作る作業は、論文では一般向けの RTX 3090 でも1コマ十数秒以内に収まっています。映像の世界でも、自分の PC の GPU で何ができるかが、これから問われてくるのではないでしょうか。
参考にしたサイト
- 3DGStream(arXiv)/3DGStream の本文(HTML 版・比較表)/3DGStream のプロジェクトページ
- QUEEN(NeurIPS 2024)/QUEEN のプロジェクトページ(NVIDIA)
- HiCoM(arXiv)
- V³(arXiv)/V³ の本文(HTML 版)
- PLY 形式(PlayCanvas)/.splat 形式(antimatter15/splat)/SuperSplat 3.0 のリリースノート(990MB の例)
- SPZ 形式(PlayCanvas)/SPZ 4 の発表(Niantic Spatial)
- SOG 形式(PlayCanvas)
- KHR_gaussian_splatting の発表(Khronos Group)/仕様書(GitHub)
- Gaussian Splat Coding(MPEG)/MPEG の素材募集(Radiance Fields)
- A$AP Rocky「Helicopter」(Radiance Fields)
- DNE × Gracia「Open」(CG Channel)
- 4DV.ai × OBSBOT(OBSBOT)/4DV.ai × OBSBOT(CineD)
- SplatLabs
- YouTube のライブ配信のエンコーダ設定(推奨ビットレート)