--- title: "Dependabotとは｜料金は無料・dependabot.ymlの書き方とRenovateとの違い【2026年10月】" url: "https://www.issoh.co.jp/tech/details/6796/" published: 2025-05-19 updated: 2026-10-18 categories: ["GitHub"] publisher: "株式会社一創" --- # 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 | | --------------------------- | ---------------- | -------------- | -------------- | | Dependabot alerts | 脆弱性のある依存を通知 | Settingsの画面 | 不要 | | Dependabot security updates | 脆弱性を直す版へのPRを作成 | Settingsの画面 | 任意（PRの体裁を調整） | | Dependabot version updates | 新しい版へのPRを定期作成 | dependabot.yml | 必須 | | Dependabot malware alerts | 既知のマルウェアパッケージを通知 | Settingsの画面 | 不要 | [公式ドキュメント](https://docs.github.com/ja/code-security/concepts/supply-chain-security/about-the-dependabot-yml-file)によると、`dependabot.yml`が無くても、security updatesを有効にしていれば脆弱性修正のPRは作られます。ファイルが必要になるのはversion updatesを使うときと、security updatesのPRにラベルやグループ化などの設定を足したいときです。 ### マルウェアアラートの対象エコシステム malware alertsは、GitHub Advisory Databaseに悪意あるパッケージとして登録された依存がデフォルトブランチにあると通知する機能です。[2026年3月17日](https://github.blog/changelog/2026-03-17-dependabot-now-detects-malware-in-npm-dependencies/)にnpm向けで始まり、7月28日にOpenSSFのmalicious-packagesのデータを取り込んで対象が広がりました。[現在の対象](https://docs.github.com/ja/code-security/concepts/supply-chain-security/malware-alerts)はComposer・Go・Maven・npm・NuGet・pip・RubyGems・Rustの8つです。Dependabot alertsを有効にしたうえで、セキュリティ設定のトグルで別途オンにします。社内パッケージが公開マルウェアと同じ名前・版だと誤検知になる点は公式も注記しています。 ## Dependabotの料金：無料の範囲と有料になる条件 GitHub.com上のリポジトリでは、version updatesとsecurity updatesは全リポジトリで使え、alertsも組織所有・個人所有を問わず使えます。追加料金が発生する場面は限られます。 | 項目 | public | private | | --------------------------------------- | --------- | ---------------- | | alerts・security updates・version updates | 無料 | 無料 | | 更新ジョブのActions実行（標準ランナー） | 無料 | 無料 | | 低影響のnpm開発依存を却下するプリセット | 無料（既定で有効） | 無料（手動で有効化） | | カスタム自動トリアージルール | 無料 | Code Securityが必要 | | 組織レベルのプライベートレジストリ設定 | 無料 | Code Securityが必要 | Dependabotの更新処理はGitHub Actionsのランナー上で動きますが、[Actionsの課金ドキュメント](https://docs.github.com/ja/billing/concepts/product-billing/github-actions)は標準のGitHubホストランナーを「public リポジトリ」「GitHub Pages」「Dependabot」で無料と明記しています。privateリポジトリでも、標準ランナーによるDependabotの更新ジョブでは無料枠の分数は減りません。ただし、そのPRを契機に実行するCIや自動マージ用ワークフローには通常のActions料金が適用され、larger runnersの利用も有料です。Actions全体の単価や無料枠は[GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準](/tech/details/16698/)で整理しています。 有料機能には、privateリポジトリ向けのカスタム自動トリアージルールと、組織レベルのプライベートレジストリ設定があります。[公式ドキュメント](https://docs.github.com/ja/code-security/concepts/supply-chain-security/dependabot-auto-triage-rules)では、重大度・パッケージ名・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年】](/tech/details/5211/)にまとめました。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ブロック書きます。[オプションリファレンス](https://docs.github.com/ja/code-security/reference/supply-chain-security/dependabot-options-reference)に載っている値は2026年10月時点で33種類あり、パッケージマネージャ名とYAMLに書く値が違うものがあるので注意が必要です。 | 使っているツール | 書く値 | security updates | | ----------------------------- | --------------------- | ---------------- | | npm・yarn・pnpm | npm | 対応 | | Bun（bun.lock） | bun | 非対応 | | pip・pipenv・pip-compile・Poetry | pip | 対応 | | uv | uv | 対応 | | Go modules | gomod | 対応 | | Maven・Gradle | maven・gradle | 対応 | | Hex（Elixir） | mix | 非対応 | | Dockerfile・Compose | docker・docker-compose | 非対応 | | GitHub Actions | github-actions | 対応 | | Terraform・OpenTofu | terraform・opentofu | 非対応 | 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との選び方](/tech/details/12303/)でも触れています。 ### 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つです。 | 値 | 実行タイミング | | ------------ | ------------------ | | daily | 平日（月〜金）毎日 | | weekly | 週1回（既定は月曜、dayで変更可） | | monthly | 毎月1日 | | quarterly | 1・4・7・10月の1日 | | semiannually | 1・7月の1日 | | yearly | 1月1日 | | cron | cronjobに書いたcron式 | 時刻を指定しないと、Dependabotが実行時刻をランダムに割り当てます。`time`の既定はUTCなので、日本時間の朝に揃えたいときは`timezone: "Asia/Tokyo"`を一緒に書きます。`cron`（[2025年4月22日](https://github.blog/changelog/2025-04-22-dependabot-now-lets-you-schedule-update-frequencies-with-cron-expressions/)に追加）を選んだ場合は`cronjob: "0 9 * * 1"`のようにcron式を書き、タイムゾーンはcron式の中でなく`timezone`で指定します。 ### versioning-strategyの5つの値 `versioning-strategy`は、新しい版が出たときにマニフェストのバージョン指定をどう書き換えるかを決めます。対応しているのはbundler・cargo・composer・helm・mix・npm・pip・pub・uvです。既定の`auto`は、アプリケーションなら`increase`、ライブラリなら`widen`として振る舞います。 | 値 | ^1.0.0 で 1.2.0 が出たとき | 2.0.0 が出たとき | | --------------------- | -------------------- | --------------- | | increase | ^1.2.0 に書き換え | ^2.0.0 | | increase-if-necessary | ^1.0.0 のまま（ロックのみ更新） | ^2.0.0 | | widen | ^1.0.0 のまま | \>=1.0.0 <3.0.0 | | lockfile-only | ロックのみ更新 | PRを作らない | アプリケーションで差分を小さく保ちたいなら`increase-if-necessary`、利用者の環境に幅を残したいライブラリなら`widen`が向きます。実際にどう変わるかは、後の実測の章で確かめます。 ## PRが多すぎるときの設定：groups・cooldown・open-pull-requests-limit Dependabotを入れて最初につまずくのは、PRが一度に大量に来て放置されることです。放置が続くと、Dependabotは更新そのものを止めます。[公式の条件](https://docs.github.com/ja/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-updates-stopped)は「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日](https://github.blog/changelog/2026-07-14-dependabot-version-updates-introduce-default-package-cooldown/)からは、`cooldown`を書かなくてもversion updatesに**3日**のcooldownがかかるようになりました（[オプションリファレンス](https://docs.github.com/ja/code-security/reference/supply-chain-security/dependabot-options-reference#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年規制対応の実装判断](/tech/details/16232/)で扱っています。 ### 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](https://github.com/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`に当たります。 | 条件 | expressのPR | lodashのPR | | ---------------------------------- | ----------------- | ------------------------- | | increase・cooldown 0日 | 5.3.0へ（^5.3.0に変更） | 4.18.1へ（^4.18.1に変更） | | increase-if-necessary・cooldown 0日 | 5.3.0へ（^5.3.0に変更） | 4.18.1へ（package.jsonは変えず） | | increase-if-necessary・cooldown 14日 | 5.2.1へ（^5.2.1に変更） | 4.18.1へ（package.jsonは変えず） | 結果から読み取れることは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日に一般提供](https://github.blog/changelog/2025-07-22-centralized-private-registry-configuration-for-dependabot-is-now-generally-available/)された組織レベルのレジストリ設定で認証情報をまとめられます。リポジトリの`dependabot.yml`に設定があればそちらが先に使われ、失敗したときや設定が無いときに組織の設定へフォールバックします。前述のとおりprivateリポジトリでの利用にはCode Securityが必要です。トークンの種類と権限の選び方は[GitHub PAT（Personal Access Token）とは？作成方法・classicとfine-grainedの違い・確認と失効【2026年10月】](/tech/details/7545/)を参照してください。 ### Dependabotが起動したワークフローの制限 [公式ドキュメント](https://docs.github.com/ja/code-security/reference/supply-chain-security/dependabot-on-actions)によると、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の連携設定｜依存関係の自動更新から自動マージまで](/tech/details/5896/)で詳しく説明しています。ワークフロー内のアクションをタグでなくコミットSHAで固定する場合の注意は[SHA Pinningとは？GitHub ActionsをコミットSHAで固定する方法【Enforce設定・pinact v5】](/tech/details/10238/)にまとめました。 ## 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](https://github.com/renovatebot/renovate)は、Mend.ioが保守するオープンソースの依存関係更新ツールです（AGPL-3.0、2026年10月17日公開の最新版は44.166.0）。どちらも更新PRを自動で作りますが、動く場所と設定の考え方が違います。 | 観点 | Dependabot | Renovate | | ---------- | ---------------------- | ----------------------------------------------------- | | 料金 | 無料（GitHub組み込み） | OSSは無料・Mendの有料版あり | | 対応プラットフォーム | GitHubのみ | GitHub・GitLab・Bitbucket・Azure DevOps・Gitea・Forgejo など | | 設定ファイル | .github/dependabot.yml | renovate.json など | | 同時PRの既定上限 | 5（version updates） | 10（prConcurrentLimit） | | 自動マージ | 無し（Actionsで実装） | automerge オプション | | 更新状況の一覧 | Insightsの画面 | Dependency Dashboard（Issue） | | 新版の待機 | cooldown（既定3日） | minimumReleaseAge（既定なし） | 判断の基準は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の実際の挙動](/tech/details/12321/)で実測しています。 ### GitLab・Bitbucket・Azure DevOpsでのDependabotの利用条件 GitHubが提供するDependabotの機能はGitHub専用で、GitLab・Bitbucket・Azure DevOpsの設定画面から有効にする手段はありません。更新処理の本体である[dependabot-core](https://github.com/dependabot/dependabot-core)のREADMEは、自前でホストすればAzure DevOps・GitLab・Bitbucket・AWS CodeCommitに対してもPRを作れると説明しています。ただし実行環境の隔離や認証情報の保護は自分で用意する前提です。前述のDependabot CLIもPRは作らず差分を出力するだけです。GitHub以外が中心なら、各プラットフォームに公式に対応しているRenovateを選ぶのが現実的です。脆弱性の検出だけが目的なら、ソフトウェア構成分析（SCA）ツールも選択肢になります（[SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説](/tech/details/16216/)）。依存関係の脆弱性を定期的に第三者の目で点検したい場合は、当社の[脆弱性診断・セキュリティ診断](/service/system/vulnerability/)も利用できます。 ## よくある質問 ### 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の連携設定｜依存関係の自動更新から自動マージまで](/tech/details/5896/) - [RenovateでTerraformを自動更新する設定｜lockファイルとrangeStrategyの実際の挙動](/tech/details/12321/) - [GitHub Advanced Securityとは｜Secret Protection月19ドル・Code Security月30ドルの料金と課金の数え方【2026年】](/tech/details/5211/) - [ソフトウェアサプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断](/tech/details/16232/) - [SHA Pinningとは？GitHub ActionsをコミットSHAで固定する方法【Enforce設定・pinact v5】](/tech/details/10238/) --- 出典: [Dependabotとは｜料金は無料・dependabot.ymlの書き方とRenovateとの違い【2026年10月】]()（株式会社一創）