Generated release notes credit you for Copilot pull requests は、Copilot cloud agent が作成した pull request をリリースノートに載せるとき、@copilot だけでなく、その作業を依頼した開発者もクレジット表示されるようになった変更です。つまり「CopilotがPRを作ったから、自分の貢献がリリースノート上で見えにくい」という問題を減らすための改善です。GitHub Changelog の該当ページは 2026年6月18日付で公開されており、日本時間では6月19日前後の公式情報として確認するケースがあります。なお、該当ページ上の分類表示は「Improvement」です。(The GitHub Blog)
この機能で迷いやすいのは、「どこでオンにするのか」ではありません。基本的には、Copilot cloud agent が作成した pull request がマージされ、その後 GitHub Releases の「Generate release notes」で自動生成リリースノートを作ったときに、表示内容が変わるという理解で十分です。リリース担当者がまず確認すべきなのは、Copilot cloud agent の利用可否、対象PRが前回リリース以降にマージされているか、そして .github/release.yml で除外設定をしていないかの3点です。
Generated release notes credit you for Copilot pull requests とは
Generated release notes credit you for Copilot pull requests は、GitHub の自動生成リリースノートにおける「誰のPRとして表示されるか」を改善する更新です。
GitHub の自動生成リリースノートは、リリース作成時にマージ済み pull request の一覧、共同作成者、完全な変更ログへのリンクなどを生成できます。これまでは Copilot cloud agent が開いたPRの場合、生成されたリリースノート上では @copilot の作業として見えやすい状態でした。今回の変更により、CopilotにPR作成を依頼した開発者も @copilot と並んで表示されます。(The GitHub Blog)
たとえば、以前は「機能追加 by @copilot」のように表示されていたものが、変更後は「機能追加 by @開発者名 with @copilot」という形で、人間の依頼者とCopilotの関与が分かる表示になります。これは、CopilotがPRを代理で作成しても、最終的な依頼・判断・レビューに関わった開発者の貢献をリリースノート上で示しやすくするための変更です。(The GitHub Blog)
まず押さえたい結論
| 迷うポイント | 答え | 実務での見方 |
|---|---|---|
| 設定をオンにする必要はあるか | リリースノート側のクレジット表示は、該当条件を満たすと反映される変更 | 「新しいボタンを探す」より、PR作成からリリース生成までの流れを確認する |
| どのPRが対象か | Copilot cloud agent が作成し、マージされた pull request | Copilot Chatの通常回答やIDE内補完だけでは対象にならない |
| 表示される場所はどこか | GitHub Releases の自動生成リリースノート | PR一覧画面やコミット履歴の作者表示そのものが変わる話ではない |
| すべてのGitHubユーザーが使えるのか | クレジット表示の改善はGitHub上の全リポジトリ・全プランで利用可能と案内されている | ただし、Copilot cloud agent自体を使うには対象プランや管理者設定の確認が必要 |
| うまく出ないときの確認先 | PRの作成経路、マージ状態、前回リリースとの差分、.github/release.yml | リリースノート生成前に対象PRと除外設定を確認する |
GitHub Changelog では、この変更は「GitHub上のすべてのリポジトリ、すべてのプランで利用可能」とされています。一方で、Copilot cloud agent はすべての有料 Copilot プランで利用でき、Business や Enterprise では管理者ポリシーの有効化が必要になる場合があります。ここを混同すると、「リリースノート機能はあるのに Copilot PR を作れない」という状態になりやすいです。(The GitHub Blog)
使い方の流れ
Generated release notes credit you for Copilot pull requests を利用する流れは、特別な新機能を起動するというより、Copilot cloud agent でPRを作成し、通常のリリース作業の中で自動生成リリースノートを使う流れです。
Copilotにpull requestを作成させる
Copilot cloud agent は、リポジトリの調査、実装計画の作成、コード変更、PR作成などをGitHub上で進められるエージェント機能です。GitHub.com のエージェント関連画面、ダッシュボード、Copilot Chat、Issue割り当てなどからタスクを開始できます。(GitHub Docs)
Copilot Chat から始める場合は、GitHub.com の Copilot Chat で /task を入力し、変更内容と pull request の作成を依頼します。必要に応じてベースブランチを選ぶと、Copilot はそのブランチをもとに新しいブランチを作り、変更をPRにプッシュします。(GitHub Docs)
依頼文は、単に「修正して」ではなく、目的・対象ファイル・期待する挙動・テスト条件まで書くと失敗しにくくなります。
/task Create a pull request to improve the error message shown when login fails.
Target the default branch.
Do not change the authentication logic.
Add or update tests if relevant.この段階で大切なのは、Copilotに「何を変えるか」だけでなく「何を変えないか」も伝えることです。認証、課金、権限管理、CI/CD設定などに関わる変更では、制約を書かないと意図しない範囲まで修正案が広がることがあります。
pull requestをレビューしてマージする
CopilotがPRを作成したら、人間の開発者が通常のPRと同じように差分を確認します。GitHub Docs でも、Copilot pull request は人間の投稿と同じように十分なレビューが必要だと説明されています。リポジトリで承認レビューが必須の場合、Copilotの承認は必要な承認数にカウントされず、別のレビュー担当者による承認が必要です。(GitHub Docs)
特に注意したいのは GitHub Actions です。CopilotがPRに変更をプッシュしても、既定ではGitHub Actionsワークフローは自動実行されません。ワークフローにはシークレットへアクセスできるものがあるため、.github/workflows/ 配下の変更を確認したうえで、必要に応じて「Approve and run workflows」を実行します。(GitHub Docs)
GitHub Releasesでリリースノートを生成する
PRをマージしたら、GitHubのリポジトリ画面から Releases に進み、新しいリリースを作成します。タグ、前回タグ、リリースタイトルを指定したうえで、説明欄の上にある「Generate release notes」をクリックします。生成後は、含めたい情報がすべて入り、不要な情報が混ざっていないか確認してから公開します。(GitHub Docs)
ここで、Copilot cloud agent が作成してマージ済みになっているPRが対象範囲に含まれていれば、リリースノート上で依頼した開発者と @copilot が並んで表示されます。リリースノートを生成した後にPRをマージした場合は、そのPRは生成済みのノートに自動で追加されないため、再生成または手動追記が必要です。
設定場所で迷いやすいポイント
クレジット表示そのものの設定画面は探さなくてよい
この変更は、リリースノート生成時の表示改善です。GitHub Changelog の内容を見る限り、「クレジット表示を有効にするための専用トグルをオンにする」というタイプの機能ではありません。確認すべきなのは、Copilot cloud agent が使える状態か、対象PRが正しくマージされているか、自動生成リリースノートの対象範囲に入っているかです。(The GitHub Blog)
「設定が見つからない」と感じたら、次の順で切り分けると早いです。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| Copilot cloud agent が使えるか | Copilot設定、組織・Enterpriseポリシー | Business / Enterprise では管理者が有効化しているか |
| 対象リポジトリで使えるか | Copilot cloud agent のリポジトリアクセス設定 | リポジトリが無効化・オプトアウトされていないか |
| PRが対象になるか | Pull requests、Releases | 前回タグ以降にマージされたPRか |
| リリースノートから除外されていないか | .github/release.yml | ラベル・author除外の設定に該当していないか |
| 表示を確認したか | リリース作成画面の生成結果 | 公開前に人名、PRタイトル、分類を目視確認したか |
Copilot cloud agentの利用可否を確認する
個人向けの有料 Copilot プランでは、Copilot cloud agent は既定で有効と説明されています。一方、GitHub Copilot Business または GitHub Copilot Enterprise では既定で無効で、管理者が有効化してから利用できるようになります。また、リポジトリ単位でオプトアウトされている場合も使えません。(GitHub Docs)
個人アカウント所有のリポジトリでは、GitHub右上のプロフィール画像から「Copilot settings」に入り、サイドバーの「クラウド エージェント」でリポジトリアクセスを確認できます。設定では「リポジトリなし」「すべてのリポジトリ」「選択したリポジトリのみ」を選べます。(GitHub Docs)
会社のリポジトリで使う場合は、自分の画面だけを見ても解決しないことがあります。組織またはEnterpriseの管理者が、Copilot cloud agent のポリシーを有効にしているか、対象リポジトリを許可しているかを確認してください。
自動生成リリースノートの設定は .github/release.yml
リリースノートの分類や除外条件を調整したい場合は、リポジトリ内に .github/release.yml を作成します。このファイルでは、pull request のラベルを使ったカテゴリ分けや、特定のラベル・ユーザー・ボットをリリースノートから除外する設定ができます。(GitHub Docs)
たとえば、次のように設定すると、機能追加・不具合修正・その他の変更に分けて表示できます。
# .github/release.yml
changelog:
exclude:
labels:
- ignore-for-release
categories:
- title: Features
labels:
- enhancement
- title: Fixes
labels:
- bug
- title: Other Changes
labels:
- "*"Copilot PRのクレジットが表示されない場合、release.yml で対象ラベルを除外していないか確認してください。特に changelog.exclude.authors やカテゴリごとの exclude.authors を使っているリポジトリでは、ボットや特定ユーザーのPRを意図せず除外している可能性があります。GitHub Docs では、リリースノートに表示しない pull request のラベルやユーザー、ボットのログインハンドルを指定できると説明されています。(GitHub Docs)
導入前に確認したい前提条件
Copilot PRを作る権限があるか
Copilot cloud agent は、すべての有料 Copilot プランで利用できると説明されています。ただし、Business / Enterprise 環境では組織やEnterpriseのポリシーに左右されます。PR作成を依頼できない場合は、ライセンスだけでなく、対象リポジトリでクラウドエージェントが許可されているかを確認してください。(GitHub Docs)
また、IssueをCopilotに割り当てる場合、リポジトリ選択にはアクセス権の条件があります。少なくとも読み取りアクセスがあるリポジトリは候補に出ますが、実際に選択できるのは、書き込みアクセスがあり、Copilot cloud agent が有効なリポジトリです。(GitHub Docs)
リリース運用でタグを使っているか
自動生成リリースノートは、リリース対象のタグと前回タグの差分をもとに内容を作ります。タグ運用が曖昧だと、対象PRが多すぎたり、逆に必要なPRが入らなかったりします。
実務では、次のようなルールを決めておくと安定します。
| 運用項目 | おすすめの決め方 |
|---|---|
| タグ名 | v1.4.0 のように一貫した形式にする |
| 前回タグ | リリース作成時に必ず確認する |
| Copilot PRのラベル | enhancement、bug、docs など既存カテゴリに合わせる |
| 除外ラベル | ignore-for-release など明確な名前にする |
| 公開前確認 | PRタイトル、クレジット、カテゴリ、不要な内部情報の有無を見る |
「Copilotが作ったPRだから自動でよし」と考えず、リリース作業では人間が最終確認する前提にしてください。リリースノートは利用者や顧客が読む情報なので、PRタイトルが内部向けすぎる場合は、公開前に自然な表現へ整えることも重要です。
GitHub Actionsとシークレットの扱いを確認する
Copilot PRでは、GitHub Actionsの実行が既定で自動実行されない点を理解しておく必要があります。これは不便に見える一方、シークレットにアクセスできるワークフローを不用意に実行しないための安全策です。.github/workflows/ の変更が含まれるPRでは、必ず差分を確認してからワークフロー実行を許可してください。(GitHub Docs)
リリース前のチェックリストには、次の項目を入れておくと安全です。
| チェック項目 | 確認内容 |
|---|---|
| ワークフロー変更 | .github/workflows/ に変更があるか |
| 権限変更 | permissions、トークン、シークレット参照が変わっていないか |
| テスト結果 | 必要なCIが実行済みか |
| レビュー | 人間のレビュー担当者が承認しているか |
| リリースノート | Copilot PRの内容が正しく説明されているか |
よくあるつまずきと対処法
リリースノートにCopilot PRが出てこない
まず、PRがマージ済みか、前回リリースタグ以降の変更かを確認します。自動生成リリースノートは、リリースに含まれるマージ済みPRをもとに生成されます。マージされていないPR、前回タグより前に入ったPR、別ブランチに入ったPRは想定通りに出ないことがあります。(GitHub Docs)
次に、.github/release.yml の除外条件を確認してください。ignore-for-release のような除外ラベルが付いている、または authors の除外に該当している場合、リリースノートに表示されない可能性があります。
自分の名前ではなくCopilotだけに見える
対象が「Copilot cloud agent が作成したPR」かを確認します。GitHub Copilot の補完やIDE内チャットで自分が手動作成したPRは、今回の変更の対象とは別物です。今回の改善は、Copilot cloud agent が代理で pull request を開いた場合のリリースノート上のクレジット表示に関するものです。(The GitHub Blog)
また、既に生成済みのリリースノートを見ている場合は、生成し直すか手動編集が必要になる場合があります。公開前に「Generate release notes」を押した直後の内容を確認し、期待する表示になっているか見てください。
どの画面からCopilot PRを作ればよいか分からない
初めてなら、IssueをCopilotに割り当てる方法が分かりやすいです。Issueの内容がそのまま作業指示になり、Copilotは作業を開始してPRを作成し、完了後にレビューを要求します。ただし、この機能はパブリックプレビューとして説明されており、挙動が変わる可能性があります。(GitHub Docs)
既存PRの修正を依頼したい場合は、PRコメントで @copilot をメンションします。Copilotが作成したPRだけでなく、自分や他のユーザーが作成したPRでも使えます。ただし、Copilotはリポジトリへの書き込みアクセス権を持つユーザーからのコメントにのみ応答します。(GitHub Docs)
チームで使うときの実務的なルール
Generated release notes credit you for Copilot pull requests は、単なる表示改善に見えますが、チーム運用では「AIに任せた作業の責任範囲」を見える化する意味があります。リリースノートに人間の依頼者が表示されることで、後から「誰がこの変更を進めたのか」「誰に仕様意図を確認すればよいのか」を追いやすくなります。
チームで導入するなら、次のルールを先に決めると混乱しません。
| ルール | 決める内容 |
|---|---|
| Copilotに任せる作業 | 小さな修正、テスト追加、ドキュメント更新などから始める |
| 任せない作業 | 認証、決済、権限、データ削除、リリース自動化など高リスク領域 |
| PRタイトル | リリースノートに出ても分かる表現にする |
| ラベル運用 | リリースノートのカテゴリと連動させる |
| 最終責任 | Copilotではなく、依頼者とレビュー担当者が持つ |
| 公開前確認 | リリース担当者がクレジットと内容を確認する |
特に重要なのは、Copilot PRのタイトルです。自動生成リリースノートはPR情報をもとに作られるため、PRタイトルが「fix」「update」「minor changes」のように曖昧だと、リリースノートも分かりにくくなります。CopilotにPR作成を依頼するときは、「ユーザー向けに意味が伝わるPRタイトルにして」と明示しておくと、後工程が楽になります。
こんな使い方がおすすめ
Copilot cloud agent と自動生成リリースノートの組み合わせは、次のような場面で効果を発揮します。
| 活用シーン | 使い方 |
|---|---|
| 小さな不具合修正が多いプロジェクト | IssueをCopilotに割り当て、PR化からリリースノート反映まで流れを揃える |
| ドキュメント更新を溜めがちなチーム | docs系ラベルを付け、リリースノートで変更内容を分けて表示する |
| OSSや社内ライブラリのメンテナンス | Copilot PRでも依頼者が見えるため、問い合わせ先を追いやすい |
| リリース担当が複数いるチーム | .github/release.yml で分類ルールを固定し、属人化を減らす |
一方で、大規模な仕様変更やセキュリティに関わる変更を、いきなりCopilotに丸投げするのはおすすめしません。最初は影響範囲が小さく、テストで正否を確認しやすいタスクから始める方が安全です。
まとめ：設定探しより「PRからリリースまでの流れ」を整える
Generated release notes credit you for Copilot pull requests は、Copilot cloud agent が作成した pull request をリリースノートに載せる際、依頼した開発者もクレジットされるようにする改善です。専用の設定画面を探すより、Copilot cloud agent が対象リポジトリで使えるか、PRがマージ済みか、自動生成リリースノートの対象範囲に含まれているかを確認するのが近道です。
導入時は、まず小さなIssueをCopilotに割り当ててPRを作らせ、レビュー・マージ・リリースノート生成まで一度試してください。そのうえで .github/release.yml の分類、除外ラベル、PRタイトルの付け方を整えると、Copilotを使った開発でも、誰が何を進めたのかがリリースノート上で分かりやすくなります。
コメント