GitHubカスタムスレッド購読の廃止は一時停止|通知が増えたときの対処法

GitHub Notificationsの「カスタムスレッド購読が廃止され、通知が一気に増えるのではないか」と心配している場合、まず最新状況を確認しておきましょう。

GitHubは2026年8月10日にカスタムスレッド購読の廃止を発表しましたが、同年8月14日に計画を一時停止しました。 Customizeは復元され、Subscribedへ変換された既存のカスタム購読についても、以前の設定へ戻るはずだと案内されています。

そのため、2026年9月2日時点では、通知増加を避けるためにすべてのスレッドを慌ててUnsubscribeする必要はありません。ただし、重要なIssueやPull Requestについては、購読状態が意図どおり戻っているか確認するのが安全です。(The GitHub Blog)

目次

GitHubカスタムスレッド購読の廃止は一時停止されている

GitHubカスタムスレッド購読の廃止を巡る経緯は、次のとおりです。

日付発表内容利用者への影響
2026年8月10日カスタムスレッド購読の廃止を発表Customizeを削除し、既存設定をSubscribedへ変換する予定だった
2026年8月14日廃止計画を一時停止Customizeを復元し、変換済みの設定も以前の状態へ戻す方針
2026年9月2日時点機能を継続提供IssueやPull RequestでCustomizeを利用できる

当初の計画では、スレッド単位の通知設定からCustomizeを削除し、選択肢を次の2つに絞る予定でした。

  • Subscribed
  • Not subscribed

さらに、既存のカスタム購読はすべてSubscribedへ変換され、そのスレッド内の全イベントについて通知を受け取る仕様になると説明されていました。

しかし、高頻度で更新されるリポジトリの通知管理に欠かせないという利用者の意見を受け、GitHubは発表から4日後に計画を一時停止しました。現在は機能の価値や今後の通知設計を改めて検討している段階です。(The GitHub Blog)

なお、「一時停止」は永久的な廃止撤回を意味するものではありません。将来、別の形で通知機能が変更される可能性はあるため、GitHub Changelogの更新は引き続き確認する必要があります。

カスタムスレッド購読とは

カスタムスレッド購読は、個別のIssueやPull Requestについて、どのタイミングで通知を受け取るかを細かく指定する機能です。

対象のIssueまたはPull Requestを開き、右側のNotifications付近にあるCustomizeから設定します。Customを選択すると、マージ、クローズ、再オープンなど、通知を受け取りたいイベントを絞り込めます。(GitHub Docs)

たとえば、Pull Requestのレビュー中にすべてのコメントを追う必要はなく、最終的にマージされたかどうかだけ知りたい場合に役立ちます。

設定通知の受け取り方適したケース
Subscribedスレッドの更新を広く受け取る担当中のIssueや自分がレビューしているPull Request
Custom指定したイベントだけ受け取るマージ、クローズ、再オープンだけ確認したい
Unsubscribe通常の更新通知を停止する対応が完了し、継続的に追う必要がない

リポジトリ単位のCustom設定とは別の機能

GitHubには、リポジトリのWatchメニューにもCustomがあります。

こちらは、リポジトリ全体について通知対象を次のような種類から選ぶ機能です。

  • Issues
  • Pull requests
  • Releases
  • Discussions
  • Security alerts

今回、廃止対象として発表されたのは、個別のIssueやPull Requestに設定するスレッド単位のカスタム購読です。

リポジトリ単位のWatch設定とスレッド単位のCustomizeは、名前が似ていますが設定範囲が異なります。通知を見直す際は、どちらを変更しているのか確認してください。(GitHub Docs)

当初の廃止計画で通知が増えるとされた理由

当初の計画では、既存のカスタム購読がSubscribedへ自動変換される予定でした。

たとえば、次のような設定をしていたケースを考えます。

Pull Requestがマージまたはクローズされたときだけ通知を受け取る

これがSubscribedに変換されると、状態変更だけでなく、そのスレッドで発生する各種更新について通知を受け取る状態になります。

