Renovateとは — 依存関係の更新を任せっぱなしにできるGitHub botの仕組みと使い方

Last updated at 2026-09-16Posted at 2026-09-16

グラレコ

まずはこの1枚に、記事全体の要点をまとめました。Renovateの動く仕組み、導入の流れ、PR洪水を防ぐ設定、Dependabotとの使い分け、そして2025〜2026年のサプライチェーン対策の潮流までを描いています。詳細はこれから順に見ていきます。

🤖 はじめに

Renovate は、リポジトリ内の依存関係を自動で検出し、新しいバージョンが出るたびに更新のPull Requestを作ってくれるオープンソースのbotです。Mend.io が開発・保守していて、GitHubスターは約22.5k（2026年9月時点）。npm や pip のような定番から、Dockerfile、GitHub Actions、Terraform まで、公式表現で「90以上」のパッケージマネージャーに対応しています。

「依存関係の更新bot」と聞くと、GitHubに標準搭載されている Dependabot を思い浮かべる方が多いと思います。Renovate はその強力な対抗馬で、モノレポの自動グルーピング、柔軟なスケジュール設定、1行で有効になる automerge など、「更新PRを大量にさばく」ための機能が充実しているのが特徴です。

この記事では、次のことを紹介します。

Renovate が何をしてくれるbotなのか、その動作の仕組み
GitHub App でのインストールから、オンボーディングPR、renovate.json の基本設定まで
PRが大量に来る問題への対処と、automerge を安全に使う設定
Dependabot との比較と使い分けの考え方
minimumReleaseAge に代表される、2025〜2026年のサプライチェーン攻撃対策の潮流

対象読者は、GitHubでチーム開発をしていて、依存ライブラリの更新が後回しになりがちなエンジニアの方です。なお、本記事の内容は執筆時点（2026年9月、Renovate 44.x）の情報に基づいています。

📦 Renovateとは

依存関係の更新は「重要だが緊急ではない」タスクの代表格

Renovate の話に入る前に、そもそもの課題を整理します。依存ライブラリの更新は、放置すると次のようなループに陥りがちです。

以下の図は、多くのチームで起きている「依存更新の放置ループ」を示したものです。

一度このループに入ると、抜け出すコストがどんどん上がっていきます。数ヶ月放置した package.json を前にして、どこから手をつけるべきか途方に暮れた経験のある方も多いのではないかと思います（そして大抵、そういうときに限って脆弱性アラートが飛んできます）。

このループを断ち切る定石が「更新を小さく・高頻度に・機械にやらせる」ことで、それを実現するのが Renovate です。

Renovateの動作サイクル

Renovate の基本動作はシンプルです。以下の図は、そのサイクルを示したものです。

ポイントは、package.json だけでなく、Dockerfile のベースイメージ、GitHub Actions のバージョン、Terraform のプロバイダーまで、リポジトリ内のあらゆる「バージョンが書かれたファイル」を検出対象にできることです。既存のマネージャーが対応していない独自形式でも、custom manager（正規表現ベース）で拾えます。

作成されるPRには、更新対象のリリースノートや変更履歴が自動で埋め込まれます。「このバージョンアップで何が変わったのか」をPR上で確認できるので、レビューのために各リポジトリを見に行く手間が省けます。

対応プラットフォームはGitHubだけではない

Renovate はマルチプラットフォーム対応で、これが後述する Dependabot との大きな違いの1つです。

プラットフォーム	対応状況
GitHub（github.com / Enterprise Server）	✅ 対応
GitLab（gitlab.com / セルフマネージド）	✅ 対応
Bitbucket Cloud / Server	✅ 対応
Azure DevOps	✅ 対応
Gitea / Forgejo	✅ 対応
AWS CodeCommit / Gerrit / SCM-Manager	🧪 experimental

提供形態も、GitHub App（Mend Renovate App）、npmパッケージ、Dockerイメージ、GitHub Action と複数あります。この記事では、いちばん手軽な GitHub App での利用を中心に説明します。

🚀 導入してみる

GitHub Appのインストール

