tech.guitarrapc.cóm

Technical updates

GitHub Agentic WorkflowとCOPILOT_GITHUB_TOKENと個人PATと運用

GitHub Actionsには、GitHub Agentic Workflowという機能があります。これを使うと、自然言語で書いた指示をgh cliでコンパイルするとGitHub Actionsのワークフローが生成されるというものです。昨日一日の作業をサマってIssueにまとめてと書くだけでワークフローが自動生成される、と聞くと面白そうじゃないですか? 実際良いです。

自然言語で書くだけでいいならLLMにやらせればいいのですが、Agentic Workflowは以下のような対策により安全なサンドボックス的な環境で実行されるのがいい点です。

  • ガードレールが内蔵されてプロンプト挿入や悪意のあるリポジトリから守られる
  • エージェントは読み込み専用トークンしか持たない
  • 書き込みトークンや秘密情報を持たない
  • ネットワーク的に隔離されたコンテナで実行される

今回はこのGitHub Agentic Workflowを使ってみて、OrganizationのPrivate Repositoryで使うにあたってはまる点、手放し運用が難しいというメモです。

簡単なまとめ

GitHub Agentic Workflowは手放し運用、Organizationの統制下で使えるという段階ではなく、以下の点に注意が必要です。

  • GitHub Agentic Workflowはsecrets.COPILOT_GITHUB_TOKENCopilot Requests: read権限が必要な個人トークンを求める
  • Organization制御下のPATは本権限が設定できないので、個人トークンを用意して設定する必要がある
  • gh awは頻繁に更新されるため、定期的にgh aw拡張を更新してワークフローファイルもコンパイルし直す必要がある

COPILOT_GITHUB_TOKENが必要

GitHub Agentic Workflowは、secrets.COPILOT_GITHUB_TOKENをワークフローで参照します。このPATにはCopilot Requests: read権限を付与し、Repository(またはOrganization)のSettings > Actions > Secretsに登録しておく必要があります。ワークフローでもこの状態が前提ですCOPILOT_GITHUB_TOKENというシークレットが登録されていなかったり、Copilot Requests: read権限がないとワークフローは失敗します。

以下は、GitHub Agentic Workflowで生成されるYAMLの一部です。

jobs:
  activation:
    runs-on: ubuntu-slim
    permissions:
      actions: read
      contents: read
      # 省略...
      - name: Validate COPILOT_GITHUB_TOKEN secret
        id: validate-secret
        run: bash "${RUNNER_TEMP}/gh-aw/actions/validate_multi_secret.sh" COPILOT_GITHUB_TOKEN 'GitHub Copilot CLI' https://github.github.com/gh-aw/reference/engines/#github-copilot-default
        env:
          COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }} # ここで参照/チェックされる
      # 省略...

Secretsがない場合、次のようなエラーが出ます。

Run ${RUNNER_TEMP}/gh-aw/actions/validate_multi_secret.sh COPILOT_GITHUB_TOKEN 'GitHub Copilot CLI' https://github.github.com/gh-aw/reference/engines/#github-copilot-default
Error: None of the following secrets are set: COPILOT_GITHUB_TOKEN
The GitHub Copilot CLI engine requires either COPILOT_GITHUB_TOKEN secret to be configured.

Common causes if the secret appears to be configured:
  - Organization secrets must have repository access granted
  - Environment secrets require the job to specify that environment
  - Secret names are case-sensitive - verify exact spelling

Documentation: 'https://github.github.com/gh-aw/reference/engines/#github-copilot-default'
Error: Process completed with exit code 1.

トークンにCopilot Requests: read権限がない場合、Execute GitHub Copilot CLIステップで次のようなエラーが出ます。

[copilot-harness] 2026-05-12T05:33:27.648Z attempt 4: spawning: /usr/local/bin/copilot --add-dir /tmp/gh-aw/ --log-level all --log-dir /tmp/gh-aw/sandbox/agent/logs/ --disable-builtin-mcps --no-ask-user --allow-all-tools --allow-all-paths --add-dir /home/runner/work/githubactions-lab/githubac
[copilot-harness] 2026-05-12T05:33:27.651Z attempt 4: process started (pid=517)

Authentication failed with provider at http://172.30.0.30:10002 (HTTP 401).
  Check your COPILOT_PROVIDER_API_KEY or COPILOT_PROVIDER_BEARER_TOKEN.

