2026年5月5日 – Niantic Spatialは、3D Gaussian Splatting向けの圧縮フォーマットの最新版となる「SPZ 4」を発表しました。
これまでの経緯
2024年後半にNiantic社から「SPZ」フォーマットがオープンソース化された際、同社はこれを「3D Gaussian SplattingのためのJPG」と表現していました。
これは、SplatデータをPLY形式と比較して約10分の1のサイズに圧縮し、どこでも簡単に共有できるように設計された実用的な単一フォーマットです。モバイルデバイスから直接Gaussian Splatを共有することを現実的なものにし、幅広い普及を可能にするコンパクトでポータブルなフォーマットとして定着しました。
その後のアップデートでは、圧縮効率の向上や仕様の安定化、そしてレンダリングエンジンやWebパイプライン、下流システムとの互換性拡大など、フォーマットの成熟に焦点が当てられてきました。
それ以来、Adobe Photoshopのユーザーだけでも過去2ヶ月間で約80万個のSPZファイルが作成されるなど、広く利用されるようになりました。（後述）現在ではWeb環境、リアルタイムエンジン、ロボティクスパイプライン、モバイルプラットフォームなど、当初の想定を遥かに超える大規模で複雑なシーンで活用されています。
SPZ 4 の技術的な進化と新機能
より大規模なシーンと、高速なエンコーディング
発表によると、SPZ 4 ではエンコード速度が約 3〜5 倍、エンドツーエンドの読み込み速度が約 1.5〜2 倍に向上しています。非圧縮の PLY ファイルと比べてサイズを 1/10 に抑えられるという利点はそのままに、開発者が品質を細かく調整できる新しいコントロール手段が追加されました。
これにより、同じフォーマットでありながら「最高品質を重視するワークフロー」と「効率を最優先するワークフロー」のどちらにも柔軟に対応できるようになっています。
この今回の最大の変更は、ファイル圧縮の仕組みそのものにあります。
初期の SPZ では、ペイロード全体が 1 つの GZip ストリームで圧縮されていました。これは、当時主流だった「スマートフォンでスキャンした数十万ポイント規模の Splat データ」には十分でしたが、圧縮と解凍が単一のCPUコアで行われるため、数百万ポイントに及ぶ大規模なキャプチャデータでは処理に時間がかかりすぎるという課題がありました。
SPZ 4 では、このボトルネックを解消するために GZip から ZSTD への移行が行われ、さらに 6 つの並列ストリームとして処理されるようになりました。
各ストリームは、位置、色、スケール、回転、アルファ、球面調和関数（SH）の各属性ごとに独立して割り当てられています。それぞれが個別に圧縮されたバッファとして保存され、ファイルの先頭には小さな目次（インデックス）が配置されます。
これにより、パーサーやローダーは、ファイルを事前に解凍したりスキャンしたりすることなく、圧縮された各属性ストリームのサイズとレイアウトを迅速に特定できるようになりました。結果として、エンコードとデコードの処理が複数コアでスケーラブルに実行される仕組みとなっています。
公式に公開された、8.5 GB / 3,400万ポイントのPLYデータを使用したベンチマーク結果は以下の通りです。
| フォーマット | エンコード時間 | ファイルサイズ（ベースライン比） |
|---|---|---|
| SPZ 3 (ベースライン) | 3分 26秒 | – |
| SPZ 4 | 1分 8秒 (約3倍高速) | 2.5% 縮小 |
複数コアを活用して CPU 使用率を最大化することで、より小さなファイルサイズと大幅なエンコード速度の向上が実現されているようです。デコード処理も同様に並列化されており、従来の PLY ローダーや SPZ デシリアライザーで課題となっていた「1,000 万ポイントの上限」も撤廃されました。SPZ 4 では、数千万規模の Gaussian を問題なく扱えるようになっています。
こうした高速化は、後続の処理にも良い影響を与えています。並列デコードの導入により、テストシーン全体でレンダリングまでの時間（解凍とローダーへの読み込み）が明確に短縮され、約 33〜52% の高速化（約 1.5〜2.1 倍の処理速度向上）が報告されています。
| ベンチマークシーン | ポイント数 | v2/v3 サイズ | v4 サイズ | TTR (レンダリングまでの時間) v2/v3 | TTR v4 |
|---|---|---|---|---|---|
| Scene A | 360万 | 66.2MB | 65.7MB | 1,264ms | 844ms |
| Scene B | 710万 | 254MB | 128MB | 3,450ms | 1,660ms |
| Scene C | 260万 | 39.3MB | 40.5MB | 958ms | 619ms |
| Scene D | 100万 | 20.7MB | 18.9MB | 364ms | 238ms |
| Scene E | 260万 | 118.5MB | 65.1MB | 1,375ms | 657ms |
プレーンテキストのヘッダー
SPZ 4 では、32 バイトのファイルヘッダーが圧縮領域の外側に固定オフセットでプレーンテキストとして配置されています。これにより、ペイロードを 1 バイトも解凍することなく、ポイント数、SH の次数、バージョン、各種フラグといった基本情報を直接確認できるようになっています。
また、ファイルの先頭には従来の GZip のマジックバイトではなく、新たに 「NGSP」 というマジックバイトが使われています。ローダーは最初の 4 バイトを参照して適切な処理経路を判断するため、古い SPZ v2/v3 ファイルはフォールバックパスを通じて問題なく読み込まれます。
一方で、v4 ファイルに遭遇した古いローダーは、クラッシュしたり破損した Splat を生成したりするのではなく、未対応フォーマットとしてエラーを返して安全に停止するよう設計されています（フェイルファスト）。これにより、互換性と安全性の両立が図られています。
拡張システムの導入
SPZ 4 のもう一つの大きな変更点として、拡張機能（Extensions）の導入が挙げられます。
従来のフォーマットは「普遍的な基準（最小公分母）」を目指して設計されていたため、圧縮率やパラメータレイアウトが固定されるなど、あえて厳格な仕様になっていました。しかし、SPZ の利用範囲が当初の想定を超えて広がるにつれ、この厳格さが柔軟性の面で制約となりつつありました。
そこで SPZ 4 では、互換性を保ちながらフォーマットを拡張できる仕組みが導入され、新しい属性やメタデータを追加しやすい構造へと進化しています。
この仕組みは、オプトイン方式のベンダー拡張チェーンによって実現されており、各レコードにはベンダー固有のタグ付き ID、長さを示すフィールド、そしてペイロードが含まれています。これにより、ローダーが認識できない拡張は安全にスキップされ、複数のベンダーによるデータが互いに干渉することなく同じファイル内に共存できるようになっています。
拡張機能はデフォルトでは無効で、PackOptions を通じて明示的に有効化（オプトイン）します。拡張を含まないファイルは従来の SPZ と同じ構造に見えるため、古いリーダーでも問題なく読み込むことができます。
最初の拡張機能は、今回のアーキテクチャの大部分を牽引したとされるAdobe社から提供されています。
- 0xADBE0002 Safe Orbit Camera: オービット（周回）スタイルのカメラ操作において、推奨される仰角と半径の制限値を保存します。これにより、Splatビューア側でシーンのフレーミングやナビゲーション方法を推測する必要がなくなります。
ベンダーIDの割り当てについては、公式リポジトリの extensions/README.md に文書化されています。今後さらに多くの拡張機能が登場することが予想されており、もし独自の拡張機能の追加を検討される場合は、まずこのREADMEを参照することが推奨されています。
Splat の品質調整
SPZ 4 は、Splat の表現力をさらに引き上げると同時に、開発者が求める品質とパフォーマンスのバランスを柔軟に選べるよう設計されています。
設定可能な球面調和関数（SH）の量子化
設定可能な球面調和関数（SH）の量子化は、SPZ 4 における大きな改善点のひとつです。SH係数は、Splatの視点依存の外観（表面での光の反射、カメラの移動に伴うハイライトの変化、素材の光沢やマット感など）を決定づける重要なパラメータです。同時に、ファイルサイズの多くを占める要因でもあります。
今回、Splatデータを再作成することなく、同じシーンを最高品質のアーカイブ用レンダリング向け、あるいは最大効率のモバイルビューア向けに調整できるようになりました。内部テストの結果では、3ビットで18倍の圧縮率を達成し、8ビットでは平均二乗誤差（MSE）がほぼゼロになることが確認されており、多くのシーンにおいては5ビットが最適なバランス（スイートスポット）になるとされています。
SH次数4による高精細なSplat
従来の SPZ では SH 次数 3 が上限で、多くのスマートフォン由来の Splat には十分でしたが、視点によって鋭く変化する表面表現を扱うパイプラインでは限界がありました。
SPZ 4 では SH 次数 4 がサポートされ、より高次の Splat が生成時のライティング情報を損なうことなくフォーマットを通過できるようになっています。これにより、光の当たり方や反射の変化といった細かな表情がより正確に再現され、より高精細で自然な外観を保ったまま扱えるようになりました。
これらの機能により、SPZ 4は品質調整の機能（ダイアル）を備えた初めてのSPZフォーマットになったと言えます。
Adobeとの連携によるSPZの大規模展開
SPZは、主要なクリエイティブツールや開発者ツールにおいて、Gaussian Splatを繋ぐ重要な役割を担いつつあります。
Adobeは、自社の3Dツールチェーンの中心にSPZを据えているようです。
最近リリースされたPhotoshopの新機能「オブジェクトを回転（Rotate Object）」は、2D画像を3D空間で回転させることを可能にし、リリース直後から大きな注目を集めました。
SPZは、この機能の裏でデータのやり取りを担うフォーマットとして採用されており、すでに数百万人のユーザーに利用される環境へと導入されています。
冒頭でも触れていますが、Adobe Photoshopのユーザーだけでも過去2ヶ月間で約80万個のSPZファイルが作成されたとのことです。
Webでの高速化と拡大するエコシステム
現在、SPZ の多くは公式が提供する Emscripten/WASMビルドを通じてブラウザ上で利用されています。SPZ 4 のリリースにあわせて、リファレンスライブラリには再構築された WASM／TypeScript バインディングレイヤーが同梱され、Gaussian データに対して適切な TypedArray ビューが提供されるようになりました。また、エディタでの自動補完に役立つ spz.d.ts も追加されています。
ブラウザでの SPZ 読み込み速度は最大 20 倍に向上したとされ、C++ から JavaScript へのレイヤーに Emscripten バインディングを追加したことで、Web ベースのワークフローにおいても実感できるパフォーマンス改善が得られています。
SPZ を取り巻く Web エコシステムも着実に広がっています。最近では Adobe が Babylon.js における SPZ サポートを拡張し、Web ベースの 3D パイプラインで SPZ アセットをより簡単に読み込み、レンダリングできる環境が整いつつあります。
こうした取り組みにより、SPZ は Web 上で扱いやすいフォーマットとしてさらに存在感を高めているようです。
Splatデータの検査と変換のためのWebツール
ライブラリのリリースと併せて、Splatファイルを扱うためのWASMベースの小規模なWebツールが nianticspatial.com/spz-converter にて公開されました。
ページ上に .spz または .ply ファイルをドロップするだけで、ヘッダー情報、ポイント数、SH次数、ストリームレイアウト、バウンディングボックスを確認でき、フォーマット間の変換やメタデータのJSON形式でのエクスポートが可能です。これらの処理はすべて、ユーザーのブラウザ内のローカル環境で実行される仕組みになっています。
注意: このツールは、新しいSPZ v4フォーマットでファイルをエクスポートします。v4はエンコード速度が3〜5倍速く、ファイルサイズも小さく、拡張機能をサポートしていますが、これらのファイルを読み込めるのは最新のSPZライブラリを実行しているリーダーのみとなります。古いv2/v3リーダーでは、未認識フォーマットとしてエラーになります。関連する開発者の方は github.com/nianticlabs/spz にてライブラリのアップデートが推奨されています。
後方互換性について
読み込みに関する互換性については、以下のようにアナウンスされています。
- SPZ 4はすべてのバージョンを読み込めます。 古いSPZ v2/v3ファイルも、レガシーパスを通じて正常にロードされます。
- 古いローダーはSPZ 4ファイルを読み込めません。 新しい「NGSP」マジックバイトを検知し、未認識フォーマットとして適切にエラーを報告して停止します。
- 拡張機能を含まないファイルは、標準的なSPZとして扱われます。 拡張機能を実装していない、または認識できないローダーでも問題なく処理されます。
古いリーダーとの前方互換性を断つという決定は慎重に行われたとのことですが、エンコードの高速化、並列デコード、プレーンテキストヘッダー、そして今後の拡張性を考慮した結果、アップデートのメリットが明確に上回ると判断されたようです。
今後の展望
v4におけるアーキテクチャの変更は、今後のさらなる改善の基盤となるものです。次期バージョンとなるv5に向けて、開発チームは以下のような方向性を検討しているとのことです。
- ストリーミングとプログレッシブローディング（段階的読み込み）
- SH量子化のさらなる改善
- 空間チャンク化（分割）とLOD（詳細度制御）
- ベンダー拡張機能の拡充
SPZフォーマットは、これまでもコミュニティからの提案や働きかけによって進化してきた背景があります。開発チームは、新しいアイデアの探求や議論について、GitHubリポジトリでのIssue作成を歓迎しています。すでにプロトタイプが作成されている場合は、Pull Requestの送信も推奨されています。
SPZ 4 を使い始めるには
SPZ 4を利用し始めるにあたって、目的に応じていくつかの方法が案内されています。
PLYファイルを圧縮したい、あるいはSPZファイルの中身を確認したい場合
nianticspatial.com/spz-converter にアクセスし、ページにファイルをドロップするだけで利用できます。インストール、ユーザー登録、ファイルのアップロードは一切不要で、数秒でヘッダー情報が表示され、ワンクリックで .ply と .spz v4 の相互変換が可能です。
自身のアプリケーションにSPZを統合したい場合
ライブラリはGitHub (github.com/nianticlabs/spz) にて公開されています。C++プロジェクトの場合は、リポジトリをクローンしてコアライブラリにリンクします。Pythonの場合は、リポジトリから pip install することでバインディングが利用可能です。Web向けには、TypeScript定義付きのWASMビルドも用意されています。
既存の統合の多くにおいて、SPZ 4はそのまま置き換え可能な（ドロップイン）アップグレードとなります。mainブランチをプルすれば既存の読み込み/保存の呼び出しは引き続き機能し、保存時にはデフォルトでv4が生成されるようになります。
Nianticの3Dスキャンアプリである「Scaniverse」にも、数ヶ月以内にSPZ 4のエクスポート機能が追加される予定です。開発チームは、SPZをインポートするアプリを開発している方々に対し、一緒に前進できるよう、このタイムラインに合わせたアップデートを呼びかけています。
コードでの貢献を希望する場合
Pull Requestが歓迎されています。バグ修正やプラットフォーム固有のビルド改善は迅速に取り入れられる傾向にあります。より大きな変更（新しい拡張機能、フォーマットレベルの調整、パフォーマンス向上など）については、設計について議論するため、事前にIssueを作成することが推奨されています。
独自の拡張機能の追加を検討されている場合は、extensions/README.md にベンダーIDの割り当てスキームが文書化されています。初めてのPRとして、ビルドの改善、主要なレンダラー向けの統合ガイド、Webユーティリティ周辺のツール開発などが適しているとのことです。
コメント