Dependabotとは｜料金は無料・dependabot.ymlの書き方とRenovateとの違い【2026年10月】

Dependabot（ディペンダボット）は、リポジトリが使っているライブラリの脆弱性を知らせ、更新用のプルリクエスト（PR）を自動で作るGitHubの機能です。料金はかからず、定期更新の設定は.github/dependabot.ymlの1ファイルで完結します。この記事では、2026年10月時点のGitHub公式ドキュメントをもとに3つの機能と料金の条件、dependabot.ymlの各キーを整理し、versioning-strategyとcooldownの違いはDependabot CLIで実際に動かした結果で示します。最後にRenovateとの選び方をまとめます。

まとめ：Dependabotの料金・設定・Renovateとの選び方

• 料金：alerts・security updates・version updatesはpublic・privateを問わず無料です。Dependabotの更新ジョブが使うGitHubホストの標準ランナーも課金されません。privateリポジトリでは、カスタム自動トリアージルールや組織レベルのプライベートレジストリ設定を使う場合にGitHub Code Securityが必要です。
• 設定：.github/dependabot.yml（.yamlも可）にversion: 2とupdatesを書き、各ブロックにpackage-ecosystem・directory・schedule.intervalを置けば動きます。対応するpackage-ecosystemの値は33種類です。
• 2025〜2026年の変更点：version updatesには、設定しなくても公開から3日間のcooldownがかかります。reviewersは2025年に削除済みで、レビュアーの自動割り当てにはCODEOWNERSを使います。
• PRが多すぎるとき：groupsでまとめ、cooldownで間隔を空け、最後にopen-pull-requests-limitで上限を決めます。
• Renovateとの選び方：GitHubだけで使い、設定を小さく保ちたいならDependabot。GitLab・Bitbucket・Azure DevOpsでも使う、あるいは自動マージや細かいルールを設定ファイル側で持ちたいならRenovateです。

以下、機能・料金・dependabot.ymlの書き方・実測・Renovateとの比較の順に説明します。

Dependabotとは：GitHubに組み込まれた依存関係の更新ボット

Dependabotは、package.json・requirements.txt・go.modなどのマニフェストとロックファイルを読み、依存パッケージに脆弱性や新しいバージョンが見つかるとアラートやPRを出します。PRの作成者はdependabot[bot]というボットアカウントです。公開レジストリの依存を更新する基本構成では、外部サービスへの登録やAPIトークンの発行は要らず、リポジトリの設定画面とdependabot.ymlだけで動きます。

Dependabotの読み方と成り立ち

読み方は「ディペンダボット」です。dependency（依存関係）とbotを合わせた名前で、もとは独立したサービスでしたが、2019年にGitHubが買収して標準機能になりました。

alerts・security updates・version updatesの違い

名前が似た3つの機能は、役割と設定場所が違います。脆弱性への対応はalertsとsecurity updates、ライブラリを古びさせないための定期更新はversion updatesが担います。

公式ドキュメントによると、dependabot.ymlが無くても、security updatesを有効にしていれば脆弱性修正のPRは作られます。ファイルが必要になるのはversion updatesを使うときと、security updatesのPRにラベルやグループ化などの設定を足したいときです。

マルウェアアラートの対象エコシステム

malware alertsは、GitHub Advisory Databaseに悪意あるパッケージとして登録された依存がデフォルトブランチにあると通知する機能です。2026年3月17日にnpm向けで始まり、7月28日にOpenSSFのmalicious-packagesのデータを取り込んで対象が広がりました。現在の対象はComposer・Go・Maven・npm・NuGet・pip・RubyGems・Rustの8つです。Dependabot alertsを有効にしたうえで、セキュリティ設定のトグルで別途オンにします。社内パッケージが公開マルウェアと同じ名前・版だと誤検知になる点は公式も注記しています。

Dependabotの料金：無料の範囲と有料になる条件

GitHub.com上のリポジトリでは、version updatesとsecurity updatesは全リポジトリで使え、alertsも組織所有・個人所有を問わず使えます。追加料金が発生する場面は限られます。

Dependabotの更新処理はGitHub Actionsのランナー上で動きますが、Actionsの課金ドキュメントは標準のGitHubホストランナーを「public リポジトリ」「GitHub Pages」「Dependabot」で無料と明記しています。privateリポジトリでも、標準ランナーによるDependabotの更新ジョブでは無料枠の分数は減りません。ただし、そのPRを契機に実行するCIや自動マージ用ワークフローには通常のActions料金が適用され、larger runnersの利用も有料です。Actions全体の単価や無料枠はGitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準で整理しています。

