---
title: "GitHub ActionsとDependabotの連携設定｜依存関係の自動更新から自動マージまで"
url: "https://www.issoh.co.jp/tech/details/5896/"
published: 2025-03-18
updated: 2026-10-12
categories: ["GitHub"]
publisher: "株式会社一創"
---

# GitHub ActionsとDependabotの連携設定｜依存関係の自動更新から自動マージまで

Dependabot（読み方はディペンダボット）は、リポジトリの依存ライブラリに新しいバージョンや脆弱性修正が出たときに、更新用のプルリクエスト（PR）を自動で作成するGitHub標準の仕組みです。GitHub Actionsと組み合わせると、そのPRに対して自動テストを走らせ、安全なものだけを自動マージするところまで一気通貫で構築できます。この記事は「dependabot github actions」を連携させる具体的な設定を、`dependabot.yml`の書き方・自動マージのワークフロー・つまずきやすい権限とプライベートリポジトリ対応まで、実装ベースで整理します。

## まとめ：連携の全体像と最初に押さえる勘所

- Dependabotは**依存関係の更新PRを自動生成**し、GitHub Actionsが**そのPRの検証・自動マージ**を担う。役割は別物で、両者をつないで自動更新パイプラインにする。
- 更新の指示は`.github/dependabot.yml`に書く。GitHub Actionsのワークフロー自体を更新するなら`package-ecosystem: "github-actions"`を指定する。
- 自動マージは`dependabot/fetch-metadata`で更新種別を判定し、パッチ更新などに絞って`gh pr merge --auto`で有効化するのが定石。
- 最大の落とし穴は権限。**Dependabotが起動したワークフローはread-onlyの`GITHUB_TOKEN`で走り、通常のSecretsも読めない**。ここを知らないとPRが失敗する。

以下、基礎の整理から順に、設定ファイルとワークフローの実装、権限、プライベートリポジトリやセキュリティ更新への対応まで見ていきます。

## DependabotとGitHub Actionsの関係を整理する

### Dependabotの役割と「連携」の2つの意味

Dependabotが行うのは、依存パッケージのバージョン追従と脆弱性修正の適用提案です。実体はPRを作るところまでで、そのPRを検証・マージする作業は別の仕組みが担います。ここで「GitHub Actionsとの連携」という言葉が2つの意味で使われるため、混同しないことが重要です。1つ目は**GitHub Actionsのワークフローで使っているアクション自体をDependabotで更新する**こと、2つ目は**Dependabotが作ったPRをGitHub Actionsのワークフローで自動処理する**ことです。多くの記事がこの2つを地続きに書いてしまいますが、設定する場所（前者は`dependabot.yml`、後者はワークフローYAML）が異なります。Dependabotの基本機能そのものは[Dependabotとは？依存関係の自動更新の基本と仕組み](/tech/details/6796/)で先に押さえておくと、以降の設定が理解しやすくなります。

### バージョン更新とセキュリティ更新の違い

Dependabotの更新には2系統あります。**version updates**は`dependabot.yml`の`schedule`に従って定期的に依存を最新へ追従させるもの、**security updates**はDependabotアラート（脆弱性検知）を起点に、影響を受ける依存だけを修正版へ引き上げるものです。前者は設定ファイルが必須、後者はリポジトリの設定で有効化すれば`dependabot.yml`が無くても動きます。目的が違うので、両方を有効にして使い分けます。

## dependabot.ymlで依存更新を設定する

### 設定ファイルの基本構造

version updatesは`.github/dependabot.yml`に記述します。トップに`version: 2`を置き、`updates`配下で更新対象ごとにエコシステム・対象ディレクトリ・更新頻度を指定します。

```
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
```

`schedule.interval`に指定できるのは`daily`・`weekly`・`monthly`の3つで、`weekly`のときは`schedule.day`（曜日）や`schedule.time`で実行タイミングを絞れます。`open-pull-requests-limit`は同時に開くバージョン更新PRの上限で、既定値は5です。PRが溢れて放置される前に、頻度と上限をチームのレビュー体制に合わせて調整します。

### GitHub Actionsのワークフロー自体を更新する設定

ワークフローで`uses:`しているアクションのバージョンを追従させたい場合は、`package-ecosystem`に`"github-actions"`を指定します。対象ディレクトリはリポジトリ直下の`"/"`で、Dependabotが`.github/workflows`配下と`action.yml`を走査します。

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

