Dependabot更新PRが3日遅れる理由｜cooldownの変更・無効化とsecurity updateへの影響

Dependabotのversion update PRがパッケージ公開直後に作られなくなったのは、不具合ではありません。GitHubが2026年7月14日に導入した新しい既定動作により、レジストリで新バージョンが公開されてから少なくとも3日間、version updateを待機するようになったためです。

この3日間の待機は、.github/dependabot.ymlに設定を書いていないリポジトリにも適用されます。待機期間を短縮・延長する場合はcooldownを追加します。すべての依存関係で待機を無効化することも可能です。一方、脆弱性を修正するsecurity updateはcooldownの対象外で、従来どおり待機せず処理されます。(The GitHub Blog)

Dependabotのversion update PRが3日遅れる理由

新しい既定動作では、Dependabotがレジストリ上の新しいリリースを検出しても、公開から3日が経過するまではversion updateの候補として扱いません。

GitHubがcooldownを既定化した主な理由は、ソフトウェアサプライチェーンのリスクを抑えるためです。公開直後のパッケージには、次のような問題が後から判明することがあります。

• メンテナーのアカウント侵害による不正なリリース
• マルウェアや悪意のあるコードの混入
• ビルド不能や重大なリグレッション
• 誤って公開されたバージョン
• 公開直後に取り下げられる不安定なリリース

短い待機期間を設けることで、メンテナーや利用者コミュニティから問題の報告が出る時間を確保し、公開直後の問題あるバージョンを自動的に取り込む可能性を下げる狙いがあります。(The GitHub Blog)

version updateとsecurity updateの違いを整理すると、次のようになります。

項目	version update	security update
主な目的	通常の新バージョンへ追従する	既知の脆弱性を修正する
既定のcooldown	3日	適用されない
cooldownによる変更	可能	対象外
PRの作成条件	新バージョンがあり、cooldownとスケジュールの条件を満たす	脆弱性アラートがあり、修正版へ解決できる
待機を無効化する必要性	運用方針に応じて判断	不要

重要なのは、設定ファイルを変更していないリポジトリでもversion updateの動作が変わる点です。これまで公開直後に届いていたPRが数日間届かなくなっても、まずは障害ではなく3-day defaultの影響を疑う必要があります。

対象サービスとGitHub Enterprise Serverの対応

新しい3日間の既定cooldownは、GitHub.com上でDependabot version updatesが対応するすべてのパッケージエコシステムに適用されます。

GitHub Enterprise Serverでは、GitHub Enterprise Server 3.23から適用される予定です。3.22以前を運用している場合は、GitHub.comと同じ動作になると決めつけず、利用中のGHESバージョン向けドキュメントとリリースノートを確認してください。(The GitHub Blog)

利用環境	3日間の既定cooldown
GitHub.com	対応する全エコシステムに適用
GitHub Enterprise Server 3.23	適用対象
GitHub Enterprise Server 3.22以前	バージョン固有の仕様を確認

既存の.github/dependabot.ymlにcooldownがなくても、GitHub.comでは3日間の待機が有効です。これが、設定変更をしていないのにPR作成時期が変わったように見える理由です。

3日後に必ずPRが作られるわけではない

「3日間のcooldown」は、公開から3日後にPRを即座に作成するタイマーではありません。新バージョンがversion updateの候補になるまでの最低待機期間です。

Dependabotは、おおむね次の順序で判定します。

1. schedule.intervalで指定したタイミングに更新を確認する
2. 対象バージョンがcooldown期間内か確認する
3. cooldown期間内なら、その更新をスキップする
4. cooldown終了後の更新確認で、PR作成条件を満たしていれば処理する

つまり、実際のPR作成時期は「公開から3日」と「次回のDependabot実行スケジュール」の組み合わせで決まります。(GitHub Docs)

dailyでも4日近く待つ例

次の設定を想定します。

schedule:
  interval: "daily"
  time: "09:00"
  timezone: "Asia/Tokyo"

月曜日の10時にパッケージが公開された場合、概念上は木曜日の10時以降にcooldownを通過します。しかし、木曜日の更新確認は9時に終わっているため、次の確認は金曜日の9時です。

日時	Dependabotの判定
月曜日 10:00	新バージョン公開
火曜日 09:00	3日未満のためスキップ
水曜日 09:00	3日未満のためスキップ
木曜日 09:00	まだ3日経過前のためスキップ
木曜日 10:00	cooldown終了の目安
金曜日 09:00	次回確認でversion updateの候補になる

また、dailyは毎日ではなく、標準では月曜日から金曜日までの平日に実行されます。weeklyは週1回で、曜日を指定しなければ月曜日が既定です。週次更新では、新バージョン公開から次の実行まで1週間近く空く場合があります。(GitHub Docs)

「3日を過ぎたのにPRが届かない」ときは、cooldownだけでなくinterval、day、time、timezoneも確認する必要があります。

dependabot.ymlでcooldownを上書きする方法

待機期間を変更するには、.github/dependabot.ymlの対象となるupdatesブロック内にcooldownを追加します。

