Generated release notes credit you for Copilot pull requestsとは？対象者と表示されない時の確認ポイント

GitHub Copilotで作成されたプルリクエストがリリースノートに載るとき、「誰の作業として表示されるのか」「自分の名前は出るのか」と気になった人向けの更新です。結論から言うと、Copilot cloud agentが開いたプルリクエストでも、それを依頼した開発者が@copilotと並んでリリースノート上でクレジットされるようになりました。これにより、Copilotに作業を代行させた場合でも、リリース履歴上で人間の開発者の貢献が見えやすくなります。GitHub Changelogの当該更新は2026年6月18日付で公開されており、すべてのGitHubリポジトリとすべてのプランで利用可能と案内されています。(The GitHub Blog)

この記事では、「Generated release notes credit you for Copilot pull requests」とは何か、誰が対象になるのか、表示されないときにどこを確認すべきかを、Q&A形式で実務目線に整理します。

Generated release notes credit you for Copilot pull requests とは何ですか？

「Generated release notes credit you for Copilot pull requests」は、GitHubの自動生成リリースノートに関するCopilot関連の更新です。

GitHubではリリースを作成するときに、前回リリース以降にマージされたプルリクエストをもとにリリースノートを自動生成できます。今回の変更により、Copilot cloud agentが開いたプルリクエストがマージされた場合、そのPRをCopilotに依頼した開発者もリリースノート上でクレジットされるようになりました。(The GitHub Blog)

GitHub Changelogでは、表示例として次のような違いが示されています。

状態	リリースノート上の表示イメージ
変更前	`Add create_feature_flag MCP tool by @copilot`
変更後	`Add create_feature_flag MCP tool by @monalisa with @copilot`

ポイントは、単に@copilotだけが表示されるのではなく、Copilotに作業を依頼した開発者のアカウントも併記されることです。

何が変わったのですか？

大きく変わったのは、リリースノート上の「貢献者の見え方」です。

これまでは、Copilot cloud agentが作成したプルリクエストがリリースノートに含まれる場合、表示上は@copilotの作業に見えやすい状態でした。今回の更新後は、CopilotにPR作成を依頼した開発者が@copilotと一緒に表示されます。

つまり、Copilotを使ってPR作成を自動化しても、リリースノート上では次のように整理されます。

観点	変更前	変更後
PR作成者の見え方	Copilot中心に見える	依頼した開発者とCopilotの共同作業として見える
人間の貢献の可視化	分かりにくい場合がある	分かりやすくなる
リリースノート確認時の印象	「botが作った変更」に見えやすい	「開発者がCopilotを使って進めた変更」と分かる
チームでのレビュー	担当者の把握にひと手間かかる	担当者を追いやすい

実務では、これは小さな表示変更に見えて、意外と重要です。リリースノートは社内共有、監査、顧客向け告知、障害時の変更追跡に使われることがあるため、「誰がCopilotに作業を依頼したのか」が見えることは、責任の所在や確認先を明確にする助けになります。

対象になる人は誰ですか？

対象になるのは、主にGitHub Copilot cloud agentを使ってプルリクエスト作成を依頼する開発者、リリース担当者、リポジトリ管理者です。

対象者	関係する理由
Copilot cloud agentでPRを作る開発者	自分のGitHubアカウントがリリースノートに表示される可能性がある
リリース担当者	自動生成リリースノートで、Copilot由来のPRの担当者を確認しやすくなる
リポジトリ管理者	リリースノートの見え方や貢献者表示のルールを把握しておく必要がある
開発マネージャー	Copilot活用時の作業実績や担当者を追いやすくなる
OSSメンテナー	外部公開されるリリースノートで、表示名の見え方を確認しておきたい

一方で、通常の手動PRだけを使っている人には、直接の影響は限定的です。今回の更新は、あくまでCopilot cloud agentが開いたプルリクエストがリリースノートに含まれる場面に関係します。

すべてのGitHubプランで使えますか？

GitHub Changelogでは、この機能はすべてのGitHubリポジトリとすべてのプランで利用可能と説明されています。(The GitHub Blog)

ただし、実際に恩恵を受けるには、次の条件がそろっている必要があります。

確認項目	内容
自動生成リリースノートを使っている	手動でリリースノートを書いているだけでは、この表示変更は関係しにくい
Copilot cloud agentがPRを開いている	通常の手動PRや別botのPRでは対象外
そのPRがマージされている	自動生成リリースノートは、前回リリース以降にマージされたPRをもとに生成される
リリース作成時に対象範囲へ含まれている	タグや前回リリースの指定によって、含まれるPRが変わることがある
除外設定に引っかかっていない	`.github/release.yml`で特定のラベルや作者を除外している場合は表示されないことがある

