はじめに
2026年7月2日、GitHub は Copilot CLI no longer needs a personal access token in GitHub Actions を発表しました。GitHub Actions のワークフローで Copilot CLI を動かす際、これまで必須だった個人アクセストークン（PAT）の発行・シークレット登録が不要になり、ワークフロー組み込みの GITHUB_TOKEN だけで認証できるようになったという内容です。
筆者は普段、複数のAI自動化パイプラインをCI/CD上で運用しており、「エージェントに書き込み権限を渡すワークフロー」の設計には人一倍気を遣ってきました。今回の変更は便利な半面、公式ドキュメントに 「forkからのプルリクエストで起動するワークフローは特に危険」 という一文がさらっと書かれており、見落とすと事故る設計になっています。実際に設定を検証しながら、その注意点を掘り下げます。
この記事で分かること
-
GITHUB_TOKENだけで Copilot CLI を Actions 上で動かす具体的な設定 - 個人PATが不要になった仕組みと組織課金の関係
- forkPRトリガーのワークフローで何が危険なのか（公式ドキュメントの原文引用付き）
TL;DR
- Copilot CLI は
copilot-requests: write権限を workflow のpermissionsに追加するだけで、GITHUB_TOKEN認証が使えるようになった（PAT・追加シークレット不要） - 組織のCopilotポリシーで課金設定を有効化するのが前提で、AI利用料は組織に直接課金される
- 公式ドキュメントは「Invoking Copilot CLI directly in workflow steps gives it broad access to your workflow environment」「Workflows triggered by pull requests from forks are particularly at risk」と明記しており、forkPRトリガーのワークフローに組み込むのは避けるべき
何が変わったのか
従来、GitHub Actions で Copilot CLI（@github/copilot）を動かすには、Copilot Requests 権限を持つ個人アクセストークンを発行し、リポジトリまたは Organization のシークレットとして登録する必要がありました。長期間有効なPATをCI側に保管する運用は、漏洩時の被害範囲・ローテーション漏れなど典型的な管理コストを伴います。
今回の変更で、ワークフローに組み込みで発行される一時トークン GITHUB_TOKEN に Copilot Requests の権限を付与できるようになり、PATの発行・保管が丸ごと不要になりました。GitHub公式ドキュメント（Using Copilot CLI in GitHub Actions）に掲載されている最小構成は以下の通りです。
name: Copilot CLI example
on: [push]
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: Run Copilot
run: copilot --yolo -p "Summarize the changes in this commit"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
ポイントは permissions ブロックの copilot-requests: write だけです。これを追加すれば、追加のシークレット登録なしで GITHUB_TOKEN がそのままCopilot CLIの認証に使えます（Node.js 22以降が必要）。
有効化と課金の仕組み
この認証方式を使うには、組織のCopilotポリシー設定で「Copilot CLI利用料を組織に課金する」設定を有効にする必要があります。CLIが消費したAIクレジットは個人のCopilotシート予算ではなく、組織に直接課金される仕組みです。個人PATを使う旧方式と違い、「誰の権限で叩いているか」ではなく「どのOrganizationの請求先か」で管理する発想に変わっている点は、コスト管理の実務上おさえておく価値があります。
ハマりポイント: forkPRトリガーは「特に危険」と明記されている
ここが今回一番伝えたいポイントです。公式ドキュメントには次の警告文がそのまま書かれています。
Invoking Copilot CLI directly in workflow steps gives it broad access to your workflow environment.
Workflows triggered by pull requests from forks are particularly at risk.
Review your workflow triggers and permissions carefully before using this approach.
— Using Copilot CLI in GitHub Actions（GitHub公式ドキュメント）
これは目新しい脆弱性の告知ではなく、GitHub Actions ではおなじみの「pull_request / pull_request_target トリガーとシークレット露出」の一般原則が、Copilot CLI にもそのまま当てはまるという注意喚起です。具体的には以下の構造がリスクになります。
- サンプルの
on: [push]を安易にon: pull_requestに変えて「PRの差分を要約させたい」ユースケースに流用する - 外部コントリビューターがforkから送ったPRでもワークフローが起動し、
copilot --yoloがPR内容（=第三者が自由に書けるテキスト）をプロンプトとして処理する -
--yoloは非対話環境向けに確認プロンプトを抑制するフラグのため、悪意あるプロンプトインジェクションが仕込まれたPR本文・コミットメッセージがあっても、人間の承認なしにCopilotがワークフロー環境内で行動してしまう可能性がある
GITHUB_TOKEN は本来forkPR起動時には読み取り専用に制限される設計ですが、pull_request_target を使うと base 側の権限を持つトークンが渡ってしまう、という古典的な事故パターンは Copilot CLI を挟んでも変わりません。「PATが要らなくなった＝安全になった」ではなく、「認証の手間が減った分、権限設計のミスがそのまま事故に直結する」と読み替えるべきだと感じました。
著者視点の発見ポイント
筆者はニュース収集からドラフト生成・ファクトチェック・公開までを自動化するAIパイプラインを日常的にCI/CD的なスケジュール実行で回しています。その運用で常に意識しているのは「エージェントに書き込み権限を渡す設計は、便利さと引き換えにブラスト半径（何が壊れうるか）を必ず広げる」という点です。
今回のCopilot CLIの変更も、PATという「見えやすいリスク（漏洩したら気づける・ローテーションできる）」を、GITHUB_TOKEN + permissions という「見えにくいリスク（ワークフロー定義のミスがそのまま権限ミスになる）」に置き換えたとも言えます。PAT管理の手間が減るのは間違いなく歓迎すべき改善ですが、copilot-requests: write を有効化する前に「このワークフローはforkPRで起動しうるか」を必ずチェックリスト化しておくべきだと実感しました。
まとめ
- Copilot CLI は
permissions.copilot-requests: writeを追加するだけでGITHUB_TOKEN認証が使える（PAT・追加シークレット不要） - 組織のCopilotポリシーで「組織課金」を有効化する必要があり、AI利用料は組織に直接請求される
- 公式ドキュメントが明記する通り、forkPRトリガーのワークフローに組み込むのは特に危険。
on: pull_requestへの安易な流用は避け、トリガーと権限を必ず見直す
参考リンク
- Copilot CLI no longer needs a personal access token in GitHub Actions — GitHub Changelog（2026-07-02）
- Using Copilot CLI in GitHub Actions — GitHub公式ドキュメント（YAML例・警告文の引用元）
- Automating tasks with Copilot CLI and GitHub Actions — GitHub公式ドキュメント
- @github/copilot — npmパッケージ