主な設定項目は次のとおりです。

設定項目	用途
default-days	基本となる待機日数
semver-major-days	メジャーアップデートの待機日数
semver-minor-days	マイナーアップデートの待機日数
semver-patch-days	パッチアップデートの待機日数
include	cooldownを適用する依存関係
exclude	cooldownから除外する依存関係

待機日数には1日から90日までを指定できます。includeとexcludeはそれぞれ最大150項目で、*によるワイルドカードに対応します。excludeはincludeより優先され、除外された依存関係はcooldownを待たずに更新対象になります。(GitHub Docs)

3日を1日に短縮する

最新版への追従速度を高めたい場合は、default-daysを1にします。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
      time: "09:00"
      timezone: "Asia/Tokyo"
    cooldown:
      default-days: 1

この設定では、新バージョンの公開直後ではなく、少なくとも1日待ってからversion updateの候補になります。

ただし、1日経過した瞬間にPRが作られるわけではありません。実際の処理は、その後に実行されるdailyなどのスケジュールに従います。

3日を7日に延長する

より長く利用者の反応や不具合報告を確認したい場合は、待機期間を延長します。

cooldown:
  default-days: 7

特に、次のようなリポジトリでは長めのcooldownを検討できます。

• 本番環境へ短期間で自動デプロイされる
• Dependabot PRを自動マージしている
• CIだけでは互換性問題を十分に検出できない
• 依存パッケージの障害が業務停止に直結する
• ロールバックに時間がかかる

一方、単に待機期間を長くするだけでは、脆弱性の早期修正や互換性検証の負担は解決しません。CI、ブランチ保護、自動マージ条件、ロールバック手順と組み合わせて判断することが重要です。

major・minor・patchで待機期間を変える

SemVerの更新レベルごとに異なる待機期間を設定できます。

cooldown:
  default-days: 7
  semver-major-days: 30
  semver-minor-days: 7
  semver-patch-days: 3

この例では、破壊的変更を含む可能性が高いmajor updateを30日待機し、patch updateは3日で取り込めるようにしています。

実務では、次のようにリスクを分けると運用しやすくなります。

更新レベル	設定例	判断の考え方
major	14～30日	移行手順や破壊的変更を確認する
minor	3～7日	機能追加と互換性を確認する
patch	1～3日	修正を比較的早く取り込む

semver-major-days、semver-minor-days、semver-patch-daysは、DependabotがSemVerの更新レベルを判別できるパッケージマネージャーでのみ利用できます。対応状況が不明な場合は、まずdefault-daysを使う方法が安全です。(GitHub Docs)

特定の依存関係だけcooldownを無効化する

社内パッケージや、自社で公開タイミングを管理している依存関係だけを即時更新したい場合は、excludeを使用します。

cooldown:
  default-days: 7
  exclude:
    - "@company/*"
    - "internal-runtime-package"

