GitHub Dependabot を使うと、リポジトリの composer.json や package.json、GitHub Actions のワークフローで使っている依存関係に新しいバージョンが出たとき、更新用のプルリクエストを自動で作らせることができます。この記事では、WordPress のテーマ・プラグインやサイトのリポジトリを例に、dependabot.yml の書き方、プルリクエストを増やしすぎない工夫、パッチ更新の自動マージまでを説明します。
Dependabotの3つの機能を区別する
Dependabot という名前で呼ばれる機能は、大きく 3 つに分かれます。
- Dependabot alerts: 依存しているパッケージに既知の脆弱性が見つかったとき、リポジトリに警告を表示します。
- Dependabot security updates: 脆弱性のある依存関係を修正済みのバージョンに上げるプルリクエストを自動で作ります。
- Dependabot version updates: 脆弱性の有無に関係なく、新しいバージョンが出たら更新のプルリクエストを作ります。設定ファイル
.github/dependabot.ymlで動作を決めます。
alerts と security updates はリポジトリの設定画面のセキュリティ関連の項目から有効にします（画面の項目名は GitHub の更新で変わることがあります。2026年10月現在の表記は公式ドキュメントで確認してください）。この記事で主に扱うのは、設定ファイルで細かく制御できる version updates です。
WordPress本体やプラグインの自動更新とは別物
Dependabot が更新するのは、リポジトリにある依存関係の定義ファイルとロックファイルです。管理画面からインストールしたプラグインや WordPress 本体を更新するものではありません。WordPress の自動更新は WordPress 側の機能で管理し、Dependabot はテーマやプラグインの開発で使っている Composer・npm のパッケージ、Bedrock のように Composer で WordPress を管理しているサイト構成などに使う、と役割を分けて考えます。
dependabot.ymlの基本
リポジトリに .github/dependabot.yml を作成し、デフォルトブランチにコミットすると有効になります。Composer、npm、GitHub Actions を対象にした例です。
version: 2
updates:
- package-ecosystem: "composer"
directory: "/"
schedule:
interval: "weekly"
day: "monday"
time: "09:00"
timezone: "Asia/Tokyo"
open-pull-requests-limit: 5
groups:
composer-dev:
dependency-type: "development"
update-types:
- "minor"
- "patch"
ignore:
- dependency-name: "phpunit/phpunit"
update-types:
- "version-update:semver-major"
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
groups:
wordpress-packages:
patterns:
- "@wordpress/*"
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "monthly"各項目の意味は次のとおりです。
version: 2: 設定ファイルの形式のバージョンで、この値で固定です。package-ecosystem: 対象のパッケージマネージャーです。Composer はcomposer、npm はnpm、GitHub Actions はgithub-actionsを指定します。directory: 定義ファイルがある場所です。composer.jsonがリポジトリ直下なら/、テーマのディレクトリにあるなら/wp-content/themes/my-themeのように書きます。GitHub Actions の場合は/と書けば.github/workflowsが対象になります。schedule: 更新を確認する頻度です。daily、weekly、monthlyなどを指定し、timeとtimezoneで時刻を決められます。open-pull-requests-limit: Dependabot が同時に開いておくプルリクエストの上限です。groups: 複数の更新をひとつのプルリクエストにまとめる設定です。ignore: 特定のパッケージや更新種別を除外します。
設定を保存した後は、リポジトリの依存関係グラフや Dependabot の画面で最後に実行された時刻やエラーを確認できます。設定に誤りがあるとここにエラーが表示されるので、最初のコミット後に一度確認しておきます。
プルリクエストを増やしすぎない工夫
Dependabot を有効にした直後は、溜まっていた更新のプルリクエストが一度に届くことがあります。レビューが追いつかないと放置され、かえって更新が滞る原因になります。
groupsでまとめる
@wordpress/scripts や @wordpress/components など、@wordpress/ で始まるパッケージは同時に更新されることが多いため、patterns でひとつのグループにまとめると扱いやすくなります。開発用の依存関係（PHP_CodeSniffer や PHPUnit など）を dependency-type: "development" でまとめ、マイナーとパッチの更新だけを 1 本のプルリクエストにする方法も有効です。
メジャー更新は分けて扱う
メジャーバージョンの更新は互換性のない変更を含むことがあります。例のように ignore でメジャー更新を除外するか、グループに含めず個別のプルリクエストにして、変更履歴を読んでから取り込む運用が安全です。除外したまま忘れると古いバージョンに取り残されるので、定期的に手動で確認する日を決めておきます。
公開直後のバージョンを避ける
新しく公開されたバージョンを少し待ってから取り込む「クールダウン」のような設定も追加されています。公開直後の不具合や、乗っ取られたパッケージの悪意あるバージョンを取り込むリスクを下げる目的で使えます。項目名や対応しているエコシステムは変わることがあるため、使う前に GitHub の公式ドキュメントで確認してください。
CIと組み合わせて安全に取り込む
Dependabot のプルリクエストは、通常のプルリクエストと同じように GitHub Actions のワークフローを起動します。PHP の構文チェック、PHP_CodeSniffer、PHPUnit、JavaScript のビルドなどを CI で実行しておけば、更新によって壊れたかどうかをマージ前に判断できます。CI がない状態で Dependabot のプルリクエストをマージし続けるのは、テストせずに本番を更新するのと同じなので避けてください。
なお、Dependabot が起動したワークフローでは、通常の Actions のシークレットではなく Dependabot 用のシークレットが使われ、GITHUB_TOKEN の権限も既定では制限されています。CI でプライベートなパッケージを取得する場合などは、Dependabot 用のシークレットを別に登録する必要があります。
パッチ更新だけを自動マージする
テストが通ったパッチ更新まで毎回手でマージするのは負担です。GitHub が公開している dependabot/fetch-metadata アクションで更新の種類を判定し、パッチ更新だけ自動マージを予約するワークフローの例です。
# .github/workflows/dependabot-auto-merge.yml
name: Dependabot auto-merge
on: pull_request
permissions:
contents: write
pull-requests: write
jobs:
dependabot:
runs-on: ubuntu-latest
if: github.event.pull_request.user.login == 'dependabot[bot]'
steps:
- name: Fetch Dependabot metadata
id: metadata
uses: dependabot/fetch-metadata@v2
with:
github-token: "${{ secrets.GITHUB_TOKEN }}"
- name: Enable auto-merge for patch updates
if: steps.metadata.outputs.update-type == 'version-update:semver-patch'
run: gh pr merge --auto --squash "$PR_URL"
env:
PR_URL: ${{ github.event.pull_request.html_url }}
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}gh pr merge --auto は「条件を満たしたらマージする」予約なので、すぐにはマージされません。この仕組みを安全に使うには、次の準備が前提になります。
- リポジトリの設定で自動マージ（auto-merge）を許可しておく。
- デフォルトブランチにブランチ保護ルールやルールセットを設定し、CI のチェックが通ることをマージの条件にしておく。
この条件がないと、テストの結果を待たずにマージされる可能性があります。また、パッチ更新でも不具合が入ることはあるので、自動マージの対象は開発用の依存関係に限定する、本番に影響する依存関係は人が確認する、といった線引きをチームで決めておくと安心です。
WordPressプロジェクトでの注意点
- ロックファイルをコミットする:
composer.lockやpackage-lock.jsonがリポジトリにないと、Dependabot は定義ファイルの範囲指定だけを更新し、実際に入るバージョンを管理できません。サイトやテーマのリポジトリではロックファイルをコミットしておきます。 - PHP のバージョンを揃える: Composer は実行環境の PHP バージョンを前提に依存関係を解決します。本番サーバーの PHP より新しいバージョンを要求するパッケージが入らないよう、
composer.jsonのconfig.platform.phpに本番の PHP バージョンを書いておくと安全です。 - 独自のパッケージリポジトリ: WPackagist のような Composer リポジトリや、認証が必要なプライベートリポジトリを使っている場合は、
dependabot.ymlのregistriesで接続先を設定する必要があることがあります。対応状況は公式ドキュメントで確認してください。 - 配布するプラグインの vendor: プラグインに
vendorを同梱して配布している場合、Dependabot が更新するのはロックファイルまでです。配布用の ZIP は更新を取り込んだ後にビルドし直します。
まとめ
- Dependabot には alerts、security updates、version updates があり、version updates は
.github/dependabot.ymlで制御する。 - 更新対象はリポジトリの依存関係の定義ファイルとロックファイルで、WordPress 管理画面からの更新とは別物。
groups、ignore、open-pull-requests-limitでプルリクエストの量を調整し、メジャー更新は個別に確認する。- マージ前に CI で検証し、自動マージはブランチ保護と組み合わせてパッチ更新など範囲を絞って使う。
- ロックファイルのコミットと PHP バージョンの固定で、更新結果を再現できる状態にしておく。