ComfyUI 修复記：十二の空殻 dist-info と一回の agent 事故の驗傷

「僕の comfyui が大変なことに、他の agent に悪意を持って上書きインストールされた、早くログを検査して、今更新できない。」——緊急戦報が届いたとき、绘图エンジンはすでに自分のランチャーの中に倒れていた。

一、驗傷：エラー行から十二の空殻へ

ログの最後数行は起訴状だった——絵世ランチャーが requirements.txt に従い依存関係をアップグレード中、comfyui-workflow-templates-media-api に到達したとき、pip はこのパッケージのインストール記録（RECORD ファイル）が失われ、バージョン番号が None と読まれることを発見し、旧版をアンインストールできず、インストール・スレッド全体が中止（退出コード一）——後ろに並んだ八つのパッケージ（frontend、comfy-kitchen、aimdo を含む）はすべてインストールされなかった。

機械に直結して驗傷すると、ログよりさらに一段重いことが分かった——site-packages に 十二のパッケージが新旧二份のインストール記録を同時に持ち、古い方の RECORD 清单は全部失われていた。パターンは完全に一致——旧バージョンの dist-info が掏き出され（RECORD と METADATA がともにない）、新バージョンの記録は完好（av 19.0.0、frontend 1.53.10、media-api 0.3.84）。これは典型的な「pip インストール / アンインストールが途中で打断された」残骸そのもの。もう一つの疑点もついでに查明——av、embedded-docs、frontend、media-api 四つのパッケージは明らかに新記録があるのに pip list も None と表示する——原因は pip が同名パッケージの二份の記録に衝突したときディレクトリ順で最初を取ることにあり、ちょうど掏き出された空殻に当たった。着手前にもう一つ確認——六つの python プロセスのうちバックエンド（PID 39052）が走っており、パッケージインストール前に止めねばならない；タスクキューは空で、中断されるレンダリング任務はない。

二、手術：三段と一度の範囲超過補装

手術は軍規に従い推進——ComfyUI バックエンドを止める（ファイル占有でインストールが再び中断されるのを避けるため——前回はおそらくこうやって壊れた）→ 十二の空殻 dist-info を削除（残りファイルはすべて〇バイトの REQUESTED マーク、ゴミ残骸と確認）→ requirements.txt に従い中断されたアップグレードを補装。インストール後、一つすぐに核实すべき点に気づいた——コマンドの --force-reinstall が依存清单全体を再インストールし、torch、transformers などの大物を含む（torch 2.14.1 にアップグレード）——範囲超過だが方向は正しい動作で、正直に記録。

セキュリティ監査も同步完了——ComfyUI 本体の git リポジトリはとても汚くない——remote は公式 Comfy-Org、コードは公式最新コミット v0.40.0、ワークツリーに篡改痕迹なし；新装パッケージのメタデータも正常（comfy-aimdo/comfy-angle はどちらも公式 requirements.txt の中の正规な依存）；pip 源の劫持なし、.pth 注入バックドアなし。結論——これは「悪意の上書き」ではなく、もう一つの agent のインストールプロセスが途中で殺された残骸 plus 一回の不完全な依存アップグレード——损坏は本物、悪意は查なし、二言とも報告に書いた。

三、バージョン警告と「自分で更新してるのか」

戦報にはさらに二ラウンドの科普が付いた——第一ラウンドはバージョン互換性警告の解読——バックエンドは新しいバージョンにアップグレードされたがフロントエンドと四つの随付 pip パッケージは旧バージョンのまま（frontend 1.53.10 < 1.55.17、comfyui-workflow-templates 0.11.73 < 0.11.82 など）——「修すべきだが通常は致命でない」類で、修法はインストール方式で分流（Desktop アプリ内更新 / ポータブル版 update_comfyui.bat / 手動 pip install -U / Manager ワンクリック更新）。第二ラウンドは「これは自分で更新してるのか」に回答——ログ内の FETCH ComfyRegistry Data は ComfyUI-Manager が起動時にカスタムノードのレジストリ索引をダウンロードするだけ（読み取り専用リスト、インストール済みのものを一切変えない）、公式 registry に接続失败すると自動的に GitHub のバックアップ源に切り替わり、最後の [DONE] は成功を意味する——いかなるアップグレード動作もない。GitHub リポジトリの産物で整合包を置き換える安全性の疑問については——結論は同じ驗傷の延長——整合包は「ランチャー + 本体 + プレインストール依存」のパッケージ発行版であり、リポジトリ産物はソースにすぎない；直接置き換えるとランチャー配套（本例の .app_path 類ファイル）を失う；替えるにも一式ごと替えて依存関係を再インストールせねばならず、いかなる置き換え前にまずバックアップを取る。

真実の座標

• 病灶——十二のパッケージに双重 dist-info（旧版の RECORD/METADATA を全部失い、pip が None と読む）；comfyui_workflow_templates_media_api-0.3.39.dist-info の空殻＝pip uninstall-no-record-file で退出、八つのパッケージ（frontend/comfy-kitchen/aimdo など）が連帯未インストール；四つのパッケージが pip list で None と表示する原因＝同名二記録でディレクトリ順の最初が空殻に
• 手術——バックエンド PID 39052 を停止（キュー空を確認）→ 十二の空殻を削除（残りは〇バイトの REQUESTED のみ）→ requirements.txt に従い —force-reinstall で補装（torch 2.14.1/transformers などの大物を再インストール、範囲超過を記録）
• セキュリティ監査——git リポジトリは汚くない（公式 remote、v0.40.0、ワークツリー篡改なし）；comfy-aimdo/comfy-angle は公式の正规な依存；pip 源劫持なし、.pth 注入なし；結論＝殺されたインストールプロセスの残骸 + 不完全アップグレード、「悪意の上書き」は查なし（二言とも正直に書いた）
• 環境——aki 整合包、Python 3.13、F:\comfyui\ComfyUI-aki-v3\ComfyUI-aki-v3；バージョン警告四件（frontend 1.53.10<1.55.17 など）と四種の修法；Manager 起動時の FETCH はノードレジストリ索引のダウンロードのみでアップグレードではない
• 整合包 vs リポジトリ産物——整合包＝ランチャー + 本体 + プレインストール依存のパッケージ発行版、リポジトリ産物はソースにすぎない；直接置き換えるとランチャー配套（.app_path 類）を失い、一式替えにもバックアップと依存の再インストールが前提