GitHub Copilot cloud agentを複数リポジトリで使っている組織にとって、2026年5月8日の「More flexible secrets and variables for Copilot cloud agent」は、運用負荷をかなり下げる更新です。結論から言うと、Copilot cloud agent向けのsecretsとvariablesを、GitHub Actionsのcopilot環境ではなく、専用の「Agents」設定として管理できるようになりました。さらに、組織レベルで共通設定を作成し、対象リポジトリへ共有できるようになった点が大きな変更です。(The GitHub Blog)
これまでリポジトリごとに同じトークンやMCPサーバー設定を登録していた場合、今後は「全リポジトリで共通化するもの」と「個別リポジトリだけに置くもの」を分けて整理するのが重要です。特に、内部パッケージレジストリ、社内API、MCPサーバー、copilot-setup-steps.ymlで使う環境変数を扱うチームは、設定場所とアクセス範囲を早めに見直しておきましょう。
GitHub Copilot cloud agentのsecretsとvariablesで何が変わったのか
今回の変更では、Copilot cloud agent専用のsecretsとvariablesが「Agents」という独立した種類として追加されました。これは、既存のActions、Codespaces、Dependabot向けsecrets/variablesとは別枠で管理されます。(The GitHub Blog)
変更前は、Copilot cloud agentに渡すsecretsやvariablesを、各リポジトリのGitHub Actions設定内にあるcopilot環境へ登録する必要がありました。そのため、複数リポジトリで同じ内部パッケージレジストリ用トークンやMCPサーバー設定を使う場合でも、リポジトリ単位で重複登録する必要がありました。(The GitHub Blog)
変更後は、組織レベルでAgents secrets/variablesを作成し、すべてのリポジトリ、private/internalリポジトリ、または選択したリポジトリだけに共有できます。リポジトリ単位の設定も、Actions設定とは分離された専用の「Agents」セクションで管理します。(The GitHub Blog)
| 項目 | 変更前 | 変更後 |
|---|---|---|
| 設定場所 | 各リポジトリのActions設定内のcopilot環境 | リポジトリまたは組織の「Secrets and variables > Agents」 |
| 組織レベル管理 | 利用不可 | 利用可能 |
| 複数リポジトリへの共有 | リポジトリごとに個別設定が必要 | 組織レベルから対象リポジトリを選んで共有可能 |
| Actions用secretsとの関係 | Actions設定内で扱っていた | Agents専用枠としてActions/Codespaces/Dependabotと分離 |
| 管理しやすさ | 大規模展開では重複管理になりやすい | 共通設定と個別設定を分けやすい |
Copilot cloud agentとは何をする機能なのか
Copilot cloud agentは、開発者が依頼したタスクをGitHub上でバックグラウンド実行するエージェントです。GitHubの公式説明では、タスクを委任すると、Copilot cloud agentはGitHub Actionsを基盤とする独自の一時的な開発環境で作業します。(The GitHub Blog)
この開発環境でビルド、テスト、依存関係のインストール、MCPサーバー経由の外部ツール連携などを行うには、必要な認証情報や環境変数を渡す必要があります。たとえば、次のような用途です。
- private npm registryや社内パッケージレジストリへアクセスする
- Sentry、Azure DevOps、Cloudflareなど外部サービスのMCPサーバーを利用する
copilot-setup-steps.ymlで依存関係を事前インストールする- テスト実行時に必要な非機密の設定値を渡す
- APIキーやトークンをMCPサーバーに渡す
ここで重要なのは、Copilot cloud agentが通常のGitHub Actions secrets、Codespaces secrets、Dependabot secretsをそのまま参照するわけではない点です。GitHub Docsでは、Copilot cloud agentに渡されるのはAgents secrets/variablesのみであり、Actions、Codespaces、Dependabotのsecrets/variablesにはアクセスしないと説明されています。(GitHub Docs)
管理者にとっての一番大きなメリットは「共通設定の集約」
今回の更新で最も恩恵を受けるのは、複数のリポジトリを管理しているOrganization管理者です。
たとえば、20個のリポジトリで共通の社内パッケージレジストリを使っている場合、以前は各リポジトリに同じトークンを登録し、ローテーション時にも20箇所を更新する必要がありました。これでは、設定漏れ、古いトークンの残存、権限過多の温床になりがちです。
今後は、組織レベルのAgents secretとして共通トークンを1つ登録し、対象リポジトリを選んで共有できます。GitHubの公式発表でも、内部パッケージレジストリのトークンや共通MCPサーバー設定を多数のリポジトリへ展開しやすくなる点が例として挙げられています。(The GitHub Blog)
ただし、「組織レベルで作れるようになったから、すべてを組織レベルへ移す」のはおすすめできません。共通化すべきものと、リポジトリ固有にすべきものを分ける必要があります。
| 設定の種類 | 推奨される配置 | 理由 |
|---|---|---|
| 全リポジトリ共通の内部レジストリURL | 組織レベルのvariable | 機密ではなく、共通利用しやすい |
| 全社共通の読み取り専用パッケージトークン | 組織レベルのsecret | ローテーション対象を集約できる |
| 特定サービスの本番APIキー | 原則として慎重に検討。必要なら対象リポジトリを限定 | 影響範囲が大きく、権限過多になりやすい |
| リポジトリ固有の検証用トークン | リポジトリレベルのsecret | 他リポジトリへ共有する必要がない |
| MCPサーバー用のAPIキー | COPILOT_MCP_接頭辞付きのAgents secret | MCP設定で参照するには接頭辞が必要 |
管理画面での設定場所
リポジトリレベルで設定する場合は、対象リポジトリのSettingsから、Securityセクションの「Secrets and variables」を開き、「Agents」を選択します。リポジトリ単位のAgents secrets/variablesを設定するには、リポジトリ管理者権限が必要です。(GitHub Docs)
組織レベルで設定する場合は、OrganizationのSettingsから、Securityセクションの「Secrets and variables」を開き、「Agents」を選択します。組織レベルのAgents secrets/variablesを設定するには、Organization owner権限が必要です。(GitHub Docs)
組織レベルでは、Repository accessとして次の範囲を選べます。
| Repository access | 意味 | 使いどころ |
|---|---|---|
| All repositories | 組織内のすべてのリポジトリから利用可能 | 全社共通で安全に共有できる非機密設定や低権限トークン |
| Private repositories | private/internalリポジトリから利用可能 | 公開リポジトリには渡したくない内部向け設定 |
| Selected repositories | 指定したリポジトリだけ利用可能 | 権限を絞りたいAPIキー、MCPサーバー、部署別設定 |
セキュリティを重視するなら、最初からAll repositoriesを選ぶのではなく、Selected repositoriesで小さく始めるのが安全です。特に、外部サービスのAPIキーや書き込み権限を持つトークンは、必要なリポジトリだけに限定しましょう。
既存設定の移行で確認すべきこと
過去に各リポジトリのGitHub Actions設定でcopilot環境にsecretsやvariablesを登録していた場合、それらは新しいリポジトリレベルのAgents typeへ自動移行されます。GitHub Docsでは、このケースではユーザー側の作業は不要で、今後は新しい場所から管理できると説明されています。(GitHub Docs)
ただし、実務では「自動移行されたから確認不要」とは考えないほうが安全です。特に、組織で複数リポジトリを管理している場合は、次の観点で棚卸しを行いましょう。
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
旧copilot環境の設定が移行されているか | リポジトリのAgentsセクションに値があるか | Copilot cloud agentがビルドやテストで失敗する |
| 同じ名前のsecret/variableが複数レベルにないか | 組織レベルとリポジトリレベルの重複 | 意図しない値が優先される |
| 不要なトークンが残っていないか | 使われていないsecretの削除候補 | 退職者・旧システム・旧権限の残存 |
| 共通化できる設定がないか | レジストリURL、読み取り専用トークン、MCP共通設定 | 更新作業がリポジトリ数分だけ増える |
| 権限が広すぎないか | All repositoriesにする必要があるか | Copilot cloud agentに不要なアクセス権を渡す |
特に注意したいのは、同じ名前のsecretまたはvariableが複数レベルに存在する場合です。GitHub Docsでは、同じ名前が複数レベルにある場合、より低いレベルの値が優先されると説明されています。たとえば、リポジトリレベルのsecretは、同名の組織レベルsecretを上書きします。(GitHub Docs)
secretsとvariablesの使い分け
Agents secretsとAgents variablesは、どちらもCopilot cloud agentの環境に渡すための設定ですが、使い分けを誤るとセキュリティ事故や運用混乱につながります。
基本的には、漏えいしたら困る値はsecret、公開されても大きな問題にならない設定値はvariableとして扱います。
| 種類 | 使う値の例 | 判断基準 |
|---|---|---|
| secret | APIキー、アクセストークン、レジストリの認証トークン、PAT | 値を見られると不正アクセスにつながる |
| variable | レジストリURL、環境名、機能フラグ、タイムアウト値 | 値自体に認証能力がない |
| MCP用secret | COPILOT_MCP_SENTRY_ACCESS_TOKENなど | MCPサーバー認証に使う機密情報 |
| MCP用variable | COPILOT_MCP_REGIONなど | MCP設定で参照する非機密値 |
GitHub Docsでは、設定されたAgents secrets/variablesは、原則としてCopilot cloud agentの開発環境で環境変数として利用できると説明されています。ただし、COPILOT_MCP_で始まるものはMCPサーバー向けに利用されます。(GitHub Docs)
また、secretの値はCopilot cloud agentのセッションログでマスクされます。とはいえ、ログでマスクされるから安全という考え方は危険です。値を渡した時点で、agentが実行するツールやスクリプトから利用可能になるため、最小権限のトークンを使うことが前提です。(GitHub Docs)
MCPサーバーを使う場合の注意点
MCPサーバーをCopilot cloud agentと連携しているチームは、今回の変更を特に確認すべきです。
GitHub Docsでは、MCPサーバーが変数、キー、secretを必要とする場合、COPILOT_MCP_で始まる名前のAgents secretまたはvariableを追加する必要があると説明されています。COPILOT_MCP_で始まるAgents secrets/variablesだけがMCP設定で利用可能です。(GitHub Docs)
たとえば、SentryのMCPサーバーにアクセストークンを渡すなら、次のような名前にします。
COPILOT_MCP_SENTRY_ACCESS_TOKENMCP設定側では、次のように参照します。
{
"mcpServers": {
"sentry": {
"type": "local",
"command": "npx",
"args": ["@sentry/mcp-server@latest"],
"tools": ["*"],
"env": {
"SENTRY_ACCESS_TOKEN": "$COPILOT_MCP_SENTRY_ACCESS_TOKEN"
}
}
}
}ここでの失敗しやすいポイントは、通常の環境変数名とMCP向けの名前を混同することです。たとえば、SENTRY_ACCESS_TOKENというAgents secretを作っても、MCP設定で参照するsecretとしては不十分です。MCP設定で使う参照名はCOPILOT_MCP_で始まっている必要があります。(GitHub Docs)
もう一つの重要な注意点は、MCPサーバーのツール権限です。GitHub Docsでは、MCPサーバーを設定するとCopilotがサーバーのツールを自律的に利用でき、使用前にユーザー承認を求めないと説明されています。そのため、MCP設定では可能な限り読み取り専用ツールや必要なツールだけを許可するのが安全です。(GitHub Docs)
copilot-setup-steps.ymlを使うリポジトリで確認すること
Copilot cloud agentの開発環境をカスタマイズしている場合、.github/workflows/copilot-setup-steps.ymlもあわせて確認しましょう。
GitHub Docsでは、Copilotの環境をカスタマイズするには、リポジトリ内の.github/workflows/copilot-setup-steps.ymlに専用のGitHub Actionsワークフローファイルを作成すると説明されています。このファイルの中で、依存関係のインストールやツールの準備などを行えます。(GitHub Docs)
ただし、このワークフローにはいくつかの条件があります。
| 確認項目 | 内容 |
|---|---|
| ファイル配置 | .github/workflows/copilot-setup-steps.yml |
| ブランチ | default branchに存在しないとCopilot用に実行されない |
| ジョブ名 | copilot-setup-stepsである必要がある |
| 権限 | 必要最小限のpermissionsを設定する |
| 失敗時の挙動 | setup stepが失敗すると、残りのsetup stepはスキップされ、現在の環境状態で作業が始まる |
たとえば、private package registryから依存関係を取得するためにトークンを使う場合、そのトークンはActions secretsではなくAgents secretとして登録されている必要があります。ここを誤ると、通常のGitHub Actionsワークフローでは成功するのに、Copilot cloud agentでは依存関係のインストールに失敗する、という分かりにくい問題が起きます。
命名ルールと優先順位
Agents secrets/variablesには命名ルールがあります。GitHub Docsでは、名前には英数字とアンダースコアのみ使用でき、スペースは使えず、GITHUB_で始めることも、数字で始めることもできないと説明されています。また、名前は大文字・小文字を区別せず、小文字は大文字へ変換されます。(GitHub Docs)
実務では、次のような命名ルールをチーム内で統一しておくと管理しやすくなります。
| 用途 | 命名例 | ポイント |
|---|---|---|
| 内部npmレジストリのURL | NPM_REGISTRY_URL | 非機密ならvariableでよい |
| npm認証トークン | NPM_READ_TOKEN | secretとして管理 |
| MCP用Sentryトークン | COPILOT_MCP_SENTRY_ACCESS_TOKEN | MCPで使うため接頭辞が必須 |
| MCP用GitHub PAT | COPILOT_MCP_GITHUB_PERSONAL_ACCESS_TOKEN | 権限を必要最小限にする |
| 環境名 | APP_ENV | productionなどの値を渡す場合に使う |
避けたいのは、TOKENやAPI_KEYのような曖昧すぎる名前です。リポジトリ単位では問題がなくても、組織レベルへ広げると用途が分からなくなります。SERVICE_PURPOSE_SCOPEのように、サービス名、用途、権限範囲が分かる名前にすると、後から棚卸ししやすくなります。
開発者への影響
開発者側の主な影響は、Copilot cloud agentが利用する認証情報の置き場所が明確になることです。
これまで、Copilot cloud agentで依存関係の解決に失敗した場合、「GitHub Actionsのsecretは設定しているのに、なぜCopilotでは使えないのか」と混乱することがありました。今回の変更後は、Copilot cloud agent用の設定はAgentsに置く、という切り分けがしやすくなります。
開発者が確認すべきポイントは次のとおりです。
- Copilot cloud agentで使う値がActions secretsではなくAgents secrets/variablesに登録されているか
copilot-setup-steps.yml内で参照する環境変数名と、Agents側の名前が一致しているか- MCPサーバーで使う値に
COPILOT_MCP_接頭辞が付いているか - リポジトリ固有の値を組織レベルの共通値で上書きしていないか
- Copilot cloud agentのセッションログでsetup stepの失敗が出ていないか
特に、ローカル環境や通常のCIでは成功するのに、Copilot cloud agentだけ失敗する場合は、まずAgents secrets/variablesの設定漏れを疑うとよいでしょう。
管理者が取るべき展開手順
組織で安全に展開するなら、いきなり全リポジトリに適用するのではなく、次の順で進めるのがおすすめです。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | Copilot cloud agentを使うリポジトリを洗い出す | 利用中・検証中・未利用を分ける |
| 2 | 既存のAgents secrets/variablesを確認する | 自動移行された旧copilot環境の設定を含める |
| 3 | 共通化できる値を分類する | レジストリ、MCP、共通ツール設定など |
| 4 | 組織レベルへ移す候補を決める | 全体共有しても安全か、権限が広すぎないかを見る |
| 5 | Selected repositoriesで小規模に展開する | 最初は重要度の低い検証リポジトリで試す |
| 6 | Copilot cloud agentの実行ログを確認する | 依存関係、MCP接続、setup stepの失敗を確認 |
| 7 | 問題なければ対象リポジトリを広げる | All repositoriesは最後に検討する |
この順序で進めると、設定漏れや権限過多を見つけやすくなります。特に、組織レベルのsecretは便利ですが、対象範囲を広げすぎると、意図しないリポジトリのCopilot cloud agentにも値が渡る可能性があります。
セキュリティ面で注意すべきポイント
Copilot cloud agentはバックグラウンドで作業するため、開発者が毎回すべてのコマンド実行を目視するわけではありません。そのため、secrets/variablesの設計では「便利さ」よりも「権限の絞り込み」を優先すべきです。
特に重要なのは次の点です。
| 注意点 | 実務での対策 |
|---|---|
| 書き込み権限のあるトークンを広く共有しない | 読み取り専用トークンを基本にする |
| 本番環境のsecretを安易に渡さない | 検証用・限定スコープの認証情報を使う |
| MCPサーバーのツールを広く許可しすぎない | tools: ["*"]は慎重に使い、可能なら個別指定する |
| 組織レベルsecretの対象範囲を広げすぎない | Selected repositoriesから始める |
| 同名secretの優先順位を把握しないまま運用しない | 組織レベルとリポジトリレベルの命名を棚卸しする |
| ローテーション手順を決めない | 更新担当者、影響リポジトリ、確認方法を文書化する |
便利になったからこそ、設定ミスの影響範囲も広がります。組織レベルで共通化する値は、できるだけ低権限・短寿命・用途限定にしておくのが現実的です。
よくある失敗例
Actions secretsに登録したのにCopilot cloud agentで使えない
Copilot cloud agentはActions secrets/variablesをそのまま参照しません。Agents secrets/variablesに登録する必要があります。通常のCIでは成功するのにCopilot cloud agentだけ失敗する場合、この設定場所の違いが原因になりやすいです。(GitHub Docs)
MCP用のsecret名にCOPILOT_MCP_を付け忘れる
MCP設定で参照するsecretやvariableは、COPILOT_MCP_で始まる必要があります。SENTRY_TOKENやAPI_KEYのような名前では、MCP設定から期待どおりに参照できない可能性があります。(GitHub Docs)
組織レベルとリポジトリレベルで同じ名前を使う
同じ名前の値が複数レベルにある場合、より低いレベルの値が優先されます。つまり、リポジトリレベルの値が組織レベルの値を上書きします。共通設定を更新したのに一部リポジトリだけ挙動が変わらない場合、同名のリポジトリレベル設定が残っている可能性があります。(GitHub Docs)
All repositoriesで広く公開しすぎる
組織レベルで設定できるようになると、All repositoriesを選びたくなります。しかし、secretの内容によっては、対象リポジトリを限定するべきです。特に、社内システムや外部SaaSにアクセスできるトークンは、Selected repositoriesで必要な範囲に絞りましょう。
今回の更新をどう活用すべきか
今回の「More flexible secrets and variables for Copilot cloud agent」は、単なる設定画面の変更ではありません。Copilot cloud agentを組織で本格展開するための管理機能が整った更新と見るべきです。
小規模な個人リポジトリでは影響は限定的ですが、OrganizationでCopilot cloud agentを使う場合は、次の方針で整理すると運用しやすくなります。
- 共通設定は組織レベルのAgents secrets/variablesへ集約する
- 機密値はsecret、非機密値はvariableに分ける
- MCP用の値は
COPILOT_MCP_接頭辞で統一する - リポジトリ固有の値は無理に共通化しない
- 最初はSelected repositoriesで展開し、動作確認後に範囲を広げる
- Actions/Codespaces/Dependabot用のsecretsとは別物として管理する
まず行うべきことは、現在Copilot cloud agentで使っているリポジトリを洗い出し、Agents secrets/variablesの設定状態を確認することです。そのうえで、重複しているトークンやMCP設定を組織レベルへ集約できるかを検討しましょう。設定の共通化と権限の最小化を同時に進めることで、Copilot cloud agentをより安全に、よりスケールしやすく運用できます。
コメント