GitHub Dependabotで、新しいパッケージが公開されているのにバージョン更新PRがすぐ作られない場合、2026年7月から既定化された3日間のクールダウンが原因である可能性が高いです。
GitHub.comのDependabotは、通常のバージョン更新について、新しいバージョンがパッケージレジストリで公開されてから少なくとも3日経過するまで、更新候補として扱いません。設定ミスや障害ではなく、公開直後の不具合版や悪意のあるパッケージを取り込むリスクを減らすための安全策です。一方、既知の脆弱性を修正するセキュリティ更新には、この3日間の待機は適用されません。(The GitHub Blog)
クールダウン期間は、.github/dependabot.ymlのcooldown.default-daysで延長、短縮、無効化できます。本記事では、3日経過後もPRが作られない理由、実際の設定例、リポジトリごとの判断基準まで具体的に解説します。
新しいパッケージ版のDependabot PRが3日間作られないのはなぜ？
Dependabotの既定3日クールダウンは、ソフトウェアサプライチェーン攻撃への対策として導入されたものです。
新しく公開されたパッケージには、次のようなリスクがあります。
- パッケージ管理者のアカウントが侵害され、不正なコードを含むバージョンが公開された
- ビルドや公開手順のミスにより、正常に動作しないバージョンが公開された
- 後方互換性を壊す変更が、意図せずパッチ版として公開された
- 公開後に問題が見つかり、短時間で取り下げられた
公開直後にDependabotがPRを作り、自動マージまで実行すると、問題が発見される前のバージョンを取り込む可能性があります。数日待つことで、パッケージ管理者、セキュリティ研究者、自動スキャナー、利用者コミュニティが問題を発見する時間を確保できます。
GitHubは、3日間を「公開直後のリスクを避けつつ、依存関係を古い状態にしすぎないためのバランス」と位置付けています。ただし、クールダウンは安全性を保証する機能ではなく、短期間で発見・削除される不正パッケージへの防御策の一つです。(The GitHub Blog)
Dependabotが扱う2種類の更新を整理すると、次のようになります。
| 更新の種類 | 主な目的 | 既定3日クールダウン | PR作成の考え方 |
|---|---|---|---|
| バージョン更新 | 新機能、改善、不具合修正を含む通常の更新 | 適用される | 公開から少なくとも3日経過した版を対象にする |
| セキュリティ更新 | 既知の脆弱性を修正する | 適用されない | 修正版が利用可能で、必要な機能が有効なら速やかに作成する |
2026年7月時点では、GitHub.com上でDependabotが対応するパッケージエコシステム全体に、この既定動作が適用されます。GitHub Enterprise Serverではバージョンによって動作が異なり、GitHubはGHES 3.23での適用を案内しています。オンプレミス環境では、利用中のGHESリリースノートも確認してください。(The GitHub Blog)
「3日後に必ずPRが作られる」わけではない
既定3日クールダウンで特に誤解しやすいのが、公開から3日後にDependabotが自動的にPRを作るわけではないという点です。
Dependabotは、次の順序でバージョン更新を判定します。
schedule.intervalで指定された日時に更新チェックを開始する- 新しいバージョンの公開日時を確認する
- クールダウン期間内なら、そのバージョンを更新対象から外す
- クールダウン期間を過ぎていれば、通常の更新条件を評価する
- バージョン制約やPR上限などにも問題がなければPRを作成する
つまり、3日間は「PRを作らない期間」ではなく、より正確には新しいバージョンを更新候補として扱わない最低期間です。3日経過後、次回のスケジュール実行時に初めてPR作成の対象になります。(GitHub Docs)
日次チェックでも4日以上待つことがある
たとえば、新しいnpmパッケージが月曜日の10時に公開され、Dependabotを平日の9時に実行する設定だったとします。
| Dependabotの実行時刻 | 公開からの経過時間 | 判定 |
|---|---|---|
| 火曜日 9時 | 約23時間 | クールダウン中のため対象外 |
| 水曜日 9時 | 約47時間 | クールダウン中のため対象外 |
| 木曜日 9時 | 約71時間 | まだ3日未満のため対象外 |
| 金曜日 9時 | 約95時間 | クールダウンを過ぎたため更新候補 |
この場合、既定値は3日でも、PRが作られる可能性があるのは公開から約4日後です。
さらに、schedule.interval: "daily"は毎日ではなく、原則として月曜日から金曜日までの平日実行です。週次や月次にしている場合は、公開タイミングによって3日を大きく超えて待つことがあります。timeを指定していない場合、実行時刻はGitHub側で割り当てられるため、時刻を明確にしたい場合はtimeとtimezoneを設定しましょう。(GitHub Docs)
scheduleとcooldownは役割が異なる
| 設定 | 制御するもの | 例 |
|---|---|---|
schedule.interval | Dependabotが更新を確認する頻度 | 平日、週次、月次 |
schedule.time | 更新確認を開始する時刻 | 9時 |
schedule.timezone | timeに使用するタイムゾーン | Asia/Tokyo |
cooldown.default-days | 公開後、更新候補にしない日数 | 3日、7日、0日 |
groups | 複数の更新を1本のPRにまとめる | npm更新を一括化 |
open-pull-requests-limit | 同時に開いておけるバージョン更新PR数 | 5本、10本 |
「DependabotのPRを週1回にしたい」ならschedule、「公開直後のバージョンを避けたい」ならcooldown、「PRの本数を減らしたい」ならgroupsを使います。
セキュリティ更新は3日待たずに作成される
既定3日クールダウンが適用されるのは、通常のバージョン更新だけです。
既知の脆弱性に対するDependabotセキュリティ更新は、クールダウンの対象になりません。脆弱性が公開され、更新可能な修正版が存在する場合は、通常のバージョン更新スケジュールとは別に処理されます。(The GitHub Blog)
ただし、「セキュリティ更新は即時」とは、クールダウンによる意図的な待機がないという意味です。PRを作成させるには、リポジトリ側で次の機能が有効になっている必要があります。
- Dependency graph
- Dependabot alerts
- Dependabot security updates
これらが無効なままでは、通常のバージョン更新を月次にしていても、脆弱性修正のPRが別枠で作成されるとは限りません。更新頻度を下げる前に、リポジトリの「Settings」内にあるコードセキュリティ関連設定を確認してください。(GitHub Docs)
dependabot.ymlでクールダウンを変更する方法
クールダウンは、デフォルトブランチに配置した.github/dependabot.ymlの各updatesエントリー内で設定します。
次は、npmのバージョン更新を毎週火曜日の9時に確認し、新しいバージョンを7日間待ってから、1本のPRにまとめる例です。
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
day: "tuesday"
time: "09:00"
timezone: "Asia/Tokyo"
cooldown:
default-days: 7
groups:
routine-updates:
patterns:
- "*"cooldownはパッケージエコシステムごとに設定します。npmは7日、GitHub Actionsは3日、Dockerは14日というように、同じリポジトリ内でも個別に変更できます。
既定の3日間をそのまま使う
cooldownを記述しなければ、バージョン更新には3日間の既定値が適用されます。
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"既存のdependabot.ymlにcooldownが書かれていなくても、2026年7月以降のGitHub.comでは3日間の待機が自動的に適用されます。
組織の設定方針をコード上で明確にしたい場合は、既定値と同じでも明示的に記述できます。
cooldown:
default-days: 3クールダウンを7日に延長する
公開直後のパッケージをより慎重に扱いたい場合は、日数を増やします。
cooldown:
default-days: 7本番環境で利用する公開パッケージや、更新後の影響範囲が広い基盤ライブラリでは、7日程度に延長する運用が考えられます。ただし、修正や新機能の取り込みも遅くなるため、単純に長くすれば安全というわけではありません。
クールダウンを1日に短縮する
新機能を早く検証したいリポジトリでは、1日に短縮できます。
cooldown:
default-days: 1公開から1日経過した時点で更新候補になりますが、PRの作成はその後のスケジュール実行時です。default-days: 1にしても、週次チェックなら翌日にPRが作られるとは限りません。
クールダウンを無効化する
公開直後のバージョンも対象にしたい場合は、default-daysを0に設定します。
cooldown:
default-days: 0GitHubの公式案内ではクールダウンをオプトアウトでき、現在のDependabot実装では既定日数として0を指定できます。これにより、従来に近い形で、スケジュール実行時点の最新バージョンを更新候補にできます。(The GitHub Blog)
ただし、公開レジストリの依存関係すべてに対して一律に無効化するのは慎重に判断してください。高速な更新が本当に必要なパッケージだけを例外にする方が、リスクを抑えやすくなります。
major・minor・patchで待機期間を変える
対応するパッケージマネージャーでは、SemVerの更新レベルごとにクールダウン期間を分けられます。
cooldown:
default-days: 3
semver-major-days: 14
semver-minor-days: 7
semver-patch-days: 3この設定では、次のように扱われます。
| 更新レベル | 例 | クールダウン |
|---|---|---|
| major | 1.5.0から2.0.0 | 14日 |
| minor | 1.5.0から1.6.0 | 7日 |
| patch | 1.5.0から1.5.1 | 3日 |
破壊的変更が含まれる可能性の高いmajor更新を長く待ち、影響が比較的小さいpatch更新を早めに取り込む運用に向いています。
semver-major-days、semver-minor-days、semver-patch-daysは、SemVer別設定に対応するパッケージマネージャーでのみ利用できます。個別の日数を省略した更新レベルには、default-daysが適用されます。(GitHub Docs)
社内パッケージだけクールダウンから除外する
公開パッケージには7日間のクールダウンを適用し、自社で管理するnpmパッケージだけすぐ更新する例です。
cooldown:
default-days: 7
exclude:
- "@example-company/*"excludeに一致する依存関係は、クールダウンから除外され、待機なしで更新候補になります。includeとexcludeの両方に一致した場合は、excludeが優先されます。(GitHub Docs)
注意したいのは、cooldown.excludeはDependabotの更新対象から除外する設定ではないという点です。
cooldown:
exclude:
- "example-package"この設定は「example-packageを更新しない」ではなく、「example-packageにはクールダウンを適用しない」という意味です。更新そのものを停止したい場合は、ignoreを使用します。
Dependabotのクールダウンは何日に設定すべきか
GitHubの既定値である3日は、多くのリポジトリでそのまま利用できる現実的な出発点です。変更する場合は、更新速度だけでなく、パッケージの信頼性、CIの充実度、影響範囲を合わせて判断します。
以下はGitHubの公式推奨値ではなく、実務上の目安です。
| 日数 | 向いている運用 | 主な注意点 |
|---|---|---|
| 0日 | 自社管理パッケージ、公開直後の検証が必要な開発用リポジトリ | 不正版や不具合版を早期に取り込む可能性が高まる |
| 1～3日 | 更新頻度の高いWebアプリ、十分な自動テストがある環境 | 公開直後のリスクを完全には避けられない |
| 7日 | 一般的な本番システム、週次で依存関係をレビューするチーム | 不具合修正や新機能の取り込みも遅くなる |
| 14～30日 | 安定性を重視する基盤、更新検証に時間が必要なシステム | 更新差分が大きくなり、後からまとめて対応しにくくなる |
判断に迷った場合は、次の方針が扱いやすいでしょう。
- まず既定の3日間で運用する
- 問題が多い公開パッケージだけ7日以上に延長する
- 自社管理パッケージだけ
excludeで即時更新にする - リポジトリ全体の
default-days: 0は、必要性を説明できる場合だけ使用する
クールダウンを長くしすぎると、依存関係が古くなり、後から複数の変更をまとめて検証する負担が増えます。日数を固定して終わりにせず、更新PRの失敗率や差し戻し件数を見ながら調整することが重要です。
PR数を減らしたいならgroupsも併用する
クールダウンは、公開直後のバージョンを避けるための機能です。複数の依存関係を1本のPRにまとめる機能ではありません。
Dependabotの通知やCI実行回数を減らしたい場合は、groupsを併用します。
groups:
routine-updates:
patterns:
- "*"運用目的ごとに使い分けると、設定を設計しやすくなります。
| 解決したい問題 | 使用する設定 |
|---|---|
| 新しすぎるパッケージを避けたい | cooldown |
| PRが毎日のように作られる | schedule |
| 依存関係ごとに大量のPRが作られる | groups |
| 開いているPRが多すぎる | open-pull-requests-limit |
| 特定のパッケージを更新したくない | ignore |
たとえば「週次実行・7日クールダウン・全更新を1本にグループ化」とすれば、公開直後のバージョンを避けながら、レビュー日を固定してPR数も抑えられます。GitHubも、通常の更新を静かに運用する方法として、クールダウン、スケジュール、グループ化の組み合わせを紹介しています。(The GitHub Blog)
3日を過ぎてもDependabot PRが作られないときの確認ポイント
公開から3日以上経過しているのにPRが作られない場合、クールダウン以外の条件も確認する必要があります。
| 確認項目 | よくある原因 | 対処 |
|---|---|---|
| 次回スケジュール | 3日経過後の更新チェックがまだ実行されていない | schedule.interval、day、time、timezoneを確認する |
| 個別クールダウン | majorやminorだけ長い日数になっている | semver-*-daysを確認する |
| バージョン制約 | マニフェストの制約上、最新版へ更新できない | package.jsonなどのバージョン指定を確認する |
ignoreやallow | 対象パッケージや更新レベルが制限されている | dependabot.ymlの条件を確認する |
| PR上限 | 開いているバージョン更新PRが上限に達している | 既存PRを処理するか、グループ化・上限変更を行う |
| 既存PR | 同じ依存関係のPRがすでに開いている | 既存PRの状態を確認する |
| プライベートレジストリ | 認証情報やアクセス権に問題がある | Dependabotのジョブログを確認する |
| 更新処理エラー | ロックファイル更新や依存関係解決に失敗している | エラー内容に沿ってマニフェストを修正する |
Dependabotでは、開いているバージョン更新PRの既定上限は5本です。5本に達している場合、それらがマージまたはクローズされるまで、新しいバージョン更新PRは作成されません。セキュリティ更新PRは、このバージョン更新用の上限には含まれません。(GitHub Docs)
Dependabotのジョブログを確認する手順
- 対象リポジトリを開く
- 「Insights」を選択する
- 「Dependency graph」を開く
- 「Dependabot」タブを選択する
- 対象エコシステムの「Last checked」を開く
- 最新のジョブログを確認する
設定や認証エラーを修正した後は、「Check for updates」から更新チェックを手動実行できます。(GitHub Docs)
ただし、手動の「Check for updates」はクールダウンを回避する機能ではありません。再実行時にも同じクールダウン条件が評価されるため、公開から3日以内のバージョンを強制的にPR化することはできません。すぐに更新する必要がある場合は、default-days: 0へ変更するか、手動で依存関係を更新します。
クールダウンだけでは防げないリスクにも注意する
3日間待ったからといって、そのパッケージが安全だと保証されるわけではありません。
クールダウンが特に有効なのは、公開後すぐに問題が発見され、短時間で取り下げられる不正バージョンです。次のような攻撃や問題には、十分な効果が期待できません。
- 数週間から数か月後に動作するバックドア
- 正規の管理者による意図的な不正変更
- パッケージのビルド環境そのものの侵害
- 正常な機能に見せかけた情報収集処理
- 依存関係の更新とは無関係なCI/CD認証情報の漏えい
GitHubも、クールダウンを多層防御の一つとして扱うよう案内しています。ロックファイルによるバージョン固定、CI/CDトークンの最小権限化、変更内容のレビュー、可能な環境でのインストールスクリプト制限などを組み合わせることが重要です。(The GitHub Blog)
Dependabot PRを自動マージしている場合は、少なくとも次の条件を設けましょう。
- 必須テストがすべて成功している
- major更新を自動マージしない
- 本番依存関係と開発依存関係を分ける
- リリースノートと変更差分を確認できる
- GitHub Actionsなどの実行権限を必要最小限にする
まとめ：まず既定3日を維持し、必要な部分だけ調整する
Dependabotの新しいバージョン更新PRがすぐ作られない場合、最初に確認すべきなのが既定3日クールダウンです。
通常のバージョン更新は、パッケージ公開から少なくとも3日間待機します。ただし、3日経過直後にPRが作られるとは限らず、次回のschedule実行まで待つ必要があります。セキュリティ更新はクールダウンの対象外ですが、Dependency graph、Dependabot alerts、Dependabot security updatesが有効であることを確認してください。
まずは既定の3日間を維持し、schedule.timeとtimezoneを明示して、実行タイミングを予測できる状態にするのが現実的です。そのうえで、安定性を重視する公開パッケージは7日以上、自社管理パッケージはexclude、即時更新が必要な環境だけdefault-days: 0というように、依存関係の性質に応じて調整しましょう。
コメント