# Dependabot 本番運用ガイド：アラート・セキュリティ更新・バージョン更新を「3本柱」で分離し、依存関係を自動で安全に保つ

> GitHub の Dependabot を本番品質で運用する実装ガイド。公式ドキュメント（2026年6月時点）に忠実に、Dependabot alerts／security updates／version updates の3本柱の違いと使い分け、有効化手順、dependabot.yml の実戦設定、どこで動くか（Actions ランナー）と課金、auto-merge とグルーピング、SLA を持った運用設計までを、コピペできる実コードと案件視点で解説します。

- 公開日: 2026-06-28
- 著者: 友田 陽大
- タグ: Dependabot, GitHub Actions, サプライチェーンセキュリティ, 依存関係管理, DevSecOps, セキュリティ
- URL: https://tomodahinata.com/blog/dependabot-production-guide
- カテゴリ: Dependabot・依存関係の自動更新

## 要点

- Dependabot は1つの機能ではなく『アラート（脆弱性の検知）』『セキュリティ更新（脆弱性を直すPR）』『バージョン更新（古い依存を最新化するPR）』の3本柱。最初にこの3つを頭の中で分離するのが運用の出発点
- アラートとセキュリティ更新はリポジトリ設定でONにする。バージョン更新は dependabot.yml をコミットして初めて動く。混同すると『なぜPRが来ないのか』で必ず詰まる
- Dependabot の更新は GitHub Actions ランナー上で実行されるが、標準ランナー（GitHub-hosted / self-hosted）では Actions 課金分を消費しない＝事実上無料。プライベートネットワーク内のレジストリには self-hosted ランナーで到達する
- PR の洪水は『groups（まとめてPR化）』『cooldown（リリース直後を待つ）』『open-pull-requests-limit』で構造的に抑える。auto-merge は GitHub Actions と fetch-metadata で patch/minor だけ安全に自動マージする
- ツールを入れる＝運用ではない。誰がレビューし、何を自動マージし、major をどう棚卸しし、放置PRをどう減らすか——SLA と例外ルールを決めて初めてサプライチェーンの技術的負債が増えなくなる

---

`npm install` した瞬間から、あなたのリポジトリには**他人が書いた数百〜数千のパッケージ**がぶら下がります。その中の1つに既知の脆弱性が見つかったとき、あなたは**何日後に気づき、何日後に直せる**でしょうか。依存関係の放置は、静かに積み上がる**サプライチェーンリスク**であり、同時に**技術的負債**でもあります。

