§5.4 Negative findings — 失敗から得た 3 つの発見 (卒論章ドラフト)

作成日

2026-05-22

位置付け

卒業論文 §5.4 として直接転記する初稿。一次資料は <code>docs/findings/</code> 配下のノートと <code>3dgs-rs/README.md</code> ablation 表に明示する。文体は卒論本文用 (だ・である体)。

§5.4 リード — Engineering における negative findings の位置付け

本研究は 3D Gaussian Splatting (3DGS) を Apple Silicon 上で native 実装する試みであり、forward / backward kernel 群、refine スケジュール、損失関数、Apple 固有の最適化と、多層にわたる構成要素を段階的に積み上げてきた。これらの過程では、事前 commit した gate (PSNR / wallclock の最低基準) を満たさず採用に至らなかった試みが多数発生した。本章は、そうした「失敗の記録」を engineering 上の発見として位置付け直し、卒論の貢献の一部に組み込むことを目的とする。

特に以下の 3 ストーリーは、いずれも単発の reject ではなく 複数試行を経て初めて原因の構造が見えた 事例であり、benchmark を前提とした自己検証手順がどのように研究を駆動したかを示す典型例である。本章では各事例について、(i) 動機、(ii) 試行と症状、(iii) 後付けでの原因理解、(iv) その失敗から得た知見と次の発見への接続、の 4 軸で整理する。

§5.4.1 scale 正則化の 3 連敗 — variance formulation の設計的限界

発端

Phase 4 後続段階で classic refine ベースの自作実装は val PSNR 25.59 dB (M-1) に頭打ちとなり、brush との -11.78 dB gap の一因として「splat の scale 暴走」が候補に上がった。brush は MCMC の birth-death 平衡で間接的に scale を抑制していると推測されたため、本実装でも loss 側に scale 正則化項を加えることで gap を縮めることを期待した (3dgs-rs/README.md §「後続 F: scale_reg v2」)。

試行

3 つの formulation を順次試した:

1. v0: loss = w · log_scale² — log 空間で 0 (= scale = 1) へ引き付ける素朴な定式化。実シーンの scene scale が ~0.03 程度のため完全に逆方向の力が働き、学習初期に NaN 発散 した。
2. v1: loss = w · scale² = w · exp(2·log_scale) — scale 空間で抑制する形に修正。今度は classic refine の aggressive growth と相互作用し、splats が 約 1M 個まで飽和、val PSNR は 13.46 dB へ劣化した。
3. v2: variance formulation loss = w · Σ (log_scaleᵢ − μ_axis)² — 軸方向平均を free にして分散のみを抑える定式化に再修正。これに weight sweep と warmup schedule、split cap を加えた 4 config (L-1〜L-4) を 10k iter で実行した結果は 16.06〜16.31 dB、いずれも K-5 baseline (23.29 dB) / M-1 (25.59 dB) から約 -7 dB の致命的劣化に終わった (3dgs-rs/README.md 表行 L-1〜L-4)。

原因の理解

3 回の失敗を通じて、scale_reg 単体の問題ではなく 「splat の生死と scale の連動」が classic refine では実現できていない という構造的欠陥が浮上した。すなわち:

• log 空間で正則化すれば scale = 1 という非物理的な値へ引かれる (v0)
• scale 空間で正則化すれば、refine の clone/split が cap を作らず延々と splat を増やす (v1)
• 平均 free の variance formulation でも、anisotropic な細部を均してしまい PSNR を回復できない (v2)

3 度目の失敗が確定した時点で、これは「formulation を変えれば解ける」種類の問題ではなく、「MCMC 的な birth-death 平衡が無い環境では scale_reg は本質的に機能しない」 と結論付けた (3dgs-rs/README.md §「30-F-4 negative」)。

得た発見

scale_reg そのものは本研究の baseline からは外し、default 0.0 で無効化した上で CLI flag のみ残置するという保守的な扱いに収めた。代わりに、scale 抑制を必要とする研究シナリオは MCMC 章 (§5.4.2) の λ_Σ covariance regularization へ移管した。3 連敗の意義は、後段の MCMC 完全実装仕様 (docs/findings/mcmc-3-defects.md 欠陥 2) において「λ_Σ は単独の loss 項ではなく birth-death と一体で機能する」と言い切る根拠を、自身の手で測定した値で支えられる点にある。

§5.4.2 MCMC 移植の 4 連敗 — 数式独立移植と周辺 infrastructure の非対称性

