Dependabot alertsの設定方法と対応手順｜安全にアラートを解消する実践ガイド | PYLORHYTHM（ピロリズム）

GitHubのリポジトリを開いたら、Security and qualityタブ（旧Securityタブ）に見慣れない脆弱性アラートが何件も並んでいた——そんな経験はありませんか？

Dependabot alertsは、プロジェクトが使っているライブラリに既知の脆弱性が見つかったときに知らせてくれる便利な機能です。ただし「とりあえず全部アップデート」「自動PRをそのままマージ」で対応すると、思わぬ破壊的変更を本番に持ち込んでしまうこともあります。

この記事では、Dependabot alertsの設定方法と、アラートが来たときにリスクを抑えて対応する手順を、実際の対応経験をもとに解説します。Node.js（npm）のプロジェクトを例にしていますが、考え方は他の言語でも共通です。

この記事でわかること

Dependabotの3つの機能（alerts / security updates / version updates）の違い
Dependabot alertsの有効化と、見落とさないための通知設定
アラートが来たときの「影響判定 → 修正 → 検証 → リリース」の手順
修正できないアラートをdismiss（却下）する判断基準
現場でハマりやすいポイントとその対処法

Dependabotとは？3つの機能の違い

Dependabotには、名前が似ている3つの機能があります。混同しやすいので、最初に整理しておきましょう。

機能	何をするか	設定場所
Dependabot alerts	依存ライブラリに既知の脆弱性があるとアラートで通知する	リポジトリのSettings
Dependabot security updates	アラートに対して、修正版へ上げるPRを自動作成する	リポジトリのSettings
Dependabot version updates	脆弱性に関係なく、ライブラリを定期的に最新化するPRを作成する	`.github/dependabot.yml`

ポイントは、alerts（通知）とsecurity updates（自動PR）は別の機能だということです。自動PRをオフにしても、アラートの通知は届きます。

アラートの判定には、GitHubが管理する脆弱性データベース（GitHub Advisory Database）が使われています。npm auditもGitHub Advisory Databaseの情報をもとにしているため、ローカルでもおおむね同じ脆弱性を確認できます（件数の数え方は異なります。後述）。

Dependabot alertsの設定方法

1. Dependabot alertsを有効化する

リポジトリのSettingsを開く
左メニューの「Security and quality」欄にあるAdvanced Securityを開く
Dependabot alertsの右にあるEnableを押す（前提となるDependency graphは、このとき自動で作られます）
必要に応じてDependabot security updatesも有効にする

組織（Organization）単位で、すべてのリポジトリに一括で有効化することもできます。

2. 通知を見落とさない設定にする

アラートが出ていても、誰も気づかなければ意味がありません。通知は2か所の設定がそろって初めて届きます。

① 個人の通知設定

右上のアイコン → Settings → Notificationsを開き、「Dependabot alerts」の項目で通知方法（On GitHub / Email / CLI）を選びます。

ただし、GitHub上やメールで通知が届くのは、重要度がCriticalかHighの新しい脆弱性が見つかったときだけです。ModerateやLowのアラートは、通知なしで一覧に増えていきます。

そこで、あわせてEmail weekly digestを有効にしておくのがおすすめです。アラートのまとめが毎日または毎週メールで届きます（対象は最大10リポジトリ）。通知が来ないアラートを溜めたまま放置するのを防げます。

② リポジトリのWatch設定

リポジトリのトップページ右上のWatchボタンから、All Activityを選ぶか、CustomでSecurity alertsにチェックを入れます。

⚠️ リポジトリのSettingsにある「Email notifications」は、pushのたびにメールを送るための別の設定です。Dependabotの通知とは関係ないので注意しましょう。

チームで確実に共有したい場合は、GitHubのSlackアプリでチャンネルにアラートを流すのも有効です。

3. dependabot.ymlで定期アップデートを設定する（任意）

ライブラリを定期的に最新化したい場合は、.github/dependabot.ymlを置きます。以下は、npmの依存を月1回まとめて更新し、PRをstagingブランチ向けに作る例です。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    target-branch: "staging"   # PRの向き先
    schedule:
      interval: "monthly"
    commit-message:
      prefix: "build"
    groups:
      npm-dependencies:        # 更新を1つのPRにまとめる
        patterns:
          - "*"
    ignore:
      # 互換性の問題があるメジャーアップデートを除外する例
      - dependency-name: "eslint"
        update-types: ["version-update:semver-major"]

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

