3日。2026年7月14日から、Dependabot が新しいリリースを取り込むまでに置く既定の待機期間だ。何も設定していないリポジトリでも、公開されたばかりのバージョンには更新PRが3日間作られなくなった。「更新が遅れるのは嫌だ」と感じた人にこそ、この既定値を切る前に読んでほしい変更の中身を整理する。
何が変わったか
GitHub の changelog によると、Dependabot のバージョン更新は「レジストリ公開から最低3日経過したリリース」だけを PR の対象にするようになった。原文はこうだ。
Dependabot now waits until a new release has been available on its registry
for at least three days before opening a version update pull request.要点は4つ。
| 項目 | 内容 |
|---|---|
| 既定日数 | 3日（設定不要で適用） |
| 対象 | version updates のみ。セキュリティ更新は対象外で即時 |
| 適用範囲 | github.com の全サポートエコシステム |
| Enterprise | GitHub Enterprise Server 3.23 で反映予定 |
cooldown 自体は新機能ではない。時系列を並べると、今回の変更の性格がはっきりする。
| 時期 | 出来事 |
|---|---|
| 2025-07-01 | cooldown オプションが GA。dependabot.yml に書いた人だけ有効（opt-in） |
| 2025-07-29 | NuGet・Helm へ対応拡大 |
| 2026-07-14 | 未設定リポジトリにも既定3日を適用 今回 |
1年かけて opt-in の実績を積んでから既定値を変えた、という順番だ。裏を返せば、この1年で「設定した人」に大きな問題が出なかったということでもある。
なぜ3日待つのか
狙いはサプライチェーン攻撃対策だ。侵害されたバージョンが公開されてから、メンテナやコミュニティが異常に気づくまでには時間差がある。その空白の間に自動更新が侵害版を取り込んでしまうのが、新リリースを起点にした攻撃の典型的な入口になる。3日の遅延は、検知のシグナルが表面化する時間を確保する。
筆者はこの設計に説得力を感じる側だ。理由は自分の失敗にある。以前、X API まわりの新機能を疎通確認なしで全経路に組み込み、仕様側の変更で機能全体を落としたことがある。あの事故以来「新しいものは単発で試してから既定経路に入れる」を自分のルールにしてきた。Dependabot の既定3日は、まさにこのルールをプラットフォーム側が全員に配った形に見える。
「セキュリティ更新は即時、それ以外は待つ」という非対称も実務的だ。急ぐ理由があるのは修正パッチであって、新機能リリースの取り込みを急ぐ理由はたいてい無い。
発売日にゲームを買うかどうかの判断に似ている。初日に買う自由はあるが、3日待てばレビューが出そろい、致命的な不具合は誰かが先に踏んでくれる。依存パッケージの新バージョンで「初日に買う」メリットは、ゲームと違って所有欲すら満たさない。
背景として、2025年秋には npm で自己複製型ワーム（GitHub が公式ブログで Shai-Hulud と名指しした事案）が500超のパッケージを侵害し、公開直後の自動取り込みの危うさが広く共有された。GitHub が cooldown の既定化とこの事案を直接結びつけた記述は見当たらないので因果は筆者の推測になるが、時期的な文脈としては重なっている。
cooldown の書き方
挙動は .github/dependabot.yml の cooldown ブロックで変えられる。公式リファレンスの例をベースにすると、こうなる。
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
cooldown:
default-days: 5 # 既定より慎重に
semver-major-days: 30 # メジャーは30日置く
semver-patch-days: 3
exclude:
- "eslint*" # 除外は include より優先
キーは6種類。default-days（未指定なら3日）、SemVer 対応エコシステム限定の semver-major-days / semver-minor-days / semver-patch-days、それに適用対象を絞る include / exclude（各最大150件・ワイルドカード可）。日数は公式チュートリアルの記載で1〜90日の範囲。
include / exclude の使いどころは「信頼の濃淡」で考えると決めやすい。例えば自組織が出している社内パッケージは侵害リスクの見立てが違うので exclude で即時に戻す、逆に過去にトラブルを踏んだ依存だけ include で30日にする、といった濃淡が付けられる。exclude が include より優先されるので、「全体は include で広く縛り、例外だけ exclude」という書き方が素直だ。
対象範囲の誤解も1つ潰しておく。cooldown が効くのは Dependabot が作るバージョン更新PRだけで、自分で打つ npm update や lockfile の手動更新には何の影響もない。「3日待たされて開発が止まる」類の話ではない。
完全な無効化はどうか。changelog は「opt out entirely できる」と書いているが、公式ドキュメントに無効化の構文は明記されていない（日数の許容範囲は1〜90のまま）。default-days: 0 で切れたという報告はコミュニティにあるものの、公式明記なしの実例レベルだと思って扱うのが正確だ。
自動マージと組み合わせるなら
AI にコードを書かせるようになってから、依存の増えるペースは目に見えて上がった。依存が増えるほど「Dependabot PR を自動マージで捌く」運用に寄っていくが、即時更新と自動マージの組み合わせは、侵害版が出た瞬間にそれを無人で取り込む構成でもある。
公式は cooldown と auto-merge の組み合わせ方までは踏み込んでいない（両方のドキュメントに相互の言及がない）。ここからは筆者の運用判断になる。
- cooldown は既定の3日をそのまま受け入れる。急ぐ理由のある更新はセキュリティ側が素通ししてくれる
- auto-merge を許すのは semver-patch のみ。major は cooldown を30日に伸ばした上で手動レビュー
- CI の status check 必須化（Require status checks to pass）を auto-merge の前提にする
「3日を切って即時に戻す」のは、この構成の中では一番割に合わない選択だと思う。得られるのは最大3日の先行だけで、失うのは検知猶予の全部だ。
立場別・7月14日以降にやること
読者の状況は3通りに分かれる。
Dependabot を使っていない人。今回の変更で直接やることはないが、依存更新を手動と気合いで回しているなら、cooldown が既定で付いた今は有効化の好機だと思う。「即時更新が怖いから自動化しない」という理由が1つ消えた。
version updates を既定設定で使っている人。何もしなくても7月14日から3日クールダウンが効いている。PR の出るタイミングが「リリース即日」から数日ずれるので、「最近 PR が遅い気がする」と感じたらそれは正常動作だ。意図的に即時へ戻したい依存がある場合だけ cooldown ブロックを書く。
auto-merge まで組んでいる人。この変更で一番恩恵を受けるのがこの層で、無人マージの手前に3日の検知猶予が挟まった。逆に言うと、cooldown を切る設定を入れた瞬間に7月13日以前の露出へ戻る。切るなら、その3日ぶんの検知を自前の監視で肩代わりできるかを先に確認してからにしたい。
筆者のリポジトリの現状
説得力のために書いておくと、筆者の公開リポジトリ（日本語ASRベンチマーク）を今回確認したら、そもそも dependabot.yml が無かった。バージョン更新は未設定で、更新PRの実績もゼロ。上の方針どおりに default-days: 3 と semver-major-days: 30 を書いて 7月22日の朝に置いたら、2分と経たないうちに最初の更新PRが立った。nemo-toolkit の要求バージョンを 2.5.0 以上から 2.7.3 以上へ上げる内容だ。
このPRは cooldown の証拠にならない。2.7.3 が PyPI に出たのは4月で、PRが立った7月から見れば3か月前のリリースだ。3日の窓はとうに過ぎている。有効化した直後に飛んでくるのは溜まっていた古い更新なので、待機がどう効くかは次の新しいリリースを待つしかない。
観測すべき数字は決まっている。パッケージの公開日と、Dependabot がPRを立てた日の差だ。ここが3日以上開いていれば cooldown が働いている。
上に書いた自動マージの方針も、同じリポジトリに入れた。patch 更新だけを auto-merge に予約するワークフローを置き、その前提になる CI（uv.lock と pyproject.toml の整合チェック＋テスト）を作って、master にはその CI を必須にした保護を掛けた。auto-merge は必須チェックが緑になるまでマージを保留するので、3日待って、テストが通ったものだけが無人で入る形になる。
公開の前日に、この無人マージが本当に成立するのか測ってみた。patch の更新PRが自然に飛んでくるのを待つと何週間かかるか読めないので、ロックファイルの pytest だけ1つ古い版に落として更新PRを立てさせた。PRが作られてから24秒でマージ完了。CI が16秒で緑になり、その3秒後には master に入っていた。マージの実行主体は github-actions で、私はボタンを1つも押していない。
この24秒で「3日」の意味がはっきりした。待たされるのはパッケージの公開からPRが立つまでで、PRが立ってからのマージは一瞬だ。今回落とした pytest 9.1.1 は6月19日の公開なので3日の窓はとうに抜けており、測れたのは自動マージの経路だけになる。
白状しておくことがある。この CI は音声認識の推論そのものを検証していない。テストが読むのは文字誤り率と集計まわりの純Pythonコードだけで、torch も NeMo も import しない。GPU と数GBのモデルが要る処理をホストランナーでは回せないからだ。守れているのは依存ファイルの整合と集計ロジックの回帰までで、依存更新が推論結果を変えても気づけない。自動マージを組むなら、自分のCIが何を見ていて何を見ていないかは把握しておいたほうがいい。
設定を入れてから分かったこともある。torch と torchaudio の更新は、cooldown 以前の理由で毎週失敗していた。このリポジトリは CUDA 12.4 向けのホイール配布先を指定していて、そこに置かれている torch は 2.6.0 で止まっていた。PyPI 側の最新は 2.13.0 だ。Dependabot は PyPI を見て「上げよう」と提案し、実際に取りに行く先にその版が無いので解決に失敗する。見ている棚と、買いに行く棚が違っていた。
この2つはいったん ignore で Dependabot の対象から外し、手動更新に切り替えた。ベンチマークのリポジトリなので、torch が黙って上がると測定した数字の前提が崩れる。入れ直したら更新ジョブは失敗しなくなり、ログに「All versions of torch ignored」と出た。
ignore には注意が一つある。バージョン更新だけでなく、セキュリティ更新のPRも止まる。外した依存は自分で見張る、とセットで決めておきたい。自動化を組むと、こういう「動いているつもりで止まっていた経路」が表に出てくる。
torch の ignore は6日後に外した。ホイールの配布先を CUDA 12.6 のほうへ移したら torch 2.13.0 がそのまま解決できるようになり、外しておく理由が消えたからだ。更新ジョブのログも「All versions of torch ignored」から「Checking if torch 2.13.0+cu126 needs updating」に変わった。ベンチマークの数字が動かないかは、4モデルを測り直して確かめてある。cooldown の待機そのものはまだ観測できていないので、そこは実測がたまったら続報にする。
設定ゼロでも既定3日は github.com 側で効く。「何もしていないから関係ない」が一番の誤読で、何もしていない人の挙動こそ7月14日から変わっている。
会社で GitHub Enterprise Server を使っている人は時差に注意。オンプレ側への反映は GHES 3.23 からで、手元の github.com リポジトリと挙動が揃わない期間が生じる。個人と会社でリポジトリを行き来する人ほど、この差は「片方だけ PR が来ない」という形で目につくはずだ。
まとめ
筆者の判断はこうだ。既定の3日は受け入れる。変えるとしたら伸ばす方向（major を30日）で、切る方向の設定はしない。自動マージを使うなら対象を patch に絞り、status check を前提条件にする。侵害パッケージの検出を自分でやる力があるチームだけが、cooldown を切る資格を持つ。
供給網まわりでは、CodeQL のプロンプトインジェクション検出やWordPress mu-plugins の監査でも「自動で入ってくるものを検査する」話を書いた。入口が npm でも WordPress でも、考え方は同じところに落ちる。自動化の速度と検知の猶予はトレードオフで、猶予を捨てるなら代わりの検知を自前で持つ必要がある。