複数エコシステムを扱うリポジトリでは、`npm`・`github-actions`・`docker`などを`updates`に並べて併記します。1ファイルで対象をまとめて宣言できます。

### PRを増やしすぎない制御キー

更新PRが多すぎるとレビューが破綻します。関連する更新を1つのPRにまとめる`groups`、追従しないバージョンを除外する`ignore`、対象を絞る`allow`、既定以外のブランチを対象にする`target-branch`を使い分けます。コミット接頭辞やラベルは`commit-message`・`labels`で整えられます。装飾より、まず`groups`でパッチ更新をまとめるだけでもPR数は大きく減ります。

## GitHub ActionsでDependabotのPRを自動処理する

### Dependabot発のPRを見分ける

自動処理ワークフローは、Dependabotが作ったPRだけを対象にする必要があります。判定条件は`github.event.pull_request.user.login == 'dependabot[bot]'`です。この`if`を付けずに`pull_request`全体へ処理をかけると、人手のPRまで巻き込みます。

### fetch-metadataで更新種別を取得する

更新がパッチかメジャーかで自動マージの可否を分けたいので、まず公式アクション`dependabot/fetch-metadata`でメタ情報を取り出します。出力は`dependency-names`・`dependency-type`・`update-type`で、`update-type`は`version-update:semver-patch`・`semver-minor`・`semver-major`の形を取ります。

```
name: Dependabot auto-merge
on: pull_request

permissions:
  contents: write
  pull-requests: write

jobs:
  automerge:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]'
    steps:
      - id: meta
        uses: dependabot/fetch-metadata@v2
      - name: Enable auto-merge for patch updates
        if: steps.meta.outputs.update-type == 'version-update:semver-patch'
        run: gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```

### 条件付きで自動マージする

上の例では`update-type`がパッチのときだけ`gh pr merge --auto --merge`で自動マージを予約しています。`--auto`は「必須チェックが通れば自動でマージ」の予約で、[Required Status Checksとは？概要と基本的な仕組み](/tech/details/5873/)で設定した必須チェックと組み合わせて初めて安全に機能します。メジャー更新は破壊的変更を含みやすいため自動マージから外し、人のレビューに回す方針を推奨します。

## Dependabot起動のワークフローで詰まる権限とシークレット

ここが最もつまずく箇所です。**Dependabotが起動したワークフロー実行は、フォークからのPRと同じ扱いになり、`GITHUB_TOKEN`はread-only、通常のActions Secretsも参照できません**。「ワークフローは正しいのにマージやコメントが権限エラーで落ちる」「Secretsが空になる」の大半はこれが原因です。対処は次の3点です。第一に、必要な操作は`permissions:`で`contents: write`・`pull-requests: write`のように明示的に付与します。第二に、シークレットが必要なら通常のActions SecretsではなくDependabot secretsに登録し、`secrets`コンテキストから参照します。第三に、権限を広げたいからと`pull_request_target`で未検証のPR内容を`checkout`するのは避けます。`pull_request_target`は書き込み権限とシークレットを持つ特権実行のため、Dependabot以外の外部PRからリポジトリを侵害される典型的な穴になります。権限は「落ちたから広げる」ではなく「必要な最小限だけ足す」で運用してください。

## セキュリティ更新（脆弱性アラート）への対応

脆弱性起点の自動修正を使うには、リポジトリまたは組織の設定でDependabotアラートとDependabotセキュリティ更新を有効化します（Settings のコードセキュリティ項目）。有効にすると、Dependabotが検知した脆弱性に対して修正版へ引き上げるPRが自動で作られます。バージョン更新と違い、対象は「アラートが出た依存だけ」です。セキュリティ更新のPRも前述の自動マージワークフローに乗せられますが、脆弱性修正はマイナー以上のバージョン跳ねを伴うことがあるため、`update-type`での絞り込みだけに頼らず、テストの網羅性で担保する設計にします。

## プライベートリポジトリとセルフホストランナーの注意点

プライベートリポジトリでもDependabotの動作は基本的に同じですが、社内レジストリなど非公開の依存元を参照する場合は`dependabot.yml`のトップレベル`registries`で認証情報を定義し、各`updates`から参照します。

```
version: 2
registries:
  npm-private:
    type: npm-registry
    url: https://npm.example.com
    token: ${{secrets.NPM_TOKEN}}
updates:
  - package-ecosystem: "npm"
    directory: "/"
    registries:
      - npm-private
    schedule:
      interval: "weekly"
```

