GitHub Copilot Workspace 実践ハンズオン2026

この記事でわかること

  • GitHub Copilot Workspace を Issue 起点で動かす実際の流れ
  • プラン → 実装 → テストの3段階で人間が介入すべきポイント
  • 実プロジェクトで使う際のレビュー観点と運用ルール

結論

Copilot Workspace は「Issue を書けば動くPRが出てくる」開発体験を目指したプロダクトで、2026年時点で中級開発者の片腕として実用に耐えるレベルに達しています。最大の価値は手元 IDE を開かずに、ブラウザだけで Issue から PR まで進められること。一方で「丸投げ」は事故るので、プラン段階での人間の介入が成功率を決めます。

本題

Copilot Workspace の流れ（全体像）

中級者向けに、典型的なフローを4ステップで整理します。

  1. Issue を書く: 通常の GitHub Issue、ただしタイトルと本文の質が後工程の精度を決める
  2. Spec フェーズ: Workspace が Issue を読み、現状理解と変更方針を提示 → 人間が修正
  3. Plan フェーズ: 変更するファイル一覧と各ファイルの編集内容を提示 → 人間が修正
  4. Implement フェーズ: 実コードを生成 → ローカルで実行 / テスト → PR 化

人間が口を出すのは Spec と Plan、Implement 後のレビューの3か所です。

Issue の書き方が9割

Workspace は Issue の本文をほぼ唯一の入力として使うので、ここの粒度がすべてを左右します。良い Issue の構造例:

## 概要
ユーザー設定画面でメールアドレスを変更できるようにしたい。

## 背景
現状は管理者にメールで依頼する運用になっており、月10件ほど発生している。

## 要件
- /settings/email で新メールアドレスを入力できる
- 確認メールを新メアドに送り、リンク踏破で確定する
- 旧メアドにも通知メールを送る

## 受け入れ条件
- e2e テスト: メアド変更フローが通る
- 既存ログイン動作に影響しない

## 触ってほしくない場所
- app/admin/

特に「触ってほしくない場所」は強力なガードになります。

Spec フェーズで必ず確認すること

Workspace が出してくる Spec は要約＋変更方針です。チェックすべきは次の3点。

  1. 意図の取り違え: 自分の意図と1mmでもズレていたら、ここで全力で修正
  2. 既存コードの理解: 既存の関数名・モデル名を正しく拾えているか
  3. 欠落要件: 受け入れ条件のうちカバーされていない項目がないか

ここで甘くすると、Plan / Implement で全部やり直しになります。

Plan フェーズの修正パターン

Plan ではファイル単位の差分計画が出ます。中級者がよく直すのは次のパターン。

  • 「新規ファイルにロジックを切り出すべきところを、既存ファイルに詰め込もうとしている」 → ファイル分割を指示
  • 「同じロジックが複数箇所にコピペされている」 → 共通関数化を指示
  • 「テストの追加が抜けている」 → 「最低3ケースの単体テストを追加」と明記

Plan を直すコストは Implement を直すコストの 1/5 程度なので、ここで時間をかけるほうが結果的に速いです。

Implement / レビュー時の観点

Implement 後は通常の PR レビューに戻りますが、Workspace 産 PR では特に次を確認します。

  1. 環境変数の扱い: ハードコードされていないか
  2. ログの粒度: ログ出しすぎ / 不足はないか
  3. エラーハンドリング: 想定外入力で落ちないか
  4. テストの本物度: アサーションが「always true」になっていないか

特に4は罠が多く、expect(true).toBe(true) 相当のテストが紛れていることがあります。

チームで運用するときのルール

1人でなく、チームで Workspace を活用する場合の運用ルール例。

  • Issue テンプレを「概要 / 背景 / 要件 / 受け入れ条件 / スコープ外」の5項目で固定
  • Workspace 産 PR は人間PRと区別できるラベル（例: from:workspace）を付与
  • マージ前に必ず人間1人がレビュー、自動マージは禁止
  • Workspace の利用ログを Issue にコメントとして残す（再現性確保）

よくある質問（FAQ）

Q1: Cursor の Agent と機能はかぶりますか？

A1: かぶりますが、UX が違います。Workspace はブラウザで Issue 起点、Cursor の Agent はローカル IDE 起点。普段から GitHub の Issue で仕事を回すチームは Workspace、ローカルで設計しながら書きたい個人は Cursor が合います。

Q2: モノレポでも使えますか？

A2: 使えますが、Plan フェーズで「対象パッケージ」を明示しないとファイル横断の影響範囲が読みづらくなります。Issue で packages/web のように対象を限定するのがコツです。

Q3: 料金は個人で回収できますか？

A3: Issue ベースで定常的にタスクが流れているプロジェクトなら回収可能、たまにしか使わない個人開発だと割高に感じる、というのが実感です。

まとめ

Copilot Workspace は「Issue → PR」の自動化を本気で狙ったプロダクトで、中級開発者なら明日から実戦投入できます。鍵は Issue の質と、Spec / Plan フェーズでの人間の介入。Implement に進む前にしっかり修正を入れることで、レビューコストを最小化しながら開発速度を上げられます。