GitHub Copilot Workspaceは終了｜いまのCopilotでIssueからPRまで進める方法

GitHub Copilot Workspaceに何が起きたのか

GitHubの「Copilot Workspace」は、2025年5月30日にテクニカルプレビューを終えました。一般提供（正式版）にはならないまま、提供が止まっています。研究開発チームGitHub Nextのページには、いまも「テクニカルプレビューは2025年5月30日に終了した」と書かれています。

ただ、なくなったのはWorkspaceという「場所」です。Issueを起点に計画を立て、コードを書き、プルリクエストにまとめるという考え方は、GitHub Copilotの本体に移っています。主な出来事を時系列で並べます。

ヒカリちゃんのまとめCopilot Workspaceは、正式版にならないまま2025年5月に終わりました。でも、Issueから計画を立ててコードにする流れは、いまのGitHub Copilotの中で使えます。

Copilot Workspaceの機能はどこへ行ったか

GitHub Nextは終了の告知で、Workspaceを「リポジトリ全体にまたがる提案をうまく動かすための、2度目の試み」と振り返っています。そこで作った、大きなコードベースを扱う技術は、GitHubとMicrosoftの新しい製品の中心に使われているといいます。そのうえで、VS Codeのエージェントモードと、新しく発表したcoding agentを試してほしいと案内し、「Workspaceと1対1で同じではないが、それが未来だ」と書いています。

2024年の記事で紹介したWorkspaceの機能が、2026年10月時点でどこにあるかを対応させると、次のようになります。

大きな違いは、Workspaceでは人が画面の中で一歩ずつ進めていたのに対し、いまのクラウドエージェントは任された作業をバックグラウンドで進め、終わったらレビューを頼んでくる点です。人は、計画を確かめる場面と、できあがった変更を確かめる場面に集中する形になりました。

Workspaceを使っていた方へ

終了の告知によると、2025年5月30日以降は、新しいワークスペースを作ることも、既存のワークスペースを開くこともできません。一方で、Workspaceから作ったプルリクエストは「ほかと同じ普通のプルリクエスト」なので、影響を受けないとされています。残したい変更は、プルリクエストとしてリポジトリに残っているかを確かめてください。

ヒカリちゃんのまとめWorkspaceの「計画を立てて、人が直してから作る」という考え方は、クラウドエージェントとプランモードに分かれて残っています。プルリクエストにした変更は、いまもリポジトリに残っていますよ。

いまのGitHub Copilotで「Issue→計画→コード→PR」を進める方法

Workspaceと同じ流れを、2026年10月のGitHub Copilotで進める方法は3つあります。GitHubのサイトでIssueを任せる方法、先に計画を出してもらう方法、パソコンのエディターで進める方法です。手順はGitHubの公式ドキュメント（2026年10月26日確認）に沿っています。

方法1：IssueをCopilotに割り当てる（GitHubのサイト）

準備として、Copilot Pro以上の契約と、作業させたいリポジトリへの書き込み権限が必要です。会社のBusinessやEnterpriseでは、管理者がクラウドエージェントを有効にしておく必要があります。

1. Issueに、やってほしいことを書く。何を、なぜ変えるのか、どうなれば完了かを具体的に書きます。画面の画像を貼ることもできます。
2. Issueを開き、右側の「Assignees」から「Copilot」を選ぶ。表示される画面で、追加の指示や、作業を始めるブランチ、使うAIモデルを選べます。
3. Copilotがバックグラウンドで作業する。GitHub Actionsで動く専用の環境でリポジトリを調べ、copilot/ で始まる新しいブランチに変更を積んでいきます。
4. 終わると、プルリクエストを開いてレビューを頼んでくる。変更点と作業の記録（セッションログ）を確かめます。
5. 直してほしい点は、プルリクエストに「@copilot」をつけてコメントする。割り当てたあとにIssueへ書き足したコメントは、Copilotには届きません。追加の情報はプルリクエスト側に書きます。
6. テストの実行を承認し、自分でマージする。初期設定では、Copilotの変更に対するGitHub Actionsのワークフローは自動では動きません。中身を確かめてから「Approve and run workflows」を押します。

方法2：先に実装計画を出してもらう（Workspaceにいちばん近い形）

2026年4月から、クラウドエージェントはコードを書く前に計画を出せるようになりました。リポジトリの「Agents」タブか、画面右上のエージェントのアイコンから始めます。

1. リポジトリを選び、「〜を実装するための計画を作って」と頼む。
2. 出てきた計画を読み、意図と違うところを会話で直していく。
3. 納得したら「合意した計画で実装して」と頼む。
4. 終わったら「Diff」で変更を確かめ、よければ「Create pull request」を押す。この方法では、頼まない限りプルリクエストは自動で作られません。

方法3：パソコンのエディターで進める

VS Codeなどのエディターでは、チャット欄の下のエージェント選択から「Plan」を選ぶと、コードを変える前に計画を作ってくれます。計画ができたら「Start Implementation」で、そのままエージェントモードに切り替えて実装に進めます。エージェントモードは無料のCopilot Freeでも使えます（回数に制限あり）。

