GitHub Copilot appで複数のissueやpull requestを並行処理していると、『今どれが進行中で、どれがレビュー待ちで、どれが終わったか』が見えにくくなります。2026年8月19日にGitHubが公開したMy work paneの解説は、この散らかりやすい状況をどう整理するかに焦点を当てたものです。単なる画面改善ではなく、agent sessionが増えるほど価値が出る運用機能として理解すると、導入判断がしやすくなります。
GitHub Copilot appのMy workとは何か
GitHubの公式記事によると、My work paneはCopilot app内で自分のpull requestsとissuesを一か所に集約して確認するための画面です。対象になるのは、Copilot appの中で自分が触れたprojectにひもづくrepositoryで、アクセスできる全repoが自動で並ぶわけではありません。この制約は地味ですが重要で、現場では『必要なrepoが見えない』のではなく『まだそのrepoでsessionを開始していない』だけというケースを切り分けやすくします。
標準ビューとして案内されているのは、全体を確認するAll、未完了の項目を見るActive、他者からレビュー依頼を受けたpull requestを見るReview requests、完了済みを追うDoneです。レビュー待ちと実装中を同じ場所で追えるため、agentに作業を任せながら人間が確認すべきPRを見落としにくくなるのが実務上の変化です。
8月19日の公開で何が変わるのか
今回のポイントは、Copilot appを『会話する場所』から『仕事の流れを管理する場所』へ一段進めたことです。これまでのsession中心の使い方では、依頼を投げたあとに一覧性を失いやすく、どのissueからどのsessionを起こしたかを人間側が覚えておく必要がありました。My work paneを前提にすると、issueとpull requestを起点に仕事を再開できるため、agent利用が増えるほど整理コストを下げやすくなります。
加えて、GitHubの8月7日付weekly releasesでは、desktop appとCLIの更新が『workを再開しやすくし、整理しやすくする』方向で進んでいると説明されています。Copilot app側ではshared sessionsへ直接飛べることや/sideで本筋を崩さず横道の質問を掘れることが案内されており、My workの一覧管理と組み合わせると、複数案件を並行で扱うチームほど恩恵が出やすい流れです。
実務で効く使い方：カスタムビューと複数session管理
公式記事ではNew viewから独自ビューを作成でき、Is: IssueやAssignee: Meのような条件で絞り込めるとされています。ここで効くのは、単に『自分のissue一覧』を作ることではなく、運用ルールに合わせてビューを分けることです。たとえば『今週中に返すreview request』『自分が一次切り分けする障害』『agentに投げる候補issue』のように分けると、朝の確認動線がかなり短くなります。
一覧表示もlist viewだけでなくtable viewへ切り替えられ、列の表示、並び替え、幅調整ができます。個人利用では見た目の違いに見えますが、複数repoを横断して担当するleadやmanagerにとっては、更新日時順、repo順、assignee順などに切り替えながらボトルネックを把握できる意味があります。『何をしているか』だけでなく『どこで止まっているか』を見るためのUIだと捉えると使いどころが明確です。
さらに、issueやpull requestを開いてそのまま新しいsessionを始めたり、複数項目をまとめて選択してsession化したりできる点も重要です。独立したfeature requestなら1件ずつsessionを切り、同じ機能に関するbug reportが複数あるなら1つに束ねてsessionを起こす、といった使い分けができます。repo hosting先と実際に修正するrepoが別でも、session起動時にrepoを変更できるため、triage担当と実装担当が分かれている組織にも合わせやすい設計です。
導入前に確認したい判断ポイント
1つ目は、Copilot appを単発の相談窓口ではなく、複数sessionを運用する前提で使っているかです。sessionが常に1本だけなら恩恵は限定的ですが、bug修正、レビュー、企画メモ、検証タスクが並行するチームでは一覧管理の価値が一気に高まります。『agentを増やす前に、人間が追える見取り図を持てるか』が判断軸です。
2つ目は、issue運用がどれだけ整理されているかです。My workはissueやpull requestを起点に整理するので、issueが粗いままだと一覧だけ整っても判断が難しくなります。逆に、優先度、担当、レビュー依頼の基本が整っているチームなら、Copilot側のsession起動と人間側の作業管理がつながりやすく、agent導入が『別システム』になりにくいです。
3つ目は、レビュー待ちと実装待ちを分けて見たいかです。Review requestsビューが標準であるため、コードを書く作業と人間が意思決定する作業を分けて追いやすくなります。AI活用が進むほど、ボトルネックは生成そのものよりレビューや承認に移ることが多いので、ここを見える化できるかは小さくない差になります。
導入の進め方
実務では、まずCopilot appを使っている代表的なrepoで短いsessionを1本ずつ作り、My workにどこまで自動で集約されるかを確認するのが安全です。そのうえで、ActiveとReview requestsを日次確認の入口にし、必要なら『自分担当のissue』『今週中に返すPR』などのカスタムビューを追加します。一覧ができてからsession数を増やす順番にすると、便利さより先に混乱が来る状態を避けやすくなります。
もし運用ルールを社内展開するなら、1. sessionを起こす前にissueかPRをひも付ける、2. bug群は必要に応じてbundleして1 sessionにまとめる、3. review requestは毎日同じ時間に確認する、の3点をテンプレ化すると定着しやすいです。My workは高度な自動化機能というより、agent活用を仕事の棚に戻すための基本画面として扱うほうが失敗しにくいでしょう。
よくある疑問
Q. 見えるのは全repositoryですか。A. いいえ。GitHubの公式記事では、Copilot app内で自分が触れたprojectに基づいて一覧が絞られると説明されています。Q. 自分用の絞り込みは作れますか。A. はい。New viewから独自ビューを作成し、IssueやAssigneeなどの条件を組み合わせられます。Q. issueからすぐagent作業を始められますか。A. はい。項目を開いて新規sessionを始めるか、複数項目を選んでsession化できます。
まとめ
GitHub Copilot appのMy workは、8月19日の公式解説で明確になったように、複数session時代の仕事の見取り図を作るための機能です。強みは、issue・pull request・review requestを一か所で追いながら、そのままagent sessionへつなげられる点にあります。Copilotを個人の補助ツールからチームの実務フローへ広げたいなら、モデル性能の比較より先に、この一覧性をどう使うかを決めておくほうが効果が出やすいです。
GitHub Copilot appの運用設計や、issue管理とagent活用を社内フローに落とし込みたい場合は、 HelloCraftAIに相談する からご連絡ください。導入ルール、教育、レビュー体制までまとめて支援できます。
