Copilot-authored pull requests now included in author searchesの使い方｜PR検索で迷うポイントを解説

Copilotで作成されたPull Requestを探すときに迷いやすいのは、「Copilotが開いたPRは誰のPRとして検索されるのか」という点です。今回の変更により、author:@me や author:ユーザー名 でPull Requestを検索すると、自分が直接作成したPRだけでなく、Copilot cloud agentが自分の指示で開いたPRも一緒に表示されるようになりました。つまり、設定を有効化する新機能というより、GitHub上のPR検索結果の見え方が変わった更新として理解すると迷いません。GitHub Changelogでは2026年6月18日付の更新として公開されており、日本時間では2026年6月19日頃に確認される内容です。公式ページ上の分類は「Improvement」として掲載されています。(The GitHub Blog)

何が変わったのか

今回の「Copilot-authored pull requests now included in author searches」は、GitHub Copilotが開いたPull Requestの扱いを分かりやすくする変更です。

これまでは、Copilot cloud agentがユーザーの代わりにPRを開いた場合、「そのPRを誰の作業として検索すればよいのか」が分かりにくい場面がありました。自分が依頼した作業なのに、通常のauthor:@me検索では見つけにくく、@copilotや別条件を使って探す必要が出ることがありました。

今回の変更後は、author:@meで検索すれば、次の2種類のPRをまとめて確認できます。

検索結果に含まれるPR	具体例
自分で直接作成したPull Request	ブランチを作成し、自分でPRを開いたもの
Copilot cloud agentが自分の指示で開いたPull Request	Copilotに修正や実装を依頼し、CopilotがPRを作成したもの

GitHubの公式説明では、author:[username]またはauthor:@meを使ったPull Request検索で、人間が作成したPRとCopilotが作成したPRが一緒に返るようになったと案内されています。github.com/pullsの「Created by me」のような既定ビューにも、Copilotが開いたPRが自動的に含まれるようになります。(The GitHub Blog)

まず覚えるべき使い方は「author:@me」

実務で最初に使うべき検索は、author:@meです。

GitHubにログインした状態で、グローバルのPull Request一覧やリポジトリのPull Requests画面を開き、検索欄に次のように入力します。

is:pr author:@me

この検索で、自分が直接開いたPRと、自分の指示でCopilot cloud agentが開いたPRをまとめて確認できます。

特定リポジトリのOpen PRだけを見たい場合は、次のように条件を足します。

is:pr is:open author:@me

レビュー済みやマージ済みも含めて確認したい場合は、状態条件を変えます。

is:pr is:merged author:@me

GitHub Docsでは、IssueやPull Requestの検索欄は、各リポジトリのIssues・Pull requestsタブや、Issues・Pull requestsのダッシュボードで使えると説明されています。また、author:は作成者で絞り込む検索条件で、@meを使うと自分に関係する条件として検索できます。(GitHub Docs)

設定場所で迷ったときの答え

この変更について「どこで設定をオンにするのか」と迷う人が多いですが、基本的には個別に有効化する設定ではありません。GitHub側の検索仕様が変わるため、ユーザーは従来どおりPull Request検索を使えば反映されます。

迷いやすい点	答え
管理画面で有効化が必要か	通常のPR検索機能の変更なので、専用のオン・オフ設定として考えなくてよい
どこで使うのか	github.com/pulls、リポジトリのPull Requests画面、GitHub Mobileなど
どの検索条件を使うのか	author:@meまたはauthor:ユーザー名
CopilotだけのPRを探したい場合	author:@copilotなど、目的に応じて別条件を使う
APIでも同じ結果になるか	公式情報では、REST APIとGraphQL APIへの展開は2026年7月16日予定と案内されている

特に注意したいのは、2026年6月時点では、GitHub.comのUIとGitHub Mobileが対象で、REST APIとGraphQL APIへの反映は2026年7月16日に展開予定とされている点です。社内ツールやダッシュボードでAPI検索を使っている場合は、UIとAPIで一時的に結果が異なる可能性があります。(The GitHub Blog)