活発なPull Requestでは、コメント、レビュー、修正、状態変更などが短時間に繰り返されます。複数の高頻度リポジトリを扱っている開発者ほど、通知が急増する可能性がありました。

現在は廃止計画が一時停止されているため、この変換を前提に運用を変更する必要はありません。ただし、一時的な変換や設定復元の影響が疑われる場合は、重要なスレッドの設定を個別に確認しましょう。

GitHub通知が急に増えたときの対処法

通知が増えた場合、カスタムスレッド購読の廃止だけを原因と決めつけず、スレッド、リポジトリ、受信箱の順に確認すると効率的です。

個別スレッドの購読状態を確認する

通知が多いIssueまたはPull Requestを開き、右側のNotificationsを確認します。

必要なイベントだけ受け取りたい場合

  1. Customizeを選択する
  2. ダイアログでCustomを選択する
  3. 通知が必要なイベントを指定する
  4. Saveを選択する

マージ結果やクローズだけ確認したいスレッドでは、SubscribedのままにするよりもCustomが適しています。現在のGitHub公式ドキュメントでも、IssueやPull Requestの右側からCustomizeを選び、通知条件を指定する手順が案内されています。(GitHub Docs)

もう追う必要がない場合

対象スレッドでUnsubscribeを選択します。

ただし、購読解除後でも、次のような場合は再び通知されることがあります。

  • 自分のユーザー名がメンションされた
  • 所属チームがメンションされた
  • Pull Requestのレビューを依頼された
  • 自分が再びスレッドへ参加した

Unsubscribeは、そのスレッドから永久にすべての通知を遮断する機能ではありません。必要な依頼まで見逃しにくい仕組みになっています。(GitHub Docs)

Subscriptionsページで購読をまとめて確認する

どのスレッドを購読しているか分からない場合は、GitHub NotificationsのSubscriptionsページを利用します。

  1. GitHub右上の通知アイコンを開く
  2. Manage notificationsを選択する
  3. Subscriptionsを開く
  4. リポジトリや購読理由で絞り込む
  5. 不要なスレッドを選択してUnsubscribeする

購読一覧では、リポジトリや通知理由による絞り込みに加え、購読した時期で並べ替えられます。古い購読を探す場合は、購読日時が古い順に確認すると、忘れていたIssueやPull Requestを見つけやすくなります。(GitHub Docs)

ただし、一括解除する前に、担当中のIssueやレビュー待ちのPull Requestが含まれていないか確認してください。

リポジトリ全体のWatch設定を見直す

特定のスレッドではなく、同じリポジトリから大量の通知が届く場合は、リポジトリ単位のWatch設定が原因かもしれません。

Manage notificationsからWatched repositoriesを開き、各リポジトリの設定を確認します。

状況適した設定
リポジトリ内の全活動を追いたいAll Activity
IssueやReleaseなど一部だけ必要Custom
自分が参加・メンションされた場合だけ必要Participating and @mentions相当の状態
今後ほとんど関わらないUnwatch

リポジトリをUnwatchしても、自分が会話に参加した場合やメンションされた場合は通知対象になることがあります。すべてのリポジトリ更新を追う必要がない場合は、CustomまたはUnwatchへ変更すると通知量を減らせます。(GitHub Docs)

通知フィルターだけでは通知量そのものは減らない

GitHub Notificationsの受信箱には、通知を整理するためのカスタムフィルターがあります。

たとえば、次のような条件を利用できます。

reason:review-requested

自分または所属チームにレビュー依頼が届いた通知を表示します。

reason:mention

自分が直接メンションされた通知を表示します。

repo:owner/repository reason:participating

特定リポジトリのうち、自分が参加しているスレッドの通知を表示します。

そのほか、org:author:is:unreadなども利用できます。GitHubの受信箱には最大15件のカスタムフィルターを作成できます。(GitHub Docs)

ただし、受信箱のフィルターは届いた通知を見やすく分類する機能です。スレッドの購読やメール配信そのものを停止するわけではありません。

