GitHub ActionsのCI/CDを、Personal Access Token(PAT)からGitHub Appsへ移行しよう! – より安全で、よりスッキリした自動化への第一歩
やあ、みんな! DevOpsの世界へようこそ。今回は、みんなが日々使っているであろうGitHub Actionsの認証方法について、ちょっと踏み込んだ話をしようと思うんだ。特に、Personal Access Token(PAT)を使っている君に、もっと安全で、もっと管理しやすい認証方法があることを伝えたいんだ。そう、その名も GitHub Apps だ!
「え、PATで動いてるから別に困ってないんだけど?」なんて声が聞こえてきそうだけど、ちょっと待ってほしい。PATは便利だけど、万が一漏洩した時のリスクって、実は結構大きいんだ。それに比べてGitHub Appsは、必要な権限だけをピンポイントで与えられるし、管理もずっと楽になる。
この記事では、PATの代わりにGitHub Appsを使ってGitHub Actionsを安全に実行する方法を、初心者さんにも分かりやすく、そして実践的に解説していくよ。「これさえ読めば、君のCI/CDライフが劇的に変わる!」って言っても過言じゃない。さあ、一緒に新しい自動化の世界へ飛び込もう!
なぜPATからGitHub Appsへ移行すべきなのか? – 安全性の向上と管理の効率化
まずは、なぜPATではなくGitHub Appsを使うべきなのか、その重要性を理解しておこう。
1. セキュリティリスクの最小化:最小権限の原則を徹底
PATは、発行したユーザーの権限をそのまま持ってしまう。つまり、もしPATが漏洩したら、そのPATを発行したユーザーと同じ権限で、リポジトリへのアクセスや操作が可能になってしまうんだ。これは、思わぬデータ改ざんや削除、あるいは悪意のあるコードのコミットにつながる可能性もゼロではない。
一方、GitHub Appsは、特定のアプリケーション(GitHub Actionsのワークフロー)に対して、必要な権限だけを付与できるんだ。例えば、「このリポジトリのコードを読み取る権限だけ」「このリポジトリのIssueを作成する権限だけ」といった具合に、用途に合わせて細かく設定できる。これにより、万が一GitHub Appsの認証情報が漏洩したとしても、被害を最小限に抑えることができる。まさに、「最小権限の原則」を実践できるわけだね。
2. 管理の簡素化と透明性の向上
PATは、個々のユーザーが発行・管理することが多い。そのため、誰がどのPATを発行して、それがどのリポジトリで使われているのか、把握するのが難しくなりがちだ。特にチームで開発している場合、PATの管理は「誰が最新のトークンを持っているか」「もう使わないトークンはないか」といった、煩雑なコミュニケーションを生む原因にもなる。
GitHub Appsは、組織やユーザーアカウントに紐づく「アプリケーション」として管理される。一度設定すれば、そのアプリケーションが複数のリポジトリで利用できる。誰がどのAppを使っているのか、そのAppにはどのような権限が付与されているのかが一元的に管理できるので、可視性が高く、管理も格段に楽になるんだ。
3. より高度な連携と自動化の可能性
GitHub Appsは、単に認証のためだけではなく、GitHub APIとの連携をより柔軟に行えるように設計されている。Webhooksを利用してイベント駆動型の処理を実装したり、より詳細なAPI操作を行ったりと、GitHub Appsを使いこなすことで、CI/CDパイプラインの自動化をさらに進化させることができるんだ。
GitHub Appsの基本:仕組みと設定の流れ
さて、GitHub Appsの重要性は理解してもらえたかな? では、具体的にどうやって設定していくのか、その基本的な流れを見ていこう。
1. GitHub Appsとは何か? – アプリケーションとしての認証
GitHub Appsは、GitHub上で動作する「アプリケーション」として登録される。このアプリケーションが、特定の権限を持ってGitHubリソースにアクセスできるようになるんだ。GitHub ActionsからこのGitHub Appsを利用する場合、Actionsは「このGitHub Appsとして」リポジトリにアクセスし、必要な操作を実行する、というイメージになる。
2. 設定の大まかな流れ
1. GitHub Appsの作成: GitHub上で新しいGitHub Appsを作成する。
2. 権限の設定: 作成したAppsに、必要な権限(Read, Writeなど)を付与する。
3. インストール: 作成したAppsを、利用したいリポジトリまたは組織にインストールする。
4. 認証情報の取得: GitHub Actionsで利用するための秘密情報(Private KeyやApp IDなど)を取得する。
5. GitHub Actionsでの利用: 取得した認証情報を使って、GitHub ActionsのワークフローからGitHub Appsとして認証し、リソースにアクセスする。
実践! GitHub ActionsでGitHub Apps認証を設定してみよう
ここからが本番だ! 具体的な設定手順を、ひとつずつ丁寧に見ていこう。
ステップ1:GitHub Appsの作成
まずは、GitHub Appsを作成するところから始めよう。
1. GitHubの右上にあるプロフィールアイコンをクリックし、「Settings」を選択する。
2. 左側のサイドバーにある「Developer settings」をクリックする。
3. 「GitHub Apps」を選択し、「New GitHub App」ボタンをクリックする。