ここで参照する`token`もDependabot secretsに登録します。ランナーについては、Dependabotの更新はGitHubホストランナーで動くのが既定です。内部リソースへの到達が必要などの要件がある場合にセルフホストランナーを選ぶことになりますが、その際はセキュリティ設計が前提になります。セルフホストランナーは読み取り権限を持つ相手にビルド環境やトークンを奪われる余地が生じるため、誰でもPRを送れる公開リポジトリではほぼ使うべきではなく、プライベートでも読み取り権限者が多い場合は権限の見直しから始めます。

## github/dependabot-actionという選択肢

更新処理そのものを動かす公式アクションとして`github/dependabot-action`が公開されています。これはDependabotの更新エンジン（dependabot-core）を実行するもので、通常のクラウド版GitHubではGitHub側がマネージドで実行するため、利用者が直接呼ぶ必要はありません。自前で更新処理を制御したいケースや、GitHub Enterprise Serverでセルフホスト運用する場面で関わってくる仕組みだと理解しておけば十分です。まずは`dependabot.yml`による標準運用から始めるのが実務的です。

## 更新PRが作られないときの確認ポイント

Dependabotが動かないときは、次を順に確認します。設定ファイルの配置は`.github/dependabot.yml`で正しいか、`package-ecosystem`やインデントのYAML構文にエラーがないか。実行状況はリポジトリの Insights の依存関係グラフやDependabotのログ画面で追えます。PRが増えないのは`open-pull-requests-limit`に達している、`ignore`で対象を除外している、対象ディレクトリに該当マニフェストが無い、といった理由が典型です。ワークフロー側の失敗は前述の権限（read-only `GITHUB_TOKEN`・Secrets不可）を最初に疑うと切り分けが速くなります。ワークフローYAMLそのものの記述ミスは[actionlintとは何か？GitHub Actionsワークフロー用Lintツールの基本概要と特徴【完全解説】](/tech/details/10397/)で静的に検出できます。

## よくある質問

### Dependabotの読み方は？

「ディペンダボット」と読みます。dependency（依存関係）とbot（自動化ロボット）を組み合わせた名称で、依存関係を自動更新するボットという意味合いです。

### GitHub Actionsエコシステムの更新頻度はどれくらいが妥当ですか？

アクションのバージョンは頻繁には変わらないため、`schedule.interval`は`weekly`程度が扱いやすい目安です。PRが多いと感じたら`groups`でまとめ、更新確認を逃したくない重要リポジトリだけ頻度を上げる、といった使い分けにします。

### Java（Maven/Gradle）の依存も対象にできますか？

できます。`package-ecosystem`に`maven`または`gradle`を指定すれば、Javaプロジェクトの依存も同じ枠組みで更新できます。1つの`dependabot.yml`にnpmやgithub-actionsと並べて併記します。

### dependency-review-actionとDependabotの違いは？

Dependabotは「依存を更新するPRを作る」仕組み、dependency-review-actionは「PRで持ち込まれる依存の変更に脆弱性や許可外ライセンスが無いかをレビュー時に検査する」仕組みです。前者が更新の実行、後者がPRのゲートで、役割が異なるため併用します。なお、dependency-review-actionはパブリックリポジトリでは無料ですが、プライベートリポジトリで使うにはGitHub Advanced Security（GitHub Code Security）の契約が必要です。

### Dependabotは無料で使えますか？

Dependabotのバージョン更新・セキュリティ更新・アラートはGitHubの標準機能として利用でき、パブリックリポジトリはもちろん、プライベートリポジトリでも利用できます。実行に伴うGitHub Actionsの利用は各プランの実行時間の枠内で扱われます。あわせて、cabal-plan-boundsについても解説しています。

## 関連記事

- [Dependabotとは｜dependabot.ymlの設定・料金・Renovateとの違いを解説](/tech/details/6796/)
- [GitHub Actionsで自動テストとビルドを設定する方法](/tech/details/2497/)
- [Required Status Checksとは？概要と基本的な仕組み](/tech/details/5873/)
- [GitHub Scriptとは何かを初心者にもわかりやすく解説](/tech/details/6529/)
- [actionlintとは何か？GitHub Actionsワークフロー用Lintツールの基本概要と特徴【完全解説】](/tech/details/10397/)

---

出典: [GitHub ActionsとDependabotの連携設定｜依存関係の自動更新から自動マージまで](<https://www.issoh.co.jp/tech/details/5896/>)（株式会社一創）