WordPressの通知を「ベル1つ」にまとめる案、Feature Notificationsの設計が10月29日に公開
WordPressの開発コミュニティは2026年10月29日、管理画面の通知を統一する取り組み「Feature Notifications」の設計案を、Coreチームのブログ（Make WordPress Core）で公開しました。サイト、プラグイン、WordPress本体からの通知を1つのベルにまとめ、重要なものを目立たせる構想です。フィードバックの受け付けも始まっています。
ただし、投稿自体が「すぐではない」と述べているとおり、すぐに使えるようになる機能ではありません。0.3.0が機能プラグインとして先に出て、Coreへの統合はその後です。この記事では、設計案の中身と、プラグイン開発者・サイト運営者が今のうちに知っておくと役に立つ点を整理します。
解こうとしている問題は、管理画面の通知が埋もれること
投稿によると、WordPressにはサイトで起きていることをユーザーに伝える統一的な方法がありません。プラグインは管理画面の通知（admin notices）に頼っていて、その表示がページを押し下げます。決済の失敗、セキュリティ更新、チームメンバーからの質問のような重要な情報が、リマインダーやプロモーションに埋もれやすくなっています。
投稿者は、WooCommerceとWooPaymentsが現在表示しているメッセージを実際のプラグインとして検証し、その結果をもとに設計を考えたと書いています。
設計案の柱：ベル1つ、詳細表示、重要な問題の固定
- ベルは1つ：サイト、プラグイン、WordPress本体の通知を、1つのベルにまとめます。
- 詳細の見せ方：通知を開くと、対象（注文や投稿など）、送信元、明確な次の一手が表示されます。
- 重要な問題は上に固定：解決されるまで上部に残り、それ以外の通知は邪魔にならないようにします。
- 参考にしたもの：WordPress.comの通知パネルを参考にしています。
通知トレイは、管理画面のすべてのページ、エディター内、サイトのフロントエンドで使えるとされています。プラグインは、ページを押し下げる大きな通知に頼らずにメッセージを届けられるようになります。
第2版のルール：データだけを送り、見た目はCoreが決める
第1版（GitHub issue #655）に寄せられたフィードバックをもとに、第2版ではルールが整理されました。
- プラグインは、4つのレイアウト（Standard、Object、Conversation、Group）から1つを選び、その項目に値を入れる。レイアウトそのものは送らない。
- 通知は5つの独立した軸（種類、重大度、運用上の意図、既読状態、送信者のステータス）で表す。原文の表記は Type、severity、operational intent、read state、sender status。値はCoreが管理し、プラグインはその中から選ぶ。
- 重大度はcritical、warning、infoの3つだけで、「success」はない。良い知らせは「Won」のようにステータスで表す。
- criticalは稀で目立つ扱いにする。上部に固定され、既読にするだけでは解消されず、解決されるまでベルの件数が赤くなる。
- Alertsタブにcriticalとwarningを集める。
- 同じ通知は置き換え、多数の同種の通知は1つにまとめる。ヒントやオファーは一括で無効にできる。
- 表示の密度は、comfortableとcompactを切り替えられる。compactでは1行に1件で、一度に2倍の件数を見られる。
既存のadmin noticesは壊れない、ただし将来の方向ではない
プラグイン開発者にとって気になるのは、既存のコードが動かなくなるかどうかです。投稿は、これは破壊的変更ではないと書いています。既存のプラグインは動き続け、APIやフックも削除されません。管理画面の通知（カスタムのものを含む）も引き続き使えます。ただし、今後の通知の方向性ではないという位置づけです。
一方で、この取り組みは未完成で、すべてが0.3.0に含まれるわけでもないと、投稿は断っています。プラグインが新しい通知を採用できるのは、Coreに入った後だけです。移行はプラグインごとの判断になります。
決まっていない7つの論点
投稿は、フィードバックを求める未解決の課題を7つ挙げています。
- バッジを、種類ごとに用意するか、汎用的な数種類にまとめるか。
- 重大度は3つで足りるか、誰がcriticalを許可するか。
- 送信者（actor）と対象（about）の情報を、既存のmeta列に入れるか、正式なフィールドにするか。
- どのイベントをどの経路（ベル、管理メニューの件数、メール、プッシュ通知）で届けるか。各イベントが1回だけ届くようにする趣旨です。
- 未読タブを残すか、フィルターにするか。
- チャネルごと・プラグインごとの設定を、参加するプラグインが増えても管理しやすく保つ方法。
- キーボード操作がスクリーンリーダーなどで十分に機能するか。
フィードバックは、投稿のコメント、GitHubのissue #655、Slackの#feature-notificationsで受け付けています。締め切りは記載がなく、投稿は「時間はある」とだけ述べています。
実装の動き：通知をユーザー単位で扱う土台ができた
11月1日に公開された週次アップデートによると、2026年10月30日の週の主な変更は、通知リポジトリがユーザーごとのスコープになったことです（#626）。Notification_Repositoryのインターフェースが書き直され、すべての検索で user_id を受け取るようになりました。
find_by_user() と count_by_user() が追加され、ステータス、チャネル、期限、ページネーションなどで絞り込めます。従来の interface-notification.php は削除されました。REST API側では、一覧と合計件数（X-WP-Total）を返すための土台が整っています。この週のマージは、機能・ドキュメントが2件（#626、#648）で、依存パッケージの更新を含めると6件です。週次アップデートには、0.3.0のリリース時期は書かれていません。
今のうちにしておくこと：自分の通知の棚卸し
プラグインを作っている人は、自分のプラグインが出している通知を棚卸しするところから始められます。ページを押し下げる通知のうち、本当に重要なものと、プロモーションに近いものを分けておくと、将来の移行がやりやすくなります。サイト運営者は、今すぐ何かをする必要はありません。プラグインの通知が多すぎて重要なものを見落とした経験があるなら、その実例をコメントやGitHubのissueで伝えられます。
筆者の見方：criticalの線引きが仕組みの成否を左右する
設計案は重大度をcritical・warning・infoの3つに絞り、criticalを「稀で、解決するまで赤い件数が消えない」ものと定めています。一方で、誰がcriticalを許可するかは未解決の論点として残っており、プロモーションをcriticalにしないという点も、本文ではなくコメント欄での回答にとどまっています。筆者は、この許可の仕組みがルールとして本文に書き込まれるかどうかが、admin noticesの二の舞を避けられるかの分かれ目だと考えています。0.3.0の機能プラグインで、criticalの申請や審査がどう実装されるかに注目したいところです。
出典
- Make WordPress Core「Exploring a design for Feature Notifications」（2026年10月29日）
- Make WordPress Core「WP Feature Notifications weekly update: 2026-10-30」（2026年11月1日）
2026年11月2日時点の情報です。
コメント