新しいライブラリが出た瞬間に、自動で更新PRが届く。便利な仕組みですが、その速さがそのまま安全とは限りません。2026年7月、GitHubのDependabotは通常のバージョン更新で「少し待つ」運用を標準にしました。
GitHubの発表では、Dependabotは新しいリリースがレジストリで少なくとも3日間利用可能になってから、version updateのプルリクエストを開くようになりました。設定を追加しなくても標準で適用されます。
これは自動更新をやめる話ではありません。むしろ、セキュリティ更新、通常のバージョン更新、チーム内のマージ判断を分けるための変更です。Webサービス、社内ツール、ECサイト、業務アプリを持つ小さなチームほど、ここで自分たちの確認順を作っておく価値があります。
何が変わったのか。3日待つのは通常のバージョン更新
今回のポイントは、Dependabotが新しいパッケージのリリースを見つけても、通常のversion update PRをすぐには出さないことです。GitHubは、新しいリリースが公開されてから少なくとも3日たつまで待つと説明しています。
背景にあるのは、ソフトウェアサプライチェーンのリスクです。新しいバージョンは、修正や機能追加を含む一方で、壊れた変更や侵害されたパッケージが混ざる入口にもなります。公開直後に自動PRが来て、そのままテストを通ってマージされると、問題が見つかる前に本番へ入る可能性があります。
3日待つことで、メンテナーや利用者コミュニティが異常に気づく時間を少し作れます。ただし、これは保証ではありません。3日後でも問題が残ることはあります。だから、今回の変更は「安全になったから何もしなくてよい」ではなく、「自動更新PRを受け取る前段階に、最低限の待機が入った」と読むのが現実的です。
セキュリティ更新を同じ棚に置かない
誤解しやすいのは、3日待機がすべてのDependabot更新にかかるわけではない点です。GitHubは、この標準の待機はversion updatesだけに適用され、security updatesはすぐ開くと説明しています。
ここは運用上かなり重要です。通常のバージョン更新は、機能改善、互換性、保守性のために必要です。一方、セキュリティ更新は、既知の脆弱性を修正するための更新です。両方を同じ速度で扱うと、急ぐべき更新を遅らせたり、急がなくてよい更新を雑に入れたりしやすくなります。
小さなチームなら、まずPRの種類を分けるだけでも判断が変わります。脆弱性対応のPRは、影響範囲、悪用可能性、修正バージョン、テスト結果を優先して確認します。通常更新のPRは、リリースノート、破壊的変更、依存先のさらに先の変更、ロックファイル差分、CI結果を見る順番にします。
この区別を作っておくと、「Dependabotが出したから全部同じ」から抜け出せます。
`cooldown` で変える前に見る設定
GitHub Docsでは、`cooldown` オプションで待機期間を調整できると説明されています。`default-days` を指定すれば標準の待機期間を変えられ、対応するパッケージマネージャーではmajor、minor、patchごとの待機も設定できます。不要な場合は特定の依存関係を待機対象から外すこともできます。
ただし、最初にやるべきことは、設定を細かくすることではありません。まず現在の `.github/dependabot.yml` を見て、どのパッケージエコシステムを、どの頻度で、どのディレクトリから更新しているかを確認します。
次に、更新PRの量を見ます。PRが多すぎて放置されているなら、待機期間よりもグループ化、更新頻度、担当者、レビュー基準の方が効くかもしれません。逆に、特定の重要パッケージだけは早く追いたいなら、その依存関係を例外にする余地があります。
`cooldown` は便利ですが、万能の安全装置ではありません。設定を増やすほど、なぜその期間にしたのかを説明できる必要があります。
小さなチームが今日確認する順番
まず、DependabotのPRを通常更新とセキュリティ更新に分けて見ます。タイトルやラベルだけでなく、GitHubのDependency graphやDependabotの画面で、どの機能が有効になっているかを確認します。
次に、通常更新PRのマージ条件を短く決めます。最低限、リリースノート、CI、ロックファイル差分、主要機能の手動確認、本番影響が大きい依存関係かどうかを見ます。3日待機が入っても、マージ前の判断はチーム側に残ります。
最後に、例外ルールを決めます。セキュリティ修正は早く見る。通常更新は急がない。壊れやすい依存関係は長めに待つ。社内ツールより公開サービスを優先して検証する。この程度でも、更新PRの扱いはかなり明確になります。
Dependabotの3日待機は、開発チームだけの細かい仕様変更ではありません。外部パッケージに依存するサービスを運用しているなら、更新を「速く入れるか、止めるか」ではなく、「何を待ち、何を急ぎ、何を確認してから入れるか」に分けるきっかけになります。
