【要約】pip は『足す』のは得意、でも『消す』のは誰がやる？ ── 配布物の削除を全履歴さかのぼって監査し、本体の更新は『様子見』にした話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
C3の開発者が、配布ツール特有の「不要なファイルの削除」という課題に直面した。pipはパッケージ本体の入れ替えは行うが、ツールがユーザー環境に書き込んだ成果物の管理は行わないため、以下の問題が発生する。
- ・廃止されたファイルが利用者のプロジェクト内に残り続ける。
- ・Claude Codeのコンテキストを無駄に消費する。
- ・将来的な名前衝突や、調査コストの増大を招く。
// Approach
C3の開発者が、配布物の削除を自動化し、過去の削除漏れを正確に特定するための仕組みを構築した。
- ・削除マニフェスト「deletions.txt」を導入し、update時に指定ファイルを削除する。
- ・歴史的な削除漏れを特定するため、2段フィルタによる監査を実施した。
- ・第1フィルタ：配布対象外のファイルを除外するため、本番ロジック（should_skip）を再利用した。
- ・第2フィルタ：過去の全公開タグに対し、git cat-file -e で実在を確認し、未出荷のファイルを除外した。
// Result
C3の開発者が、正確な削除指示書を作成し、利用者の環境をクリーンに保つことに成功した。
- ・全履歴から「実際に配布された」23件の削除漏れを特定し、deletions.txtに追記した。
- ・AIによる調査では32%の過剰検出が発生したが、機械的な実在チェックで精度を確保した。
- ・基盤の更新に対しても、実害がない限り「様子見」とする規律を確立した。
Senior Engineer Insight
> 配布ツールの設計において、追加（Add）だけでなく削除（Delete）のライフサイクルを考慮することは極めて重要だ。特に、パッケージマネージャの責務外となる「ユーザー環境への書き込み」を伴う場合、削除マニフェストの導入は必須となる。また、プラットフォームの更新に対して「反射的に追従しない」という判断は、保守コストを抑え、システムの安定性を維持するための高度な規律である。AIによる調査の網羅性と、機械的な検証による精度の使い分けは、実戦的なエンジニアリングとして高く評価できる。