GitHub ActionsでCopilot CLIがPAT不要に：GITHUB_TOKEN対応の変更点と管理者の注意点

GitHub Actions で Copilot CLI を使うたびに personal access token（PAT）を発行し、Secrets に保存していたチームにとって、今回の「Copilot CLI no longer needs a personal access token in GitHub Actions」は運用負荷とセキュリティリスクを下げる重要な更新です。結論から言うと、Copilot CLI は GitHub Actions の組み込み GITHUB_TOKEN で実行できるようになり、長期間有効な PAT を自動化用に管理する必要がなくなりました。(The GitHub Blog)

ただし、「PAT を消せば終わり」ではありません。Organization 所有リポジトリでは Copilot CLI の利用分が組織に直接課金されるため、管理者は Copilot ポリシー、copilot-requests: write 権限、AI クレジットの利用状況、ワークフローのトリガー設計をあわせて確認する必要があります。(The GitHub Blog)

GitHub の新機能・変更点：「Copilot CLI no longer needs a personal access token in GitHub Actions」で確認すべきポイント

GitHub は 2026年7月2日、GitHub Actions 内で Copilot CLI を実行する際に、従来の personal access token ではなく、組み込みの GITHUB_TOKEN を使えるようになったことを発表しました。これにより、ワークフローで Copilot CLI を呼び出すために個人ユーザーの PAT を作成・保管・ローテーションする必要がなくなります。(The GitHub Blog)

変更点を実務目線で整理すると、次のようになります。

確認項目	変更前の考え方	変更後の考え方
認証	PAT を Secrets に保存して Copilot CLI を実行	GitHub Actions の GITHUB_TOKEN で認証可能
認証主体	PAT を作成した個人ユーザー	ワークフロー実行時の GitHub Actions 側トークン
Secrets 管理	Copilot CLI 用の PAT を作成・保存・更新	追加 Secrets なしで構成可能
Organization リポジトリの課金	PAT 所有者の Copilot seat に紐づく	組織に直接メーターされる
必要な設定	PAT の発行、権限設定、保管	Copilot ポリシー有効化と copilot-requests: write
主な注意点	PAT 漏えい、退職者トークン、権限過多	組織課金、AI クレジット消費、ワークフロー権限

今回の更新は、特に複数リポジトリで Copilot CLI を自動実行している組織に大きな意味があります。個人に紐づく PAT を使うと、ユーザーの異動・退職・権限変更・トークン期限切れが CI/CD の停止要因になります。GITHUB_TOKEN を使えば、ワークフローごとに生成される短命かつスコープされたトークンを利用できるため、長期認証情報を Secrets に置き続ける設計から脱却できます。(GitHub Docs)

Copilot CLI を GitHub Actions で使うと何が便利になるのか

Copilot CLI は、ターミナルから GitHub Copilot を利用するためのコマンドラインツールです。質問への回答だけでなく、コードの作成・修正、GitHub.com とのやり取り、Pull Request 作成などのタスク支援に使えます。プログラム的に単発プロンプトを渡して実行する使い方もできるため、GitHub Actions との相性が高い機能です。(GitHub Docs)

たとえば、次のような自動化が考えられます。

活用シーン	具体例	注意点
変更内容の要約	Push 後にコミット差分を要約する	機密情報をプロンプトに含めない
PR 補助	テスト失敗時に原因候補をコメント用に整理する	自動投稿前に人間のレビューを挟む設計が安全
リファクタリング支援	定期的に改善候補を抽出する	自動修正まで許可する場合は権限を厳格に制限
ドキュメント更新	変更差分から README 更新案を生成する	生成内容をそのまま main に反映しない
障害調査補助	CI ログを要約し、調査観点を出す	ログにシークレットが出ない設定を確認する

今回の変更で、これらの処理を実行するために個人 PAT を別途用意する必要がなくなりました。特に「特定の管理者が作った PAT に全自動化が依存している」構成を避けられる点が実務上の大きなメリットです。

