「Issue を投げると、計画を立てて複数ファイルを編集し、プルリクエストまで作ってくれる」。Copilot Workspace のテクニカルプレビューでこの体験に手応えを感じ、定型的なタスクを少しずつ任せていた方は多いはずです。ところが、その使い方を再開しようとしたら Workspace が見当たらない——そんな状況に戸惑っているのではないでしょうか。
Copilot Workspace は 2025 年 5 月 30 日にサンセット（提供終了）しました。ただし「廃止されてなくなった」わけではありません。Workspace が培ったサブエージェント構造・Issue から PR への自動化ワークフロー・非同期での自律実行モデルは、Copilot Coding Agent として再構築され、2025 年 9 月に有償 Copilot 全プランで一般提供（GA）されています。つまり、あの「Issue 丸投げ」体験には、ちゃんと後継がいます。
やっかいなのは、ここに Claude Code という選択肢が並ぶことです。Claude Code もターミナルやヘッドレス実行で似たような自律タスクをこなせるため、「自律的に丸投げするなら、結局どちらに任せれば失敗しないのか」が判断できず、手が止まってしまいます。任せた PR が的外れだったり、途中で止まったりして、結局自分でやり直す——その不安が、丸投げをためらわせる最大の原因です。
本記事では、ツール全体の総合比較はあえて行いません。スコープを「Issue→PR の非同期・自律開発」という 1 つのユースケースに絞り込み、Copilot Coding Agent と Claude Code の自律実行機能を正面から使い分ける方法を解説します。判断の軸に据えるのは、両者の実行環境の差です。Coding Agent は GitHub Actions 上で動き 1 セッション約 59 分という上限を持ちますが、Claude Code はターミナル/CI 上で時間の上限なく並列実行できます。この違いが「どのタスクで止まりやすいか／安全に丸投げできるか」を分けます。最後に、丸投げの失敗を減らす具体的な任せ方まで踏み込みます。
なお、Copilot と Claude Code を補完・Agent Mode も含めて広く比較したい場合は、別記事のGitHub CopilotとClaude Codeの使い分けで総合的な判断軸を整理しています。本記事は「非同期自律開発」というレイヤーの深掘りに専念します。
Copilot Workspace で丸投げしていた使い方を、いま続けるには
最初に、検索の出発点になっているはずの「Workspace はどこへ行ったのか」をはっきりさせておきます。
Copilot Workspace は終了し、その役割は Coding Agent に引き継がれた
Copilot Workspace は GitHub Next の研究プロジェクトとして始まり、2025 年 5 月 30 日にテクニカルプレビューを終了しました（GitHub Blog: Meet the new coding agent）。検索で「Copilot Workspace」を探して見つからず混乱した方は、まずここを押さえてください。プロダクト名としての Workspace は消えましたが、機能そのものが消えたわけではありません。
GitHub は Workspace から学んだ要素——サブエージェント構造、Issue から PR への一連のワークフロー、非同期での自律実行モデル——をそのまま Copilot Coding Agent として作り直しました。Coding Agent は 2025 年 9 月以降、有償の Copilot 全プランで一般提供されています。Workspace で「Issue を投げる」運用をしていた方にとって、後継として迷わず向かうべき先は Coding Agent です。
「Issue 丸投げ」を Coding Agent と Claude Code のどちらでやるかが本記事の問い
ここで悩みが一段複雑になります。同じ「Issue を投げたら自律的に実装してくれる」体験は、Claude Code でも実現できるからです。Claude Code はターミナルから起動する自律エージェントで、コードベース全体の文脈を保ちながらタスクを分解し、複数ファイルを編集します。ヘッドレス（対話画面を介さない）実行で CI に組み込むこともできます。
つまり、いまや「Issue 丸投げ」の受け皿は 1 つではありません。Coding Agent に非同期で投げるのか、Claude Code を手元やパイプラインで回すのか。この選択を、機能リストの突き合わせではなくタスクの性質と実行環境の制約から決められるようにするのが、本記事のゴールです。次の章から、まず「Coding Agent が Workspace の何を受け継いだのか」を整理し、それから両者の使い分けに入ります。
Coding Agent は Copilot Workspace の何を受け継いだのか
後継だと分かっても、「では具体的に何がどう変わったのか」が曖昧なままだと、安心して移行できません。Workspace から Coding Agent への系譜を整理します。
Workspace の3つの資産（サブエージェント・Issue→PR・非同期実行）の行方
Workspace が持っていた価値は、大きく 3 つに分けられます。1 つ目はサブエージェント構造——タスクを内部で小さな単位に分解して進める仕組み。2 つ目は Issue から PR への一貫したワークフロー——課題を起点に計画・編集・プルリクエスト作成までを通しでつなぐ流れ。3 つ目は非同期での自律実行——人間が張り付かなくても裏側で処理が進むモデルです。
Coding Agent は、この 3 つをそのまま受け継いでいます。GitHub の説明でも、Workspace の「サブエージェント・アーキテクチャ、Issue→PR ワークフロー、非同期実行モデル」を再構築したと明言されています（GitHub Blog: Meet the new coding agent）。具体的には、GitHub 上で Issue を Copilot にアサインすると、Coding Agent がクラウド上の使い捨て環境で起動し、リポジトリをクローンして実装を進め、ドラフトのプルリクエストを自動で作成します。あなたは PR が上がってきたところでレビューに入る、という流れです。
研究プロジェクトだった Workspace が、本番運用に耐えるインフラとして GitHub のプラットフォームに深く統合された——これが移行の本質です。使い勝手の細部は変わっても、「Issue を起点に PR まで任せる」というあなたの運用の骨格はそのまま続けられます。
Coding Agent と Agent Mode はどう違うか（非同期 vs 同期）
ここで混同しやすいのが、Coding Agent と Agent Mode の違いです。名前が似ているうえ、どちらも「エージェント」と呼ばれるため、検索しているとごちゃ混ぜになりがちです。両者は動く場所と実行のされ方がまったく異なります。
Agent Mode は VS Code などのエディタ内で動く同期的なエージェントです。あなたが手元で指示を出し、エージェントが編集を進め、その場で確認しながら対話的に進めます。人間がそばにいて、リアルタイムで応答するのが前提です。
一方 Coding Agent は GitHub のクラウド上で動く非同期のエージェントです。Issue をアサインしたら、あなたはその場を離れて構いません。エージェントが裏で動き、完了したらドラフト PR という形で結果が返ってきます。Workspace の「投げて、待つ」という運用感を引き継いでいるのは Coding Agent のほうです。本記事で「丸投げ」の対象にしているのも、この非同期の Coding Agent です。手元で対話しながら詰めたいなら Agent Mode、非同期で放置したいなら Coding Agent、と切り分けて考えてください。
実行環境の差が使い分けを決める
ここからが本記事の核心です。Coding Agent と Claude Code の使い分けは、機能の有無ではなくどこで・どのくらいの時間・どれだけ並列に動けるかという実行環境の差で決まります。なぜ「途中で止まる」のか、なぜ「安全に丸投げできる」のかは、すべてこの環境制約から説明できます。
Coding Agent — GitHub Actions 実行・セッション上限・PR ファースト
Copilot Coding Agent は、GitHub Actions の上で、使い捨ての仮想マシン環境で動きます。ここに最も重要な制約があります。1 セッションあたりの実行時間は最大約 59 分で、これはハードリミットです。設定で延長することはできず、タスクがこの時間を超えると、セッションはタイムアウトして停止します（GitHub Docs: About GitHub Copilot cloud agent、community discussion #183671）。
加えて、Coding Agent は GitHub Actions の実行時間と AI クレジットを消費します。「とりあえず大きめのタスクを投げて、足りなければ待てばいい」という発想は通用しません。約 59 分で終わる見込みのスコープに収めることが、そもそもの前提になります。
その代わり、Coding Agent には「PR ファースト」という強みがあります。結果が必ずドラフト PR として GitHub 上に上がるため、レビュー導線が最初から GitHub のワークフローに乗っています。チームのレビュー文化に自然に組み込め、Issue をアサインするだけで完結する非同期運用は、Workspace 時代の使い勝手をそのまま受け継いでいます。
Claude Code — ローカル/CI 実行・時間無制限・並列サブエージェント
Claude Code は、あなたのターミナルや CI パイプラインの上で動きます。実行場所が手元（あるいは自前の CI 環境）であるため、約 59 分のような明確なセッション上限はありません。長時間かかる探索的な実装でも、環境が許す限り走り続けられます。
さらに大きな違いが並列サブエージェントです。Claude Code はコードベース全体の文脈を保ったまま、複数のサブエージェントを同時に起動して、コードベースの別々の部分を並行して処理できます。たとえば大規模なマイグレーションで、1 つのサブエージェントが API 層をリファクタリングし、別のサブエージェントがデータベースクエリを更新し、さらに別のサブエージェントがフロントエンドのコンポーネントを修正する——といった分担を並行で進められます（Morph: Codex vs Claude Code）。Claude Code の並列実行を本格的に活用する具体的な手法は、別記事のClaude Codeのサブエージェント並列実行で詳しく扱っています。
性能面でも、Claude Code を支える Claude Opus 4.8 は SWE-bench Verified で 88.6% のスコアを記録しており、自律的なコード生成タスクで高い水準にあります（Morph: Codex vs Claude Code）。時間の上限がなく、並列で動かせ、長い文脈を保てる——これが Claude Code 側の環境特性です。
「途中で止まる」のはどんなタスクか（環境制約から逆算する）
ここまでの環境差を踏まえると、「Coding Agent に任せたら途中で止まった」という手戻りの正体が逆算できます。止まるのは、約 59 分のセッション上限を超えるタスクです。具体的には次のようなものです。
- 複数モジュールにまたがり、影響範囲が広い大規模リファクタリング
- 仕様が固まっておらず、試行錯誤しながら進める探索的な実装
- ビルドやテストに長い時間がかかり、それを何度も繰り返す必要があるタスク
- 大量のファイルを横断して文脈を積み上げないと判断できないタスク
これらはセッション時間を食い尽くしやすく、Coding Agent では完走しきれずにタイムアウトする可能性が高くなります。逆に言えば、こうしたタスクは時間無制限で並列に動ける Claude Code に寄せるべきだ、という判断が環境制約から自然に導けます。「なんとなく不安」だった手戻りリスクが、「セッション上限を超えそうかどうか」という具体的な物差しに変わります。次の章では、この物差しをタスク別の一覧に落とし込みます。
非同期自律タスク別の任せ分けマトリクス
実行環境の差が判断の根っこだと分かったところで、実際の Issue を前にして即引きできる形に整理します。「このタスクはどちらに丸投げすれば失敗しにくいか」を、理由とセットで一覧にします。
非同期自律タスク別の任せ分けマトリクス
タスクの性質 | 推奨 | なぜそうなるか（環境制約から） |
|---|---|---|
単一〜少数ファイルの定型修正（バグ修正・文言変更など） | Coding Agent | 約 59 分で完結しやすく、PR が GitHub 上に上がりレビュー導線が自然。非同期で放置できる |
依存ライブラリのバージョン更新・軽微な追従 | Coding Agent | スコープが限定的で時間内に収まる。ドラフト PR で差分を確認しやすい |
既存仕様に沿ったテストの追加 | Coding Agent | 仕様が明確でスコープが切りやすく、短時間で完了する |
複数モジュールにまたがる大規模リファクタリング | Claude Code | セッション上限を超えやすい。並列サブエージェントで分担でき、時間無制限で完走しやすい |
仕様が曖昧で試行錯誤が必要な探索的実装 | Claude Code | 長時間の試行に上限がなく、手元で対話的に方向修正できる |
複数の実装候補を並行で試して比較したいタスク | Claude Code | 並列サブエージェントで同時に複数案を走らせられる |
GitHub Issue 起点で、非同期に放置して後でレビューしたいタスク | Coding Agent | Issue アサインだけで起動し、PR が返るまで離席できる |
手元のリポジトリで対話的に詰めながら進めたいタスク | Claude Code | ターミナルでリアルタイムに指示・修正できる |
この表の使い方はシンプルです。Issue を見たら「スコープは小さいか」「約 59 分で終わりそうか」「並列で試したいか」「非同期で放置したいか」を確認し、該当する行の推奨に従います。
定型・スコープが小さいタスクは Coding Agent に非同期で投げる
定型的でスコープが小さいタスク——バグ修正、文言の修正、依存更新、既存仕様に沿ったテスト追加など——は、Coding Agent に非同期で投げるのが第一候補です。約 59 分のセッション上限が問題になりにくく、結果がドラフト PR として GitHub に上がるため、チームのレビューにそのまま流せます。Workspace で気持ちよく回せていた「Issue を投げて、PR が来たらレビューする」運用は、この層でこそ最も力を発揮します。
ポイントは、Coding Agent の強みを「短時間で終わる・GitHub に閉じている・非同期で放置できる」と理解し、その範囲のタスクを意識的に選んで投げることです。背伸びして大きなタスクを投げると、前の章で見たとおりタイムアウトの手戻りを招きます。
大規模・長時間・並列探索は Claude Code に寄せる
一方、複数モジュールにまたがる大規模リファクタリング、仕様が曖昧な探索的実装、複数候補を並行で試したいタスクは、Claude Code に寄せます。時間の上限がなく、並列サブエージェントで分担でき、手元で対話的に方向修正できるため、Coding Agent では止まりやすいタスクを完走させやすくなります。
Claude Code をヘッドレスで CI に組み込み、定型的な自動処理として運用する方法もあります。ヘッドレス実行や権限設計の具体的な勘所は、別記事のClaude Codeによる業務自動化で整理しています。「対話的に詰めるか・自動で回すか」も含めて、Claude Code 側は柔軟に使い分けられます。
Agent HQ で Copilot 上に Claude を載せる選択肢（2026年の動向）
2026 年に入り、「どちらか一方を選ぶ」という前提自体が緩み始めています。GitHub は Agent HQ を通じて、Claude（Anthropic）や Codex（OpenAI）といった他社のコーディングエージェントを GitHub と VS Code の中から直接実行できるようにしました。2026 年 2 月に Copilot Pro+ / Copilot Enterprise 向けにパブリックプレビューが始まり、その後 Copilot Business / Pro ユーザーにも追加費用なしで提供範囲が広がっています（GitHub Blog: Pick your agent、GitHub Changelog 2026-02-04）。
これにより、GitHub の Issue→PR ワークフローや履歴・レビューの導線を保ったまま、エージェントとして Claude を指定する、という選択肢が現実になりました。1 つのタスクに複数のエージェントを割り当て、Copilot・Claude・Codex がトレードオフをどう推論し、どんな解にたどり着くかを見比べることもできます。ただしプレビュー段階の機能であり、運用に組み込む際は提供状況とプランの対象範囲を都度確認してください。本記事の使い分けの軸——スコープ・実行時間・並列性・非同期で放置したいか——は、こうしたマルチエージェント環境でも変わらず判断の土台になります。
丸投げの失敗を減らす任せ方
どちらに任せるかが決まっても、「的外れな PR が来る」「途中で迷走する」という不安は残ります。これは裏テーマそのものです。最後に、任せ方そのもので手戻りを減らす実務テクニックを整理します。これはどちらのエージェントを使う場合にも共通します。
タスクは「人間が15分で説明できる粒度」に切る
自律エージェントが的外れな成果物を返す最大の原因は、タスクが大きすぎる・曖昧すぎることです。目安として、「同僚に口頭で 15 分以内に説明しきれる粒度」までスコープを切ってください。説明に 15 分以上かかるなら、それは複数の Issue に分けるべきサインです。
特に Coding Agent では、この粒度がそのままセッション上限への適合性につながります。15 分で説明できる程度のスコープなら、約 59 分の実行時間に収まりやすく、タイムアウトによる中断も避けやすくなります。粒度を小さく切ることは、的外れ防止とタイムアウト防止を同時に効かせる、最もコストの低い対策です。
受け入れ条件とテストを Issue に書き込む
エージェントは Issue やプロンプトに書かれた情報を手がかりに動きます。逆に言えば、書かれていない期待は満たされません。「何ができていれば完了か」という受け入れ条件を Issue に明記し、可能なら検証用のテストや再現手順も添えてください。
受け入れ条件が明確なほど、エージェントは正解に向かいやすくなり、レビュー時にも「条件を満たしているか」を機械的に確認できます。さらに、エージェントが触ってよいファイルやディレクトリの範囲を限定して伝えると、想定外の箇所まで書き換えられる事故を防げます。曖昧な一文を投げて期待どおりの PR を待つより、最初に条件を書き切るほうが、結局は手戻りが少なく済みます。
生成 PR のレビュー責任は人間が持つ（受託開発での注意点）
最後に、運用上もっとも重要な原則です。エージェントが生成した PR の最終的な品質責任は、常に人間が持ちます。Coding Agent がドラフト PR を上げても、それは「人間がレビューする前提のたたき台」であって、無条件にマージしてよいものではありません。
受託開発の現場では、この点が特に重みを持ちます。秋霜堂株式会社のような受託開発を行う立場では、納品するコードの品質はクライアントへの責任に直結します。自律エージェントの生成物だからといってレビューを省くと、的外れな実装やセキュリティ上の見落としがそのまま納品物に紛れ込むリスクがあります。エージェントは「実装のたたき台を高速に作る道具」と位置づけ、レビュー・テスト・受け入れ判断という品質のゲートは人間が握り続けてください。Claude Code を受託開発で活用する際の採算管理や運用の考え方は、別記事のClaude Codeを受託開発で活用するでも触れています。この責任分界を守ることが、「丸投げしても安心」を成立させる前提条件です。
Issue を見たら任せ先を即決する判断軸
ここまでの流れを振り返ります。Copilot Workspace は終了しましたが、その役割は Copilot Coding Agent が受け継ぎました。Coding Agent と Claude Code の使い分けは、機能リストではなく実行環境の差——GitHub Actions 上の約 59 分セッション・PR ファースト vs ターミナル/CI 上の時間無制限・並列サブエージェント——から決まります。そこからタスク別の任せ分けが導け、最後に任せ方そのもので手戻りを減らせます。
Issue を前にしたときに確認すべき判断軸は、次の 4 つに圧縮できます。
- スコープは小さいか: 単一〜少数ファイルの定型修正なら Coding Agent。複数モジュールにまたがるなら Claude Code
- 想定実行時間は約 59 分に収まるか: 収まるなら Coding Agent、超えそうなら Claude Code
- 並列で複数候補を試したいか: 試したいなら Claude Code の並列サブエージェント
- 非同期で放置したいか・対話的に詰めたいか: 放置なら Coding Agent、手元で詰めるなら Claude Code
この 4 軸を Issue ごとに当てはめれば、「どちらに任せるか」で手が止まることはなくなります。まずは小さく確実なところから始めてください。定型的な Issue を 1 件、Coding Agent にアサインして挙動を確かめるのがおすすめです。約 59 分の中で何が起き、どんな PR が返ってくるかを一度体験すれば、自分のタスクのどこまでが Coding Agent の射程かが肌感覚で掴めます。
なお、補完・Agent Mode・Coding Agent を含めた Copilot 全体と Claude Code の総合的な比較を知りたい場合は、GitHub CopilotとClaude Codeの使い分けを参照してください。本記事は「非同期自律開発」というユースケースに絞った深掘りでしたが、ツール選択の全体像はそちらで整理しています。
よくある質問
- Coding Agentが約59分でタイムアウトした場合、それまでの作業はドラフトPRに残りますか？それとも全部消えますか？
タイムアウト時点までにエージェントがコミットした変更は、起動時に作られたドラフトPRにそのまま残ります。ゼロからやり直しにはならないため、PRの差分を見て「どこまで進んだか」を確認し、続きを別Issueに切り出すか、Issueのアサインを一度外して再アサインすることでセッションを投げ直せます（GitHub Docs: Troubleshooting coding agent）。ただし「途中から自動で延長して続行する」機能は提供されていません（残りの進捗を保存して途中再開する仕組みは要望段階です）。実務上は、中断を前提に小さく切って投げ、PRに残った部分を足がかりに次を回すのが安全です。「途中まで進んでいるなら待てば終わる」という期待では設計しないでください。
- Coding Agentがセッション上限の約59分でタイムアウトしてしまった場合、どう対処すればよいですか？
途中再開で延長することはできないため、Issueをより小さなスコープに分割して投げ直すのが基本です。タスクが本質的に大規模・長時間なら、時間無制限で並列実行できるClaude Codeに寄せる判断が適切です。
- 約59分で終わるかどうかを、Issueを投げる前に見積もる目安はありますか？
「同僚に口頭で15分以内に説明しきれる粒度か」を目安にしてください。15分以内で説明できる定型タスクは約59分に収まりやすく、説明に15分以上かかるものは複数Issueに分割すべきサインで、そのままだとタイムアウトの可能性が高くなります。
- Agent HQでCopilot上からClaudeを呼べるなら、使い分けを考える必要はなくなりますか？
なくなりません。Agent HQはGitHubの導線を保ったままエージェントを選べる仕組みですが、どのエージェントに何を任せるかの判断軸（スコープ・実行時間・並列性・非同期で放置したいか）は依然として必要です。なおAgent HQはプレビュー段階のため、提供状況とプラン対象は都度確認してください。
- チームにこの使い分けを導入するとき、最初に何から始めれば失敗しにくいですか？
いきなり全タスクを振り分けようとせず、まず「定型・少数ファイル・受け入れ条件が書ける」Issueを1〜2件だけCoding Agentにアサインして、PRが返るまでの一連の流れをチームで一度通すことから始めてください。最初の判断は「どちらが優秀か」ではなく「どのIssueなら安全に任せられるか」です。1〜2件の実績でレビュー負荷とPRの質感が掴めたら、大規模・探索的なタスクをClaude Code側に寄せる、という順で広げると、判断軸がチームの共通言語になりやすく、初手での手戻りを最小化できます。逆に最初から曖昧で大きいタスクを投げると、的外れなPRが出てチームが『使えない』と判断してしまいがちです。
- 受託開発で自律エージェントが生成したコードを納品する場合、クライアントに「AIが書いた」と説明する必要はありますか？
技術的な必須要件ではありませんが、契約・秘密保持・成果物の権利の観点から、事前に取り決めておくほうが安全です。実務上の判断軸は「AIが書いたかどうか」ではなく「誰が品質責任を負うか」で、本記事の通り最終的なレビュー・テスト・受け入れ判断は人間（受託側）が握り続けます。その前提を契約やキックオフで共有しておけば、生成手段そのものを逐一申告するかは案件の方針次第で構いません。むしろクライアントの懸念は「品質をどう担保するか」にあることが多いため、レビュー体制やテストのゲートを説明するほうが、納品物への信頼につながります。クライアント側にコード提供元・利用ツールの開示規定がある場合は、その規定に従ってください。
