Renovateで依存パッケージを自動更新する設定方法

Renovate（通称 Renovatebot）は、リポジトリ内の composer.json や package.json、Dockerfile、GitHub Actions のワークフローなどを読み取り、依存パッケージの新しいバージョンが出るとプルリクエストを自動で作ってくれるツールです。導入のポイントは、最初は自動マージを使わず、スケジュールと PR 数の上限を決めて「通知が多すぎて放置される」状態を避けること です。この記事では、GitHub での導入手順、実用的な renovate.json の書き方、自動マージを安全に使う条件までを説明します。

Renovate でできること

Renovate は Mend 社が開発しているオープンソースのツールで、GitHub・GitLab・Bitbucket など複数のプラットフォームに対応しています。主な機能は次のとおりです。

• 依存の更新ごと、またはまとめてプルリクエストを作成する
• composer.lock や package-lock.json などのロックファイルも合わせて更新する
• 「Dependency Dashboard」という Issue に、保留中・待機中の更新を一覧表示する
• 実行する曜日や時間帯、パッケージごとのルール、自動マージ条件を細かく設定する

GitHub には標準機能として Dependabot もあります。設定項目の少なさと手軽さでは Dependabot、ルールの柔軟さや対応する形式の幅では Renovate、という傾向があります。どちらが合うかはリポジトリの規模とチームの運用次第です。両方を同じ依存に対して有効にすると重複した PR ができるので、片方に寄せてください。

導入方法は2通り

GitHub App を使う（手軽）

GitHub であれば、Mend が提供する Renovate の GitHub App をインストールするのが最も手軽です。インストール時に対象リポジトリを選ぶと、まず「Configure Renovate」のようなタイトルのオンボーディング PR が作られます。この PR には renovate.json の雛形と、設定を有効にしたら何件の PR が作られる見込みかの説明が含まれています。

オンボーディング PR をマージするまで、Renovate は更新 PR を作りません。内容を読み、後述の設定を加えてからマージするのがおすすめです。App の提供条件や画面の表記は変わることがあるので（2026年10月現在）、インストール前に公式ドキュメントで確認してください。

自前で実行する（セルフホスト）

社内の Git サーバーを使っている場合や、外部サービスにリポジトリへの権限を渡したくない場合は、Renovate を自分で実行できます。npm パッケージ、Docker イメージ、GitHub Actions 用のアクションが用意されており、定期実行（cron や CI のスケジュール）で動かすのが一般的です。

# 例: 環境変数でトークンを渡して実行する（値はダミー）
export RENOVATE_TOKEN=your-access-token
npx renovate --platform=github your-org/your-repo

トークンには対象リポジトリへの書き込み権限が要ります。権限は必要最小限にし、CI のシークレット機能に保存してください。ログにトークンを出力しないよう、デバッグ用の設定を有効にしたまま運用しないことも大切です。

renovate.json の基本設定

リポジトリ直下に置く renovate.json の、実用的な出発点の例です。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "timezone": "Asia/Tokyo",
  "schedule": ["before 9am on monday"],
  "prConcurrentLimit": 5,
  "prHourlyLimit": 2,
  "labels": ["dependencies"],
  "packageRules": [
    {
      "matchManagers": ["composer"],
      "matchDepTypes": ["require-dev"],
      "groupName": "PHP dev dependencies"
    },
    {
      "matchManagers": ["github-actions"],
      "groupName": "GitHub Actions"
    },
    {
      "matchUpdateTypes": ["major"],
      "labels": ["dependencies", "major"]
    }
  ]
}

各項目の意味は次のとおりです。

• **$schema**: エディタで入力補完と検証が効くようになります。
• **extends: ["config:recommended"]**: Renovate が用意している推奨プリセットです。以前は config:base という名前でしたが、現在は config:recommended が使われています。古い記事の設定を写すときは名前に注意してください。
• **timezone と schedule**: PR を作る時間帯を決めます。指定しないと、新しいバージョンが出るたびに随時 PR が届きます。週1回などに絞ると、レビューのリズムを作りやすくなります。
• **prConcurrentLimit / prHourlyLimit**: 同時に開いておく PR の数と、1時間あたりに作る数の上限です。導入直後に数十件の PR が一度に届くのを防げます。
• **packageRules**: 条件に合う依存にだけ別のルールを適用します。上の例では、Composer の開発用依存と GitHub Actions をそれぞれ1つの PR にまとめ、メジャー更新には目立つラベルを付けています。

