PRの整理を任せたいとき、担当者にコードの書き込み権限まで渡すかどうかは、分けて考えたいところです。スパムなどへの対応を日常的に担う人がいても、アーカイブのたびに管理者へ引き継ぐ必要があれば、その部分で作業が止まります。

2026年10月8日のGitHubの更新は、この引き継ぎを減らすものです。Triage以上のロールへアーカイブ操作が広がったことで何を委任できるのか、そしてPRを元に戻すときに何が戻るのかを整理します。

Triageならコードの書き込み権限を付けずにPR整理を任せられる

Triageは、IssueやPRなどを管理する人向けのリポジトリロールです。Organizationのロール定義と権限表では、ラベルの適用やPRのクローズ・再オープンが可能な一方、コードのpushやPRのマージは許可されていません。

今回、従来は管理者に限られていたPRのアーカイブと解除を、Triage、Write、Maintain、Adminの各ロールで実行できるようになりました。整理担当者にTriageを割り当てているなら、この操作のためだけに上位ロールへ変更する必要がなくなります。

たとえば、スパムPRへの対応を整理担当者が判断し、アーカイブまで進める運用が考えられます。ただし、権限が増えたからといって、終了したPRをすべてアーカイブする必要はありません。次に見るように、アーカイブは公開状態と会話の可否にも作用するからです。

PRのアーカイブは通常の会話ロックより強く活動を止める

アーカイブされたPRは公開表示から外れ、管理者には引き続き表示されます。同時にPRはクローズされ、会話が読み取り専用になります。単にレビュー待ちの一覧から片付ける以上の操作ですね。

ここで、通常の会話ロックとの違いが効いてきます。会話ロックの仕様では、ロック中でもWrite権限のある人などはコメントできます。従来のPRアーカイブもロックを使っていましたが、管理者によるコメントは可能でした。

今回の変更では、アーカイブ中の新規コメント、リアクション、自動コメントがブロックされます。Triageに通常の会話ロックを操作する権限を与えずに、アーカイブしたPRの活動を止められる仕組みです。

このため、アーカイブ後にbotが処理結果を書き込む運用は見直す余地があります。説明をPRへ残す必要があるなら、アーカイブ前に記録する順序を検討できます。これは自動化の実装手順が新設されたという意味ではなく、コメントが停止する仕様から導ける運用上の判断です。

アーカイブ解除と再オープンを別の判断にする

アーカイブ解除ではコメントやリアクションが再び可能になりますが、PRは自動で再オープンされません。「会話を再開できる状態に戻すこと」と「変更提案をもう一度受け付けること」は、別の操作として扱います。

たとえば、アーカイブの判断を取り消して説明を追加したいだけなら、再オープンまで行う理由はありません。レビューを再開するなら、解除後にPRを開き直す判断が必要です。こうして目的から手順を分けると、解除しただけでレビュー待ちへ戻ったと思い込むのを避けられます。

管理者が見直したいのは、整理担当者へ渡す権限の大きさだけではありません。アーカイブする基準、処理理由を残すタイミング、解除後にレビューを再開するかどうかまで共有すれば、コード変更権限を増やさずに任せられる仕事を具体化できます。

出典

• Title: Triage role users or higher can now archive pull requests
• URL: https://github.blog/changelog/2026-10-08-triage-role-users-or-higher-can-now-archive-pull-requests