GitHub Copilotで作成されたPull Request（PR）が「自分のPR検索に出てこない」「author:@meで拾えるのか分からない」と悩んでいる人向けの変更です。今回のポイントは、author:@meやauthor:ユーザー名でPRを検索したときに、本人が直接作成したPRだけでなく、Copilot cloud agentが本人の指示で開いたPRも一緒に表示されるようになったことです。GitHub.comの画面やGitHub MobileでPRを整理している開発者、レビュー担当者、チームリードは、検索条件や運用ルールを見直す価値があります。(The GitHub Blog)
Copilot-authored pull requests now included in author searches の要点
GitHub Changelogで案内された「Copilot-authored pull requests now included in author searches」は、PR検索の作者条件に関する改善です。
これまでは、Copilot cloud agentがユーザーの代わりに開いたPRを探す場合、人間が直接作成したPRとは別の検索や確認が必要になることがありました。今回の変更により、author:[username]またはauthor:@meを使ったPR検索で、人間が作成したPRとCopilotが本人の指示で開いたPRをまとめて確認しやすくなります。(The GitHub Blog)
特に影響が大きいのは、以下のような画面や使い方です。
| 確認したいこと | 使う検索・画面 | 期待できる変化 |
|---|---|---|
| 自分が責任を持つPRを一覧したい | author:@me | 自分が直接作成したPRと、Copilotが自分の指示で開いたPRをまとめて確認できる |
| 特定ユーザーのPRを確認したい | author:username | そのユーザー本人のPRと、そのユーザーのためにCopilotが開いたPRを探しやすくなる |
| GitHubのPull Requestsダッシュボードで作業を整理したい | Created by me などの既定ビュー | Copilot-authored PRも一覧に含まれるようになる |
| モバイルでPRを確認したい | GitHub Mobile | GitHub.com UIと同様に確認しやすくなる |
なお、GitHub Changelog上の当該ページは「Improvement」として表示されています。新しい独立機能というより、既存のPR検索とダッシュボードの挙動を実務に合わせて改善する変更と捉えると理解しやすいです。(The GitHub Blog)
何が変わったのか
author:@meでCopilot作成PRも見つけやすくなった
一番分かりやすい変更は、author:@meの検索結果です。
たとえば、GitHubのPull Requests画面で次のように検索します。
is:pr author:@meこの検索では、自分が手動で作成したPRに加えて、Copilot cloud agentが自分の指示で開いたPRも対象に含まれるようになります。GitHub Changelogでは、github.com/pullsでauthor:@meを使うと、自分自身のPRと、Copilotが自分の指示で開いたPRを返す例が示されています。(The GitHub Blog)
実務上は、「自分が対応すべきPR」「自分の作業としてレビュー・マージ判断が必要なPR」を一つの検索で追えるようになる点が重要です。
Created by meビューにも反映される
GitHubの既定ビューであるCreated by meのようなPR一覧にも、Copilot-authored PRが自動的に含まれるようになります。(The GitHub Blog)
これにより、Copilotに作業を任せたPRだけが別枠で埋もれるリスクを減らせます。チームでCopilot cloud agentを使っている場合、朝会前の確認、リリース前のPR棚卸し、レビュー待ちの確認などで効果が出やすい変更です。
作者表示は「ユーザー with Copilot」の方向に変わる
GitHubの新しいグローバルPull Requestsダッシュボードでは、Copilotだけを作者として扱うのではなく、username with Copilotのように、人間のユーザーとCopilotの関与を合わせて示す方向になっています。GitHubは、同様の変更を今後もプラットフォーム全体に展開していくと説明しています。(The GitHub Blog)
これは単なる表示名の変更ではありません。AIエージェントが作成したPRであっても、誰の指示・責任範囲で作られたのかを追いやすくするための変更です。
対象になる人
GitHub Copilot cloud agentを使ってPRを作らせている開発者
最も直接的な対象は、Copilot cloud agentにIssue対応やコード変更を依頼し、PRを作成させている開発者です。
GitHub Docsでは、Copilot cloud agentはリポジトリの調査、実装計画の作成、コード変更、バグ修正、テストカバレッジ改善、ドキュメント更新などを行えると説明されています。また、GitHub.com上のエージェント入口やIssue、Visual Studio Codeなどから、Copilotに新しいPRを開くよう依頼できます。(GitHub Docs)
そのため、次のような人は今回の変更を知っておくべきです。
- IssueをCopilotに割り当ててPR化している人
- GitHub上でCopilotに修正タスクを依頼している人
- Copilotが開いたPRを自分の担当PRとして管理したい人
author:@meを日常的に使ってPRを整理している人
レビュー担当者・メンテナー・チームリード
レビュー担当者やメンテナーにも影響があります。
Copilotが作成したPRであっても、チーム運用上は「誰が依頼したPRか」「誰がレビュー・マージ判断を持つのか」を明確にする必要があります。今回の変更により、特定メンバーが関与するPRをauthor:usernameで追いやすくなるため、レビュー割り当てや進捗確認がしやすくなります。
たとえば、チームリードが次のような検索を使うケースです。
is:pr is:open author:tanakaこの検索で、田中さんが直接作ったPRだけでなく、田中さんの指示でCopilotが開いたPRも確認できるようになれば、作業量やレビュー待ちの把握が現実に近づきます。
APIでPR一覧を集計している管理者・開発基盤チーム
GitHub Changelogでは、2026年7月16日にREST APIとGraphQL APIにもこの変更をロールアウト予定と案内されています。2026年6月時点では、まずGitHub.com UIとGitHub Mobileが対象です。(The GitHub Blog)
そのため、独自ダッシュボードや社内レポートでPRを集計している場合は注意が必要です。UI上では見えるのに、API経由の集計にはまだ反映されていない期間が発生する可能性があります。
よくある疑問
Copilot-authored pull requestsとは何ですか？
Copilot-authored pull requestsとは、開発者本人がGitHub上で直接PRを作るのではなく、Copilot cloud agentがユーザーの指示に基づいて作成したPRを指します。
Copilot cloud agentは、GitHub上でバックグラウンドに動作し、リポジトリの調査、ブランチ作成、コード変更、テストやリンターの実行、PR作成などを支援します。GitHub Docsでは、IDE内で動くagent modeとは異なり、Copilot cloud agentはGitHub Actionsベースの環境で自律的にタスクを進めるものとして説明されています。(GitHub Docs)
つまり、Copilot-authored PRは「AIが勝手に作ったPR」ではなく、「ユーザーが依頼し、Copilotが作業して開いたPR」と理解するのが実務上は適切です。
author:@meとauthor:@copilotはどう使い分けますか？
author:@meは、自分が関与する作者条件としてPRを探したいときに使います。今回の変更により、自分が直接作ったPRと、Copilotが自分の指示で開いたPRをまとめて見つけやすくなりました。(The GitHub Blog)
一方、author:@copilotは、Copilot自体が作者として扱われるIssueやPRを探したいときの検索です。GitHub Docsでも、assignee:@copilotやauthor:@copilotのように、Copilotに割り当てられたもの、またはCopilotが作成したものを検索できると説明されています。(GitHub Docs)
実務では、次のように使い分けると分かりやすいです。
| 目的 | 検索例 | 向いている場面 |
|---|---|---|
| 自分の担当PRをまとめて見たい | is:pr author:@me | 日次のPR確認、レビュー前の棚卸し |
| 特定メンバーの担当PRを見たい | is:pr author:username | チームリードの進捗確認 |
| Copilotが作成したPRを広く探したい | is:pr author:@copilot | Copilot利用状況の確認、運用ルールの見直し |
| 自分の未完了PRだけ見たい | is:pr is:open author:@me | 作業中PRの整理 |
| マージ済みの自分関連PRを見たい | is:pr is:merged author:@me | リリースノート前の確認 |
GitHub Mobileでも使えますか？
はい。GitHub Changelogでは、今回の変更はGitHub.com UIとGitHub Mobileに適用されると説明されています。(The GitHub Blog)
外出中や移動中にPRを確認する人にとっては、Copilotが作成したPRだけが見落とされにくくなる点がメリットです。ただし、アプリの表示が古い、ログインアカウントが異なる、対象リポジトリの権限がない場合は、期待したPRが見えないことがあります。
REST APIやGraphQL APIではすぐ使えますか？
2026年6月時点の公式案内では、REST APIとGraphQL APIへの展開は2026年7月16日予定です。(The GitHub Blog)
そのため、APIでPR一覧を取得している社内ツールでは、GitHub.com上の検索結果とAPIの結果が一時的に一致しない可能性があります。
たとえば、次のような運用をしている場合は確認が必要です。
- 毎週のPR件数をAPIで集計している
- リリース候補PRをGraphQLで取得している
- メンバー別のPR作成数を社内ダッシュボードに出している
- Copilotが作ったPRを別のラベルやステータスで管理している
API反映前後で集計条件が変わると、PR件数が増えたように見えることがあります。これはチームの作業量が急に増えたのではなく、検索・集計対象にCopilot-authored PRが含まれたことが原因かもしれません。
既存のPR検索クエリは変更する必要がありますか？
多くの場合、既存のauthor:@meやauthor:usernameはそのまま使えます。今回の変更は、検索クエリを複雑にしなくても対象PRを広く拾えるようにするための改善です。GitHub Changelogでも、ユーザーが責任を持つPRを返すために複数検索や複雑なクエリを使う必要がなくなると説明されています。(The GitHub Blog)
ただし、社内運用によっては見直しが必要です。
たとえば、「人間が直接作成したPRだけを集計したい」「Copilotが開いたPRを別枠で監査したい」といった場合、従来のauthor:検索だけでは意図より広く拾う可能性があります。PRタイトル、ラベル、作成者表示、タイムライン、レビュー担当者などを組み合わせて、チーム内で定義を揃えることが大切です。
使えない・見えない時の確認観点
GitHub.com UIまたはGitHub Mobileで確認しているか
今回の変更は、まずGitHub.com UIとGitHub Mobileに適用されると案内されています。REST APIとGraphQL APIは2026年7月16日展開予定です。(The GitHub Blog)
そのため、API、外部BIツール、社内ダッシュボード、古い連携ツールで確認している場合は、まだ同じ結果にならない可能性があります。
まずはブラウザでGitHubにログインし、Pull Requests画面で次の検索を試してください。
is:pr author:@me対象を開いているPRに絞るなら、次のようにします。
is:pr is:open author:@meそのPRが本当に「自分の指示でCopilotが開いたPR」か
author:@meで含まれるのは、Copilotがユーザーの代わりに開いたPRです。単にCopilotがコメントした、レビューした、修正提案を出した、というだけでは「自分の作者検索」に含まれるとは限りません。
確認すべきポイントは次の通りです。
| 確認項目 | 見る場所 | 判断のヒント |
|---|---|---|
| PRを開いた主体 | PRの作者表示・タイムライン | username with Copilotのような表示があるか確認する |
| 依頼元 | Issue、Copilot Chat、Agent session | 自分がCopilotに作業を依頼した履歴があるか確認する |
| レビュー依頼 | PRのReviewers | 自分がレビュー担当として追加されているか確認する |
| ブランチやコミット | PRのCommits・Files changed | Copilotが作成・更新した履歴があるか確認する |
GitHub Docsでは、CopilotにIssueを割り当てると、Copilotが作業してPRを作成し、完了後にユーザーへレビューを依頼すると説明されています。(GitHub Docs)
検索条件が狭すぎないか
author:@meに他の条件を組み合わせている場合、別の条件が原因で表示されないことがあります。
たとえば、次の検索では「自分関連のオープンPR」だけが対象です。
is:pr is:open author:@meすでにマージ済みなら表示されません。マージ済みも見たい場合は、次のように変えます。
is:pr is:merged author:@meまた、リポジトリを絞っている場合は、対象リポジトリが正しいか確認します。
repo:owner/repository is:pr author:@meGitHub Docsでは、IssueやPull Requestの検索バーで、作者、担当者、ラベル、レビュー状態、ステータスなど多様な条件を組み合わせて検索できると説明されています。(GitHub Docs)
権限やリポジトリの見え方を確認する
検索結果に出るかどうかは、リポジトリへのアクセス権限にも左右されます。対象PRがプライベートリポジトリにある場合、ログイン中のアカウントに権限がなければ表示されません。
特に、次のケースは見落としやすいです。
- 個人アカウントと会社アカウントを切り替えている
- GitHub Mobileで別アカウントにログインしている
- Organizationの権限が変更された
- 対象リポジトリが移管・アーカイブされた
- PRがドラフト、クローズ、マージ済みで検索条件から外れている
「Copilotで作ったはずなのに見えない」と感じたら、まずアカウント、リポジトリ、PR状態、検索条件を順番に切り分けるのが近道です。
実務での活用例
自分のPR棚卸しを1つの検索にまとめる
日々の作業確認では、次の検索をブックマークしておくと便利です。
is:pr is:open author:@meこれにより、自分が直接作成したPRだけでなく、Copilotに依頼して開かれたPRもまとめて確認しやすくなります。
レビューが必要なPR、CIが落ちているPR、マージ待ちのPRをさらに絞りたい場合は、GitHubの検索条件を追加します。
is:pr is:open author:@me status:failureis:pr is:open author:@me review:requiredGitHub Docsでは、PR検索でレビュー状態やステータスを条件にできることが説明されています。たとえば、review:requiredやstatus:failureなどを使ってPRを絞り込めます。(GitHub Docs)
チームリードがメンバー別の作業を確認する
チームリードは、メンバー別にPRを確認する時にauthor:usernameを使えます。
is:pr is:open author:suzukiCopilot cloud agentを使うチームでは、「鈴木さんが直接作ったPR」と「鈴木さんがCopilotに作らせたPR」を分けて探すより、まずは鈴木さんが責任を持つPRとしてまとめて確認する方が自然です。
そのうえで、AI生成PRだけをレビュー強化したい場合は、PRラベルやテンプレート運用を組み合わせると管理しやすくなります。
例として、Copilotが作成したPRに次のようなラベルを付ける運用が考えられます。
copilot-authored
needs-human-review
ai-generated-changeGitHub側の作者検索だけに頼らず、ラベルやレビュー必須ルールと組み合わせることで、品質管理と作業管理を両立できます。
リリース前のPR確認に使う
リリース前は、「この期間に誰がどのPRを作ったか」を確認する場面があります。Copilotが作ったPRがauthor:@meやauthor:usernameに含まれるようになると、リリース候補の洗い出し漏れを減らせます。
たとえば、期間を指定して確認する場合は、次のような検索が役立ちます。
is:pr is:merged author:@me merged:2026-06-01..2026-06-30Copilotに依頼した軽微な修正、テスト追加、ドキュメント更新なども拾いやすくなるため、リリースノート作成前の確認にも向いています。
運用で注意したいポイント
「作者」と「最終責任者」を混同しない
今回の変更により、Copilotが開いたPRも人間の作者検索に含まれやすくなります。ただし、作者検索に出ることと、コード品質の責任をすべて自動で満たしていることは別です。
Copilot-authored PRでも、最終的には人間が次の点を確認する必要があります。
- 要件を満たしているか
- 変更範囲が大きすぎないか
- テストが通っているか
- セキュリティ上の問題がないか
- 既存設計やコーディング規約に合っているか
- 生成された説明文やコメントに誤りがないか
Copilot cloud agentはPR作成までを効率化しますが、レビュー判断やマージ判断まで完全に肩代わりするものではありません。
API集計の前後で数字が変わる可能性がある
REST APIやGraphQL APIへの反映は2026年7月16日予定です。(The GitHub Blog)
この前後で、社内レポート上のPR数、ユーザー別作成数、Copilot利用PR数が変わって見える可能性があります。特に月次レポートや四半期レビューでPR数を指標にしている組織は、集計ロジックの変更日を記録しておくべきです。
おすすめは、レポートの注記に次のような文言を残すことです。
2026年7月中旬以降、GitHubのauthor検索仕様変更により、Copilotがユーザーの代わりに作成したPull Requestがユーザー別PR集計に含まれる可能性があります。こうしておくと、後から数字を比較するときに「なぜ急にPR数が増えたのか」を説明しやすくなります。
Copilot利用PRのレビュー基準を決めておく
Copilotが作成したPRが通常の作者検索に混ざるようになると、便利な一方で、AI生成変更のレビュー基準が曖昧になりやすくなります。
最低限、次のルールをチームで決めておくと安全です。
| ルール | 具体例 |
|---|---|
| 小さな変更から任せる | ドキュメント修正、テスト追加、軽微なリファクタリングから開始する |
| レビュー必須にする | Copilot-authored PRは必ず1人以上がレビューする |
| ラベルを付ける | copilot-authoredなどのラベルで識別する |
| CI通過を必須にする | テスト、Lint、型チェックをマージ条件に含める |
| 変更範囲を制限する | 認証、課金、権限管理など高リスク領域は慎重に扱う |
特に、Copilotが作成したPRがauthor:@meに含まれるようになると、通常のPRと同じ流れで処理されやすくなります。効率化のためにも、レビュー観点だけは明文化しておくと安心です。
まず確認すべきこと
Copilot-authored pull requests now included in author searchesは、Copilot cloud agentを使うチームにとって、PR管理を実態に近づける変更です。author:@meやauthor:usernameで、本人が直接作ったPRとCopilotが本人の指示で開いたPRをまとめて確認しやすくなります。
まずはGitHub.comで次の検索を試してください。
is:pr author:@me次に、オープン中のPRだけを確認します。
is:pr is:open author:@meチームで使う場合は、API集計への反映タイミング、Copilot-authored PRのラベル運用、レビュー必須ルールを合わせて見直すのがおすすめです。検索で見える範囲が広がるほど、PR管理は楽になりますが、レビュー責任まで自動化されるわけではありません。Copilotを「PRを作る担当」として活用し、人間は「判断と品質保証」に集中できる形へ運用を整えることが重要です。
コメント