（更新: ）

CopilotのAgent整理：Agent/Plan/cloud agentの違い

GitHub CopilotのAgent機能は、2026年4月時点で「VS CodeのローカルAgent」と「GitHub上で任せるcloud agent」に大きく分かれます。

この記事は、GitHub Copilotの用語が混ざって分かりにくいと感じている人向けに、どこで動くか、対話し続けるか、PRを作るかの3軸で整理する記事です。

TL;DR

  • まずは VS Code の Agent を使うと、手元で対話しながら実装を進めやすいです。
  • 実装前に影響範囲を整理したいなら Plan agent が向いています。
  • GitHub上で調査・実装・PR作成まで任せたいなら Copilot cloud agent を使います。

なお、GitHub Docsでは Copilot cloud agent、VS Code Docsでは Copilot coding agent の旧称が一部に残っています。この記事では、最新のGitHub Docsに合わせて「Copilot cloud agent」を主に使います。

先に結論：まずは「どこで動くか」で分ける

混乱しやすいですが、最初に分けるべきなのは「VS Codeの中で対話しながら進めるか」「GitHub上で任せるか」です。

機能主に動く場所対話のしかた出力向いている場面
Agent（VS Code）ローカル / IDE手元で会話しながら進める直接編集今すぐ実装したい
Plan agentローカル / IDEまず計画を詰める計画書影響範囲を先に知りたい
Copilot cloud agentGitHub.com など調査や実装を任せるブランチやPRIssueベースで任せたい

迷ったら、まずは Agent から始めるのが分かりやすいです。実装をすぐ触りたいなら Agent、計画から入りたいなら Plan agent、GitHub上で非同期に任せたいなら Copilot cloud agent です。

VS Code の Agent：その場で実装を進める

VS Code の Agent は、IDE 上でコードを読み、編集し、必要ならコマンド実行まで進められるローカルAgentです。

VS Code Docs の Agents 概念ページやLocal agents の説明でも、Agent はローカルで対話しながら進める前提で整理されています。

向いている作業

  • バグ修正
  • 小〜中規模の機能追加
  • テスト追加
  • 手元で差分を見ながら進めたい作業

指示の出し方

Agent は、ゴールが具体的なほど精度が上がります。

良い例
- この関数を TypeScript に変換して型も付けて
- ESLint エラーを解消して、変更理由も説明して
- このテストファイルの失敗原因を特定して修正して

避けたい例
- なんとなく良くして
- うまく動くように直して

ローカルで都度確認しながら進められるので、仕様をまだ固めきっていない段階でも扱いやすいです。

Plan agent：実装前に計画を固める

Plan agent は、コードをいきなり書く前に、影響範囲や実装手順を整理するためのAgentです。

VS Code Docs の Planning with agents では、Plan agent が調査・計画の要約・実装手順・検証手順を作る流れとして説明されています。

向いている作業

  • 影響範囲が広い変更
  • アーキテクチャに関わる変更
  • 初めて触るコードベース
  • チームで実装前に認識を揃えたいとき

使いどころ

「まず何を触るべきか分からない」ときは、Plan agent を先に使うと事故が減ります。

Plan agent に渡すとよい情報
- 何を達成したいか
- 壊してはいけない制約
- 現状困っている点
- 想定している受け入れ条件

計画に納得したら、その後は Agent で手元実装へ進める流れが自然です。

Copilot cloud agent：GitHub上で調査・実装・PR作成を任せる

Copilot cloud agent は、GitHub上で動くAgentです。最新のGitHub Docsでは Copilot cloud agent と表記され、旧称の Copilot coding agent からの移行が案内されています。

何ができるか

cloud agent は、Issue を読むだけでなく、GitHub.com の agents panel、Copilot Chat、GitHub CLI、MCP 対応ツールなどから開始できる場面があります。

実際には、次のような流れで使われます。

  1. 調査する
  2. 実装方針を立てる
  3. ブランチや差分を作る
  4. 必要なら PR を作成する

つまり、「Issue を渡したら即 PR が生えるだけ」の機能ではなく、調査や計画を含む非同期の実装担当として使うイメージが近いです。

向いている作業

  • 受け入れ条件が明確なIssue
  • 手元で張り付きたくない定型作業
  • 先に別作業を進めたいとき
  • PRベースでレビューしたい変更

使い方のコツ

cloud agent は、曖昧な依頼だとブレやすいです。Issue には、やりたいことと受け入れ条件を先に書いておくのが重要です。

## やりたいこと
- ログイン画面にパスワード再設定導線を追加する

## 受け入れ条件
- [ ] /reset-password ページがある
- [ ] メール入力フォームがある
- [ ] 送信後に確認メッセージが表示される
- [ ] 既存テストが通る

PR作成後の追加入力は、GitHub上で @copilot を使って依頼できます。最終判断は人がレビューして行う前提です。

迷ったときの選び方

まずは Agent で十分なケース

  • 仕様はだいたい固まっている
  • 自分で差分を見ながら進めたい
  • その場で微調整したい

Plan agent を先に使うべきケース

  • どのファイルを触るか見えていない
  • 変更が大きい
  • 先に方針をレビューしたい

cloud agent が向いているケース

  • Issue に落とし込める
  • PR単位でレビューしたい
  • 自分は別の作業を進めたい

よくある誤解

Agent mode と Plan agent と cloud agent は同じ種類の機能ではない

ここが一番混乱しやすい点です。

  • Agent / Plan agent は VS Code 側のローカルAgent体験
  • Copilot cloud agent は GitHub上で任せる体験

同じ「Agent」という言葉でも、動く場所と操作感が違うので、同列に「3つのモード」とだけ覚えると混乱しやすくなります。

Copilot coding agent という言葉は消えたのか

完全に消えたわけではありません。2026年4月時点では、GitHub Docs は Copilot cloud agent を採用しつつ、VS Code Docs などに Copilot coding agent の表記が残っています。

そのため、古い記事やUI説明では coding agent と書かれていても、最新のGitHub Docsと照らすと cloud agent を指している と理解すると読みやすいです。

まとめ

  • 手元で対話しながら実装するなら VS Code の Agent
  • 実装前に影響範囲を整理するなら Plan agent
  • GitHub上で調査・実装・PR作成まで任せるなら Copilot cloud agent
  • 迷ったら、まずは Agent → 必要なら Plan / cloud agent へ広げると使い分けしやすい

用語が似ていても、どこで動くか と どこまで任せるか で整理すると迷いにくくなります。

参考リンク