有料機能には、privateリポジトリ向けのカスタム自動トリアージルールと、組織レベルのプライベートレジストリ設定があります。公式ドキュメントでは、重大度・パッケージ名・CWEなどで自動却下するカスタムルールは、publicリポジトリと、GitHub Code Securityを有効にしたTeamプランの組織所有リポジトリで使えるとしています。組織レベルのレジストリ設定も、privateリポジトリで使うにはCode Securityが必要です（リポジトリ単位のdependabot.ymlによる設定は無料）。Code Securityは1アクティブコミッターあたり月30ドルで、価格と課金の数え方はGitHub Advanced Securityとは｜Secret Protection月19ドル・Code Security月30ドルの料金と課金の数え方【2026年】にまとめました。npmの開発用依存で影響の小さいアラートを自動で却下するGitHubプリセットは、privateリポジトリでも無料で有効にできます。

dependabot.ymlの書き方：必須キーと配置場所

version updatesは、デフォルトブランチの.github/dependabot.ymlに設定を置くと始まります。必須のキーはversion・updates・package-ecosystem・directory（またはdirectories）・schedule.intervalの5つです。npmとGitHub Actionsを週1回更新する最小構成は次のとおりです。

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

ファイルの配置場所と拡張子

置き場所はデフォルトブランチ（通常はmain）の.githubディレクトリで、ファイル名はdependabot.ymlかdependabot.yamlのどちらでも構いません。トップレベルに書けるのはversion（常に2）、updates、プライベートレジストリを定義するregistries、複数エコシステムをまとめるmulti-ecosystem-groupsです。作業ブランチに置いただけでは読まれないので、マージしてから動作を確認します。

package-ecosystemに書く値

package-ecosystemはパッケージマネージャごとに1ブロック書きます。オプションリファレンスに載っている値は2026年10月時点で33種類あり、パッケージマネージャ名とYAMLに書く値が違うものがあるので注意が必要です。

2025年以降も対応は増えており、vcpkgとRust toolchain（2025年8月）、Conda・Julia・Bazel・OpenTofu（2025年12月）、pre-commit（2026年3月）、Nix（2026年4月）、sbt（2026年5月）、Deno（2026年6月）が加わりました。BunはテキストのbunロックファイルにだけDependabotが対応し、旧形式のバイナリbun.lockbは読めません。PoetryでDependabotを使う場合の設定はPoetryとは？Python依存管理の仕組みと2.5系の使い方・uvとの選び方でも触れています。

directoryとdirectoriesの使い分け

directoryはマニフェストのあるディレクトリを1つ、directoriesは複数をリストで指定します。directoriesだけがワイルドカード*とglobに対応するので、モノレポで"/apps/*"のように書くならこちらを使います。github-actionsでは"/"を指定すると、.github/workflowsとルートのaction.ymlが自動で探索されます。同じエコシステム・同じブランチで複数ブロックを書くときは、ディレクトリが重複しないようにします。

schedule.intervalとcronの値

intervalに書ける値はdaily・weekly・monthly・quarterly・semiannually・yearly・cronの7つです。

時刻を指定しないと、Dependabotが実行時刻をランダムに割り当てます。timeの既定はUTCなので、日本時間の朝に揃えたいときはtimezone: "Asia/Tokyo"を一緒に書きます。cron（2025年4月22日に追加）を選んだ場合はcronjob: "0 9 * * 1"のようにcron式を書き、タイムゾーンはcron式の中でなくtimezoneで指定します。

versioning-strategyの5つの値

versioning-strategyは、新しい版が出たときにマニフェストのバージョン指定をどう書き換えるかを決めます。対応しているのはbundler・cargo・composer・helm・mix・npm・pip・pub・uvです。既定のautoは、アプリケーションならincrease、ライブラリならwidenとして振る舞います。

アプリケーションで差分を小さく保ちたいならincrease-if-necessary、利用者の環境に幅を残したいライブラリならwidenが向きます。実際にどう変わるかは、後の実測の章で確かめます。

PRが多すぎるときの設定：groups・cooldown・open-pull-requests-limit

