GitHub Dependabotで依存パッケージの更新を確認する方法

2026/09/06

URLをコピーしました！

npmやpipを使っていると、依存パッケージに新しい版が出ても、なかなか気づけません。気づいたときには更新対象が何十件も溜まっていて、どこから手を付ければいいのか分からなくなる。

GitHubのDependabotは、その更新を自動で見つけてPull Requestの形にしてくれる仕組みです。ただし、届いたPull Requestをそのままマージしてよいわけではありません。

dependabot.ymlの最小構成と、取り込む前に何を確認すればよいかを整理します。

Dependabotは「更新を見つけてPull Requestにする」仕組み

小さなWebサイトやツールでも、npm、pip、Bundlerといったパッケージ管理を使えば、外部ライブラリへの依存は数十件になります。

開発が一段落した後に、どれへ新しい版が出たのかを毎回手で調べるのは、正直かなり面倒ですよね。

Dependabot version updatesは、指定したパッケージ管理方式とディレクトリを定期的に確認して、利用できる更新が見つかったときに依存関係を書き換えたPull Requestを作ります。

更新内容が通常のPull Requestとして届くので、変更ファイルやCIの結果を見てから取り込めるわけです。

気をつけたいのは、Dependabotを「安全性まで自動で保証してくれる機能」と捉えないことです。Dependabotが受け持つのは更新候補の発見と、変更案の作成まで。

更新後もアプリケーションが正しく動くか、仕様変更の影響がないか、いつ本番へ反映するか。この判断はリポジトリを管理する人に残ります。

結論は小さく始めて人間が確認する

初めて設定するなら、すべてのパッケージ管理方式を毎日確認する構成へいきなり寄せる必要はありません。

影響を把握しやすいリポジトリで、1つのエコシステムを週1回確認するところから始めるのが現実的でしょう。

npmを使う小規模なサイトなら、次のような流れになります。

.github/dependabot.ymlにnpmの設定を追加する
更新確認の間隔を週1回にする
Dependabotが作成したPull Requestを一覧で確認する
版の変化、変更ファイル、テスト結果を見る
ローカルや検証環境で主要機能を動かす
問題がなければ通常のPull Requestと同じ手順でマージする

この流れなら、更新候補を見逃しにくくしながら、確認の工程も省かずに済みます。

Pull Requestが多すぎると感じたら、後から頻度や同時に開く件数、グループ化を調整できます。最初の設定を完璧に決めようと悩まなくて大丈夫です。

設定前に確認しておくこと

設定ファイルを書く前に、リポジトリの構成を押さえておきましょう。

ここが曖昧なままサンプルをコピーすると、Dependabotが対象のマニフェストを見つけられなかったり、想定と違う場所を監視したりします。

どのリポジトリで更新を管理するか
既定ブランチはどれか
npm、pip、Composer、GitHub Actionsなど、何で依存関係を管理しているか
package.jsonやrequirements.txtなどのマニフェスト、ロックファイルがどこにあるか
Pull Request作成後に実行できるテストやビルドがあるか
本番へ反映する前に確認できる検証環境があるか
非公開レジストリや別の非公開リポジトリにある依存関係を使っているか

エコシステムごとに指定するのは、package-ecosystem、directoryまたはdirectories、schedule.intervalの3つです。

非公開の依存関係を使っている場合は、Dependabotがその取得先へアクセスできるよう、追加の設定が必要になることもあります。

テストは設定上の必須項目ではありません。とはいえ、テストがなければ更新の安全性を判断する材料は乏しくなります。

CIを組んでいないなら、ログイン、フォーム送信、表示、データ保存など、壊れると困る操作を先に確認リストとして書き出しておくのがおすすめです。

dependabot.ymlの最小構成

Dependabotの細かな挙動は、既定ブランチに置いた.github/dependabot.yml、または.github/dependabot.yamlで決まります。

version updatesを使うには、まずこのファイルをリポジトリへ追加してください。書く項目自体は多くありません。対象のエコシステムと場所、確認の間隔を指定すれば動きます。

npmを週1回確認する設定例

ルートディレクトリにpackage.jsonがあるnpmプロジェクトなら、最小構成はこれだけです。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

npmの依存関係を対象に、ルートディレクトリを週1回確認する設定になります。プロジェクトのマニフェストがサブディレクトリにあるなら、directoryを実際の場所へ書き換えてください。

各項目の意味

version

設定ファイルの構文バージョンです。必須項目なので、ファイルの先頭に2を書きます。

updates

監視したいパッケージ管理方式ごとの設定を並べる場所です。

package-ecosystem

npm、pip、Docker、GitHub Actionsなど、更新対象の種類を指定します。使える値を思い込みで入力せず、対象のエコシステムがGitHubの対応一覧に含まれるかを確かめておきましょう。

directory

マニフェストや依存関係定義ファイルの場所です。ルートなら/を指定します。モノレポのようにプロジェクトが複数の場所へ分かれているなら、directoriesを使う方法もあります。

schedule.interval

新しい版を確認する頻度です。基本の構成ではdaily、weekly、monthlyなどを指定できます。

選べる間隔は今後変わる可能性もあるため、公開前に公式のオプションリファレンスで確認しておくと安心です。

複数のパッケージ管理方式を使う場合

npmとGitHub Actionsの両方を更新したいなら、updatesの下に設定を分けて並べます。

GitHub Actionsについては、ワークフローが標準の.github/workflowsにある場合でも、directoryにはルートの/を指定します。ここは迷いやすいところですね。

