GitHub ActionsとGitHub Packagesで築く！プライベート依存関係の要塞：セキュアかつ高速なCI/CDパイプライン構築術
テックリードの皆さん、日々のビルド時間と依存関係の管理に頭を悩ませていないだろうか？
「社内共通のnpmパッケージを別リポジトリで管理したいが、アクセス権の制御が面倒くさい」
「CI/CDからプライベートレジストリにアクセスするたびに、漏洩リスクのあるパーソナルアクセストークン（PAT）をハードコーディングしていないか？」
その場しのぎのスクリプトや、セキュリティホールになりかねない設定は、今日で終わりにする。
今回は、GitHub ActionsとGitHub Packagesを完璧に連携させ、社内プライベートパッケージのインストールを極限までセキュアかつ高速化する実践的アプローチを伝授する。
—
1. なぜ「GitHub Packages + GitHub Actions」なのか？
モノレポ全盛の時代であっても、ドメイン駆動設計や組織の関心の分離の観点から、共通ライブラリを別リポジトリ（ポリレポ）として切り出すアーキテクチャは依然として根強い。ここで問題になるのが「認証の壁」だ。
サードパーティのレジストリ（ArtifactoryやNexusなど）を立てるのも手だが、インフラ管理コストが増大する。その点、GitHubエコシステム内で完結させれば、以下の圧倒的なメリットを享受できる。
- 同一IAM基盤による強固なセキュリティ: GitHubの組織権限（Teams）と完全に連動。
- 短命なトークン（`GITHUB_TOKEN`）の自動発行: PATの管理・ローテーション地獄から解放される。
- 通信の最適化: GitHubのインフラ内での通信となるため、レイテンシが極めて低い。
—
2. チーム開発で絶対に守るべきセキュリティ・設計ルール
実装に入る前に、プロとしてチームに強制すべき設計ルールを共有する。
1. PAT（Personal Access Token）の完全排除: 人間に紐付くトークンをCI/CDや設定ファイルに埋め込んではならない。必ず自動発行される `GITHUB_TOKEN` を使う。
2. 最小権限の原則（Principle of Least Privilege）: Actionsのトークンには、必要なスコープ（`packages:read` 等）のみを付与する。
3. スコープ付きパッケージの徹底: npmなら `@my-org/my-package` のようにスコープを切ることで、パブリックレジストリとの名前空間の衝突（Dependency Confusion攻撃）を物理的に防ぐ。
—
3. 実践：npmパッケージのプライベート管理と認証突破
具体的な設定ファイルを構築していこう。今回はNode.js（npm）環境をベースに解説するが、MavenやNuGetでも思想は全く同じだ。
① `.npmrc` の構成（プロジェクトルート）
GitHub Packagesにアクセスするためには、どのスコープのパッケージをどのURLから取得するかを `.npmrc` で指定する必要がある。
@my-org スコープのパッケージは GitHub Packages から取得する
@my-org:registry=https://npm.pkg.github.com/
上記レジストリへのアクセス時に GitHub Actions が自動生成するトークンを使用する
//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}
Tip: ローカル開発時は環境変数 `NODE_AUTH_TOKEN` に自身のPATを設定することでシームレスに開発できる。
② GitHub Actions ワークフローの設定（YAML）
ここが本記事の核心だ。`GITHUB_TOKEN` に適切な権限を与え、安全にパッケージをインストールするパイプラインを構築する。
name: CI with Private Packages
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
name: Build & Test
runs-on: ubuntu-latest
# 1. GITHUB_TOKEN に付与する権限を明示的に定義（セキュリティの要）
permissions:
contents: read # リポジトリのコードをチェックアウトするために必要
packages: read # GitHub Packages からプライベートパッケージをダウンロードするために必要
steps:
- name: Checkout Repository
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: ’20’
# 2. ここを指定することで、setup-node が自動的に .npmrc に認証情報を注入してくれる
registry-url: ‘https://npm.pkg.github.com/’
scope: ‘my-org’
- name: Cache dependencies
uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles(‘/package-lock.json’) }}
restore-keys: |
${{ runner.os }}-node-
- name: Install Dependencies
run: npm ci
env:
# 3. setup-node が設定したスコープ用トークンを明示的に渡す
NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Run Tests
run: npm test
—
4. プロが実践する「ワンランク上の」最適化ハック
上記の基本構成に加えて、現場の生産性を劇的に高めるためのプロのテクニックを授ける。
ハック1: クロスリポジトリ間アクセスの罠を回避する
別リポジトリでホストされているプライベートパッケージをインストールする場合、デフォルトの状態では `GITHUB_TOKEN` がそのリポジトリへの読み取り権限を持たないケースがある。
対策: パッケージをホストしているリポジトリ側の設定で、利用側（コンシューマー）のリポジトリからのアクセスを明示的に許可する必要がある。
> `Package Settings` -> `Manage Actions access` -> 利用側リポジトリを追加し、ロールを `Read` に設定。
これを忘れると、CI上で突然 `404 Not Found` や `401 Unauthorized` が発生し、デバッグの迷宮に迷い込むことになる。
ハック2: 依存関係キャッシュの極限最適化
`npm ci` は高速だが、プライベートパッケージが多いプロジェクトではネットワークI/Oがボトルネックになる。`actions/cache` を用いて `~/.npm` をキャッシュする際、ロックファイルのハッシュをキーに含めるのは定石だが、パッケージのバージョンアップ頻度が高いモジュールは別管理にするなどの設計を取り入れると、ビルド時間をさらに数秒〜数十秒削り出せる。
—
5. まとめ
GitHub ActionsとGitHub Packagesの連携は、正しく設計すれば「セキュア」と「高速」を高い次元で両立できる。
今回紹介した `permissions` の厳格な定義と、`setup-node`（あるいは他言語の対応アクション）を介した `GITHUB_TOKEN` の伝播は、現代のCI/CDパイプラインにおけるゴールドスタンダードだ。
インフラの管理工数をゼロにしつつ、堅牢なサプライチェーンセキュリティを手に入れる。
今すぐあなたのチームのパイプラインを見直し、レガシーな認証方式をパージしてほしい。開発スピードの桁違いの向上を実感できるはずだ。