Dependabot が GitHub Packages を PAT なしで読む、Actions と同じ付与を再利用

private な GitHub Packages を Dependabot に読ませるために、dependabot.yml の registry エントリへ PAT（personal access token）を渡している repository がある。その PAT を外せるようになった。GitHub が2026年9月8日付の changelog に載せた変更で、Dependabot の GITHUB_TOKEN が packages: read を要求できるようになり、Dependabot の job は *.pkg.github.com と ghcr.io から pull するときにこのトークンを送る。受け付けるのは、package の設定にある「Manage Actions access」で repository に Read を付与してある package だ。GitHub Actions の workflow が private package を読むときと同じ経路を、Dependabot も通る。

private な GitHub Packages を Dependabot から引いていない repository には関係がない。読む必要があるのは、PAT ベースの registry エントリを dependabot.yml に書いているチームと、この機能が6月に一度有効になった際に npm の更新 job で公開 package の解決先が変わったチームだ。後者の経緯は changelog の末尾に Editor’s note として書かれていて、いまの実装が「fallback」である理由になっている。

package ごとに「Manage Actions access」へ repository を足す

有効化の手順は changelog に2段階で書かれている。Dependabot に読ませたい package ごとに、組織または個人アカウントの Packages タブから package の設定ページを開く。「Manage Actions access」の欄で、Dependabot を動かしている repository を Read で追加する。dependabot.yml は変更しなくてよく、その package 向けに足していた PAT ベースの registry エントリは削除できる。

対象は Dependabot が対応する GitHub Packages の全 ecosystem だと changelog は書く。ecosystem ごとの差は書かれていないので、*.pkg.github.com 配下の registry でも ghcr.io でも手順は同じと読める。

設定の単位が package である点は、運用コストとして押さえておきたい。手順は「Dependabot に読ませたい package ごと」なので、private package の数だけ設定ページを開くことになる。組織単位や repository 単位でまとめて付与する方法は changelog に書かれていない。

PAT 方式との違いは優先順位に出る

観点	PAT ベースの registry エントリ	自動付与の GITHUB_TOKEN
認証情報	Dependabot 用に発行した PAT	Dependabot の GITHUB_TOKEN（packages: read を要求）
設定する場所	dependabot.yml の registry エントリ	package 設定の「Manage Actions access」に repository を Read で追加
両方あるとき	こちらが優先される	fallback としてだけ使われる

出典：GitHub Changelog「Automatic Dependabot access to GitHub-hosted registries」（2026年9月8日）

表の3行目は、二つの方式が同時にあるときの優先順位を述べている。PAT エントリが残っている package では引き続き PAT が使われ、自動付与のトークンは出番がない。新しい経路に実際に切り替わるのは PAT エントリを消した後で、それまでは付与を済ませても挙動は変わらないことになる。この順序は changelog に明記されているわけではなく、fallback という記述からの推測だ。

6月23日に出て、いったん戻された

changelog の Editor’s note によれば、この機能は2026年6月23日に最初に公開された直後、一時的にロールバックされている。理由は、一部の npm 更新 job が公開 package を GitHub Packages 経由で解決してしまう衝突が見つかったことだ。影響を受けた job の条件や件数までは書かれていない。

再有効化にあたって GitHub は、自動付与の GitHub Packages 認証情報を fallback 認証にだけ 使う形に変えた。明示的な registry 認証情報と通常の registry routing が引き続き優先される、と changelog は書く。6月時点の実装がどう優先順位を付けていたかは書かれていないため、前後で何が変わったかを比較で示すことはできない。言えるのは、いまの設計では自動トークンが既存の設定を上書きしない、ということだけだ。

6月の初回リリースで npm の更新 job に影響が出たチームが確かめたいのは、同じ衝突が再発しないかどうかだろう。changelog が書くのは自動付与の認証情報が fallback にだけ使われるようになった点までで、その衝突が解消したかどうかの検証結果は示されていない。試すなら、影響の小さい repository から始めるのが妥当だ。

changelog にないもの

changelog に書かれていない点を挙げる。

• GitHub Enterprise Server での提供。changelog が挙げる registry は *.pkg.github.com と ghcr.io で、GHES への言及はない。
• 再有効化の日付。Editor’s note は「再有効化した」と書くだけで、日付として分かるのは changelog 自体の9月8日だ。
• package の所有者と Dependabot を動かす repository の所有者が異なる場合の扱い。「Manage Actions access」に repository を足せる範囲は書かれていない。
• Dependabot の実行ログで、PAT と自動トークンのどちらが使われたかを見分ける方法。

切り替えの順番と残る手間

PAT を外す作業自体は小さい。まず対象 package ごとに「Manage Actions access」で repository に Read を付与し、その後に dependabot.yml から該当 package 向けの PAT エントリを削除する。changelog は「削除できる」と書くだけで順番を指定していないが、fallback の設計上、付与を先に済ませておかないと削除した時点で private package を読めなくなると考えられる。

changelog が書くのは registry エントリを削除できるところまでで、Dependabot 用に発行した PAT そのものの扱いには触れていない。この変更に付いているタグは supply chain security だ。

残るのは package の数だけ設定ページを開く手間で、それがこの変更の実質的なコストだ。手順は Dependabot に読ませる package ごとに発生するものなので、private な GitHub Packages を Dependabot に読ませていない repository には、この変更で触る設定がない。