導入は、GitHub Marketplace の Renovate から「Install」を押すだけです。対象は「All repositories」か「Only select repositories」を選べます。パッケージファイルが見つからないリポジトリとforkは自動的に無視してくれるので、迷ったら All でも実害は少ないです。

無料（Community）プランの場合、ジョブキューは4時間ごとに更新され、リポジトリへの関連コミットでも実行がトリガーされます。「設定を変えたのに反映されない」と思ったら、たいていはこの実行間隔の問題なので、少し待ってみてください。

オンボーディングPR — マージするまで何もしない設計

インストールすると、Renovate は各リポジトリに 「Configure Renovate」というオンボーディングPR を作ります。ここが Renovate の親切な設計ポイントで、このPRをマージするまで、Renovate はリポジトリに一切変更を加えません。

以下の図は、導入からPRが流れ始めるまでの流れです。

オンボーディングPRの説明文には、「この設定でマージすると、こういうPRたちが作られる予定です」というプレビューの一覧が表示されます。マージする前に、何が起きるかを一望できるわけです。導入した瞬間に大量のPRが飛んでくる事態を防ぐ、よくできた合意形成の仕組みだと思います。

最小構成のrenovate.json

オンボーディングPRに含まれる設定は、最小構成だとこれだけです。

renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"]
}

たった1行の config:recommended ですが、実はかなり多くの設定が詰まっています。このプリセットの中身を展開すると、次のようになっています。

以下の図は、config:recommended が継承しているプリセットの主なものを示したものです。