発端

Phase 4 後続 ablation で brush との -11.78 dB gap の主因は「MCMC vs classic refine」と推定されたため、brush の MCMC refine を自実装に取り込むことで gap を狙った (3dgs-rs/README.md §「後続 G」)。brush 実装の精読により、MCMC の本体は (1) noise injection と (2) multinomial respawn の 2 操作で表現できると判断し、当初は実装難易度を「想定より大幅に低い」と評価していた。

試行

4 run で順に gate を下げながら検証したが、いずれも採用基準 (val PSNR ≥ 30 dB、brush -7 dB 以内) を満たさなかった (3dgs-rs/README.md 表行 N-1〜N-4):

数式部分は brush 実装と数値的に一致する単体テスト (6/6 pass) を通過していたにもかかわらず、統合 run では一貫して破綻した。

原因の理解

論文 (Kheradmand et al. 2024) を全部入りで読み直した結果、本実装は paper §3 と比較して 3 箇所で設計的に乖離していたことが判明した (docs/findings/mcmc-3-defects.md):

1. 欠陥 1 — 5% incremental growth が無い: 論文§3.3 は N_alive を毎 100 iter に 1.05 倍ずつ拡大する schedule を持つが、本実装は capacity を hard cap で確保し、growth は classic refine の clone/split に委ねていた。
2. 欠陥 2 — λ_Σ (covariance L1) と λ_o (opacity L1) が欠落: 論文 loss は L_total = (1−λ)·L1 + λ·L_SSIM + λ_Σ·Σ‖Σᵢ‖_eig_L1 + λ_o·Σ‖oᵢ‖_L1 で、λ_Σ = λ_o = 0.01 が birth-death 平衡を成立させる主因子である。本実装は両項とも未実装で、scale_reg (§5.4.1) で代替を試みたが §5.4.1 のとおり失敗していた。
3. 欠陥 3 — relocation が prune に便乗: 論文§3.2 の relocation は 100-tick の独立スケジュールで opacity-weighted multinomial に従い実行されるべきだが、本実装は refine 関数内の Delete → Respawn 変換として slot 再利用しているに過ぎず、probability-preserving 公式 (論文 Eq. 9) も適用されていない。

加えて SGLD noise の係数も (1−σ(o))^150 という近似式で実装しており、論文の σ(−100·(o − 0.995)) 形と整合しない (mcmc-3-defects.md §6 行 2)。これらの 3 欠陥 + 係数差 が複合して、特に G-6 の「569k splat 爆発」や G-4 の view 1 崩壊として現れた。

得た発見

4 連敗の最大の収穫は、論文の数式部分は短期間で独立移植可能であっても、その周辺の 点数上限 / 正則化項 / 多項分布スケジュール という infrastructure が同等の重要性を持つという原則の実証である。この知見は docs/findings/mcmc-3-defects.md として spec 化され、A.2 の修正項目 (growth schedule / λ_Σ / multinomial relocation / SGLD coef 補正) として後続の作業項目に直結した。本研究では MCMC 完全実装は卒論の future work とし、Phase 5 (Apple 最適化) へ pivot した。

§5.4.3 #5.31 ArgBuffer 却下 → M-3.x の偶発的発見

発端

