npm install した瞬間から、あなたのリポジトリには他人が書いた数百〜数千のパッケージがぶら下がります。その中の1つに既知の脆弱性が見つかったとき、あなたは何日後に気づき、何日後に直せるでしょうか。依存関係の放置は、静かに積み上がるサプライチェーンリスクであり、同時に技術的負債でもあります。
Dependabot は、この問題を GitHub ネイティブに、しかも標準ランナー上では追加課金なしで自動化してくれるツールです。脆弱性を検知し、修正PRを自動で開き、古くなった依存を最新へ追従させる——ここまでは多くの記事が書いています。けれど本番で効くのは、その先の**「3本柱の分離」「PR洪水の抑制」「SLAを持った運用設計」**です。
この記事のルール：機能名・設定キー・挙動は GitHub 公式ドキュメント（2026年6月時点） に基づきます。Dependabot は機能追加が速く、本記事執筆時点でも
cooldown・directories（グロブ）・multi-ecosystem-groupsなど新オプションが増えています。本番投入前に必ず公式の設定リファレンスで最新の挙動を確認してください。コードは実運用に耐える形に整えていますが、レジストリの認証情報は Dependabot シークレット前提です（リポジトリにハードコード厳禁）。
この記事は本クラスタの**ピラー（全体像）**です。各論は専用ガイドへ深掘りします。
- 設定ファイルの全オプション → dependabot.yml 設定完全ガイド
- 脆弱性対応の運用 → Dependabotアラート・セキュリティ更新・脆弱性対応ガイド
- 自動マージ → auto-merge × GitHub Actions 自動化ガイド
- ツール選定 → Dependabot vs Renovate 技術選定ガイド
0. 最重要：Dependabot は「3本柱」である
Dependabot でつまずく人の9割は、1つの機能だと思っていることが原因です。実際には性格の違う3つの機能の総称で、有効化の方法も、目的も、設定ファイルへの依存も違います。まずここを分離します。
| 機能 | 何をするか | 何で有効化するか | dependabot.yml は必要か |
|---|---|---|---|
| Dependabot alerts（アラート） | 依存グラフ上の依存に既知の脆弱性があると通知する。コードは変更しない | リポジトリ/Organization のセキュリティ設定でON | 不要 |
| Dependabot security updates（セキュリティ更新） | アラートのうちパッチが存在するものを直すPRを自動で開く | セキュリティ設定でON（アラートが前提） | 不要（あれば挙動を調整できる） |
| Dependabot version updates（バージョン更新） | 脆弱性の有無に関わらず古い依存を最新へ追従するPRを開く | dependabot.yml をコミットして初めて動く | 必須 |
公式の言葉で言えば、バージョン更新は「脆弱性がなくても依存を最新に保つ自動PR」、セキュリティ更新は「脆弱性のうちパッチがあるものだけを直すPR」です。アラートは検知、セキュリティ更新は修正、バージョン更新は鮮度維持——この3語で覚えてください。
[GitHub Advisory DB] × [依存グラフ]
└─▶ Dependabot alerts（検知・通知）
└─▶ Dependabot security updates（パッチがある脆弱性を直すPR）
[.github/dependabot.yml]
└─▶ Dependabot version updates（古い依存を最新化するPR）
よくある詰まり：「セキュリティ設定をONにしたのに、ライブラリの新バージョンPRが来ない」。それは正常です。新バージョン追従（version updates）は
dependabot.ymlがないと動きません。逆に「dependabot.ymlを置いたのに脆弱性が放置されている」も、アラート/セキュリティ更新がOFFなだけ、ということが大半です。
1. どの場面で何を使うか（意思決定）
3本柱は排他ではなく重ねて使うのが基本です。プロジェクトの段階別に最小構成を示します。
- まず全リポジトリで：アラート + セキュリティ更新をON。これは「脆弱性を放置しない」という最低限の防衛線で、設定ファイル不要・数クリックで効きます。OSS でも社内でも、まずここから。
- アクティブに開発しているリポジトリ：上記に加えてバージョン更新（
dependabot.yml）。古い依存が積もると、いざ脆弱性が出たときに「メジャーバージョンが離れすぎて直せない」状態に陥ります。小さく追従し続けるほど、緊急対応が楽になります。 - モノレポ / 多数のサービス：バージョン更新を
groups・cooldown・directoriesでノイズ最小化しながら回す。ここを雑にやるとPRが洪水になり、結局誰も見なくなる（＝形骸化）。設計が要ります。
| あなたの状況 | 推奨する柱 |
|---|---|
| とにかく脆弱性だけは見逃したくない | alerts + security updates |
| ライブラリを定期的に最新へ追従したい | + version updates（dependabot.yml） |
| PR が多すぎてレビューが回らない | groups + cooldown + open-pull-requests-limit + auto-merge |
| GitHub 以外のGit基盤、または90超のパッケージマネージャ | Renovate も比較検討 |
2. 最短で有効化する
2.1 アラート + セキュリティ更新（設定ファイル不要）
リポジトリの Settings → Advanced Security（または Code security）で、次を順にONにします。
- Dependency graph（依存グラフ）— 何に依存しているかを GitHub が把握する土台。多くのリポジトリで既定ON。
- Dependabot alerts — 依存グラフ × GitHub Advisory Database を突き合わせ、脆弱性を検知。
- Dependabot security updates — アラートのうちパッチがあるものを直すPRを自動で開く。
Organization 全体に一括適用したい場合は、Organization の Global settings（Advanced Security） から既定値として全リポジトリに展開できます。新規リポジトリにも自動適用したいなら、ここで設定するのが正解です。
前提条件（公式）：セキュリティ更新が動くには、依存グラフが有効・アラートが有効・サポート対象のエコシステム・依存が manifest かロックファイルに記載されている、の4つが必要です。
package-lock.jsonを.gitignoreしていると更新対象から外れる、といった落とし穴はここに起因します。
2.2 バージョン更新（dependabot.yml をコミット）
リポジトリ直下の .github/dependabot.yml を置くと、バージョン更新が動き始めます。最小構成は次の通りです。
# .github/dependabot.yml
version: 2
updates:
# アプリの依存（npm / yarn / pnpm）
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# GitHub Actions のワークフローで使うアクション自体も更新対象にする
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
version: 2 は必須（現行スキーマ）。updates の各エントリが「どのエコシステムの・どのディレクトリを・どの頻度で」更新するかを表します。github-actions を入れておくのは強く推奨です——ワークフローで使うアクションのバージョン（特にハッシュ固定）も立派なサプライチェーンであり、ここを放置すると CI 経由の侵害に気づけません。
設定ファイルの全オプション（groups・cooldown・ignore・registries・モノレポの directories など）は、dependabot.yml 設定完全ガイドで網羅します。
3. どこで動くのか・課金はどうなるか
ここは費用感を左右するのに誤解が多い点です。公式の現状（2026年6月時点）はこうです。
- Dependabot の更新は GitHub Actions ランナー上で実行されます（GA 済み）。
- ただし標準の GitHub-hosted ランナー、および self-hosted ランナーでは、Dependabot の更新は課金対象の Actions 分（minutes）を消費しません。パブリック／プライベートを問わず、事実上無料で使えます。
- **larger runner（大型ランナー）**で動かす場合のみ、通常レートで課金されます。
- self-hosted ランナーを選ぶ理由は主にネットワーク到達性です。VPC 内など外部から到達できないプライベートレジストリの依存を更新したいとき、社内ネットワークに置いた self-hosted ランナーで Dependabot を走らせます。
コスト最適化の観点：「Dependabot は無料、ただし Dependabot のPRをトリガに走るあなたの CI（テスト・ビルド）は通常通り Actions 分を消費する」と分けて考えてください。PRが洪水になると、消費するのは人間のレビュー時間だけでなくCI 分でもあります。だからこそ次章のノイズ抑制が、品質だけでなく請求の最適化にも効きます。
4. PR 洪水を構造的に抑える（運用が形骸化しないために）
Dependabot 導入が失敗する最大の理由は、技術ではなく**「PRが多すぎて誰も見なくなる」**ことです。これは設定で構造的に解けます。
4.1 groups：関連する更新を1つのPRにまとめる
groups を使うと、複数の依存更新を1本のPRに束ねられます。@types/* をまとめる、テスト系をまとめる、といった定番に加え、パッチ/マイナーは束ねてレビュー負荷を下げる運用が効きます。
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
groups:
# 型定義はまとめて1PRに
types:
patterns: ["@types/*"]
# その他の patch / minor は1PRに束ねる（major は個別のまま）
minor-and-patch:
update-types: ["minor", "patch"]
groups はバージョン更新だけでなくセキュリティ更新にも applies-to: security-updates で適用でき、モノレポでは group-by: dependency-name でディレクトリ横断のまとめも可能です。詳細は設定完全ガイドへ。
4.2 cooldown：リリース直後の「事故ロット」を避ける
cooldown（比較的新しいオプション）は、新バージョンが出てから一定日数待ってからPRを開く機能です。公開直後に取り下げられる版や、出たての回帰を踏まないための緩衝材になります。
cooldown:
default-days: 7 # 既定で7日寝かせる
semver-major-days: 30 # major はさらに慎重に30日
4.3 open-pull-requests-limit：同時に開くPRの上限
バージョン更新の同時オープンPR数の既定は 5。多すぎても少なすぎても運用しづらいので、チームのレビュー処理能力に合わせて調整します。セキュリティ更新の上限は 10 で固定（変更不可）です——「脆弱性修正は溜めない」という GitHub の思想が表れています。
5. auto-merge：安全なものだけ自動で取り込む
ノイズを抑えてもレビュー負荷は残ります。そこで**「壊れる確率が低い更新（patch / minor）」は CI 通過を条件に自動マージし、人間はmajor と中身のある更新に集中**する、という分業が定石です。
GitHub Actions と dependabot/fetch-metadata を使い、更新の種類で条件分岐します（最小例）。
# .github/workflows/dependabot-auto-merge.yml
name: Dependabot auto-merge
on: pull_request
permissions:
contents: write
pull-requests: write
jobs:
auto-merge:
runs-on: ubuntu-latest
if: github.actor == 'dependabot[bot]'
steps:
- name: Fetch Dependabot metadata
id: meta
uses: dependabot/fetch-metadata@v3
with:
github-token: "${{ secrets.GITHUB_TOKEN }}"
# patch / minor のみ自動マージ（major は人間がレビュー）
- name: Enable auto-merge for patch & minor
if: steps.meta.outputs.update-type == 'version-update:semver-patch' || steps.meta.outputs.update-type == 'version-update:semver-minor'
run: gh pr merge --auto --merge "$PR_URL"
env:
PR_URL: ${{ github.event.pull_request.html_url }}
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
--auto は「必須チェックがすべて green になったらマージ」を予約する指示です。テストが落ちれば自動マージされません＝CI が安全弁になります。
ここにはセキュリティ上の重要な前提があります。Dependabot がトリガする pull_request ワークフローの GITHUB_TOKEN は既定で読み取り専用で、通常の Actions シークレットにアクセスできません（侵害された依存が秘密情報を盗み出すのを防ぐ設計）。そのため上のようにワークフロー側で permissions を明示して書き込みを与えます。pull_request_target を安易に使う・PRのコードをチェックアウトして実行する、といった危険なパターンは避けます。token モデル・pull_request と pull_request_target の違い・グループPR/cooldown との併用・必須チェックとの組み合わせは、auto-merge × GitHub Actions 自動化ガイドで詳しく扱います。
6. 脆弱性対応の運用（検知だけで終わらせない）
アラートは検知にすぎません。価値が出るのは「検知 → トリアージ → 修正 → クローズ」が運用として回り始めてからです。
- アラートの中身：影響を受けるファイルへのリンク、脆弱性の詳細と深刻度（severity）、（あれば）修正バージョン。深刻度で優先順位を付け、Critical/High から潰します。
- auto-triage rules（自動トリアージ）：アラート疲れを防ぐ仕組み。GitHub のプリセット（例：本番に影響しにくい npm の開発依存の低影響アラートを自動 dismiss）に加え、深刻度・スコープ（dev/prod）・パッケージ名・CWE などでカスタムルールを作れます。ルールは通知の前に適用されるため、自動 dismiss されたものは通知も飛びません＝ノイズが減ります。
- grouped security updates：複数の脆弱性修正をエコシステム単位で1PRにまとめ、対応の手数を減らせます（エコシステムをまたぐ統合や、バージョン更新との混在はしない、という制約付き）。
- クローズの自動化：Dependabot のセキュリティ更新PRがマージされると、対応するアラートは自動でクローズされます。手で閉じ忘れる事故が起きません。
「どの深刻度を何営業日で直すか」というSLA、開発依存の扱い、誤検知の dismiss 基準——ここを言語化するのが運用設計の本丸です。具体的な設計はアラート・セキュリティ更新・脆弱性対応ガイドで深掘りします。
Dependabot が見るのは**依存（SCA：Software Composition Analysis）**の脆弱性です。自分たちが書いたコードの脆弱性（SQLi・XSS・SSRF・認可不備など）は守備範囲外で、そこは SAST/DAST の領域です。両者は補完関係にあります（参考：Webアプリ脆弱性診断の実践ガイド）。
7. 本番運用チェックリスト（SRP な「運用の設計」）
ツール導入と運用設計は別物です。世界最高峰を名乗るなら、ここを文書化します。
- 全リポジトリでアラート + セキュリティ更新がON（Organization 既定で強制）
- アクティブなリポジトリは
dependabot.ymlでバージョン更新を有効化（github-actionsエコシステムを含む） - SLA を定義：Critical はN営業日、High はM営業日以内に対応——を明文化
- PRノイズ対策：
groups+cooldown+open-pull-requests-limitを設定 - auto-merge で patch/minor を CI 条件付き自動マージ、major は人間レビュー
- CODEOWNERS / 必須レビューで依存更新PRの承認フローを定義
- 必須ステータスチェック（テスト・型・lint・ビルド）をブランチ保護で強制し、auto-merge の安全弁にする
- 棚卸し：四半期に一度、滞留している major PR と
ignoreした依存を見直す（ignoreの塩漬けが新たな負債にならないように） - プライベートレジストリは Dependabot シークレット +
registries、到達できないネットワークは self-hosted ランナー - 可観測性：未対応アラート件数・最古アラートの経過日数・PRの平均滞留時間をダッシュボード化（REST API でアラートをエクスポート可能）
8. よくある落とし穴
- 「PRが来ない」＝大半は設定の誤解。バージョン更新は
dependabot.yml、脆弱性修正は設定のトグル。.github/dependabot.ymlのパスとインデント（YAML）も確認。 - ロックファイルを
.gitignore→ セキュリティ更新の対象外になりがち。manifest/ロックファイルはコミットする。 open-pull-requests-limitが小さすぎる → 更新が詰まって最新化が進まない。逆に大きすぎると洪水。- auto-merge を major にも適用 → 破壊的変更を無人で取り込み事故る。patch/minor に限定が鉄則。
- 必須チェック未設定で auto-merge → 安全弁がない自動マージはただのロシアンルーレット。ブランチ保護とセットで。
ignoreの塩漬け → 「今は上げたくない」でignoreしたまま忘れると、脆弱性が出たとき逃げ場がない。棚卸し対象にする。- Dependabot を SAST だと思う → 依存の脆弱性は見るが、自作コードの脆弱性は見ない。役割を取り違えない。
9. FAQ
Q. Dependabot は有料ですか？ A. いいえ。標準ランナー上では Actions 課金分を消費せず、パブリック/プライベートとも事実上無料です。larger runner で動かす場合のみ通常レートで課金されます。なお Dependabot のPRをトリガに走るあなたの CI は通常通り Actions 分を消費します。
Q. アラートをONにしたのに新しいバージョンのPRが来ません。
A. 正常です。新バージョン追従（version updates）は .github/dependabot.yml をコミットして初めて動きます。アラート/セキュリティ更新とは別機能です。
Q. PRが多すぎてレビューが回りません。
A. groups（まとめる）+ cooldown（寝かせる）+ open-pull-requests-limit（上限）でノイズを抑え、auto-merge で patch/minor を CI 条件付き自動マージしてください。人間は major に集中します。
Q. プライベートレジストリの依存も更新できますか？
A. できます。registries と Dependabot シークレットで認証情報を渡します。外部から到達できないネットワーク内のレジストリは、self-hosted ランナーで Dependabot を走らせます。
Q. Renovate とどちらが良いですか？ A. GitHub 中心・ゼロ設定・ネイティブなセキュリティ連携を重視するなら Dependabot、グループ化の柔軟性・多Git基盤・90超のパッケージマネージャ・細かいスケジュールが要るなら Renovate です。詳細はDependabot vs Renovate 技術選定ガイド。
まとめ
Dependabot は「入れたら終わり」のツールではなく、3本柱を分離して理解し、PR洪水を構造的に抑え、SLA を持って運用して初めて価値が出る仕組みです。技術的負債とサプライチェーンリスクを同時に減らせる数少ない自動化なので、まずは全リポジトリでアラート + セキュリティ更新を、アクティブな開発にはバージョン更新 + auto-mergeを。各論は本クラスタの専用ガイドへどうぞ。