この設定では、通常の依存関係には7日間のcooldownが適用されますが、@company/*とinternal-runtime-packageは待機せずversion updateの候補になります。

ここで注意したいのは、cooldown.excludeとignoreの違いです。

設定	動作
cooldown.exclude	待機させず、通常どおり更新する
ignore	条件に一致する更新そのものを対象外にする

特定のパッケージを早く更新したいときにignoreを使うと、PR自体が作られなくなります。待機だけを外したい場合は、cooldown配下のexcludeを使用してください。

すべてのcooldownを無効化して従来の速度に戻す

すべての依存関係をcooldownから除外するには、excludeにワイルドカードを指定します。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
      time: "09:00"
      timezone: "Asia/Tokyo"
    cooldown:
      exclude:
        - "*"

GitHub公式ドキュメントでは、excludeがワイルドカードに対応し、除外対象は即時更新されると説明されています。GitHubの変更告知でも、cooldownによる完全なオプトアウトが可能とされています。そのため、すべてに一致する"*"を除外することで、version updateに対する既定の3日待機を実質的に無効化できます。(The GitHub Blog)

なお、次の設定は使用しないでください。

cooldown:
  default-days: 0

cooldownの日数として指定できるのは1日から90日です。待機をゼロにする目的でdefault-days: 0を設定するのではなく、excludeを使って対象をcooldownから除外します。(GitHub Docs)

複数のupdatesブロックがある場合は、即時更新したい各ブロックに設定が必要です。npm用のブロックへ設定しても、GitHub Actions、Docker、pipなど別のブロックには自動的に適用されません。

特定のパッケージだけ待機させる

逆に、不安定になりやすい依存関係だけを長く待機させることもできます。

cooldown:
  default-days: 14
  include:
    - "framework-core"
    - "database-driver*"

includeを省略すると、そのupdatesブロックの依存関係すべてがcooldownの対象になります。includeを指定した場合は、指定した依存関係に対象を絞れます。

ただし、同じ依存関係がincludeとexcludeの両方に一致した場合は、excludeが優先されます。つまり、その依存関係は待機せずに更新されます。(GitHub Docs)

security updateは3日間待機しない

今回の3-day defaultが適用されるのは、通常の最新版追従を目的としたversion updateだけです。既知の脆弱性を修正するsecurity updateには、既定cooldownも、dependabot.ymlで指定したcooldownも適用されません。(The GitHub Blog)

たとえば、あるパッケージの新バージョンが公開された場合、状況によって処理が異なります。

状況	処理
通常の機能追加版が公開された	version updateとしてcooldownの対象
脆弱性の修正版が公開され、アラートが発生した	security updateとしてcooldownを待たず処理
security updatesが無効	自動のsecurity update PRは作成されない
依存関係の制約上、修正版へ解決できない	security update PRを作れない場合がある

「security updateは即時」という表現は、脆弱性公開と同時に必ずPRが完成することを保証するものではありません。正確には、3日間のcooldownによって意図的に遅延されないという意味です。

実際にsecurity update PRが作成されるには、Dependabot security updatesが有効で、脆弱性アラートがあり、依存関係を安全なバージョンへ解決できる必要があります。依存関係の制約やレジストリへの接続エラーなどにより、PRを作成できないこともあります。(GitHub Docs)

どのcooldown設定を選ぶべきか

実務上は、すべてのリポジトリで3日間を無効化するより、リポジトリのリスクと更新体制に応じて使い分ける方法が適しています。

運用状況	選択の目安
一般的な業務システム	既定の3日を維持
自動マージを利用している	3日以上を維持し、CI条件を厳格化
最新版への追従速度が重要	default-days: 1
社内パッケージだけ即時更新したい	excludeで対象パッケージを指定
major updateの影響が大きい	majorだけ14～30日程度に延長
release直後から検証したい	exclude: ["*"]で全面オプトアウト
CIや自動テストが弱い	cooldownを短縮せず、テスト整備を優先

既定の3日間は、更新を止める設定ではありません。公開直後のリスクを避けつつ、数日後には通常の更新フローへ戻すための安全策です。

特別な事情がなければ、まず既定値のまま運用し、更新速度が業務上の問題になる依存関係だけをexcludeする方法が管理しやすいでしょう。

3日以上経ってもPRが来ないときの確認項目

version update PRが作成されない原因は、cooldownだけとは限りません。次の順序で確認すると、原因を切り分けやすくなります。

確認項目	確認内容
リリース日時	レジストリ公開から3日が経過しているか
実行スケジュール	cooldown終了後に次の実行があったか
タイムゾーン	timeがUTCとして解釈されていないか
PR数の上限	version update PRが既定の5件に達していないか
対象ディレクトリ	directoryまたはdirectoriesが正しいか
更新ルール	ignoreやallowで除外されていないか
バージョン制約	manifestの制約内で更新できるか
レジストリ接続	private registryの認証や通信に失敗していないか
ジョブログ	Dependabotの実行結果にエラーがないか

Dependabotでは、version update PRが5件開いていると、既定では追加のversion update PRを作成しません。security update PRには別の上限があり、既定では10件です。両者の上限は分離されているため、version update PRが上限に達したことだけを理由にsecurity update PRが止まるわけではありません。(GitHub Docs)

Dependabotのジョブログを確認する手順

GitHub上では、次の順序で実行履歴を確認できます。

1. 対象リポジトリを開く
2. Insightsを選択する
3. Dependency graphを開く
4. Dependabotを選択する
5. 対象manifestのRecent update jobsを開く
6. 必要な実行のView logsを選択する

ジョブログでは、更新処理が実行された時刻や、依存関係の解決、レジストリ接続、PR作成を妨げたエラーを確認できます。(GitHub Docs)

設定変更後に確認すべきこと

cooldownを変更した後は、PRが来たかどうかだけで判断せず、次の点を確認してください。

1. 対象となるupdatesブロックにcooldownを配置したか
2. YAMLのインデントが正しいか
3. 複数エコシステムのうち、必要なブロックすべてに設定したか
4. includeとexcludeのパターンが依存関係名に一致しているか
5. cooldown終了後にscheduleの実行があったか
6. version update PRの上限に達していないか
7. ジョブログにエラーが記録されていないか

全面的に待機を無効化する場合も、まず一部のリポジトリで検証するのが安全です。公開直後の更新を自動マージする構成では、少なくとも次の対策を併用してください。

• 必須のCIテスト
• ブランチ保護ルール
• 自動マージの対象をpatch updateに限定
• デプロイ後の監視
• 即時ロールバックできる手順
• lock fileを含めた再現可能なビルド

Dependabotのversion update PRが3日遅れるのは、2026年7月に導入された新しい既定のcooldownが理由です。更新速度に問題がなければ設定変更は不要です。

早めたい場合はdefault-days: 1、特定の依存関係だけ即時更新する場合はcooldown.exclude、すべての待機を無効化する場合はexcludeに"*"を指定します。default-days: 0は使用できません。

また、security updateは3日間のcooldown対象外です。まず現在の.github/dependabot.ymlとscheduleを確認し、自社のテスト体制と更新リスクに合った待機期間へ調整してください。