diff --git a/journals/20260215-0004-Debugging_Endgame.md b/journals/20260215-0004-Debugging_Endgame.md
index 5e3c1c6..60096f4 100644
--- a/journals/20260215-0004-Debugging_Endgame.md
+++ b/journals/20260215-0004-Debugging_Endgame.md
@@ -11,7 +11,7 @@
 
 広範な調査の結果、以下の要因による **ABI (Application Binary Interface) 衝突** であることが判明した。
 
-### 真因：システム環境変数 `PATH` の汚染
+### 真因：システム環境変数 `PATH` の汚染と、ビルド時のアーキテクチャ誤認
 
 Windows の DLL ロード順序において、アプリケーション自身のディレクトリに DLL が見つからない場合、システムは `PATH` を探索する。
 
@@ -19,6 +19,13 @@
 - アプリケーションは **MSVC** でビルドされていたが、実行時に `WebView2Loader.dll` や `sqlite3.dll` を探す際、`PATH` にある MinGW 版を誤ってロードしてしまった。
 - 同名でも内部構造やエクスポート関数が異なるため、「エントリポイント未発見」でクラッシュしていた。
 
+1. **システム PATH 内の予期せぬ競合**:
+    - 調査の結果、`C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\` に存在する `WebView2Loader.dll` がロードされていたことが判明した。
+    - これは MinGW 版と同様に、MSVC ビルドが期待するエントリポイントを持っていない（あるいは architecture が不一致）ため、`0xc0000139` クラッシュを引き起こしていた。
+
+2. **ビルドプロセスでのアーキテクチャ誤認**:
+    - また、初期の集約スクリプトにおいて、`target/debug/build` 内の `x86` 版 `WebView2Loader.dll` を優先して拾ってしまい、バイナリ（x64）の隣に不適切な DLL を置いていたことも二次的な要因となっていた。
+
 ## 3. 解決策 (How it was solved)
 
 環境変数 `PATH` の手動クリーンアップに頼らず、ビルドプロセス自体を「自己完結型（Hermetic）」にすることで、根本的に問題を解決した。