「すべてのプランで利用可能」と聞くと、何もしなくても必ず表示されるように感じるかもしれません。しかし実際には、対象PRがリリースノート生成の範囲に入っているかどうかが重要です。

自動生成リリースノートとは何ですか？

自動生成リリースノートは、GitHubのリリース作成時に、マージ済みプルリクエスト、リリースへの貢献者、フルチェンジログへのリンクなどを自動でまとめる機能です。GitHub Docsでは、リポジトリへのwrite権限を持つ人やコラボレーターが、自動生成リリースノートを生成・カスタマイズできると説明されています。(GitHub Docs)

一般的な流れは次のとおりです。

手順	作業内容
1	GitHubで対象リポジトリを開く
2	Releasesを開く
3	Draft a new releaseを選ぶ
4	タグを選択、または新しいタグを作成する
5	必要に応じてPrevious tagを指定する
6	Release titleを入力する
7	Generate release notesを実行する
8	生成内容を確認し、必要に応じて編集する
9	Publish releaseまたはSave draftを選ぶ

重要なのは、生成されたリリースノートをそのまま公開せず、必ず人間が確認することです。Copilot関連のPRに限らず、リリースノートには外部に出したくない内部向けのPRタイトルや、ユーザーに伝わりにくい技術的な表現が含まれることがあります。

どんな場面で役立ちますか？

この更新が特に役立つのは、Copilotを開発フローに組み込んでいるチームです。

たとえば、以下のような場面で効果があります。

活用シーン	役立つ理由
リリース前レビュー	Copilotが作ったPRでも、依頼した担当者を確認しやすい
社内向けリリース報告	「誰が関わった変更か」を共有しやすい
障害調査	変更に関与した人をたどりやすい
OSSプロジェクトの公開リリース	botだけでなく人間の貢献も見えやすい
Copilot活用状況の把握	AIエージェントを使った作業の流れを説明しやすい

特にチーム開発では、「Copilotがやったから分からない」ではなく、「誰がCopilotに依頼し、誰がレビューし、どのPRがマージされたか」を追える状態にしておくことが大切です。

今回の変更は、AIエージェントの作業を人間の開発プロセスに自然に結びつけるための改善といえます。

表示されるのはコミット作者ですか？PRの依頼者ですか？

今回の更新でリリースノートにクレジットされるのは、GitHub Changelogの説明に基づくと、Copilot cloud agentにプルリクエストを開くよう依頼した開発者です。(The GitHub Blog)

そのため、単純にコミット作者だけを見て判断するものではありません。

混同しやすいポイントを整理すると、次のようになります。

項目	意味
PR作成者	プルリクエストを開いたアカウント。今回の文脈では`@copilot`になることがある
Copilotに依頼した開発者	Copilot cloud agentにPR作成を指示した人。今回の更新でクレジットされる対象
コミット作者	Gitのコミット上のauthor情報。リリースノート上の表示と必ず一致するとは限らない
レビュアー	PRをレビューした人。今回のクレジット表示とは別の概念
マージした人	PRをマージした人。これも依頼者やPR作成者とは別の場合がある

実務では、「リリースノートに名前が出る人」と「コードを最終的に承認した人」は別になることがあります。責任範囲を明確にしたいチームでは、PRテンプレートやレビュー運用で担当者、レビュアー、マージ担当を明記しておくと安全です。

自分の名前がリリースノートに表示されないときの確認ポイント

自分がCopilotにPR作成を依頼したはずなのに、Generated release notesで名前が表示されない場合は、次の順番で確認すると原因を切り分けやすくなります。

確認ポイント	見るべき内容
Copilot cloud agentが開いたPRか	通常のCopilot補完や手動PRではなく、Copilot cloud agentがPRを作成したものか
PRがマージ済みか	オープン中、クローズのみ、未マージのPRはリリースノートに含まれない可能性が高い
前回リリース以降のPRか	Previous tagの指定によって対象範囲から外れていないか
対象ブランチが合っているか	リリース対象ブランチとPRのマージ先が一致しているか
`.github/release.yml`の除外設定	作者、bot、ラベル、カテゴリ設定で除外されていないか
PRタイトルが変更されていないか	表示名ではなくPR行自体を見落としていないか
リリースノートを再生成したか	古い下書きのまま確認していないか

特に見落としやすいのは、Previous tagの指定と除外設定です。GitHubの自動生成リリースノートは、リリース間の差分をもとに内容を作るため、前回タグの指定が想定と違うと、対象PRが含まれません。