注目したいのは group:monorepos です。たとえば @angular/* 系のパッケージが同時に更新されたとき、バラバラのPRではなく「Renovate angular monorepo packages」という1つのPRにまとめてくれます。コミュニティがメンテナンスしているグルーピング定義が最初から同梱されているので、自分でグループを定義しなくても、有名どころのモノレポパッケージはいい感じにまとまります。

また、mergeConfidence:age-confidence-badges によって、PRに Merge Confidence バッジが表示されます。このプリセットで見られるのは、そのリリースが出てから何日経ったか（Age）と総合の信頼度（Confidence）の2つです。さらに mergeConfidence:all-badges（Mend のホステッドアプリでは自動で有効）にすると、Renovateユーザーのうちどれくらいがそのバージョンに移行済みか（Adoption）、そのパッケージの更新でテストが通った割合（Passing）も加わります。「このバージョン、上げて大丈夫そうか」の判断材料になります。

⚙️ renovate.jsonの基本設定

デフォルトのままでも動きますが、チームで運用するなら少し調整したくなります。よく使う3つの設定を紹介します。

スケジュール — PRが来る時間帯を絞る

schedule を設定すると、PRの作成タイミングを制限できます。プリセットが用意されているので、まずはそれで十分です。

プリセット	意味
`schedule:daily`	毎日0〜3時台
`schedule:weekly`	週1回（月曜早朝）
`schedule:monthly`	月1回（1日の早朝）
`schedule:nonOfficeHours`	平日夜間 + 週末
`schedule:weekends`	週末のみ

timezone と組み合わせて使います。

renovate.json

{
  "extends": ["config:recommended", "schedule:weekly"],
  "timezone": "Asia/Tokyo"
}

1つ注意点として、スケジュールの最小粒度は「時間」です。分単位のcronを書いても意図どおりには動きません。

グルーピング — 関連パッケージを1つのPRにまとめる

packageRules と groupName で、任意のパッケージ群を1つのPRにまとめられます。

renovate.json

{
  "packageRules": [
    {
      "matchPackageNames": ["/eslint/"],
      "groupName": "eslint"
    }
  ]
}

この例では、名前に eslint を含むパッケージの更新が「eslint」という1つのPRにまとまります。PRの数は劇的に減りますが、トレードオフもあります。まとめたPRがCIで落ちたとき、どのパッケージが犯人かの切り分けが必要になる点です。公式ドキュメントもこの点を明記しているので、「リスクの低いものだけまとめる」くらいのバランスがおすすめです。

automerge — テストが通ったら自動でマージ

Renovate の看板機能の1つが、組み込みの automerge です。設定は1行で済みます。

renovate.json

{
  "packageRules": [
    {
      "matchDepTypes": ["devDependencies"],
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true
    }
  ]
}

この例では、devDependencies の minor / patch 更新だけが automerge の対象になります。「automerge って怖くない？」と思われるかもしれませんが、デフォルトでは status check（CI）がすべて通るまで絶対にマージしない設計になっています。

以下の図は、automerge の判定フローです。

この図のとおり、「テストがないリポジトリ」ではそもそも automerge が動きません（ignoreTests: true で強行はできますが、おすすめしません）。また、baseブランチに「レビュー必須」のブランチ保護がかかっていると automerge は失敗するので、Renovate用の例外を検討する必要があります。

公式ドキュメントが automerge を推奨しているのは、次の3つです。

lockFileMaintenance（lockファイルの再生成）— もっともリスクが低い
devDependencies（linter、formatter、テストフレームワーク）— 本番コードに影響しない
SemVerエコシステムの minor / patch（ただし 1.0.0 未満のパッケージは除く）

逆に言うと、本番依存のメジャー更新まで automerge するのは、テストへの相当な自信がない限りやめておいたほうが無難です。

📊 Dependency Dashboard — 更新の全体像を1つのIssueで

Renovate を入れると、リポジトリに「Dependency Dashboard」というIssueが1つ作られます（config:recommended に含まれています）。このIssueには、依存関係更新の全体像が集約されます。

📋 保留中の更新の一覧
⏳ レート制限やスケジュール待ちでキューに入っているPR
🚫 closeされて無視扱いになった更新
⚠️ 非推奨（deprecated）パッケージの警告

さらに便利なのが、チェックボックスによる承認ワークフローです。dependencyDashboardApproval を設定すると、Dashboard上でチェックを入れるまでPRを作らせない運用ができます。

renovate.json

{
  "packageRules": [
    {
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true
    }
  ]
}

以下の図は、この設定での運用フローです。

「minor / patch は自動で流し、メジャーだけ人間が着手タイミングを決める」という運用が、この仕組みだけで実現できます。破壊的変更を含みがちなメジャー更新を、チームの余裕があるときにまとめて対応する、といったコントロールがしやすくなります。

なお、脆弱性修正のPRだけはこの承認をバイパスして即作成されます。セキュリティは待たせない、という設計思想が徹底していますね。

⚖️ Dependabotとの比較

「それ、Dependabot でよくない？」という疑問には正面から答えておきます。結論から言うと、どちらが優れているかではなく、要件次第です。

まず機能面の比較です。

観点	Renovate	Dependabot
プラットフォーム	GitHub / GitLab / Bitbucket / Azure DevOps / Gitea など	基本はGitHubのみ（Azure DevOpsは一部機能のみ公式対応）
導入	App インストール or セルフホスト	GitHubにビルトイン（設定ファイル1つ）
対応エコシステム	90以上	40弱
モノレポのグルーピング	コミュニティ定義を同梱（自動）	groups機能あり（自分で定義が必要）
Dependency Dashboard	✅ あり	❌ なし
automerge	✅ 組み込み（`"automerge": true`）	❌ 設定キーなし（GitHubのauto-merge + ワークフロー構築で実現）
セルフホスト	✅ 公式サポート	GitHub外は非公式
ライセンス	AGPL-3.0	MIT

Renovate 側の強みは、この表のとおり「規模と複雑さに耐える機能群」です。一方、Dependabot の強みは GitHubネイティブであることに尽きます。インストール不要・無料で、dependabot.yml を1つ置くだけ。GitHub の Security タブや Advisory Database ともシームレスに統合されています。セキュリティアラートから修正PRまでが GitHub の標準機能だけで完結するのは、素直に強いです。

また、公平のために書いておくと、近年の Dependabot は改善が着実に進んでいます。グループ更新（groups）、複数ディレクトリ対応、そしてバージョン更新へのデフォルト3日のクールダウン適用など、かつて Renovate だけの強みだった機能が徐々に追加されており、機能差は縮小傾向にあります。

使い分けの目安を図にすると、こうなります。

海外の比較記事でも「GitHub単一・小規模・ゼロコンフィグ志向なら Dependabot、モノレポ・マルチプラットフォーム・細かい制御なら Renovate」という結論はおおむね共通しています。すでに Dependabot で困っていないなら乗り換える必要はありませんし、PRの洪水やモノレポ運用に悩んでいるなら Renovate を試す価値は十分にあります。

🛡️ 運用のコツ — PR洪水とサプライチェーン対策

「RenovateはPRを大量に作る」問題への対処

Renovate の悪評として最も有名なのが「PRが洪水のように来る」というものです。ただ、実はデフォルトでもある程度の抑制は効いています。

制限	デフォルト値	意味
`prHourlyLimit`	2	1時間あたりに新規作成するPRの数
`prConcurrentLimit`	10	同時にオープンにしておくPRの数

オンボーディング直後に更新候補が50件あっても、1時間に2本ずつ、同時オープンは10本まで、というペースで順次やってくる計算です（なお、脆弱性修正PRはこの制限を無視して「列に割り込み」ます）。

それでも多いと感じる場合の対策は、この4つの組み合わせです。

以下の図は、PR流量を制御する4つのバルブを示したものです。

全部を一気に設定する必要はありません。「まず schedule:weekly で週1に絞る → それでも多ければグルーピング → メジャーだけ承認制に」と段階的に締めていくのが現実的です。

minimumReleaseAge — 「賢く待つ」というサプライチェーン対策

2025年、npm エコシステムでは Shai-Hulud ワームをはじめとする大規模なサプライチェーン攻撃が相次ぎました。悪意あるコードを仕込んだパッケージが公開され、それを自動更新で取り込んでしまう、というのがまさに依存更新botの弱点を突く攻撃です。

これに対する Renovate の回答が minimumReleaseAge です。リリースから指定期間が経過するまで、そのバージョンへの更新を提案しないという機能で、v42（2025年11月）からは config:best-practices に npm 向けの「3日待ち」がデフォルトで入りました。

以下の図は、この「3日待ち」がなぜ効くのかを時系列で示したものです。

ロジックは単純で、悪性パッケージの多くは公開から24〜72時間のうちに検出されてレジストリから削除されるため、3日待つだけで危険域の大部分をスキップできる、というものです。「最速で最新に上げる」ことをあえてやめて、「少し待ってから上げる」ほうが安全という、依存関係管理の考え方の転換です。

設定はプリセット1つです。

renovate.json

{
  "extends": ["config:recommended", "security:minimumReleaseAgeNpm"]
}

さらに、automerge を使う場合は「14日待ってからにせよ」と公式ベストプラクティスは推奨しています。人間のレビューを挟まない分、待機期間を長めに取るという考え方です。

面白いのは、この「クールダウン」の考え方が業界標準になりつつあることです。Dependabot もバージョン更新にデフォルト3日のクールダウンを適用するようになり、pnpm にも minimumReleaseAge 設定があります。2025〜2026年の依存関係管理は、「速く上げる」競争から「賢く待つ」設計へとはっきり舵を切りました。

そのほかのハマりどころ

運用していてつまずきやすいポイントを表にまとめます。

😵 ハマりどころ	原因と対処
automergeが動かない	status checkが1つもない / ブランチ保護でレビュー必須 / （branch方式の場合）`renovate/**` ブランチがCIのトリガー対象外、のどれかが大半
メジャー更新PRをcloseしたら二度と来ない	仕様。closeは「今は上げない」の意思表示として扱われる。自分でメジャーを上げれば以後のminor/patch追従は再開する
設定変更が反映されない	Communityプランは4時間ごとの実行。急ぎなら関連コミットをpushするとトリガーされる
カスタムレジストリで更新が止まる	v42以降、リリース日時が取れないレジストリでは`minimumReleaseAge`系の判定で待機扱いになることがある。`minimumReleaseAgeBehaviour`で調整可能
Issueが1つ増えるのが気になる	Dependency DashboardはIssueを1つ占有する。不要なら`dependencyDashboard: false`

全部入りの設定例

ここまでの内容を組み合わせた、日本のチーム向けの構成例を載せておきます（各オプションの意味は前述のとおりで、そのまま使える構文になっています）。

renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "schedule:weekly",
    "security:minimumReleaseAgeNpm"
  ],
  "timezone": "Asia/Tokyo",
  "prConcurrentLimit": 5,
  "packageRules": [
    {
      "matchDepTypes": ["devDependencies"],
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true
    }
  ],
  "lockFileMaintenance": { "enabled": true }
}

ポイントは4つです。

週1回・日本時間の早朝にまとめてPRが来る（schedule:weekly + timezone）
devDependencies の minor / patch はテストが通れば automerge
メジャー更新は Dashboard で人間が承認したときだけPR化
npm パッケージは公開から3日待ってから提案（サプライチェーン対策）

「自動で回るところは全自動、判断が要るところは人間」という分担が、この程度の設定量で組めます。

🔭 最近のRenovate — バージョンごとのテーマ

Renovate はリリースが非常に活発です。直近のメジャーバージョンの流れを見ると、開発の方向性がよく分かります。

以下の図は、2025年以降のメジャーバージョンとテーマの推移です。

v42・v43 と、2世代連続でセキュリティがテーマになっているのが読み取れます。2025年の npm 攻撃ラッシュを受けて、「依存更新botそのものが攻撃経路にならない」方向へ振り切っている状況です。依存関係の自動化を任せる相手として、この姿勢は安心材料だと思います（ちなみにv44は「誤ってメジャー扱いでリリースされた」と公式が認めているご愛嬌バージョンで、破壊的変更はありません）。

❓ よくある疑問

Q1. 料金はかかりますか？

Renovate 本体はオープンソース（AGPL-3.0）で、GitHub App の Community プランは無料で使えます。無料プランは実行キューの更新が4時間ごと、という頻度の違いはありますが、通常のチーム開発で困ることはあまりないはずです。

Q2. プライベートリポジトリでも使えますか？

使えます。GitHub App のインストール時に対象リポジトリを選ぶだけです。社内レジストリやプライベートパッケージを参照している場合は、認証情報の設定（hostRules）が別途必要になります。

Q3. モノレポでパッケージごとに設定を変えられますか？

できます。packageRules の matchFileNames などでパス単位のマッチングができるほか、組織で共通設定リポジトリを作って extends で共有するのが定番の運用です。共通ルールは組織プリセットに、リポジトリ固有の差分だけ各 renovate.json に書く形にすると、リポジトリが増えても管理が破綻しません。

Q4. Dependabot と併用してもいいですか？

技術的には併用できます。よくあるのは「バージョン更新は Renovate、セキュリティアラートは GitHub（Dependabot alerts）」という分担です。実際、Renovate の vulnerabilityAlerts 機能自体が GitHub の Dependabot alerts を読み取って動く仕組みなので、この2つは対立するというより補完関係にあります。ただし両方にバージョン更新PRを作らせると同じ更新のPRが二重に来るので、役割は分けましょう。

Q5. 導入したら最初に何をすべきですか？

オンボーディングPRの説明文を読むことです。そこに「マージしたら何が起きるか」がすべて書いてあります。いきなりマージせず、プレビューされたPR一覧を見て、多すぎると感じたら schedule や prConcurrentLimit をPR上で調整してからマージする、という手順が安全です。

🎁 まとめ

Renovate について、仕組みから導入、運用チューニング、Dependabot との使い分けまでを紹介しました。

Renovate は90以上のパッケージマネージャー・複数プラットフォーム対応の依存関係更新bot
config:recommended 1行で、Dashboard・モノレポグルーピング・Merge Confidence バッジまで有効になる
PR洪水は schedule・グルーピング・Dashboard承認・並列上限の4つのバルブで制御できる
automerge は「CIが通るまでマージしない」設計。devDependencies の minor / patch から始めるのが定石
2025〜2026年のトレンドは minimumReleaseAge に代表される「賢く待つ」サプライチェーン対策

依存関係の更新は、頑張って追いつくものではなく、仕組みで回すものになりました。もし手元のリポジトリに古い依存が溜まっているなら、まずは1つのリポジトリに Renovate を入れて、オンボーディングPRのプレビューを眺めるところから始めてみてください。「うちのリポジトリ、更新候補がこんなにあったのか」と可視化されるだけでも、導入する価値があります。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up