GitHub Copilot のコーディングエージェント（現 Copilot cloud agent）は、Issue を割り当てると GitHub Actions 上で作業し、ドラフト PR を出します。カスタム指示・setup steps・MCP・ファイアウォールを整え、Issue → 割り当て → レビュー → マージの流れに乗せる手順と、AI クレジット制の料金を解説します。
SNSでシェアして、他のエンジニアにも教えてあげましょう
GitHub Copilot のコーディングエージェントは、Issue を割り当てるだけで GitHub Actions 上の使い捨て環境でコードを書き、ドラフトのプルリクエスト（PR）を出してくれる機能です。2026 年 4 月に名前が「Copilot cloud agent」に変わりました1。チームで使うなら、カスタム指示・copilot-setup-steps.yml・MCP・ファイアウォールの 4 つを先に整えます。そのうえで「Issue テンプレート → Copilot に割り当て → Copilot code review → 人のレビュー → マージ」の流れに乗せるのが近道です。この記事では、2026 年 10 月時点の GitHub 公式ドキュメントに沿って設定ファイルを用意しました。YAML は actionlint と JSON Schema で検証し、gh コマンドは手元の v2.98.0 で確かめています。AI クレジット制に変わった料金と、Claude Code などローカルのエージェントとの使い分けも整理します。
Copilot cloud agent は、リポジトリを調べ、計画を立て、コードを変更する作業をバックグラウンドで進める AI エージェントです。手元の IDE ではなく、GitHub Actions で動く使い捨ての開発環境の中でファイルを編集し、テストやリンターを実行します2。
GitHub は 2026 年 4 月 1 日の changelog で、Copilot coding agent を Copilot cloud agent に改名しました。同時に、PR を作らずにブランチ上で作業する使い方、実装計画を先に出させる使い方、リポジトリを調べて答えさせる使い方（deep research）も加わりました1。古い記事で「coding agent」と書かれているものは、同じ機能を指します。この記事でも見出しでは「コーディングエージェント」、本文では現在の名前「cloud agent」を使います。
作業を頼む入り口はいくつもあります。チーム開発でよく使うのは次の 4 つです3。
| 入り口 | 操作 | 向いている場面 |
|---|---|---|
| Issue の割り当て | Issue の Assignees で Copilot を選ぶ | チームのバックログから切り出したタスク |
| Agents タブ・パネル | プロンプトを書いて Start task | Issue にするほどでもない小さな依頼 |
| PR のコメント | @copilot をメンションして修正を頼む | レビュー指摘の反映、マージコンフリクトの解消 |
| 失敗した Actions | ジョブの画面で Fix with Copilot | PR ブランチの CI 失敗の調査と修正 |
このほか、Copilot Chat の /、GitHub CLI の gh agent-task create、IDE、Slack や Jira などの連携からも始められます3。
制約も先に押さえておきます。1 回のタスクで変更できるのは、開始時に指定した 1 つのリポジトリだけです。扱えるブランチは 1 つで、開ける PR も 1 つです。1 回のセッションは最長 59 分で、延長はできません2。大きな仕事は、59 分に収まる単位に分けて渡します。
2026 年の春から夏にかけて、名前・機能・料金がまとめて変わったからです。1 年前の解説記事の手順や料金は、もう当てはまりません。
国内でも関心が上がっています。Qiita でストック 5 以上の記事を数えると、2026 年 10 月 8 日までの 14 日間で copilot タグは 4 本でした。その前の 14 日間は 0 本です。
| タグ | 9/10〜9/23（本） | 9/24〜10/7（本） |
|---|---|---|
| copilot | 0 | 4 |
| GitHubCopilot | 2 | 4 |
cloud agent は Copilot Free 以外のすべてのプランで使えます。Copilot Business と Copilot Enterprise では、管理者がポリシーで有効にするまで使えません61。
2026 年 6 月 1 日から、料金はトークンの量とモデルで決まる AI クレジットで数えます。1 AI クレジットは 0.01 米ドルです46。
| プラン | 月額（米ドル） | 月に含まれる AI クレジット | cloud agent | Copilot code review |
|---|---|---|---|---|
| Copilot Free | 無料 | 一定量 | × | VS Code の「Review selection」のみ |
| Copilot Pro | 10 | 1,500（基本 1,000 + フレックス 500） | ○ | ○ |
| Copilot Pro+ | 39 | 7,000（基本 3,900 + フレックス 3,100） | ○ | ○ |
| Copilot Max | 100 | 20,000（基本 10,000 + フレックス 10,000） | ○ | ○ |
| Copilot Business | 19 / ユーザー | 1,900 / ユーザー（組織でプール） | ○ | ○ |
| Copilot Enterprise | 39 / ユーザー | 3,900 / ユーザー（組織でプール） | ○ | ○ |
出典: GitHub Docs「Plans for GitHub Copilot」6
| プラン | 月に含まれる AI クレジット（クレジット） |
|---|---|
| Pro | 1,500 |
| Business（1 人あたり） | 1,900 |
| Enterprise（1 人あたり） | 3,900 |
| Pro+ | 7,000 |
| Max | 20,000 |
チームで見積もるときのポイントは 3 つです。
コード補完と次の編集の提案（next edit suggestions）は AI クレジットの対象外で、有料プランでは無制限のままです6。
ここからは、リポジトリに置くファイルと設定を順番に用意します。下のファイルはすべて手元の検証用リポジトリに置き、構文を確かめました。
Copilot Business・Copilot Enterprise では、組織のメンバーに対して cloud agent も、サードパーティの MCP サーバーも既定で無効です7。組織の Copilot のポリシー設定ページで、次の 2 つを Enabled にします。
有効にすると、組織のすべてのリポジトリで使える状態になります。試験導入では、Settings → Copilot → Cloud agent の「Repository access」で対象のリポジトリだけに絞ると安全です。リポジトリへの書き込み権限を持つ人だけが、Copilot に仕事を頼めます7。
cloud agent は、リポジトリに置いた指示ファイルを自動で読みます。読むファイルは次の 3 種類です8。
| 種類 | 置き場所 | 効く範囲 |
|---|---|---|
| リポジトリ全体の指示 | .github/ | cloud agent・code review・Copilot Chat |
| パスごとの指示 | .github/ | applyTo の glob に合うファイル |
| エージェント向けの指示 | AGENTS.md（どこでも。近いものが優先）、またはルートの CLAUDE.md・GEMINI.md | cloud agent・code review |
AGENTS.md を読めるので、Claude Code や Codex と同じ指示ファイルを共有できます。CLAUDE.md と AGENTS.md の書き分けは「CLAUDE.md と AGENTS.md の書き方」にまとめました。ここでは Copilot だけの書き方に絞ります。
まず、リポジトリ全体の指示です。ビルドとテストのコマンドを書いておくと、cloud agent が自分で検証してから PR を出しやすくなります。
このリポジトリは Next.js（TypeScript）の Web アプリです。
## ビルドと検証
- 依存関係: `npm ci`
- 型チェック: `npm run typecheck`
- テスト: `npm test`
- 変更を終える前に、必ず型チェックとテストを両方実行し、通ることを確認する
## 守ること
- `.github/workflows/` と `migrations/` は Issue で明示されない限り変更しない
- 新しい依存パッケージを追加するときは、PR の説明に理由を書く
- PR の説明は日本語で書く
次に、パスごとの指示です。excludeAgent に "code-review" か "cloud-agent" を書くと、どちらか片方にだけ効かせられます8。次の例は、テストの書き方を cloud agent にだけ伝えます。
---
applyTo: "**/*.test.ts"
excludeAgent: "code-review"
---
テストは Vitest で書く。1 つの it に 1 つの振る舞いだけを書き、テスト名は日本語で「〜のとき〜になる」の形にする。
自分で書く時間がなければ、cloud agent に copilot-instructions.md を書かせることもできます。公式ドキュメントに、そのためのプロンプトが載っています8。
cloud agent は依存関係を自分で入れようとしますが、試行錯誤になり時間がかかります。非公開のパッケージは取れないこともあります。.github/ に手順を書いておくと、作業の前に決まった手順で入ります9。
name: "Copilot Setup Steps"
on:
workflow_dispatch:
push:
paths:
- .github/workflows/copilot-setup-steps.yml
pull_request:
paths:
- .github/workflows/copilot-setup-steps.yml
jobs:
# ジョブ名は copilot-setup-steps でなければ Copilot に読まれない
copilot-setup-steps:
runs-on: ubuntu-latest
timeout-minutes: 30
permissions:
contents: read
steps:
- name: Checkout code
uses: actions/checkout@v6
- name: Set up Node.js
uses: actions/setup-node@v7
with:
node-version: "22"
cache: "npm"
- name: Install JavaScript dependencies
run: npm ci
この YAML は公式ドキュメントの例をもとに timeout-minutes を足したもので、actionlint 1.7.12 と check-jsonschema 0.38.2（GitHub Actions のスキーマ）でエラーが出ないことを確かめました。守るべき約束は次の 3 つです9。
copilot-setup-steps にするsteps・permissions・runs-on・services・snapshot・timeout-minutes（最大 59）だけで、ほかは無視されるcloud agent には、最初から 2 つの MCP（Model Context Protocol）サーバーがつながっています。GitHub の Issue や PR を読む GitHub MCP サーバーと、ブラウザを操作する Playwright MCP サーバーです。GitHub MCP サーバーは既定で、作業中のリポジトリを読むだけのトークンを使います10。
ほかの MCP サーバーは、リポジトリの Settings → Copilot → MCP servers に JSON で書きます。次は公式ドキュメントにある Cloudflare のドキュメント検索サーバーの例です10。
{
"mcpServers": {
"cloudflare": {
"type": "sse",
"url": "https://docs.mcp.cloudflare.com/sse",
"tools": ["*"]
}
}
}
設定するときの注意は 4 つです10。
tools には必要なツールだけを並べ、できるだけ読み取り専用のものにするCOPILOT_MCP_ で始まる名前にする: Agents secrets に COPILOT_MCP_ で始まる名前で登録し、$COPILOT_MCP_SENTRY_ACCESS_TOKEN のように参照する。それ以外の名前は MCP の設定から見えないもう 1 つがファイアウォールです。cloud agent のインターネット接続は既定で制限されています。パッケージレジストリなどを含む「推奨の許可リスト」は既定で有効です。社内のパッケージサーバーが要るなら、Settings → Copilot → Internet access でドメインか URL を許可リストに足します11。ブロックされた通信は、PR の本文かコメントに警告として出ます。
ただし、このファイアウォールが見張るのは、エージェントが Bash ツールで起動したプロセスだけです。MCP サーバーのプロセスと、copilot-setup-steps.yml の手順には効きません。公式ドキュメントも「完全なセキュリティ対策と考えるべきではない」と書いています11。
公式のベストプラクティスは「Copilot に割り当てる Issue はプロンプトだと考える」ことを勧めています。良いタスクには、問題の説明、完了の条件（テストを足すか等）、変更するファイルの手がかりが入っています12。
もう 1 つ大事な仕様があります。Copilot に渡るのは、割り当てた時点の Issue のタイトル、本文、コメント、追加の指示だけです。割り当てたあとに Issue に書いたコメントは届きません3。そこで、必要なことを書き切れる Issue テンプレート（issue forms）を用意します。
name: Copilot に任せるタスク
description: Copilot cloud agent に割り当てる前提の、範囲を絞ったタスク
title: "[Copilot]: "
labels: ["copilot"]
body:
- type: markdown
attributes:
value: |
この Issue は Copilot へのプロンプトになります。割り当てた後のコメントは Copilot に届かないので、必要なことはここに書き切ってください。
- type: textarea
id: goal
attributes:
label: やること
description: 解決したい問題、または追加したい振る舞いを 1〜3 文で
validations:
required: true
- type: textarea
id: acceptance
attributes:
label: 完了の条件
description: テストの追加の有無、通すべきコマンドなど
placeholder: |
- npm test が通る
- src/lib/date.test.ts にケースを追加する
validations:
required: true
- type: textarea
id: files
attributes:
label: 触ってよいファイル・触ってはいけないファイル
placeholder: |
触る: src/lib/date.ts
触らない: .github/workflows/ 配下、migrations/
- type: checkboxes
id: scope
attributes:
label: 任せてよいタスクか
options:
- label: 本番障害・認証・個人情報に関わる変更ではない
required: true
.github/ に置きます。check-jsonschema の GitHub issue forms スキーマで検証済みです。
Issue ができたら、画面の Assignees で Copilot を選びます。ダイアログで、対象のリポジトリ、元にするブランチ、カスタムエージェント、モデル、追加の指示を選べます3。ターミナルからなら、GitHub CLI で割り当てられます。下の GIF は、手元の gh 2.98.0 でヘルプを表示した実際の出力です。
# Issue を作ると同時に Copilot に割り当てる
gh issue create --title "[Copilot]: 日付表示を JST にそろえる" --body-file task.md --assignee "@copilot"
# 既存の Issue #23 を Copilot に割り当てる
gh issue edit 23 --add-assignee "@copilot"
# Issue を作らずにタスクを始め、ログを追いかける（preview）
gh agent-task create "src/lib/date.ts のタイムゾーン処理にテストを足す" --follow
gh agent-task は GitHub CLI v2.80.0 以降で使えるプレビューのコマンドです。
Copilot code review は、PR を読んでコメントと修正案を付けるレビュー担当です。全員の PR に自動で付けるなら、リポジトリの Settings の「Rulesets」でブランチのルールセットを作ります。「Automatically request Copilot code review」にチェックを入れます5。
既定では、PR が Open になったときに 1 回だけレビューします。push のたびにレビューする「Review new pushes」と、ドラフトの間からレビューする「Review draft pull requests」も選べます。レビューの深さは Lite と Balanced（既定）の 2 段階です。日常の小さな変更は Lite、セキュリティに関わる変更は Balanced、と使い分けます5。
手で頼むときは、PR の Reviewers で Copilot を選ぶか、gh pr edit 23 --add-reviewer "@copilot" を実行します。
ここまでの設定がそろったら、チームの流れは次のようになります。
copilot/ で始まるブランチでドラフト PR を作る7.github/ の変更がないか見てから Approve and run workflows を押す3@copilot をメンションすると、同じ PR に修正の commit が積まれる36 番の「Start a review でまとめる」は見落としがちです。1 件ずつ送ると、1 件ごとにセッションが始まり、AI クレジットも余計に使います。
7 番の仕組みのおかげで、ブランチ保護の「承認 1 件以上」をそのまま使えます。ほかにも、Copilot の commit には頼んだ人が共同作成者として入り、セッションログへのリンクも付きます7。後から「誰がどう頼んだか」を追えるので、監査の面でも人の PR と同じに扱えます。
公式のベストプラクティスは、最初は小さなタスクから始めるよう勧めています。例は、バグ修正、UI の調整、テストの追加、ドキュメントの更新、アクセシビリティの改善、技術的負債の解消です12。逆に、人が自分でやるべきタスクとして次の 4 種類を挙げています12。
先ほどの Issue テンプレートのチェックボックスは、この 2 つ目を起票の時点で弾くためのものです。
結論から言うと、「Issue で切り出せて、CI で正しさを確かめられる仕事」は cloud agent に任せます。「手元で対話しながら方向を決める仕事」は Claude Code などのローカルエージェントでやります。違いは実行場所と、人がどこで関わるかです。
| 観点 | Copilot cloud agent | Claude Code などのローカルエージェント |
|---|---|---|
| 動く場所 | GitHub Actions の使い捨て環境2 | 開発者の PC（またはその人が用意した環境） |
| 頼み方 | Issue の割り当て、Agents タブ、@copilot | ターミナルで対話 |
| 人が関わる場所 | PR のレビューとコメント | 実行中の対話と、手元での確認 |
| 1 回の長さ | 最長 59 分、1 リポジトリ・1 PR2 | 制限は使い方次第 |
| 権限 | copilot/ ブランチへの push だけ。マージはできない7 | 開発者の権限で何でもできる（設定で絞る） |
| ネットワーク | ファイアウォールで制限11 | 開発者の環境の通り |
| 料金 | Copilot の AI クレジット6 | 各ツールの料金体系 |
cloud agent の強みは、並列で何本も走らせても開発者の手が空いていることです。もう 1 つは、権限が最初から絞られていることです。一方、59 分の制限と 1 リポジトリの制約があります。設計を詰めながら進める仕事や、複数のリポジトリを同時に触る仕事には向きません。
両方を使うチームなら、指示は AGENTS.md にまとめて共有するのがおすすめです。cloud agent はルートの CLAUDE.md も読めます8。PR のレビューを Claude で自動化する方法は「Claude Code GitHub Actions で PR レビューを自動化」で解説しました。ローカルのエージェント同士の違いは「Codex CLI と Claude Code の違い」が参考になります。なお Copilot には、Anthropic Claude や OpenAI Codex を GitHub 上のエージェントとして呼べる「サードパーティのコーディングエージェント」もあります（2026 年 10 月時点で public preview、Pro 以上の有料プラン）6。
ツールの概要は GitHub Copilot、Claude Code、Codex のページにもまとめています。
| 症状 | 原因 | 対処 |
|---|---|---|
| 割り当てたのに Copilot が動かない・PR を作れない | ルールセットやブランチ保護（コミットの作成者を限定するルールなど）と合わない2 | ルールセットなら Copilot をバイパスの対象に加える |
| Issue に後から書いた補足が反映されない | 割り当て後の Issue コメントは Copilot に届かない3 | 補足は Copilot が作った PR のコメントに @copilot 付きで書く |
| PR の CI が走らない | Copilot の push では Actions が自動で動かない3 | 差分を見てから Approve and run workflows を押す |
| PR に「ファイアウォールでブロック」の警告が出る | 許可リストにないホストへの通信11 | 必要なホストだけを Internet access の許可リストに足す |
| MCP サーバーのツールが使われない | 起動に失敗している、または OAuth が必要なサーバー10 | セッションログの「Start MCP Servers」の手順で起動結果を見る |
| 途中で止まる | 59 分の上限2 | タスクを分ける。timeout-minutes で短く切ることもできる |
セキュリティでは、次の 3 点を押さえておきます。
copilot-instructions.md・AGENTS.md）・copilot-setup-steps.yml・MCP・ファイアウォールの 4 つを整える次にやることは、試験導入するリポジトリを 1 つ決めることです。まず copilot-instructions.md と copilot-setup-steps.yml だけを置き、テスト追加のような小さな Issue を 3 件割り当ててみてください。
同じものです。GitHub は 2026 年 4 月 1 日に Copilot coding agent を Copilot cloud agent に改名しました。あわせて、PR を作らずにブランチで作業する、実装計画を先に出す、といった使い方が加わりました1。
使えません。Copilot Free には cloud agent が含まれず、Copilot Pro 以上の有料プランと Copilot Student で使えます。Copilot Business・Copilot Enterprise では、組織の管理者がポリシーで有効にする必要があります67。
2026 年 6 月 1 日に、プレミアムリクエストの回数制は AI クレジット制に置き換わりました。プレミアムリクエストで数えるのは、それ以前から年額プランを続けている Copilot Pro・Pro+ の利用者だけで、その年額プランが終わるまでです4。
読まれます。cloud agent と Copilot code review は AGENTS.md（近いものが優先）と、ルートの CLAUDE.md・GEMINI.md をエージェント向けの指示として使います8。
Copilot は自分の PR を承認もマージもできません。頼んだ本人も承認できない仕組みです7。CI を承認して実行し、別の人がレビューして承認してからマージします。
リポジトリか組織の Agents secrets に、COPILOT_MCP_ で始まる名前で登録します。MCP の設定 JSON からは $COPILOT_MCP_... の形で参照します。それ以外の名前の秘密情報は、MCP の設定から使えません10。
Research, plan, and code with Copilot cloud agent — GitHub Changelog, 2026-04-01（2026-10-08 参照） ↩ ↩2 ↩3 ↩4 ↩5
GitHub Copilot on GitHub.com（Limitations and compatibility） — GitHub Docs（2026-10-08 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6
Using Copilot cloud agent on GitHub — GitHub Docs（2026-10-08 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
What changed with Copilot billing (legacy) — GitHub Docs（2026-10-08 参照） ↩ ↩2 ↩3
About GitHub Copilot code review — GitHub Docs（2026-10-08 参照） ↩ ↩2 ↩3 ↩4 ↩5
Plans for GitHub Copilot — GitHub Docs（2026-10-08 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
Risks and mitigations for GitHub Copilot cloud agent と Adding GitHub Copilot cloud agent to your organization — GitHub Docs（2026-10-08 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
Adding repository custom instructions for GitHub Copilot — GitHub Docs（2026-10-08 参照） ↩ ↩2 ↩3 ↩4 ↩5
Configure the development environment（copilot-setup-steps.yml） — GitHub Docs（2026-10-08 参照） ↩ ↩2
Configure MCP servers for your repository — GitHub Docs（2026-10-08 参照） ↩ ↩2 ↩3 ↩4 ↩5 ↩6
Customizing or disabling the firewall for GitHub Copilot — GitHub Docs（2026-10-08 参照） ↩ ↩2 ↩3 ↩4
Best practices for using GitHub Copilot to work on tasks — GitHub Docs（2026-10-08 参照） ↩ ↩2 ↩3 ↩4