⚠️ target-branchはversion updates（定期更新）にしか効きません。 security updatesの自動PRは、常にデフォルトブランチ（多くはmain）向けに作られます。staging → mainの順でリリースする運用の場合、自動PRをそのままマージすると、stagingでの確認を飛ばしてしまうので注意してください。

さらに、target-branchを指定すると、同じecosystemに書いた他の設定（commit-messageやgroupsなど）もsecurity updatesには適用されなくなります。上の例では、security updatesのPRにはbuildの接頭辞もグループ化も付きません。

アラートが来たときの対応手順

ここからが本題です。アラートを見たらすぐにアップデートしたくなりますが、まず影響を判断してから手を動かすのが安全です。

ステップ1：影響範囲を確認する

アラートの重要度（Critical / High / Moderate / Low）だけで判断せず、次の3点を確認します。

① どこから入っている依存か

npm ls <パッケージ名>

自分でpackage.jsonに書いた直接の依存なのか、他のライブラリ経由で入っている間接の依存なのかがわかります。

② 本番に含まれる依存か

npm audit --omit=dev

--omit=devを付けると、本番用の依存（dependencies）だけを対象にできます。ここに出てこない脆弱性は、テストやLintなど開発時にしか使われないものです。

💡 Dependabotの画面の「Development」ラベルは参考になりますが、同じパッケージが本番の依存経由でも入っていることがあります。npm audit --omit=devで確認するのが確実です。

③ 脆弱性が発動する条件に当てはまるか

アラートの詳細画面にある脆弱性の説明（「Impact」などの見出しで書かれていることが多い）には、どんな使い方をすると影響を受けるかが書かれています。たとえば、

「◯◯という機能に外部からの入力を渡している場合」
「◯◯という設定をしていなければ影響なし」

のような条件です。自分たちのコードや設定で、その機能を使っているか検索して確認しましょう。

# 例：該当する機能を使っているか検索する
grep -rn "該当する関数名やimport" src/

ステップ2：優先度を決める

確認した内容から、対応の優先度を決めます。

状況	優先度の目安
本番の依存＋発動条件に当てはまる	最優先（すぐに対応）
本番の依存＋発動条件に当てはまらない	通常のリリースサイクルで対応
開発用の依存のみ	余裕のあるときにまとめて対応

重要度がCriticalでも、発動条件に当てはまらなければ、慌てて他のリリースと混ぜてまで出す必要はありません。逆にModerateでも、条件に当てはまるなら優先して対応します。

ステップ3：最小の差分で修正する

修正方法は大きく2つあります。

A. Dependabotが作った自動PRを使う手軽ですが、関係のない変更が混ざったり、デフォルトブランチ向けに作られていたりすることがあります。中身（Files changed）を必ず確認しましょう。

B. ローカルで必要なパッケージだけを更新する（おすすめ）差分を最小限にでき、手元で動作確認してからPRを出せます。

# 作業ブランチを最新のstaging（または main）から作る
git switch staging && git pull
git switch -c fix/security-xxx

# 指定範囲内で更新する（package.jsonは変わらず、lockfileだけ更新）
npm update <パッケージ名>

# 直接の依存のバージョンを指定して上げる場合
npm install <パッケージ名>@<修正版のバージョン>

⚠️ npm audit fix --forceは使わないでください。 メジャーバージョンの更新（破壊的変更）まで自動で行います。実際にNext.jsがダウングレードされかけた例は「npm audit fix –forceの提案は毎回読む」にまとめています。

また、--forceなしのnpm audit fixも、関係のないパッケージまでまとめて更新することがあります。事前にnpm audit fix --dry-runで、何が変わるかを確認しましょう。

ステップ4：改善と動作を確認する

修正前後のnpm auditの結果を比べると、狙った脆弱性が消えたかどうかが一目でわかります。

