Dependabotとは｜dependabot.ymlの設定・料金・Renovateとの違いを解説

Dependabot（ディペンダボット）は、リポジトリの依存パッケージを監視し、脆弱性の通知やバージョン更新のプルリクエスト（PR）を自動で作成するGitHubの機能です。設定の中心は.github/dependabot.yml1ファイルで、package-ecosystemやschedule、versioning-strategyを書くだけで運用が始まります。この記事では定義から設定の各フィールド、料金、Renovateとの使い分けまでをGitHub公式ドキュメント準拠で整理します。

まとめ：Dependabotは無料で使える依存関係更新の自動化機能

Dependabotはalerts・security updates・version updatesの3機能を持ち、public/privateを問わず全プランで無料です。設定は.github/dependabot.ymlに集約し、必須項目はversion: 2とupdates（配下にpackage-ecosystem・directory・schedule.interval）の3つだけ。GitHubに閉じて設定ファイル1つで始めたいならDependabot、GitLabや細かいPR集約まで制御したいならRenovate、という使い分けが実務の目安です。以降で各フィールドの書き方と判断基準を具体的に見ていきます。

Dependabotとは：依存関係を監視して更新PRを自動作成する機能

Dependabotは、package.jsonやrequirements.txtなどのマニフェストを読み取り、依存パッケージに脆弱性や新しいバージョンが出たときにPRを自動で起票します。読み方は「ディペンダボット」。2019年にGitHubへ統合され、現在はnpm・pip・Bundler・Maven・Gradle・NuGet・Docker・GitHub Actionsなど30以上のパッケージマネージャに対応します。外部サービスやAPIトークンの用意は不要で、リポジトリ設定からそのまま有効化できます。

Dependabotの3つの機能：alerts・security updates・version updates

名前が似ていて混同されやすいため、まず3機能の役割を分けて押さえます。脆弱性対応に効くのはalertsとsecurity updates、ライブラリを古びさせない運用に効くのがversion updatesです。

alertsとsecurity updatesはリポジトリの「Code security」設定でオン・オフするだけで、設定ファイルは要りません。.github/dependabot.ymlを書く必要があるのは、定期的な最新化を行うversion updatesです。検知された脆弱性の具体例はLog4j2の脆弱性について：Log4Shellの詳細解説とその影響も参考になります。

dependabot.ymlの設定：必須フィールドと書き方

version updatesの設定は.github/dependabot.ymlに書きます。最小構成は次の通りで、version・updates・package-ecosystem・directory・schedule.intervalが必須です。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

ファイルの配置場所と基本構造

ファイルはリポジトリ直下の.github/dependabot.ymlに置きます（.yaml拡張子は不可）。トップレベルのキーはversion（常に2）、updates（更新対象の配列）、任意のregistries（プライベートレジストリ定義）の3つです。エコシステムを複数管理する場合はupdates配下のブロックを並べます。

package-ecosystem：対象エコシステムの指定

package-ecosystemで監視するパッケージマネージャを指定します。npmはyarn・pnpmも含み、Pythonはpip（Poetryもこの値）、Goはgomod、Javaはmavenまたはgradle、コンテナはdockerです。GitHub Actionsのワークフロー自体を更新対象にするならgithub-actionsを指定します。1つの値につき1ブロックが基本です。

directory / directories：対象ディレクトリの指定

マニフェストの場所をdirectory（単一）で指定します。リポジトリ直下なら"/"、モノレポのサブパッケージなら"/packages/app"のように書きます。複数パスをまとめたい場合はdirectories（複数形）でリスト指定でき、"/apps/*"のようなワイルドカードも使えます。

schedule：更新頻度（interval・cron）

schedule.intervalで頻度を決めます。指定できる値はdaily・weekly・monthly・quarterly・semiannually・yearly・cronです。dailyは平日（月〜金）、weeklyは既定で月曜に実行されます。day・time・timezoneで曜日や時刻を指定でき、cronを選べばcron式で細かく制御できます（cronは2025年にGitHub.comへ追加された比較的新しい値で、Enterprise Serverでは一部の値がバージョンによって使えません）。新着直後の更新を避けたいときはcooldown（version updates限定。default-daysやsemverレベル別の遅延日数を指定）でリリースから一定日数を待たせられます。

versioning-strategy：バージョン更新の戦略

マニフェストのバージョン制約をどう書き換えるかをversioning-strategyで制御します。既定値はエコシステムによって異なります。

その他のオプション：PR数の上限・ラベル・対象の絞り込み

運用で多用するのが、同時に開くPR数を制限するopen-pull-requests-limit（version updatesの既定は5）、PRに付与するlabels、レビュアーを割り当てるreviewersです。更新対象を絞るならallowとignore、関連パッケージを1つのPRにまとめるならgroupsを使います。groupsはPRの乱立を抑える効果が大きく、ライブラリ数が多いリポジトリでは最初に設定しておく価値があります。

プライベートリポジトリ・プライベートレジストリでの設定

