diff --git a/CLAUDE.md b/CLAUDE.md
index d7bef33..9180b55 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -21,7 +21,8 @@
 次のアクション（キャリブ再開時）: 残差に **LSC（ISP レンズシェーディング）順方向モデル**を当てる（物理動機づけ低自由度形、overfitting 回避・取得パラメータ数明記）．
 
 補足: **速度最適化ワーク開始**（キャリブ作業を一旦中断）．[TEST_04 シミュレーション速度最適化履歴](docs/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 順を制御（`sensors.py`/`lights.py` のモジュールレベル `import mitsuba` 前に検出を確実に通す）．`docs/02_ENV/ENV_02_環境構築手順.md` に LLVM インストール手順・DRJIT_LIBLLVM_PATH 説明・動作確認コマンドを追記．**速度は不変**（コード経路同等）．新規テスト 51 件追加で **606 件全通過**（仕様 A1〜E1 すべてカバー）．数値同等性: SHA256 は MC 内部シードで異なるが平均相対誤差 7.23e-05（5σ 閾値 0.4508 に対し差 0.011）で統計同等性パス．これで「環境変数が消えて沈黙クラッシュ」する事故が再発しない土台が整備された．次は Speed-2 (path bake wavefront 化) へ．
+補足: **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 順を制御（`sensors.py`/`lights.py` のモジュールレベル `import mitsuba` 前に検出を確実に通す）．`docs/02_ENV/ENV_02_環境構築手順.md` に LLVM インストール手順・DRJIT_LIBLLVM_PATH 説明・動作確認コマンドを追記．**速度は不変**（コード経路同等）．新規テスト 51 件追加で **606 件全通過**（仕様 A1〜E1 すべてカバー）．数値同等性: SHA256 は MC 内部シードで異なるが平均相対誤差 7.23e-05（5σ 閾値 0.4508 に対し差 0.011）で統計同等性パス．これで「環境変数が消えて沈黙クラッシュ」する事故が再発しない土台が整備された．
+補足: **速度最適化ワーク一旦中断**（Speed-2 path bake wavefront 化は未着手）．**実時間の改善は実質ゼロ**（B1=508s／B2=56s で不変）．副次的成果として環境破綻問題の発見と恒久対処，JIT 診断ログ，ベンチ条件のドキュメント，テスト 51 件追加が得られた．中断理由: B2 は現状ボトルネックではなく，B1 は CPU 完結・精度据置の制約下で取れる打ち手が限定的．本筋のキャリブ作業（LSC モデル化）に戻ることがプロジェクト目的により近い．再開条件: path bake samples を増やすユースケース発生／NVIDIA GPU 利用可／クラウド計算活用判断／キャリブ反復回数増加でバッチ時間が研究進度を圧迫した場合．詳細・Speed-2 テンプレ保持は [TEST_04 中断記録](docs/06_TEST/TEST_04_シミュレーション速度最適化履歴.md#中断記録-suspension-note--2026-05-28) 参照．次のアクション: キャリブ作業（LSC モデル化）に戻る．
 
 実装済みモジュール:
 - `src/sm_tias_lightsim/uniformity.py` — Rec.709 輝度変換 + CoV/std/max-min（MiniTias-Evaluation コピー）
diff --git "a/docs/06_TEST/TEST_04_\343\202\267\343\203\237\343\203\245\343\203\254\343\203\274\343\202\267\343\203\247\343\203\263\351\200\237\345\272\246\346\234\200\351\201\251\345\214\226\345\261\245\346\255\264.md" "b/docs/06_TEST/TEST_04_\343\202\267\343\203\237\343\203\245\343\203\254\343\203\274\343\202\267\343\203\247\343\203\263\351\200\237\345\272\246\346\234\200\351\201\251\345\214\226\345\261\245\346\255\264.md"
index 417f08d..f7560b0 100644
--- "a/docs/06_TEST/TEST_04_\343\202\267\343\203\237\343\203\245\343\203\254\343\203\274\343\202\267\343\203\247\343\203\263\351\200\237\345\272\246\346\234\200\351\201\251\345\214\226\345\261\245\346\255\264.md"
+++ "b/docs/06_TEST/TEST_04_\343\202\267\343\203\237\343\203\245\343\203\254\343\203\274\343\202\267\343\203\247\343\203\263\351\200\237\345\272\246\346\234\200\351\201\251\345\214\226\345\261\245\346\255\264.md"
@@ -292,3 +292,56 @@
 - 数値同等性が破れた最適化は不採用とする．
 
 それ以降の最適化（denoiser・サンプラ・クラウド GPU 等）は Speed-3 以降で別途検討する．
+
+## 中断記録 (Suspension Note) — 2026-05-28
+
+Speed-1 完了時点で **速度改善ワークを一旦中断** することにした．
+
+### 中断時点の正直な評価
+
+ユーザー当初目的「シミュレーション速度を上げる」に対し，**実時間の改善は実質ゼロ**：
+
+| ベンチ | Speed-0（ベースライン） | Speed-1 後 | 速度比 |
+| --- | --- | --- | --- |
+| B1: sm-render | 507.86 s | ≈ 508 s（不変） | **1.0×** |
+| B2: path bake | 55.97 s | ≈ 56 s（不変） | **1.0×** |
+
+### やったこと・やらなかったこと
+
+| 項目 | 状態 | 備考 |
+| --- | --- | --- |
+| Speed-0 ベースライン計測 | ✓ 完了 | 副次的に `DRJIT_LIBLLVM_PATH` 消失問題を発見・復旧 |
+| Speed-1 LLVM 自動検出 + 診断ログ | ✓ 完了 | 再発防止と診断容易化．**速度自体は不変が想定** |
+| Speed-2 path bake wavefront 化 | ✗ **未着手** | 本命だったが中断 |
+| Speed-3 以降（denoiser・サンプラ等） | ✗ 未検討 | — |
+
+### 中断の理由
+
+- 当面の速度改善の本命は Speed-2 (path bake wavefront 化) のみだったが，**それを実施しても直接の研究目的（実機との形状一致＝ LSC モデル化）には寄与しない**．現状の path bake (samples=16) 約 56 秒は実用上ボトルネックではなく，本格的に速度問題になるのは samples を増やして per-face 精細化する場合のみ．
+- B1 (sm-render) はユーザー方針「GPU なし・CPU 完結・精度据置」の制約下では取れる打ち手が限定的．現状の **8.5 分/回は Mitsuba CPU 実装としては妥当**であり，「許容して進む」判断．
+- 本筋のキャリブ作業（LSC モデル化）に戻ることがプロジェクトの目的により近い．
+
+### 副次的に得られた成果（速度ではない）
+
+| 成果 | 価値 | 影響範囲 |
+| --- | --- | --- |
+| `DRJIT_LIBLLVM_PATH` 消失でサイレントクラッシュしていた問題の発見と恒久対処 | 高 | 環境破綻の再発防止（自動検出ロジック + User scope 永続化） |
+| JIT 経路の診断ログ機構 | 中 | 「同じシーンなのに数値がずれる」事態の即時検知 |
+| ベンチマーク条件と TEST_04 のドキュメント | 中 | 再開時に「3 回中央値・warm-up 捨て・SHA256/MC 統計同等性」の手順がそのまま使える |
+| テスト 51 件追加（606 件全通過） | 中 | runtime 層の安全網 |
+
+### 再開条件 (Re-entry Criteria)
+
+以下のいずれかに該当した時は速度改善ワークを再開する：
+
+1. **path bake samples を増やしたいユースケースが発生**（例: 別タスクでメッシュ境界の継ぎ目を消すため samples=256 以上で焼く必要がある）→ Speed-2 を実施．効果は samples に比例して大きくなる．
+2. **NVIDIA GPU が利用可能になった**（マシン換装または別環境への移行）→ CUDA variant への切り替えを Speed-N として実施．`runtime/llvm_init.py` と同じ思想で「未検出時の自動 fallback」を入れる．
+3. **クラウド計算リソースを活用する判断**（複数キャリブパラメータ並列スイープ等）→ Speed-N としてバッチ実行基盤を別途設計．Speed-2 とは独立．
+4. **キャリブ反復回数が増えてバッチ実行時間が研究進度のボトルネックになった場合** → 改めて B1 / B2 の壁時計を再計測し，本ドキュメントの再開判断に使う．
+
+### 次のアクション
+
+- 本ワーク：feature/perf-optimization の Speed-0 / Speed-1 成果を main にマージしてクローズ．
+- プロジェクト本筋：キャリブ作業（**LSC モデル化** [TEST_03 / SPEC_03 参照]）に戻る．
+
+Speed-2 のテンプレートは下記に**未実施のまま保持**しており，上記再開条件に該当した時にそのまま `/implement` で着手可能．