pip 25.3のURL依存非推奨化を最速で直す2026年8月版

2026年8月下旬にリリースされたpip 25.3で、requirements.txtにパッケージを直接URL指定する書き方（git+https://...やhttps://.../xxx.whl形式）の扱いが厳格化され、これまで警告どまりだったレガシーインストール経路がエラーに格上げされたという報告が相次いでいる。影響が大きいのは、requestsベースのスクレイピングスクリプトとPlaywrightを同居させたrequirements.txt構成だ。CI・本番サーバーで「昨日まで通っていたpip installがいきなり依存解決に失敗する」という事故が起きやすいので、原因の切り分けと直し方を整理しておく。

pip 25.3のURL依存非推奨化で何が変わったか

これまでpipは、GitHubのフォークやプライベートリポジトリから直接パッケージを取得するgit+https://指定や、社内ミラーに置いたtarball・wheelのURLを直接指定するインストール方法を許容してきた。取得先にpyproject.toml（PEP 517ビルドバックエンド）が無くsetup.pyだけで構成されている古いリポジトリでも、pipが黙ってsetup.pyフォールバックビルドを実行して通してくれていたのが実態だ。pip 25.3ではこのフォールバック経路が非推奨から一段引き上げられ、メタデータが正しく取得できないURL依存はビルド段階でエラー終了するようになった。

典型的なエラーメッセージ

• ERROR: Cannot install from 'git+https://...': legacy-install-path is no longer supported
• error: subprocess-exited-with-error / Preparing metadata (setup.py) did not run successfully
• ResolutionImpossible（URL依存のパッケージが他の固定バージョンと矛盾すると判定される）

影響を受けやすい書き方・受けにくい書き方

requests+Playwright同居構成で特に崩れやすい理由

スクレイピング用の環境は、requestsやBeautifulSoupのような素直なPyPIパッケージだけでなく、アンチボット対策のために自作パッチを当てたSeleniumラッパーや、特定サイト向けにforkしたスクレイピングライブラリをGitHub直参照で入れているケースが多い。さらにPlaywrightはPythonパッケージのインストールとは別にplaywright installでブラウザバイナリを別途取得する二段構成のため、依存解決の失敗がどちらの層で起きているのか切り分けにくい。

事故が起きやすい典型パターン

# requirements.txt の例（pip 25.3で失敗しやすい）
requests==2.32.3
playwright==1.45.0
git+https://github.com/someuser/custom-selenium-wire.git@fix-branch
-e git+https://internal-git.example.com/scraping-utils.git#egg=scraping_utils

上記のうち下2行が典型的な「URL依存」で、社内でメンテナンスしている小規模ユーティリティほどpyproject.toml化が後回しになっており、対象になりやすい。CIログを見て、失敗箇所がPlaywright本体ではなくgit+https://指定のパッケージであることを最初に確認するだけで、対処の方向性が大きく変わる。

依存解決エラーの直し方

応急処置：pipのバージョンを固定してCIを止めない

# 一時的に旧挙動のpipへ固定して切り戻す
python3 -m pip install "pip
本番を止めないための時間稼ぎとしては有効だが、いずれpip側の対応終了とともに使えなくなるため、根本対応とセットで扱う。

恒久対策：URL依存をpyproject.toml化・PyPI発行に切り替える

社内で保守しているスクレイピング用ユーティリティは、setup.pyのみの構成からpyproject.toml＋PEP 517ビルドバックエンド（setuptoolsやhatchling）に移行する
外部の重要なforkは、社内PyPIミラー（devpiやAWS CodeArtifact等）にビルド済みwheelとして登録し、requirements.txtからは通常のバージョン指定でインストールする
どうしてもGit直参照が必要な場合は、対象リポジトリ側にpyproject.tomlを追加してもらうか、自分でforkしてビルド構成を足す


lockfile運用でURL依存の再発を防ぐ
requirements.txtを手で書き足していく運用は、誰がいつURL依存を混入させたか追跡しづらい。pip-compile（pip-tools）やuv pip compileでロックファイルを生成する運用に切り替えると、依存グラフの解決結果が明示され、URL依存が紛れ込んだ時点でCIのビルド段階で検知できる。
# pip-tools での例
pip install pip-tools
pip-compile requirements.in -o requirements.txt
pip-sync requirements.txt


移行時に見落としがちな落とし穴

Playwrightのバージョン固定漏れ：requirements.txtのPlaywrightバージョンを上げてもplaywright installを再実行しないと、Pythonパッケージとブラウザバイナリのバージョンがずれてクラッシュする
requirements.txtの散在：案件ごとにスクリプトをコピーして使い回していると、同じURL依存の記述が複数箇所に残ったままになり、1つ直しても他で同じエラーが再発する
CI環境とローカル環境のpipバージョン差：ローカルは古いpipのままで気づかず、CIだけ最新pipで失敗するケースがあるため、pip --versionをCIログに必ず出力させておく

アンチボット対策のコードを頻繁に更新している環境では、こうした依存関係の足回りトラブルの検知と修正コストがそのまま運用負担として積み上がる。curl_cffi 0.16.0の403対策｜2026年8月版で扱ったような対策コードの更新と、今回のような依存解決エラーの止血が同時多発すると、片手間の運用では手が回らなくなりやすい。

環境を直しても収集の適法性は別問題
依存関係のエラーを解消して収集が再び動くようになっても、それだけで「収集して良い」ことにはならない。特に以下の3点は、環境トラブル対応と並行して必ず確認する。

個人情報保護法：氏名・連絡先など個人情報を含むページを収集する場合、利用目的の特定や安全管理措置など通常の個人情報取得と同じ規制がかかる
著作権法：サイトのテキスト・データベース構造をそのまま複製・再配布すると著作権侵害になり得る
不正競争防止法・利用規約違反：利用規約でスクレイピングを明示的に禁止しているサイトに対して自動アクセスを続けると、規約違反として債務不履行や不法行為責任を問われるリスクが指摘されている。海外でもLinkedIn対hiQ Labsの訴訟のように、公開情報のスクレイピングであっても合法性の判断が流動的な事例がある

依存関係トラブルの原因調査でエラーログや通信内容を見ている最中は、収集先の規約やrobots.txtも合わせて再確認する良いタイミングでもある。関連して、自動実行しているスクリプトが意図しない挙動をしていないかの点検にはsystemctl・cronで不審な自動起動を点検2026年8月が参考になる。

まとめ
pip 25.3のURL依存非推奨化は、requestsやPlaywrightを組み合わせたスクレイピング環境で見えにくい形の障害を起こしやすい。応急処置はpipバージョンの固定、恒久対策はURL依存のpyproject.toml化とlockfile運用への移行が基本線になる。加えてPlaywrightのブラウザバイナリ整合性やrequirements.txtの散在といった見落としがちな箇所も点検すると再発を防げる。ただし環境が直ってもデータ収集の適法性は別問題であり、個人情報保護法・著作権法・利用規約の確認は都度セットで行う必要がある。