通知量を実際に減らすには、目的に応じて次の設定を使い分けます。

  • 個別スレッドの通知を減らす:CustomizeまたはUnsubscribe
  • リポジトリ全体の通知を減らす:Watch設定を変更
  • メール通知を減らす:GitHubの通知設定でメール配信先や対象を変更
  • 受信箱を整理する:カスタムフィルター、DoneSave

DoneとUnsubscribeを混同しない

GitHub Notificationsでは、DoneUnsubscribeの違いが重要です。

操作現在の通知今後の通知
Done受信箱から片付ける購読は継続する
Unsubscribe受信箱から削除する通常の更新通知も停止する
Save後で確認できるよう保存する購読状態は変更しない
Mark as read既読にする購読状態は変更しない

通知を読んだだけで今後も追いたい場合はDone、今後の通常更新が不要な場合はUnsubscribeを選びます。

通知を減らしたいのにDoneだけを使っていると、そのスレッドが更新されるたびに新しい通知が届きます。(GitHub Docs)

フィルター依存の運用を見直す方法

カスタムスレッド購読の廃止計画は一時停止されましたが、GitHubが通知機能の全体的な見直しを続けている点には注意が必要です。

将来の仕様変更に備えるなら、「すべて購読してフィルターで隠す」運用から、通知の重要度に応じて購読範囲を分ける運用へ移行するのが現実的です。

対応が必要な通知

次の通知は、専用フィルターを作って優先的に確認します。

reason:review-requested
reason:mention
reason:team-mention
reason:assign

レビュー依頼や担当割り当ては、他の通知に埋もれると開発を止める原因になります。

結果だけ確認したいスレッド

マージ、クローズ、再オープンなど、特定の状態変更だけ知りたい場合は、スレッド単位のCustomizeを利用します。

参考として参加したスレッド

継続的な対応が不要になった段階でUnsubscribeします。後から確認したい通知はSaveを使い、購読と保管を分けると受信箱を整理しやすくなります。

チームでルールを決める

チーム開発では、次のような基準を決めておくと通知設定が属人化しにくくなります。

通知の種類推奨する管理方法
レビュー依頼reason:review-requestedで優先表示
自分へのメンションreason:mentionで優先表示
担当Issuereason:assignで管理
状態変更だけ必要なPRスレッドのCustomize
対応終了済みのスレッドUnsubscribe
後で読み返す情報Save

GitHub公式ドキュメントでも、レビュー依頼、メンション、CI通知などを優先度別にフィルタリングし、不要な参加通知は解除する運用例が案内されています。(GitHub Docs)

既存のカスタム購読は確認しておくべきか

GitHubは、Subscribedへ変換されたカスタム購読について、以前の設定へ戻るはずだと説明しています。(The GitHub Blog)

ただし、業務上重要なスレッドについては、復元されたことを前提にせず、次の項目を確認しておくと安全です。

  • 重要なPull RequestがSubscribedのままになっていないか
  • Customizeで指定していたイベントが維持されているか
  • 不要なスレッドを大量に購読していないか
  • リポジトリ自体がAll Activityになっていないか
  • メールとGitHub受信箱の両方で通知を受け取っていないか

特に、通知が増えた時期が2026年8月10日から14日前後と重なる場合は、スレッド設定を優先して確認してください。

今後の廃止に備えて取るべき対応

2026年9月2日時点で、カスタムスレッド購読の廃止は実施されていません。Customizeも引き続き利用できます。

現時点で取るべき対応は、すべてのスレッドを一括で購読解除することではなく、次の3点です。

  1. 重要なIssueやPull RequestのCustomize設定を確認する
  2. SubscriptionsWatched repositoriesで不要な購読を整理する
  3. レビュー依頼やメンション用の受信箱フィルターを作成する

GitHubの通知が急に増えた場合も、まず個別スレッドの状態を確認し、必要なイベントだけならCustomize、不要ならUnsubscribeを選びます。

カスタム購読、リポジトリのWatch設定、受信箱フィルターを役割ごとに使い分けることで、今後GitHub Notificationsの仕様が変更されても、重要な通知を見逃しにくい運用を構築できます。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次