---
title: "Next.js + Supabaseで未読管理機能を実装する完全ガイド：DB設計からRealtime自動更新まで"
description: "Next.jsとSupabaseで未読通知機能を実装する方法を解説。PostgreSQL RLSによるセキュアな設計から、React Contextでの状態管理、Realtimeによるリアルタイム更新まで、実装の全步骤を網羅しました。今日から未読管理を導入できます。"
created: "2026-01-01"
status: "draft"
platforms:
wordpress:
published: false
url: ""
published_date: ""
tags: ["Supabase", "PostgreSQL", "RLS", "Realtime", "React Context", "未読管理", "データベース設計"]
schema:
"@context": "https://schema.org"
"@type": "Article"
"headline": "Next.js + Supabaseで未読管理機能を実装する完全ガイド"
"description": "Next.jsとSupabaseで未読通知機能を実装する方法を解説。PostgreSQL RLSによるセキュアな設計から、React Contextでの状態管理、Realtimeによるリアルタイム更新まで紹介。"
"author":
"@type": "Person"
"name": "kurokawa"
"publisher":
"@type": "Organization"
"name": "kurokawa.dev"
"datePublished": "2026-01-01"
"dateModified": "2026-01-01"
---
掲示板アプリで、ユーザーが新しい返信を見逃さないよう「未読管理機能」と「通知UI」を実装しました。
正直なところ、最初は既読管理の仕様をどう設計するかで少し悩みました。最終的にSupabaseのRLSとRealtimeを組み合わせることで、シンプルかつリアルタイムに更新される未読管理が実現できました。
個人的に、React Contextでの状態管理がシンプルで気に入っています。また、実際に使ってみると、未読管理の重要性を改めて実感しました。
この記事では、データベース設計からReact Contextによる状態管理、Realtime購読による自動更新まで、実装の全貌を解説します。
## こんな人におすすめ
この記事は以下のような方に役立ちます。
- Supabaseで未読管理機能を実装したい方
- PostgreSQLのRLS（Row Level Security）を活用したい方
- Supabase Realtimeでリアルタイム更新を実装したい方
- React Contextでグローバルな状態管理を検討している方
- 未読管理のデータベース設計に悩んでいる方
## 目次
- [実装の概要](#実装の概要)
- [アーキテクチャ設計](#アーキテクチャ設計)
- [アーキテクチャ図](#アーキテクチャ図)
- [データベース設計と実装](#データベース設計と実装)
- [user_read_statusテーブルの作成](#user_read_statusテーブルの作成)
- [RLSポリシーの設定](#rlsポリシーの設定)
- [未読数取得RPC関数の実装](#未読数取得rpc関数の実装)
- [未読判定フロー図](#未読判定フロー図)
- [フロントエンドの実装](#フロントエンドの実装)
- [React Contextによる状態管理](#react-contextによる状態管理)
- [Realtime自動更新のシーケンス図](#realtime自動更新のシーケンス図)
- [既読マーク処理のシーケンス図](#既読マーク処理のシーケンス図)
- [未読バッジコンポーネント](#未読バッジコンポーネント)
- [未読判定ルールとビジネスロジック](#未読判定ルールとビジネスロジック)
- [パフォーマンスの最適化](#パフォーマンスの最適化)
- [FAQ：よくある質問](#faqよくある質問)
- [まとめ](#まとめ)
## 実装の概要
掲示板アプリにおいて、ユーザーが新しい返信を見逃さないよう、未読管理機能と通知UIを実装しました。
主な実装内容:
- **DBスキーマ**: `user_read_status` テーブル + RPC関数
- **API**: 既読マーク / 未読数取得 / トピック一覧に未読情報追加
- **UI**: 未読バッジ / ハイライト / 自動既読処理
- **Realtime**: 新しい返信があったら未読数を自動更新
## アーキテクチャ設計
未読管理機能のアーキテクチャは、以下の3層構造で設計しました。
**データベース層（Supabase/PostgreSQL）**:
- `user_read_status` テーブルでユーザーごとの既読状態を管理
- RLS（Row Level Security）でセキュリティを確保
- RPC関数で複雑な未読判定ロジックを実装
**API層（Next.js API Routes）**:
- 未読数取得エンドポイント
- 既読マーク付けエンドポイント
- Supabaseクライアントを通じたデータアクセス
**プレゼンテーション層（React）**:
- React Contextでグローバルな未読状態を管理
- Supabase Realtimeで新規返信を監視し自動更新
- 未読バッジコンポーネントで視覚的に通知
この3層構造により、関心の分離と保守性の向上を実現しています。
### アーキテクチャ図
```mermaid
graph LR
subgraph プレゼンテーション層
A[React Context]
B[未読バッジ<br/>UnreadBadge]
C[Realtime購読]
end
subgraph API層
D[未読数取得API<br/>/api/notifications/unread-count]
E[既読マークAPI<br/>/api/topics/:id/mark-read]
end
subgraph データベース層
F[(Supabase<br/>PostgreSQL)]
G[user_read_status<br/>テーブル]
H[get_unread_topic_count<br/>RPC関数]
I[RLSポリシー]
end
A --> D
A --> E
B --> A
C --> F
D --> F
E --> F
F --> G
F --> H
F --> I
style A fill:#e1f5fe
style B fill:#fff3e0
style C fill:#f3e5f5
style F fill:#e8f5e9
style G fill:#c8e6c9
style H fill:#c8e6c9
style I fill:#ffcdd2
```
**アーキテクチャのポイント**:
- プレゼンテーション層はReact Contextで状態管理し、Realtimeで自動更新
- API層はNext.js API RoutesでSupabaseへのアクセスを抽象化
- データベース層はRLSでセキュリティを確保し、RPC関数で複雑なロジックを実装
## データベース設計と実装
### user_read_statusテーブルの作成
まず、ユーザーの既読状態を管理するテーブルを作成します。
```sql
-- user_read_status テーブル作成
CREATE TABLE IF NOT EXISTS "public"."user_read_status" (
"id" "uuid" DEFAULT "gen_random_uuid"() NOT NULL,
"user_id" "text" NOT NULL,
"topic_id" "uuid" NOT NULL,
"last_read_at" timestamp with time zone DEFAULT "now"() NOT NULL,
"last_reply_count" integer DEFAULT 0 NOT NULL,
"created_at" timestamp with time zone DEFAULT "now"() NOT NULL,
"updated_at" timestamp with time zone DEFAULT "now"() NOT NULL,
CONSTRAINT "user_read_status_pkey" PRIMARY KEY ("id"),
CONSTRAINT "user_read_status_user_id_fkey" FOREIGN KEY ("user_id")
REFERENCES "public"."users"("id") ON DELETE CASCADE,
CONSTRAINT "user_read_status_topic_id_fkey" FOREIGN KEY ("topic_id")
REFERENCES "public"."topics"("id") ON DELETE CASCADE
);
```
**テーブル設計のポイント**:
- `user_id` と `topic_id` の複合ユニーク制約（アプリ側で実装）
- `last_read_at` で最後に既読にした日時を管理
- `last_reply_count` で既読時の返信数を保持（増分判定用）
- 外部キー制約でCASCADE削除を設定（トピック/ユーザー削除時に連動削除）
### RLSポリシーの設定
セキュリティのため、RLS（Row Level Security）を有効にします。
```sql
-- RLSポリシー（自分のレコードのみ閲覧・操作可能）
ALTER TABLE "public"."user_read_status" ENABLE ROW LEVEL SECURITY;
CREATE POLICY "user_read_status_select_policy" ON "public"."user_read_status"
FOR SELECT TO "authenticated" USING (auth.uid()::text = user_id);
```
**RLSのメリット**:
- データベースレベルでセキュリティを保証
- アプリケーション側のバグによる情報漏洩を防止
- 認証済みユーザーが自分のレコードのみアクセス可能
### 未読数取得RPC関数の実装
未読数を取得するRPC関数を作成します。
```sql
-- 未読数取得RPC関数
CREATE OR REPLACE FUNCTION "public"."get_unread_topic_count"("p_user_id" "text")
RETURNS integer
LANGUAGE "sql"
SECURITY DEFINER
AS $$
SELECT COUNT(DISTINCT t.id)::integer
FROM public.topics t
LEFT JOIN public.user_read_status urs
ON t.id = urs.topic_id AND urs.user_id = p_user_id
WHERE
EXISTS (SELECT 1 FROM public.replies r WHERE r.topic_id = t.id)
AND (
urs.id IS NULL
OR EXISTS (
SELECT 1 FROM public.replies r
WHERE r.topic_id = t.id AND r.created_at > urs.last_read_at
)
)
AND (
t.author_id = p_user_id
OR EXISTS (
SELECT 1 FROM public.replies r2
WHERE r2.topic_id = t.id AND r2.author_id = p_user_id
)
);
$$;
```
**未読判定ロジック**:
1. 返信が存在するトピックのみ対象
2. 以下の条件をすべて満たすトピックを未読としてカウント:
- 自分が作成したトピック、または自分が返信したトピック
- `user_read_status` レコードが存在しない（未訪問）
- または `last_read_at` より後に新しい返信がある
未読判定のフローを図で確認します。
### 未読判定フロー図
```mermaid
flowchart TD
A[トピック] --> B{返信が<br/>存在する?}
B -->|いいえ| Z[未読対象外]
B -->|はい| C{自分が関与<br/>している?}
C -->|いいえ| Z
C -->|はい| D{user_read_status<br/>レコードが<br/>存在する?}
D -->|いいえ| E[未読]
D -->|はい| F{last_read_atより<br/>後に新しい返信<br/>がある?}
F -->|はい| E
F -->|いいえ| G[既読]
style E fill:#ffcdd2
style G fill:#c8e6c9
style Z fill:#e0e0e0
```
**フローのポイント**:
- まず「返信が存在するか」でフィルタリング（返信がないトピックは通知不要）
- 次に「自分が関与しているか」でフィルタリング（作成者または返信者）
- 最後に「既読状態」を判定（未訪問または新しい返信があれば未読）
## フロントエンドの実装
### React Contextによる状態管理
React Contextで未読状態を管理し、Supabase Realtimeで新規返信を監視します。
```typescript
export function NotificationProvider({ children }: { children: ReactNode }) {
const [unreadCount, setUnreadCount] = useState(0);
const { currentUser } = useAuth();
const refreshUnreadCount = useCallback(async () => {
if (!currentUser?.id) return;
const response = await fetch(
`/api/notifications/unread-count?userId=${encodeURIComponent(currentUser.id)}`
);
if (response.ok) {
const data = await response.json();
setUnreadCount(data.unreadCount ?? 0);
}
}, [currentUser?.id]);
const markAsRead = useCallback(
async (topicId: string, _replyCount: number) => {
if (!currentUser?.id) return;
const response = await fetch(`/api/topics/${topicId}/mark-read`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ userId: currentUser.id }),
});
if (response.ok) await refreshUnreadCount();
},
[currentUser?.id, refreshUnreadCount]
);
// Realtime購読
useEffect(() => {
if (!currentUser?.id) return;
const channel = supabase
.channel('replies-for-notifications')
.on('postgres_changes',
{ event: 'INSERT', schema: 'public', table: 'replies' },
() => refreshUnreadCount()
)
.subscribe();
return () => { supabase.removeChannel(channel); };
}, [currentUser?.id, refreshUnreadCount]);
// ...
}
```
**実装のポイント**:
- `useState` で未読数を管理
- `useCallback` で関数をメモ化（再レンダリング防止）
- `useEffect` でRealtimeチャンネルを購読
- クリーンアップ関数でチャンネルを解除（メモリリーク防止）
Realtimeによる自動更新のシーケンスを図で確認します。
### Realtime自動更新のシーケンス図
```mermaid
sequenceDiagram
participant U as ユーザーA
participant U2 as ユーザーB
participant R as React Context
participant S as Supabase Realtime
participant DB as PostgreSQL
Note over R,DB: 初期化
R->>DB: 未読数を取得
DB-->>R: 未読数: 3
Note over U2,DB: 新規返信投稿
U2->>DB: 返信をINSERT
DB->>S: INSERTイベント発火
S->>R: postgres_changes通知
R->>DB: 未読数を再取得
DB-->>R: 未読数: 4
R->>U: 未読バッジ更新(4)
Note over R,S: クリーンアップ
R->>S: チャンネル解除
```
**Realtime自動更新のポイント**:
- ユーザーBが返信を投稿すると、PostgreSQLがINSERTイベントを発火
- Supabase Realtimeがイベントを購読中のReact Contextに通知
- React Contextが未読数を再取得してバッジを更新
- ユーザーAはページをリロードせずにリアルタイムで通知を受け取れる
既読マーク処理のシーケンスも確認します。
### 既読マーク処理のシーケンス図
```mermaid
sequenceDiagram
participant U as ユーザー
participant R as React Context
participant API as Next.js API
participant DB as PostgreSQL
U->>R: トピックを開く
R->>API: mark-read POST
API->>DB: user_read_statusをUPSERT
DB-->>API: 成功
API-->>R: レスポンス
R->>DB: 未読数を再取得
DB-->>R: 未読数: 2
R->>U: 未読バッジ更新(2)
```
**既読マーク処理のポイント**:
- トピックを開くと自動で既読マークAPIを呼び出し
- データベースの`user_read_status`をUPSERT（存在すれば更新、なければ作成）
- 未読数を再取得してバッジを更新
### 未読バッジコンポーネント
未読数を表示するバッジコンポーネントです。9より大きい場合は「9+」と表示します。
```typescript
export function UnreadBadge({ count, className = '' }: UnreadBadgeProps) {
if (count <= 0) return null;
return (
<span className={`inline-flex items-center justify-center min-w-[20px] h-5 px-1.5 text-xs font-bold text-white bg-red-500 rounded-full ${className}`}>
{count > 9 ? '9+' : count}
</span>
);
}
```
**UIのポイント**:
- 未読数が0の場合は非表示（`null`を返却）
- 9を超える場合は「9+」表示（UIの崩れ防止）
- Tailwind CSSでスタイリング（赤背景の丸型バッジ）
## 未読判定ルールとビジネスロジック
未読判定のビジネスロジックを明確に定義します。
| シナリオ | 未読対象 | 理由 |
|---------|---------|------|
| 自分が作成したトピック（返信あり） | ✅ | 自分のトピックに新しい返信がある |
| 自分が返信したトピック（新規返信あり） | ✅ | 関与したトピックに新しい返信がある |
| 返信が0件のトピック | ❌ | 返信がないため通知不要 |
| 閲覧のみのトピック | ❌ | 関与していないトピックは対象外 |
このルールにより、ユーザーにとって意味のある通知のみを表示できます。
## パフォーマンスの最適化
Gemini PRレビューで指摘を受けるまでは、パフォーマンス問題に気づいていませんでした。
別コミットで以下を対応:
**SQLの最適化**:
- WITH句で自分が関与したトピックを先に絞り込む
- インデックスの追加（`user_read_status(user_id, topic_id)` など）
**Realtimeの最適化**:
- Debounce（2秒）を追加して頻繁な更新を抑制
- チャンネル名を一意にして競合を防止
**APIの最適化**:
- mark-read APIで全返信データ取得を避け、カウントのみ取得
- レスポンスデータを最小限に削減
[関連記事：Supabaseのクエリパフォーマンスを改善するテクニック](#)（※内部リンク予定）
## FAQ：よくある質問
### Q1: 未読管理機能を実装するのにどのくらい時間がかかりますか？
A: 基本的な実装で1〜2日、テストと調整を含めて3〜5日程度です。データベース設計（半日）、フロントエンド実装（1日）、Realtime連携（半日）、テスト（1日）、微調整（1日）といった内訳になります。
### Q2: RLSは必須ですか？
A: セキュリティの観点から強く推奨します。RLSがない場合、アプリケーション側のバグで他ユーザーの既読状態にアクセスされるリスクがあります。データベースレベルでアクセス制限をかけることで、より安全なシステムになります。
### Q3: Realtimeはどのような場合に有効ですか？
A: 複数ユーザーが同時に利用するアプリケーションで有効です。掲示板、チャット、コラボレーションツールなど、リアルタイム性が求められる場面で活躍します。一方、個人利用のみのアプリではポーリングでも十分かもしれません。
### Q4: 未読数が増え続ける問題が発生した場合、どう対処しますか？
A: 以下の対策が有効です:
- 定期的に未読数を0にリセットする機能
- 未読数の上限を設定（例：99+表示）
- 古い未読をアーカイブする機能
- 通知オフ機能の実装
### Q5: スマートフォンでも動作しますか？
A: はい、レスポンシブデザインで実装すれば動作します。RealtimeはWebSocketを使用するため、モバイルネットワークでも安定して動作します。ただし、バッテリー消費に注意が必要です。
## まとめ
Next.jsとSupabaseで未読管理機能を実装しました。DBスキーマ設計からReact Contextによる状態管理、Realtime購読による自動更新まで、一連の実装を紹介しました。
個人的に、この実装を通じて学んだことは大きかったです。特に、SupabaseのRLSとRealtimeを組み合わせることで、フロントエンド側の実装をシンプルに保ちながら、リアルタイム性とセキュリティの両立ができることを実感しました。
同じような未読管理機能の実装を検討している方の参考になれば幸いです。
掲示板アプリで、ユーザーが新しい返信を見逃さないよう「未読管理機能」と「通知UI」を実装しました。
正直なところ、最初は既読管理の仕様をどう設計するかで少し悩みました。最終的にSupabaseのRLSとRealtimeを組み合わせることで、シンプルかつリアルタイムに更新される未読管理が実現できました。
個人的に、React Contextでの状態管理がシンプルで気に入っています。また、実際に使ってみると、未読管理の重要性を改めて実感しました。
この記事では、データベース設計からReact Contextによる状態管理、Realtime購読による自動更新まで、実装の全貌を解説します。
こんな人におすすめ
この記事は以下のような方に役立ちます。
- Supabaseで未読管理機能を実装したい方
- PostgreSQLのRLS（Row Level Security）を活用したい方
- Supabase Realtimeでリアルタイム更新を実装したい方
- React Contextでグローバルな状態管理を検討している方
- 未読管理のデータベース設計に悩んでいる方
目次
実装の概要
掲示板アプリにおいて、ユーザーが新しい返信を見逃さないよう、未読管理機能と通知UIを実装しました。
主な実装内容:
- DBスキーマ:
user_read_statusテーブル + RPC関数 - API: 既読マーク / 未読数取得 / トピック一覧に未読情報追加
- UI: 未読バッジ / ハイライト / 自動既読処理
- Realtime: 新しい返信があったら未読数を自動更新
アーキテクチャ設計
未読管理機能のアーキテクチャは、以下の3層構造で設計しました。
データベース層（Supabase/PostgreSQL）:
user_read_statusテーブルでユーザーごとの既読状態を管理- RLS（Row Level Security）でセキュリティを確保
- RPC関数で複雑な未読判定ロジックを実装
API層（Next.js API Routes）:
- 未読数取得エンドポイント
- 既読マーク付けエンドポイント
- Supabaseクライアントを通じたデータアクセス
プレゼンテーション層（React）:
- React Contextでグローバルな未読状態を管理
- Supabase Realtimeで新規返信を監視し自動更新
- 未読バッジコンポーネントで視覚的に通知
この3層構造により、関心の分離と保守性の向上を実現しています。
アーキテクチャ図
graph LR
subgraph プレゼンテーション層
A[React Context]
B[未読バッジ<br/>UnreadBadge]
C[Realtime購読]
end
subgraph API層
D[未読数取得API<br/>/api/notifications/unread-count]
E[既読マークAPI<br/>/api/topics/:id/mark-read]
end
subgraph データベース層
F[(Supabase<br/>PostgreSQL)]
G[user_read_status<br/>テーブル]
H[get_unread_topic_count<br/>RPC関数]
I[RLSポリシー]
end
A --> D
A --> E
B --> A
C --> F
D --> F
E --> F
F --> G
F --> H
F --> I
style A fill:#e1f5fe
style B fill:#fff3e0
style C fill:#f3e5f5
style F fill:#e8f5e9
style G fill:#c8e6c9
style H fill:#c8e6c9
style I fill:#ffcdd2
アーキテクチャのポイント:
- プレゼンテーション層はReact Contextで状態管理し、Realtimeで自動更新
- API層はNext.js API RoutesでSupabaseへのアクセスを抽象化
- データベース層はRLSでセキュリティを確保し、RPC関数で複雑なロジックを実装
データベース設計と実装
user_read_statusテーブルの作成
まず、ユーザーの既読状態を管理するテーブルを作成します。
-- user_read_status テーブル作成
CREATE TABLE IF NOT EXISTS "public"."user_read_status" (
"id" "uuid" DEFAULT "gen_random_uuid"() NOT NULL,
"user_id" "text" NOT NULL,
"topic_id" "uuid" NOT NULL,
"last_read_at" timestamp with time zone DEFAULT "now"() NOT NULL,
"last_reply_count" integer DEFAULT 0 NOT NULL,
"created_at" timestamp with time zone DEFAULT "now"() NOT NULL,
"updated_at" timestamp with time zone DEFAULT "now"() NOT NULL,
CONSTRAINT "user_read_status_pkey" PRIMARY KEY ("id"),
CONSTRAINT "user_read_status_user_id_fkey" FOREIGN KEY ("user_id")
REFERENCES "public"."users"("id") ON DELETE CASCADE,
CONSTRAINT "user_read_status_topic_id_fkey" FOREIGN KEY ("topic_id")
REFERENCES "public"."topics"("id") ON DELETE CASCADE
);
テーブル設計のポイント:
user_idとtopic_idの複合ユニーク制約（アプリ側で実装）last_read_atで最後に既読にした日時を管理last_reply_countで既読時の返信数を保持（増分判定用）- 外部キー制約でCASCADE削除を設定（トピック/ユーザー削除時に連動削除）
RLSポリシーの設定
セキュリティのため、RLS（Row Level Security）を有効にします。
-- RLSポリシー（自分のレコードのみ閲覧・操作可能）
ALTER TABLE "public"."user_read_status" ENABLE ROW LEVEL SECURITY;
CREATE POLICY "user_read_status_select_policy" ON "public"."user_read_status"
FOR SELECT TO "authenticated" USING (auth.uid()::text = user_id);
RLSのメリット:
- データベースレベルでセキュリティを保証
- アプリケーション側のバグによる情報漏洩を防止
- 認証済みユーザーが自分のレコードのみアクセス可能
未読数取得RPC関数の実装
未読数を取得するRPC関数を作成します。
-- 未読数取得RPC関数
CREATE OR REPLACE FUNCTION "public"."get_unread_topic_count"("p_user_id" "text")
RETURNS integer
LANGUAGE "sql"
SECURITY DEFINER
AS $$
SELECT COUNT(DISTINCT t.id)::integer
FROM public.topics t
LEFT JOIN public.user_read_status urs
ON t.id = urs.topic_id AND urs.user_id = p_user_id
WHERE
EXISTS (SELECT 1 FROM public.replies r WHERE r.topic_id = t.id)
AND (
urs.id IS NULL
OR EXISTS (
SELECT 1 FROM public.replies r
WHERE r.topic_id = t.id AND r.created_at > urs.last_read_at
)
)
AND (
t.author_id = p_user_id
OR EXISTS (
SELECT 1 FROM public.replies r2
WHERE r2.topic_id = t.id AND r2.author_id = p_user_id
)
);
$$;
未読判定ロジック:
- 返信が存在するトピックのみ対象
- 以下の条件をすべて満たすトピックを未読としてカウント:
- 自分が作成したトピック、または自分が返信したトピック
user_read_statusレコードが存在しない（未訪問）- または
last_read_atより後に新しい返信がある
未読判定のフローを図で確認します。
未読判定フロー図
flowchart TD
A[トピック] --> B{返信が<br/>存在する?}
B -->|いいえ| Z[未読対象外]
B -->|はい| C{自分が関与<br/>している?}
C -->|いいえ| Z
C -->|はい| D{user_read_status<br/>レコードが<br/>存在する?}
D -->|いいえ| E[未読]
D -->|はい| F{last_read_atより<br/>後に新しい返信<br/>がある?}
F -->|はい| E
F -->|いいえ| G[既読]
style E fill:#ffcdd2
style G fill:#c8e6c9
style Z fill:#e0e0e0
フローのポイント:
- まず「返信が存在するか」でフィルタリング（返信がないトピックは通知不要）
- 次に「自分が関与しているか」でフィルタリング（作成者または返信者）
- 最後に「既読状態」を判定（未訪問または新しい返信があれば未読）
フロントエンドの実装
React Contextによる状態管理
React Contextで未読状態を管理し、Supabase Realtimeで新規返信を監視します。
export function NotificationProvider({ children }: { children: ReactNode }) {
const [unreadCount, setUnreadCount] = useState(0);
const { currentUser } = useAuth();
const refreshUnreadCount = useCallback(async () => {
if (!currentUser?.id) return;
const response = await fetch(
`/api/notifications/unread-count?userId=${encodeURIComponent(currentUser.id)}`
);
if (response.ok) {
const data = await response.json();
setUnreadCount(data.unreadCount ?? 0);
}
}, [currentUser?.id]);
const markAsRead = useCallback(
async (topicId: string, _replyCount: number) => {
if (!currentUser?.id) return;
const response = await fetch(`/api/topics/${topicId}/mark-read`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ userId: currentUser.id }),
});
if (response.ok) await refreshUnreadCount();
},
[currentUser?.id, refreshUnreadCount]
);
// Realtime購読
useEffect(() => {
if (!currentUser?.id) return;
const channel = supabase
.channel('replies-for-notifications')
.on('postgres_changes',
{ event: 'INSERT', schema: 'public', table: 'replies' },
() => refreshUnreadCount()
)
.subscribe();
return () => { supabase.removeChannel(channel); };
}, [currentUser?.id, refreshUnreadCount]);
// ...
}
実装のポイント:
useStateで未読数を管理useCallbackで関数をメモ化（再レンダリング防止）useEffectでRealtimeチャンネルを購読- クリーンアップ関数でチャンネルを解除（メモリリーク防止）
Realtimeによる自動更新のシーケンスを図で確認します。
Realtime自動更新のシーケンス図
sequenceDiagram
participant U as ユーザーA
participant U2 as ユーザーB
participant R as React Context
participant S as Supabase Realtime
participant DB as PostgreSQL
Note over R,DB: 初期化
R->>DB: 未読数を取得
DB-->>R: 未読数: 3
Note over U2,DB: 新規返信投稿
U2->>DB: 返信をINSERT
DB->>S: INSERTイベント発火
S->>R: postgres_changes通知
R->>DB: 未読数を再取得
DB-->>R: 未読数: 4
R->>U: 未読バッジ更新(4)
Note over R,S: クリーンアップ
R->>S: チャンネル解除
Realtime自動更新のポイント:
- ユーザーBが返信を投稿すると、PostgreSQLがINSERTイベントを発火
- Supabase Realtimeがイベントを購読中のReact Contextに通知
- React Contextが未読数を再取得してバッジを更新
- ユーザーAはページをリロードせずにリアルタイムで通知を受け取れる
既読マーク処理のシーケンスも確認します。
既読マーク処理のシーケンス図
sequenceDiagram
participant U as ユーザー
participant R as React Context
participant API as Next.js API
participant DB as PostgreSQL
U->>R: トピックを開く
R->>API: mark-read POST
API->>DB: user_read_statusをUPSERT
DB-->>API: 成功
API-->>R: レスポンス
R->>DB: 未読数を再取得
DB-->>R: 未読数: 2
R->>U: 未読バッジ更新(2)
既読マーク処理のポイント:
- トピックを開くと自動で既読マークAPIを呼び出し
- データベースの
user_read_statusをUPSERT（存在すれば更新、なければ作成） - 未読数を再取得してバッジを更新
未読バッジコンポーネント
未読数を表示するバッジコンポーネントです。9より大きい場合は「9+」と表示します。
export function UnreadBadge({ count, className = '' }: UnreadBadgeProps) {
if (count <= 0) return null;
return (
<span className={`inline-flex items-center justify-center min-w-[20px] h-5 px-1.5 text-xs font-bold text-white bg-red-500 rounded-full ${className}`}>
{count > 9 ? '9+' : count}
</span>
);
}
UIのポイント:
- 未読数が0の場合は非表示（
nullを返却） - 9を超える場合は「9+」表示（UIの崩れ防止）
- Tailwind CSSでスタイリング（赤背景の丸型バッジ）
未読判定ルールとビジネスロジック
未読判定のビジネスロジックを明確に定義します。
| シナリオ | 未読対象 | 理由 |
|---|---|---|
| 自分が作成したトピック（返信あり） | ✅ | 自分のトピックに新しい返信がある |
| 自分が返信したトピック（新規返信あり） | ✅ | 関与したトピックに新しい返信がある |
| 返信が0件のトピック | ❌ | 返信がないため通知不要 |
| 閲覧のみのトピック | ❌ | 関与していないトピックは対象外 |
このルールにより、ユーザーにとって意味のある通知のみを表示できます。
パフォーマンスの最適化
Gemini PRレビューで指摘を受けるまでは、パフォーマンス問題に気づいていませんでした。
別コミットで以下を対応:
SQLの最適化:
- WITH句で自分が関与したトピックを先に絞り込む
- インデックスの追加（
user_read_status(user_id, topic_id)など）
Realtimeの最適化:
- Debounce（2秒）を追加して頻繁な更新を抑制
- チャンネル名を一意にして競合を防止
APIの最適化:
- mark-read APIで全返信データ取得を避け、カウントのみ取得
- レスポンスデータを最小限に削減
関連記事：Supabaseのクエリパフォーマンスを改善するテクニック（※内部リンク予定）
FAQ：よくある質問
Q1: 未読管理機能を実装するのにどのくらい時間がかかりますか？
A: 基本的な実装で1〜2日、テストと調整を含めて3〜5日程度です。データベース設計（半日）、フロントエンド実装（1日）、Realtime連携（半日）、テスト（1日）、微調整（1日）といった内訳になります。
Q2: RLSは必須ですか？
A: セキュリティの観点から強く推奨します。RLSがない場合、アプリケーション側のバグで他ユーザーの既読状態にアクセスされるリスクがあります。データベースレベルでアクセス制限をかけることで、より安全なシステムになります。
Q3: Realtimeはどのような場合に有効ですか？
A: 複数ユーザーが同時に利用するアプリケーションで有効です。掲示板、チャット、コラボレーションツールなど、リアルタイム性が求められる場面で活躍します。一方、個人利用のみのアプリではポーリングでも十分かもしれません。
Q4: 未読数が増え続ける問題が発生した場合、どう対処しますか？
A: 以下の対策が有効です:
- 定期的に未読数を0にリセットする機能
- 未読数の上限を設定（例：99+表示）
- 古い未読をアーカイブする機能
- 通知オフ機能の実装
Q5: スマートフォンでも動作しますか？
A: はい、レスポンシブデザインで実装すれば動作します。RealtimeはWebSocketを使用するため、モバイルネットワークでも安定して動作します。ただし、バッテリー消費に注意が必要です。
まとめ
Next.jsとSupabaseで未読管理機能を実装しました。DBスキーマ設計からReact Contextによる状態管理、Realtime購読による自動更新まで、一連の実装を紹介しました。
個人的に、この実装を通じて学んだことは大きかったです。特に、SupabaseのRLSとRealtimeを組み合わせることで、フロントエンド側の実装をシンプルに保ちながら、リアルタイム性とセキュリティの両立ができることを実感しました。
同じような未読管理機能の実装を検討している方の参考になれば幸いです。
