GitHub Copilot Coding Agent：Issue を振ったら、翌朝 PR が来ていた

夜、Issue に「このバグを直して」とコメントして寝た。翌朝、Draft PR が届いていた。

これが GitHub Copilot Coding Agent の体験だ。Cursor のようにエディタを開く必要はない。ターミナルも不要。GitHub の Issue 画面からアサインするだけで、エージェントが自律的にコードを書き、テストを実行し、PR を出してくれる。

---

Copilot Workspace から Coding Agent へ

まず歴史を整理しておく。

GitHub Copilot Workspace は、2024年に技術プレビューが始まった「Issue を起点にブラウザ上でコードを編集する」実験的プロダクトだった。しかし 2025年5月30日に技術プレビューが終了・廃止された。後継に集中するためだ。

後継が GitHub Copilot Coding Agent だ。2025年5月19日の Microsoft Build 2025 で発表され、同年 9月25日に一般提供（GA） となった。

Workspace との違いは明確だ。Workspace はブラウザ上でコードを編集する「半自動」ツールだったが、Coding Agent はエージェントが完全に自律してコーディングを行う。人間は指示を出して、結果をレビューするだけでいい。

---

仕組みを理解する

「自律的にコードを書く」と言われても、どこで何が動いているのか見えないと不安だ。順番に整理する。

Issue にアサインするだけ

GitHub の Issue 画面を開く。担当者欄に「Copilot」を選んでアサインする。それだけだ。

すると Copilot がタスクの内容を読み取り、コーディングを開始する。ブランチを切る。コードを変更する。テストを走らせる。そして Draft PR を自動で作成し、開発者をレビュアーに追加する。

「隔離された作業部屋」で動く

Copilot Coding Agent は GitHub Actions の一時的な仮想環境（エフェメラル環境） の中で動く。本番のリポジトリに直接手を触れるわけではない。専用の作業部屋を用意して、その中で作業し、結果だけを持ってくるイメージだ。

この環境で、コードの変更・テスト実行・コミットまでをこなす。ログは GitHub Actions の画面から確認できるので、エージェントが何をしているか透明に把握できる。

copilot/ ブランチにしか push できない

Copilot は copilot/ で始まるブランチにのみコードを push できる。main や master への直接 push は不可能だ。

新入社員が「提案はできるが、最終決定権はない」という権限設定に似ている。PR を出すところまでが Copilot の仕事で、マージするかどうかは必ず人間が判断する。

PR にコメントで再指示できる

Draft PR が出てきたあと、「ここの実装を変えてほしい」と思ったら、PR のコメント欄に @copilot を付けてコメントするだけで再作業してくれる。Issue を立て直す必要はない。

---

実際に何ができるか

「なんでも任せられる」わけではない。得意なタスクと苦手なタスクがある。これを把握しておかないと、期待外れな結果に終わる。

得意なタスク

• バグ修正: 再現手順が明確で、変更範囲が限定されているもの
• 機能追加: 既存のパターンを踏まえた小規模な追加
• テストの追加: カバレッジを上げるためのテスト作成
• リファクタリング: 命名変更、関数の分割、重複コードの整理

共通しているのは、「ゴールが明確で、変更範囲が狭い」タスクだ。

苦手なタスク

• 複雑なロジック: ビジネスルールが複雑に絡み合ったコード
• アーキテクチャ変更: 設計レベルから変えるような大規模な改修
• 不慣れなコードベース: 既存コードの文脈が読めていないと精度が落ちる
• コンフリクト解消: 複数人が同じファイルを編集していると失敗しやすい

「プログラミングの教師に論文の構成を全部考えさせる」ようなタスクは苦手だ。「誤字を直してもらう」「段落を追加してもらう」ようなタスクは得意だと考えるとわかりやすい。

---

コード例：Issue の書き方で精度が変わる

Coding Agent の精度を左右するのは Issue の書き方だ。「直してください」だけでは、何をどう直せばいいか判断できない。

❌ 悪い Issue の書き方

タイトル: ログインが動かない
本文: 直してください

これだと Copilot は「どう動かないのか」「期待する動作は何か」「どこを直せばいいか」が判断できない。

✅ 良い Issue の書き方

タイトル: ログインフォームがメールアドレス未入力でも送信できてしまう

## 現状の問題
- メールアドレス欄が空の状態でログインボタンを押すと、APIリクエストが送信される
- サーバー側で 400 エラーが返るが、UIにエラーメッセージが表示されない

## 期待する動作
- メールアドレスが空の場合、クライアント側でバリデーションエラーを表示する
- 「メールアドレスを入力してください」というメッセージを表示する

## 関係するファイル（わかる場合）
- src/components/LoginForm.tsx
- src/lib/validators.ts

「現状の問題」と「期待する解決状態」を明記するだけで、精度は大きく上がる。関係するファイルがわかれば書いておくとさらに良い。

