写真を何十枚か撮ってしばらく待つだけで、その場に立っているかのような3D空間がぬるぬる動く——3D Gaussian Splatting（3DGS） が2023年に登場したとき、多くの人が受けた衝撃はそれだった。日本語でも「3DGSとは」「フォトグラメトリとの違い」といった解説はこの2年でかなり増えた。
ところが、その入口として必ず紹介される本家リポジトリ graphdeco-inria/gaussian-splatting が今どうなっているかを書いた日本語記事は、ほとんど無い。★は23,495に達しているのに main ブランチは2024年10月から動いておらず、ライセンスは非商用限定で、公式の environment.yml には README の記述と噛み合わない箇所がある。本記事は、その3点をすべて手元で実測して整理する。
30秒でわかる — この記事で実測したこと
- 本家の main は2024年10月30日で止まっている — タグもリリースも0件。GitHub API の
pushed_atは2025年10月17日を返すが、その実体はishaan/wip_new_viewerという作業中ブランチへの push であって、本体の更新ではない - ライセンスは非商用限定で、しかも中核サブモジュールにも同じ条件が付く — 本体・
diff-gaussian-rasterization・simple-knnの3つが Inria/MPII の独自ライセンス。学習を回す最小構成がまるごと非商用側に入る - 公式
environment.ymlの CUDA 指定を README の推奨に合わせると、PyTorch が黙って CPU 版になる —cudatoolkit=11.8へ変えて solve すると、エラーを出さないままpytorch 1.12.1 py3.7_cpu_0が選ばれる
3DGS は生成AIそのものではなく、写真から空間を再構成するレンダリング技術だ。ただし出力形式としての「3D Gaussian」は画像→3D生成AIの世界とも地続きで、生成AI全体のどこに位置する話なのかを掴んでおくと理解が速い。全体像はLLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版を参照してほしい。
3D Gaussian Splatting（3DGS）とは——SIGGRAPH 2023論文と本家リポジトリ
3D Gaussian Splatting は、複数視点から撮影した写真群をもとにシーンを再構成し、任意の新しい視点からの見た目をリアルタイムに描画する手法だ。原典は SIGGRAPH 2023（ACM Transactions on Graphics 42巻4号、2023年7月） に採録された論文で、著者は Bernhard Kerbl、Georgios Kopanas（両名が等貢献）、Thomas Leimkühler、George Drettakis の4名。所属は Inria、Université Côte d’Azur、Max Planck Institut für Informatik である。
論文が主張する貢献は3点に整理されている。①カメラキャリブレーション時に得られる疎な点群を出発点に、シーンを3次元ガウシアンの集合として表現すること。②最適化とガウシアンの密度制御を交互に行い、異方性の共分散を最適化すること。③可視性を考慮した高速な描画アルゴリズムにより、異方性スプラッティングを支えつつ学習も描画も加速すること。この3つで、1080p 解像度で 30fps 以上のリアルタイム新視点合成を達成した。
ここで押さえておきたいのは、3DGS の入口が COLMAP であるという点だ。本家のパイプラインは写真から直接始まるのではなく、まず COLMAP（Structure-from-Motion）でカメラの位置姿勢と疎な点群を求め、その点群をガウシアンの初期値にする。つまり3DGSを動かすには 3DGS 本体だけでなく COLMAP も必要で、撮影の失敗（テクスチャの乏しい壁、動く被写体、露出のばらつき）はまず COLMAP の段階で効いてくる。
NeRF との違いもここに関係する。NeRF はニューラルネットが空間の色と密度を暗黙的に持つため、1点の色を得るのにネットワークの前向き計算が要る。3DGS は空間を明示的なガウシアンの集合として持ち、描画はそれをスクリーンへ投影して合成するだけなので、学習済みシーンの描画がはるかに軽い。代わりにデータサイズは大きくなりやすく、出力の .ply は数百MBに達することもある。
・入力：同一シーンを複数視点から撮った写真群（動画からのフレーム抽出でも可）
・前処理：COLMAP によるカメラ位置推定と疎な点群生成
・学習：GPU上でガウシアンのパラメータを最適化。本家READMEは論文品質で24GB VRAMを要件に挙げる
・出力：.ply 形式のガウシアン群。メッシュではないため、そのままではゲームエンジンの通常パイプラインに乗らない
・描画：専用ビューア（本家のSIBR、またはWebGL系ビューア）でリアルタイム表示
では、その「3次元ガウシアン」1個は何を持っているのか。ここを押さえると .ply のファイルサイズが大きくなる理由も、学習で何が動いているのかも見通しがよくなる。1個のガウシアンが保持するのは次の4種類のパラメータだ。
・位置（3次元の平均） — 空間のどこにあるか
・共分散行列（異方性） — どの方向にどれだけ伸びた楕円体か。実装上はスケール3成分と回転クォータニオン4成分に分解して保持し、最適化中も正定値性が崩れないようにしている
・不透明度 — 手前のガウシアンが背後をどれだけ隠すか。アルファ合成の重みになる
・色（球面調和係数） — 単なるRGB1色ではなく、見る方向によって色が変わる関数として持つ。金属やガラスのてかりが視点で動くのはこの成分の働きによる
論文の貢献②にある「異方性の共分散を最適化する」とは、この楕円体の向きと伸びを写真に合うよう調整することを指す。壁のような平たい面は薄く潰れた楕円体で、細い枝は細長い楕円体で表現できるので、同じ枚数でも表現力が上がる。加えて密度制御が並行して走り、誤差の大きい領域ではガウシアンを分割・複製し、不透明度がほぼゼロになったものは削除する。最終的なガウシアン数はシーン次第で数十万から数百万に及ぶ。
1個あたりのパラメータが数十個あり、それが数百万個あるのだから、.ply が数百MBになるのは必然だ。配布や Web 表示を考えるなら、この時点で圧縮・間引きを行うツール（後述の supersplat など）が必要になる、と見込んでおくとよい。
画像1枚から3Dアセットを「生成」する系統の技術とは目的が違う点にも注意したい。3DGS は実在するシーンの再構成であって、無い部分を作り出すものではない。生成側の代表例はTRELLIS完全ガイド｜Microsoftの画像→3D生成AI・SLATの仕組みと導入・比較まで解説で扱っており、TRELLIS が出力形式のひとつとして「3D Gaussian」を持つのは、まさに本記事の表現形式が共通言語になっているからだ。
【実測】本家リポジトリは今どうなっているか——mainは2024年10月で停止
「3D Gaussian Splatting を試したい」と検索して最初にたどり着くのが本家リポジトリだが、そこが現在どう保守されているかを確認せずに着手すると、後から時間を失う。2026年8月28日時点で GitHub API から実測した値を並べる。
| 項目 | 実測値（2026-08-28） |
|---|---|
| star | 23,495 |
| fork | 3,382 |
| オープンissue+PR | 713（GitHub の open_issues_count はPRを含む） |
| リポジトリ作成 | 2023-07-04 |
| main の最終コミット | 2024-10-30（fix submodule name in environment.yml） |
dev ブランチ |
2024-09-17 |
licensed ブランチ |
2024-10-30 |
ishaan/wip_new_viewer |
2025-10-17 |
API の pushed_at |
2025-10-17 |
| タグ | 0件 |
| リリース | 0件 |
| archived フラグ | false |
ここで誤読しやすいのが pushed_at の 2025-10-17 という値だ。GitHub のリポジトリ一覧やAPIが返す「最終更新」はこの値だが、実際には ishaan/wip_new_viewer（コミットメッセージは “Add new viewer in train script while keeping option for SIBR”）という作業中ブランチへの push を拾っているにすぎない。本体である main は2024年10月30日から動いておらず、約22か月更新されていない。
タグとリリースが0件である点も実務上は重要だ。「現行バージョン」という概念が存在せず、README の手順で git clone すればその時点の main を取ることになる。バージョンを固定したいならコミットSHAで留める以外に方法がない。
licensed というブランチ名を「商用版」と誤読しない
ブランチ一覧に licensed という名前があるため、商用ライセンス版の抜け道があるように見える。実際に LICENSE.md を取得して比較したところ、このブランチのライセンスは main とまったく同一の非商用ライセンスだった。main との差分は1コミット・4ファイル（SIBR_viewers のサブモジュール参照先、environment.yml、scene/dataset_readers.py、scene/gaussian_model.py）で、ライセンス条件の変更は含まれていない。environment.yml の中身も実際に取得して比較したが、差は conda 依存から plyfile が外れ pip 依存に meshio が加わるだけで、後述する cudatoolkit=11.6 の pin は main と同じだった。名前から用途を推測せず、条文を読むこと。
なお、README 自身がこの状況を認めている。「NEW FEATURES !」の節に、コードの保守と更新に割けるリソースが限られていること、それでも一部の機能は追加してきたことが明記されている。放置されているのではなく、研究成果の公開物として役目を終えつつある、と読むのが正確だ。実装を継続的に追いたいなら別のリポジトリを見る必要がある——それが後述の実装選定の話につながる。
3D Gaussian Splatting のライセンスを全系統で読む——本家は非商用限定
ここが本記事でもっとも実害に直結する部分なので、条文に沿って整理する。GitHub のリポジトリページは本家のライセンスを “Other”（SPDX では NOASSERTION）としか表示しない。つまりGitHub の表示を見ただけでは何も分からないので、LICENSE.md を開く必要がある。
本体の LICENSE.md は「Gaussian-Splatting License」という Inria と Max Planck Institut für Informatik（MPII）の独自ライセンスで、要点は次のとおり。
・第3条（付与される権利）：研究目的での使用権を、学術・産業を問わず研究利用者に無償で付与する。サブライセンス権は無い。ソフトウェアは「非商用に、すなわち研究および／または評価の目的でのみ」使用してよい
・第4.1条（再配布）：本ライセンスの下で配布すること、ライセンス全文を同梱すること、著作権・特許・商標・帰属の表示を改変せず保持することが条件
・第4.2条（派生物）：派生物に別条件を付す場合でも、使用制限が派生物にも適用されると定めた場合に限る
・第5条（免責）：冒頭で「利用者は、ライセンサーの事前かつ明示的な同意なしに、本ソフトウェアを商用目的で使用・利用・配布することはできない」と大文字で明記し、問い合わせ先として [email protected] を指定している
・第6条：utils/loss_utils.py の内容のみ、MIT ライセンスの pytorch-ssim（Evan Su 氏）に基づく
条文に相互参照の誤りがある（実際に読んだ人だけが気づく点）
第4.2条は「第2条の使用制限（the use limitation in Section 2）」を参照しているが、第2条は「Purpose（本ライセンスの目的）」であって使用制限そのものは含まない。非商用の制限が書かれているのは第3条である。同様に第4.1条は「Section 3.1 の再配布要件」に言及するが、3.1 という条項番号は存在しない。
本記事はこの点を「条文にそう書いてある」という事実として報告するにとどめ、派生物への制限の効き方について法的な結論は述べない。判断が必要な場面では、条文の原文と第5条の問い合わせ窓口にあたってほしい。
そのうえで見落とされがちなのが、サブモジュール側のライセンスだ。.gitmodules を読むと、本家は4つのサブモジュールを参照している。それぞれの LICENSE を個別に取得した結果が次の表になる。
| サブモジュール | ホスト | ライセンス（実測） | 役割 |
|---|---|---|---|
submodules/diff-gaussian-rasterization |
github.com | Gaussian-Splatting License（非商用） | 微分可能CUDAラスタライザ。3DGSの中核 |
submodules/simple-knn |
gitlab.inria.fr | Gaussian-Splatting License（非商用） | 近傍探索。初期化と密度制御に使用 |
submodules/fused-ssim |
github.com | MIT | SSIM損失の高速実装 |
SIBR_viewers |
gitlab.inria.fr | Apache-2.0（ただし後述） | リアルタイムビューア |
つまり、学習を回すのに必須の3点（本体・CUDAラスタライザ・simple-knn）がすべて非商用ライセンスである。MIT なのは fused-ssim と utils/loss_utils.py だけで、これらを取り替えても中核は非商用のまま残る。「本体だけ気をつければよい」という理解は成立しない。
ビューア側にも注意点がある。SIBR_viewers が参照する sibr_core の LICENSE.md は「sibr システムは Apache 2.0 ライセンスである。ただし src/projects 配下の特定ブランチにある一部プロジェクトは、それぞれのディレクトリに別のライセンスを持つ」と述べている。Apache-2.0 なのは SIBR のコア部分であって、3DGS 用のビューアプロジェクトが同じ条件とは限らない。README が Windows 向けにプリビルドバイナリを配布しているのはこのビューアなので、配布物に組み込む前に該当ディレクトリの LICENSE.md を個別に確認する必要がある。なお本記事の執筆時点では、gaussian_code_release に相当するプロジェクトの LICENSE は gitlab.inria.fr 上で認証を要求され匿名では取得できなかったため、当該ファイルの内容は未検証である。
自分のプロジェクトに3DGS由来のコードが混入していないかは、次のコマンドで確認できる。
# 依存ツリーとソースに Inria 非商用ライセンスのコンポーネントが無いか探す
grep -ril "Gaussian-Splatting License" . 2>/dev/null
grep -rl "[email protected]" . 2>/dev/null
# Python環境に本家由来のCUDA拡張が入っていないか
pip list 2>/dev/null | grep -Ei "diff-gaussian-rasterization|simple-knn"
【実測】公式 environment.yml は今日も解けるのか——CUDA 11.6 と 11.8 のA/B
本家のセットアップ手順は conda 前提で、リポジトリ同梱の environment.yml を使う。ここにREADME の記述と噛み合わない箇所がある。
README の Software Requirements はこう書いている。「PyTorch拡張のために CUDA SDK 11 が必要。Visual Studio の後にインストールすること（私たちは 11.8 を使った。11.6 には既知の問題がある）」。ここで言う CUDA SDK は、サブモジュールのCUDA拡張を nvcc でコンパイルするためのシステム側のツールキットを指す。一方、同梱の environment.yml が pin しているのはconda パッケージとしての cudatoolkit で、こちらは README が「既知の問題がある」と名指しした 11.6 になっている。
dependencies:
- cudatoolkit=11.6 # README は 11.8 推奨・11.6 に known issues と書いている
- python=3.7.13 # Python 3.7 は 2023-06 に EOL
- pytorch=1.12.1
- torchaudio=0.12.1
- torchvision=0.13.1
README は environment.yml を編集せよとは書いていない。だが「11.6 には既知の問題がある」と読んだ人が、この食い違いを素直に解こうとして conda 側の pin も 11.8 へ揃えるのは自然な発想だ。そこで実際にどうなるかを確かめた。micromamba 2.9.0 で --platform linux-64 を指定し、--dry-run で依存解決だけを実行して比較している（実行日：2026年8月28日）。
| 中核パッケージ | A：cudatoolkit=11.6（公式のまま） |
B：cudatoolkit=11.8（README推奨に合わせた） |
|---|---|---|
| pytorch | 1.12.1 py3.7_cuda11.6_cudnn8.3.2_0（1GB） |
1.12.1 py3.7_cpu_0（80MB） |
| torchvision | 0.13.1 py37_cu116 |
0.13.1 py37_cpu |
| torchaudio | 0.12.1 py37_cu116 |
0.12.1 py37_cpu |
| cudatoolkit | 11.6.2（628MB） |
11.8.0（716MB） |
| python | 3.7.13 |
3.7.13 |
| パッケージ総数 | 76 | 76 |
| ダウンロード総量 | 2GB | 1GB |
| solve の結果 | 成功 | 成功（エラーなし） |
結論はこうだ。conda 側の cudatoolkit を 11.8 へ揃えると、依存解決は成功したまま PyTorch が CPU 版になる。 理由は単純で、PyTorch 1.12.1 には cu118 ビルドが存在しない（cu118 の提供は PyTorch 1.13 以降）。solver は cudatoolkit=11.8 と pytorch=1.12.1 を同時に満たす組み合わせを探し、CUDA ビルドが使えないので CPU ビルドを選ぶ。しかも cudatoolkit 自体は716MB分きっちりインストールされるため、環境は一見 CUDA 対応に見える。
なぜ気づきにくいか
・conda / mamba はエラーも警告も出さない。解決可能な組み合わせを見つけただけだから
・nvidia-smi は通るし、cudatoolkit も入っているので環境は正常に見える
・気づくのは学習を回して torch.cuda.is_available() が False を返したとき、あるいは学習が極端に遅いとき
・確認方法：python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())" を環境構築の直後に実行する。torch.version.cuda が None なら CPU ビルドが入っている
この検証は手元でも再現できる。GPU は不要で、依存解決だけを見る。
# 公式 environment.yml を取得し、conda 依存部分だけを linux-64 向けに dry-run で解く
curl -sO https://raw.githubusercontent.com/graphdeco-inria/gaussian-splatting/main/environment.yml
micromamba create -n gs_check -f environment.yml \
--platform linux-64 --dry-run -y | grep -E "pytorch|torchvision|cudatoolkit"
上のコマンドは curl で取得したままの environment.yml（pip セクションを含む）に対して実行し、結果が表A（torchvision 0.13.1 py37_cu116 を含む76パッケージ・2GB）と一致することを確認している。ただし --dry-run が実際に解いているのは conda 依存の側だけで、environment.yml の pip セクションにある3本のローカルパス（submodules/diff-gaussian-rasterization / simple-knn / fused-ssim）は評価されない。この3本のCUDA拡張が実際にビルドできるかは、本記事では検証していない（nvcc と対応するコンパイラを持つ実機が要る）。
もうひとつ実測しておくと、公式の environment.yml は2026年8月28日時点でも conda 側の依存解決は成功する。Python 3.7.13 は 2023年6月に EOL を迎えているが、パッケージはまだ配布されており、76パッケージ・約2GBで解ける。したがって「古すぎてもう入らない」わけではない。問題は入るかどうかではなく、入った環境が今のGPU世代と噛み合うかにある。CUDA 11.6 世代のビルドは Ada Lovelace（RTX 40系）以降の新しい Compute Capability を想定していないため、新しめのGPUでは別途 PyTorch を入れ直す判断が要る。
具体的に言えば、cudatoolkit=11.6 系のビルドが想定する GPU アーキテクチャは Ampere（RTX 30系、Compute Capability 8.6）までが実用範囲で、Ada Lovelace（RTX 40系、8.9）や、それ以降の世代では対応するカーネルが同梱されていない可能性がある。README が要件として挙げているのは「Compute Capability 7.0 以上」という下限だけで、上限側については何も書かれていない点に注意したい。手元のGPUが新しい場合、公式 environment.yml をそのまま使うのではなく、PyTorch と CUDA を自分の世代に合わせて入れ直したうえで、サブモジュールの CUDA 拡張をビルドし直す手順になる。この作業が発生する時点で「公式手順どおりに一発で入る」という前提は崩れるので、最初から新しめの実装を選ぶ判断も現実的になる。
サブモジュールの取得可能性も確認した。.gitmodules の4つのうち2つは github.com ではなく gitlab.inria.fr にホストされているが、git ls-remote で4つとも到達できた（2026-08-28時点）。git clone --recursive が研究機関のホスト側の事情で失敗する懸念はあるが、現時点では問題ない。
3D Gaussian Splatting の実装をどう選ぶか——本家・gsplat・ビューア
ここまでの実測を踏まえると、「本家をそのまま使う」が最適解になる場面はかなり限られる。目的別に整理する。
| リポジトリ | ★（実測） | 配布ライセンス | 直近push | 位置づけ |
|---|---|---|---|---|
graphdeco-inria/gaussian-splatting |
23,495 | Gaussian-Splatting License（非商用） | main は2024-10-30 | 論文の参照実装 |
nerfstudio-project/nerfstudio |
11,939 | Apache-2.0 | 2025-07-29 | 学習フレームワーク（Splatfacto を内包） |
playcanvas/supersplat |
9,909 | MIT | 2026-08-27 | ブラウザで動く .ply エディタ／ビューア |
nerfstudio-project/gsplat |
5,597 | Apache-2.0 | 2026-08-20 | CUDAラスタライザのライブラリ |
antimatter15/splat |
3,066 | MIT | 2025-11-16 | WebGL ビューア（軽量） |
mkkellogg/GaussianSplats3D |
2,872 | MIT | 2025-10-19 | three.js ベースのビューア |
graphdeco-inria/hierarchical-3d-gaussians |
1,461 | Other（NOASSERTION） | 2025-06-10 | 大規模シーン向け階層版（SIGGRAPH 2024） |
gsplat の来歴について、事実だけを書いておく。 nerfstudio-project/gsplat は Apache-2.0 のライセンスファイルを同梱して配布されており、LICENSE に Inria への帰属表示は含まれていない。README は自身を「SIGGRAPH論文に着想を得た（inspired by）CUDAアクセラレーテッドなガウシアンのラスタライズ用ライブラリ」と説明し、より高速・省メモリにしたと述べている。独自の技術文書として arXiv:2409.06765 のホワイトペーパーを持ち、引用もそちらを案内している。
本記事はここから先、「したがって商用利用できる」という法的な結論は述べない。配布ライセンスが Apache-2.0 であることと、ある実装が上流の制限から自由であることは別の主張であり、後者を判断するにはコードの由来まで踏み込む必要がある。商用プロダクトに組み込むなら、選定候補それぞれについて自組織の判断でライセンス確認を行ってほしい。ここで言えるのは「本家は明示的に非商用と書いてあるので、少なくともそれをそのまま製品に入れる選択肢は無い」という一点である。
ビューアまわりで実務的に効くのは、本家がWindows向けのプリビルドバイナリを配布している点だ。README はビューア一式（約60MB）のダウンロードリンクを掲げ、SIBR のビルドには外部依存を都度取得・コンパイルする必要があるため、Windowsではプリビルドの利用を推奨している。逆に言えば Linux や macOS では自分でビルドする前提になり、README もビューアのビルド要件として Visual Studio か g++（Clang は不可と明記）、CUDA SDK 11、CMake を挙げている。macOS で本家のビューアを動かす経路は用意されていないと考えたほうがよい。結果を見るだけならブラウザで動く MIT ライセンスのビューアのほうが、環境を選ばず配布もしやすい。
目的別の整理はこうなる。
・論文を追試したい／研究で使う → 本家が正解。参照実装であり、論文の数値と対応する。非商用ライセンスの範囲にも収まる
・学習を回して自分のシーンを作りたい（研究外） → Nerfstudio + Splatfacto、または gsplat を直接使う経路を検討する。更新が続いており、CUDA・PyTorch の新しい世代への追随がある
・できた .ply を見せたい・配りたい → supersplat（編集とビューア）や antimatter15/splat、GaussianSplats3D。いずれも MIT で、ブラウザで動くためGPUサーバーが要らない
・街区スケールなど大規模シーン → hierarchical-3d-gaussians。ただしこちらも Inria 系で NOASSERTION なので、ライセンスは同様に個別確認が要る
・シミュレータやワールドモデルの文脈で3DGSを使いたい → 自動運転やロボティクスでの利用が広がっている領域で、フィジカルAIとは？英語表記Physical AIの意味・ワールドモデル・NVIDIA Cosmosを解説が周辺の全体像を扱っている
3D Gaussian Splatting を始める前のチェックリスト
最後に、着手前に潰しておくと時間を失わない項目をまとめる。本記事で実測した内容がそのまま確認項目になる。
着手前チェックリスト
- 用途は研究・評価か、それとも製品か — 製品なら本家（および
diff-gaussian-rasterization/simple-knn）はそのまま使えない。第5条の窓口[email protected]に確認するか、別実装を選ぶ - GPU要件を満たすか — Compute Capability 7.0以上のCUDA対応GPU。論文品質まで学習するなら24GB VRAM。閲覧だけならWebGLビューアでGPUサーバーは不要
- COLMAP を含めた前処理まで見積もったか — 3DGS単体では写真から始められない。撮影の質がCOLMAPの段階で効く
environment.ymlの CUDA 指定を触るなら PyTorch のビルドを確認したか — 11.8 へ変えると PyTorch が CPU 版に落ちる。構築直後にtorch.cuda.is_available()を確認する- バージョンを固定する手段を決めたか — タグもリリースも0件なので、再現性が要るならコミットSHAで固定する
- 本家の更新を前提にしていないか — main は2024年10月30日から動いていない。継続的なメンテナンスが要るなら gsplat / Nerfstudio 側を見る
3DGS そのものは今も伸びている領域で、SIGGRAPH Asia 2024 の Taming 3DGS のように学習の効率化を扱う後続研究も続いている（本家 README も参照している）。だが、その入口として最も有名な本家リポジトリは、論文の参照実装としての役割に落ち着きつつある。研究の再現には今も最良の選択肢である一方、動くものを作って配るという目的には、更新が続き配布ライセンスの明確な実装のほうが素直だ。この使い分けを最初に決めておけば、CUDAのバージョン合わせで数日を溶かすことは避けられる。
参照ソース
・graphdeco-inria/gaussian-splatting — 本家リポジトリ。README・LICENSE.md・.gitmodules・environment.yml、およびGitHub APIによるブランチ／タグ／リリースの実測（2026-08-28）
・3D Gaussian Splatting for Real-Time Radiance Field Rendering（公式プロジェクトページ） — SIGGRAPH 2023（ACM Transactions on Graphics）掲載。著者・所属・論文PDF・データセットの一次情報
・論文本体（DOI: 10.1145/3592433） — Kerbl, Kopanas, Leimkühler, Drettakis「3D Gaussian Splatting for Real-Time Radiance Field Rendering」ACM Transactions on Graphics 42(4)、2023年7月26日。掲載誌・巻号は Crossref で確認。公式PDF（高解像度版）
・graphdeco-inria/diff-gaussian-rasterization — 中核サブモジュール。LICENSE.md を個別に取得して確認
・sibr_core（gitlab.inria.fr） — SIBR ビューアの LICENSE.md。Apache-2.0 と src/projects 配下の例外規定
・nerfstudio-project/gsplat — README とライセンスファイルの記述、および arXiv:2409.06765 の案内