(画像はGitHub公式ドキュメントより引用)
4. App name: アプリケーションの名前を入力する。(例: `my-github-actions-app`)
5. Homepage URL: (任意)アプリのホームURL。今回はActionsでの利用が主なので、必須ではない。
6. Webhook URL: (任意)今回はActionsでの利用が主なので、必須ではない。
7. Webhook secret: (任意)必須ではない。
8. Where can this GitHub App be installed?:
- 「Only on this account」: このアカウント(個人または組織)のみにインストール可能。
- 「On any account」: 他のユーザーや組織にもインストール可能。(公開アプリにする場合)
今回は、特定のプライベートリポジトリで利用したいので、「Only on this account」を選択するのが一般的だ。
9. Permissions (Repository permissions): ここが最も重要!
- Contents: コードの読み取りや書き込みが必要なら「Read & Write」または「Read-only」。
- Metadata: リポジトリのメタデータ(名前、説明など)の読み取りが必要なら「Read-only」。
- Pull requests: プルリクエストの作成や更新が必要なら「Read & Write」。
- Actions: GitHub Actionsのワークフローをトリガーしたり、ジョブのステータスを取得したりする必要がある場合は「Read & Write」。
- Issues: Issueの作成やコメントが必要なら「Read & Write」。
【重要】 ここでは、CI/CDで最低限必要な権限だけを付与するようにしよう。例えば、コードのデプロイだけなら「Contents」の「Read-only」、「Actions」の「Read-only」で十分かもしれない。もし、プルリクエストにコメントを付けたり、マージしたりするなら、「Pull requests」の「Read & Write」が必要になる。
【今回の例】 コードをチェックアウトし、ビルド・テストを実行するだけのシンプルなCIであれば、「Contents」の「Read-only」、「Metadata」の「Read-only」、「Actions」の「Read-only」あたりで十分だろう。
10. Event subscriptions: (任意)今回はActionsからの利用が主なので、こちらも必須ではない。
11. 「Create GitHub App」ボタンをクリックして作成完了。
ステップ2:認証情報の取得と設定
アプリを作成したら、GitHub Actionsから利用するための認証情報を取得する。
1. 作成したGitHub Appの詳細ページに移動する。
2. 「General」タブの下の方にある「Private keys」セクションで、「Generate a private key」ボタンをクリックする。
- 【注意】 この秘密鍵は、絶対に漏洩しないように厳重に管理すること! 誰かに見られたら、このAppsが持つ全ての権限を行使されてしまう可能性がある。
- 秘密鍵は `.pem` ファイルとしてダウンロードされる。
3. 同じく「General」タブで、「App ID」の値を控えておく。
4. 「Install App」ボタンをクリックし、このAppsをインストールしたいリポジトリまたは組織を選択する。
- 「Only on this account」で作成した場合、ここでインストールするリポジトリを選択する。
- 「Select repositories」から、特定のプライベートリポジトリを選択しよう。
ステップ3:GitHub ActionsでGitHub Appsを利用する
いよいよ、GitHub Actionsのワークフローで、作成したGitHub Appsを使って認証を行う。
PATの代わりにGitHub Appsを使うための最も簡単な方法は、`actions/checkout` アクションなどが内部的に利用している、GitHub Appsの認証を自動的に行ってくれるActionを利用することだ。
最も推奨される方法: `actions/checkout` アクションは、デフォルトで `GITHUB_TOKEN` という特別なトークンを使用する。この `GITHUB_TOKEN` は、ワークフローを実行しているリポジトリに紐づいた、自動生成されるトークンだ。しかし、この `GITHUB_TOKEN` は、リポジトリにインストールされたGitHub Appsの権限まで広げてくれるわけではない。
そこで、`actions/create-github-app-token` のようなActionを利用して、GitHub Appsの認証情報を元に、Actionsワークフローで利用できる一時的なトークンを生成するのが一般的だ。
例:`actions/create-github-app-token` を利用するワークフロー
まずは、GitHubリポジトリの Secrets に、先ほど取得した情報を登録しよう。
1. リポジトリの「Settings」>「Secrets and variables」>「Actions」に移動する。
2. 「New repository secret」ボタンをクリックし、以下の3つのSecretを作成する。
- `APP_ID`: ステップ2で控えたApp ID
- `PRIVATE_KEY`: ステップ2でダウンロードした `.pem` ファイルの内容をコピー&ペースト。(改行もそのままコピーすること!)
- `INSTALLATION_ID`: これは少し追加作業が必要。GitHub Appsの詳細ページで、「About」セクションにある「Install App」をクリックし、インストール済みのAppを選択すると、URLに `installation_id=XXXXX` のような形で表示される。もしくは、API経由で取得することも可能だが、ここでは手動で取得するのが一番手っ取り早い。