Copilot cloud agentのPRとは何か

今回の変更を理解するには、「Copilot cloud agentがPRを開く」という流れを押さえておく必要があります。

Copilot cloud agentは、GitHub上でタスクを受け取り、リポジトリを調査し、実装計画を立て、ブランチ上で変更を行い、必要に応じてPull Requestを作成する仕組みです。GitHub Docsでは、Copilot cloud agentがリポジトリの調査、実装計画、バグ修正、機能追加、テスト改善、ドキュメント更新などを行えると説明されています。(GitHub Docs)

たとえば、開発者がCopilotに次のような依頼をします。

ログイン失敗時のエラーメッセージを分かりやすくして、Pull Requestを作成してください。

Copilot cloud agentがその依頼をもとにブランチを作成し、コードを変更し、PRを開いた場合、そのPRはCopilotによって作成されたものです。ただし、作業の起点は人間の開発者にあります。

今回の変更では、このようなPRもauthor:@meの検索結果に含まれるようになりました。これにより、「自分が責任を持って確認すべきPR」を1回の検索で把握しやすくなります。

実務で便利な検索例

Copilotをチームで使う場合は、単にauthor:@meだけを覚えるより、状態やレビュー条件を組み合わせると管理しやすくなります。

やりたいこと	検索クエリ例
自分が作成・依頼したOpen PRを確認する	is:pr is:open author:@me
自分が作成・依頼したマージ済みPRを確認する	is:pr is:merged author:@me
特定ユーザーが作成・依頼したPRを確認する	is:pr author:octocat
Copilotが関係するPRだけを探す	is:pr author:@copilot
まだレビューされていないOpen PRを探す	is:pr is:open review:none author:@me
レビューが必須のPRを確認する	is:pr is:open review:required author:@me
CIが失敗しているPRを確認する	is:pr is:open status:failure author:@me

GitHub Docsでは、Pull Request検索でreview:none、review:required、status:success、status:failure、is:mergedなどの条件を使えると案内されています。Copilotが開いたPRもauthor:@meに含まれるようになることで、これらの条件と組み合わせた管理がしやすくなります。(GitHub Docs)

「Created by me」の見え方も変わる

今回の変更は、検索欄に手入力するクエリだけではありません。

GitHub Changelogでは、github.com/pullsの「Created by me」のような既定のPull Requestビューにも、Copilotが作成したPRが自動的に含まれると説明されています。つまり、普段からGitHubのPull Requestダッシュボードで自分のPRを確認している人は、特別な操作をしなくても表示件数が増える可能性があります。(The GitHub Blog)

これは便利な一方で、最初は「急に自分が作ったPRが増えた」と感じるかもしれません。実際には、自分が手で作成したPRだけでなく、Copilotに依頼して作成されたPRも同じ責任範囲として表示されるようになった、という理解が正確です。

使い方で迷いやすいポイント

Copilotが作ったPRは「自分のPR」なのか

実務上は、「自分が依頼し、レビューやマージ判断を行うPR」として扱うのが自然です。

GitHubの新しいグローバルPull Requestダッシュボードでは、Copilotだけでなく「ユーザー名 with Copilot」のように、人間のユーザーとCopilotの関係が分かる形で著者が表示されると案内されています。(The GitHub Blog)

この表示は、責任の所在を曖昧にしないために重要です。Copilotがコードを書いたとしても、最終的にレビューし、マージするか判断するのは人間です。チーム運用では「Copilotが作ったから自動的に安全」と考えず、通常のPRと同じレビュー基準で確認する必要があります。

author:@meとauthor:@copilotはどう使い分けるのか

author:@meは、自分が関与して作成されたPRをまとめて確認したいときに使います。今回の変更後は、自分が直接作成したPRと、自分の指示でCopilotが開いたPRが一緒に表示されます。

一方、author:@copilotは、Copilotが著者として関係するPRを探したいときに使います。GitHub Docsでも、assignee:やauthor:などの検索条件で@copilotを使い、Copilotに割り当てられたIssueやCopilotが作成したIssue・PRを検索できると説明されています。(GitHub Docs)

