2025.03.18 プラットフォーム

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とは？依存関係の自動更新の基本と仕組みで先に押さえておくと、以降の設定が理解しやすくなります。

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

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とは？概要と基本的な仕組みで設定した必須チェックと組み合わせて初めて安全に機能します。メジャー更新は破壊的変更を含みやすいため自動マージから外し、人のレビューに回す方針を推奨します。

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ツールの基本概要と特徴【完全解説】で静的に検出できます。

よくある質問

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についても解説しています。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る