コンテンツにスキップ

GitHub Copilot cloud agentとは？

GitHub Copilot 完全ガイド

対象 / ポイント

対象: GitHub上のIssueや保守作業をCopilotへ任せ、レビュー可能な変更を受け取りたい開発者・テックリード

ポイント:

  • Copilot coding agentは2026年4月にCopilot cloud agentへ名称・ワークフローを拡張した
  • IDEのAgent Modeがローカルで同期的に作業するのに対し、cloud agentはGitHub Actions環境でバックグラウンド実行する
  • 1タスク1リポジトリ・1ブランチ・1PR、最長59分という境界を前提にタスクを分割する

まず名称を更新する

GitHubは2026年4月1日、Copilot coding agentをCopilot cloud agentとして再構成した。従来はPR作成が前提だったが、現在はリポジトリを調査し、実装計画を作り、ブランチ上で変更し、差分を見ながら反復してからPRを作成できる1。

検索や古い設定名にはcoding agentが残る。機能を探すときは両方の名前が出るが、本記事では現名称のcloud agentを使う。

Agent Modeとの違い

両方ともコードを探索し、コマンドを実行し、複数ファイルを編集できる。違いはモデルより実行場所と人の待ち方にある2。

観点Copilot cloud agentIDEのAgent Mode
実行場所GitHub Actionsの一時環境手元のIDE・端末
進め方バックグラウンドで非同期会話を見ながら同期
成果物ブランチ、差分、必要に応じてPRローカルの作業ツリー
向く仕事境界が明確なIssue、定型保守、テスト追加探索的デバッグ、設計対話、ローカル依存の作業
人の関与結果と差分を後からレビュー作業中に随時誘導

「どちらが高性能か」ではなく、作業中に人が張り付く必要があるかで選ぶ。仕様が曖昧で判断を何度も挟むならAgent Mode、受け入れ条件をIssueに書けるならcloud agentが向く。

cloud agentが行う流れ

現在の基本フローは次の通りだ。

flowchart LR
    A[Issueまたは依頼] --> B[調査と計画]
    B --> C[一時環境で変更]
    C --> D[テストと自己修正]
    D --> E[ブランチ差分を確認]
    E -->|追加指示| C
    E -->|準備完了| F[PRを作成]
    F --> G[人間がレビュー]

開始時のプロンプトで「すぐPRを作る」と指定することも、PRを作らずブランチ上で計画・差分を反復することもできる。計画だけを依頼し、実装範囲に同意してからコード変更へ進める使い方は、大きめのIssueで有効だ。

向くタスクと避けるタスク

向くタスク

  • 再現手順と期待結果がある小さな不具合
  • 既存パターンを使う限定的な機能追加
  • テスト不足が明確なモジュールへのテスト追加
  • ドキュメント、型、lint違反の修正
  • 依存更新や技術的負債のうち、機械的に検証できるもの
  • 単一リポジトリで完結する軽いマージコンフリクト解消

分割または人主導にするタスク

  • 複数リポジトリを同時に変更する移行
  • 59分を超える大規模ビルドやE2Eが不可欠な変更
  • 本番データ、支払い、権限境界を直接扱う作業
  • UIの「良さ」など受け入れ条件を言語化できない変更
  • 社内ネットワークや開発者のローカル機器へ依存する作業

タスクの大きさではなく、完了を機械的に判定できるかが重要だ。

依頼文に必要な5項目

Issueをそのまま渡す前に、最低限次を揃える。

## Goal
ログイン失敗時に同じエラー通知が重複表示される問題を直す。

## Scope
- `src/auth/`だけを変更する
- APIのレスポンス形式は変更しない

## Reproduction
1. 無効なパスワードで送信する
2. 通知が2件表示される

## Acceptance criteria
- 通知は1件だけ表示される
- 既存の認証テストが通る
- 回帰テストを1件追加する

## Checks
`pnpm lint && pnpm test auth`

目標、変更範囲、再現、受け入れ条件、検査コマンドがあれば、cloud agentは計画と完了判定を作りやすい。

開発環境を先に整える

cloud agentはGitHub Actions上の一時環境で動く。標準イメージにない依存関係や環境準備は、リポジトリの.github/workflows/copilot-setup-steps.ymlで定義できる3。

セットアップにはビルドに必要な公開依存だけを置く。長期資格情報をファイルへ書かず、必要な秘密情報はGitHubの管理機構と最小権限で渡す。セットアップが10分かかるリポジトリは、59分の作業枠をその分消費するため、キャッシュと軽い検査経路も設計対象になる。

現在の制限

GitHub公式ドキュメントが示す主要な境界は次の通りだ2。

  • 1回のタスクで変更できるのは指定した1リポジトリだけ
  • 1ブランチだけで作業し、作成できるPRは1件
  • 1セッションの最大実行時間は59分で延長できない
  • GitHub上にホストされたリポジトリだけが対象
  • 一部のrulesetやbranch protectionと互換性がない場合がある
  • cloud agentはCopilotのcontent exclusionを考慮しない

最後の点はセキュリティ上重要だ。content exclusionだけで機密ファイルを隔離したつもりにならず、cloud agentへアクセスさせてよいリポジトリとデータを別途設計する。

料金とモデル選択

cloud agentはすべての有料Copilotプランで利用できるが、組織では管理者がポリシーで無効化できる2。実行はGitHub Actions分とAI creditsを消費し、AI creditsは選択モデルと処理トークンに応じて変わる。

モデルを選べる場合も、最も高価なモデルを固定する必要はない。定型変更は高速モデル、複雑なデバッグは高い推論能力を持つモデルというように、失敗時の再実行コストまで含めて選ぶ。

PRを人間がレビューする

cloud agentがテストを通したことと、変更が採用可能なことは同じではない。PRでは次を確認する。

  • Issueの受け入れ条件を満たすか
  • 変更範囲が依頼したディレクトリ内か
  • 新しい依存、権限、外部通信を増やしていないか
  • テストが成功経路だけでなく失敗経路も覆うか
  • ロールバック可能か
  • cloud agentが説明した検査をCIでも再現できるか

Copilot code reviewを一次レビューに使っても、同じベンダーのエージェント同士が見落としを共有する可能性は残る。セキュリティ境界、業務仕様、ユーザー体験は責任を持つ人が判断する。

小さく導入する

最初は1リポジトリ、1種類のタスク、1つの検査セットに限定する。

  1. ドキュメントまたはテスト追加を3件選ぶ
  2. 完了率、差し戻し理由、Actions分、AI creditsを記録する
  3. AGENTS.mdとセットアップ手順を改善する
  4. 不具合修正へ対象を広げる
  5. 高リスク領域は別の承認とガードレールを維持する

導入の評価指標は生成コード量ではない。人が受け取って採用できた変更の割合と、レビューに残った時間で測る。

まとめ

Copilot cloud agentは「IDEをクラウドへ移したもの」ではなく、GitHub上で調査、計画、変更、反復を非同期化する作業者だ。境界が明確なIssueを渡し、差分とCIを人間がレビューする運用に向く。

最初に覚える制約は3つでよい。

  • 1タスク1リポジトリ・1ブランチ・1PR
  • 最大59分
  • content exclusionはcloud agentの隔離策にならない

この境界内へタスクを切れば、非同期化の利点を得ながらレビュー可能性を保てる。

関連記事

  1. Research, plan, and code with Copilot cloud agent — GitHub Changelog ↩

  2. About GitHub Copilot cloud agent — GitHub Docs ↩↩↩

  3. Customizing the development environment for Copilot cloud agent — GitHub Docs ↩