使い分けの目安は次のとおりです。

目的	使う検索条件
自分が責任を持つPRを確認したい	author:@me
特定メンバーが依頼したPRを確認したい	author:ユーザー名
Copilotが作成したPRを中心に確認したい	author:@copilot
チーム全体のAI活用状況を見たい	author:@copilotにリポジトリや期間条件を追加

API連携している場合は反映時期に注意する

社内の開発メトリクス、リリースノート生成、PR一覧通知などをREST APIやGraphQL APIで作っている場合は、UIと同じ感覚で判断しないようにしましょう。

公式情報では、この変更はまずGitHub.com UIとGitHub Mobileに適用され、REST APIとGraphQL APIには2026年7月16日に展開予定とされています。(The GitHub Blog)

そのため、2026年7月16日より前後の期間に、次のような差が出る可能性があります。

場面	起こり得ること
GitHub UIでauthor:@meを検索	Copilotが自分の指示で開いたPRも含まれる
社内ツールでAPIからPRを集計	反映前はCopilot作成PRが同じ条件で含まれない可能性がある
週次レポートを自動生成	UI上の件数とレポート上の件数が一時的にずれる可能性がある

管理者や開発リーダーは、API反映前後でPR件数の集計条件が変わる点をチームに共有しておくと、レポートの数字を誤解しにくくなります。

導入前に確認したい前提条件

この変更自体は検索機能の改善ですが、チームでCopilot cloud agentを使うなら、PR運用の前提を整えておくことが大切です。

CopilotがPRを開く運用になっているか

まず、自分たちのチームがCopilot cloud agentにPR作成まで任せているかを確認しましょう。

GitHub Docsでは、Copilotに「Pull Requestを開いてほしい」と依頼できる例が示されています。また、Copilotが作業を開始し、コード変更をプッシュし、セッションログからPRを開ける流れも説明されています。(GitHub Docs)

まだCopilotにコード補完やチャットだけを使っている場合、今回の変更による影響は限定的です。一方、Copilot cloud agentにIssue対応や軽微な修正を任せているチームでは、author:@me検索の意味が変わるため、PR確認フローを見直す価値があります。

レビュー責任を明確にしているか

Copilotが開いたPRも、最終確認は人間が行う必要があります。

特に次のような変更は、Copilot生成であっても通常のPRと同じように確認しましょう。

確認項目	見るべきポイント
仕様との一致	依頼内容を過剰に解釈していないか
影響範囲	変更対象外のファイルまで修正していないか
テスト	既存テストが通るか、新規テストが必要か
セキュリティ	認証、権限、入力値処理に問題がないか
保守性	チームのコーディング規約に合っているか

author:@meでCopilot作成PRが見えるようになると、自分が確認すべきPRを見落としにくくなります。逆に言えば、検索結果に出てきたPRを「自分は作っていないから関係ない」と扱うと、レビュー漏れにつながります。

社内ルールやメトリクスの定義を見直す

開発チームによっては、PR数を生産性指標、評価資料、リリースノート、監査ログの一部として使っていることがあります。

今回の変更後は、author:@meで見えるPR数に、Copilotが作成したPRも含まれます。そのため、次のような定義を見直すと安全です。

見直す対象	確認したいこと
個人別PR数	Copilotが開いたPRを個人の作業として含めるか
AI活用レポート	Copilot作成PRを別集計にするか
リリースノート	Copilot作成PRの貢献者表記をどう扱うか
監査・承認フロー	Copilot作成PRも通常PRと同じ承認を必須にするか
チームKPI	PR件数だけでなくレビュー品質やマージ後の安定性も見るか

PR数だけを見ると、Copilot活用が進んだチームほど「人間が直接書いたPR」と「Copilotに依頼したPR」が混ざります。実態を把握するには、author:@meで責任範囲を確認しつつ、author:@copilotやラベル、ブランチ名、作成者表示も併用するのがおすすめです。

