diff --git a/CLAUDE.md b/CLAUDE.md
index 4ebf450..b046917 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -4,7 +4,7 @@
 
 ## 開発進捗
 
-最新: 初回の `/deps-update` で Dependabot PR 5 件を検証し，全件がビルド不能（OpenCvSharp の semver 違反な破壊的変更／packages.config 更新の生成不具合）と判明．追従作業を Issue #29〜#32 として起票し，うち #32（ENV_04 の `vswhere` 修正）を実施
+最新: Dependabot 追従作業のうち #29（OpenCvSharp を専用グループに分離）・#30（NUnit テストを制約モデルへ移行）・#32（ENV_04 の `vswhere` 修正）をマージ．検証過程で見つけた「クリーンビルドでテスト 41 件が落ちる」既存不具合も #39 で修正済み．#31（ArUco API 移行）は実機確認待ちの PR #36 として保留中
 ※ 本欄は**最新ステップ 1 行のみ上書き更新**．詳細な進捗履歴（動機・設計判断・失敗パターン）は [docs/PROGRESS.md](docs/PROGRESS.md) に追記する．運用ルールは `.claude/rules/progress-log.md` を参照（該当ファイル編集時に自動ロードされる）．
 
 ## 必須ルール（コード実装時）
diff --git a/docs/PROGRESS.md b/docs/PROGRESS.md
index c49f1aa..f31f2ae 100644
--- a/docs/PROGRESS.md
+++ b/docs/PROGRESS.md
@@ -128,3 +128,9 @@
   - 設計判断（NUnit 4 追従の順序）: `ClassicAssert` への置換は NUnit 3.14 でコンパイルできず「上げてから直す」と main が壊れる期間ができる．一方，制約モデル（`Assert.That` ＋ `Is.*` / `Does.*`）は両バージョンで動くため，先に移行しておけば破壊期間ゼロで追従できる（#30）．ArUco は逆に新旧両対応の中間形が作れず，パッケージ更新とコード移行を同一 PR で原子的に入れるしかない（#31）．
   - 判断待ちとして残したもの: #25・#26・#28 は net48 では更新の利得が無い（それぞれ型フォワード facade で中身同一／死んだ参照／依存 0 件→約 50 パッケージの死荷重）ため見送りが妥当だが，`@dependabot ignore` の投稿は人間の決定なので保留．分析結果は各 PR のコメントと `.claude/deps-update-report.md` に残した．
   - 付随して判明: ENV_04 の `vswhere` は `-products *` が無く，VS Build Tools のみの環境（IDE 未導入）では何も返さないため `$msbuild` / `$vstest` が解決できなかった．検証を委譲したエージェントが実際にこれで検証不能に陥ったので修正した（#32）．
+
+- [x] **Dependabot 追従作業の実施と，クリーンビルドでのみ顕在化する依存欠落の発見** (2026-08-29): 前エントリで起票した #29・#30・#32 を実装してマージし，#31（ArUco 移行）は実機確認待ちの PR として残した．その検証過程で，**`main` に元から存在した「クリーンビルドするとテスト 41 件が落ちる」不具合**を発見して修正した（#39）．
+  - 失敗パターン（最重要）: `bin` に前回のビルド成果物が残っていると，過去にコピーされた DLL でアセンブリ解決が偶然成立し，**依存の記述漏れを隠してしまう**．テストプロジェクトは OpenCvSharp が要求する `System.Memory` / `System.Runtime.CompilerServices.Unsafe` を `packages.config` にも csproj にも持っていなかったが，同じマシンで作業し続ける限り誰も気づけなかった．この作業中に「`main` のベースラインは全緑」と**誤った計測結果を一度報告している**．対策として ENV_04 に「計測・マージ前検証は `bin`/`obj` を消してから，依存を変えた PR では `packages` も退避して `nuget restore` からやり直す」手順を明記した．ただし運用頼みの弱い防御なので，構造的な解は CI（#40 で起票）．
+  - 設計判断（推移的依存をどのバージョンで足すか）: 同じ「不足している推移的依存を追加する」対処でも，**要求元のバージョンによって正解が変わる**．#39（OpenCvSharp 4.10 のまま）は本体と同一の現行版を足すのが正しい．4.10 が要求するアセンブリバージョンと NuGet パッケージが供給する版が厳密一致し，バインディングリダイレクトが不要になるため．一方 #31（4.13 へ更新）は依存を 4.6.x 系に上げる必要がある．4.13 の要求版はどの lib にも存在せずリダイレクトを自動生成できないので，手書きのダウングレードリダイレクトを保守し続けることになるため．「競合を避けたいから新版に先合わせする」は後者の罠を前者に持ち込むので採らない．
+  - 原因（#31 側）: OpenCvSharp は 4.13 で `lib/net48` を廃止し `lib/netstandard2.0` のみになった．net48 プロジェクトが netstandard2.0 アセンブリを消費する形になり，`System.Memory` 等への推移的依存が新たに発生する．`packages.config` は推移的依存を自動解決しないため，本体・テストの両方に明示的な参照追加が要る．
+  - 後段: #31 は**実機・実チャートでの確認待ち**（PR #36）．OpenCvSharp のネイティブ側が変わるため，合成 fixture の自動テストが緑でも検出性能・色変換の数値差は実機でしか担保できない．CI 導入（#40）が入れば `/deps-update` のマージゲートがローカル検証から CI 緑に変わり，判断待ちで残っている #25・#26・#28 の処理も進めやすくなる．テストプロジェクトの PackageReference 移行（推移的依存が自動解決される根本対策）は #31 マージ後・CI 導入後に検討する．