グループ化は PR の数を減らせる反面、1つの PR に複数の変更が入るため、問題が起きたときにどの更新が原因か切り分けにくくなります。テストが整っている範囲から少しずつまとめるのが安全です。

設定ファイルを書いたら、マージ前にバリデーターで確認できます。

npx --yes --package renovate -- renovate-config-validator

WordPress / PHP プロジェクトでの注意点

Composer で WordPress のテーマやプラグインを管理している場合（WPackagist などのリポジトリを使う構成）、Renovate は composer.json の依存として更新を検出します。ただし、取得元のリポジトリ設定や認証の有無によって検出できる範囲が変わるので、Dependency Dashboard で実際にどの依存が認識されているかを確認してください。

プラグインの更新は、PHP のバージョン要件が上がったり、管理画面の挙動が変わったりすることがあります。Renovate の PR はあくまで「新しいバージョンがある」という知らせであり、動作確認は別に必要です。PR ごとにステージング環境へデプロイして確認する流れを用意できると、更新の判断がしやすくなります。

また、公開直後のバージョンは不具合修正のリリースがすぐ続くことがあります。minimumReleaseAge を設定すると、公開から一定期間が過ぎたバージョンだけを PR にできます。

{
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "minimumReleaseAge": "3 days"
    }
  ]
}

minimumReleaseAge は以前 stabilityDays という名前だった設定です。どちらの名前が使えるかは Renovate のバージョンによるので、公式の設定リファレンスで確認してください。

自動マージを使う前に整えておくこと

Renovate には、条件を満たした PR を自動でマージする automerge があります。手間は大きく減りますが、テストが不十分なまま有効にすると、壊れた更新がそのまま本番に向かうことになります。次の条件がそろってから使うのが目安です。

1. プルリクエストで CI（テスト、静的解析、ビルド）が自動で走る
2. ブランチ保護で、CI の成功をマージの必須条件にしている
3. 対象をパッチ更新や開発用依存など、影響の小さい範囲に絞る

{
  "packageRules": [
    {
      "matchManagers": ["composer"],
      "matchDepTypes": ["require-dev"],
      "matchUpdateTypes": ["patch", "minor"],
      "automerge": true
    }
  ]
}

この例では、Composer の開発用依存のマイナー・パッチ更新だけを自動マージの対象にしています。本番で動くコードに入る依存や、メジャー更新は手動レビューのままにしておくのが無難です。バージョン 0.x のパッケージはマイナー更新でも互換性が崩れることがあるので、自動マージの対象から外すことも検討してください。

運用でつまずきやすい点

• PR が作られない: オンボーディング PR がマージされているか、schedule の時間帯外ではないかを確認します。Dependency Dashboard に「待機中」として表示されている場合は、スケジュールや minimumReleaseAge で止まっています。
• ロックファイルの更新で失敗する: プライベートなパッケージリポジトリを使っている場合、Renovate にも認証情報を渡す必要があります。Renovate のドキュメントにある hostRules などの仕組みを確認してください。
• PR が溜まって放置される: 上限とスケジュールを絞る、影響の小さいものはグループ化する、担当者を決める、のいずれかで見直します。放置された依存は、まとめて更新するほど調査が大変になります。

まとめ

• Renovate は依存の新しいバージョンを検出し、ロックファイル込みの PR を自動で作るツール。
• GitHub なら App で手軽に導入でき、社内サーバーではセルフホストで動かせる。
• config:recommended を土台に、schedule と PR 数の上限で通知の量を調整する。
• WordPress のプラグイン更新は PR だけで判断せず、ステージングで動作を確認する。
• 自動マージは CI とブランチ保護を整えてから、影響の小さい更新に限って使う。

• GitHub Dependabotで依存関係を自動更新する
• composer.jsonとcomposer.lockの役割