よくある勘違いと対処法

自分が作っていないPRが表示される

author:@meで見たときに、見覚えの薄いPRが出てきた場合は、Copilot cloud agentに依頼したタスクから作成されたPRの可能性があります。

PRの作成経緯、タイムライン、ブランチ名、説明文、Copilotとのやり取りを確認しましょう。チームで複数人がCopilotを使っている場合は、誰の依頼で作成されたPRなのかをPR本文やコメントで分かるようにしておくと、後から追いやすくなります。

CopilotのPRだけを除外したい

自分が手で作成したPRだけを厳密に見たい場合、今回の変更後はauthor:@meだけでは目的に合わない可能性があります。

GitHub検索では条件の除外に-を使えるため、目的に応じて除外条件を試す余地があります。ただし、Copilot関連PRの表記や著者の扱いはGitHub側の展開状況によって変わる可能性があります。重要な集計に使う場合は、検索結果をサンプル確認してから運用に組み込むのが安全です。

PR数が増えて見える

「Created by me」やauthor:@meの結果にCopilot作成PRが含まれるため、以前よりPR数が増えて見えることがあります。

これは、作業量が急に増えたというより、これまで別扱いに見えていたCopilot作成PRが、ユーザーの責任範囲として見えるようになったためです。週次レポートやチームレビューで数字を比較する場合は、変更前後で検索仕様が変わったことを注記しておくと誤解を防げます。

チームで使うときのおすすめ運用

Copilot cloud agentを使うチームでは、検索条件だけでなくPR運用のルールを揃えると効果が出やすくなります。

運用ルール	具体例
PR本文に依頼元を残す	「CopilotにIssue #123の対応を依頼」などを記載する
ラベルを付ける	copilot, ai-assisted, needs-human-reviewなど
レビュー担当を明確にする	Copilot作成PRでも人間のレビュワーを必ず設定する
検索クエリを共有する	チームWikiにis:pr is:open author:@meなどを載せる
集計条件を固定する	月次レポートで使う検索条件を明文化する

特におすすめなのは、Copilot作成PRにチーム共通のラベルを付ける運用です。author:@meで責任範囲を確認し、ラベルでAI関与の有無を切り分けられるようにしておくと、レビューや振り返りがしやすくなります。

管理者・リーダーが確認すべきポイント

開発リーダーやGitHub管理者は、今回の変更を単なる検索改善として流さず、次の3点を確認しておくとよいでしょう。

確認項目	理由
Copilot作成PRのレビュー基準	AI生成コードを通常PRと同じ品質基準で確認するため
API連携ツールの集計条件	2026年7月16日前後で結果が変わる可能性があるため
PR作成者の社内定義	「人間が作成」「Copilotが作成」「人間が依頼」を区別するため

特に、GitHubのUIで見えるPR数と、社内ダッシュボードのPR数が一致しない場合は、API反映時期や検索条件の違いを疑いましょう。UI上ではすでにCopilot作成PRが含まれていても、API側の集計が同じ仕様になっていない期間があるためです。

まずやるべきこと

今回の変更を実務に取り入れるなら、最初に次の3つを行うのがおすすめです。

1つ目は、GitHubでis:pr is:open author:@meを検索し、自分が直接作成したPRとCopilotが開いたPRがどう表示されるかを確認することです。

2つ目は、チームでCopilot cloud agentが作成したPRのレビュー責任を決めることです。Copilotが作成したPRも、マージ前には必ず人間が差分、テスト、影響範囲を確認する運用にしましょう。

3つ目は、社内ツールやレポートでPull Requestを集計している場合、2026年7月16日前後でAPI結果が変わる可能性を考慮し、検索条件と集計定義を見直すことです。

Copilot-authored pull requests now included in author searchesは、派手な新機能というより、Copilot時代のPR管理を現実に合わせるための変更です。author:@meを「自分が直接作ったPR」ではなく、「自分が責任を持って確認すべきPR」を見る検索として使うと、レビュー漏れや集計ミスを減らせます。