PR が出てきたあと、内容が意図と違った場合はコメントで再指示できる。

✅ PR へのフィードバックの書き方

@copilot バリデーションメッセージを英語ではなく日本語で表示してほしい。
また、エラーの表示位置をフォーム上部ではなく各フィールドの直下に変更してください。

@copilot を付けてコメントするだけで、その指示をもとに再実装してくれる。

---

Cursor Agent との棲み分け

Cursor にも「エージェントモード」がある。Coding Agent と何が違うのか。

最大の差は作業場所だ。

Cursor はエディタの中で動く。コードの変更をリアルタイムでGUIの差分として確認しながら進められる。「この変更はちょっと違うかな」と思ったらその場で修正できる。

Copilot Coding Agent は GitHub 上で非同期に動く。指示を出したあとは待つだけで、結果が PR として届く。確認するのは PR のレビュー画面だ。

もう一つの差は GitHub との統合度だ。Coding Agent は GitHub のエコシステム——Issue、PR、Actions、レビュー——と完全に溶け込んでいる。チームで Issue 管理をしているプロジェクトや、企業で GitHub を中心に開発フローを組んでいる場合には、この統合度が実用上の強みになる。

さらに、Slack, Teams, Linear, Azure Boards などの外部ツールからもタスクをトリガーできる。「Slack でバグ報告が来たら、そのまま Copilot にタスクを投げる」というフローも組める。

---

料金とプラン

GitHub Copilot の料金プラン を確認しておく。Coding Agent を使うには Pro 以上が必要だ。

「プレミアムリクエスト」とは、Copilot が高性能なモデル（Claude Sonnet、GPT-4o 等）を使うときに消費するクレジットのことだ。Coding Agent はこのプレミアムリクエストを消費する。不足した場合は $0.04/回で追加購入できる。

個人で始めるなら Pro（月額 $10）が現実的だ。300回/月というのは、中程度の複雑さのタスクを毎日 1〜2 件こなせる量に相当する。

---

使いこなすコツ

実際に使っているユーザーの知見をまとめると、以下のポイントが繰り返し出てくる。

Issue は「仕事の発注書」として書く

曖昧な指示では曖昧な結果しか出ない。「何が問題で、どういう状態になってほしいか」を具体的に書く。発注書を書く感覚に近い。書き方が磨かれるほど、出てくる PR の質も上がる。

小さいタスクに分割する

「ユーザー管理機能を全部実装して」という巨大な Issue は失敗しやすい。「ユーザー一覧ページを作る」「ユーザー詳細ページを作る」「削除ボタンを追加する」のように分割する。1つの Issue が 1〜2 ファイルの変更で収まる粒度が理想だ。

コンフリクトには注意する

複数人が同じファイルを編集していると、Copilot が作ったブランチでコンフリクトが起きやすい。コンフリクト解消は苦手なので、Coding Agent に任せるタスクのブランチは、できるだけ他の作業と衝突しないよう調整する。

ログを読む習慣をつける

GitHub Actions のログを確認すれば、Copilot がどのファイルを参照して、なぜその変更をしたかが追跡できる。ログを読む習慣があると、「なんか変な実装になってる」に気づく速度が上がる。

---

GitHub ネイティブ、という強み

Cursor や Claude Code と Coding Agent の最大の違いは「どこで使うか」だ。

Cursor はエディタの中。Claude Code はターミナルの中。Copilot Coding Agent は GitHub の中だ。

Issue・PR・Actions・レビュー——GitHub を使った開発フローに組み込まれているツールだからこそ、チーム開発や企業での利用で威力を発揮する。個人の開発環境を変えず、既存のワークフローに乗っかれる。

Fortune 100 企業の 90% が GitHub Copilot を導入しているという数字も、この「既存フローとの親和性」が評価されているからだろう。

2026年1月時点で GitHub Copilot の有料ユーザーは 470 万人を超え、前年比 75% の成長を続けている。エージェント機能が「実験」から「実務」に移行したことで、Copilot を選ぶ理由がまた一つ増えた。

---

自動化できる部分を見極める

Coding Agent は「全部任せられる」ツールではない。得意なタスクと苦手なタスクがある。それを把握した上で、「Issue を書く → 待つ → レビューする」というループをどこに組み込むかを考える。

バグ修正、テスト追加、小規模な機能追加——これらを非同期で Copilot に任せ、人間はアーキテクチャの判断や複雑なロジックの実装に集中する。そういう分担が機能したとき、開発の速度と質は両立する。

Issue の書き方から始めよう。うまい「発注書」を書く練習をすることが、Coding Agent を使いこなす最初のステップだ。

About GitHub Copilot cloud agent - GitHub Docsdocs.github.com

GitHub Copilot · Plans & pricingGitHub Copilot works alongside you directly in your editor, suggesting whole lines or entire functions for you.github.com