GitHubは2026年10月8日、コードの変更を提案するPR(プルリクエスト)のアーカイブ権限を広げたと発表しました。管理者だけでなく、リポジトリのtriage以上の権限を持つ担当者も、PRをアーカイブしたり解除したりできるようになりました。一方、アーカイブ中のPRには、管理者もコメントできなくなります。
管理者への整理依頼を減らせる変更
対象は、コードなどを管理するリポジトリのtriage・write・maintain・adminロールです。ロールは、そのリポジトリで操作できる範囲を決める権限区分です。
従来、PRをアーカイブできるのはリポジトリ管理者だけでした。triage担当者は整理作業を管理者に依頼する必要がありました。今回の変更では、対象ロールの担当者がアーカイブと解除を行えます。
GitHubは、アーカイブの用途としてスパム、重複、放置されたPRの整理を挙げています。こうしたPRの整理を別の担当者に任せている会社では、管理者を経由する手順を見直す材料になります。ただし、権限があることと、社内で整理を任せることは別です。どのPRを誰の判断でアーカイブするかは、社内の手順として確認が必要です。
日本での提供は発表には書かれていません。対象プランや製品の版についても、発表には書かれていません。
アーカイブは「閉じる」だけではない
PRをアーカイブすると、自動でクローズされ、会話は読み取り専用になります。新規コメントだけでなく、自動コメントや新たなリアクションも拒否されます。従来は管理者がアーカイブ後もコメントできましたが、今回、その操作も禁止されました。
また、アーカイブしたPRは一般公開されず、リポジトリ管理者には見えるとされています。整理対象を選ぶ際は、会話を止めることに加え、公開状態が変わることも判断材料にしてください。
アーカイブを解除すると、コメントとリアクションは再び可能になります。ただし、PR自体は再オープンされません。「会話を再開すること」と「PRを再オープンすること」を分けて扱う必要があります。
影響する会社・しない会社
- 影響する: triage・write・maintainロールの担当者がPRを整理する会社です。管理者への依頼を前提にした役割分担を見直す余地があります。
- 影響する: adminロールの管理者が、アーカイブ後にコメントを追記していた会社です。今後は管理者もコメントできません。
- 影響する: PRへの自動コメントを使っている会社です。アーカイブ中のPRには自動コメントも拒否されるため、対象に含まれるPRの扱いを確認する必要があります。
- 影響しない: GitHubのPRを利用していない会社には、このPR操作の変更による直接の影響はありません。
- 影響しない: 対象外となるプラン・版・地域の条件は、発表には書かれていません。契約名や利用地域だけで対象外とは判断できません。
情シスが今日やること
以下は、今回の変更を受けた確認手順の提案です。発表に対応期限は示されていません。
- 今日、リポジトリ管理者に、PR整理担当者が持つロールの確認を依頼します。triage・write・maintain・adminのどれかを整理し、現在の社内手順で管理者への依頼が必須になっていないか照合してください。権限確認画面の名称や操作経路は、発表には書かれていません。
- 次の整理作業までに、担当者と対象PRの会話を確認します。スパム・重複・放置のどれに該当するか、判断理由を記録する必要があるかを決めます。記録が必要なら、コメントできるアーカイブ前に済ませる手順にしてください。
- 自動コメントを運用する開発担当者へ、アーカイブ中は投稿が拒否されることを知らせます。アーカイブ済みPRも投稿先に含めているかを確認し、社内の運用手順を見直してください。
- 整理担当者と管理者に、解除後もPRはクローズのままであることを共有します。作業を再開したい場合は、解除後にPRの状態を確認する手順を加えます。解除だけで再オープンしたと判断しないよう、引き継ぎにも明記してください。