最初から対象を増やしすぎると、作成されるPull Requestが一気に増えます。まず1種類で動きを確かめ、レビューに使える時間とテスト環境を見ながら足していく方が管理しやすいでしょう。

設定を反映して動作状況を確認する

設定ファイルを既定ブランチへ追加または更新すると、Dependabotは指定したエコシステムを設定した間隔で監視します。

利用できる更新を見つけると、設定の内容に従って依存関係を変更するPull Requestが作られます。

GitHubの設定画面からDependabot version updatesを有効にして、.githubディレクトリに基本のdependabot.ymlを作る流れも用意されています。

画面名や項目の位置は変わりやすいので、実際のリポジトリで現在の表示を確かめながら進めてください。

反映後に見ておきたいのが、Dependency graph内にあるDependabotの画面です。監視対象のパッケージ管理方式と、最後に新しい版を確認した時点が表示されます。

設定ファイルを置いただけで終わらせず、想定した対象がきちんと並んでいるかを確認しましょう。

Forkでは、dependabot.ymlが存在してもversion updatesは自動的に有効になりません。元のリポジトリから設定ファイルごと取り込んだ場合も、Fork側で明示的に有効化する操作が必要です。

DependabotのPull Requestを確認する順序

Dependabotが作成したPull Requestは、作者がdependabotになり、初期状態ではdependenciesラベルが付きます。通常のPull Request一覧からでも見分けられるはずです。

自動で作られたからといって、中身を見ずにマージする理由にはなりません。見る順序を決めておくと、判断材料を集めやすくなります。

更新対象と版の変化を確認する

最初に見るのは、どのパッケージがどの版からどの版へ変わるのかという点です。

パッチ、マイナー、メジャーのどれに当たるかを押さえたうえで、対象パッケージのリリースノートや移行案内にも目を通します。

とくにメジャーアップデートでは、利用方法や設定方法そのものが変わる可能性があります。版番号だけで判断せず、自分のコードが使っている機能に影響する変更がないかを見てください。

変更ファイルとCI結果を確認する

次はPull RequestのFiles changedです。マニフェストやロックファイルなど、想定したファイルだけが変わっているかを見ます。

CIを設定しているなら、テスト、ビルド、型チェック、静的解析の結果もここで合わせて確認します。

ただ、CIが成功しても、事業上重要な画面や外部サービスとの連携まで保証されるとは限りません。反対にCIが失敗した場合も、すぐ更新を諦めるのではなく、テスト側の前提が古いのか、更新によって互換性が崩れたのかを切り分けます。

実際の画面や主要機能を確認する

Webサイトなら、トップページが表示されるかだけでなく、問い合わせフォーム、ログイン、決済、予約、管理画面といった重要な流れを検証環境で通しておきます。

ライブラリなら、公開APIや主要な処理を実際に走らせます。

先に決めておきたい3つ

更新確認の担当者
毎回確認する項目
問題が起きたときの戻し方

この3つを事前に決めておくと、Pull Requestが作られたまま放置されにくくなります。Dependabot側の決まりではなく、小規模な運用で更新を続けるための実務上の提案です。

Pull Requestが増えすぎるときの調整

依存関係が多いプロジェクトでは、DependabotのPull Requestが短期間で積み上がり、確認が追いつかなくなることがあります。調整に使える設定は主に4つです。

設定	できること
`schedule`	確認の頻度に加え、曜日、時刻、タイムゾーンを指定する
`open-pull-requests-limit`	同時に開くPull Requestの数を制限する
`groups`	関連する依存関係の更新を1つのPull Requestへまとめる
`ignore`	特定の依存関係や版を対象から外す

まず見直したいのは更新頻度です。毎日の確認が必要ないなら週1回へ変え、自分やチームがレビューできる曜日と時刻に寄せます。

open-pull-requests-limitは同時に開く件数の上限ですが、値を0にすると、そのエコシステムのversion updates用Pull Requestを停止する設定として扱われます。

件数を絞るつもりで0を入れると更新が届かなくなるので、値の意味を確認してから変更してください。

関連する依存関係をまとめたい場合はgroupsを検討します。まとめればPull Requestの数は減りますが、その分1件あたりの変更範囲は広くなります。

問題が起きたときに原因を切り分けられるか、まとめてテストできる組み合わせかを基準にしましょう。

特定の依存関係や版を対象外にするignoreもあります。複数人で管理するリポジトリなら、Pull Request上のコメントで無視条件を保存するより、設定ファイルへ明示しておく方が、更新されない理由を共同作業者が把握しやすいとGitHubは案内しています。

security updatesとversion updatesを混同しない

Dependabotには役割の違う3つの機能があり、設定する場所もそれぞれ別です。

機能	役割	設定する場所
Dependabot alerts	脆弱性のある依存関係を知らせる	リポジトリまたはOrganizationの設定画面
Dependabot security updates	脆弱性のある依存関係の更新Pull Requestを作る	リポジトリの設定画面
Dependabot version updates	新しい版を定期的に探して更新Pull Requestを作る	`.github/dependabot.yml`

dependabot.ymlがなくても、リポジトリ設定でsecurity updatesを有効にしていれば、脆弱な依存関係の更新Pull Requestが作成される場合があります。

一方で、version updatesの自動確認とスケジュール、細かな更新条件はdependabot.ymlで設定します。

3つを同じ設定だと思い込むと、ファイルを置いたのにアラートが出ない、security updatesを有効にしたのに定期更新されない、といった行き違いにつながるので注意してください。

この記事の中心はversion updatesです。脆弱性対応の優先順位、アラートの対象条件、security updatesの有効化状態は、リポジトリごとに別途確認してください。