React Server Components とAI機能の意外な相性問題

結論: RSCとAIは相性が良いが、落とし穴も多い

React Server Components (RSC) はLLMのStreamingと相性が良いと宣伝されていますが、実装してみると意外な相性問題が次々と出てきます。本記事では2026年現在のRSC × AI機能で遭遇する5つの相性問題と、実用的な回避策を共有します。

この記事でわかること:

• RSCとAIストリーミングの実態
• ‘use client’境界で起きる詰まりポイント
• Server Actionsの認証・エラー処理
• 2026年版のおすすめ構成

相性問題1: ストリーミングがRSCを直接通らない

「RSCはストリーミングできる」と言われますが、これはHTMLのストリーミングであり、LLMのトークン単位ストリーミングとは別物です。LLMの応答をリアルタイムにUIへ反映するには、結局クライアントコンポーネント側でuseChatなどのフックを使う必要があります。RSCで完結すると思って設計を始めると、後で大きな手戻りが発生します。

相性問題2: useEffectが使えない

RSCにはuseEffectやuseStateがありません。AIの応答結果に応じてクライアント側の状態を更新したい場合、必然的に'use client'境界が必要になります。サーバーで取得した初期データをPropsで渡し、以降の対話はクライアントで管理するハイブリッド設計が定石です。

相性問題3: Server Actionsのエラーが握り潰される

Server Actionsは便利ですが、内部で発生したエラーがクライアントには「サーバーエラー」としか伝わらない設計になっています。LLMのレート制限・タイムアウトを明確にユーザーへ伝えるには、結果オブジェクトとして返すパターン (Result型) が推奨されます。

'use server'
export async function chat(input: string): Promise<Result> {
  try {
    const res = await llm.generate(input);
    return { ok: true, data: res };
  } catch (e) {
    return { ok: false, error: classify(e) };
  }
}

相性問題4: ‘use client’境界の肥大化

チャットUIをクライアントコンポーネントとして作り始めると、依存するコンポーネントが芋づる式にクライアント側へ移動し、結果としてRSCのメリットがほとんど失われる現象が起きます。回避策は、メッセージリストの個々のMessageをRSCで描画し、入力フォームと送信ロジックだけをクライアントに分離する設計です。

相性問題5: キャッシュ戦略の不一致

Next.js App RouterはRSCを積極的にキャッシュしますが、AI応答はキャッシュすべきではありません。export const dynamic = 'force-dynamic'またはnoStore()を明示的に呼ばないと、古い応答が他のユーザーに表示される事故が起きます。

2026年版のおすすめ構成

これらの問題を踏まえ、現時点でうまく機能する構成は以下のとおりです。

1. 初期データ取得: RSCでDB・履歴を取得
2. UI描画: メッセージ表示はRSC、入力エリアはClient Component
3. 送信: Server Action経由でLLM呼び出し
4. ストリーミング: useChatまたはai-sdkのStream APIで処理
5. エラー伝達: Result型で明示的に
6. キャッシュ: AI関連はnoStore()を徹底

この構成で社内チャットボットを実装したところ、初期表示が180ms、最初のトークン到達が420ms、エラー時のリカバリーUIも自然に動く水準に到達しました。

RSCを使わない選択肢もある

AIチャットUIは結局クライアント主体になることが多く、あえてRSCを使わずPages Routerで作る判断も依然として合理的です。重要なのは「フレームワークの新機能を全部使う」ことではなく、AIアプリの要件に合った最小構成を選ぶことです。

まとめ

RSCはAIアプリと相性が良いと言われますが、現実にはストリーミング・useEffect不在・Server Actionsのエラー処理・’use client’境界・キャッシュの5つで詰まりやすい構造です。2026年の今、RSCを使うなら「サーバーで取れるデータはRSC、対話はClient」というハイブリッド設計を徹底するのが安全です。新機能に振り回されず、AIアプリの要件から逆算して設計しましょう。