(画像はGitHub公式ドキュメントより引用。URLの `installation_id` を確認)
次に、ワークフローファイル (`.github/workflows/main.yml` など) を作成・編集する。
name: CI with GitHub Apps Authentication
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build_and_test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Generate GitHub App Token
id: generate_token
uses: actions/create-github-app-token@v1
with:
app-id: ${{ secrets.APP_ID }}
private-key: ${{ secrets.PRIVATE_KEY }}
installation-id: ${{ secrets.INSTALLATION_ID }}
- name: Use the generated token for API calls
run: |
# 生成されたトークンを環境変数として利用する
# このトークンは、GitHub Appsの権限でGitHub APIにアクセスできる
# 例: リポジトリの情報を取得する
curl -H “Authorization: token ${{ steps.generate_token.outputs.token }}” \
-H “Accept: application/vnd.github.v3+json” \
https://api.github.com/repos/${{ github.repository }}
# 例: プルリクエストにコメントを追加する (Pull Request権限が必要)
# echo “This is a test comment from GitHub Actions.” >> comment.txt
# curl -X POST \
# -H “Authorization: token ${{ steps.generate_token.outputs.token }}” \
# -H “Accept: application/vnd.github.v3+json” \
# https://api.github.com/repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/comments \
# -d ‘{“body”: “$(cat comment.txt)”}’
# もし、actions/checkout@v4 がリポジトリのApps権限を必要とする場合
# checkout アクション自体も、この生成されたトークンを指定して実行できる
# ただし、通常は GITHUB_TOKEN で十分な場合が多い
# – name: Checkout code with App Token (if GITHUB_TOKEN is not enough)
# uses: actions/checkout@v4
# with:
# token: ${{ steps.generate_token.outputs.token }}
- name: Run your build and test commands
run: |
echo “Running build and test…”
# ここに実際のビルドやテストコマンドを記述
# 例: npm install && npm run build && npm test
echo “Build and test completed successfully!”
解説:
- `actions/create-github-app-token@v1` アクションは、Secretsに登録した `APP_ID`, `PRIVATE_KEY`, `INSTALLATION_ID` を使って、GitHub Appsとしての認証を行い、一時的な access token を生成してくれます。
- 生成されたトークンは `steps.generate_token.outputs.token` で取得でき、これを `Authorization` ヘッダーに含めることで、GitHub APIへのリクエストが、このGitHub Appsの権限で行われるようになります。
- コメントアウトされている部分では、実際にAPIコールをして、リポジトリ情報を取得する例を示しています。もしプルリクエストにコメントを追加したい場合は、`Pull requests` の権限をAppsに付与し、コメントアウトを解除して実行してみてください。(ただし、`github.event.pull_request.number` は `pull_request` イベントでのみ有効です。)
- `actions/checkout@v4` は、通常は `GITHUB_TOKEN` で動作しますが、もしリポジトリにインストールされたGitHub Appsの権限でコードをチェックアウトする必要がある場合(例えば、リポジトリへの書き込み権限が必要な場合など)は、`with: token: ${{ steps.generate_token.outputs.token }}` のように明示的に指定することも可能です。
補足:`GITHUB_TOKEN` と GitHub Apps トークンの使い分け
- `GITHUB_TOKEN`:
- ワークフローを実行しているリポジトリに自動的に紐づくトークン。
- リポジトリの読み取り/書き込み権限(デフォルト)や、リポジトリにインストールされたGitHub Appsの権限の一部を持つ。
- リポジトリ固有の操作(コードのチェックアウト、Actionsの実行ステータスの更新など)には十分。
- 有効期限がない。
- GitHub Apps トークン (generated by `actions/create-github-app-token`):
- GitHub Appsとして認証されたトークン。
- Appsに付与された任意の権限でGitHub APIにアクセスできる。
- リポジトリを跨いだ操作や、より詳細なAPI操作(Issueの管理、Organizationの操作など)に必要。
- 有効期限がある(通常1時間)。
ほとんどの場合、`GITHUB_TOKEN` で十分ですが、より広範な権限や、リポジトリを跨いだ操作が必要な場合に、GitHub Appsトークンが強力な武器になります。
まとめ:より安全で、よりモダンなCI/CDへ
どうだったかな? GitHub Appsを使えば、PATの代わりに、より安全に、そしてより管理しやすくGitHub Actionsを動かせるようになるんだ。
- PATの漏洩リスクを回避し、最小権限の原則を徹底できる。
- 権限管理が一元化され、チームでの運用もスムーズになる。
- GitHub APIとの連携を強化し、自動化の幅が広がる。
最初は少し設定が複雑に感じるかもしれないけど、一度この仕組みを理解してしまえば、君のCI/CDパイプラインは格段に洗練されるはずだ。
「これをマスターすれば、毎日の作業が劇的に楽になりますよ」と、自信を持って言える。ぜひ、この機会にGitHub Appsでの認証を試してみてほしい。もし分からないことがあれば、いつでも聞いてくれ! 君のDevOpsライフが、より安全で、より快適なものになることを願っているよ!