保守を引き受けているWebアプリで、毎週10本前後のプルリクエストが自動で立ちます。依存パッケージのバージョン更新です。CIが緑なら中身を読まずにマージする——現場でよくある処理の仕方で、責める話ではありません。1本あたり数分でも10本あれば時間になりますし、大半は本当に安全な更新です。
問題は、その「大半」に紛れて悪意のあるバージョンが混ざったときに、機械的なマージが最短経路で本番に運んでしまうことです。パッケージが乗っ取られてから、コミュニティが気づいて警告が出るまでには時間差があります。その時間差の中でマージしてしまうのが、いちばん避けたい負け方でした。
2026年7月、GitHubがこの時間差に手を入れました。
既定が「公開から3日待つ」になった
Dependabotのバージョン更新は、新しいリリースがレジストリに公開されてから最低3日が経つまでプルリクエストを開かないという挙動が既定になりました。設定は不要で、何もしなければこの挙動になります（Dependabot version updates introduce default package cooldown — GitHub Changelog）。
重要な線引きが一つあります。この待ち時間はバージョン更新（version updates）だけに適用され、セキュリティ更新（security updates）は従来どおり即座にプルリクエストが立ちます。 既知の脆弱性への修正が3日遅れるという事態にはなりません。ここを混同すると「セキュリティ対応が鈍る変更だ」という誤読になるので、最初に押さえておく価値があります。
待ち時間は変更できます。.github/dependabot.yml の cooldown オプションで、1日から90日の範囲で指定するか、明示的に無効化することもできます。既定値が3日になったというだけで、選択の自由は残っています。
同じ思想の変更は言語のパッケージマネージャ側でも進んでいて、pip 26.1の依存クールダウンでも同じ発想を扱いました。「新しいものをすぐ取り込まない」がエコシステム側の既定になってきている流れです。
なぜ3日で足りるのか
3日という数字の根拠は、攻撃の側の時間軸にあります。パッケージの乗っ取りは、公開直後がもっとも危険です。誰も中身を見ていない状態で配布が始まり、自動更新の仕組みがそれを各社へ運びます。逆に言えば、公開から数日が経てば、誰かが気づいて騒ぎ始める確率がかなり上がる。npmで実際に起きたワーム型の事案でも、発覚から警告が回るまでは短時間でした（Mini Shai-Huludワームの経緯）。
つまりこの変更は、検知能力を上げるものではありません。すでに世の中にある検知能力が働くまで、自分が待つという設計です。守りとして地味ですが、費用がゼロで効くという点で筋がいい。
副産物として、壊れたリリースを踏む確率も下がります。公開直後に取り下げられたバージョンや、すぐパッチが出たバージョンを回避できるので、悪意の有無に関係なく更新の安定性が上がります。
クールダウンが守らない層がある
ここは見落とされやすいので、はっきり書きます。この3日は「Dependabotがプルリクエストを開くタイミング」を遅らせるだけです。 アプリが実際にどのバージョンをインストールするかは、別の層で決まります。
この点は変更直後から指摘されています。バージョン指定が緩いままだと、CIやデプロイ時の依存解決で新しいバージョンがそのまま取り込まれ得るためです（GitHub’s Dependabot Cooldown Has an Install-Layer Gap — TECHi）。プルリクエストを3日待たせても、別の経路で当日中に入ってくるなら守りとして穴が空きます。
だから、あわせて確認すべきものが2つあります。
ひとつはロックファイルがリポジトリにコミットされ、CIがそれを尊重してインストールしているか。npm ci のようにロックファイル通りに入れるコマンドを使っているか、npm install で毎回解決し直していないかという話です。
ふたつはビルドやデプロイのパイプラインで依存を取り直していないか。コンテナイメージをビルドするたびに最新を引いてくる構成だと、Dependabotの設定は関係なく最新が入ります。CI/CDそのものの供給網としてのリスクはGitHub Actionsの継続的な棚卸しで扱いました。
保守運用の取り決めに落とす
既定が変わったことを、保守の運用ルールに反映しておくと後が楽です。更新の種類ごとに扱いを分けるのが基本形です。
| 更新の種類 | 既定の挙動 | 運用の置き方 |
|---|---|---|
| セキュリティ更新 | 即時にPRが立つ | 優先で確認しマージする。ここを止めない |
| バージョン更新（パッチ・マイナー） | 3日待ってPRが立つ | まとめて定期的に処理する。CI緑を条件にする |
| バージョン更新（メジャー） | 3日待ってPRが立つ | 個別に判断する。自動マージの対象から外す |
大事なのは、セキュリティ更新とバージョン更新を運用上で分けることです。両方が同じ列に並んで届くと、量に押されて全部が同じ扱いになります。「セキュリティ更新だけは当日中に見る」という線が引けていれば、残りは週次でまとめて処理して構いません。
放置側の問題にも触れておきます。更新を溜め込むと、いざ脆弱性対応が必要になったときに、バージョンが離れすぎていて上げられません。更新を止めることは、緊急時に動けない体を作ることと同じです。3日待つのは止めることではないので、この点は混同しないでください。保守されていないサイトが実際にどう詰むかは放置されたサイトが攻撃を受けた実例で書きました。
発注している側が確認する2つのこと
外部に開発や保守を委託している場合、次の2点を聞いておくと状態が分かります。
「セキュリティ更新とバージョン更新は、別の扱いになっていますか」。同じ扱いなら、どちらかが雑になっています。前者が雑なら危険で、後者が雑ならコストが膨らみます。
「ロックファイルはコミットされていて、CIはそれを使っていますか」。技術的な質問に見えますが、答えは一言で返ってくる種類のものです。返ってこない場合は、依存の管理が誰の責任範囲か決まっていない可能性があります。
保守契約の範囲に依存更新が含まれているか、含まれている場合の頻度と判断基準はどうなっているか。ここが曖昧なまま数年経つと、更新されていないのに「保守している」状態になります。
今週やるなら、1行の確認から
自社または委託先のリポジトリで、.github/dependabot.yml を開いてください。cooldown の記述がなければ、今後は既定の3日が効きます。何もしなくてよいということです。
そのうえで、CIの設定でロックファイルを尊重するコマンドが使われているかを見る。この2つが揃っていれば、今回の変更の恩恵はほぼ受け取れています。
依存更新の運用を含めた保守の設計を相談したい、既存システムがどこまで更新できる状態にあるか調べてほしい——そうしたご相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- Dependabot version updates introduce default package cooldown — GitHub Changelog
- The case for a cooldown: Why Dependabot now waits before issuing version updates — The GitHub Blog
- GitHub Introduces Default “Cooldown” Policy for Dependabot Version Updates — InfoQ
- Version updates now have a 3 day cooldown by default — dependabot/dependabot-core Discussion #15582
- GitHub’s Dependabot Cooldown Has an Install-Layer Gap — TECHi