[Dependabot](https://docs.github.com/en/code-security/dependabot) は、この問題を GitHub ネイティブに、しかも**標準ランナー上では追加課金なし**で自動化してくれるツールです。脆弱性を検知し、修正PRを自動で開き、古くなった依存を最新へ追従させる——ここまでは多くの記事が書いています。けれど本番で効くのは、その先の**「3本柱の分離」「PR洪水の抑制」「SLAを持った運用設計」**です。

> **この記事のルール**：機能名・設定キー・挙動は **GitHub 公式ドキュメント（2026年6月時点）** に基づきます。Dependabot は機能追加が速く、本記事執筆時点でも `cooldown`・`directories`（グロブ）・`multi-ecosystem-groups` など新オプションが増えています。本番投入前に必ず[公式の設定リファレンス](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference)で最新の挙動を確認してください。コードは実運用に耐える形に整えていますが、**レジストリの認証情報は Dependabot シークレット前提**です（リポジトリにハードコード厳禁）。

この記事は本クラスタの**ピラー（全体像）**です。各論は専用ガイドへ深掘りします。

- 設定ファイルの全オプション → [dependabot.yml 設定完全ガイド](/blog/dependabot-yml-configuration-complete-guide)
- 脆弱性対応の運用 → [Dependabotアラート・セキュリティ更新・脆弱性対応ガイド](/blog/dependabot-security-updates-alerts-vulnerability-management-guide)
- 自動マージ → [auto-merge × GitHub Actions 自動化ガイド](/blog/dependabot-auto-merge-github-actions-automation-guide)
- ツール選定 → [Dependabot vs Renovate 技術選定ガイド](/blog/dependabot-vs-renovate-comparison-guide)

---

## 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語で覚えてください。

```text
[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 も比較検討](/blog/dependabot-vs-renovate-comparison-guide) |

---

## 2. 最短で有効化する

### 2.1 アラート + セキュリティ更新（設定ファイル不要）

リポジトリの **Settings → Advanced Security**（または Code security）で、次を順にONにします。

1. **Dependency graph**（依存グラフ）— 何に依存しているかを GitHub が把握する土台。多くのリポジトリで既定ON。
2. **Dependabot alerts** — 依存グラフ × [GitHub Advisory Database](https://github.com/advisories) を突き合わせ、脆弱性を検知。
3. **Dependabot security updates** — アラートのうち**パッチがあるもの**を直すPRを自動で開く。

Organization 全体に一括適用したい場合は、Organization の **Global settings（Advanced Security）** から既定値として全リポジトリに展開できます。新規リポジトリにも自動適用したいなら、ここで設定するのが正解です。

> **前提条件**（公式）：セキュリティ更新が動くには、**依存グラフが有効**・**アラートが有効**・**サポート対象のエコシステム**・**依存が manifest かロックファイルに記載**されている、の4つが必要です。`package-lock.json` を `.gitignore` していると更新対象から外れる、といった落とし穴はここに起因します。

### 2.2 バージョン更新（dependabot.yml をコミット）

リポジトリ直下の **`.github/dependabot.yml`** を置くと、バージョン更新が動き始めます。最小構成は次の通りです。

```yaml
# .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 設定完全ガイド](/blog/dependabot-yml-configuration-complete-guide)で網羅します。

---

## 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/*` をまとめる、テスト系をまとめる、といった定番に加え、**パッチ/マイナーは束ねてレビュー負荷を下げる**運用が効きます。

```yaml
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` でディレクトリ横断のまとめも可能です。詳細は[設定完全ガイド](/blog/dependabot-yml-configuration-complete-guide)へ。

### 4.2 cooldown：リリース直後の「事故ロット」を避ける

`cooldown`（比較的新しいオプション）は、**新バージョンが出てから一定日数待ってからPRを開く**機能です。公開直後に取り下げられる版や、出たての回帰を踏まないための緩衝材になります。

```yaml
    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` を使い、更新の種類で条件分岐します（最小例）。

```yaml
# .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 自動化ガイド](/blog/dependabot-auto-merge-github-actions-automation-guide)で詳しく扱います。

---

## 6. 脆弱性対応の運用（検知だけで終わらせない）

アラートは**検知**にすぎません。価値が出るのは「**検知 → トリアージ → 修正 → クローズ**」が運用として回り始めてからです。

- **アラートの中身**：影響を受けるファイルへのリンク、脆弱性の詳細と**深刻度（severity）**、（あれば）**修正バージョン**。深刻度で優先順位を付け、Critical/High から潰します。
- **auto-triage rules（自動トリアージ）**：アラート疲れを防ぐ仕組み。GitHub のプリセット（例：本番に影響しにくい npm の開発依存の低影響アラートを自動 dismiss）に加え、**深刻度・スコープ（dev/prod）・パッケージ名・CWE** などで**カスタムルール**を作れます。ルールは**通知の前**に適用されるため、自動 dismiss されたものは通知も飛びません＝ノイズが減ります。
- **grouped security updates**：複数の脆弱性修正を**エコシステム単位で1PR**にまとめ、対応の手数を減らせます（エコシステムをまたぐ統合や、バージョン更新との混在はしない、という制約付き）。
- **クローズの自動化**：Dependabot のセキュリティ更新PRがマージされると、**対応するアラートは自動でクローズ**されます。手で閉じ忘れる事故が起きません。

「どの深刻度を何営業日で直すか」という**SLA**、開発依存の扱い、誤検知の dismiss 基準——ここを言語化するのが運用設計の本丸です。具体的な設計は[アラート・セキュリティ更新・脆弱性対応ガイド](/blog/dependabot-security-updates-alerts-vulnerability-management-guide)で深掘りします。

> Dependabot が見るのは**依存（SCA：Software Composition Analysis）**の脆弱性です。**自分たちが書いたコード**の脆弱性（SQLi・XSS・SSRF・認可不備など）は守備範囲外で、そこは SAST/DAST の領域です。両者は補完関係にあります（参考：[Webアプリ脆弱性診断の実践ガイド](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-guide)）。

---

## 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 技術選定ガイド](/blog/dependabot-vs-renovate-comparison-guide)。

---

## まとめ

Dependabot は「入れたら終わり」のツールではなく、**3本柱を分離して理解し、PR洪水を構造的に抑え、SLA を持って運用して初めて価値が出る**仕組みです。技術的負債とサプライチェーンリスクを**同時に**減らせる数少ない自動化なので、まずは全リポジトリで**アラート + セキュリティ更新**を、アクティブな開発には**バージョン更新 + auto-merge**を。各論は本クラスタの専用ガイドへどうぞ。