Dependabot が npm 12・pnpm 11/12・Bun 1.4 に対応。pnpm 12 の特定 lockfile ではセキュリティアラートと修正更新が作られない。GHES の対応版と事前の確認点を整理する。
GHES 3.24 GHES で npm 12・pnpm 11/12・Bun 1.4 に Dependabot が対応するバージョン github.com は 2026年10月20日時点で全ユーザー対象。GHES は 3.24 に含まれる予定と changelog に記載
npm 12、pnpm 11 または 12、Bun 1.4 にプロジェクトを上げても、Dependabot のバージョン更新は引き続き受け取れる。GitHub は2026年10月20日の changelog でそう書いている。github.com では全ユーザーが対象で、GitHub Enterprise Server（GHES）には 3.24 で入る予定だ。ただし、pnpm 12 の特定の lockfile ではセキュリティアラートとセキュリティ更新が作られない既知の制限がある。
github.com のリポジトリなら、これらのバージョンへの移行で Dependabot の対応を待つ必要はなくなった。GHES を使う組織は事情が違う。対応が入るのは 3.24 からで、3.23 以前のインスタンスでこれらのバージョンに上げた場合に Dependabot がどう振る舞うか（更新 PR が来なくなるのか、ジョブがエラーになるのか）は changelog に書かれていない。
changelog の記述を環境ごとに並べると次のようになる。
| 環境 | npm 12・pnpm 11/12・Bun 1.4 のサポート |
|---|---|
| github.com | 全ユーザーで利用可能 |
| GHES 3.24 | 含まれる予定（リリース時期の記載なし） |
| GHES 3.23 以前 | 記載なし |
| GitHub Enterprise Cloud（データレジデンシー） | この changelog には個別の記載なし |
出典：GitHub Changelog「Dependabot now supports npm 12, pnpm 11 and 12, and Bun 1.4」（2026年10月20日）
表の下 2 行は「対応しない」と書かれているわけではない。書かれていないだけだ。GHES 3.23 以前については、changelog が 3.24 を対応の入るバージョンとして名指ししている以上、それより前のバージョンには含まれていないと読むのが自然だが、これは文面からの推測である。データレジデンシー付きの GitHub Enterprise Cloud も、同じ日の別の changelog（後述）では github.com と並べて明記されているのに、この発表では触れられていない。
GitHub は同じ changelog で、pnpm 12 でパッケージマネージャのバージョンを固定したプロジェクトのデフォルト形式に注意を促している。pnpm-lock.yaml が2つの YAML ドキュメントで書かれる場合、dependency graph はその中の依存関係をまだ検出できない。
この形式でも Dependabot のバージョン更新は動く。一方、検出されない依存関係については Dependabot alerts とセキュリティ更新が新規作成されず、既存のアラートが閉じる場合もある。したがって「更新が続く」ことと「脆弱性を引き続き検出できる」ことは同義ではない。pnpm 12 に移行するなら、生成した pnpm-lock.yaml がこの形式かを確認し、dependency graph と既存アラートの状態を点検する必要がある。GitHub は対応を進めているが、解消時期は告知していない。
発表の文面は「npm 12、pnpm 11 または 12、Bun 1.4 にアップグレードしても Dependabot の更新を受け取り続けられる（訳）」というものだ。この言い回しは、対応前にこれらのバージョンへ上げると更新が受け取れない状態があったことをうかがわせる。ただし、以前の具体的な挙動（どのバージョンで、どんなエラーになっていたか）は changelog に書かれておらず、確認できていない。
もう一つ、この発表はパッケージマネージャのバージョン対応だけを述べている。dependabot.yml の書き方が変わる、新しい設定キーが増える、といった記述はない。既存の設定をどう変えるべきかという話は、この発表からは出てこない。
移行の判断材料として、次の 3 点を確認したい。
pnpm-lock.yaml が生成されていないかを見る。他のバージョンは公式の「Dependabot supported ecosystems and repositories」で確かめる。GHES で複数のリポジトリが別々にパッケージマネージャを上げていく組織では、どのリポジトリが先に上げたかを把握しておくと、Dependabot の PR が来なくなったときに原因を切り分けやすい。
同じ 2026年10月20日には、Dependabot alerts の REST API にも変更が入っている。各アラートの dependency オブジェクトに version_requirement フィールドが加わり、Dependabot が最後に記録したバージョンかバージョン制約が返る。値の出どころは検出方法で変わり、lockfile があれば解決済みのバージョン、lockfile のないマニフェストなら宣言されたバージョンか制約になる。値がなければ null で、長い制約は切り詰められることがある。
パッケージマネージャを上げると lockfile も作り直されることが多いので、アラートを外部のセキュリティツールへ同期しているチームは、この値の変化も見ておくとよい。こちらは github.com とデータレジデンシー付きの GitHub Enterprise Cloud で使え、GHES には同じく 3.24 で入る予定と書かれている。GHES 側では、パッケージマネージャ対応とこの API 変更が同じバージョンでそろう。
Dependabot とプライベートレジストリの組み合わせを使っているなら、Dependabot が GitHub Packages を PAT なしで読む変更もあわせて確認しておきたい。