npm audit > /tmp/audit-before.txt   # 修正前に実行しておく
# …更新…
npm audit > /tmp/audit-after.txt
diff /tmp/audit-before.txt /tmp/audit-after.txt

あわせて、変更範囲と動作も確認します。

git diff --stat           # 想定したファイルだけが変わっているか
npm ls <パッケージ名>      # 想定したバージョンになっているか

# 型チェック・テスト・Lint・ビルド（プロジェクトに合わせて）
npx tsc --noEmit && npm test && npm run lint && npm run build

フレームワーク本体を更新した場合は、開発サーバーだけでなく本番モード（ビルド結果）でも主要なページを確認しておくと安心です。リダイレクトなどのルーティング処理がある場合は、curl -Iでステータスコードと転送先を確認できます。

curl -sI http://localhost:3000/old-path | grep -iE "^HTTP|^location"

ステップ5：小さく分けてリリースする

PRは小さく分ける：本番に関わる更新（フレームワーク本体など）と、開発用の依存の更新は別のPRにすると、問題が起きたときに原因の切り分けや切り戻しがしやすくなります。
他のリリースと混ぜない：ステージング環境に確認待ちの機能が入っている場合は、そちらのリリースを先に済ませてから、セキュリティ修正を単独でリリースします。
ステージングで確認してから本番へ：staging → mainの流れを崩さないようにします。

マージ後、Dependabot alertsの画面で対象のアラートが自動でクローズされていれば完了です。

修正できないアラートは「dismiss」で判断を残す

アップデートでは解消できないアラートもあります。主なケースは次の2つです。

修正版がまだ公開されていない（Patched version: None）
依存元のライブラリが古いバージョンに固定しているため、修正版に上げられない

この場合は、影響を評価したうえでアラートをdismiss（却下）し、判断の理由を記録に残します。

dismissの手順

対象のアラートを開く
Dismissのメニューから理由を選ぶ
コメントを書き、Dismiss alertを押して確定する

選べる理由は次のとおりです。

理由	使う場面
A fix has already been started	修正作業がすでに進行中
No bandwidth to fix this	今は対応する余裕がない
Risk is tolerable to this project	リスクを許容できる（開発用の依存のみ、など）
This alert is inaccurate or incorrect	誤検知
Vulnerable code is not actually used	脆弱な処理が実際には使われていない

コメントには「なぜ影響がないと判断したか」と「いつ見直すか」を書いておきましょう。 後から見た人が判断の根拠をたどれます。

依存元（◯◯経由）が旧バージョンに固定しているため修正版に上げられない。
◯◯は△△関数のみを使用しており、脆弱性の発動条件（□□）に該当しない。
◯◯の更新時に再確認する。

dismissの注意点

dismissしたアラートは、自分でReopenしない限り閉じたままです。修正版が出ても気づけるように、依存元のライブラリを更新するときにnpm auditで再確認する習慣をつけておきましょう。
修正版が未公開のアラートは、あえて開いたままにしておくのも一つの選択肢です。security updatesが有効なら、修正版が出たときに自動で修正PRが作られるので、気づきやすくなります。
dismissはいつでもReopenで元に戻せます。

よくあるハマりどころと対処法

アラートがある日突然まとめて出てきた

Dependabotは、主に次のタイミングでアラートを出します。

依存ファイル（package.json / package-lock.json）が変わるpushがデフォルトブランチにあったとき
新しい脆弱性情報が公開されたとき（pushの有無に関係なく通知されます）

依存ファイルをしばらく触っていなかったリポジトリでは、久しぶりにlockfileを更新したタイミングで、依存関係が読み直されてアラートがまとめて出ることがあります。直前の変更が原因とは限らないので、慌てずにgit diffで何が変わったかを確認しましょう。

Actionsに「Dependabot Updates」の失敗が出ている

security updatesが有効な場合、Dependabotはアラートごとに修正PRの作成を試み、その記録がActionsに表示されます。

「security_update_not_possible」のようなエラーは、依存関係の都合で自動修正できなかったという意味です。サイトの動作やデプロイには影響しません。ローカルで修正するか、影響を評価してdismissし、判断を残しましょう。

overridesを使っているとDependabotが失敗する