GITHUB_TOKEN を使うための前提条件

GitHub Actions で Copilot CLI を GITHUB_TOKEN 認証で使うには、単にワークフロー内で環境変数を渡すだけでは不十分です。公式情報では、Organization のワークフローで利用する場合、Copilot CLI を組織課金で使うためのポリシーが有効になっている必要があります。この設定は、既存の「Copilot CLI」ポリシーが有効な組織では既定で有効になるとされていますが、管理者は Organization のポリシー画面で明示的に確認しておくべきです。(The GitHub Blog)

確認すべき前提は次の4つです。

前提条件	確認する人	確認内容
Copilot CLI ポリシー	Organization owner / 管理者	「Allow use of Copilot CLI billed to the organization」が有効か
ワークフロー権限	リポジトリ管理者 / 開発者	copilot-requests: write を付与しているか
Copilot CLI バージョン	開発者 / CI 管理者	GITHUB_TOKEN 認証に対応した最近のバージョンか
課金・予算管理	管理者 / 経理・FinOps 担当	組織課金、利用ダッシュボード、コストセンターを確認しているか

GitHub Docs では、Copilot CLI を直接 workflow step で呼び出す場合、copilot-requests: write 権限が必要であり、GITHUB_TOKEN が自動的に認証を処理するため追加 Secrets は不要と説明されています。また、GITHUB_TOKEN 認証には最近の Copilot CLI が必要で、copilot update または npm install -g @github/copilot による更新が案内されています。(GitHub Docs)

実装イメージ：PAT を使わない GitHub Actions ワークフロー

最小構成の考え方は、ワークフローに copilot-requests: write を付与し、Copilot CLI 実行時に GITHUB_TOKEN を環境変数として渡すことです。

name: Copilot CLI example

on:
  push:
    branches:
      - main

permissions:
  contents: read
  copilot-requests: write

jobs:
  copilot:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v6

      - name: Install Copilot CLI
        run: npm install -g @github/copilot

      - name: Summarize commit changes
        run: copilot --yolo -p "Summarize the changes in this commit"
        env:
          GITHUB_TOKEN: ${{ github.token }}

ここで重要なのは、permissions を明示している点です。GitHub Actions では便利さを優先して権限を広めにしがちですが、Copilot CLI はリポジトリ内容を読み取り、設定次第ではファイル変更やコマンド実行にも関わるエージェント型ツールです。必要な権限だけを与える設計にしておくことが、PAT 不要化後も変わらない基本です。(GitHub Docs)

また、GitHub Docs の例では非対話環境である GitHub Actions では --yolo フラグにより対話プロンプトを抑止する説明があります。ただし、--yolo や自動承認系のオプションは Copilot に広い実行権限を与える可能性があるため、使うワークフロー、対象ブランチ、トリガー、権限を慎重に絞るべきです。(GitHub Docs)

PAT から GITHUB_TOKEN に移行する判断基準

すべてのケースで即時移行すべきというより、まずは「GitHub Actions 内で Copilot CLI を使っているか」「Organization 所有リポジトリか」「自動実行の権限がどこまで必要か」を確認します。

状況	推奨判断
Organization リポジトリで Copilot CLI を自動実行している	GITHUB_TOKEN への移行を優先
個人 PAT を複数リポジトリで使い回している	早めに棚卸しし、廃止計画を作る
退職者・異動者が作成した PAT が残っている可能性がある	Secrets と audit log を確認して削除
Copilot CLI がファイル変更や PR 作成まで行う	いきなり完全自動化せず、レビュー工程を残す
フォークからの Pull Request で実行される	高リスク。トリガーと権限を再設計する
利用量や費用をまだ可視化していない	移行前に予算・利用監視を整備する