Phase 5 step 30 の Instruments 計測で「1 iter あたり約 40 個の Metal encoder」が作成されていることが分かり、CPU encoding overhead の削減が次の最適化候補に浮上した (docs/findings/phase5-step30-profile.md)。当初の仮説は、26 個の buffer binding を 1 つの MTLArgumentBuffer に集約 (#5.31) すれば、encoder setup コストが大幅に削減できるというものだった。

試行と却下

step 31.0a で per-dispatch encoding を実際に分解計測した結果 (docs/findings/phase5-step31-encoding-profile.md):

• encoder setup の wallclock 寄与は 0.34 ms/iter に留まり、
• ArgBuffer が触れる範囲は理論上限でも 0.5% (= 0.21 ms / 42.5 ms) でしかなく、
• 事前 commit した「3% 改善」gate を満たし得ないことが確定的に示された。

「#5.31 ArgBuffer 単独最適化」は実装着手前に却下となり、4-6 時間の実装コストが回避された。これは F (scale_reg) / G (MCMC) と同型の「pre-committed gate による honest reject」の事例である。

偶発的発見 — queue reuse pattern と M-3.x

却下の根拠を取るために計測した CPU 側内訳から、想定外の hot path が露出した: 10 dispatch 箇所で毎回 device.new_command_queue() を呼んでいた箇所を struct field の self.queue 参照に置き換えるだけ (#5.31.0b、commit e2611df) で wallclock が 95.9 s → 82.8 s (-13.7%) へ短縮された。これは naive な per-iter 1.14 ms 削減 (= 2.3%) からの大幅な上振れであり、Objective-C autoreleasepool 経由の hidden cost が複合的に解消されたことが原因と推定される。

さらに同 profile 経由で「真の bottleneck は host loss + readback (合計 ~10 ms/iter)」と判明したため、#5.31.x として GPU loss kernel + no-readback pipeline を実装した (docs/findings/phase5-step31-x-gpu-loss.md)。結果は 2k iter で wallclock -26.9% (42.5 → 31.07 ms/iter)、30k では n=4 variance test で wallclock -14〜-19% が再現された。当初 n=1 で観測した「PSNR -0.65 dB regression」主張は 4 sample variance test で 撤回 され、systematic regression ではなく band (25.0 ± 0.6 dB) 内の sample variance と判明した。

queue reuse + GPU loss path は M-3.x として固定され、後続の splat workspace への migration gate でも variance band 内 (24.842 dB ∈ band) で再現されている (docs/findings/phase-c-migration-gate.md)。

得た発見

ArgBuffer 単独で攻めていたら 4-6 時間を投じて 0.5% の改善に留まり、本来の bottleneck (host pump pipeline = 第 3 軸 narrative の核) に到達できなかったはずである。本事例は、却下プロセスのために計測を続けたこと、すなわち 「grouped experimentation の副次効果として hot path の前提が更新される」 という方法論的な発見の典型例として位置付けられる。Apple unified memory の構造的優位は概念ではなく実装上のデータフロー設計に直結するという第 3 軸 narrative も、この偶発的経路を通じて初めて定量化できた。

§5.4 結語

3 ストーリーに共通する教訓は、事前 commit した gate に基づく honest reject が engineering 上の時間配分を保護し、同時に「失敗の数字」自体が次に必要な infrastructure の signal を encode する という点にある。scale_reg の 3 連敗は birth-death 平衡なき正則化が本質的に不可能と教え、MCMC の 4 連敗は数式独立移植では不足する周辺 infrastructure の構造を spec として可視化させ、#5.31 の reject は真の bottleneck が CPU encoding ではなく host pump pipeline にあることを明らかにした。本研究の主成果である M-3.x baseline と第 3 軸 (unified memory) narrative は、いずれもこれらの negative findings を経由した経路で初めて確定したものであり、本章はその過程を卒論の研究貢献として明示する位置付けにある。

出典 (一次資料)

• docs/findings/README.md — finding index
• docs/findings/phase5-step30-profile.md — Instruments / Metal System Trace
• docs/findings/phase5-step30b-timing.md — kernel-by-kernel timing
• docs/findings/phase5-step31-encoding-profile.md — #5.31 reject + queue reuse +13.7%
• docs/findings/phase5-step31-x-gpu-loss.md — #5.31.x GPU loss + 4 sample variance test
• docs/findings/phase-c-migration-gate.md — splat workspace migration gate (24.842 dB)
• docs/findings/mcmc-3-defects.md — A.2 MCMC 3 設計欠陥 spec
• 3dgs-rs/README.md — Phase 4 後続 F (scale_reg) / G (MCMC) ablation 表 (行 L-1〜L-4 / N-1〜N-4)
• splat/DESIGN.md — workspace 設計と milestone 表 (M-1〜M-3.x)

この finding が観測された / 言及している実験 run。

• lego-sh3-30kA.8 SH degree ablation — sh_degree=3 (DC only, no view-dependence)PSNR 24.88 dBWallclock 23m 13sverdict partial

• neutralA.2 MCMC 法の完全実装 — 3 設計欠陥の整理 (spec)2026-05-22
• mixedPhase C migration gate — splat workspace で M-3.x を再現する 30k 単発比較2026-04-30
• mixedPhase 5 step 30 — Instruments / Metal System Trace 分析結果2026-04-30
• positivePhase 5 step 30b — kernel-by-kernel timing 計測結果2026-04-30
• mixedPhase 5 #5.31 — CPU side profile + queue reuse 効果 + 真の bottleneck 同定2026-04-30
• positivePhase 5 #5.31.x — GPU loss kernel + no-readback pipeline (wallclock -26.9% + variance 解明)2026-04-30