アプリ内で発生した通知（コメント・メンション・システム更新など）を一覧し、確認・管理するUIコンポーネント。Toastが「その場で一時表示する通知」、Alertが「現在の状態を示す常時表示の通知」であるのに対し、Notification Centerは過去の通知を蓄積して後から振り返れるアーカイブ的な通知ハブ。ベルアイコン + 未読バッジ + ドロップダウンまたは専用ページで構成される。
この記事を読むと、Toast・Alert との3者の使い分け・未読バッジの設計・既読/未読管理・通知のグループ化（今日/今週/それ以前）・通知設定への導線が自分でできるようになります。
1. UI例（Preview / Live）
実装で見る（GunjoUI）
この部品を、デザインシステム GUNJO の実装で確かめられます。
2. 定義（Definition）
アプリ内で発生した通知を蓄積・一覧・管理するUIコンポーネント。通常はナビゲーションバーのベルアイコン + 未読バッジで存在を示し、クリックでドロップダウンパネルまたは専用ページを表示する。
Toast / Alert / Notification Center の3者の関係：
| タイミング | 消去 | 履歴 | |
|---|---|---|---|
| Toast | 操作直後に即時表示 | 自動消去（数秒） | なし |
| Alert | 状態変化時にインライン表示 | 手動または状態解消 | なし |
| Notification Center | 後から振り返れる通知ハブ | 手動削除または自動整理 | あり |
3. 使い分け（When to use / When NOT to use）
3.1 When to use
- 他ユーザーのアクション通知（メンション・コメント・いいね・フォロー）
- システム通知（メンテナンス予告・サービス更新・セキュリティ警告）
- タスク完了通知（レポート生成完了・ファイル処理完了など非同期処理）
- 後から振り返る必要がある通知全般
3.2 When NOT to use
- 即時確認が必要なエラー → Alert を使う
- 軽微な操作成功（コピー・保存） → Toast を使う
- 通知が1種類しかない小規模アプリ → Toast + Alert で十分
3.3 代替UI（Alternatives）
- 即時フィードバック →
Toast - 現在の状態の警告・エラー →
Alert - 重要な確認が必要な通知 →
Modal Dialog
4. 設計判断の核（Decision Principles）
Notification Centerの核は「通知の重要度の可視化」と「一括処理のしやすさ」——未読が溜まると通知疲れ（notification fatigue）が起きる。通知の種類を絞り、まとめて処理できる手段を提供することが重要。
判断の優先順位：① 未読バッジの上限表示 → ② グループ化（時系列） → ③ 一括既読 → ④ 通知設定への導線
- 未読バッジは 9+ または 99+ で上限を設ける：未読が100件を超えても正確な数字を表示するよりも「9+」で止めた方がプレッシャーを与えすぎない。バッジの目的は「未確認の通知がある」と知らせることであり、正確な数ではない
- グループ化（今日 / 今週 / それ以前）で時系列を整理する：時間でグループ化することで「今日の通知をまず見る」という行動を支援する。アプリの性質によっては「メンション / コメント / システム」などタイプ別グループ化も有効
- 「すべて既読」ボタンを必ず提供する：1件ずつ処理するしか手段がないと、未読が多い時に諦めてNotification Centerを使わなくなる
- フッターに「通知設定」への導線を置く：通知が多すぎると感じたユーザーが通知をオフにできる設定への導線を提供する（通知疲れの防止）
5. 状態設計（States）
5.1 必須状態（Required）
- 有通知（未読あり）：ベルアイコン + 未読バッジ
- 有通知（既読済み）：ベルアイコンのみ
- 通知なし：ベルアイコン + 空状態（Empty State）
5.2 条件付き状態（Conditional）
- Loading：通知一覧の取得中（スケルトン）
- Error：通知取得失敗
5.3 State Gallery
| 状態 | 必須 | 何を伝えるか |
|---|---|---|
| 未読あり | ✅ | 未読通知件数（バッジ） |
| 全既読 | ✅ | 未処理の通知なし |
| 空状態 | ✅ | 通知がないことを明示 |
6. バリエーション設計（Variants）
表示形式とグループ化の方針で使い分ける。
| バリアント | 形式 | グループ化 | 使用例 |
|---|---|---|---|
| ドロップダウン | コンパクトなパネル | 時系列 | ヘッダーのベルアイコン |
| 専用ページ | フルページ | タイプ別 + 時系列 | 通知量が多いアプリ |
| サイドパネル | Sheetで表示 | 時系列 | ダッシュボード |
禁止パターン：未読バッジを常に0にリセットする（実際に未読があるのに） → ユーザーが「見逃した」と感じる不安を生む。
7. パターン集（Good / Bad / How to fix）
7.0 よく崩れる設計パターン（3つ）
- 通知の種類を絞らずすべての操作を通知する：「Aさんがいいねしました」が100件溜まって重要な「システム障害」通知が埋もれる
- 「すべて既読」がなく1件ずつしか処理できない：未読が多い時に処理を諦め、通知センターを開かなくなる
- 空状態（Empty State）のデザインがない：通知が0件の時に何も表示されず、バグなのか通知なしなのか不明
7.1 Bad（典型3つ）
- システム・メンション・いいね・コメントが全部同じスタイルで表示され、重要なメンションが埋もれる
- 未読バッジが正確な数字（例：「247」）を表示し、確認する気が失われる
- 通知一覧にスクロールがなく、古い通知がはみ出してCSS的に崩れる
7.2 Good（対になる3つ）
- メンション・システムを目立つスタイルにし、いいねをサブカラーにすることで重要度を視覚的に階層化する
- 未読バッジを
Math.min(count, 9)+count > 9 ? '+' : ''で上限9+として表示する max-height + overflow-y: autoでスクロール可能にし、スクロール量が分かるscrollbarスタイルを付与する
7.3 How to fix（手順）
- 通知タイプを重要度順に分類（例：メンション > コメント > いいね > システム）し、上位2タイプのみバッジや強調スタイルにする
- 「すべて既読」ボタンをパネルヘッダーに追加し、
onClickで全通知のreadフラグをtrueにする - 空状態（Empty State）のデザインを追加：アイコン + 「通知はありません」テキスト
- ベルアイコンに
aria-label={未読${count}件の通知}を付与し、スクリーンリーダーに未読数を伝える
8. ルール（Must / Better）
Must（守らないと壊れる）
Better（品質が跳ねる）
9. アクセシビリティ要件（必須）
Keyboard
TabでベルアイコンボタンにフォーカスEnter/Spaceでパネルを開くEscapeでパネルを閉じてベルアイコンにフォーカスを戻す- パネル内：
Tabで各通知とボタンを移動
Screen Reader
<!-- ベルアイコン -->
<button
aria-label="通知（未読3件）"
aria-expanded="false"
aria-haspopup="dialog"
>
🔔
<span aria-hidden="true">3</span>
</button>
<!-- 通知パネル -->
<div role="dialog" aria-label="通知センター">
<ul role="list" aria-label="通知一覧">
<li role="listitem">...</li>
</ul>
</div>
未読バッジの数字は aria-hidden="true" にし、件数は aria-label の中に含める（数字を2回読み上げさせない）。
10. 実装メモ（Implementation Notes）
- 通知の既読/未読状態はクライアントサイドの state で管理しつつ、サーバーに
PATCH /notifications/read-allなどのエンドポイントで同期する。オプティミスティック UI（先にUIを更新してからサーバーに送信）でレスポンス体感を改善する - リアルタイム更新はWebSocket（Socket.io）またはServer-Sent Events（SSE）で実装する。Next.js 13+ では Route Handler +
ReadableStreamでSSEを実装できる - 通知データが多い場合はページネーション（cursor-based）または無限スクロールで取得する。初期表示は最新10〜20件のみ取得し、「すべて表示」ページで全件を表示する
11. 関連リンク
- 関連するUIデザイン原則: フィードバック (Feedback), 状態の可視化 (Visibility of System Status)
- 用語集（定義）: フィードバック (Feedback), アクセシビリティ (Accessibility)
- 関連するUIコンポーネント（横）: Toast（トースト通知）, Alert（アラート）, Badge（バッジ）, Status Bar（ステータスバー）
12. まとめ
Notification Centerの設計で最重要なのは「通知の重要度の可視化」と「一括処理の手段の提供」です。迷ったら 4. 設計判断の核 に戻り、「未読バッジに上限があるか」「すべて既読ボタンがあるか」「グループ化で時系列が整理されているか」の3点を確認してください。Toast・Alert・Notification Centerの選択基準は「通知を後から振り返る必要があるか」——振り返る必要があるものはNotification Centerに蓄積し、即時確認で十分なものはToastまたはAlertを使います。
