GitHubのIssueをCopilotへ渡して修正を任せるときは、実装前の要求、作業中の追加指示、PRの差分と検証結果をつなげて確認します。Issueへ担当者を付ける操作は、文章の整理だけでなく、クラウドでコード変更を始める入口です。
この記事はGitHub.comのCopilot cloud agentへIssueを割り当て、作成されたPRを確認する流れです。GitHubへの投稿、担当割当、エージェント実行、コード変更、Actions実行は行っていません。入力検証の不具合と依頼文は架空の例です。
目次
先に、小さく完了を判断できるIssueへ整える
GitHub公式は、明確な問題、受入条件、変更対象の手掛かりを持つ作業を推奨しています。仕様が曖昧な大規模変更や、本番障害の緊急対応を、最初の試行と同じ扱いにしません。GitHub公式：Best practices（新しいタブで開く）
例えば「プロフィール保存時に空の表示名を受け付ける」という架空の不具合なら、依頼を次の範囲へ絞れます。
表は横にスクロールできます
| 項目 | 架空の依頼内容 |
|---|---|
| 問題 | 表示名が空文字でも保存成功になる |
| 期待 | 空文字を保存せず、既存の入力エラーを表示する |
| 維持 | 通常の表示名の保存、API応答形式、既存の認証 |
| 変更範囲 | 関連する入力検証とテスト。調査で分かった対象を示す |
| 対象外 | UI全面変更、依存パッケージ更新、DB移行、公開 |
| 確認 | 空文字の拒否と、通常値の保存を分けて確かめる |
空白だけの文字列、最大長、前後の空白の除去まで同時に直すなら、その仕様も必要です。元のIssueにない条件を「普通そうだから」と足さず、今回の要求に含めるか決めます。
Assigneesから、対象リポジトリと基点を確認する
公式のIssue割当手順は、Issue右側のAssigneesでCopilotを選び、必要ならOptional promptへ補足する流れです。対象リポジトリと開始ブランチも確認します。省略時はIssueと同じリポジトリ、選択したリポジトリの既定ブランチが使われる説明です。
割当時にはIssueのタイトル、本文、その時点のコメント、追加指示が渡されます。割当後にIssueへ追加したコメントは自動では伝わらないため、要件変更はCopilotが作ったPRのコメントへ伝えます。GitHub公式：Using Copilot cloud agent on GitHub（新しいタブで開く）
対象リポジトリを別にする場合は、非公開の報告内容がどこへ渡るかも確認してください。名前が似ているリポジトリを選ばず、所有者と公開範囲、開始ブランチを見ます。Issueを開いている場所と、実装する場所が常に同じとは限りません。
AssigneesにCopilotが表示されない場合は、契約と、対象リポジトリでの機能の有効状態を確認します。組織の管理対象なら管理者へ確認し、使えるようにするためだけに別の公開リポジトリへ内容を移す方法にはしません。
割当と、実装完了を分けて追う
Issue割当からはPRが作成され、作業完了後にレビューが求められる流れです。PRができたことだけで、実装やテストが完了したとは判断しません。
公式のトラブルシューティングでは、Issueへの反応とリンクされたDraft PRを確認し、PRのタイムラインに作業開始があればView sessionからログを見る手順です。GitHub公式：Troubleshooting cloud agent（新しいタブで開く）
表は横にスクロールできます
| 見えた状態 | 確認できること | まだ確定しないこと |
|---|---|---|
| Issueへの反応 | 依頼が受け取られた手掛かり | 修正完了、テスト成功 |
| Draft PRの作成 | 変更を確認する入口ができた | 必要な実装がすべて入った |
| セッションログ | 何を調査・実行したか | PR上のCIも同じ結果になった |
| レビュー依頼 | 人が差分を確認する段階 | マージや公開が承認された |
止まったように見える場合も、まず既存PRとセッションを確認します。状況を確認せず別の依頼を重ねると、同じ修正のPRが複数でき、どれを採用するか混乱します。結果が不明な作業を、未実行と決めつけないようにします。
追加要件はPRへ、差分が分かる形で伝える
架空例で、後から「空白だけの文字列も拒否する」と仕様が決まった場合、元のIssueへ追記するだけでは済ませません。PRで、変更した条件と、維持する条件をまとめます。
@copilot 追加仕様です。空文字に加え、空白だけの表示名も保存しないでください。通常値の保存とAPI応答形式は維持します。前後の空白を自動で除去する仕様は今回追加しません。関連する拒否ケースと通常ケースを確認し、実行した検証と未確認をPRへ記載してください。
これは投稿文の例です。実際にCopilotへ送ったものではありません。コメントを投稿するとコード変更が始まる場合があるため、相談だけのメモと、実装を依頼する文を区別します。
GitHub公式は、PRでの@copilotへの依頼と、書込権限を持つ人からのコメントに反応する条件を説明しています。複数の指摘を出す場合は、関連するものをまとめて伝えると、相反する要求や修正途中への追加を減らせます。
Actionsが未実行なら、成功と数えない
Copilotの作業環境でのテストと、PRのGitHub Actionsは別に確認します。公式は、既定ではCopilotのpush後にPRのActionsが自動実行されないと説明しています。差分を確認してからApprove and run workflowsを選ぶ手順です。人の介入なしで実行する設定もあるため、現在のリポジトリ設定を確認します。
特に.github/workflows/に変更があれば、実行内容と権限・秘密情報への影響を先に読みます。「Actionsが止まっているから」という理由だけで、内容を読まず実行を許すのではありません。GitHub公式：Review output from Copilot（新しいタブで開く）
表は横にスクロールできます
| 確認 | 架空例で欲しい根拠 |
|---|---|
| 空文字の拒否 | 保存されず、期待するエラーになるテスト結果 |
| 空白のみの拒否 | 追加仕様に対応する入力と結果 |
| 通常値の保存 | 既存の正常系を維持した結果 |
| 差分の範囲 | 関連実装とテストが中心で、対象外の変更がない |
| CI | 対象コミットに対応した実行結果。未実行なら未実行 |
テスト名や緑色の表示だけでなく、何を確認したテストかを読みます。拒否のテストだけ通り、通常の保存もできなくなっていれば、目的は満たしていません。期待値を弱めたり、失敗する検査を無効にしたりしていないかも差分で確認します。
マージ前に、要求・差分・結果を対応させる
Copilotからレビューを求められたら、最新コミットの差分を読み、Issueの条件と対応させます。レビュー後に追加コミットがあれば、その変更と検証結果を確認し直します。以前のコミットの成功を、新しい差分の成功へ読み替えません。
GitHubの公式レビュー案内では、PR承認が必要な場合、このCopilot PRに対する依頼者自身の承認は必要承認数へ数えられず、別のレビュアーの承認が必要と説明しています。実際の取り込み条件は、対象リポジトリのルールとPRの表示で確認してください。
IssueをCopilotへ渡す方法は、範囲を決めた作業を任せ、後でPRを確認したい場合に向きます。仕様を対話しながら詰めたい段階なら、先に調査や計画を整理します。Issueの報告内容を整える方法はAIでGitHub Issueを整理する手順、IDEでの局所修正はCopilotで既存コードを修正する方法で確認できます。
参考資料
- GitHub：Best practices for using Copilot to work on tasks（新しいタブで開く）
- GitHub：Using Copilot cloud agent on GitHub（新しいタブで開く）
- GitHub：Troubleshooting cloud agent（新しいタブで開く）
- GitHub：Review output from Copilot（新しいタブで開く）
資料確認日：2026年10月21日。Issue割当は公式でpublic previewと案内されています。利用条件、権限、課金、実行ポリシーは、利用時点の公式案内と対象リポジトリで確認してください。