# 開発進捗ログ

<!--
本ファイルは追記型のフル進捗ログ．

- 最新エントリは下に追記する（時系列順．古いものが上，新しいものが下）
- CLAUDE.md の「開発進捗」セクションは最新 1 行のみ（上書き運用）
- 詳細・失敗パターン・設計判断はすべて本ファイルに残す
- 書式・運用ルールは .claude/rules/progress-log.md を参照
  （本ファイルの編集時に自動ロードされる）
-->

> 以下は 2026-06-25 のテンプレート同期（進捗ログ 2 段構成への移行）に伴い，CLAUDE.md「開発進捗」セクションに蓄積していた `補足:` ログを移行したもの．**移行時点の文面をそのまま保持**している（古い記述・関数名等も歴史的記録として保持．今後の新規エントリは GUIDE_05 の書式に従い，`git log` で取れる詳細は書かない）．

## フェーズ 7（実装）— Step 8 基準設計キャリブレーション

現在の進捗（移行時点）: フェーズ 7（実装）— Step 1〜7 完了，Step 8（基準設計キャリブレーション）進行中．

Step 8 進捗（初期サマリ）: spp 校正（128→1024、ノイズ/物理差を切り分け）→ 反射率スイープ（0.75〜0.92、弱い二次レバーと判明）→ **手法訂正**: シミュ linear と実測 sRGB を直接突合していた交絡を発見．標準 sRGB OETF 順方向適用＋実測 mean アンカーで見かけ差の **約 2/3 が符号化ドメイン不一致**だったと判明．寄与順は OETF（最大）＞ ISP レンズシェーディング（残差主因候補）＞ 反射率（小）．残差 1.6〜1.9 倍は調整せず正直に保持．副次: max_depth=8 は勾配を過大評価（キャリブは depth≥12）．→ **OETF 順方向適用を sm-evaluate へ正規実装完了**（`evaluation/oetf.py` + `EvaluationConfig.oetf`、baseline 有効化・real 非適用、後方互換、参照実装と数値一致テスト済み）．[SPEC_03「キャリブレーション経過」参照](04_SPEC/SPEC_03_基準設計の物理構成.md)．

### 時系列ログ（古い順 → 新しい順）

- **3D ビュー改善**: 内部キャリブ調整は一旦中断し、**シミュ結果の見せ方（3D ビュー）改善**を実施．評価板実レンダ投影 → **path ベイク（`baker.py` mode="path"、多重反射込み per-face、scalar_rgb）** 追加 → 全メッシュ統一着色（共有 lit-clim・log・単一カラーバー）を既定化、`--render` は任意のテクスチャ投影オプション（評価板 E=π·L/ρ で同一スケール）、`--bake-cache` で 1 回計算→以後即時、`--opacity`/`--hide-below`/`--bake-smooth`/`--bake-scale` を追加．さらに **path ベイク max_depth を render 設定から独立（`--bake-max-depth`、既定 16）**＝後段多重反射を積分、**幾何カリング（`--cull-outward` 既定 ON、外向き ≈0 面を非描画）**＝暗殻の濁り/見かけ段差を解消、マーカー個別非表示フラグ、を追加．実装完了．
  - 既知の制約（受容済み）: per-face ベイクはメッシュ境界の継ぎ目・粗メッシュのブロック感・低 samples の MC ノイズ・scalar_rgb の遅さ（高 samples 非現実的）あり．精細な評価は 2D `sm-evaluate` で行う（不変）．隣接内壁の見かけ段差は調査の結果「外向き ≈0 面の混在」が主因と判明＝幾何カリングで解消（内壁照度自体は物理どおりほぼ均一）．
  - 次のアクション（別タスク）: シーム/粒状感の解消には全メッシュ UV 統合＋シームレスライトマップベイク（別プロジェクト規模）．必要時に別途 `/implement`．path ベイク高速化（wavefront/GPU）も別タスク．
- **実機搭載 LED の物性確定**（LED Paradise LP-2835D90VW / Ra98 SunLightLED 2835 4000K、Vf 3.1V・If 60mA・Φv 16–19 lm @60mA・配光角 120°・規格通り 60mA 駆動前提）．規格値から独立推定した radiance ≈ 2030 W/(m²·sr) は現状校正値 2807 と 1.38× 差で、反射率 0.85→0.89 への調整で物理範囲内に説明可能．既知差分 #3（LED 実 W 値未検証）クローズ．**形状指標への影響なし**（線形ゲイン）．配光は厳密 Lambertian 仮定継続（詳細 IES 未提供、実 SMD 2835 のやや前方凸性は ISP LSC と打ち消し合う近似として現状妥当）．詳細: [SPEC_03 LED セクション](04_SPEC/SPEC_03_基準設計の物理構成.md#led光源)．
- **輝度マップ「形」の追跡を導入**（[TEST_03 輝度マップ形状追跡](06_TEST/TEST_03_輝度マップ形状追跡.md) + `scripts/build_luminance_evolution_panel.py`）．重要な発見: **これまでの全 7 改善ステップ (8-1〜8-7) で輝度マップの「形」は全く変わっていない**．OETF は単調変換で形を変えず，発光面サイズ変更も形を変えない．**実機は中央付近にピークを持つ楕円状，シミュは下端のみ明の Y 軸単調勾配**．**LSC モデル化は「数値残差縮小」と「形の構造的改善」の両方を担う唯一の改善候補**．以後の改善判断は「数値 + 形」の 2 軸で行う．
- **Step 8-8 完了**: linear 評価モードに mean 揃え正規化を導入（`evaluation/normalize.py` の `apply_mean_anchor` + `EvaluationConfig.normalization` スキーマ + CLI 統合 + OETF 排他バリデーション）．OETF 露出アンカー（Step 8-3）と同じ思想を linear ドメインに対称展開．`configs/eval_baseline_linear.yaml` で有効化（target_mean=146.7146）．形状指標 (CoV/勾配/C/P/max-min) は厳密不変，mean のみ target_mean に揃う．動作確認: α=0.961934 で baseline luminance.npy が mean=146.7146, CoV=0.182577 で評価可能．
- **Step 8-9 完了**: LED 18 個の位置を Fusion 360 設計 STL (`configs/meshes/SmTIASv3.stl`) から抽出して `scene_baseline.yaml` を更新．`scripts/extract_led_positions_from_stl.py` で連結成分分割→ LED/カバー識別→ bottom/right/left 自動命名．主な変更: 下基板 LED 配置を「等間隔 8.7mm」→「3+ギャップ+3 (4.2mm+10.8mm+4.2mm)」へ訂正（実機写真の中央電流制限抵抗 2 個と整合）．左右基板も実位置に修正．**形状指標は ~1% 以内のほぼ不変**（多重反射が支配的，LED 数 mm 誤差は ROI 上で平滑化）．絶対 mean は +10% 増加（α 値 0.962→0.873）．既知差分 #2 をクローズ．TEST_03 比較パネルに Step 8-9 を追加（5 枚並列）．
- **LED 基板カバーを 3 枚構成に展開**: 従来は下基板用 `LED基板カバー.stl` 1 枚のみだったが，`scripts/extract_led_positions_from_stl.py --export-covers configs/meshes/` で SmTIASv3.stl から `LED基板カバー下/右/左.stl` の 3 ファイルを書き出し，`scene_baseline.yaml` の geometry を `led_cover_bottom/right/left` の 3 メッシュエントリに展開．右・左基板の LED が「カバーなしで浮く」状態を解消．多重反射計算への影響は軽微だが物理的に正確．
- **Step 8-10 完了**: LED 配光を `spot` emitter (cutoff=90°/beam=30°，FWHM 120° 一致，flux 保存 I_0=0.026784 W/sr) で表現する試行．`SpotLight` クラスを `schema.py` に追加，`lights.py` に spot 分岐実装，`configs/scene_baseline_spot.yaml` を並列保持．**目視で X 方向の対称性が部分改善**（下端の明るい領域が中央寄りに集中）だが，数値指標は微悪化（CoV +4%, 勾配 +15%）．LED 指向性は形の一部（X 方向）を変えるが，Y 方向の中央ピークは LSC モデル化（Step 8-N）が必要．本格採用は LSC との組み合わせ評価後に判断．付随発見: spot で mean が 14.6× 暗くなる（理由は spot falloff 関数の cos vs 角度ドメイン smoothstep の解釈差等を仮説）．
- **Step 8-11 完了**: データシート LP-2835D90VW 準拠の照明モデルを統合．`configs/scene_baseline_datasheet.yaml` に並列保持．spot を cos^1.2 相当の前方凸 (cutoff=85°/beam=26.72°，FWHM 111.72°) に詳細化 + 反射率を Step 8-6 で導出した物理整合点 0.89 に変更 + I_0 を規格値 Φv=17.5 lm から導出 (I_0=0.021951 W/sr)．**形は依然 Y 軸単調勾配**で Step 8-10 と Step 8-9 の中間値．**データシート従順度を上げても形は実機に近づかない**ことを確定．副次的に「規格値だけで mean を実機に合わせることはできず，校正値には他のレバーの累積吸収が含まれる」が再確認された．本筋 LSC モデル化が依然必要．
- **Step 8-12 完了**: Helmholtz 相反原理を Mitsuba 上で実証検証．`schema.py` の RenderConfig に `ptracer` integrator を追加，`configs/scene_baseline_perspective_{path,ptracer}.yaml` で perspective sensor + scalar_rgb + spp=4096 で比較．**bot/top 比が path 2.035 vs ptracer 2.006 で誤差 1.4% で一致**＝形は方向独立．絶対値は Mitsuba 実装の正規化差で 1.99× 違うが形（空間パターン）は同じ．副次的発見: **orthographic + ptracer は Mitsuba 3 では実行不能**（`Endpoint::sample_direction()` 未実装）．これにより「方向変更で形を実機に近づける道は無い」が確定し，**LSC モデル化が唯一の道**である結論が強化された．
  - 次のアクション（キャリブ再開時，当時の方針）: 残差に **LSC（ISP レンズシェーディング）順方向モデル**を当てる（物理動機づけ低自由度形、overfitting 回避・取得パラメータ数明記）．※後の Step 8-13 で本方針は不採用に確定（下記）．