特に避けたいのは、「PAT が不要になったから安全になった」と短絡的に判断することです。認証情報の管理リスクは下がりますが、Copilot CLI が自動ワークフロー内で動くこと自体のリスクは残ります。GitHub Docs でも、Copilot CLI はリポジトリ内容の読み取りや変更が可能なエージェント型ツールであり、誤設定されたワークフローでは意図しない変更が発生し得ると説明されています。(GitHub Docs)

Organization 管理者が最初に確認すべきこと

管理者は、今回の変更を「開発者の便利機能」として放置せず、認証・権限・課金・監査の4点で確認する必要があります。

Copilot CLI の組織ポリシーを確認する

Organization 所有リポジトリで GITHUB_TOKEN を使って Copilot CLI を実行するには、「Allow use of Copilot CLI billed to the organization」ポリシーが有効である必要があります。既存の Copilot CLI ポリシーが有効な場合は既定で有効になるとされていますが、実運用では明示的に確認しておくと安心です。(The GitHub Blog)

確認時は、次の観点で見てください。

確認項目	見るべきポイント
ポリシーの有効状態	Organization 全体で許可するのか、一部リポジトリから始めるのか
管理者の責任範囲	Copilot 管理者、Actions 管理者、課金管理者の役割分担
既存ワークフロー	PAT を使っている Copilot CLI ワークフローの有無
利用者への周知	Secrets 追加が不要になったこと、ただし権限設計が必要なこと

Secrets に残った PAT を棚卸しする

今回の更新で不要になるのは、GitHub Actions から Copilot CLI を呼び出すためだけに作成していた PAT です。既存の Secrets に COPILOT_TOKEN、GH_TOKEN、GITHUB_PAT、PERSONAL_ACCESS_TOKEN のような名前で保存されている場合、用途を確認しましょう。

棚卸しでは、次のように分類すると進めやすくなります。

分類	対応
Copilot CLI 専用 PAT	GITHUB_TOKEN 移行後に削除候補
GitHub API 操作用 PAT	必要権限と期限を再確認
用途不明の PAT	ワークフロー参照・作成者・最終利用日を確認
退職者・異動者由来の PAT	影響範囲を確認し、原則廃止
権限が広すぎる PAT	Fine-grained PAT や GitHub App など代替を検討

PAT の削除は、いきなり本番リポジトリで行うのではなく、対象ワークフローを GITHUB_TOKEN に移行し、数回の実行で問題がないことを確認してから進めるのが安全です。

課金と AI クレジットの見え方を確認する

Organization 所有リポジトリで GITHUB_TOKEN を使う場合、Copilot CLI の AI クレジット消費は組織に直接メーターされます。GitHub の説明では、この方式では個人ユーザーに費用が紐づかないため、ユーザーレベルの予算は考慮されません。(The GitHub Blog)

そのため、管理者は次の対策を組み合わせる必要があります。

対策	目的
Organization の billing / usage dashboard を確認	利用量の増加傾向を把握する
コストセンターを設定	部門・組織単位で費用を割り当てる
予算・アラートを設定	想定外の消費を早期に検知する
セッション上限を指定	1回の Copilot CLI 実行で使う AI クレジットを抑える
ワークフロー実行回数を制御	無駄な定期実行や重複実行を避ける

GitHub の Cost centers は、利用量と支出をビジネス単位に割り当て、予算を適用するための仕組みです。Enterprise Cloud では、組織・リポジトリ・ユーザーなどのリソースをコストセンターに含めて、費用配賦や予測に使えます。(GitHub Docs)

開発者がワークフローで注意すべきこと

開発者側の最大の変更点は、Copilot CLI 用に PAT を作らずに済むことです。ただし、ワークフローの書き方にはいくつか注意があります。

copilot-requests: write を明示する

Copilot CLI が Copilot リクエストを送るには、ワークフローに copilot-requests: write 権限が必要です。contents: read などの既存権限だけでは動かない可能性があります。(GitHub Docs)

permissions:
  contents: read
  copilot-requests: write

