「公開パッケージは Dependabot で自動更新できた。けれど社内 npm レジストリや Artifactory、ECR のプライベートイメージは更新されない」——エンタープライズで必ずぶつかる壁です。原因は2つに分解できます。認証（credentials）が通らないのか、ネットワーク到達性（network）が無いのか。この2つは対処がまったく違います。
この記事はDependabot 本番運用ガイドの各論として、プライベートレジストリ対応を実装レベルで網羅します。型別の認証から OIDC、self-hosted ランナーまで、そのまま使える設定で解説します。
この記事のルール：
registriesの type・認証フィールド・OIDC 対応は GitHub 公式ドキュメント（2026年6月時点） に基づきます。認証情報は絶対にリポジトリにハードコードせず、Dependabot シークレットで渡してください。本番前に必ず公式のプライベートレジストリ設定で最新を確認してください。
0. 2つの壁：認証と到達性
| 壁 | 症状 | 越え方 |
|---|---|---|
| 認証 | private_source_authentication_failure | registries ブロック ＋ Dependabot シークレット |
| 到達性 | private_source_not_reachable / timed_out | self-hosted ランナー（私設網にランナーを置く） |
クラウドのマネージドレジストリ（CodeArtifact, Artifact Registry, Artifactory SaaS）は公開エンドポイント＋認証なので「認証の壁」だけ。VPC 内などインターネットから到達できないレジストリは「到達性の壁」も越える必要があります。まず自分がどちらかを見極めます。
1. registries ブロックの基本
dependabot.yml のトップレベルに registries を定義し、updates の各ジョブから紐づけます。
version: 2
registries:
my-npm:
type: npm-registry
url: https://npm.example.com
token: ${{secrets.DEPENDABOT_NPM_TOKEN}} # ← Dependabot シークレットを参照
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
registries:
- my-npm # このジョブで使うレジストリ
最重要：
${{secrets.NAME}}が参照するのは Dependabot 専用のシークレットストアです。場所は Settings → Secrets and variables → Dependabot（リポジトリまたは Organization）。通常の Actions シークレットとは別物で、Dependabot のジョブからは Actions シークレットは見えません。これは「侵害された依存が、CI 経由で秘密情報を盗み出す」のを防ぐ設計です。シークレットは GitHub に届く前に暗号化され、Dependabot が使う瞬間まで暗号化されたままです。
2. type 別 認証リファレンス
type ごとに使える認証フィールドが決まっています（公式）。よく使うものを表にまとめます。
type | 主な認証フィールド | replaces-base | 備考 |
|---|---|---|---|
npm-registry | username/password または token | ✓ | npm/yarn/pnpm |
docker-registry | username/password、または ECR 用の静的AWS認証 | ✓ | コンテナイメージ |
maven-repository | username/password、または OIDC（tenant-id/client-id） | ✓ | Maven/Gradle |
python-index | username/password、token、または OIDC | ✓ | pip/uv/poetry |
nuget-feed | username/password、token、または OIDC | ✗ | .NET |
rubygems-server | username/password または token | ✓ | Bundler |
composer-repository | username/password | — | PHP（GitHub PAT 可） |
cargo-registry | token（任意で registry） | — | Rust |
terraform-registry | token | — | Terraform |
git | username/password | — | Git 由来の依存 |
helm-registry | username/password | — | HTTP Basic 認証のみ・OCI 非対応 |
hex-organization | organization/key | — | Elixir |
hex-repository | repo/url/auth-key（任意で public-key-fingerprint） | — | Elixir 自前リポジトリ |
goproxy-server | username/password | — | Go モジュールプロキシ |
pub-repository | url/token | — | Dart/Flutter |
replaces-base: trueは、「公開レジストリ（例：registry.npmjs.org）の代わりにこの private レジストリを既定として使う」指定です。社内ミラーを唯一の取得元にしたいときに使います。
3. GitHub Packages は“特別扱い”（registries 不要）
GitHub Packages / GitHub Container Registry（ghcr.io）は、registries エントリを書く必要がありません。
公式：「Dependabot は
GITHUB_TOKENで自動的に認証できる。これは GitHub Actions ワークフローが使うのと同じ『Manage Actions access』の付与を利用する。PAT やdependabot.ymlの registry エントリは不要」。
つまり、同じ Organization の GitHub Packages に置いた内部パッケージは、追加設定ゼロで更新対象になります。アクセス権はリポジトリの「Manage Actions access」で管理します。これは GitHub エコシステムに寄せる最大のメリットの一つです。
4. OIDC で“静的トークンを置かない”
静的なトークン/パスワードは、失効管理・漏洩リスク・棚卸しの手間がつきまといます。OIDC（OpenID Connect）対応のレジストリなら、短命の連携トークンで認証でき、長期シークレットを保管しない設計にできます。
公式が OIDC 対応を挙げているのは次のとおりです。
- AWS CodeArtifact
- Azure DevOps Artifacts
- Cloudsmith
- Google Cloud Artifact Registry
- JFrog Artifactory
maven-repository / python-index / nuget-feed などで tenant-id / client-id を使う形が該当します。セキュリティとコスト効率（鍵管理の運用負荷削減）の両面で、可能なら OIDC を第一選択にしてください。鍵レス CI/CD と同じ思想です。
5. クラウド別の実例
5.1 AWS CodeArtifact（npm / pip）
version: 2
registries:
codeartifact-npm:
type: npm-registry
url: https://my-domain-111122223333.d.codeartifact.ap-northeast-1.amazonaws.com/npm/my-repo/
token: ${{secrets.DEPENDABOT_CODEARTIFACT_TOKEN}}
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
registries: ["codeartifact-npm"]
CodeArtifact はOIDC にも対応しているため、可能なら静的トークンではなく OIDC 連携に寄せます。
5.2 Amazon ECR（Docker・静的AWS認証）
registries:
ecr:
type: docker-registry
url: 111122223333.dkr.ecr.ap-northeast-1.amazonaws.com
username: ${{secrets.DEPENDABOT_AWS_ACCESS_KEY_ID}}
password: ${{secrets.DEPENDABOT_AWS_SECRET_ACCESS_KEY}}
docker-registry はECR からのプルに静的 AWS 認証を使えます（最小権限の読み取り専用 IAM を推奨）。Docker ベースイメージ更新の運用はDocker ベースイメージ更新ガイドへ。
5.3 JFrog Artifactory（npm 例）
registries:
artifactory-npm:
type: npm-registry
url: https://artifactory.example.com/artifactory/api/npm/npm-virtual
username: ${{secrets.DEPENDABOT_ARTIFACTORY_USER}}
password: ${{secrets.DEPENDABOT_ARTIFACTORY_TOKEN}}
replaces-base: true
Artifactory もOIDC 対応。ガバナンス要件が厳しい組織ほど OIDC を選ぶ価値があります。
6. 到達性の壁：self-hosted ランナー
ここまでは「認証」の話。VPC 内・社内ネットワークのみで到達できるレジストリは、GitHub-hosted ランナーからはそもそも届きません。このとき self-hosted ランナーで Dependabot を走らせます。
6.1 必要になる場面
- インターネット非公開の社内 Artifactory / Nexus / プライベート PyPI / 社内 Go プロキシ
- VPC エンドポイント経由でしか到達できない CodeArtifact / Artifact Registry
6.2 セットアップの要点（公式）
- 前提：Dependabot が有効・GitHub Actions が有効。
- ランナーを用意：リポジトリまたは Organization レベルで self-hosted ランナーを登録。
- 環境要件を満たす：Dependabot ジョブが動く実行環境（必要なツール・ネットワーク）。
dependabotラベルを付与：単一リポジトリならdependabotラベルを、Organization なら所定のラベルを付ける。
ハマりどころ（必読）：この機能を有効にすると、Dependabot ジョブは
dependabotラベルを持つランナーでしか実行されません。ラベルを付け忘れると、ジョブはいつまでもキューされ続ける（＝何も起きないように見える）重大な落とし穴です。有効化前に「ラベル付きランナーが本当に存在するか」を必ず検証してください。
6.3 ネットワークとセキュリティ設計
- ネットワーク：ランナーから GitHub と対象レジストリの両方に到達できること。Firewall/プロキシの許可リストを整える。
- 隔離：self-hosted ランナーは、Dependabot が信頼境界の外（更新後の依存）に触れ得る実行環境です。他用途と共有せず隔離し、最小権限で運用する（ネットワークも認証情報も）。本番の機密に触れられる場所で動かさない。
7. セキュリティ・チェックリスト
- 認証情報はすべて Dependabot シークレット（Actions シークレットに置かない・ハードコードしない）
- 可能なレジストリは OIDC（CodeArtifact / Azure Artifacts / Cloudsmith / Artifact Registry / Artifactory）で静的トークンを排除
- トークンは最小権限・読み取り専用（更新の取得に必要な範囲だけ）
- GitHub Packages は
GITHUB_TOKEN自動認証を活用し、余計な PAT を作らない - self-hosted ランナーは隔離・最小権限、
dependabotラベルを検証 - 認証エラー時は4分類のエラーコードで切り分け
8. FAQ
Q. registries の token はどこに置きますか？ A. Dependabot シークレット（Settings → Secrets and variables → Dependabot）です。Actions シークレットとは別ストアで、Dependabot ジョブからは Actions シークレットは参照できません。
Q. GitHub Packages の内部パッケージにも registries 定義が要りますか？
A. 不要です。Dependabot が GITHUB_TOKEN で自動認証します。アクセスは「Manage Actions access」で管理します。
Q. 静的トークンを置きたくありません。 A. OIDC 対応レジストリ（CodeArtifact / Azure Artifacts / Cloudsmith / Google Artifact Registry / JFrog Artifactory）なら OIDC 連携で長期シークレットを保管せずに済みます。
Q. 設定したのに private_source_not_reachable になります。
A. 認証ではなく到達性の問題です。私設網のレジストリなら self-hosted ランナーを立て、ランナーに dependabot ラベルを付けてください（ラベルが無いとジョブが無限キューになります）。
Q. self-hosted ランナーは普段の CI ランナーと共有してよい？ A. 推奨しません。Dependabot 用は隔離・最小権限で運用し、本番機密に触れられない環境にしてください。