Changes   +0 -0
Duration  47s
[copilot-harness] 2026-05-12T05:33:30.898Z attempt 4: process exit event exitCode=1
[copilot-harness] 2026-05-12T05:33:30.899Z attempt 4: process closed exitCode=1 duration=3s stdout=0B stderr=180B hasOutput=true
[copilot-harness] 2026-05-12T05:33:30.899Z attempt 4 failed: exitCode=1 isCAPIError400=false isMCPPolicyError=false isModelNotSupportedError=false isNullTypeToolCallError=false isAuthError=false hasOutput=true retriesRemaining=0
[copilot-harness] 2026-05-12T05:33:30.899Z all 3 retries exhausted — giving up (exitCode=1)

OrganizationポリシーのPATは使えない

Organizationにも関わらず個人PATを使うと「Organization側でPATを拒否できない」「権限変更の統制が取れない」など運用で問題があるため、PATをOrganizationポリシーで制御することが多いでしょう。

しかしCopilot Requests権限は個人(Account)権限で、Organizationポリシーを適用したPATはAccount権限を持たずOrganization権限に置き換わります。OrgポリシーPATをCOPILOT_GITHUB_TOKENとして使えないことはGitHub Documentに未記載で、GitHub Issue #223で同じ悩みの民を確認できます。gh awリポジトリのIssueでGitHub Appトークンでの認証をサポートしてほしいと要望が出ていますが、現状は個人トークンでしか動かせない状況です。

シークレットの参照元はSecretsから変更できない

importやAgentic Workflowの指示マークダウンでsecrets.COPILOT_GITHUB_TOKENの参照元をSecretsではなく任意のシークレットプロバイダー(1Password/load-secrets-actionなど)に差し替えられないか試みたものの、プロンプトでのsecrets参照部分を差し替えは防御されており難しいようです。とはいえコンパイルされたワークフローは原則触れません。

ワークアラウンド

残念ながら個人トークンを用意してsecrets.COPILOT_GITHUB_TOKENに設定します。Organization所属のPATが使えないため、制御が甘くなるのでかなり嫌な感じで、受け入れられない場合もあるでしょう。その場合、いったんあきらめるしかない状況です。

gh awを更新する

ちなみに、gh awは、ちょくちょく更新されます。なので、GitHub Actionsで動作させていて「gh awでコンパイルされたバージョンが古いので更新しないと実行させないエラー」が出る場合もあります。例えば次のようなエラーを確認しています。

Run actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd
Checking compile-agentic version: v0.65.2
Fetching update configuration from: https://raw.githubusercontent.com/github/gh-aw/main/.github/aw/releases.json
Error: Outdated compile-agentic version: v0.65.2 is below the minimum supported version v0.65.3. Update gh-aw to the latest version and recompile your workflow.

兆候で対処するには、手元でgh awを実行していて次のような警告が出たらgh aw拡張を更新しましょう。

$ gh aw compile
✓ .github/workflows/monthly-oss-repo-status.md (73.2 KB)
✓ Compiled 1 workflow(s): 0 error(s), 0 warning(s)

ℹ Compiler upgrade recommended: gh-aw v0.72.1 is behind the latest release v0.74.4.
ℹ Hint: upgrade the compiler with: gh extension upgrade github/gh-aw



A new release of aw is available: 0.72.1 → 0.74.4
To upgrade, run: gh extension upgrade aw
https://github.com/github/gh-aw

gh awの拡張を更新してからワークフローのコンパイルgh aw compileを再度実行すれば、警告が消えます。

$ gh extension upgrade aw
[aw]: upgraded from v0.72.1 to v0.74.4
✓ Successfully checked extension upgrades

$ gh aw compile
✓ .github/workflows/monthly-oss-repo-status.md (76.4 KB)
✓ Compiled 1 workflow(s): 0 error(s), 0 warning(s)

更新すると、.github/aw/actions-lock.jsonにあるパッケージバージョンが更新され、コンパイルして生成されたAgentic WorkflowのYAML、agentic-maintenance.ymlが更新されます。

この挙動は理解できるんですが、GitHub Actionsで動かしていて、1週間とかで突然更新しないと動かせないよ! って言われるのでびっくりします。 しょうがないので、gh extension upgrade awgh aw compileを定期的に実行するのが暫定対応になります。 正式リリース前に何か手が入るんだろうか...

まとめ

GitHub Agentic Workflowは、自然言語で書いた指示をgh cliでコンパイルするとGitHub Actionsのワークフローが生成される機能です。実際いい感じの機能なんですが、使ってみている感じだとまだ手放し運用できる段階ではなく、Organizationの統制下で使う時に個人PATが必要なのはいただけません。とはいえ、GitHub Actions経由のセキュリティ侵害事件が続く中、安全なサンドボックス環境で実行されるのは、ユーザー側ではやりにくい対応です。今後に期待しています。

参考