https://k1low.hatenablog.com/entry/2025/08/05/083000

テイラーでは開発にGitHubを使用しているのですが、それはもう毎日たくさんのPull Request / Issueが作られます。

RenovateなどのPull Requestの数も影響していますが、それを差し引いても構成人数比でいうと多い印象があります。

GitHub Notificationsの未読通知ベースの管理のツラミ

私はGitHub Notificationsの未読通知でPull Request / Issueを把握していて、確認したものから既読にしていく（つまり、確認するつもりで開く）運用をしていたのですが、この運用がうまくいっていない感覚がありました。

明らかに（もう）見なくてもいい未読通知が大量にある

マージやクローズの通知はもう終わったことなので、一旦は見なくて良いかなと思うのですが（プロダクトの変遷を追うという意味では重要な情報ではあるのですが、それは別のフェーズで実施できるという判断です）、未読のNotificationsを使っていると「既読」にしないと一覧が何も消化されないので、都度ポチポチ対応していました。

他のメンバーがレビュアーにアサインされているものも確認の優先度を低くしているのですが、それも「既読」にしていかないと見た目上は消化されません。

この「ポチポチ」が面倒です。

今すぐ自分がみるべき未読通知が埋もれる

今すぐ自分がみるべき未読通知、例えば私がレビュアーにアサインされているPull Requestです。

できる限り早めにレビューに取り掛かることでチームメンバーのブロック時間を減らせます。

ただ、それがどれかはGitHub NotificationsのWeb UI上からは初見では分かりません（フィルタリングが必要）

優先して確認したい。Slackでメンションされる前に取り掛かりたい。

また、CIがPASSしたタイミングでレビューしたい。

でもそれもWeb UI上ではリンクを開かないと分かりません。

Viewing and triaging notifications

GitHub Docsには「Viewing and triaging notifications（通知の表示とトリアージ）」というページがあります。

docs.github.com

うまく優先度をつけたり、チェックボックスを使って複数の通知に一括対応したり、カスタムフィルタ機能を使ってうまく絞り込んで確認したりして対応していきましょうという内容で、とても有用です。

gh-triage

上記のトリアージをさらに便利に実施するツールとして gh-triage を作成しました。これは GitHub CLIのエクステンションとして機能します。

github.com

gh-triage は未読通知に対して5つのアクションを取ることができます。

Done: 完了とする
Read: 既読にする
Unsubscribe: サブスクライブを解除する
Open: ブラウザで開く
List: CLI出力として一覧表示する

それぞれに条件 (if)と上限 (max)を設定することができます。

gh-triage は以下のようにGitHub CLIのサブコマンドとして実行します。

$ gh triage

上記コマンドで、GitHub Notificationsに未読通知としてリストアップされている各Pull RequestまたはIssue（またはRelease）について、条件 (if)に合致したら上限 (max)まで各アクションを実行します。

例えば、私の設定は次のような感じです。

# cat ~/.local/share/gh-triage/default.yml
done:
  max: 1000
  conditions:
  - merged
  - is_issue && closed
  - closed && author contains '[bot]'
read:
  max: 1000
  conditions:
  - is_release
  - author contains '[bot]' && me not in reviewers
  - is_pull_request && me not in reviewers && approved
open:
  max: 1
  conditions:
  - "is_pull_request && me in reviewers && passed && !approved && open && !draft"
  - is_pull_request && author == me
list:
  max: 1000
  conditions:
  - unread

意図としては次のようになります。

マージされたもの、IssueでCloseされたもの、botが作成したものでCloseされたものは全て完了とします。
リリースやbotが作成したPull Requestで私がレビュアーにアサインされていないもの、既にApproveされているものは全て既読にします。
私がレビュアーとしてアサインされているPull RequestでまだApproveされていないのでCIがPASSしていてドラフト状態でないものはブラウザで1件だけ開きます。つまり、レビューが必要なPull Requestを1つ確認します。あと、自分のPull Requestに何か変化があれば通知があるのでそれもブラウザで開く対象にします。
その他上記のアクションを経て、未読状態のものは全て一覧表示します。

これで gh triage を実行するたびに、多くの未読通知を自動で消化しつつ、確認すべきPull Requestを1件づつブラウザで確認できます。

また、一覧表示もWeb UI以上の情報を持っています。

なんとステータスも⚫︎の色（よく見る緑黄赤）で判定できます。

最近の私のGitHub Notificationsの運用

自分のタスクに集中して作業した後、落ち着いたときに gh triage を実行して、自動で選択されブラウザに開いたPull Requestをレビューしています。

余裕があればブラウザ表示がなくなるまでgh triage を実行して確認します。さらに余裕がある場合は一覧表示がなくなるまでクリックして確認します（一覧表示はクリックできるようにしています）。

これで、「確認しなければならない未読通知が多い」「確認しなければならないPull Requestがあるかもしれない」というストレスがほとんどなくなりました。

皆さんもよろしければ是非使ってみてください。

能動的に未読通知を減らしつつ、確実にレビューすべきPull Requestを見ていけるのは我ながら楽です。

インストールや設定についての詳しくは READMEをご覧ください。

では、快適なGitHub Notificationsライフを！