また、2026年6月に一般提供が始まったデスクトップアプリ「GitHub Copilot app」では、Issueやプルリクエストから作業を始め、複数のリポジトリで並行して進めさせ、変更を確かめてからプルリクエストを出せます。7月からは無料プランでも使えます。

ヒカリちゃんのまとめWorkspaceのように計画から確かめたいなら、方法2がいちばん近いです。最初は小さなIssueを1つだけ任せて、プルリクエストを読むところから始めてみてくださいね。

GitHub Copilotのプランと料金：どれで何ができるか

Issueを任せるクラウドエージェントは、有料プランの機能です。無料のCopilot Freeでは使えません。料金はGitHubの公式ページで2026年10月26日に確認したものです。ドル建ての料金には、日本の消費税が別にかかる場合があります。

2026年6月1日から、エージェントモード、コードレビュー、クラウドエージェント、Copilot CLIなどの利用は「GitHub AIクレジット」で数えるようになりました。1クレジットは0.01ドルです。GitHubのドキュメントでは、毎月のクレジットはProで1,500（基本1,000と変動分500）、Pro+で7,000、Maxで20,000とされています。変動分は今後変わることがあると書かれています。

使い切ったときは、上のプランに変える、追加分の予算を設定して払う、翌月のリセットを待つ、のどれかを選びます。1行ずつ続きを出すコード補完は、有料プランならクレジットを使わず、回数の制限もありません。

GitHub Copilotをほかのコード生成AIと比べたい方は、コード生成AIの比較（2026年版）を見てください。なお、WordやExcelで使う「Microsoft Copilot」はGitHub Copilotとは別のサービスです。こちらはCopilotの使い方で紹介しています。

ヒカリちゃんのまとめIssueを任せたいなら、月10ドルのProからです。エディターで試すだけなら無料のFreeでも始められるので、まずはそこから感触をつかむのも一つの手ですね。

GitHub Copilotを使うときの権利・データ・安全面の注意

AIにコードを書かせると、「できたコードは誰のものか」「入れたコードはどう使われるか」「勝手に動いて困らないか」の3つが気になります。2024年の記事では、どれにも触れていませんでした。

生成されたコードの権利

GitHubの公式FAQは、Copilotの提案の所有権をGitHubは主張しないと明記しています。そのうえで、AIが作ったものを誰かが所有できるかは、国の知的財産法や、その部分の長さ・性質によって変わると説明しています。また、公開されているコードとそっくりの提案が出ることは、GitHubの調査では1%未満とまれですが、GitHub上の公開コードと一致する提案を止める「重複検出フィルター」も用意されています。仕事で使うなら、オンになっているかを確かめておくと安心です。

入れたデータは学習に使われるか

同じFAQでは、個人向けプラン（Free・Pro・Pro+・Max）の利用者の入力や出力、コードの断片などを、オプトアウトしない限りAIモデルの学習や改善に使う場合があるとしています。オプトアウトはGitHubアカウントの設定からいつでもでき、しても機能は変わりません。法人向けのBusinessとEnterpriseのデータは学習に使わないとしています。

エージェントが勝手に動かないための仕組み

GitHubのドキュメントでは、クラウドエージェントに次のような歯止めがあると説明されています。

1. 頼めるのは書き込み権限がある人だけ。権限のない人のコメントはエージェントに渡りません。
2. 書き込めるのは1つのブランチだけ。新しく作る copilot/ ブランチで作業し、ブランチ保護のルールにも従います。
3. 頼んだ本人は、そのプルリクエストを承認できない。承認の数を求めるルールが、そのまま働きます。
4. テストや配備のワークフローは、人が確かめるまで動かない。初期設定では、書き込み権限のある人の承認が必要です。
5. インターネットへのアクセスは制限されている。APIキーなどの秘密情報がコードに入ると、シークレットスキャンで検出されます。

それでも、ドキュメントは、Copilotが誤ったコードや、セキュリティ上の弱点を含むコードを作ることがあると認めています。マージする前に、人が中身を読むことは欠かせません。パスワードやAPIキーをIssueやチャットに書かないことも基本です。

ヒカリちゃんのまとめ仕事で使う前に、学習のオプトアウトと重複検出フィルターの2つを確かめておきましょう。どんなに仕組みが整っていても、最後にマージを決めるのは人です。

2024年の記事の答え合わせ

私たちは2024年5月、GitHub Copilot Workspaceで開発効率を最大化しよう、という記事を書きました。当時書いたことが、いまから見てどうだったかを確かめます。

いちばんの見落としは、「プレビュー」が終わることもあると書かなかったことです。

当時の記事は、Workspaceが有用なツールになることは「間違いない」と書きました。けれど、プレビューは試験提供です。実際には1年あまりで終わり、機能は別の形に分かれて残りました。また、生成されたコードの権利や、入れたコードの扱いにも触れていませんでした。Soraの答え合わせと同じく、AIツールは名前や形が変わる前提で、作ったものを手元のリポジトリに残しておくことが大切だと、あらためて感じています。

ヒカリちゃんのまとめWorkspaceの機能の説明はおおむね正確でしたが、「この先」の見通しは外れました。プレビューのツールは、終わることもあると考えて付き合うのが安心です。