- **速度最適化ワーク開始**（キャリブ作業を一旦中断）: [TEST_04 シミュレーション速度最適化履歴](06_TEST/TEST_04_シミュレーション速度最適化履歴.md) に試行を集約．**Speed-0 ベースライン計測完了**（`configs/scene_baseline.yaml`，3 回中央値）: **B1 sm-render = 507.86 s（≈8.46 分）/ B2 sm-visualize path bake (samples=16) = 55.97 s**．**副次発見**: `DRJIT_LIBLLVM_PATH` 環境変数の消失で sm-render が ImportError でクラッシュしていたことを発見．`C:\Program Files\LLVM\bin\LLVM-C.dll` を発見し **User scope に永続化**して復旧．sm-visualize の direct bake は内部 scalar_rgb 固定のため過去ログでも警告は出ていたが完走していた．**方向修正**: Speed-1 当初の「JIT 有効化で高速化」は既に JIT 経路に乗っているため不成立 → 「LLVM-C.dll 自動検出と診断ログ」に再定義（再発防止）．**本命の高速化レバーは Speed-2 path bake wavefront 化**（10× 以上見込み）．GPU は Intel HD Graphics 520 のみで CUDA 不可，CPU 側完結方針．精度（spp/max_depth）は不変．
- **Speed-1 完了**: `src/sm_tias_lightsim/runtime/llvm_init.py` に `ensure_drjit_libllvm_path()`（標準パス自動探索→ `os.environ` 設定）と `log_variant_status()`（llvm_/cuda_/scalar_ 経路を INFO 明示，要求 llvm_* で実 scalar_* なら WARNING 追加）を新規実装．`render/runner.py` で variant=llvm_* 時に自動検出を呼び、`ImportError` 時は原因明示ログ→ re-raise．`visualize/baker.py` でも `log_variant_status` 呼び出し追加＋ Speed-2 wavefront 化用に LLVM 自動探索の分岐を先取り．`cli/render.py` で import 順を制御．`docs/02_ENV/ENV_02_環境構築手順.md` に LLVM インストール手順・DRJIT_LIBLLVM_PATH 説明・動作確認コマンドを追記．**速度は不変**（コード経路同等）．数値同等性: SHA256 は MC 内部シードで異なるが平均相対誤差 7.23e-05 で統計同等性パス．これで「環境変数が消えて沈黙クラッシュ」する事故が再発しない土台が整備された．
- **速度最適化ワーク一旦中断**（Speed-2 path bake wavefront 化は未着手）: **実時間の改善は実質ゼロ**（B1=508s／B2=56s で不変）．副次的成果として環境破綻問題の発見と恒久対処，JIT 診断ログ，ベンチ条件のドキュメント，テスト追加が得られた．中断理由: B2 は現状ボトルネックではなく，B1 は CPU 完結・精度据置の制約下で取れる打ち手が限定的．本筋のキャリブ作業（LSC モデル化）に戻ることがプロジェクト目的により近い．再開条件: path bake samples を増やすユースケース発生／NVIDIA GPU 利用可／クラウド計算活用判断／キャリブ反復回数増加でバッチ時間が研究進度を圧迫した場合．詳細・Speed-2 テンプレ保持は [TEST_04 中断記録](06_TEST/TEST_04_シミュレーション速度最適化履歴.md#中断記録-suspension-note--2026-05-28) 参照．
- **キャリブ方針の根本見直し（2026-05-28）**: 「シミュ vs 実機 PNG の比較」を再検討した結果，**実機 PNG 自体が定量データとして揺らいでいる**ことが判明．SmTIAS の現行撮影は AE/AWB/NR/EDGE/TONEMAP/SHADING がすべて Camera2 API のオート/デフォルトで，撮影ごとに露光・WB・補正量が変動する．既存 baseline `MiniTIAS_20260408_144434` もこのモードで取得されており，シミュ側でいくらモデルを精緻化しても比較対象が不安定．**当初考えていた「LSC モデル化」より上位の問題**として「**定量撮影モード**」を SmTIAS 側に追加することを優先する．Android Camera2 API には `STATISTICS_LENS_SHADING_CORRECTION_MAP`・`SHADING_MODE=OFF`・`MANUAL_SENSOR`/`MANUAL_POST_PROCESSING` 能力フラグが存在し，これらを活用すれば「ISP 介入を最小化した再現性ある撮影」が可能．要求仕様を [TECH_01](05_TECH/TECH_01_定量撮影モード要求仕様.md) に，ハンドオフ手順を [TECH_02](05_TECH/TECH_02_SmTIAS引き継ぎ手順.md) に新規作成．データ受け渡しは `reference_measurement/quantitative/` 配下（gitignore 対象）．SmTIAS-LightSim 側のキャリブ作業は本仕様書を SmTIAS に渡した時点で一旦停止．
- **SmTIAS 側で定量モード実装完了（2026-06-01）**: [TECH_03](05_TECH/TECH_03_定量モード実装報告とSHADING_MODE相談.md) と [TECH_04](05_TECH/TECH_04_SmTIASへの回答.md) を取り込み．**AQUOS sense3 (SH-02M) は `LEVEL_3`（最上位）でハードウェア能力フル**．Phase 1〜5 全完了で **DNG (RAW_SENSOR) 経路を第 1 優先採用**．撮影設定: 1/60s + ISO 40 + AWB/NR/EDGE/AF/AE OFF + TONEMAP 線形 + BLACK_LEVEL_LOCK + SHADING_MODE=HIGH_QUALITY (★) + STATISTICS_LENS_SHADING_MAP_MODE=ON．LSC マップは 13×17．保存ファイルは `SmTIAS_QM_*.{dng, meta.json, preview.jpg}` 3 種．**SHADING_MODE 判断**: HIGH_QUALITY を本流維持（Mitsuba orthographic 出力 ≒「ISP が完璧に補正できた場合の理想値」で HIGH_QUALITY DNG と直接比較が物理整合）．OFF 切替は将来のフォールバック条件 C1-C3 発動時のみ．データ転送は **adb pull 推奨**．既存実機 PNG の Y' 抽出は BT.601 係数（Rec.709 ではない）も判明．
- **作業フェーズを A/B に分割（2026-06-01）**: 「連射再現性が確保できてもシミュとの対応が取れなければ意味が薄い」という研究上の判断から，**フェーズ A: 1 ショット撮影でシミュ vs 実機対応を先に検証** → **フェーズ B: 対応が取れたら連射 V1 再現性検証**の二段階方式に変更．フェーズ A で SmTIAS 側に依頼するのは **画素統計・Hot pixel map（高優先 2 件）と白板 1 ショット試し撮りのみ**．**連射 UI は高優先→フェーズ B に降格**．SmTIAS-LightSim 側は DNG/meta.json/LSC マップ読み込み I/F・新規 baseline config を実装し，1 ショット突合で既存通常モード baseline 残差 2.1× が定量モードで変化するかを観察．[TEST_01](06_TEST/TEST_01_キャリブレーション検証履歴.md) に **Step 8-13** として記録．
- **DNG 対応を SmTIAS-Evaluation 側にも依頼（2026-06-01）**: PNG から DNG への撮影フォーマット変更に伴い，SmTIAS-Evaluation も実機データの一次窓口として DNG 読み込み I/F の追加が必要．既存パターン（`uniformity.py` を SmTIAS-Evaluation から SmTIAS-LightSim にコピー）を踏襲する役割分担を採用：**SmTIAS-Evaluation 側で正規実装 → SmTIAS-LightSim 側にコピー**．[TECH_05](05_TECH/TECH_05_SmTIAS-Evaluation_DNG対応要求仕様.md) に要求書を作成．既存 PNG 経路と並列対応（後方互換）．依存追加: `rawpy>=0.21.0`．
- **SmTIAS-Evaluation 側 Phase 1 完了とハンドオフ受領（2026-06-01）**: TECH_05 Phase 1 (DNG 読み込み I/F) と LSC 順適用プロトタイプ・新指標 (動径 min/max 比) が完成．受領記録は [TECH_06](05_TECH/TECH_06_SmTIAS-Evaluation引き継ぎ受領.md)，関連分析は [TEST_05](06_TEST/TEST_05_PNG_DNG評価比較.md) と [TEST_06](06_TEST/TEST_06_外乱光影響評価.md)．**5 つの重要発見**: (1) **TECH_05 の `apply_lsc_inverse` は誤り**（DNG は LSC 未補正で逆ではなく順方向適用が正しい．TECH_05 §4 を訂正済）．(2) **過去 Step 8 キャリブの残差 2.1× はドメイン不一致**：正しい linear 比較では DNG linear+LSC 0.0689 vs シミュ linear 0.183 = **真の残差 2.66×**．(3) **新実機ターゲット = `MiniTIAS_QM_20260601_124500`（暗闇撮影）**: CoV=0.0695, 勾配=8.35%, 中心/周辺=1.0911, 動径 min/max=0.860．Step 8-13 以降の正規 baseline．(4) **外乱光ロバスト確認**: 室内灯 ON/OFF で指標差 < 1%．SmTIAS 自前照明が支配的で外乱光モデル化不要．(5) **新指標 `calc_radial_min_max_ratio`** を追加．
- **S2 完了 (2026-06-01)**: `src/sm_tias_lightsim/evaluation/dng_loader.py` を `handoff_smtias_lightsim/src/dng_loader.py` の完全コピーで新規作成．`radial.py` に `calc_radial_min_max_ratio` をマージ追加 (nan ビン除外を移植時に補強)．`pyproject.toml` に `rawpy>=0.21.0` 追加 (実 rawpy==0.27.0)．**検証 V4 が完全一致**: 実 DNG を読み込んで LSC 順方向適用 + 白板 ROI で評価指標 6 件が相対誤差 < 1e-6 で期待値完全一致，空間指標 3 件も絶対誤差 < 0.003．Refactorer 判断: `dng_loader.py` 内部の `_apply_srgb_oetf` は既存 `oetf.py:apply_srgb_oetf` と実装重複だが「コピー方針優先」「用途が異なる」「違反基準未満」でそのまま放置．
- **S3 方針見直しと Step D 完了 (2026-06-01)**: ユーザー指摘により「sm-evaluate に DNG 入力経路を追加する」当初案は **不採用**（実機 DNG 評価は SmTIAS-Evaluation の本業で完結，重複実装不要）．S3 を **3 項目に絞り込み**: Step D (動径 min/max 比を sm-evaluate に統合)・Step C' (新規シミュ用 baseline config)・Step G (シミュ再評価 → Step 8-13 記録)．**Step D 完了**: `MetricsConfig.radial_min_max` をスキーマ追加，`cli/evaluate.py` で `_run_radial_min_max` を追加して metrics.csv に 4 列追加，コンソールサマリに 2 行追加．`radial_profile` を再利用（重複算出回避）．後方互換維持．SPEC_04 §動径 min/max 比 を追記．
- **Step C' 完了と Step G 計測 (2026-06-02)**: `configs/eval_baseline_dng_target.yaml` を新規作成（eval_baseline_linear.yaml ベース，target_mean=207.82，radial_min_max=true，OETF なし）．Step 8-13 数値: シミュ CoV=0.1826, 勾配=24.65%, 中心/周辺=1.3271, 動径 min/max=0.6151．実機 DNG+LSC (CoV=0.0695, 勾配=8.35%, C/P=1.0911, 動径 min/max=0.860) と比較して **残差 2.63×**（TECH_06 予想「真の残差 2.66×」とほぼ一致）．過去 Step 8-3 の「2.1×」は PNG sRGB ガンマ圧縮による楽観値．**LSC 取り扱いの結論を [TECH_07](05_TECH/TECH_07_LSC取り扱い方針.md) に一元化**: 3 プロジェクト役割分担 (SmTIAS=HIGH_QUALITY 撮影 / SmTIAS-Evaluation=lscMap 順方向適用 / SmTIAS-LightSim=一切扱わない)，シミュ側で LSC を扱わない物理的根拠 (Mitsuba orthographic = LSC 完璧補正後相当)，代替案 3 つ全却下，フォールバック条件 C1-C3，残差解釈 を明文化．
- **実機変更とシミュ側対応の整合マッピングを明文化 (2026-06-02)**: [TECH_08](05_TECH/TECH_08_実機変更とシミュ側対応.md) として作成．実機側 8 項目変更に対するシミュ側 3 層 (Mitsuba シーン定義 α / sm-render β / sm-evaluate γ) の対応をマッピング．**結論: シミュ側で実際に対応が必要だったのは sm-evaluate の config レベルでの OETF 無効化 (#4) と mean アンカー調整 (#3) の 2 項目のみで，他はすべて対応不要 (Mitsuba は per-channel 独立計算で AWB/AE/NR/EDGE 概念なし，orthographic で LSC 自然対応)**．計 15 項目以上で網羅チェック．**残差 2.63× は ISP 関連の対応漏れではなく，シミュ物理モデル誤差 (反射率精度・LED 配光モデル・メッシュ幾何精度等) が主因**と推定．
  - 補足: **「対応不要」を 2 タイプに細分化** (TECH_08 §許容している構造的差異)．**タイプ I (本質構造同一・対応概念なし)** = AWB/NR/EDGE/LSC 等，**タイプ II (構造的差異あり・白板で許容)** = AF (焦点モデル)/絞り口径食/ピクセル積分/センサノイズ/QE 波長依存/シャッター方式/温度依存．特に AF は実機 perspective+固定焦点 vs シミュ orthographic 無限遠相当という構造的違い．白板撮影では影響軽微で許容．舌模型評価時や残差精緻化フェーズで再評価対象．
- **S3 全体完結 — TEST_01 に Step 8-13 正式記録 + handoff 整理 (2026-06-02)**: [TEST_01 §Step 8-13](06_TEST/TEST_01_キャリブレーション検証履歴.md) に新方針 (実機 DNG+LSC linear) でのシミュ突合を正式記録．俯瞰サマリ表に新ターゲット (CoV=0.0695) と Step 8-13 結果 (CoV=0.1826, 残差 2.63×) を追加．§Step 8-N 候補 (LSC 順方向モデル) を「不採用 — Step 8-13 で方針確定」に更新（歴史的記録として保持）．`handoff_smtias_lightsim/` は整理: 参考スクリプト `run_uniformity_dng.py` のみ `reference_measurement/quantitative/reference_scripts/` に移動，他は取り込み済みのため削除．
- **LED データシート調査結果を [TECH_09](05_TECH/TECH_09_LEDデータシート調査結果.md) として明文化 (2026-06-02)**: **OEM 元 HONGLITRONIC (広州，鸿利智汇集团) のデータシートが存在**することが判明．LED Paradise LP-2835D90VW は HONGLITRONIC HL-A-2835D90VW シリーズ (PDF: lcsc.com/datasheet/C5362368.pdf) の OEM 再販品．**配光図から数値読み取り: ほぼ厳密 Lambertian (cos θ) と一致** (0°→1.0, 30°→0.87, 60°→0.50, 80°→0.15, 90°→0)．**重要な含意**: (1) 現状の area light Lambertian モデルはデータシート実測と整合．配光モデル精緻化余地は限定的．(2) **過去 Step 8-11「データシート従順版」(cos^1.2) は実態はデータシート不整合**だった (同等品の典型配光を借用)．道理で形状指標が悪化．(3) **Step 8-14 候補 B (LED 配光詳細化) の意義は限定的**．SPEC_03 の「やや前方凸」記述は訂正対象．取得 PDF は REFERENCE/datasheets/ に配置 (gitignore 対象)．
- **docs/05_TECH と docs/06_TEST に README 追加 (2026-06-02)**: 15 ファイルがフラットに並んで散らかり感があるため，性質分類と navigation を README で提供．05_TECH/README: 🟢 現状方針 (TECH_07-09) と 🔵 議論の経緯 (TECH_01-06)．06_TEST/README: 🟡 中核 (TEST_01-03) と 🔵 クローズ済み (TEST_04) と 📋 外部スナップショット (TEST_05/06)．ファイル削除・移動はせずナビゲーションのみ追加．
- **残差 2.63× の主因候補を [TECH_10](05_TECH/TECH_10_残差主因候補の網羅整理.md) として網羅整理 (2026-06-02)**: Step 8-14 候補選定の判断材料．5 カテゴリ 18 項目を網羅．当初の優先度評価: 🥇 A1 内壁の非 Lambertian 性 / 🥈 A8 反射率 R=0.85→0.89 / 🥉 A9 max_depth 8→16+．（※その後の検証で優先度は更新．下記参照）
- **Step 8-14 候補 γ (D1 ROI 整合の再確認) 完了 — クリア (2026-06-02)**: 設定変更ゼロ，既存設定の数値検証のみ．シミュ ROI (24, 37, 464, 450) の物理範囲 (幅 90.63×91.41 mm) と実機 ROI (539, 1015, 1400, 1409) の物理範囲 (物理分解能 0.0654 mm/px → 幅 91.54×92.13 mm) を比較した結果，**物理サイズ差 < 1%・中心位置差 < 1 mm で整合**．3 列パネル `output/_slide_panels/roi_alignment_check.png` でも視覚確認．**残差 2.63× の主因は ROI 整合ではない**ことが確定．副次発見: 評価板は実機画像中央から下方向に約 4.2 mm (65 px) オフセット配置だが ROI もそのオフセットに沿って選択されているため物理領域として整合．
- **Step 8-14 候補 β (A1 内壁の非 Lambertian 性) 完了 — クリア (2026-06-02)**: 候補 🥇 1 位だった A1 を 3×3 グリッド感度分析で検証．スキーマ拡張 (`BlendBSDFConfig` + `RoughConductorBSDFConfig`，`MaterialConfig` Union 拡張，forward reference + `model_rebuild()`) と `materials.py` 再帰変換 (`_build_bsdf_dict`) を新規実装．テンプレ `configs/scene_baseline_blend.yaml` + `scripts/sweep_blend_bsdf.py` + `scripts/build_blend_bsdf_panel.py`．**weight ∈ {0.05, 0.15, 0.30} × α ∈ {0.1, 0.3, 0.6} の 9 ジョブ実走 (75.5 分)**．結果: ベースライン純 diffuse (CoV=0.1826) と比較して **全 9 パターンが悪化または不変**．実機 (CoV=0.0695) 方向と **逆方向に動く**．「形」は w=0.30 で下端中央に specular 集中スポット顕在化．物理的解釈: 純 Lambertian は cos 重み散乱で多重反射の均一化作用が最大．specular 成分は光を集中させ均一化を阻害．**3D プリンタ白フィラメントは完全 Lambertian として扱うのが実機挙動に近い近似**と判明．**A1 は残差 2.63× の主因ではない**ことが確定．副次成果: スキーマ層に `blendbsdf` + `roughconductor` のサポートが入り再利用可能．
- **LED グループ別 sanity check 完了 — TEST_07 として報告 (2026-06-03)**: 「シミュが下/右/左の 3 LED 基板を物理位置どおりに独立にモデル化できているか」の基礎健全性確認．`scripts/sanity_led_groups.py` で各基板の 6 LED だけを ON にした一時 YAML を生成 → 3 ジョブ sm-render (約 25 分) → 比較パネル．結果: **方向性 ✓** (bottom は下端中央/right は右側面寄り/left は左側面寄り)，**左右対称性 ✓** (right mean=47.10 vs left mean=47.08)，**量的バランスは bottom が right/left の 2.10× で強い**．物理的説明: bottom LED は評価板下端真下に X 中央寄り集中で直接光が広範囲 / right/left LED は側面外側 Y 中央付近に分散で中央は多重反射経由．**線形性検証は別途未実施**（既存 `output/baseline/luminance.npy` が Step 8-1 時点の古いもの．Mitsuba は理論線形なので baseline 再生成で一致見込み）．副次発見: 実機の right/left は **完全な左右対称設計ではない**（Fusion STL 実位置と整合）．[TEST_07](06_TEST/TEST_07_LEDグループ別動作確認.md) 参照．
- **scene_baseline.yaml の max_depth を 8 → 16 へ更新 (2026-06-03)**: Step 8-14 候補 α 前半の結論「d=16 が実用収束点」を反映．SPEC_03 既知差分 #6 (未対処の max_depth=8) を解消．SPEC_03 の関連 4 箇所を一括更新．影響: 今後の sm-render は自動的に d=16 で実行され理論累積 92.6% を取り込む．計算時間は約 2× (8.5 分 → 17 分) に増加するが形状指標 4 つすべてが d=8 時代より実機方向に改善 (CoV 0.1817 → 0.1604, 勾配 24.01% → 20.59%)．
- **Step 8-14 候補 ξ (A2/A3 LED 配光 cutoff スイープ) 完了 — 配光が形改善の本物の候補として初実証 (2026-06-03)**: ユーザー要請「配光条件を変えてどのような変化が起こるかの実験（データシートに合わせる必要なし）」に基づき，`scripts/sweep_led_distribution.py` で spot emitter の cutoff_angle を {30°, 60°, 90°, 120°, 150°} で 5 値スイープ (beam_width = cutoff/3，max_depth=16，約 85 分)．**重要な 2 つの発見**: ① **「area light → spot」のステップが本質的** — area (Lambertian) の angular_ratio=0.4536 → spot (どの cutoff でも) 0.34〜0.36 へ **25% 大幅低下** (実機方向)．② **cutoff スイープ内 (30°→150°) では effect 限定的** — angular_ratio は +0.018 のみ．**A8 と真逆のパターン**: 数値悪化 (CoV +3〜11%) するが形改善 (angular_ratio -25%)．「数値の偽物の一致」(A8) と対をなす「形改善の本物の候補」初実証．物理的解釈: spot は +Z 方向にしか光を出さない → 内壁に当たる成分減・直接光増 → LED 直下の明点 → 半径方向ばらつき支配 (angular_ratio 減)．area は半球全方向拡散で多重反射 ambient 支配 → Y 軸勾配．副次発見: 数値最良点 (cutoff=90°) と形最良点 (cutoff=30°) が異なる→キャリブの優先順位議論を明確化．**TECH_10 優先順位を再更新**: A2/A3/ξ を「形改善候補」へ昇格．
- **Step 8-14 候補 α 後半 (A8 反射率スイープ) 完了 — 数値改善のみ・形は逆効果 / 「数値の偽物の一致」の初の定量実証 (2026-06-03)**: `scripts/sweep_reflectance.py` で d=16 新基準のもと R ∈ {0.75, 0.80, 0.85, 0.89, 0.92} を 5 値スイープ．新指標 (shape_metrics) を初めて感度分析に投入．結果: 既存 4 指標 (CoV/勾配/C/P/動径 min/max) は単調改善 (R=0.75→0.92 で CoV 0.186→0.142 で残差 24% 縮小) するが，**新指標 angular_ratio は 0.408→0.494 で実機方向と逆に増加**．実機は中央ピーク楕円 (同心円的) なので **形は実機から遠ざかる**．物理的解釈: R 上昇で ambient 増 → 半径方向の偏りは圧縮されるが角度方向ばらつきは相対的に圧縮されにくい → angular_ratio 増加．**形改善の本筋は B1 筐体幾何精度に最終確定**（A1/A8/A9 すべてクリア済で構造的再配分系のみ残る）．副次発見: R=0.85 の CoV=0.1604 が max_depth スイープ d=16 と完全一致．新指標を導入していなければ気づけない発見で，形状指標見直し (TECH_11) の正当性が定量データで裏付けられた．
- **Step 8-14 候補 α 前半 (A9 max_depth スイープ) 完了 — 数値改善のみクリア・形不変 (2026-06-03)**: ユーザー仮説「現状 d=8 では 0.85^8≈0.27 で取りこぼし大」を 5 値スイープ {8, 12, 16, 20, 28} で検証 (`scripts/sweep_max_depth.py` 約 85 分 + `scripts/build_max_depth_panel.py`)．結果: 全 4 形状指標が **単調に実機方向に改善** (d=8→28 で CoV 0.1817→0.1583 で残差 20.9% 縮小)．mean は 207.82 で固定．**実用的な収束は d=16 で達成** (d=16→28 で CoV 1.3% のみ)．**「形」は完全に不変** (Y 軸単調勾配のまま contrast が緩むだけ)．物理的解釈: 多重反射は **空間的に均一な ambient 成分**で，足しても暗/明の絶対差は縮むが空間配置は不変．「LED が下にしかない」配置の非対称性は除去不能．**ユーザー仮説の評価**: 方向性は正しい (21-28% 残差縮小) だが実用収束は d=16，実機 (CoV=0.0695) には届かず残差は形改善で詰める必要．新キャリブベースライン: **d=16**．
- **形状指標の本質的見直しと新指標導入 (2026-06-03)**: 「数値が実機方向に動いても形は変わらない」が続けて確定したため，ユーザー指摘「現状 4 指標は不均一性の絶対量しか測れず，Y 軸単調勾配と中央ピーク楕円を構造的に区別できない」に対応する **形を直接評価する 5 指標** を追加実装．`src/sm_tias_lightsim/evaluation/shape_metrics.py` (新規): `calc_intensity_centroid` / `calc_angular_radial_decomposition` (angular_ratio: 0=同心円, 1=方向依存) / `calc_ssim` (scikit-image 依存) / `calc_ncc` / `calc_intensity_pca` の純関数 5 つ．`MetricsConfig` に `shape_metrics` / `shape_reference` を追加（後方互換）．`configs/eval_baseline_dng_target_shape.yaml` を新規作成．`pyproject.toml` に `scikit-image>=0.21.0` を追加．[TECH_11](05_TECH/TECH_11_形状指標の見直しと新指標導入.md) で背景・計算式・予想値・遡及的注記を記録．今後の評価方針: **数値指標 4 + 形指標 5 + 視覚比較の 3 軸評価**で「数値改善のみで形が変わらない候補」と「形を変えうる候補」を明確に区別する．
- **面光源スケール軸バグの発見・修正 — 下灯 2.1× の真因確定 (2026-06-29)**: 実機の単灯（下/左/右）実測データ（`lightsim/`，SmTIAS-Evaluation 引き渡し，各灯単独点灯の白板 ROI 輝度マップ）とシミュ単灯を**灯ごとに突き合わせ**た結果，`scene/lights.py` の `_build_area_light_transform` に**座標軸取り違えバグ**を発見．Mitsuba の rectangle は実体「XY 平面・法線 +Z」（実機 Mitsuba で検証）なのに，コードは旧コメント「XZ 平面・+Y 前面」を前提に `scale([sw/2, 1.0, sh/2])` と書かれ，**高さ `sh` を潰れた奥行き Z に入れ・縦 Y を無補正（±1m）のまま**にしていた → **全 18 LED が「幅 ~3mm × 高さ 2000mm」の縦長ストリップ**化．全灯が同一 look_at（direction=(0,0,-1), up=(0,1,0)）のため local Y→world Y で全灯が world Y に 2m 伸び，**板中央の真裏にある下灯だけが過剰に効いて 2.1×** を生んでいた（左右灯は x=±66 で板外・壁脇のため損失大）．**修正は 1 行**: `scale([sw/2, sh/2, 1.0])`．
  - **検証 (spp=1024, max_depth=16)**: 灯間 mean 比は bottom 2.099→**1.000（最暗）** / left 1.000→1.028 / right 1.000→1.026 となり，**実機の「3 灯均等・下灯最暗」順序に一致**．線形性（単灯和≈全灯）誤差 0.34%．全灯合成 linear CoV は **0.1815→0.1641**（公式 sm-evaluate，残差 2.63×→2.36×）の**小改善にとどまる**．center/周辺比・勾配はほぼ不変．
  - **論点の移動**: 灯間バランス問題は解決したが，**残る不一致は各単灯フットプリントの拡散不足**（修正後 peak/mean≈1.7 vs 実機≈1.2，シミュは中央尖り＋上暗下明，実機はほぼ一様）．本筋は**配光 ξ／ディフューザー拡散のモデル化**へ移った．成果物: 修正後出力 `output/{sanity_fix_1024,baseline_fix_1024}/`，比較図 `output/_slide_panels/{sim_vs_real_shape_fixed,sim_vs_real_colormap_fixed}.png`，記録 [TEST_08](06_TEST/TEST_08_面光源スケール軸バグの発見と修正.md)．
  - **過去結論の訂正**: [TEST_07](06_TEST/TEST_07_LEDグループ別動作確認.md) の「下灯 2.1× は直接光効率の幾何的優位で物理的に正しい／意図した設計」は**誤り**（バグ込み出力を物理で後付け正当化していた）．TEST_07 冒頭に訂正注記を追加．**教訓**: シミュ出力を物理で後付け説明するとバグを設計意図と取り違える危険があり，実機グラウンドトゥルースとの灯ごと突合が有効だった．なお `lightsim/` は実測入力として `.gitignore` 対象．
- **照明分布の「形」不一致の原因切り分け開始 — 混ぜ具合では詰められず B1 幾何に絞り込み (2026-06-29)**: バグ修正後も残る「形が実機と一致しない」問題（実機単灯は peak/mean≈1.2 のほぼ一様，シミュは≈1.7 で中央尖り＋上暗下明）を，**形の一致（実機マップ参照の NCC/SSIM＋視覚＋放射プロファイル）を唯一の判定基準**に切り分け開始．[TEST_09](06_TEST/TEST_09_照明分布の形不一致の原因切り分け.md) に記録．**前提確認**: 実機は **LED カバー＝筐体と同じ不透明白材・別ディフューザー無し**（ユーザー確認）＝むき出し LED＋白筐体のみ → 実機の平らさは筐体多重反射（積分球的拡散）由来でしかありえず，鍵は新部品でなく筐体（反射＋幾何）のモデル化．**重要**: 過去 Step 8-14 の「A8/A9/A1 を振っても形は変わらない」はすべて面光源バグ込みの結論で，TEST_07 同様に要再検証．
  - **実験1（bottom 単灯 spp=1024 max_depth バウンス分解 {1,2,4,8,16,32}）**: depth=1,2 が**真っ暗（mean=0）**＝LED は板に背を向け **板は完全に間接光のみ**（3〜4 反射でやっと到達）．バウンス増で多少平らになるが **d16 で頭打ち**（d16≈d32），到達点 peak/mean **1.65** が実機 **1.22** に届かず・NCC 0.67 頭打ち．**混ぜ不足は原因でない**．完全閉箱なら無限反射で均一化するはずが尖り＋縦勾配が残る＝**光が混ざりきる前に逃げている**疑い．出力 `output/depth_bottom/d{N}/`，図 `output/_slide_panels/depth_bottom_shape_roi.png`（ROI 揃え．数値は TEST_09 が正：ROI 版で d16 peak/mean=1.59・NCC=0.72）．
  - **実験2（bottom 単灯 spp=1024 d=16 反射率スイープ R={0.85,0.90,0.95,0.98}）**: R↑で少し平ら（peak/mean 1.65→1.44，縦勾配 top/bot 0.867→0.894 で実機方向）だが **R=0.98（非現実的高反射）でも 1.44 止まりで実機 1.22 に届かず，NCC は改善せず微減**（0.670→0.640）．**反射率も本筋でない**．出力 `output/refl_bottom/run_r{90,95,98}/`，図 `output/_slide_panels/refl_bottom_shape_roi.png`（ROI 揃え．数値は TEST_09 が正）．
  - **総括**: 「筐体が光をかき混ぜる強さ」を司る 2 レバー（反射回数・反射率）を両方上限まで振っても形は実機の平らさに構造的に届かない → **形の残差の本筋は B1 筐体幾何（光の入り方・箱の閉じ漏れ）に絞り込み**．次は実験3（漏れの定量化／開口を白壁で塞ぐ閉じテスト）．補足: 実機マップは LSC 補正済みのため，実験3 前に「実機の平らさが本物の照明分布か処理由来か」を一度確認すると安全．
- **バグの独立検証・修正前後比較・LED 幾何 3D 確認ツールを整備 (2026-06-29)**: 上司報告向けに「2m ストリップ化」を可視化マーカーに頼らず裏付け．[TEST_08](06_TEST/TEST_08_面光源スケール軸バグの発見と修正.md) に 3 重の一次証拠を追記: ① git で修正前の実コード行を確定，② 修正前の式で `rectangle` を生成し **Mitsuba の `bbox()` が X=2.80mm / Y=2000.00mm（面積 5600mm²＝実物の約 570 倍）と報告**，③ `builder→_build_area_light_transform→mi.render` の呼び出し経路で実レンダ使用を確認．新規ツール `scripts/show_led_geometry.py`（LED を実サイズ長方形＋発光方向矢印で 3D 表示，`--buggy` で修正前の 2m ストリップ再現，`--screenshot` で 4 アングル保存）を追加．これで **LED 位置・サイズ・向きは実機どおり（評価板を背にする設計で正しい）＝形不一致の容疑者から無罪**を 3D で確認．
  - **修正前後カラーマップ比較**（TEST_08 に追記，図 `output/_slide_panels/before_after_{shape,amplitude}.png`）: mean 正規化した「形」は修正前後でほぼ不変（合成 peak/mean 1.54→1.54）．**バグが壊していたのは形でなく灯間の明るさ**（下灯 left基準で 2.10→0.97 へ均等化）．だから合成 CoV も小改善にとどまった．
  - **修正後 3 単灯は形がほぼ同一**（TEST_09 に追記）: 板が間接光のみ＋Lambertian 拡散壁で照らされるため形が光源でなく筐体で決まる（積分球原理＝多重反射が光源形状を洗い流す）．結果，下・左・右の単灯フットプリントが互いに **NCC≈0.92** とほぼ同形（縦勾配 top/bot≈0.85/1.06 が 3 灯共通）．**実機（TEST_04）の「3 灯が相補的に別方向を照らす」を再現できていない**＝シミュでは LED 位置の効きが弱すぎる→ (a) B1 幾何不正確 or (b) 間接化しすぎ（実機は各灯の指向性がもっと残る）を示唆．実験3 の追加手がかり．
- **実験5（壁の光沢化 blend BSDF）再検証完了 — 材料側レバー出尽くし・実機の非対称相補性を初定量化 (2026-07-14)**: 旧 Step 8-14 β の A1 blend 実験はバグ込み・3 灯・絶対指標のため，修正後 LED・bottom 単灯・形指標（TEST_09 流）で正式に再検証．`printer_white` を blendbsdf 化し w∈{0.05,0.15,0.3,0.6}×α∈{0.1,0.3,0.6} の 12 ジョブ（spp=1024, d=16，約 2h）＋最強光沢 w0.6_a0.1 で left/right 単灯を追加レンダ．**結果 ①（平らさ）**: 全 12 ジョブが純 diffuse（peak/mean 1.585・NCC 0.721）より悪化し w に単調悪化（最悪 w0.6_a0.1 で 2.145/0.667）＝光沢はホットスポットを作り実機の平らさと逆方向．**結果 ②（相補性）**: 灯間 NCC は diffuse 0.96 → blend 0.86 に低下し「Lambertian 壁が光源形状を洗い流す」機構自体は実証されたが，**実機の灯間 NCC は 0.85/0.61/0.41 と強く非対称**（今回初定量化，実験4 以降の到達目標アンカー）で，等方な材料変更では原理的に再現不能．単灯の対実機 NCC も 3 灯とも悪化するトレードオフ．**結論: 壁の反射特性は大きさ（実験2）・種類（実験5）とも本筋でなく，B1 筐体幾何が唯一の残存候補として確定**．副次修正: TEST_09 §追加観察の灯間 NCC≈0.92 は低 spp ノイズによる過小（spp=1024 で 0.96）と判明し訂正．成果物: `output/blend_bottom/`（summary.csv 含む），解析 `scripts/build_blend_bottom_panel.py`，図 `output/_slide_panels/blend_bottom_shape_roi.png`，記録 [TEST_09 §実験5](06_TEST/TEST_09_照明分布の形不一致の原因切り分け.md)．次: 実験4（幾何の漏れ点検＝漏れの定量化・開口の閉じテスト）．
  - **left/right 拡張 (2026-07-14)**: 時間短縮のため縮小グリッド w∈{0.05,0.3}×α∈{0.1,0.6}（＋w0.6_a0.1）を left/right 単灯でも実走（8 ジョブ）．**「w 単調悪化」は 3 灯共通**（w0.6_a0.1 で left 2.03/right 2.20 まで尖る）．3 灯揃う 5 材料条件の灯間 NCC は w に対し一様に低下（0.96→0.92→0.86）するが**常に 3 ペア均等で実機の非対称（0.85/0.61/0.41）に近づかず**＝「等方な材料変更は 3 ペアを一様にしか動かせない」をスイープ全域で確認．解析スクリプトは --side 引数で 3 灯対応化．
- **TEST_10 後側ロフト変形 w=1.4 実験完了 — 幾何レバーが形を動かすことを初実証・対称変形では相補性は不動 (2026-07-26)**: 実験4 に先行し，ユーザーが Fusion で後側筐体のロフトパラメータを 0.5→1.4 に変えた `後側_w1p4.stl`（下側フレア部 Z=-150〜-86 が外側へ最大 10mm 膨張・体積 +6.3%，LED/評価板側は不変）をシミュで評価．TEST_09 パネルの見た目からユーザーが選定した blend w=0.05・α=0.1（形を壊さない最弱光沢で幾何の効きを残す意図）・spp=1024・d=16 で単灯 3＋全灯 2（元メッシュ全灯 blend 基準含む）の 5 レンダ．**結果 ①**: bottom 単灯 peak/mean 1.672→1.508 と明確に平ら化＝**筐体幾何が形を動かせることの初実証**（TEST_09 の光源側・材料側レバーはすべて不発だった）．ただし left/right は不動で NCC 対実機は 3 灯とも微減．**結果 ②**: 灯間 NCC は 0.95x→0.96x と不動（むしろ同形化）＝**対称なキャビティ拡大では実機の非対称相補性（0.85/0.61/0.41）に近づかない**．TEST_09 実験5 の「等方な材料変更では 3 ペアを一様にしか動かせない」が対称幾何変更にも当てはまると判明．**結果 ③**: 全灯 CoV 0.1717→0.1701 でほぼ不変＝印刷リスクは低いが期待効果も小．**次への示唆**: 非対称相補性の再現には灯ごとに光路が変わる非対称幾何（開口・仕切り・カバー形状）が必要＝実験4（幾何の漏れ点検）の優先度を再確認．失敗パターン: 全灯 config を `_tmp_loft_w1p4/` に置いたら scene_baseline.yaml 由来の相対メッシュパスが config 起点解決で file not found→絶対パス化で解決．成果物: `output/loft_w1p4/`（summary.csv 含む），図 `output/_slide_panels/loft_w1p4_shape_roi.png`，記録 [TEST_10](06_TEST/TEST_10_後側ロフト変形w1p4実験.md)．
- **TEST_10 拡張 — 全灯ロフト重みスイープで「ロフトは全灯に実質不感」を確定 (2026-07-28)**: ユーザー作成の `後側_{w2p0,w4p0}.stl`（w4.0 は体積 +66%・元外形を Z に 43mm はみ出しスマホ面と交差）を追加し，全灯のみ同条件（blend w0.05_a0.1・spp=1024・d=16）で w ∈ {0.5, 1.4, 2.0, 4.0} をスイープ．CoV 0.170〜0.177・NCC 対実機 0.737〜0.747 で全指標横ばい（最大の w4.0 のみ微悪化）＝**ロフト（フレア部の対称な膨らみ）は全灯の均一性・形に対して実質不感なパラメータ**．単灯 bottom で見えた平ら化も全灯合成では消える．副次: w4.0 は絶対照度が -29%（キャビティ拡大で光が薄まる）．また実機全灯マップを `MiniTIAS_QM_20260601_124500.dng` から単灯と同一手順で npy 化（CoV=0.0695 で Step 8-13 記録値と一致検証済み，`lightsim/luminance_maps/full_*.npy`）し，4×3 形パネルの full 行を実機込みに拡充．均一性の絶対比較用に各セル max=1.0 の相対輝度パネル（シミュ mean/max 0.64〜0.67 vs 実機 0.899）も追加．解析・パネル生成は `scripts/build_loft_w1p4_panel.py` に集約．実機側: ロフト w=1.4 版を印刷・組込みし初の実機測定 `MiniTIAS_QM_20260726_183416.dng`（全灯・定量モード）を取得済み＝SmTIAS-Evaluation での分析待ち（シミュ予測「従来筐体とほぼ同じ」の検証ポイント）．記録 [TEST_10 §拡張](06_TEST/TEST_10_後側ロフト変形w1p4実験.md)．
- **TEST_11 球体筐体実験完了 — 幾何の理想極限（完全閉球・積分球）でも実機の均一性に届かないことを上限実証 (2026-08-17)**: ユーザー発案「筐体を球体に変えたらどうなるか」を，実機構成にとらわれない理想化実験として設計（評価板のみ現行同位置で共通，他メッシュ全撤去，`scripts/generate_sphere_housing.py` によるスクリプト生成の完全閉球殻 r=100mm，単灯を壁向き配置＝評価板への直接光ゼロ，blend w0.05_a0.1・d=16）．**結果 ①**: CoV 0.1717→**0.1350**（-21%）・mean/max 0.671→0.756 と改善するが，**実機（0.0695／0.899）には遠く及ばない**＝漏れゼロ・完全対称・完全間接の理想積分球ですらこの水準で，筐体幾何の追い込みだけでは実機水準の均一性に到達できないことの上限実証．**結果 ②**: 形は Y 単調勾配→中心対称ドームへ質的変化（angular_ratio 0.352→0.126）だが NCC 対実機はむしろ低下（0.744→0.460）＝実機の形は「理想混合の形」と構造的に別物で，実機の平坦さは ISP LSC 等の非幾何要因が本命という推定を補強．残る CoV 0.135 の物理源は R=0.85 の未混合一次照射成分（幾何では消せない）．失敗パターン: ① 単灯を壁 5mm 手前に置く案 → path tracer の NEE がほぼ外れ spp=64 で相対ノイズ 89% と実用不能 → 壁 50mm 手前へ移動（直接光ゼロは維持）＋spp=8192 で残留 0.79% に解決 / ② ptracer への切替案 → orthographic センサ非対応（sample_direction 未実装，Step 8-12 の知見と同根）で不成立．副次: 新マシンに環境を新規構築（uv・LLVM 22・`uv sync`）し，full_base 再評価で保存済み metrics と完全一致を確認＝評価パイプラインのマシン間再現性を実証．成果物: `configs/scene_sphere_r100.yaml`，`output/sphere_r100/`，図 `output/_slide_panels/sphere_r100_{shape_roi,relative}.png`，解析 `scripts/build_sphere_panel.py`，記録 [TEST_11](06_TEST/TEST_11_球体筐体実験.md)．次: 実験4（幾何の漏れ点検）は引き続き未着手で残存．
- **TEST_11 改訂 — 評価板嵌め込み・ロフト一体化版で幾何上限を更新（CoV 床 ≈0.12 を確定）(2026-08-18)**: ユーザー指摘「初版は板が球内に浮いて縁に隙間がある．すっぽり嵌めたい」を受け，① 球を板に貫入させる fit 版（四隅貫通・ROI 四隅に壁が写る難あり，3D 確認のみでレンダ未実施）→ ② Fusion のロフト相当の「板輪郭矩形→球断面円」遷移スカートをスクリプト生成し球お椀と一体化した版（`scripts/generate_sphere_loft_housing.py`，Hermite ブレンドで球側接線連続・板実体に食い込むリムでシール・watertight）へ 2 段階で改訂．結果: CoV 0.135→**0.120**（現行筐体比 -30%）・angular_ratio 0.110 と均一性/対称性は更に向上したが peak/mean は 1.32→1.39 と微増（閉じるほど中央集中がわずかに強まるトレードオフ）．**結論は不変＝幾何の理想極限でも実機 0.0695 に届かず，残差の本命は非幾何要因（ISP LSC 等）**．運用変更 2 点（ユーザー指示）: (a) **幾何変更時はレンダ前に 3D 配置確認→OK 後にレンダ**を必須化（CLAUDE.md 必須ルール追記），(b) **spp は 8192→1024 に統一**（TEST_09/10 との条件統一優先．残留ノイズ 2.3%・CoV 汚染 +0.002 で許容）．成果物: `configs/scene_sphere_r100_loft.yaml`，`configs/meshes/球ロフト_r100.stl`，`output/sphere_r100_loft/`，図 `output/_slide_panels/sphere_loft_{shape_roi,relative}.png`（1×4 パネル），記録 [TEST_11 §改訂](06_TEST/TEST_11_球体筐体実験.md)．
- **TEST_11 追補 — 円形光源（disk）対応と完全軸対称化・発光面形状の不感を確認 (2026-08-18)**: ユーザー指示「光源を矩形でなく円形にして軸上に置きたい」に対応．スキーマの area 光源に `shape: disk`（radius 必須検証付き，rectangle は後方互換）を追加し `lights.py` を rectangle/disk 共通の半幅スケールに一般化（SPEC_02 更新・スケール実寸検証テスト追加・fast 898 件全パス）．3D 確認ツール 2 種（sm-visualize マーカー・show_led_geometry）も disk 描画対応．同面積円板（r=1.7662mm＝9.8mm² 保存）でレンダした結果，**全指標が矩形版と MC ノイズ内で完全一致**（CoV 0.12047 vs 0.12044）＝完全間接キャビティでは発光面形状は不感（TEST_09「Lambertian 壁が光源形状を洗い流す」の再確認）で，矩形 LED の非軸対称性は残差要因でないことを確定．以後は円形光源版を球実験の正準構成とする．成果物: `configs/scene_sphere_r100_loft_disk.yaml`，`output/sphere_r100_loft_disk/`，1×5 比較パネル更新，記録 [TEST_11 §追補](06_TEST/TEST_11_球体筐体実験.md)．
- **TEST_12 シェーディング法線アーティファクトの発見と修正 — Step 8 残差の支配成分がレンダリングバグと判明 (2026-08-18)**: 完全軸対称化した球実験の輝度マップが同心円にならない違和感（ユーザー指摘）を起点に消去法診断（円形/矩形プレート×浮き球/ロフト筐体の 4 診断＝すべて対称，実物評価板のみ非対称，`face_normals=true` で完全対称化）でバグを特定．**原因**: builder の PLY 出力に法線が無く Mitsuba がスムーズ頂点法線を自動生成 → 評価板裏面は巨大三角形 26 枚・全頂点エッジ上で法線が約 47° 傾き，評価面全体が汚染補間される．**修正**: builder で `face_normals: true` を強制（1 行＋再発防止テスト）．**影響**: 現行筐体全灯 CoV 0.1717→**0.0610**（実機 0.0695 を下回る），勾配 24.7→6.8%（実機 8.35%），C/P 1.328→1.073（実機 1.091）＝**Step 8-13 以降の「残差 2.4×」の大半と「Y 軸単調勾配」の見かけはこのアーティファクトだった**．球ロフトは CoV 0.0628・angular_ratio 0.005（完全同心円）で現行筐体とほぼ同等＝**現行筐体はすでに理想積分球級の混合性能**（TEST_11 の「球で -30% 改善」も撤回）．振幅系指標が実機と揃った今，残る差分は「形」（実機の斜め構造 vs シミュの上端暗，NCC 0.616）に移った．過去の絶対値・形の結論は要再検証，相対比較の結論（ロフト不感・レバー序列）は共有アーティファクトのため方向性は保持見込み（各文書の BEFORE FIX 注記参照）．検証手順: 再構成 full_base を修正前コードで保存済み結果と一致確認（CoV 差 1e-4）→ 修正後再レンダで前後差を分離．成果物: `output/{full_base_fix,sphere_r100_loft_disk_fix}/`，図 `output/_slide_panels/sphere_fix_{shape_roi,relative}.png`，記録 [TEST_12](06_TEST/TEST_12_シェーディング法線アーティファクトの発見と修正.md)．
- **TEST_12 追補 — 単灯再検証で TEST_09 中核結論「3 灯同形」を撤回・非対称相補性の部分再現を確認 (2026-08-18)**: 基準単灯 3 灯（blend w0.05_a0.1）を修正版で再レンダ（ロフト w1p4 系はユーザー判断でスキップ）．灯間 NCC（平滑）は修正前 0.99 均等 → **修正後 0.85/0.93/0.73 の非対称**＝「シミュは 3 灯ほぼ同形で非対称相補性を再現できない → B1 非対称幾何が唯一の候補」（TEST_09）はアーティファクトが作った見かけと判明し撤回（TEST_09 冒頭に BEFORE FIX 注記）．修正後シミュは「left-right が最も異なる」点で実機（0.92/0.66/0.44）と一致するが，差の振幅は弱く最類似ペアは不一致＝実験4（漏れ点検）の主動機は大幅に弱まり，残る課題は相補性の振幅・並びと実機の斜め構造の切り分けに再設定．計測上の学び: 単灯 spp=1024 はノイズ 5.3% > 構造振幅 4% で raw 指標（特に peak/mean・NCC）はノイズ支配 → 灯間 NCC は raw/smooth 併記とし解釈は smooth を正（`pairwise_ncc.csv`），以後の単灯実験は spp≥4096 推奨．成果物: `output/singles_fix/`，`scripts/build_singles_fix_summary.py`，図 `output/_slide_panels/singles_fix_shape_roi.png`，記録 [TEST_12 §追補](06_TEST/TEST_12_シェーディング法線アーティファクトの発見と修正.md)．
- **TEST_12 追補 2 — ロフト w1.4 の修正後再検証で TEST_10 の判定を確定 (2026-08-18)**: ロフト w1.4（全灯 1＋単灯 3）を修正版で再レンダ．**④「全灯に実質不感」は維持**（CoV 0.0610→0.0605，全指標差 ≈1%＝実機 w1.4 測定への予測「従来筐体とほぼ同じ」も不変）．**③「対称拡大は 3 灯を同形化」も維持・明確化**（灯間 NCC 平滑 0.85/0.93/0.73→0.91/0.96/0.84 で実機の非対称から遠ざかる）．一方 **①「bottom 単灯の平ら化＝幾何レバー初実証」は撤回相当に弱まる**（平滑 p/m 変化 -0.9% のみ．TEST_10 の raw -10% はアーティファクト期の見かけが大半．修正後 raw p/m はヘビーテイルノイズの最大値ゆらぎで不採用）．②「left/right 不動」維持．TEST_10 冒頭に BEFORE FIX 注記（結論の生死を明記）．成果物: `output/full_w1p4_fix/`・`output/singles_fix/*_w1p4/`，summary/pairwise CSV と 3×4 パネル更新，記録 [TEST_12 §ロフト再検証](06_TEST/TEST_12_シェーディング法線アーティファクトの発見と修正.md)．
- **TEST_13 物理モデル健全性の一括監査 — 潜在バグ 3 件を修正し再発防止テストを常設 (2026-08-30)**: TEST_12 と同じ「エラーも警告も出ないまま結果だけが歪む」故障モードが他に残っていないかを横断監査（動機: 同型のバグが TEST_08 でも起きており，そのとき TEST_07 が誤出力を「物理的に正しい」と一度正当化している＝3 度目を防ぐ）．**健全と確認**: シェーディング法線 == 幾何法線（実測逸脱 0.044 度）・メッシュ法線の向き（裏面ヒット 0・全 15 STL 巻き順一貫）・**絶対放射量（積分球の解析解と 0.2% 一致＝単位系/反射率/光源パワー/センサ校正が正しい）**・面光源の軸マッピング．**修正した問題 3 件**: ① 片面 BSDF の脆弱性（法線が裏返ると無警告で真っ黒．`twosided` ラップで恒久修正．実シーンでは mean +0.015%＝無影響を確認）／ ② **LLVM 初期化の順序バグで `slow` レンダテスト 8 件が長期間全滅**（`scene/lights.py` がモジュール import 時に mitsuba を読むため `runner.py` の自動探索が手遅れ．開発機は環境変数が永続設定済みで症状が隠れていた）／ ③ TEST_08 の軸取り違えに実効的な回帰テストが無かった．**要判断の発見**: `max_depth=16` は収束値の **90.3%** しかエネルギーを拾えていない（間接照明のみの構成のため．ただし CoV への影響は +0.35% で形状指標の過去結論は無影響．設定変更は LED radiance 再校正を伴うため未実施，警告ログのみ実装）．**未解決**: VTK 破損で `sm-visualize` と可視化テスト 39 件が実行不能（依存関係の修復が必要）．設計判断: 対称性テストは負のコントロールが発火せず（立方体では平滑法線でも象限比 1.002 vs 1.003）検出力を実証できなかったため**常設テストに含めない**（検出できない検査は「検査済み」という誤った安心を与える）．積分球テストは 1.5 秒と軽量なので `slow` を付けず通常実行に含めた（`slow` 隔離が ② の全滅を見逃した原因のため）．記録 [TEST_13](06_TEST/TEST_13_物理モデル健全性の一括監査.md)．
- **sm-visualize の起動不能を解消 — 原因は VTK 破損ではなく Smart App Control (2026-08-30)**: TEST_13 で唯一未解決だった 3D 可視化の全滅（可視化テスト 39 件・`sm-visualize` 実行不能）を解決．**当初「VTK のインストール破損」と誤診していたが，真因は Windows Smart App Control（強制モード）が vtk 9.6.1 の DLL 209 個のうち 14 個をレピュテーション判定でブロックしていたこと**．署名の有無は判定基準ではなく（通った DLL も弾かれた DLL も未署名），`.pyd` は全て正常に存在し `uv.lock` も 5/17 から不変だったため，`uv sync` や同一バージョン再インストールでは直らない種類だった．誤診の原因は最初に観測したメッセージが `No module named vtkmodules.vtkCommonCore` という二次症状だったこと＝**ネイティブ拡張の ImportError は表示メッセージを額面どおり受け取らない**という教訓．対処は `vtk==9.4.2` への固定（より長く配布されレピュテーションが確立したバージョン．pyvista 0.48.0 の制約 `>=9.2.2,<9.7.0,!=9.4.1` 内）で，全 147 モジュールがブロック 0 件で読み込め可視化テスト 54 件が全通過．設計判断: Smart App Control の無効化は**一度オフにすると Windows 再インストールなしに戻せない**ため不採用（可視化ツール 1 本のために恒久的にマルウェア保護を手放すのは釣り合わない）．WSL2 への切り出しは環境二重管理の負債を負うため次善策として保留．**再発防止**: 破損が 8/17〜8/30 の約 2 週間気づかれなかった原因は可視化テストが全て `slow` 隔離されていたことで，TEST_13 検査 7（LLVM 初期化バグでレンダテストが長期間全滅）とまったく同じ構図．import 可否だけを見る軽量テスト（1 秒未満）を `slow` 無しで常設し，`pyproject.toml` の固定にも理由をコメントで残した（Dependabot / `/deps-update` による静かな再破損を防ぐため）．判断は `/consult`（advisor: Fable）に諮り，A（ダウングレード）→ B（WSL2）の順・C（SAC 無効化）不採用・import 監視テスト常設という助言に沿って実施．記録 [TEST_13 検査 8](06_TEST/TEST_13_物理モデル健全性の一括監査.md)．
- **TEST_14 材質パラメータ再スイープと残差の構造分解 — ρ を確定し「材質では直せない誤差」を分離 (2026-08-31)**: 面法線修正（TEST_12）前に実施した反射率・blend BSDF スイープはアーティファクトへのフィッティングだった可能性が高いため，ρ×ω×α の全 60 条件を修正後条件（spp=1024・d=16 据え置き）で引き直した（無人 6 時間枠・58 ジョブ 3.98h）．**結論は ρ ≈ 0.81 の純 diffuse**で，振幅系 4 指標（CoV/勾配/C-P/動径）の実機交差点が 0.80〜0.82 に揃い，残差のお椀成分のゼロ交差 0.81 とも独立に一致した．**ω・α はほぼ無効**（ρ 固定で CoV 変化幅 0.008〜0.011 に対し ρ 単独では 3 倍動く）で **blendbsdf は不要**＝調整パラメータが 1 つに減る．**最重要の発見**: 60 条件すべてで NCC が 0.81〜0.86 に張り付き（外れ値の準鏡面系列を除く），**形は材質パラメータでは原理的に動かない**ことを網羅探索で実証した．残差を `傾き + お椀` に分解すると **ρ が動かすのはお椀だけ・傾き（約 6%・方位 −140 deg）は不変**で，両者を除いた残りは約 1%＝ほぼ MC ノイズ．**方法論上の学び**: 残差 RMS は支配項である傾き（直せない誤差）を測ってしまうため ρ の選択基準に使ってはならない（RMS だけ見ると ρ=0.75 が最良に見える）．**原因の切り分け**: 既存単灯に同じ分解を当てると傾きは bottom 6.00%・left 7.17% に対し **right だけ 1.84%** ＝基板ごとに違う．カメラ由来（LSC 残差）なら 4 条件に同一の傾きが乗るはずなので，**傾きは bottom/left のモデル化誤差**と確定．実機単灯の振幅も右>左>下で 10% ばらつくのにシミュは 0.5% 以内でフラット（未モデル化）だが，一律ゲイン差では right だけ整合する事実を説明できないため位置・向き・配光の疑いが濃い．**未実施の前提**: ノイズフロア（seed 違い 2 本）を測っていないため上位 4 条件（score 0.079〜0.087）は横並びで「ρ=0.82 > 0.78」とは言えず，主張は「ρ ≈ 0.80〜0.82」まで．また d=16 据え置きにより打ち切り損失が ρ とともに増える（採用条件で 5.1%，ρ=0.90 で 20.6%）点は高 ρ 側との交絡として残る．成果物: `output/bsdf_grid_fix/`（60 条件 + summary.csv），図 `output/_slide_panels/bsdf_grid_{response,contact_sheet,rho_series,top_residual,top_shape}.png`，`scripts/sweep_bsdf_grid_fix.py`・`build_bsdf_grid_panel.py`・`build_bsdf_grid_visual.py`，記録 [TEST_14](06_TEST/TEST_14_材質パラメータ再スイープと残差の構造分解.md)．

- **TEST_15 バッフル導入と球半径スイープ — 接合の不自然さが「大きい球ほど悪い」の原因と判明 (2026-08-31)**: TEST_14 で「形は材質では動かない」と確定したため幾何レバーに移行．ユーザー指示で LED を評価板と反対側の**壁面に密着**させて評価板へ向け，直前のバッフルで直接光を遮る構成を新設した（バッフル径は板の全点から LED を隠す最小値の閉形式＋安全率．効果は指標ではなく**レイキャストで直接検証**＝板全面 41×41 点 × LED 33 点の 55,473 本が全条件 100% 遮蔽）．**結果 ①**: 同じ r=100 で構造 CoV 0.0579→**0.0312**（46% 減）・輪帯 min/max 0.797→0.861・上下の傾きも消失＝バッフルは有効．**結果 ②（想定と逆）**: 半径 88〜250mm の 10 条件で，輪帯 min/max は r=135 を境に悪化し r=250 は旧構成より悪い．内側（ピーク→d=0.5）は期待どおり単調改善（8.1%→3.5%）だが**外側（d=0.5→0.95）が同じ勢いで悪化**（6.4%→18.0%）して差し引きで負ける．**結果 ③**: ユーザー指摘「半径が大きいほど不自然に接合している」を数値化したところ，接続円を固定する設計では**r≥120 で球の頂点が評価板より下にもぐり**（＝ほぼ閉じた玉に細い首），接合の傾きが 0.25→2.75 と 11 倍に急峻化していた．**結果 ④**: キャビティ全体を半径に相似（center_z=-0.92r・cut_z=-0.40r）させ，ロフトを 5 次 Hermite にして接合部で**曲率まで球に一致**させると（傾き 0.609 一定・曲率比 厳密に 1.00・球の頂点は常に板より上），外側の落ち込みが半減し（r=250 で 18.0%→8.8%），**輪帯 min/max が半径とともに改善に転じた**（0.852→0.883→0.891）．r=250 の 0.891 は全条件で最良．内側は両設計でほぼ同一＝変更が予測どおり外側だけに効いた．**方法論上の学び**: 絶対輝度が半径で 1 桁変わる（1/r²）ため生の CoV は MC ノイズ支配（ノイズが構造の 2〜3 倍）で，そのまま読むと「大きい球ほど不均一」という誤った結論になる．**同心円（輪帯）プロファイルの方位平均**ならノイズが 1/√N に落ち，標準誤差が条件間の差の 1/20〜1/100 になるので公平に比較できる（ユーザー提案）．また輪帯プロファイルは ROI 平均ではなく**ピークで正規化**しないと「どれだけ落ちるか」が読み取れない．失敗パターン: ① 評価板のキャビティ側の面を z=0 と取り違え（実際は z=-4.5 の下面）→ バッフル径が過小 / ② バッフル円板の三角形ファンのエッジが XZ/YZ 平面と一致し，その平面内のレイが数値的にすり抜け（55,473 本中 4〜32 本）→ 円板を半セクタ回転して解消 / ③ `subprocess.run` が Windows 既定の cp932 で復号して読取スレッドが落ち，レンダ失敗時にエラー本文が読めない → `encoding="utf-8"` 明示．**未完**: `similar_g2` は 3 条件のみで残り 7 半径が未実行．ノイズフロア（seed 違い）も未測定．バッフル構成は MC ノイズが 3 倍になるので絶対量の議論には spp 増が必要．成果物: `output/sphere_radius_sweep/{board_baffle,board_baffle_similar_g2}/`，`scripts/sweep_sphere_radius.py`・`verify_baffle_occlusion.py`・`build_radial_comparison.py`・`build_radius_sweep_visual.py`・`build_radius_geometry_figure.py`・`show_scene_cutaway.py`，記録 [TEST_15](06_TEST/TEST_15_バッフル導入と球半径スイープ.md)．

- **TEST_15 続き — 板直下の「喉」が最大のレバーと判明し，出発点の 4.0 倍まで改善 (2026-08-31)**: `similar_g2`（接合の相似・G2 化）でも r=250 で外側の落ち込みが 8.75% 残っていた．断面を見たユーザーの指摘「くびれがないようにしたい」「評価板に対して垂直方向にまず伸ばしているが，水平方向に伸ばしたらくびれにならないのでは」を数値化すると，**板の直下に喉ができていた**（r=250 で板縁から 12.8mm 下でも半径が 48→49.2mm しか広がらない）．原因は実装形式そのもので，ロフトを「z を等間隔に進めながら ρ(z) を決める」形で書いていたためリムの傾きが dρ/dz=0（＝板に垂直）しか表現できなかった．**ロフトを (ρ, z) の 2 次元パラメトリック Hermite に変えてリム接線を半径方向（水平）に取れるようにした**（`similar_radial`）．**結果**: 外側の落ち込みが r=250 で 17.97%（fixed_cut）→ 8.75%（similar_g2）→ **2.27%**，構造 CoV **0.0145**・輪帯 min/max **0.944** で全条件の最良．旧 axial_wall r=100（0.0579 / 0.797）の **4.0 倍**で，内側・外側とも半径に対し単調改善し頭打ちが見えていない．**設計上の結論**: 効き目の序列は **喉 > 接合の相似・G2 化 > 球半径そのもの**．球半径は単独ではレバーにならず，喉と接合を直して初めて「大きいほど均一」という素直な効き方をする．ただし **r≲95 では喉なし設計が負ける**（小型機は fixed_cut）．**方法論の追加**: 輝度マップの正規化に画素単位の最大値を使うと firefly に張り付く（max/min が 2.9〜15.5 まで暴れる）ため，**20 分割の輪帯平均の最大値**を 1.0 とする（ユーザー提案）．分割数を評価パイプラインの既定と揃えると輝度マップの「最大輪帯」と輪帯プロファイルの「ピーク」が同じ輪帯を指し，図をまたいで数値が突き合わせられる．また `angular_ratio` は分母（動径分散）が潰れると跳ねるので単独で読んではならない（similar_radial r=250 で角度分散は 12.9→11.9 と微減しているのに比は 0.06→0.49）．**未実施**: リム張り出し量 `RADIAL_TANGENT_SCALE`（現在 0.6）の最適化，`similar_g2` の残り 7 半径，ノイズフロア．実機観点ではリム水平出しは壁が板の縁に薄い刃先で当たるため襟の作り方を別途詰める必要がある．成果物: `output/sphere_radius_sweep/board_baffle_similar_radial/`，`scripts/build_cavity_comparison.py`，図 `cavity_comparison.png`・`rim_tangent_comparison.png`，記録 [TEST_15](06_TEST/TEST_15_バッフル導入と球半径スイープ.md)．

- **TEST_16 立方体キャビティ導入と球との比較 — 同じ内面積なら立方体が球に勝つと判明 (2026-08-31〜09-01)**: TEST_15 の序列「喉 > 接合 > サイズ」から「ロフトも接合も喉も構造的に存在しない立方体はどうか」という仮説を立て，立方体キャビティ（内寸 L・天井 z=0・底面 z=-L・board_baffle 構成据え置き）を新設して L ∈ {120, 160, 200, 280, 360} の 5 条件（既定 9 グリッドの部分集合＝傾向を先に安く見るユーザー判断）をスイープ，球 `similar_radial` 10 条件と**内面積を横軸に**比較した．**結果 ①**: 「球のほうが理想積分球だから有利」は不成立．同一内面積（対数内挿）で立方体の構造 CoV は球の **0.62〜0.81 倍**（L=120 のみ互角），L=280（0.0109）で球の全条件最良（r=250 の 0.0145）を超え，L=360 は **0.0090 / 輪帯 min/max 0.964** で全条件を通じた最良．同内面積で深さも約 3 割浅く実用面でも有利＝**設計探索の主軸は立方体系へ**．**結果 ②**: ムラの「形」は立方体でも球と同一の同心円ドーム（L=120 で方位分散 5.96 vs 動径分散 118）．一次照射（バッフル裏→床の明るいリング）が軸対称で cos 重みの真下方向が支配し，多重拡散反射が壁の形を洗い流すため＝輪帯プロファイル比較の正当性が立方体でも成立．**結果 ③（四隅の痕跡の定量）**: ユーザーとの議論「差があるはずかを白黒つける検定」として，輪帯ごとの方位プロファイルの **cos 4φ 符号付き係数 a4**（正＝四隅が暗い．鏡映対称からゼロのはずの直交成分 b4 をノイズ対照に併用）を抽出．全条件 \|a4\| ≤ 0.26% で輪帯構造（4〜15%）の 1/30 以下，「四隅が暗い」符号の一貫した信号なし＝**角のフィレット等は不要**．唯一有意な L=120 の −0.26% は逆符号（辺中央方向が暗い＝壁余白 9mm の局所幾何の名残）で，小型化の下限を決めるのは隅でなく辺の余白と判明．**方法論の学び**: ① 楕円距離ビンの外側輪帯（d>0.707）は四隅方向にしか画素が無く，方位フーリエに掛けるとカバレッジの欠けが m=0 を m=4 に漏れ込ませ偽信号を作る→全セクタ被覆の輪帯のみ使用 / ② b4 対照で系統誤差床 ~0.1% を実測＝MC 伝播だけの σ は有意性を過大評価する / ③ `angular_ratio` の跳ね（L=360 で 0.71）は今回も分母潰れの見かけ（TEST_15 の再確認）．幾何検証（watertight・遮蔽 55,473 本 100%・法線逸脱 ≤0.06°）は球版の対策を織り込み済みで全て一発通過．**未実施**: 残り 4 条件（L=140/180/240/320）・フラット天井版（rim_z=-4.5）・直方体 L×L×D・ノイズフロア．成果物: `scripts/generate_cube_housing.py`・`sweep_cube_size.py`・`build_cube_sphere_comparison.py`・`analyze_fourfold_component.py`，`output/cube_size_sweep/board_baffle/`（summary.csv・`cube_vs_sphere.png`・`fourfold_component.png`），記録 [TEST_16](06_TEST/TEST_16_立方体キャビティ導入と球との比較.md)．

- **TEST_16 追試 — 残り 4 条件で全 9 条件が揃い単調性を確定・mitsuba を SAC 起因で 3.7.1 に固定 (2026-09-01)**: 残り L ∈ {140, 180, 240, 320} を実行しようとしたところ，**mitsuba 3.8.0 が import 不能**（Smart App Control が同梱 `IlmThread-mitsuba.dll` 1 個をレピュテーション判定でブロック．ファイルは 8/17 から無変更＝クラウド側の判定が一晩で反転．vtk 9.6.1＝TEST_13 検査 8 と同型）．`LoadLibraryExW` + `DONT_RESOLVE_DLL_REFERENCES` で WinError 4551（ポリシー）と 126（依存の巻き添え）を切り分けてブロック対象を 1 ファイルに特定し，一時 venv で 3.7.1 が全 DLL 通ることを確認して **`mitsuba==3.7.1` に固定**（ユーザー承認．`pyproject.toml` に理由コメント，ENV_04 に vtk と並べて注意書き）．uv 生成の `pytest.exe` ランチャも同時にブロックされたため `python -m pytest` で回避．**バージョン混在の妥当性検証**: 全 1043 テスト通過（絶対放射量の解析解検証込み）＋ L=120 アンカー再レンダで 3.8.0 と構造 CoV 一致（0.0379）・輪帯プロファイル最大差 1.17σ＝統計的に区別不能．**結果**: 全 9 条件で構造 CoV（0.0379→0.0090）・輪帯 min/max（0.858→0.964）・C/P・勾配のすべてが **L に対し厳密に単調改善**，9 本の輪帯プロファイルは交差なし．球との構造 CoV 比は 1.05→0.62 と単調に開き，交差点は内面積 10 万 mm² 前後．m=4 は L=140 が −0.212%（L=120 と同じ逆符号＝辺余白の名残）で L=120→140→160 と単調減衰し「小型化の下限は隅でなく辺の余白」の解釈を補強．TEST_16 の限界から「5 条件のみ」が消え「レンダラ混在（検証済み）」に置き換わった．成果物: `output/cube_size_sweep/board_baffle/`（全 9 条件）・`_anchor_check_mitsuba371/L120/`，`pyproject.toml`（mitsuba 固定），記録 [TEST_16](06_TEST/TEST_16_立方体キャビティ導入と球との比較.md)・ENV_04．

- **TEST_17 オフ軸 LED 配置の影響とサイズ依存 — 頑健性は球が勝ち軸上の優劣と逆転 (2026-09-01)**: ユーザー発案「光源が軸からずれた場合の影響と，大きいほど影響が薄まるかの検証」．LED を**深さ方向軸の中点の高さ・+X 側の壁面**に置き板中心へ向ける構成（球 similar_radial 5 半径 + 立方体 5 サイズ・材質/レンダ据え置き）を新設した．円板は壁に対し約 41〜44° 傾くため縁が壁を貫かない分だけ浮かせ，バッフルは軸対称でないので**板 41×41 × LED 円板の全直線がバッフル平面を横切る位置から数値サイジング**（+遮蔽レイキャスト 10 条件 100%．`verify_baffle_occlusion` の LED サンプルを円板の傾きに追従するよう一般化）．立方体 L=120 のみバッフルが壁に 2.35mm 食い込む（板の手前縁への視線が壁とほぼ平行なため円板が壁まで届く必要がある＝実物積分球の「壁付きバッフル板」と同じ解釈で殻厚以内を許容）．**結果 ①（仮説成立）**: 非対称（m=1 符号付き a1・重心オフセット）はサイズとともに減衰し最大サイズで最小の約 4 割（球 -4.0→-1.6% / 立方体 -7.2→-2.3%．ノイズ対照 b1 ≤0.3% の 10〜40 倍で確実に実構造）．ただしゼロにはならない．**結果 ②**: a1 は全条件で負＝**明るいのは LED の反対側**．バッフル遮蔽下では一次照射キャップ（TEST_11）が反対側の壁にでき，板がそれを非対称に見込むため．**結果 ③（軸上と逆転）**: オフ軸頑健性は**球 > 立方体**．位置ずれの Δ構造CoV は球 ±0.006 以内＝実質ゼロ，立方体 +0.010〜+0.033（L=160 で軸上の 2.5 倍）．球の「壁上ランバート光源→球面直接照度が一様」という古典的性質の名残．**設計上の含意**: 「立方体 + 軸上配置」か「球 + 配置自由度」の二択構造．**未解決**: 非対称ピークが最小サイズでなく 2 番目（球 r=100 / 立方体 L=160）に来る非単調性の原因，ずれ量の感度曲線（軸上→壁面の中間位置）．成果物: `scripts/sweep_offaxis_led.py`・`build_offaxis_comparison.py`，`output/offaxis_led_sweep/`（10 条件 + summary.csv + `offaxis_comparison.png`），記録 [TEST_17](06_TEST/TEST_17_オフ軸LED配置の影響とサイズ依存.md)．

- **発表スライド素材の作成と TEST_16 の 10 条件化 (2026-09-01)**: TEST_15〜16 の発表準備として，スライド用のクリーン図一式を `output/_slide_panels/` に生成するスクリプトを追加した（`build_slide_test15_geometry.py`＝構成断面（注釈付き/文字なし・透過）・半径入れ子断面（直径 φ 表記）・接合比較，`build_slide_test15_results.py`＝輪帯ピーク正規化の輝度マップ 5/10 条件版・輪帯プロファイル（英語軸ラベル），`build_slide_test16_geometry.py`＝立方体版の構成断面・サイズ入れ子）．あわせてユーザー要望「球と同数の 10 条件でまとまりを良くする」を受け，**立方体スイープに L=220 を追加**（内面積 291,000mm²＝球 φ270 と φ340 の中間．watertight・遮蔽 55,473 本 100% を事前検証．構造 CoV 0.0147・輪帯 min/max 0.944・対球比 0.73・m=4 は −0.004%＝すべて既存カーブに単調に整合）．`sweep_cube_size.py` の既定グリッドを 10 条件に更新し，TEST_16・TEST_02 の表と記述を 10 条件に改訂．表記の知見: 直径は図面では「φ176」（単位なしが JIS 流），スライド・文書では「φ176 mm」も一般的＝どちらでも可で一貫性が重要．

- **研究室サーバ（Newton）で計算する仕組みを整備 — GPU で手元の 37〜72 倍 (2026-09-13)**: 手元 Windows の CPU レンダ（1 条件 5〜10 分）を研究室の GPU サーバで回せるようにした．初回セットアップ（SSH 鍵認証 → uv でユーザー領域に Python 3.12 → 転送 → `uv sync`）を ENV_02「研究室サーバ編」に，日常の操作（送信・tmux でのジョブ起動・状態確認・ログ・結果の持ち帰り）を `sm-remote` CLI として実装し ENV_04 にまとめた．使えるのは Newton のみ（Einstein はホームディレクトリが無く鍵登録不可，Archimedes は鍵未登録）．**結果**: 代表 2 シーン（spp=1024）で cuda_ad_rgb は手元 llvm の 37〜72 倍（立方体 L240 285 s→7 s，球 r135 558 s→8 s）．Newton の llvm と平均の相対差 1e-5・CoV 差 5e-5 以下で一致したため，サーバでは cuda を既定にした．**設計判断**: ① GitHub 認証をサーバに置かない（ユーザー判断: 計算して結果を受け取るだけ）→ 手元の作業ツリーをそのまま送るので未コミットの実験設定も回せる / ② Windows に rsync が無いため Python の tarfile で送受信（PowerShell と Git Bash で同じ挙動）/ ③ 同じ YAML のまま手元は llvm・サーバは cuda で回せるよう variant を環境変数で上書きし，共用サーバの 64 スレッドを占有しないよう Dr.Jit のスレッド数上限を追加（llvm で loadavg 33→87 を実測）．**失敗パターン・発見**: ① スイープ生成スクリプトが `_tmp` YAML に Windows の絶対パスを書いておりサーバで読めない → YAML からの相対パスに変更 / ② `llvm_init` が Ubuntu の `libLLVM-15.so` 形式を探せず誤警告 → 探索対象に追加 / ③ Phase 2 のテストで pull 展開のパストラバーサル対策の穴（`..`・バックスラッシュ・ハードリンク経由で `src/` を上書きできる）が見つかり，`/consult`（advisor: Fable）の判断で名前の構造検査とリンクの一律拒否に強化 / ④ 作業中に Smart App Control が評価モードからオンに切り替わり（処理中の通知のボタン操作が契機とみられる），mitsuba 3.7.1 の `mitsuba_ext` まで import 不能になった．ファイル単位の例外が無く再インストールでも直らないため，ユーザー判断で SAC をオフにした（08-30 の「SAC 無効化は不採用」を変更．経緯は ENV_04）．**解決（同日）**: 球 r135 だけ手元の過去結果と CoV が 0.0864 vs 0.0835 と食い違った件は，TEST_15 の similar_radial 10 条件を Newton で回し直して切り分けた．形状（頂点 21 万個が完全一致．STL のハッシュ差はヘッダだけ）と YAML（メッシュパス以外一致）は同じで，差は全条件で同じ向き（平均 +0.1%・画素 CoV +2〜4%）．TEST_16 の手元アンカー（立方体 L=120 を同じ Windows で 3.8.0 と 3.7.1）でも平均 +0.16%・CoV +1.8% と同じずれ方をするため，**原因は mitsuba 3.8.0（8/31 の記録）→ 3.7.1（9/1 固定）のバージョン差**．形の指標（輪帯 min/max・C/P・勾配）は ±0.4% 以内で一致し，TEST_15 の結論は不変．過去レンダと画素 CoV を突き合わせるときは mitsuba のバージョンを揃えること．
  - **学外からの接続**: Tailscale に登録済みの研究室 PC（サーバとは別）に OpenSSH Server を入れて Tailscale からのみ受け付け，SSH の踏み台（ProxyJump）にして Newton に入れるようにした（Newton 側は無変更．大学 VPN やサブネットルーターより影響範囲が自分の PC に閉じる）．失敗パターン: 研究室 PC は管理者アカウントのため鍵を `C:\ProgramData\ssh\administrators_authorized_keys` に置く必要があるうえ，両 PC の管理者 PowerShell のプロンプトが同一で鍵を手元 PC に登録してしまった → `hostname` で確かめてから実行する（手順は ENV_02「学外から接続する」）．
  - **レンダは画素単位では再現しない（GPU・CPU とも）**: 最終確認で基準シーンを同条件で繰り返すと，約 97% の画素が MC ノイズ程度に異なった（平均の差 3〜7e-4・CoV の差 1e-5）．切り分け実験: ① 同じシーンオブジェクトを 2 回レンダ → 丸め誤差だけ（並列加算の順序．平均は一致）/ ② シーンを読み込み直す → ノイズ程度の差 / ③ コーネルボックスは読み込み直しても丸め誤差だけ．＝このシーン固有で，読み込み時に並列で作られる加速構造かサンプリング用の表の丸め差が，最大 16 回の反射で経路の分岐として増幅されると推定（どちらかは未切り分け）．過去の「seed 固定で決定論的」という前提は厳密には成り立たないが，集計指標の比較には影響しない．裏返せば，同じ条件の繰り返しで未実施の**ノイズフロア**を測れる．
  - **サーバでのスイープ実測**: 球 10 条件のスイープ全体が 5 分 49 秒（手元 2 時間 13 分）．レンダ＋評価だけなら 1 条件約 10 秒で 79 倍．GPU 1 枚（`--gpu 0`）で CPU は平均 156%・最大 342%（64 スレッド中）と共用サーバへの負荷は小さく，GPU 使用率の平均は 3%＝時間の大半は CPU 側の形状生成・シーン読み込み・評価（GPU を増やしても速くならない）．研究室 PC 経由の pull は 31.8 MB を 16 秒．

- **スイープの高速化 — レンダ/評価の関数化・プロセス内実行・cuda 遮蔽検証・2 並列 (2026-09-14)**: ユーザー指示「効率化を先に」を受け，`scripts/profile_sweep_step.py` で 1 条件の内訳を実測してから手を入れた．**計測結果**: GPU のレンダ本体（spp=1024・512²）が 4.4〜5.2 秒で床．その上に `uv run sm-render`/`sm-evaluate` の起動・import・YAML・PLY 書き出しで約 2.5 秒，図の描画で約 2 秒，さらに遮蔽検証を YAML の llvm で回していたため球で約 25 秒（頂点 21 万個のメッシュを CPU で読み直す）が乗り，球 1 条件 40 秒・立方体 13 秒だった．**対策**: ① `sm-evaluate`/`sm-render` の本体を `evaluation/pipeline.py:evaluate_image`・`render/pipeline.py:render_yaml` に関数化し CLI は引数パースと例外変換だけに（CLI 挙動は不変）/ ② `--no-figures`（`save_figures=False`）/ ③ `runner.ensure_variant` を切り出し，遮蔽検証の前に cuda を確定（25 秒 → 0.5 秒）/ ④ スイープはサブプロセスをやめプロセス内で呼ぶ / ⑤ `--workers N`（spawn のプロセスプール）．**実測**: 立方体 13 → 5.5 秒，球 40 → 約 6 秒．`--workers` は GPU 律速のため 1→5.5・2→5.0・3→4.5〜5.8 秒でほぼ変わらず，**2 を推奨**（CPU 側処理を隠す分だけ）．残り 75 条件が 8 分で終わった．**発見**: 同一 seed の再レンダは集計指標が 4 桁まで一致し（画素はノイズ程度に変わるが集計で消える）ノイズフロアにならない → `RenderConfig.seed` を追加し `mi.render` に渡す（再現性条件は rep ごとに seed を変えた YAML）．`/implement` の 4 フェーズ（coder → tester 101 件追加 → refactorer → docs）を，ユーザー就寝中の指示に基づき Phase 1 の動作確認をサーバ実走で代行して完走．GPU は 0 番のみ使用（ユーザー指示）．

- **TEST_18 照明配置依存性の球と立方体の比較 — 配置依存は球が立方体の 1/2〜1/3 (2026-09-14)**: ユーザーの仮説「積分球が使われる理由は照明配置への依存が小さいから」を，同内面積 4 ペア（球 r=100/135/170/250 ↔ 立方体 L=141/187/234/340）で **LED の位置（キャビティ中心から見た極角 θ=0〜120° を 13 段階）・向き（板向き＋バッフル／壁法線向き＋バッフル／真下向き）・個数（θ=90° の輪に N=1〜4）・再現性（seed 違い）** の 198 条件で検証した（Newton cuda・1 条件 5〜6 秒）．**結果 ①**: θ 全域での構造 CoV の幅は球 0.015〜0.023・立方体 0.025〜0.071（1.2〜3.1 倍），max\|a1\| は 3〜4% vs 4.5〜11%．立方体は θ とともに単調に悪化し板の直下で軸上の 3.4〜5 倍．**球は θ≈30° が軸上より均一**（r=170: 0.0193 → 0.0057．軸上のリング構造が崩れる）で「どこに置いてもそこそこ」．立方体の優位は軸上の 1 点だけ．**結果 ②**: 真下向き（板が背後＝バッフル無し）は板向き＋バッフルと同等で 5〜30% 明るい．壁法線向き（キャビティ中心向き）は最悪（2〜5 倍）．**結果 ③**: 対向 2 灯で m=1 は ≤0.3% に消え構造 CoV は 0.005〜0.010＝単灯軸上より均一で形状差が消える．立方体は N=3 で崩れる（3 回対称が 4 回対称の壁と噛み合わない）．**ノイズフロア**: 構造 CoV ±0.0007・a1 ±0.08%．設計への含意は「単灯なら球，多灯にできるなら側壁の対向 2〜4 灯・真下向き・バッフル無しで立方体でも球と同等」．**方法論**: 極角 θ を両形状共通のパラメータにし，立方体の稜（45°）は外す．板の近くのバッフルは外殻の貫通を許容し食い込み量を記録（壁法線向きは半径がキャビティ寸法の 0.6 を超えたら無効）．解析は TEST_16/17 の方位フーリエ（m=1〜4）＋構造 CoV＋重心．**追加実験（同日夜）**: ① 方位角: 立方体は面の中央が最良で稜へ寄せるほど構造 CoV が 1.3〜1.75 倍に悪化（球は方位に依らない）/ ② 真下向き多灯（バッフル無し）: 2 灯以上で非対称は消え単灯軸上より均一だが，板向き＋バッフルの多灯には 1.5〜2.5 倍劣り N を増やしても頭打ち（一次照射が壁の下半分に集中し動径構造が残る）．全 255 条件（TEST_18 結果 5・6）．