脱・Personal Access Token：GitHub AppsでCI/CDのセキュリティを極限まで高める実践ガイド
テックリードの私たちが日々頭を悩ませる問題の一つに、「CI/CDパイプラインの権限管理」がある。
「とりあえず個人のPersonal Access Token（PAT）を発行してSecretsに放り込んでおくか」――もし、あなたのチームでまだこのアンチパターンがまかり通っているなら、今すぐそのパイプラインを止めてほしい。
PATは「作った個人の全権限」をそのまま引き継ぐ。退職したメンバーの古いPATが放置され、組織全体のリポジトリへのアクセス権が野良トークンとして残る……これはセキュリティ事故への片道切符だ。
本記事では、この悪夢を断ち切り、GitHub Appsを用いた最小権限のセキュアなCI/CD基盤を構築するための実践知を伝授する。
—
1. なぜ今、PATからGitHub Appsなのか？
実務において、CI/CDツール（GitHub Actionsなど）がリポジトリ操作を行うシーンは多岐にわたる。
- Release PRの自動作成
- 依存関係の脆弱性パッチの自動マージ
- 複数リポジトリにまたがるワークフローのトリガー
これらをPATで行う場合、以下の致命的な課題が生じる。
1. 過剰な権限（Over-privileged）: リポジトリの読み書きだけでなく、組織全体の管理権限まで持たせてしまいがち。
2. 属人化: 個人のアカウントに紐づくため、その人が異動・退職した瞬間にトークンが無効化、あるいはブラックボックス化する。
3. 監査の難しさ: 誰が・どの目的で発行したトークンなのかトレースしにくい。
対して、GitHub Appsを導入するメリットは圧倒的だ。
- ファイングレインな権限設定: 「特定のリポジトリの `contents: write` のみ」「Issues の読み取りのみ」といった極小のスコープを定義できる。
- 組織管理（Ownerless）: 個人に依存せず、GitHub Organizationの公式な「Bot」として振る舞う。
- 短期有効なトークン: GitHub Appsの認証プロセスでは、一時的なInstallation Access Token（有効期限1時間）が動的生成されるため、漏洩時のリスクが最小限に抑えられる。
—
2. 実践：GitHub Appsを用いた認証の全体像とセットアップ
まずは、GitHub上で専用のAppを作成し、シークレットを安全に取得するまでの手順を駆け足で解説する。
Step 1: GitHub Appの作成
1. Organizationの Settings > Developer settings > GitHub Apps > New GitHub App へ移動。
2. 以下の設定を行う：
- GitHub App name: `[your-org]-ci-bot` など一目でわかる名前。
- Webhook: 無効（Activeのチェックを外す）。
- Repository permissions: 必要最小限の権限を付与（例: `Contents: Read & write`, `Pull requests: Read & write`）。
3. 作成後、以下の2つを手元に控える。
- App ID
- Private Key（生成してダウンロードした `.pem` ファイル）
Step 2: リポジトリまたは組織のSecretsへの登録
ダウンロードしたプライベートキーの内容とApp IDを、GitHub ActionsのSecretsに登録する。
- `APP_ID`: App IDの数値
- `APP_PRIVATE_KEY`: `.pem` ファイルの中身（改行も含めてそのままペースト）
—
3. 神アクションの活用：`actions/create-github-app-token`
GitHub Appsの認証トークンを発行する自前スクリプトを書く必要はない。GitHub公式がメンテナンスしている神アクション `actions/create-github-app-token` を使えば、数行の記述で短命なアクセストークンを錬成できる。
以下のベストプラクティス構成例を見てほしい。
実用的なYAMLワークフロー設定例
このワークフローは、「PRがマージされた際に、自動でCHANGELOGを更新し、新しいタグとリリースノートを作成する」という実務によくあるシナリオを、GitHub Appsの権限で安全に実行するものだ。
name: Release Automation
on:
push:
branches:
- main
jobs:
release:
name: Generate Release & Changelog
runs-on: ubuntu-latest
steps:
# 1. 組織にインストールされたGitHub Appsから、短命のトークンを生成する
- name: Generate GitHub App Token
id: generate-token
uses: actions/create-github-app-token@v1
with:
app_id: ${{ secrets.APP_ID }}
private_key: ${{ secrets.APP_PRIVATE_KEY }}
# アクセスを許可するリポジトリを明示的に指定（セキュリティの多重防御）
owner: ${{ github.repository_owner }}
repositories: “core-api,frontend-app”
# 2. 生成したトークンを組み込んでチェックアウト
# デフォルトのGITHUB_TOKENではなく、Appsのトークンを使うことで
# 後続のワークフローやpushが「Appとしての権限」で行われる
- name: Checkout Repository
uses: actions/checkout@v4
with:
token: ${{ steps.generate-token.outputs.token }}
persist-credentials: true
# 3. Gitの設定とリリース処理の実行
- name: Setup Git User
run: |
git config –global user.name “ci-bot[bot]”
git config –global user.email “ci-bot[bot]@users.noreply.github.com”
- name: Run Release Script
env:
# スクリプト内でもAppsのトークンを利用
GITHUB_TOKEN: ${{ steps.generate-token.outputs.token }}
run: |
echo “Running automated release…”
# 例: conventional-changelog や semantic-release などの実行
# npm run release
—
4. プロの隠し技：チーム開発における運用のハックと安全網
GitHub Apps導入の効果を最大化し、開発スピードを落とさないための実践的なプラクティスを共有する。
ハック1: OrganizationレベルでのAppsインストール管理
個別のリポジトリごとにAppをインストールしていると、スケールした際に管理が破綻する。
GitHub Appの設定画面から “Only on this repository” ではなく “All repositories”（または “Select repositories” で組織標準テンプレートを指定）を選び、組織全体で一元管理できるようにせよ。これにより、新しくリポジトリを切った瞬間からセキュアなCI環境が自動継承される。
ハック2: `GITHUB_TOKEN` との使い分けの境界線
すべての操作にGitHub Appsを使う必要はない。
- `GITHUB_TOKEN`（デフォルト）: 同一リポジトリ内のビルド、テスト、Artifactのアップロード、PRに対する簡易的なコメントなど。
- `GitHub Apps Token`: 複数リポジトリへのまたがる操作、外部サービスとの連携、`contents: write` を伴うコミット・タグプッシュなど。
この境界線を明確に引くことが、パイプライン設計の美しさと安全性を両立させるコツだ。
—
テックリードからのメッセージ
セキュリティと開発スピードはトレードオフではない。「面倒だから」とPATを放置する文化は、いつか重大なインシデントとなってチームの足元をすくう。
GitHub Appsへの移行は、最初は少しの手間かもしれない。だが、一度この仕組みを構築してしまえば、あなたのチームのCI/CDパイプラインは「強固なセキュリティ基盤の上で、猛烈なスピードで価値をデリバリーし続ける」真のプロフェッショナルなシステムへと生まれ変わる。
今日からあなたのパイプラインの認証基盤をアップデートしよう。