また、.github/release.ymlでchangelog.exclude.authorsやchangelog.exclude.labelsを使っている場合、特定の作者やラベル付きPRがリリースノートから除外されることがあります。GitHub Docsでは、ラベルや作者をもとにリリースノートへの表示・除外・カテゴリ分けを設定できると説明されています。(GitHub Docs)

Copilot PRがリリースノートに出ないときの実務的な切り分け手順

表示されない原因を調べるときは、いきなり設定ファイルを疑うより、PRの状態から順番に確認するのがおすすめです。

まず対象PRを確認する

対象のプルリクエストを開き、次の点を確認します。

PRがマージされているか
マージ先ブランチがリリース対象と合っているか
PRが前回リリースタグ以降にマージされているか
Copilot cloud agentが開いたPRであることが分かるか
PRを依頼したGitHubアカウントが想定どおりか

ここで対象外だと分かれば、リリースノート側を調べる必要はありません。

次にリリース作成画面を確認する

リリース作成画面では、タグとPrevious tagを確認します。

たとえば、v1.2.0のリリースを作るときにPrevious tagがv1.0.0になっていると、v1.1.0以降の変更がまとめて入る可能性があります。逆にPrevious tagが新しすぎると、入るはずのPRが抜けることがあります。

「リリースノートに出ない」と感じたときは、PRそのものよりも、リリース対象の差分範囲が違っているケースが少なくありません。

最後にrelease.ymlを確認する

.github/release.ymlを使っているリポジトリでは、除外ルールやカテゴリ分けを確認します。

例として、次のような設定がある場合、特定のラベルが付いたPRはリリースノートから外れる可能性があります。

changelog:
  exclude:
    labels:
      - ignore-for-release

また、作者を除外する設定が入っている場合もあります。

changelog:
  exclude:
    authors:
      - example-user

Copilot関連のPRをリリースノートに含めたい場合は、PRに付いているラベルや作者除外設定が意図したものになっているか確認しましょう。

この機能はCopilotの利用実績を証明するものですか？

リリースノート上で開発者名と@copilotが並んで表示されるため、Copilotを使った作業であることは分かりやすくなります。ただし、これだけで個人の評価や作業量を正確に測れるわけではありません。

リリースノートは、あくまでリリースに含まれる変更の一覧です。次のような情報までは、リリースノートだけでは判断できません。

リリースノートだけでは分かりにくいこと	理由
実際にどれだけ人間が修正したか	Copilot作成後に手動修正されることがある
誰がレビューで品質を担保したか	レビュアー情報は別途PR上で確認する必要がある
作業にかかった時間	リリースノートには工数情報がない
変更の難易度	PRタイトルだけでは技術的な難しさを判断しにくい
セキュリティ上の妥当性	コードレビューやテスト結果を確認する必要がある

そのため、チームでCopilot活用を評価したい場合は、リリースノートだけでなく、PRレビュー、テスト結果、Issueとの紐付け、Copilot利用ポリシーを合わせて確認するのが現実的です。

チーム運用で注意すべきこと

Generated release notesでCopilot PRのクレジットが見えやすくなる一方で、チーム運用ではいくつか注意点があります。

注意点	実務での対応
PRタイトルがそのまま外部公開されることがある	ユーザー向けに分かる表現へ直す
Copilotが作った変更でも人間の確認は必要	レビュー必須ルールやブランチ保護を維持する
クレジット表示を評価に直結させない	表示名だけで作業量や品質を判断しない
bot除外設定で意図せず消えることがある	release.ymlの除外ルールを定期的に確認する
社外公開リポジトリでは名前の出方に注意	公開前にリリースノートの表示を確認する

特に社外向けのリリースでは、「内部チケット番号」「実験的な機能名」「顧客名」「脆弱性に関する詳細」などがPRタイトルに含まれていないか確認してください。自動生成は便利ですが、公開前の編集工程は省略しないほうが安全です。

release.ymlでリリースノートを整えるときの考え方

Copilot PRが増えてくると、自動生成リリースノートの見やすさが重要になります。単にすべてのPRを並べるだけでは、ユーザーにとって読みづらくなることがあります。

GitHub Docsでは、.github/release.ymlを使って、ラベルによるカテゴリ分け、特定ラベルの除外、特定作者の除外などを設定できると説明されています。(GitHub Docs)

実務では、次のような分類にしておくと読みやすくなります。

