Dependabotを無効にすべきだ。そんな議論が2026年2月に大きな注目を集めました。きっかけはFilippo Valsorda氏のブログ記事です。しかし、単純にオフにするのは危険です。そこで、この記事ではDependabotのPR疲れを減らす具体策を紹介します。

Turn Dependabot Offの議論が起きた経緯

まず、議論の発端を詳しく整理しましょう。Valsorda氏はGo標準ライブラリの暗号パッケージのメンテナーです。元Google セキュリティチームのリーダーでもあります。彼が1行のセキュリティ修正を行ったところ、大きな問題が発生しました。

具体的には、edwards25519ライブラリのMultiScalarMultメソッドの修正でした。しかし、この関数を実際に使っているプロジェクトはほぼありません。ところが、go-sql-driver/mysqlがこのライブラリに依存しています。このMySQLドライバーは22万8,000のGitHub依存先を持ちます。その結果、Dependabotは無関係なリポジトリに数千のPRを自動作成しました。

なぜこうなったのでしょうか。Dependabotは依存関係の「存在」だけをチェックしていたのです。つまり、影響を受ける関数が実際に呼ばれているかは確認しません。さらに、「でっち上げのCVSSスコア」と「73%の互換性スコア」を表示しました。しかし、実際は1行の変更で互換性の問題はゼロでした。

また、開発者Mehdi氏も具体的な数字で問題を示しました。3年間でDependabotは127件のPRを作成しました。しかし、そのうち97件(76%)はマージされずに閉じられました。さらに、同期間に本人が作成したPRは67件だけです。つまり、ボットが人間の約2倍のPRを生成していたのです。The Registerはこの状況を「ノイズマシン」と表現しました。

DependabotのPR疲れが深刻な理由

PR疲れは単なる煩わしさではありません。実際にセキュリティを低下させます。なぜなら、大量のアラートは「アラート疲労」を引き起こすからです。

具体的な統計を見てみましょう。84万6,000以上のリポジトリがDependabotを利用しています。月に300万から400万件のアラートが出ています。しかし、マージされるのは約100万件です。つまり、75%のアラートが放置されています。

さらに、SANS 2025調査では深刻な数字が出ています。セキュリティチームの66%がアラートに追いつけていません。また、組織は平均で1日960件のセキュリティアラートを受け取っています。特に問題なのは誤検知です。73%の組織が誤検知を最大の課題と回答しています。しかも、92%のチームがアラートの見逃しによる被害を認めています。

たとえば、NPMパッケージのクライアントコードにReDoS脆弱性の警告が出ます。また、32ビット環境専用の脆弱性が全環境に通知されることもあります。このように、文脈を無視した通知がチームの集中力を奪っているのです。Hacker Newsでは「顧客のセキュリティチームは独自のスキャナーを持っている。脆弱性のあるバイナリを出荷すれば苦情が来る」という声もありました。

Dependabotを活かすための具体策

では、完全にオフにせずにPR疲れを減らす方法を4つ紹介します。

第一に、グループ化を活用しましょう。2024年3月からセキュリティ更新のグループ化が正式版になりました。さらに、2025年7月にはマルチエコシステムのグループ化も対応しました。具体的には、Docker、Terraform、npmなどを1つのPRにまとめられます。ただし、グループPRではどの依存が原因でCIが失敗したか分かりにくい点に注意です。そこで、パッチ更新はCI通過で即マージ、マイナー更新は手動確認というルールが有効です。

第二に、スケジュールとレート制限を設定します。dependabot.ymlでintervalをmonthlyに変更できます。また、open-pull-requests-limitを0にすることも有効です。そうすれば、PRは作成されません。その代わり、セキュリティダッシュボードで定期メンテナンス時に一括確認できます。したがって、スプリント中の中断を完全に防げます。

第三に、低リスク更新の自動マージを導入しましょう。GitHub Actionsでdependabot[bot]のPRを検出できます。さらに、dependabot/fetch-metadataアクションで更新タイプを判定します。具体的には、パッチやマイナー更新はCI通過後に自動マージする設定が可能です。これだけで手動レビューの負荷を70-80%削減できます。特に、信頼できるパッケージに限定すると安全性も保てます。

第四に、ignoreルールを積極的に使いましょう。具体的には、メジャーバージョンの自動更新を除外できます。また、誤検知が多いパッケージも個別に除外可能です。さらに、allowルールで追跡対象を限定することもできます。このように、ノイズの発生源を特定して潰すことが重要です。

Dependabot以外の選択肢

Valsorda氏はGo向けの代替案を提示しました。具体的には、govulncheckをCIに組み込む方法です。このツールは静的解析で実行パスを追跡します。そのため、実際に呼ばれる関数だけを対象にアラートを出します。つまり、誤検知が大幅に減るのです。加えて、最新依存でのCIテストを毎日実行する方法も提案しました。

また、Renovateも有力な代替です。90以上のパッケージマネージャに対応しています。さらに、GitHub以外のGitLab、Bitbucket、Azure DevOpsでも使えます。特に、組織全体で設定を共有できるextendsの仕組みが便利です。なお、Dependency Dashboardという固定Issueが制御パネルとして機能します。PRが作られる前に更新の一覧を確認できるのです。実際、複雑なプロジェクトではノイズを80-90%削減できたという報告もあります。

まとめ

Dependabotをオフにする前に、まず設定を見直しましょう。グループ化、スケジュール調整、自動マージ、ignoreルールの4つで大幅にPR疲れを軽減できます。しかし、デフォルト設定のままでは確かにノイズマシンです。だからこそ、dependabot.ymlのカスタマイズが必須です。それでも不満が残る場合は、RenovateやgovulncheckなどのToolも検討してください。特に、Go言語のプロジェクトではgovulncheckの到達可能性分析が強力です。