Dependabotを入れて最初につまずくのは、PRが一度に大量に来て放置されることです。放置が続くと、Dependabotは更新そのものを止めます。公式の条件は「90日以上開いたままのDependabotのPRがあり、その90日間に人がPRのマージ・クローズやdependabot.ymlの変更などを1回もしていない」ことです。PRの数を絞る設定は、効きの大きい順に次の3つです。

groupsによる更新PRのグループ化

groupsは、条件に合う依存の更新を1本のPRにまとめます。既定では1依存につき1PRなので、依存の多いリポジトリでは最初に入れる価値があります。patternsとexclude-patternsでパッケージ名、update-typesでminor・patch・major、dependency-typeでdevelopment・productionを絞れます。applies-to: security-updatesを付けると、security updatesのPRもまとめられます。

次の断片は、先ほどの最小構成にあるnpmの更新ブロックへ、scheduleと同じ階層で追加します。

    groups:
      dev-deps:
        dependency-type: "development"
        update-types: ["minor", "patch"]
      aws-sdk:
        patterns: ["@aws-sdk/*"]

1つの依存が複数のグループ条件に合うときは、先に書いたグループに入ります。モノレポで同じ依存の更新をディレクトリをまたいで1本にしたいときは、directoriesとgroup-by: dependency-nameを組み合わせます。DockerとTerraformのように別エコシステムの更新を1本にしたいなら、トップレベルのmulti-ecosystem-groups（2025年7月1日に一般提供）を使います。この場合、各updatesブロックのpatternsは必須で、全依存を対象にするなら["*"]と書きます。

cooldownの既定3日と公開後の待機期間

cooldownは、新しい版の公開から指定日数が経つまで更新PRを出さない設定で、2025年7月1日に一般提供されました。さらに2026年7月14日からは、cooldownを書かなくてもversion updatesに3日のcooldownがかかるようになりました（オプションリファレンスにも既定値として記載）。security updatesには既定のcooldownがかからないので、脆弱性の修正版は公開直後でもPRになります。

次の断片は、待機期間を設定したい更新ブロックへ、scheduleと同じ階層で追加します。この例では通常7日、メジャー更新30日とし、typescriptは待機対象から除外します。

    cooldown:
      default-days: 7
      semver-major-days: 30
      exclude: ["typescript"]

semver-major-days・semver-minor-days・semver-patch-daysでSemVerの段階ごとに日数を変えられ、includeとexcludeには最大150件まで指定できます。両方に書いた依存はexcludeが優先され、すぐ更新されます。GitHubは既定値を入れた理由を「新しいリリースはサプライチェーン攻撃の入口になりやすく、少し待てば問題の版が見つかる時間を稼げる」と説明しています。開発工程全体での防御はソフトウェアサプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断で扱っています。

open-pull-requests-limitによる同時PR数の上限設定

同時に開くversion updatesのPRは既定で5本までで、open-pull-requests-limitで変えられます。security updatesのPRは別枠で10本に固定され、この設定では変わりません。0にするとそのエコシステムのversion updatesを一時的に止められます。上限を下げるだけだと古い更新が後回しになり続けるので、先にgroupsとcooldownで数を減らしてから調整します。

reviewersの廃止とCODEOWNERSへの移行

PRにレビュアーを自動で付けるreviewersは、2025年8月8日のGitHub公式告知で削除済みと明記されています。CODEOWNERSは、対象ファイルの変更時にコード所有者へレビューを自動依頼する仕組みです。PRの担当者の割り当てには、引き続き使えるassigneesを使います。labels・milestone・commit-messageも従来どおりです。移行用には公式のdependabot/codeowner-migration-actionが用意されています。

Dependabot CLIで実測：versioning-strategyとcooldownの違い

設定の違いがPRにどう表れるかを、Dependabotの更新ジョブを手元で動かせる公式のDependabot CLI（v1.96.0）で確かめました。2026年10月18日に、expressを^4.18.2（ロックは4.18.2）、lodashを^4.17.21（ロックは4.17.21）で固定したnpmプロジェクトに対し、条件だけを変えて3回実行しています。CLIはdependabot.ymlを読まず、ジョブ定義のYAMLを受け取ります。GitHub上にPRは作成せず、PR作成用の更新データを出力します。以下の表の「PR」は、この出力データを指します。versioning-strategyのincreaseはジョブ側のbump_versions、increase-if-necessaryはbump_versions_if_necessaryに当たります。