カテゴリ例	含めるPRの例
New features	新機能、機能追加
Improvements	既存機能の改善、UI改善
Bug fixes	不具合修正
Security	セキュリティ関連の修正
Documentation	ドキュメント更新
Dependencies	依存関係の更新

Copilotが作成したPRも、内容に応じて通常のPRと同じカテゴリに入れるのが自然です。Copilot changesのようにAI作成分だけを分ける方法もありますが、ユーザー目線では「誰が作ったか」よりも「何が変わったか」のほうが重要な場合が多いためです。

よくある疑問

Generated release notes credit you for Copilot pull requests は手動設定が必要ですか？

GitHub Changelogでは、今回の変更はすべてのリポジトリとすべてのプランで利用可能とされています。(The GitHub Blog)

そのため、基本的には個別に有効化するタイプの設定というより、GitHub側のリリースノート生成時の表示改善として捉えるとよいでしょう。ただし、対象PRがリリースノートに含まれる条件を満たしている必要があります。

Copilot Chatで作ったコードも対象ですか？

今回の説明で対象として示されているのは、Copilot cloud agentが作成したプルリクエストです。単にCopilot ChatやIDE上の補完を使って人間が手動でPRを作成した場合は、通常のPRとして扱われると考えるのが自然です。

Dependabotや他のbotのPRにも同じ表示がされますか？

今回の更新は、Copilot cloud agentで作成されたプルリクエストに関するものです。Dependabotや他のbotによるPRに、同じ「依頼者 + bot」の表示がされるとは限りません。

自分のユーザー名を出したくない場合はどうすればよいですか？

公開リポジトリでは、リリースノートにGitHubアカウント名が表示される可能性があります。表示を避けたい場合は、リリース公開前に生成されたリリースノートを編集する、対象PRをリリースノートから除外する、プロジェクトの公開運用ルールを見直す、といった対応を検討します。

ただし、貢献者表示はプロジェクトの透明性にも関わります。単に名前を消すのではなく、公開範囲、組織ルール、OSS運用方針に沿って判断しましょう。

リリースノートを生成し直せば表示は変わりますか？

下書き状態のリリースノートが古い内容のままなら、再生成や手動編集で表示が変わる可能性があります。ただし、すでに公開済みのリリースについては、編集権限を持つ人が内容を更新する必要があります。

Copilotが作ったPRでもレビューは必要ですか？

必要です。Copilot cloud agentがPRを作成しても、コード品質、仕様との整合性、セキュリティ、テスト結果は人間が確認すべきです。

リリースノートに自分の名前が出るということは、外部から見たときに「その変更に関わった人」と認識されやすくなるということでもあります。Copilotに作業を任せる場合でも、レビューと検証の責任まで自動化されるわけではありません。

導入前にチームで決めておきたいルール

Copilot cloud agentを使うチームでは、リリースノートの表示変更をきっかけに、次のルールを整えておくと運用が安定します。

決めること	例
Copilotに任せてよい作業範囲	小規模修正、テスト追加、リファクタリング補助など
PRタイトルの付け方	ユーザーに伝わる表現にする、内部略語を避ける
レビュー必須条件	Copilot作成PRも通常PRと同じレビューを必須にする
リリースノート除外ラベル	`ignore-for-release`などを明確に運用する
公開前チェック	担当者、PR内容、ラベル、機密情報の有無を確認する
貢献者表示の扱い	評価指標ではなく、変更追跡の補助として扱う

この更新は便利ですが、リリース運用を自動化しすぎると、ユーザーに不要な情報まで公開してしまうことがあります。Copilotの利用が増えるほど、「AIが作ったPRをどう人間のプロセスに組み込むか」が重要になります。

まず何を確認すべきか

Generated release notes credit you for Copilot pull requestsは、Copilot cloud agentで作成されたPRについて、リリースノート上で依頼した開発者を@copilotと一緒に表示するための更新です。リリースノートに人間の貢献が残りやすくなるため、Copilotをチーム開発で使っている場合は押さえておきたい変更です。

まずは、次の順番で確認しましょう。

Copilot cloud agentで作成されたPRがあるか確認する
そのPRがマージ済みで、次回リリースの対象範囲に入っているか確認する
GitHubの自動生成リリースノートを使って表示を確認する
.github/release.ymlの除外設定やカテゴリ設定を見直す
公開前にPRタイトル、担当者表示、機密情報の有無を確認する

CopilotによるPR作成は、開発作業を速くする一方で、履歴や責任範囲の見え方を曖昧にしがちです。今回の更新を活用すれば、AIエージェントを使った作業でも、誰が依頼し、どの変更がリリースに含まれたのかを追いやすくなります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。