「Dependabot を有効にしたのに、PRが1つも来ない」「脆弱性アラートは出るのに修正PRが作られない」「プライベートレジストリで赤いエラーが出続ける」——Dependabot の相談で最も多いのが、この手の**“動かない”系です。原因のほとんどは故障ではなく設定の誤解か、切り分け不足**です。
この記事はDependabot 本番運用ガイドの各論として、症状から原因にたどり着くためのトラブルシューティングを体系化します。手元で順に確認できるチェックリストとして書きました。
この記事のルール：エラー名・挙動・コマンドは GitHub 公式ドキュメント（2026年6月時点） に基づきます。特に @dependabot コメントコマンドは2026年1月27日に仕様変更があり、古い記事の情報は危険です（後述）。本番運用前に必ず公式のトラブルシューティングで最新を確認してください。
0. まず切り分け：止まっているのは「3本柱」のどれか
Dependabot は3つの別機能の総称です。どれが動いていないかを最初に特定すると、原因が一気に絞れます。
症状：新しいバージョンのPRが来ない
→ version updates の問題（.github/dependabot.yml が要る）
症状：脆弱性アラートは出るが修正PRが来ない
→ security updates の問題（パッチの有無・前提条件）
症状：脆弱性アラート自体が出ない
→ alerts / 依存グラフ の問題（設定トグル）
この3分岐のどこにいるかを決めてから、対応する章へ進んでください。
1. 「新バージョンのPRが来ない」（version updates）
1.1 まず .github/dependabot.yml を確認
バージョン更新は設定ファイルがないと動きません。次を順に確認します。
- ファイルパス：リポジトリ直下の
.github/dependabot.yml（.github/workflows/ではない）。 - YAML のインデント：タブ禁止・スペース2。
version: 2とupdates:があるか。 package-ecosystemの値：npm/pip/gomod/docker/github-actionsなど正しい識別子か。nodeやyarnは誤り（npm/yarn/pnpm はすべてnpm）。directory：manifest があるディレクトリを指しているか（ルートなら/）。
1.2 「Pull request limit reached」
公式のPR数上限は バージョン更新=5 / セキュリティ更新=10。上限に達すると新しいPRは作られません。
- 対処：既存の Dependabot PR をマージまたはクローズして枠を空ける。
- レビューが追いつかないなら、
groupsでPRを束ねる・auto-merge で patch/minor を自動化。open-pull-requests-limitを上げるのは対症療法で、ノイズの根本対策にはなりません。
1.3 その他の「来ない」原因
| 原因 | 確認・対処 |
|---|---|
ignore で止めている | 該当依存に ignore 条件がないか。@dependabot show <name> ignore conditions で確認（後述） |
target-branch が別ブランチ | 既定ブランチ以外を見ていないか。PRはそのブランチに対して作られる |
schedule 待ち | weekly/monthly だと次の実行まで来ない。手動トリガ（§5）で確認 |
| そもそも最新 | 依存が既に最新なら何も起きない（正常） |
| ロックファイル未コミット | package-lock.json 等を .gitignore していると解決できないことがある |
2. 「脆弱性が直らない」（security updates / alerts）
2.1 「Cannot update X to a non-vulnerable version」
セキュリティ更新で最頻のメッセージ。意味は**「脆弱性は分かったが、他の依存を壊さずに安全なバージョンへ上げられない」**です。
- 原因：修正版がまだ無い、または依存グラフ上の他パッケージとバージョン制約が衝突している。
- 対処：バージョン更新を有効化して依存を日頃から新鮮に保つと、いざという時に単純なアップグレードで脆弱性を解消できる確率が上がります（公式の推奨）。塩漬けの依存ほど、緊急の脆弱性修正で詰まります。
2.2 アラート自体が出ない
| 確認項目 | 対処 |
|---|---|
| 依存グラフが有効か | Settings → Advanced Security で Dependency graph をON |
| Dependabot alerts が有効か | 同設定で Dependabot alerts をON |
| security updates が有効か | 同設定で Dependabot security updates をON |
| ロックファイルがコミットされているか | セキュリティ更新は manifest かロックファイルに記載された依存のみ対象 |
| サポート対象エコシステムか | 対象外の言語/管理ツールは検知されない |
脆弱性対応の運用設計（SLA・auto-triage・grouped security updates）はアラート・セキュリティ更新ガイドで詳しく扱います。
3. 解析・解決エラー（dependency files）
3.1 「Dependabot can't resolve your LANGUAGE dependency files」
依存ファイルを解決できないエラー。
- 原因：参照している依存（ローカルパス参照、到達できないURL、別リポジトリの manifest など）にアクセスできない。
- 対処：参照先がすべてアクセス可能な場所にあるか確認。private repo を参照しているなら、Organization レベルで private repository アクセスの許可が要る場合があります。
3.2 「the dependency file is not parseable / not found」
- 原因：manifest/ロックファイルの構文エラー、または期待した場所にファイルが無い（
directoryの指定ミス）。 - 対処：ローカルでパッケージマネージャを実行して manifest が正しく解決できるか確認（
npm install/pip install/go mod tidy等）。directoryのパスを再確認。
4. プライベートレジストリのエラー（4分類）
社内レジストリ絡みのエラーは、公式が4種類のコードに分類しています。症状で原因が分かるので覚えておくと速いです。
| エラー（コード） | 意味 | 主な対処 |
|---|---|---|
private_source_not_reachable | レジストリに到達できない | ネットワーク到達性。GitHub-hosted から届かない私設網なら self-hosted ランナー |
private_source_authentication_failure | 認証に失敗 | registries 定義と Dependabot シークレット（≠Actions シークレット）を確認。トークン失効・スコープ不足 |
private_source_timed_out | レジストリ応答がタイムアウト | レジストリ側の負荷・ネットワーク遅延。再試行・経路確認 |
private_source_certificate_failure | 証明書を検証できない | 自己署名/社内CA。証明書チェーンの設定を確認 |
設定の作り方（registries の type 別認証・OIDC・self-hosted ランナー）はプライベートレジストリ認証ガイドで網羅します。
5. ログの読み方と手動トリガ（一次情報に当たる）
推測する前に一次情報を見ます。
- リポジトリの Insights → Dependency graph → Dependabot タブを開く。
- 各エコシステムの Last checked（最終実行）とステータスを確認。
- 失敗していればジョブログを開いて、上記のエラー文字列を探す。
手動でトリガして即座に再現・確認することもできます。
- バージョン更新：Dependabot タブで 「Check for updates」 をクリック。
- セキュリティ更新：対象アラート画面で 「Create Dependabot security update」 をクリック。
「設定を変えたが効いたか分からない」ときは、手動トリガ→ジョブログ、が最短の検証ループです。
6. @dependabot コメントコマンド（2026年1月の変更に注意）
開いているPRには、コメントで指示が出せます。ここが2026年1月27日に変わりました——古い記事をコピーすると動かないコマンドを掴むので要注意です。
6.1 いま“残っている”更新挙動の制御コマンド
これらは Dependabot の更新の振る舞いを制御するもので、GitHub 標準UIに代替がないため引き続き有効です。
@dependabot rebase # PR を rebase する
@dependabot recreate # PR を作り直す（手編集は破棄）
@dependabot ignore this dependency # この依存の今後のPRを止める
@dependabot ignore this major version # この major を無視
@dependabot ignore this minor version # この minor を無視
@dependabot ignore this patch version # この patch を無視
@dependabot unignore <dependency> # ignore を解除
@dependabot show <dependency> ignore conditions # 現在の ignore 条件を表示
ignoreをコメントで増やすと、dependabot.ymlに書いていない暗黙の ignore 条件が積み上がります。「なぜか更新が来ない」の温床なので、show ... ignore conditionsで棚卸しし、恒久ルールはdependabot.yml側に明示しましょう（ignore の塩漬け対策）。
6.2 非推奨化されたPRライフサイクル系（2026-01-27）
@dependabot merge / squash and merge / cancel merge / close / reopen 等のPRライフサイクル操作は非推奨化されました。GitHub は標準のPR機能で行うよう推奨しています。
| やりたいこと | これからの方法 |
|---|---|
| マージ | GitHub の Merge ボタン / gh pr merge / auto-merge ワークフロー |
| クローズ / 再オープン | GitHub の標準UI / gh pr close ・ gh pr reopen / REST API |
gh CLI を使う例：
gh pr merge <PR番号> --squash # マージ（自動化は auto-merge ワークフローで）
gh pr close <PR番号> # クローズ
6.3 そのほかの小技
- force-push をスキップしたい（自分の編集を Dependabot に上書きさせたくない）：コミットメッセージに
[dependabot skip]（または[skip dependabot]/[dependabot-skip]/[skip-dependabot]）を含める。 - 30日ルール：30日マージされないPRは、Dependabot が自動 rebase を停止します。古いPRは手動で rebase / 作り直し。
7. 詰まりを未然に防ぐチェックリスト
-
.github/dependabot.ymlのパス・インデント・package-ecosystem・directoryが正しい - manifest とロックファイルをコミットしている（
.gitignoreしていない） - alerts / security updates / 依存グラフがすべてON
-
open-pull-requests-limit到達時はgroups と auto-merge で枠を回す - プライベートレジストリは registries + Dependabot シークレット + self-hosted ランナー
- コメントで増やした
ignoreを定期棚卸し（show ... ignore conditions） - PR 操作は標準UI /
ghCLI / auto-merge に統一（非推奨コマンドを使わない）