結果から読み取れることは3つあります。

• increase-if-necessaryは範囲内の更新でロックファイルだけを変える：lodashの4.18.1は^4.17.21の範囲に入るため、PRが変更したのはpackage-lock.jsonだけでした。increaseでは同じ更新でpackage.jsonの下限も^4.18.1に上がり、差分が2ファイルになります。
• 範囲外のメジャー更新はどちらの戦略でも制約を書き換える：express 5系は^4.18.2に収まらないため、両方とも^5.3.0への変更になりました。メジャー更新を別扱いにしたいなら、戦略ではなくignoreやgroupsのupdate-typesで分けます。
• cooldownは更新を止めるのではなく、期間外の最新版を選ぶ：express 5.3.0は実行の9日前（2026年10月9日）に公開された版です。cooldownを14日にすると5.3.0は見送られ、2025年12月1日公開の5.2.1へのPRが作られました。cooldownを延ばしても更新が止まるわけではなく、公開から日の浅い版だけが外れます。

再現条件は、同じpackage.jsonとpackage-lock.jsonを入力し、requirements-update-strategyとcooldownだけを変えることです。cooldown 14日の回に使ったジョブ定義は次のとおりで、dependabot update -f job.yml --local ./proj -o out.ymlで実行しました（Dockerが必要）。

job:
  package-manager: npm_and_yarn
  allowed-updates:
    - dependency-type: direct
      update-type: all
  source:
    provider: github
    repo: local/dependabot-test
    directory: /
  requirements-update-strategy: bump_versions_if_necessary
  cooldown:
    default-days: 14

実行は1回あたり約35秒で、初回だけnpm用の更新イメージの取得を含めて約3分かかりました。dependabot.ymlを本番に入れる前に、PRの数と差分の大きさをこの方法で見積もっておくと、groupsやcooldownの値を決めやすくなります。

プライベートレジストリとGitHub Actionsでの扱い

プライベートレジストリの認証

社内のnpmレジストリやMavenリポジトリなど認証が必要な取得元は、dependabot.ymlのトップレベルregistriesに定義し、各updatesブロックからregistriesで参照します。トークンはYAMLに直書きせず、リポジトリまたは組織の「Dependabot secrets」に保存して${{secrets.NAME}}で参照します。組織で多数のリポジトリを管理しているなら、2025年7月22日に一般提供された組織レベルのレジストリ設定で認証情報をまとめられます。リポジトリのdependabot.ymlに設定があればそちらが先に使われ、失敗したときや設定が無いときに組織の設定へフォールバックします。前述のとおりprivateリポジトリでの利用にはCode Securityが必要です。トークンの種類と権限の選び方はGitHub PAT（Personal Access Token）とは？作成方法・classicとfine-grainedの違い・確認と失効【2026年10月】を参照してください。

Dependabotが起動したワークフローの制限

公式ドキュメントによると、Dependabotが起動したpull_requestやpushなどのワークフローでは、GITHUB_TOKENが既定で読み取り専用になり、シークレットもActionsのsecretsでなくDependabot secretsから渡されます。「DependabotのPRだけCIが失敗する」場合は、まずトークン権限とDependabot secretsの設定を確認します。Dependabotには自動マージ機能が無いため、パッチ更新だけをテスト通過後にマージする仕組みはActionsで組みます。dependabot/fetch-metadata（2026年10月時点の最新はv3.1.0）で更新種別を取り、gh pr merge --autoで予約する手順はGitHub ActionsとDependabotの連携設定｜依存関係の自動更新から自動マージまでで詳しく説明しています。ワークフロー内のアクションをタグでなくコミットSHAで固定する場合の注意はSHA Pinningとは？GitHub ActionsをコミットSHAで固定する方法【Enforce設定・pinact v5】にまとめました。

DependabotのPRを操作するコメントコマンド

DependabotのPRには、コメントで指示を出せます。よく使うのは次の4つです。

• @dependabot rebase：PRをリベースする。ベースブランチが進んでコンフリクトしたときに使う
• @dependabot recreate：PRを作り直す。PRに手で加えた変更は上書きされる
• @dependabot ignore this major version：このメジャー版のPRを閉じ、以後作らない（minor・patch版も同じ書式）
• @dependabot ignore this dependency：この依存のPRを閉じ、以後作らない

