diff --git "a/docs/02_ENV/ENV_02_\347\222\260\345\242\203\346\247\213\347\257\211\346\211\213\351\240\206.md" "b/docs/02_ENV/ENV_02_\347\222\260\345\242\203\346\247\213\347\257\211\346\211\213\351\240\206.md"
index aeb31f7..6195b67 100644
--- "a/docs/02_ENV/ENV_02_\347\222\260\345\242\203\346\247\213\347\257\211\346\211\213\351\240\206.md"
+++ "b/docs/02_ENV/ENV_02_\347\222\260\345\242\203\346\247\213\347\257\211\346\211\213\351\240\206.md"
@@ -332,6 +332,7 @@
 ```
 
 - 研究室にいるときは従来どおり `Newton` を使う（踏み台を経由しない分速い）
+- 手で `ssh Newton-via-lab 'cat ...' > ファイル` のように出力を受け取るとき，応答が返らず止まることがあった（`hostname` のような短いコマンドは通る．原因は未確認）．`ssh -n`（標準入力を閉じる）を付けると通った．`sm-remote` は標準入力を閉じて ssh を呼ぶので影響しない
 - Tailscale が直接つながらず中継サーバ（DERP）経由になっていると転送が遅い（`tailscale ping desktop-1qloo91` で `via DERP` と出る）．学外からの push は `--only src` のように変えた部分だけにする
 - 失敗パターン: 研究室 PC と手元 PC の管理者 PowerShell はプロンプトが同じ（`PS C:\Windows\system32>`）ため，鍵の登録を手元 PC で実行してしまい，研究室 PC で `Permission denied (publickey,...)` になった．sshd のログ（`Get-WinEvent -LogName OpenSSH/Operational`）には理由が出ず `Connection reset ... [preauth]` だけだった
 - 研究室 PC で SSH サーバを動かしてよいかは研究室のルールに照らして確認する（上の設定で受け付けるのは Tailscale の中＝自分のアカウントの機器からだけ）
diff --git "a/docs/02_ENV/ENV_04_\351\226\213\347\231\272\343\202\263\343\203\236\343\203\263\343\203\211.md" "b/docs/02_ENV/ENV_04_\351\226\213\347\231\272\343\202\263\343\203\236\343\203\263\343\203\211.md"
index 5067710..e3ba27a 100644
--- "a/docs/02_ENV/ENV_04_\351\226\213\347\231\272\343\202\263\343\203\236\343\203\263\343\203\211.md"
+++ "b/docs/02_ENV/ENV_04_\351\226\213\347\231\272\343\202\263\343\203\236\343\203\263\343\203\211.md"
@@ -105,6 +105,7 @@
 - `run` は既定で `SM_RENDER_VARIANT=cuda_ad_rgb` を渡す（sm-render が YAML の variant より優先して使う．GPU は手元の CPU の 37〜72 倍速く，Newton の `llvm_ad_rgb` と結果が一致することを 2026-09-13 に確認済み）．YAML の variant のまま回すときは `--yaml-variant`
 - レンダ結果は，同じコード・同じ YAML・同じ seed でも**実行ごとに画素単位で変わる**（GPU・CPU とも．2026-09-13 に Newton で確認）．同じシーンオブジェクトを 2 回レンダした差は丸め誤差（並列加算の順序）だけで平均も一致するが，シーンを読み込み直すと約 97% の画素が MC ノイズ程度に変わる（平均の差 3〜7e-4）．コーネルボックスでは読み込み直しても丸め誤差だけなので，このシーン固有の現象．読み込み時に並列で作られる加速構造かサンプリング用の表の丸め差が，最大 16 回の反射で経路の分岐として増幅されていると推定している（どちらかは未切り分け）．sm-render は毎回シーンを読み込むので，1 回ごとに別のノイズ実現と考える．集計指標の条件比較には問題ないが，画素単位で過去のレンダと突き合わせる用途には向かない
 - CPU（`llvm_*` / `scalar_*`）で回すときは `--threads N` で Dr.Jit のスレッド数に上限を付ける（共用サーバの 64 スレッドを占有しないため）
+- GPU で回すときの CPU 負荷は小さい（球 10 条件のスイープで CPU は平均 156%・最大 342%＝64 スレッド中 1.5〜3.4 スレッド分．2026-09-13 実測）．スイープ全体の時間の大半は CPU 側の形状生成・シーン読み込み・評価で GPU 使用率は平均 3% なので，1 本のスイープに GPU は 1 枚（`--gpu`）で足りる
 - GPU は `status` で空きを見てから `--gpu` で指定する（未指定だと CUDA は 0 番を使う）．その他の環境変数は `--env KEY=VALUE` で渡せる
 - サーバで pytest を回すときは `--yaml-variant` を付ける（variant の上書きをテストに持ち込まないため）: `uv run sm-remote run --name pytest-all --yaml-variant -- python -m pytest -m ""`
 - 各サブコマンドの詳細は `uv run sm-remote <サブコマンド> --help`．接続先は `--host` / `--remote-dir` で変えられる
diff --git "a/docs/06_TEST/TEST_15_\343\203\220\343\203\203\343\203\225\343\203\253\345\260\216\345\205\245\343\201\250\347\220\203\345\215\212\345\276\204\343\202\271\343\202\244\343\203\274\343\203\227.md" "b/docs/06_TEST/TEST_15_\343\203\220\343\203\203\343\203\225\343\203\253\345\260\216\345\205\245\343\201\250\347\220\203\345\215\212\345\276\204\343\202\271\343\202\244\343\203\274\343\203\227.md"
index 95f7c49..ff4ca26 100644
--- "a/docs/06_TEST/TEST_15_\343\203\220\343\203\203\343\203\225\343\203\253\345\260\216\345\205\245\343\201\250\347\220\203\345\215\212\345\276\204\343\202\271\343\202\244\343\203\274\343\203\227.md"
+++ "b/docs/06_TEST/TEST_15_\343\203\220\343\203\203\343\203\225\343\203\253\345\260\216\345\205\245\343\201\250\347\220\203\345\215\212\345\276\204\343\202\271\343\202\244\343\203\274\343\203\227.md"
@@ -330,6 +330,10 @@
 uv run python scripts/sweep_sphere_radius.py --variant board_baffle --cavity similar_g2 --radii 100 170 250
 uv run python scripts/sweep_sphere_radius.py --variant board_baffle --cavity similar_radial
 
+# 研究室サーバ（GPU）で回す場合（手元から．結果は --dest で別の場所に持ち帰ると本文の出力を上書きしない）
+uv run sm-remote run --name sphere-radial --gpu 0 -- python scripts/sweep_sphere_radius.py --cavity similar_radial
+uv run sm-remote pull sphere_radius_sweep/board_baffle_similar_radial --dest output/_newton_recheck
+
 # 可視化（--cavity ごとに出力先が分かれる）
 uv run python scripts/build_radius_sweep_visual.py --cavity similar_radial
 uv run python scripts/build_radial_comparison.py --cavity similar_radial
@@ -341,6 +345,24 @@
 `board_baffle_similar_radial/`＝10 条件）．設計比較図は `cavity_comparison.png`，
 接合の断面 before-after は `cavity_design_comparison.png` と `rim_tangent_comparison.png`．
 
+## 再検証 — 研究室サーバでの回し直し (Re-verification on Lab Server)
+
+2026-09-13，`similar_radial` の 10 条件を現在のコード（mitsuba 3.7.1・`cuda_ad_rgb`）で研究室サーバ（Newton）で回し直し，本文の値（2026-08-31．mitsuba 3.8.0・手元の `llvm_ad_rgb`）と突き合わせた．
+
+| 指標 | 本文の値との差（10 条件の範囲） |
+| --- | --- |
+| 輪帯 min/max | −0.29〜+0.18% |
+| 中心/周辺比 | −0.02〜+0.03% |
+| 勾配 | −0.38〜+0.28% |
+| ROI 平均 | +0.07〜+0.12%（全条件で同じ向き） |
+| 画素 CoV | +2.0〜+4.2%（全条件で同じ向き） |
+
+- **本文の結論（形の指標による比較）は変わらない**．形の指標は ±0.4% 以内で一致する
+- 平均と画素 CoV の系統的なずれは **mitsuba のバージョン差**（本文は 3.8.0，現在は 3.7.1 に固定）による．形状（頂点が完全一致）と YAML（メッシュパス以外一致）は同じで，TEST_16 の手元アンカー（立方体 L=120 を同じ Windows で 3.8.0 と 3.7.1）でも平均 +0.16%・CoV +1.8% と同じ向きにずれる．画素 CoV はもともと MC ノイズ支配で結論に使っていない（結果 2）
+- 過去のレンダと画素 CoV・絶対輝度を突き合わせるときは mitsuba のバージョンを揃えること
+- 所要: 10 条件のスイープ全体で 5 分 49 秒（本文の手元実行は 2 時間 13 分）
+- 回し直しの出力は手元の `output/_newton_recheck/` に持ち帰った（本文の `output/sphere_radius_sweep/` は上書きしていない）
+
 ## 参照 (References)
 
 - [TEST_11_球体筐体実験](TEST_11_球体筐体実験.md): 球ロフト筐体の起点と一次照射キャップの特定
diff --git a/docs/PROGRESS.md b/docs/PROGRESS.md
index 9e5753a..243bb0f 100644
--- a/docs/PROGRESS.md
+++ b/docs/PROGRESS.md
@@ -94,6 +94,7 @@
 
 - **発表スライド素材の作成と 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 と食い違う（Newton の llvm と cuda は一致しているので GPU 起因ではない．08-31 のロフト形状コミット前の古いメッシュでレンダした可能性があるが未確定）．
+- **研究室サーバ（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 秒．