ポイントは、「動かすために広く権限を与える」のではなく、「必要な権限を明示して最小化する」ことです。Copilot CLI にファイル変更、PR 作成、Issue コメントなどをさせる場合は、それぞれ必要な権限を個別に検討してください。

Copilot CLI を最新化する

GITHUB_TOKEN 認証を使うには、最近の Copilot CLI が必要です。公式情報では、copilot update で更新するか、npm install -g @github/copilot で最新版を再インストールする方法が案内されています。(The GitHub Blog)

CI 内で毎回 npm install -g @github/copilot を実行する構成はシンプルですが、再現性を重視する場合はバージョン固定や検証済みランナーイメージの利用も検討しましょう。最新版追従を優先するのか、安定性を優先するのかは、ワークフローの重要度で判断します。

pull_request トリガーでは特に慎重にする

GitHub Docs では、Copilot CLI を workflow step から直接呼び出すとワークフロー環境への広いアクセスを持つため、トリガーと権限を慎重に確認するよう警告しています。特に fork からの Pull Request で実行されるワークフローは、プロンプトインジェクションなどのリスクが高いとされています。(GitHub Docs)

実務では、次のような設計が安全です。

リスクのある設計	改善例
fork からの PR で Copilot CLI を自動実行	push や内部ブランチ限定にする
生成結果を自動コミット	PR 作成までに留め、人間のレビューを必須にする
contents: write を常時付与	読み取りだけで足りる処理は contents: read にする
--yolo で広範な作業を任せる	プロンプトと対象ディレクトリを絞る
すべての変更差分やログをプロンプトに入れる	秘密情報や不要なログを除外する

コスト管理ではセッション上限を活用する

Copilot CLI は、対話やプログラム実行ごとに AI クレジットを消費します。GitHub Docs では、AI クレジットは AI モデルとのやり取りのコストを追跡する単位であり、利用量はモデルと処理トークン数によって変わると説明されています。(GitHub Docs)

GitHub Actions のような非対話環境では、想定外に大きなログや差分を Copilot CLI に渡すと、1回の実行で消費量が膨らむ可能性があります。その対策として、Copilot CLI には AI credit session limit を設定する方法があります。非対話モードでは --max-ai-credits=NUMBER を指定し、上限に達すると実行が終了します。なお、このセッション上限は public preview であり、応答中に上限へ達した場合は実際の使用量が設定値を少し超える可能性があります。(GitHub Docs)

copilot -p "Summarize the CI failure and suggest next investigation steps" --max-ai-credits 50

GitHub Actions で使う場合は、次のようにプロンプトと上限をセットで設計すると管理しやすくなります。

- name: Analyze CI failure with limit
  run: |
    copilot --yolo \
      -p "Summarize the latest test failure logs and list likely causes. Do not modify files." \
      --max-ai-credits 50
  env:
    GITHUB_TOKEN: ${{ github.token }}

この例では「ファイルを変更しない」とプロンプトに明記しています。ただし、プロンプトだけに安全性を依存するのは不十分です。書き込み権限を与えない、対象ログを絞る、実行トリガーを限定する、といったワークフロー側の制御を優先してください。

PAT 不要化で失敗しやすいポイント

今回の更新は便利ですが、移行時にはいくつかの落とし穴があります。

失敗しやすいポイント	起きる問題	対策
copilot-requests: write を忘れる	Copilot リクエストが失敗する	permissions に明示する
古い Copilot CLI を使う	GITHUB_TOKEN 認証に対応せず失敗する	copilot update または再インストール
PAT を残したままにする	使われていない長期 Secrets が残る	移行後に Secrets を棚卸し
組織課金を確認しない	予想外の AI クレジット消費に気づきにくい	usage dashboard とコストセンターを確認
fork PR で実行する	外部入力による悪用リスクが上がる	トリガーを制限し、権限を最小化
自動生成結果を無条件で反映する	品質・セキュリティ問題が混入する	PR 化してレビューを必須にする
ログを丸ごと渡す	秘密情報や不要情報を Copilot に渡す	ログマスキングと入力範囲の制限

