dependabot アラートを AI エージェントに割り当てられるようになったことで、GitHub 上の脆弱性修復はかなり実務的になりました。GitHub は 2026年4月7日、Dependabot アラートを Copilot、Claude、Codex などの AI コーディングエージェントに割り当て、脆弱性の分析、修正案を含むドラフト PR の作成、更新に伴うテスト失敗の解消まで試行できる機能を公開しました。単に依存関係のバージョンを上げるだけでは直らないケースで効く変更です。 (The GitHub Blog)
結論から言えば、軽いアラートは従来どおり Dependabot security updates で処理し、メジャーアップデートでコード修正が必要になるアラートだけ AI エージェントに回すのが最も使いやすい運用です。今回の機能は Dependabot を置き換えるものではなく、Dependabot が苦手だった「依存関係更新の先にあるコード追従」を埋めるための追加レイヤーと考えると分かりやすいです。 (The GitHub Blog)
dependabot アラートを AI エージェントに割り当てると何が変わるか
GitHub は 2026年3月3日に Dependabot アラートの担当者機能を一般提供し、まずは「誰が直すか」を GitHub 上で見える化できるようにしました。そこから 4月7日の更新で、担当者の対象が AI エージェントまで広がり、「誰が直すか」だけでなく「修正案のドラフト PR まで GitHub 内で起こす」ところまで進んだ形です。 (The GitHub Blog)
GitHub の changelog と公式ドキュメントを整理すると、従来フローと今回の変更点は次の通りです。 (The GitHub Blog)
| 観点 | 従来の Dependabot 修復 | AI エージェント割り当て後 |
|---|---|---|
| 修復の入口 | Dependabot alert を確認し、必要なら security update PR を作成 | alert 詳細から AI エージェントに割り当てる |
| 自動化される範囲 | 最寄りの修正版への依存関係更新 PR が中心 | アラート分析、依存関係の使われ方の確認、コード変更を含むドラフト PR、更新起因のテスト失敗の解消試行 |
| 向いているケース | パッチ版に上げれば終わる単純な脆弱性 | 破壊的変更、非推奨 API 置き換え、型不一致、複雑な PR、修正版がないときの安全版へのダウングレード |
| 比較のしやすさ | 人が手作業で別案を作る | 同じ alert に複数エージェントを割り当てて PR を比較できる |
| 最終判断 | 人がレビューしてマージ | 人がレビューしてマージ |
この変化で大きいのは、Dependabot の役割が「安全なバージョンへ寄せる」だけで終わらず、アプリ側の追従修正を含む候補作成まで広がったことです。ただし GitHub 自身も、AI が作る修正は不完全だったり新しい問題を持ち込んだりする可能性があるため、マージ前のレビューは必須だと明言しています。 (The GitHub Blog)
AI に回すべき dependabot アラートの見分け方
GitHub の公式説明では、Dependabot security updates は脆弱な依存関係を「最寄りの修正版」に上げる PR を自動で作ります。一方で、メジャーバージョン更新による API 破壊、非推奨メソッドの置き換え、型シグネチャの不整合のように、依存関係を上げただけではアプリが動かなくなるケースがあり、そこを AI エージェントが埋める設計です。 (The GitHub Blog)
| アラートの状態 | まず選ぶべき対応 |
|---|---|
| security update PR が既にあり、差分が小さく CI も通る | 従来どおり Dependabot security updates を優先 |
| 依存関係更新後にビルドやテストが落ちる | AI エージェントに割り当ててコード追従を試す |
| メジャーアップデートで API 変更や型エラーが出る | AI エージェント向き |
| 修正版がなく、危険なパッケージを安全版へ戻したい | AI エージェントでダウングレード案を作らせつつ人が厳格に確認 |
| 修正方針が複数ありそう | 複数エージェントに割り当てて PR を比較 |
実務では、「依存関係を上げるだけで終わるか」ではなく「アプリ側のコード修正が必要か」で分けると判断しやすいです。AI エージェントは万能ではありませんが、手作業で追うには面倒な追従修正をドラフト PR に落としてくれるため、レビュー対象を「ゼロから作る」ではなく「候補を評価する」に変えられます。 (The GitHub Blog)
使い始める前の設定チェック
4月7日の changelog では、この機能の利用には GitHub Code Security と、coding agent access を含む Copilot プランが必要だと案内されています。加えて、Dependabot alerts / security updates の有効化、リポジトリへの書き込み権限、Cloud agent のリポジトリアクセス設定を確認しておくと、画面にエージェントが出ない原因をほぼ潰せます。GitHub の Copilot チュートリアルでは、Dependabot を十分に有効化する準備として、Dependabot alerts と Dependabot security updates を有効にし、空の .github/dependabot.yml をコミットする流れも紹介されています。 (The GitHub Blog)
| 確認項目 | 目安 | 実務上の確認ポイント |
|---|---|---|
| GitHub Code Security | 必須 | 4月7日告知で必須と案内 |
| Copilot プラン | 必須 | coding agent access を含む契約か確認 |
| リポジトリ権限 | 必須 | alert を割り当てるには write 以上が目安 |
| Dependabot alerts | ほぼ必須 | alert 自体が見えないと始まらない |
| Dependabot security updates | 強く推奨 | まず通常の自動 PR で済むか確認しやすい |
.github/dependabot.yml | 初期セットアップで推奨 | Copilot チュートリアルでも準備項目として案内 |
| Copilot cloud agent の repo access | 必須 | 対象リポジトリが許可対象に入っているか確認 |
| Claude / Codex の利用可否 | 利用時のみ必須 | Partner agents のトグルを有効化 |
| 契約・組織ポリシー | 必須 | 個人設定だけでなく組織側ポリシーも確認 |
上の項目は GitHub の changelog と公式ドキュメントに沿った確認ポイントです。特に個人アカウントでは Cloud agent の Repository access、組織では Copilot > Cloud agent、さらに Claude / Codex を使うなら Partner agents の有効化が詰まりやすいポイントです。 (The GitHub Blog)
4月7日の changelog では Copilot、Claude、Codex が例示されています。GitHub Docs では、サードパーティ製コーディングエージェントとして Anthropic Claude と OpenAI Codex をサポートし、これらは GitHub 上で有効化して使う設計です。なお、サードパーティ製エージェントは現時点でパブリックプレビューです。 (The GitHub Blog)
コスト面も見落とせません。Copilot cloud agent は GitHub Actions minutes と Copilot premium requests を使い、サードパーティ製 coding agents も GitHub Actions minutes と Copilot premium requests を消費します。GitHub Docs では、third-party agent の各セッションが premium request を 1 件使うと説明されています。難しくない alert まで毎回複数エージェントに投げると、便利さより先に使用量が気になりやすくなります。 (GitHub Docs)
実際の操作手順
- リポジトリの Security and quality タブを開き、サイドバーの Dependabot > Vulnerabilities に進みます。 (GitHub Docs)
- 一覧はまず Most important で見ます。GitHub はこの並び順で、CVSS スコア、dependency scope、脆弱な関数呼び出しの検出などを踏まえて優先度付けしています。開発依存は
scope:developmentや「Development」ラベルで識別できるため、本番依存から先に見るのが効率的です。 (GitHub Docs) - alert 詳細を開いたら、まず通常の Create Dependabot security update で済むか確認します。既に修正 PR へのリンクがある、または small diff で済みそうなら、先にそちらを使う方が速いです。 (GitHub Docs)
- 依存関係を上げるだけでは無理そうなら、alert 詳細ページの右側にある割り当て領域から AI エージェントを選びます。GitHub の一般ドキュメントでは Assignees ドロップダウンから Copilot を選ぶ説明ですが、4月7日の changelog では Assign to Agent から Copilot / Claude / Codex を選ぶ案内になっています。UI の表記が少し違っても、探す場所は alert 詳細ページの右側です。 (GitHub Docs)
- 修正方針に迷う alert では、同じ alert に複数エージェントを割り当てるのが有効です。各エージェントは独立して動き、それぞれ自分のドラフト PR を開くため、差分の安全性や変更範囲を比較しやすくなります。 (The GitHub Blog)
- 生成されたドラフト PR は、そのままマージせずに必ず確認します。GitHub は AI 生成修正について、不完全なパッチ、見落とし、新しい問題の混入があり得ると明示しているため、テスト、影響範囲、脆弱性解消の妥当性を見てから取り込みます。 (The GitHub Blog)
人に持たせる運用も消えるわけではありません。GitHub Docs でも、alert はユーザーやチームに割り当てて所有権を明確にするか、Copilot に割り当てて修正案を自動生成するかを選べる構成です。つまり、トリアージ担当は人、複雑な修復案は AI という役割分担が最も自然です。 (GitHub Docs)
失敗しやすいポイントとレビュー観点
エージェントが候補に出ないときは、まずポリシーを見る
「機能がない」のではなく、「リポジトリが Cloud agent の対象外」「Claude / Codex の Partner agent が無効」「組織やエンタープライズ側で許可されていない」のどれかで止まることが多いです。個人アカウントなら Copilot settings の Cloud agent、組織なら Settings の Copilot > Cloud agent を先に確認すると、無駄な調査を減らせます。 (GitHub Docs)
PR が通っても、修正が正しいとは限らない
GitHub 自身が注意書きを入れている通り、AI 生成の修正は「動いた」だけで安心できません。特に dependency update では、古い API の呼び出しが一部だけ残る、型は通るがランタイムで崩れる、設定ファイルだけ変わって実コードの追従が甘い、といったケースが起きやすいです。 (The GitHub Blog)
レビューでは、少なくとも次の観点を固定すると安定します。
- アドバイザリで求められている修正版や回避策に合っているか
- 依存関係以外の変更が必要以上に広がっていないか
- ビルドだけでなく回帰テストや主要フローの確認も通っているか
- 脆弱な API や問題のあるパッケージ参照が残っていないか
使用量と「1リポジトリ単位」の制約を見落とさない
Copilot cloud agent は GitHub Actions ベースの一時環境で作業し、GitHub Docs では 1 回の実行で変更できるのは開始時に指定した 1 リポジトリだけとされています。複数リポジトリにまたがる脆弱性対応を一度に片付ける用途には向きません。加えて、agent 利用は Actions minutes と premium requests を消費するため、モノレポや単一リポジトリでは相性がよく、横断修復は段階的に回すという考え方が現実的です。 (GitHub Docs)
チーム運用で効果を出すコツ
運用を安定させるなら、最初の優先順位付けは人が行い、その後に AI エージェントを使うのが安全です。GitHub は alert 一覧を Most important で並べ、開発依存より本番依存を優先する見方を案内しています。つまり、AI を増やす前に 何を先に直すか を整える方が先です。大量の alert があるなら、Dependabot の auto-triage rules も併用して低優先度を先に整理すると、AI の投入先がぶれません。 (GitHub Docs)
もう一つ効くのが、agent に与えるリポジトリ文脈の整備です。GitHub Docs では、Copilot cloud agent はリポジトリのコード、使っているツール、コーディング標準を多く知っているほど効果が上がると説明しており、custom instructions で build / test / validate の方法を与えられます。依存関係修復では、どのテストを必ず回すか、どの変更は避けるか、リリース前に何を確認するかを先に書いておくと、ドラフト PR の質がぶれにくくなります。 (GitHub Docs)
おすすめの運用ルールは、次の4つです。
- 単純な patch update は Dependabot security updates を優先する
- API 破壊やテスト崩れがある alert だけ AI エージェントに回す
- 難しい alert だけ複数エージェントで比較する
- マージ判断は必ず人が持つ
まとめ
dependabot アラートを AI エージェントに割り当てる機能は、Dependabot が従来苦手だった「依存関係更新のあとに必要になるコード修正」を GitHub 上のワークフローに取り込む更新です。4月7日の changelog が示しているのは、Dependabot を捨てる方向ではなく、Dependabot security updates を基本にしつつ、複雑な修復だけ AI にエスカレーションするという運用です。 (The GitHub Blog)
最初の一歩としては、テストが整っているリポジトリで 1 件だけ、メジャーアップデートや CI 崩れが絡む Dependabot alert を選び、通常の security update と AI エージェント割り当てのどちらが速く安全かを比べてみるのがおすすめです。そこで線引きが決まると、以後の修復ワークフローがかなり安定します。
コメント