プライベートリポジトリでもDependabotは無料で動きます。社内レジストリなど認証が要る取得元は、dependabot.ymlのregistriesに認証情報を定義し、updates側から参照します。認証情報そのものはリポジトリやOrganizationのDependabot secretsに保存し、YAMLには直書きしません。npmのスコープ別レジストリは.npmrcと組み合わせて指定します。2025年7月にはOrganization単位で取得元を一括管理する集中型プライベートレジストリ設定がGAになり、リポジトリごとの重複定義を減らせるようになりました（この集中管理はprivateリポジトリではGitHub Advanced Security／Code Securityの契約が前提で、publicリポジトリは無償です）。トークンの種類や有効期限の設計はGitHub PAT（Personal Access Token）とは？作成方法・classic／fine-grainedの違い・スコープ・有効期限を解説を参照してください。

自動マージとGitHub Actionsの連携

Dependabotには自動マージ機能が組み込まれていないため、auto-mergeはGitHub Actionsで実装します。PR作成をトリガーにCIを回し、テスト通過後にgh pr merge --autoでマージ予約する構成が広く使われます。パッチ更新だけ自動マージするなど、dependabot/fetch-metadataで取得した更新種別（update-type）やラベルで分岐させます。なおgh pr merge --autoを効かせるには、リポジトリ設定で「Allow auto-merge」を事前に有効化しておく必要があります。

name: dependabot-auto-merge
on: pull_request
permissions:
  contents: write
  pull-requests: write
jobs:
  auto-merge:
    if: github.actor == 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - uses: dependabot/fetch-metadata@v2
        id: meta
      - if: steps.meta.outputs.update-type == 'version-update:semver-patch'
        run: gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

手動で更新を走らせたいときは、リポジトリの「Insights > Dependency graph > Dependabot」から該当エコシステムの「Check for updates」を実行します。GitHub Actions内でスクリプトを書いて分岐や通知を組みたい場合はGitHub Scriptとは何かを初心者にもわかりやすく解説が手がかりになります。

DependabotとRenovateの違い：どちらを選ぶか

依存関係更新ツールの比較で必ず挙がるのがRenovateです。GitHubに閉じて手早く始めるならDependabot、複数プラットフォームや細かいPR制御が要るならRenovate、と割り切るのが実務では分かりやすい判断軸です。

判断の目安はシンプルで、GitHub上の中小規模リポジトリで「まず脆弱性対応と最新化を自動化したい」だけならDependabotで十分です。逆に、複数リポジトリで設定を共通化したい・更新をまとめて1PRに集約したい・GitHub以外も対象にしたい、という要件が一つでもあるならRenovateを選ぶべきです。両者を併用するとPRが重複するため、リポジトリ単位でどちらかに寄せます。

Dependabotの料金：無料の範囲とGHASとの違い

Dependabotのalerts・security updates・version updatesは、public・privateを問わず、Free／Pro／Team／Enterpriseのどのプランでも無料です。「Dependabotは有料」という誤解は、GitHub Advanced Security（GHAS）と混同していることが原因です。GHASはCode ScanningやSecret Scanningを含む有料アドオンで、Dependabotの基本機能とは課金体系が別です。GHASの機能範囲はGitHub Advanced Securityの主要機能：コードスキャンやシークレットスキャン、コード走査の仕組みはGitHub Code Scanningとは？概要と基本的な仕組みを解説で確認できます。なお、auto-mergeをGitHub Actionsで実装する場合、そのワークフロー実行はActionsの無料枠・課金の対象になる点だけ留意してください。

よくあるトラブルと対処

運用で詰まりやすいのは、PRが作成されないケースです。原因の多くは設定ファイルの配置ミスか権限不足です。

• PRが作られない：.github/dependabot.ymlの配置・package-ecosystemとディレクトリの不一致を確認。「Dependabot」タブのログにエラーが出る。
• 更新が止まる：open-pull-requests-limit（既定5）に達していないか確認。開いたままのPRをマージ・クローズすると再開する。
• プライベート取得元で失敗：registriesの参照ミスやDependabot secretsの不足、トークンのスコープ不足を確認。
• CIが失敗する：互換性のない更新はPR単位でテストし、ignoreで除外するかgroupsでまとめて検証する。

よくある質問

Dependabotの読み方は？

「ディペンダボット」と読みます。dependency（依存関係）とbot（自動化）を組み合わせた名称です。

Dependabotは無料ですか？

無料です。alerts・security updates・version updatesはpublic／privateとも全プランで料金がかかりません。有料なのは別機能のGitHub Advanced Securityです。

DependabotとRenovateはどちらを使うべきですか？

GitHubで手早く始めるならDependabot、複数プラットフォーム対応やPR集約・自動マージの柔軟さが要るならRenovateが向きます。併用はPRが重複するため避けます。

dependabot.ymlはどこに置きますか？

リポジトリ直下の.github/dependabot.ymlに置きます。.yaml拡張子やほかのパスでは認識されません。

Dependabotを一時停止・無効化するには？

version updatesはリポジトリの「Code security」設定でオフにするか、dependabot.ymlを削除します。特定の依存だけ止めたい場合はignoreで除外します。

関連記事

• GitHub PAT（Personal Access Token）とは？作成方法・classic／fine-grainedの違い・スコープ・有効期限を解説
• GitHub Advanced Securityの主要機能：コードスキャンやシークレットスキャン
• GitHub Code Scanningとは？概要と基本的な仕組みを解説
• Log4j2の脆弱性について：Log4Shellの詳細解説とその影響