Dependabotアラート、放置リポジトリで停止へ【2026年11月】

GitHub にしばらく更新していないリポジトリを置いている人に関係する変更です。

2026年11月10日（米国時間）、GitHub は 2026年12月8日から、過去1年間に活動のないリポジトリの多くで Dependabot alerts をオフにすると GitHub Changelog で発表しました。それまでに出ていたアラートは削除されず「アーカイブ」され、push などで再びオンにすれば戻ります。

Dependabot alerts will pause on inactive repositories

Dependabot alerts は、使っているライブラリに既知の脆弱性が見つかると知らせてくれる機能です。「放置しているリポジトリは見張りを休ませ、動いているリポジトリに力を回す」——という位置づけの変更です。

Dependabot alerts の一時停止とは？一言でまとめると

1年間 push もなく、Dependabot alerts を新しくオンにした記録もないリポジトリで、アラートを自動でオフにする仕組みです。GitHub は理由を「脆弱性の発見とアラートの量が急速に増えているため、活発に開発しているリポジトリで Dependabot を速く安定させる」と説明しています。

12月8日の何時からオフにするのか、オフにする前に通知が届くのかは、Changelog には書かれていません。

「活動」に数えられるのは3つだけ

Changelog が「活動」として挙げているのは、次の3つです。

どれか1つでも過去1年にあれば、そのリポジトリは「活動あり」です。

逆に、Issue やプルリクエストへのコメント、スター、Actions の実行などが活動に数えられるかは書かれていません。挙げられているのはこの3つだけなので、「コードは触っていないが Issue のやり取りはある」リポジトリは注意して見ておくとよいでしょう。

止まったアラートはどうなる？再開の方法

オフになったリポジトリの既存のアラートはアーカイブされます。消えるわけではありません。戻し方は2通りです。

① push する

リポジトリにどれか1つ push すると、Dependabot alerts は自動でオンに戻ります。

② 設定画面でオンにする

GitHub Docs の手順では、リポジトリの Settings → サイドバーの「Security and quality」→ Advanced Security を開き、Dependabot alerts の右の「Enable」を押します。オン・オフできるのはリポジトリ管理者や Organization オーナーなどです。

どちらの方法でも、アーカイブされたアラートが戻り、1年のカウントがやり直しになります。

なお、ここでの「アーカイブ」はアラートの保管のことです。リポジトリ自体を読み取り専用にする「アーカイブ（archived）」とは別の話で、アーカイブ済みのリポジトリはもともと Dependabot が調べないと GitHub Docs に書かれています。

止まらないリポジトリ：例外は2つ

活動がなくても、次の2つに当てはまるリポジトリはオフにされません。

①は Organization の Settings → Advanced Security → Configurations で作る「カスタムセキュリティ構成」です。Docs によると、「Enforce configuration」を選ぶと、リポジトリのオーナーは構成で決めた機能を変えられなくなります。

②は Enterprise の Policies → Advanced Security にある「Enable or disable Dependabot alerts by repository admins」の設定です。

Changelog は対象を「ほとんどの（most）」リポジトリとしており、例外として挙げているのはこの2つです。

対象のプラン：GitHub Enterprise Server は対象外

今回の変更は、github.com のすべてのプラン（Free を含む）と、データレジデンシーの GitHub Enterprise Cloud（GHE.com）が対象です。

データレジデンシーの場合、アーカイブしたアラートは、その Enterprise のほかのデータと同じリージョンに保存されます。自社で運用する GitHub Enterprise Server は対象外です。

管理者がやっておくこと

Changelog と Docs に書かれている範囲で、管理者ができることは次の3つです。

① 「止まってよいリポジトリ」か決める

もう使っていないリポジトリなら、止まっても困らないかもしれません。一方で、本番で動いているのに更新が少ないリポジトリは、新しい脆弱性が見つかっても知らせが来なくなります。

② 止めたくないなら「強制」の構成を付ける

Organization なら、Dependabot alerts を有効にしたカスタムセキュリティ構成を Enforce で付けるのが、Changelog に書かれた止めない方法です。Enterprise なら、リポジトリ管理者にオン・オフを許さないポリシーでも止まりません。

③ 止まったら push か設定画面で戻す

止まってしまっても、push か設定画面の Enable で、アーカイブされたアラートごと戻せます。

対象になるリポジトリを一覧で出す方法や、Dependabot の version updates・security updates（自動のプルリクエスト）への影響は、Changelog には書かれていません。記事作成時点で確認した GitHub Docs の Dependabot alerts のページにも、この一時停止の記載はまだありません。

同じ週の GitHub の変更：Actions のログのシークレット検出

前日の2026年11月9日には、Secret scanning が GitHub Actions のワークフローのログに出たシークレットも検出する機能が、パブリックプレビューになりました。

• 対象：GitHub Secret Protection か GitHub Advanced Security のある GitHub Enterprise Cloud の Enterprise
• 有効化：Enterprise の Policies → Advanced Security で設定（既定はオフ）
• 注意：有効にした後に終わった実行だけを調べる。プレビュー中は通知が出ないので、アラートの一覧を直接見る

GitHub は Actions の既定の設定も見直しています。12月2日からは、公開リポジトリの pull_request_target が既定でブロックされます。

あわせて読みたい

pull_request_targetが12月2日から既定ブロック【2026年11月】

IT Picks的な所感

脆弱性の報告が増え続けるなかで、放置されたリポジトリにまでアラートを出し続けるのは無理がある——という GitHub の判断は理解できます。アラートを消さずにアーカイブし、push 1回で戻せるようにしている点も、乱暴な変更ではないと評価しています。

気になるのは、「更新は少ないが、本番で使っている」リポジトリです。社内ツールや小さな Web サイトのように、一度作ってほとんど触らないコードほど、1年の条件に引っかかりやすいはずです。Organization の管理者は、12月8日までに Enforce のセキュリティ構成を付けるかどうかを決めておくのが現実的でしょう。

GitHub は Actions のロックファイルや pull_request_target の既定ブロックなど、セキュリティの「既定値」を次々に変えています。開発基盤の変更は、今後も追っていきたいところです。

あわせて読みたい

GitHub Actionsにロックファイル、依存をコミットで固定【2026年10月】

まとめ

Dependabot alerts の一時停止のポイントをまとめます。

• 発表日：2026年11月10日（GitHub Changelog）
• 開始日：2026年12月8日
• 対象：過去1年間に活動のないリポジトリの多く
• 活動に数えるもの：push（ブランチ・タグ）、リポジトリの作成、Dependabot alerts をオンにすること
• 既存のアラート：削除せずアーカイブ。push か設定画面でオンにすると戻る
• 止まらない例外：Enforce のセキュリティ構成、リポジトリ管理者にオン・オフを許さない Enterprise のポリシー
• 対象外：GitHub Enterprise Server

更新の少ないリポジトリを持っているなら、まずは本番で使っているものが含まれていないかを確かめておきましょう。

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。