特に注意したいのは、「PAT がなくなったから GitHub Actions のセキュリティ設計も楽になる」という誤解です。認証情報の保管リスクは下がりますが、Copilot CLI を自動実行する設計では、プロンプト、入力データ、権限、トリガーのすべてがリスク要因になります。

GitHub Agentic Workflows も検討する

GitHub Docs では、多くの自動化ユースケースでは workflow step で copilot を直接呼び出すよりも、GitHub Agentic Workflows の利用が推奨されています。Agentic Workflows は既定で GITHUB_TOKEN 認証を使い、自動化環境向けの追加ガードレールを備えていると説明されています。(GitHub Docs)

実務上は、次のように使い分けるとよいでしょう。

選択肢	向いているケース
Copilot CLI を直接 workflow step で実行	既存ワークフローに小さく組み込みたい、単純な要約や分析をしたい
GitHub Agentic Workflows	自動化の安全性やガードレールを重視したい、複雑なエージェント処理を扱いたい
人間がローカルで Copilot CLI を実行	本番ワークフローに入れる前の検証、プロンプト設計、権限確認をしたい

小さく試す段階では Copilot CLI の直接実行でも構いませんが、組織全体に広げる場合は Agentic Workflows の利用可否も検討対象に入れるべきです。

移行手順：既存ワークフローを安全に切り替える

既存の PAT ベース運用から移行する場合は、次の順序で進めると安全です。

手順	作業内容	確認ポイント
1	Copilot CLI を使っているワークフローを洗い出す	copilot、COPILOT_TOKEN、GH_TOKEN などで検索
2	Organization ポリシーを確認する	組織課金で Copilot CLI を許可しているか
3	ワークフロー権限を追加する	copilot-requests: write を明示
4	PAT 参照を GITHUB_TOKEN に置き換える	Secrets ではなく ${{ github.token }} を利用
5	Copilot CLI を更新する	CI 上で最近のバージョンを使う
6	小さな対象でテスト実行する	push 限定、読み取り権限中心で確認
7	AI クレジット消費を確認する	usage dashboard やコストセンターで確認
8	不要になった PAT を削除する	削除前に依存ワークフローがないか確認
9	運用ルールを文書化する	トリガー、権限、レビュー、上限値を明記

この移行で最も大事なのは、Secrets の置き換えだけでなく、ワークフローの安全性を同時に見直すことです。PAT 不要化は良い機会なので、不要な write 権限、危険な pull_request トリガー、無制限のログ投入、放置された Secrets をまとめて整理しましょう。

まず管理者・開発者が取るべき行動

今回の「Copilot CLI no longer needs a personal access token in GitHub Actions」は、GitHub Actions で Copilot CLI を安全かつ管理しやすく使うための実務的な改善です。個人 PAT を使わず GITHUB_TOKEN で認証できるようになったことで、長期トークンの保管・ローテーション・退職者対応といった運用リスクを下げられます。(The GitHub Blog)

一方で、Organization リポジトリでは利用分が組織に直接メーターされ、ユーザー単位の予算では制御できない点に注意が必要です。コストセンター、利用ダッシュボード、セッション上限、ワークフロー権限を組み合わせて、使いやすさと統制のバランスを取ることが重要です。(GitHub Docs)

まずは、次の3つから始めてください。

• GitHub Actions 内で Copilot CLI 用 PAT を使っているワークフローを検索する
• Organization の Copilot CLI ポリシーと copilot-requests: write 権限を確認する
• テスト用リポジトリで GITHUB_TOKEN 認証に切り替え、利用量と実行結果を確認する

この3点を押さえれば、PAT 依存の自動化を減らしながら、GitHub Copilot CLI を GitHub Actions の中でより安全に活用できるようになります。