GitHubのPRアーカイブ権限拡大:自動コメントを止める整理手順

Dev
閲覧数 3

triage担当者が管理者に依頼せずPRをアーカイブできるようになりました。整理前に、結果や進捗をまだ投稿しようとするボットの扱いを確認しましょう。

PR状態確認・レビュー根拠保存・アーカイブ後のコメント停止を示す概念図。製品画面ではありません。
PR状態確認・レビュー根拠保存・アーカイブ後のコメント停止を示す概念図。製品画面ではありません。

確認済みの変更範囲

GitHubは2026年10月8日にtriage以上でアーカイブと解除が可能になったと発表しました。アーカイブはPRを閉じ、コメント・リアクション・自動コメントを禁止します。10月9日の補足では公開表示から隠れ、triage・write・maintain・adminには見えるとされています。解除してもPRは再オープンされません。

投稿前に現在の状態を読む

運用提案として、対象がアーカイブ済みと確認できたジョブは終了し、理由を内部記録に残します。無条件の再送を避け、連携が実際に提供する状態と応答を確認してください。新しいAPIフィールドの存在を約束する説明ではありません。権限不足と通信障害も分けます。

整理前にレビュー根拠を残す

スパムや重複の整理と未決定の実装の保管は別です。理由、最後の検証、関連issue、基準PRを記録しましょう。外部読者が見られなくなる点を考慮し、必要な公開根拠を適切な場所に残します。非公開情報を公開する理由にはしません。

triageの委任とコード変更権限を分ける

日常の整理を委任できても対象基準は必要です。レビュー中や未回答の質問があるPRは人が判断します。解除後も閉じたままなので、開発再開なら再オープンの要否を別に確認してください。

実際の権限を確認し、適切な一件で自動コメントの終了処理を試しましょう。失敗だけを理由に代替PRを作らないでください。製品動作は確認済み、運用ルールは提案です。議論の規模や効果は推定していません。

公式情報と議論

GitHub Changelog

GitHub Community

アーカイブ基準とボット終了規則を一緒に見直してください。