グループ化したPRでは@dependabot ignore DEPENDENCY_NAMEや@dependabot unignore DEPENDENCY_NAMEで依存ごとに指定します。PRが作られないときは、リポジトリの「Insights」→「Dependency graph」→「Dependabot」で最後の実行ログを確認するのが早道です。なお、Dependabotは作成から30日を過ぎたPRの自動リベースを停止します。

DependabotとRenovateの違い・選定基準

Renovateは、Mend.ioが保守するオープンソースの依存関係更新ツールです（AGPL-3.0、2026年10月17日公開の最新版は44.166.0）。どちらも更新PRを自動で作りますが、動く場所と設定の考え方が違います。

判断の基準は2つです。1つ目はGitHub以外のリポジトリがあるかで、GitLabやBitbucketにもあるならツールを揃えられるRenovateを選びます。2つ目はルールを設定ファイルにどこまで持たせたいかで、依存ごとの自動マージ条件やスケジュールを細かく書き分けたいならRenovate、GitHubの画面とActionsで足りるならDependabotです。GitHubに閉じたリポジトリなら、導入作業の要らないDependabotから始めて困りません。PRを捌ききれず放置が始まっているチームは、config:recommendedプリセットでDependency Dashboardとモノレポ単位のグループ化が最初から入るRenovateへの乗り換えを検討します。

Renovateの料金は、GitHub.com・Bitbucket Cloud・Azure DevOps Cloud向けのMend Renovate Community（クラウド版）とセルフホストのCommunity版が無料で、サポート付きのMend Renovate Enterpriseが有料です。Terraformでの具体的な設定と挙動はRenovateでTerraformを自動更新する設定｜lockファイルとrangeStrategyの実際の挙動で実測しています。

GitLab・Bitbucket・Azure DevOpsでのDependabotの利用条件

GitHubが提供するDependabotの機能はGitHub専用で、GitLab・Bitbucket・Azure DevOpsの設定画面から有効にする手段はありません。更新処理の本体であるdependabot-coreのREADMEは、自前でホストすればAzure DevOps・GitLab・Bitbucket・AWS CodeCommitに対してもPRを作れると説明しています。ただし実行環境の隔離や認証情報の保護は自分で用意する前提です。前述のDependabot CLIもPRは作らず差分を出力するだけです。GitHub以外が中心なら、各プラットフォームに公式に対応しているRenovateを選ぶのが現実的です。脆弱性の検出だけが目的なら、ソフトウェア構成分析（SCA）ツールも選択肢になります（SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説）。依存関係の脆弱性を定期的に第三者の目で点検したい場合は、当社の脆弱性診断・セキュリティ診断も利用できます。

よくある質問

Dependabotの読み方は？

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

Dependabotは無料ですか？

無料です。alerts・security updates・version updatesはpublic・privateを問わず追加料金なしで使え、更新ジョブが使う標準のGitHubホストランナーも課金されません。privateリポジトリでは、カスタム自動トリアージルールや組織レベルのプライベートレジストリ設定を使う場合に、GitHub Code Securityの契約が必要です。

dependabot.ymlはどこに置けばよいですか？

デフォルトブランチの.github/dependabot.ymlに置きます。拡張子は.yamlでも読み込まれます。作業ブランチに置いただけでは反映されません。

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

GitHubだけで運用し、設定を小さく保ちたいならDependabotです。GitLabやBitbucketなどGitHub以外のリポジトリもある場合や、自動マージ条件を設定ファイルで細かく管理したい場合はRenovateが向きます。

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

version updatesは、該当ブロックのopen-pull-requests-limitを0にすると一時的に止まり、dependabot.ymlから削除すると無効になります。alertsとsecurity updatesは、リポジトリの「Settings」にあるAdvanced Security（Code security）の画面でオフにします。

関連記事

• GitHub ActionsとDependabotの連携設定｜依存関係の自動更新から自動マージまで
• RenovateでTerraformを自動更新する設定｜lockファイルとrangeStrategyの実際の挙動
• GitHub Advanced Securityとは｜Secret Protection月19ドル・Code Security月30ドルの料金と課金の数え方【2026年】
• ソフトウェアサプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断
• SHA Pinningとは？GitHub ActionsをコミットSHAで固定する方法【Enforce設定・pinact v5】