npmでは、直接の依存とoverridesの指定が一致していないとエラーになります。Dependabotが片方だけを書き換えようとして失敗することがあります。

overridesで"$パッケージ名"と書くと、直接の依存の指定を参照するので、両者が常に一致します。

{
  "devDependencies": { "sharp": "^0.35.5" },
  "overrides": { "sharp": "$sharp" }
}

npm auditの件数とDependabotのアラート数が合わない

npm auditは、脆弱なパッケージに依存しているパッケージも1件として数えます。そのため、Dependabotでは2件なのに、npm auditでは7件と表示されることがあります。中身を見て、元の脆弱性がどれかを確認しましょう。

package-lock.jsonがコンフリクトした

lockfileのコンフリクトは手で直さず、作り直すのが確実です。

git checkout origin/staging -- package.json package-lock.json  # 一旦ベース側に合わせる
npm install <パッケージ名>@<バージョン>                         # 自分の更新をやり直す

ブランチを切り替えたら挙動がおかしい

node_modulesはブランチごとではなく、フォルダに1つだけあります。lockfileが異なるブランチに切り替えたら、npm ciで入れ直しましょう。Next.jsなどビルドキャッシュを持つフレームワークでは、.nextなどのキャッシュも削除しておくと安全です。

運用を楽にするためのTips

Email digestをWeeklyにする：未対応のアラートを定期的に見直すきっかけになります。
CODEOWNERSで依存ファイルのレビュー担当を決める：ブランチ保護（またはルールセット）で「Require review from Code Owners」を有効にすると、package.json / package-lock.jsonを変更するPRに、特定メンバーのレビューを必須にできます。知らないうちにライブラリが追加されるのを防げます。
ブランチ保護で「Require branches to be up to date before merging」を有効にする：古い状態のままマージされるのを防ぎ、CIを最新の状態で通せます。
対応方針をチームで決めておく：自動PRを使うのか、ローカルで対応するのか。自動PRを使わないなら、security updatesをオフにする判断もありです（alertsの通知は残ります）。

よくある質問（FAQ）

Q. Dependabot alertsとDependabot security updatesの違いは？

alertsは脆弱性を通知する機能、security updatesはその修正PRを自動作成する機能です。security updatesをオフにしても、アラートの通知は届きます。

Q. npm audit fixを実行すれば解決しますか？

解決はしますが、関係のないパッケージまで更新されることがあります。--forceを付けるとメジャーアップデートも行われるため、本番環境のあるプロジェクトでは避けたほうが安全です。npm update <パッケージ名>で必要なものだけを更新するのがおすすめです。--forceの具体的な落とし穴は「npm audit fix –forceの提案は毎回読む」で解説しています。

Q. 開発用の依存（devDependencies）の脆弱性も対応すべきですか？

本番には影響しないため、優先度は下がります。ただし、CIや開発者のマシンで動くことには変わりないので、余裕のあるタイミングでまとめて更新しておきましょう。

Q. 自動で作られたPRをそのままマージしても大丈夫？

中身を確認すれば問題ありません。ただし、security updatesのPRはデフォルトブランチ向けに作られる点や、関係のない変更が含まれることがある点に注意が必要です。

Q. 修正版がないアラートはどうすればいい？

影響を評価したうえで、dismissして理由を残すか、修正版が出るまで開いたままにしておきます。どちらの場合も、判断の根拠をチームで共有しておくことが大切です。

まとめ

Dependabot alertsへの対応で大切なのは、「すぐにアップデートする」ことより「正しく判断して、最小の変更で直す」ことです。

設定：alertsを有効化し、個人の通知設定とWatchの両方を確認する
影響判定：直接か間接か、本番か開発用か、発動条件に当てはまるかを確認する
修正：npm updateなどで必要なパッケージだけを更新する（npm audit fix --forceは避ける）
検証：npm auditの差分、テスト、ビルド、動作確認
リリース：小さく分けて、他のリリースと混ぜずに、ステージング経由で出す
直せないもの：理由をコメントに残してdismiss、または修正版を待つ

アラートの件数をゼロにすること自体が目的ではありません。一つひとつのアラートに対して「なぜ対応したか / なぜ対応しないか」を説明できる状態を目指しましょう。