はじめに

「Next.jsアプリのパフォーマンス、もっと向上させたい…」 「静的サイトのような爆速表示と、動的コンテンツのリアルタイム更新、この二つを両立できずに悩んでいませんか？」

Next.js開発者であれば、一度はこのような課題に直面したことがあるでしょう。私たちはこれまで、ページの特性に応じてServer-Side Rendering (SSR)、Static Site Generation (SSG)、Incremental Static Regeneration (ISR) といったレンダリング戦略を使い分ける必要がありました。

• SSRは動的なコンテンツに強い反面、リクエストごとにサーバーでレンダリングするためTime to First Byte (TTFB) が遅くなりがちです。
• SSGはCDNから配信できるため非常に高速ですが、動的コンテンツの扱いやビルド時間の増大という課題を抱えています。
• ISRはSSGの弱点を補いますが、リアルタイムの更新には対応しきれない場面もあります。

これらの戦略は強力ですが、ページ全体を「静的」か「動的」のどちらか一方の型にはめる「All or Nothing」のアプローチでした。例えば、大半が静的なEコマースの商品ページでも、在庫情報やレビューといった一部の動的コンテンツのために、ページ全体をSSRせざるを得ず、パフォーマンスを犠牲にすることが少なくありませんでした。

この長年のジレンマに終止符を打つべく登場し、Next.js 16でついに安定版となったのが Partial Prerendering (PPR) です。

PPRは、静的なパフォーマンスと動的な柔軟性を融合させる、まさに革命的なレンダリングモデルです。この記事では、PPRがなぜ重要なのか、その仕組み、具体的な実装方法から実践的なTipsまで、Next.js 16の目玉機能であるPPRを徹底的に解剖します。この記事を読み終える頃には、あなたはPPRを完全に理解し、自身のプロジェクトでその強力なパフォーマンスを最大限に引き出せるようになっているはずです。

なぜPPRは登場したのか？Webレンダリングの進化と課題

PPRの革新性を理解するためには、まずこれまでのWebレンダリングがどのような変遷を辿ってきたのかを知る必要があります。

Webレンダリング戦略の歴史

1. サーバーサイドレンダリングの黎明期 (CGI, PHP, Ruby on Rails) Webの初期、コンテンツはリクエストごとにサーバーでHTMLを生成して返すのが主流でした。これにより動的なコンテンツは実現できましたが、リクエストのたびに重い処理が走るため、パフォーマンスに課題がありました。

2. SPA (Single Page Application) の台頭 (React, Vue, Angular) 次に、クライアントサイドでJavaScriptがUIを構築するSPAが登場しました。初回ロード後はページ遷移なしに高速な画面更新が可能になり、リッチなUIが実現できます。しかし、初回のバンドルサイズが大きく初期表示が遅い、そしてSEOに課題があるという弱点がありました。

3. Next.jsがもたらしたハイブリッドアプローチ (SSR, SSG, ISR) この両者の課題を解決するために登場したのがNext.jsです。Next.jsは、ページ単位で最適なレンダリング戦略を選択できるハイブリッドなフレームワークとして絶大な支持を得ました。

   • SSR (Server-Side Rendering): リクエストごとにサーバーでHTMLを生成。SEOに強く、初期表示に必要なデータが揃っています。しかし、サーバー負荷が高く、TTFBが遅くなりがちです。
   • SSG (Static Site Generation): ビルド時にすべてのページをHTMLとして事前生成。CDNに配置することで、リクエスト時にはファイルを返すだけなので超高速です。しかし、ユーザー固有の情報のような動的コンテンツには向かず、サイト規模が大きくなるとビルド時間が長大になる問題がありました。
   • ISR (Incremental Static Regeneration): SSGの弱点を補う仕組み。一定時間ごとにバックグラウンドでページを再生成し、静的コンテンツの鮮度を保ちます。しかし、リアルタイム性が求められるコンテンツには対応が難しいという側面がありました。

従来のレンダリング戦略が抱える「All or Nothing」問題

これらの戦略は非常に強力でしたが、根本的な課題を抱えていました。それは、1つのページは1つのレンダリング戦略しか選べないという「All or Nothing」の問題です。

この問題が顕著になるのが、静的コンテンツと動的コンテンツが混在するページです。先ほどのEコマースの商品ページを例に考えてみましょう。

• 静的な部分: 商品名、商品説明、スペック、メイン画像など、滅多に変わらない情報。
• 動的な部分: 在庫数、ユーザーレビュー、あなたへのおすすめ商品、セール価格など、リアルタイムで変化する情報。

従来のモデルでは、このページに動的な部分が一つでも含まれていると、ページ全体をSSRまたはISR（短い間隔での再生成）で構築する必要がありました。これにより、本来は高速に表示できるはずの静的な部分まで、リクエストのたびにサーバーでレンダリングされるのを待たなければならず、TTFBが悪化し、ユーザー体験を損なう原因となっていました。

この「All or Nothing」の制約を打ち破り、静的な部分のパフォーマンスと動的な部分の柔軟性を1つのページ内で共存させるために開発されたのが、Partial Prerendering (PPR)なのです。

Partial Prerendering (PPR) の核心に迫る：仕組みと使い方

PPRは、Next.js App RouterとReact Server Components (RSC) のアーキテクチャを基盤として実現されています。そのコンセプトは非常にシンプルです。「ページの静的な部分を事前にビルドしておき、動的な部分だけをリクエスト時にストリーミングで配信する」というものです。

「静的シェル」と「動的ホール」

PPRを理解する上で最も重要な概念が「静的シェル (Static Shell)」と「動的ホール (Dynamic Holes)」です。

• 静的シェル: ページのレイアウト、ナビゲーションバー、フッター、そして商品名や商品説明といった静的なコンテンツを含む、ページの骨格となる部分です。これはビルド時に事前生成（Prerender）され、CDNにキャッシュされます。
• 動的ホール: 在庫情報やレビューなど、動的に生成されるコンテンツが入る「穴」の部分です。静的シェルの中では、この部分はプレースホルダーとして空けられています。

この仕組みを図でイメージしてみましょう。

【ビルド時】
+-------------------------------------------------+
|               静的シェル (Static Shell)           |
| +-------------------------------------------+ |
| | ナビゲーションバー (静的)                 | |
| +-------------------------------------------+ |
| |                                           | |
| | 商品画像、商品名、商品説明 (静的)         | |
| |                                           | |
| | +---------------------------------------+ | |
| | | 動的ホール (1): レビュー (プレースホルダー)| |
| | +---------------------------------------+ | |
| |                                           | |
| | +---------------------------------------+ | |
| | | 動的ホール (2): おすすめ商品 (プレースホルダー) | |
| | +---------------------------------------+ | |
| |                                           | |
| +-------------------------------------------+ |
| | フッター (静的)                           | |
| +-------------------------------------------+ |
+-------------------------------------------------+

PPRの動作フロー

ユーザーがページにアクセスした際の動作フローは以下のようになります。

1. 即時レスポンス: ユーザーからのリクエストに対し、CDNにキャッシュされている「静的シェル」が即座に返されます。これにより、TTFBが劇的に改善され、ユーザーはすぐにページの骨格を見ることができます。
2. 動的コンテンツのストリーミング: ブラウザが静的シェルを表示している間に、Next.jsサーバーは「動的ホール」の中身を非同期でレンダリングします。
3. コンテンツの注入: レンダリングが完了した動的コンテンツは、HTTPストリーミングを通じてブラウザに送信され、対応するプレースホルダー部分にシームレスに注入されます。この間、Suspenseのfallbackに指定したスケルトンUIやローディングスピナーが表示されるため、ユーザーはデータが読み込み中であることを認識できます。

このアーキテクチャにより、ユーザーはサーバーでの重い処理が終わるのを待つことなく、インタラクション可能なページを即座に手に入れることができるのです。

コードで見るPPR：Suspenseが鍵

驚くべきことに、PPRを有効にするために特別な設定はほとんど必要ありません。Next.js 14.1以降のApp Routerを使用していれば、PPRはデフォルトで有効です。

PPRの魔法を実現する鍵となるのが、Reactの <Suspense> コンポーネントです。<Suspense>でラップされたコンポーネントが「動的ホール」として扱われます。

それでは、Eコマースの商品ページを例に、具体的なコードを見ていきましょう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

// app/products/[id]/page.tsx

import { Suspense } from 'react';
import ProductDetails from '@/components/ProductDetails';
import { Reviews, ReviewsSkeleton } from '@/components/Reviews';
import { Recommendations, RecommendationsSkeleton } from '@/components/Recommendations';
import { getStaticProductData } from '@/lib/products';

// このページ自体は静的として扱われる
export default async function ProductPage({ params }: { params: { id: string } }) {
  // 商品の基本情報（商品名、説明など）はビルド時に取得される
  // このデータ取得はキャッシュされる
  const product = await getStaticProductData(params.id);

  return (
    <div>
      {/* ============================= */}
      {/* === ここからが静的シェル === */}
      {/* ============================= */}
      <header>My E-Commerce Site</header>
      <main>
        {/* このコンポーネントは静的にレンダリングされる */}
        <ProductDetails product={product} />
        
        <hr />

        {/* ========================================= */}
        {/* === ここからが動的なホール (1): レビュー === */}
        {/* ========================================= */}
        <Suspense fallback={<ReviewsSkeleton />}>
          {/* 
            Reviewsコンポーネントは内部で動的なデータ取得を行う。
            (例: fetch(..., { cache: 'no-store' }))
            このため、この部分はリクエスト時にレンダリングされる。
          */}
          <Reviews productId={product.id} />
        </Suspense>
        
        <hr />

        {/* =================================================== */}
        {/* === ここからが動的なホール (2): おすすめ商品 === */}
        {/* =================================================== */}
        <h2>あなたへのおすすめ</h2>
        <Suspense fallback={<RecommendationsSkeleton />}>
          {/* 
            Recommendationsコンポーネントも動的なデータ取得を行う。
            レビューとは独立してストリーミングされる。
          */}
          <Recommendations category={product.category} />
        </Suspense>
      </main>
      <footer>Footer Content</footer>
      {/* =========================== */}
      {/* === ここまでが静的シェル === */}
      {/* =========================== */}
    </div>
  );
}

このコードのポイントは以下の通りです。

1. ページの基本構造は静的: ProductPage自体はasyncコンポーネントですが、内部で行われるデータ取得 (getStaticProductData) がキャッシュされるため、ページの主要部分は静的に事前生成されます。これが「静的シェル」となります。
2. Suspenseで動的境界を定義: <Reviews>と<Recommendations>コンポーネントは、それぞれ<Suspense>でラップされています。これらのコンポーネントは、内部で動的なデータフェッチ（例えば fetch の cache: 'no-store' オプションや、cookies()、headers() といったDynamic Functionsの使用）を行うため、「動的ホール」として扱われます。
3. fallbackでUXを向上: 動的コンテンツがロードされるまでの間、fallbackプロパティに指定されたスケルトンコンポーネント (<ReviewsSkeleton />, <RecommendationsSkeleton />) が表示されます。これにより、レイアウトシフトを防ぎ、ユーザー体験を向上させます。

このように、開発者は「どこを動的にしたいか」を<Suspense>で宣言するだけで、Next.jsが自動的にPPRを適用し、最適なレンダリングを行ってくれるのです。

PPRがもたらすメリットと考慮すべき点

PPRは多くのメリットをもたらしますが、採用する上で知っておくべき考慮点も存在します。

メリット

1. 圧倒的なパフォーマンス向上:

   • TTFB (Time to First Byte) の劇的な改善: CDNから静的シェルを即座に返せるため、サーバーでのレンダリング待ち時間がなくなり、TTFBは限りなくゼロに近づきます。
   • FCP/LCP の高速化: ユーザーはページの主要なコンテンツをすぐに視認できるため、First Contentful Paint (FCP) や Largest Contentful Paint (LCP) といったCore Web Vitalsの指標が大幅に改善されます。

2. 最高のユーザー体験 (UX):

   • 静的な部分は即座に表示され、インタラクション可能になります。
   • 動的な部分はスケルトンUIなどで読み込み中であることが明示されるため、ユーザーは白紙の画面を見て待たされるストレスから解放されます。

3. 優れた開発体験 (DX):

   • 「SSGかSSRか」というページ単位での二者択一の悩みから解放されます。
   • 開発者はコンポーネント単位でキャッシュ戦略を考えるだけでよくなり、より直感的にアプリケーションを構築できます。
   • 複雑な設定は不要で、Reactの標準的な機能である<Suspense>を使うだけで実現できるシンプルさも魅力です。

4. インフラコストの削減:

   • 静的シェルがCDNから配信されることで、オリジンサーバーへのリクエスト数が減少します。これにより、サーバーの負荷が軽減され、インフラコストの削減につながる可能性があります。

デメリット / 考慮すべき点

1. App RouterとRSCへの依存: PPRは、React Server Components (RSC) を前提としたApp Routerのアーキテクチャ上で成り立っています。従来のPages Routerでは利用できず、PPRの恩恵を受けるためにはApp Routerへの移行が必要です。

2. Suspenseの境界設計の重要性: Suspenseの境界（boundary）をどこに設定するかが、パフォーマンスとUXを左右します。境界が大きすぎるとストリーミングのメリットが薄れ、細かすぎるとコンポーネントの管理が複雑になる可能性があります。戦略的な設計が求められます。

3. キャッシュ戦略の理解: ページ単位ではなく、コンポーネントやデータフェッチ単位でキャッシュを管理する必要があるため、アプリケーション全体のキャッシュ戦略をより深く理解し、設計することが重要になります。特に、意図せずページ全体が動的レンダリングになってしまうケース（ルートレイアウトでのDynamic Functionsの使用など）には注意が必要です。

4. サードパーティライブラリの互換性: RSCに対応していないクライアントサイド専用のライブラリ（例: windowオブジェクトに直接アクセスするもの）は、'use client'ディレクティブを付けたClient Component内で使用する必要があります。PPRの文脈でもこの原則は変わらないため、ライブラリの選定や利用方法に注意が必要です。

現場で使えるPPR実践Tips

PPRを最大限に活用するための、より実践的なヒントをいくつかご紹介します。

Tip 1: Suspenseの境界を戦略的に設計する

Suspenseでどこを囲むかは非常に重要です。以下の点を考慮して設計しましょう。

• Above the Fold (ファーストビュー) は静的に: ユーザーが最初に目にする画面（スクロールせずに見える範囲）は、可能な限り静的シェルに含め、即座に表示されるようにします。LCPの改善に直結します。
• Below the Fold (スクロール後) を動的に: コメント欄や関連商品リストなど、スクロールしないと見えない部分は、積極的にSuspenseで囲み、遅延ロードさせましょう。これにより、初期表示のパフォーマンスへの影響を最小限に抑えられます。
• データ取得が遅いコンポーネントを分離する: 外部APIへの依存などでどうしても読み込みが遅くなるコンポーネントは、他のUIから独立させてSuspenseで囲むことで、そのコンポーネントの遅延がページ全体の表示をブロックするのを防ぎます。

Tip 2: 高品質なスケルトンUIを実装する

fallbackに表示されるUIは、ユーザー体験を大きく左右します。

• 単なる「ローディング中…」は避ける: テキストだけのローディング表示は、味気なく、ユーザーに不安を与える可能性があります。
• レイアウトを維持するスケルトンを: 実際に表示されるコンテンツのレイアウトを模したスケルトンUI（Shimmer UIとも呼ばれる）を用意しましょう。これにより、コンテンツが読み込まれた際のレイアウトシフト（CLS: Cumulative Layout Shift）を防ぎ、スムーズな表示を実現できます。shadcn/uiなどのライブラリには、便利なSkeletonコンポーネントが用意されています。

Tip 3: Next.jsのキャッシュとレンダリングを可視化・デバッグする

意図通りにPPRが機能しているかを確認することが重要です。

• ビルドログの確認: next build を実行すると、各ページが静的（λ）か動的（○）かが出力されます。PPRが適用されているページは静的（λ）としてマークされるはずです。
• ブラウザの開発者ツール: Networkタブでドキュメントのレスポンスを確認します。PPRが機能している場合、最初のHTMLレスポンスには静的シェルとSuspenseのfallbackが含まれ、その後、動的コンテンツがチャンクとしてストリーミングされてくる様子を観察できます。
• Vercelへのデプロイ: Vercelにデプロイすると、Speed InsightsやAnalytics機能を使って、TTFBやLCPといったパフォーマンス指標を実環境でモニタリングし、PPR導入による改善効果を定量的に測定できます。

まとめ

Next.js 16で安定版となったPartial Prerendering (PPR)は、単なる新機能ではありません。それは、Webアプリケーションのパフォーマンスと体験を根底から変える、レンダリングの新しいパラダイムです。

これまで私たちが直面してきた、静的サイトの「速度」と動的アプリケーションの「柔軟性」のトレードオフ、すなわち「All or Nothing」問題は、PPRによってついに解決されました。PPRは、React Server ComponentsとSuspenseを組み合わせることで、1つのページ内に静的なシェルと動的なホールを共存させ、両者の利点を同時に享受することを可能にします。

その結果として得られるのは、CDNエッジからの即時レスポンスによる驚異的なTTFB、最適化されたCore Web Vitals、そしてシームレスでストレスのないユーザー体験です。開発者にとっても、複雑なレンダリング戦略の選択に頭を悩ませることなく、コンポーネント単位でその性質を考えるだけで、フレームワークが最適なパフォーマンスを引き出してくれるという、この上ない開発体験を提供します。

App Routerへの移行というハードルはありますが、PPRがもたらす恩恵はそれを補って余りあるものです。今後のWeb開発において、このアーキテクチャがスタンダードになっていくことは間違いないでしょう。

さあ、あなたのNext.jsプロジェクトでも<Suspense>を使って、遅延がちなコンポーネントをラップすることから始めてみませんか？ 小さな一歩からでも、PPRがもたらす次世代のWebパフォーマンスをきっと実感できるはずです。Next.js 16と共に、より速く、より快適なWebの世界を構築していきましょう。

はじめに

「Reactのデータフェッチといえば、useEffectとuseStateを使って、クライアントサイドでAPIを叩くのが当たり前。」 もしあなたがまだそう考えているなら、この記事はあなたの常識を覆すことになるかもしれません。

Next.js 13のApp Routerと共に本格的に導入されたReact Server Components（RSC）は、Reactアプリケーションのアーキテクチャ、特にデータフェッチの方法を根本から変えようとしています。もはや、すべてのコンポーネントがブラウザ上で動くわけではありません。サーバーでレンダリングを完結させ、クライアントにはインタラクティブなUIの部品だけを送る、という新しい時代が到来したのです。

しかし、この大きなパラダイムシフトは、多くの開発者に新たな問いを突きつけています。

• 「Server ComponentとClient Componentは、具体的にどう使い分ければいいの？」
• 「"use client"はどこに書くのが正解？」
• 「useEffectでのデータフェッチは、もう時代遅れなの？」
• 「SWRやReact Query（TanStack Query）はもう不要になる？」

この記事では、そんな疑問を抱えるあなたのために、React Server Componentsの核心を解き明かし、次世代のReact開発におけるベストプラクティスを徹底的に解説します。この記事を読み終える頃には、あなたはRSCを自信を持って使いこなし、より高速で、より効率的なWebアプリケーションを構築するための確かな知識を手にしていることでしょう。

なぜRSCは登場したのか？ 従来のReact開発が抱えていた課題

React Server Componentsがなぜこれほど注目されているのかを理解するためには、まず従来のクライアントサイドレンダリング（CSR）やサーバーサイドレンダリング（SSR）が抱えていた課題を振り返る必要があります。

課題1: クライアントサイドでのデータフェッチの限界

SPA（Single Page Application）の普及以降、React開発の主流はクライアントサイドでのデータフェッチでした。しかし、このアプローチにはいくつかの構造的な問題が存在します。

ネットワークウォーターフォール問題

コンポーネントのレンダリングが完了してから、useEffect内でデータフェッチを開始するため、親コンポーネントのデータ取得が終わらないと子コンポーネントのデータ取得が始まらない、といった連鎖的な遅延（ウォーターフォール）が発生しがちでした。これにより、ページの表示完了までに時間がかかっていました。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// 典型的なウォーターフォール
function ProfilePage() {
  const { user } = useUser(); // 1回目のAPIコール

  // userが取得できてから、次のコンポーネントがレンダリングされる
  return user ? <UserDetails userId={user.id} /> : <Spinner />;
}

function UserDetails({ userId }) {
  const { posts } = usePosts(userId); // 2回目のAPIコール
  // ...
}

バンドルサイズの肥大化

データフェッチのためのライブラリ（axios, SWRなど）、状態管理ロジック、データ整形ロジックなど、すべてがJavaScriptバンドルに含まれ、クライアントに送信されます。アプリケーションが複雑になるほどバンドルサイズは増大し、初期ロード時間（Initial Load Time）を悪化させる大きな要因となっていました。

セキュリティリスク

APIキーやデータベースへの接続情報など、本来サーバーサイドに留めておくべき機密情報を、クライアントサイドのコードから（直接的でなくとも）扱わざるを得ないケースがありました。これにより、情報漏洩のリスクが高まります。

課題2: SSR/SSGの限界

これらの課題を解決するためにSSR（Server-Side Rendering）やSSG（Static-Site Generation）が登場しましたが、これらにもまた別の限界がありました。

• SSRの課題: サーバーでページ全体のHTMLを生成するため初期表示は高速ですが、JavaScriptがダウンロードされ、ハイドレーションが完了するまでページはインタラクティブになりません。また、データフェッチが完了するまでHTMLの生成がブロックされるため、一部のデータ取得が遅いとページ全体の表示が遅れてしまいます。
• SSGの課題: ビルド時にすべてのページを生成するため非常に高速ですが、動的なデータやユーザー固有のコンテンツを表示するには不向きでした。

これらの課題を解決し、「サーバーのパワーを最大限に活用しつつ、クライアントの豊かなインタラクティビティも損なわない」という、両者の"いいとこ取り"を目指して生まれたのが、React Server Componentsなのです。

RSCの核心: Server ComponentとClient Componentの徹底解説

RSCの最も重要な概念は、コンポーネントを「サーバーで実行されるもの」と「クライアントで実行されるもの」に明確に分離したことです。Next.jsのApp Routerでは、すべてのコンポーネントはデフォルトでServer Componentとして扱われます。

Server Component (デフォルト)

Server Componentは、その名の通りサーバーサイドでのみレンダリングされるコンポーネントです。

特徴:

• useState, useEffect, useContextなどのフックや、onClickなどのイベントハンドラは使用できません。
• ブラウザAPI（window, localStorageなど）にアクセスできません。
• async/awaitを直接使用して、データフェッチや非同期処理を行えます。
• データベースやファイルシステムなど、サーバーサイドのリソースに直接アクセスできます。
• レンダリングされても、そのJavaScriptコードはクライアントのバンドルに含まれません。

Server Componentの最大の利点は、データソースの近くでコンポーネントをレンダリングできることです。これにより、データフェッチのレイテンシーを最小限に抑え、必要なデータだけをコンポーネントに埋め込んでクライアントに送信できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// app/posts/page.tsx (Server Component)
import db from '@/lib/db'; // サーバーサイドのDBクライアント

async function getPosts() {
  // サーバー上で直接データベースにクエリを発行
  const posts = await db.post.findMany();
  return posts;
}

export default async function PostsPage() {
  // コンポーネント自体を非同期関数にできる
  const posts = await getPosts();

  return (
    <main>
      <h1>All Posts</h1>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </main>
  );
}

このコードでは、APIエンドポイントを介さずに直接データベースからデータを取得しています。また、このコンポーネントのロジックはクライアントに送られないため、バンドルサイズはゼロです。

Client Component

Client Componentは、従来のReactコンポーネントと同じように、クライアント（ブラウザ）でレンダリングされ、インタラクティブな動作を担当します。

特徴:

• ファイルの先頭に"use client";というディレクティブを記述する必要があります。
• useState, useEffectなどのフックを使用して、状態管理や副作用を扱えます。
• onClick, onChangeなどのイベントハンドラを定義できます。
• ブラウザAPIにアクセスできます。

"use client"は、単なるマーカーではありません。これは、Server ComponentとClient Componentの境界線を定義する重要な役割を果たします。"use client"が書かれたファイルからインポートされるすべてのコンポーネントも、自動的にClient Componentとして扱われます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// components/Counter.tsx (Client Component)
"use client";

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

使い分けの基本フロー

では、具体的にどう使い分ければ良いのでしょうか。以下のフローチャートを参考に判断するのがおすすめです。

graph TD
    A[コンポーネント開発開始] --> B{インタラクティブな要素は必要？<br>(onClick, onChangeなど)};
    B -- Yes --> C[Client Component<br>("use client" を使用)];
    B -- No --> D{状態管理やライフサイクルフックは必要？<br>(useState, useEffectなど)};
    D -- Yes --> C;
    D -- No --> E{ブラウザ専用APIは必要？<br>(window, localStorageなど)};
    E -- Yes --> C;
    E -- No --> F[Server Component<br>(デフォルトのまま)];

基本原則は、「可能な限りServer Componentを使い、インタラクティブ性が必要な部分だけをClient Componentとして切り出す」ことです。

RSC時代のデータフェッチ戦略

RSCの導入により、データフェッチの考え方は大きく変わりました。クライアントでのuseEffectに頼るのではなく、サーバーでデータを取得することが第一の選択肢となります。

基本戦略: データフェッチはServer Componentで行う

Server Component内では、async/awaitを使って、まるでNode.jsのスクリプトを書くかのようにシンプルにデータをフェッチできます。

Next.jsは、標準のfetch APIを拡張しており、きめ細やかなキャッシュ戦略を可能にしています。

• 静的データフェッチ (SSG相当): デフォルトの動作。ビルド時にデータを取得し、キャッシュします。

  1 2 3 4

  // キャッシュを強制（デフォルト） fetch('https://...'); // または明示的に fetch('https://...', { cache: 'force-cache' });

• 再検証 (ISR相当): 指定した時間（秒）が経過すると、次にリクエストがあった際にバックグラウンドでデータを再取得します。

  1 2	// 60秒ごとにデータを再検証 fetch('https://...', { next: { revalidate: 60 } });

• 動的データフェッチ (SSR相当): リクエストごとに常に最新のデータを取得します。

  1 2	// キャッシュを利用しない fetch('https://...', { cache: 'no-store' });

これにより、getStaticPropsやgetServerSidePropsといったNext.jsの旧来のAPIは不要になり、コンポーネント内でデータ要件を完結させることができます。

パターン1: Server Componentでデータをフェッチし、Client ComponentにPropsで渡す

これは最も基本的で強力なパターンです。データの取得と表示ロジックはServer Componentに任せ、ユーザーインタラクションが必要な部分だけをClient Componentとして分離します。

例: 記事一覧と、各記事の「いいね」ボタン

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

// app/blog/page.tsx (Server Component)
import LikeButton from '@/components/LikeButton';
import { getPosts } from '@/lib/posts';

export default async function BlogPage() {
  const posts = await getPosts(); // サーバーで全記事データを取得

  return (
    <div>
      <h1>Blog</h1>
      {posts.map((post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.content}</p>
          {/* インタラクティブな部分だけClient Componentに分離 */}
          {/* 初期データはPropsとして渡す */}
          <LikeButton postId={post.id} initialLikes={post.likes} />
        </article>
      ))}
    </div>
  );
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// components/LikeButton.tsx (Client Component)
"use client";

import { useState } from 'react';
import { incrementLikes } from '@/app/actions'; // Server Actionを利用

export default function LikeButton({ postId, initialLikes }) {
  const [likes, setLikes] = useState(initialLikes);
  const [isPending, startTransition] = useTransition();

  const handleClick = () => {
    startTransition(async () => {
      // サーバー側の関数を直接呼び出してDBを更新
      const newLikes = await incrementLikes(postId);
      setLikes(newLikes);
    });
  };

  return (
    <button onClick={handleClick} disabled={isPending}>
      👍 {likes} {isPending ? '...' : ''}
    </button>
  );
}

この構成により、以下のメリットが生まれます。

• 記事一覧のデータ取得はサーバーで完結し、クライアントのバンドルサイズを圧迫しない。
• インタラクティブなLikeButtonのみがClient Componentとなり、JavaScriptのロード量を最小限に抑える。
• initialLikesをPropsで渡すことで、ハイドレーション後も初期状態が正しく表示される。

パターン2: Server ComponentをClient Componentに埋め込む (children props)

Client Componentの中に、静的なコンテンツとしてServer Componentを配置したい場合があります。これはchildren propsを活用することで実現できます。これにより、Client Componentの島（Island）の中に、サーバーでレンダリングされたコンテンツの穴（Hole）を作ることができます。

例: タブ切り替えUI（Client）と、各タブのコンテンツ（Server）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// components/TabContainer.tsx (Client Component)
"use client";

import { useState } from 'react';

export default function TabContainer({ tabs }) {
  const [activeTab, setActiveTab] = useState(0);

  return (
    <div>
      <div role="tablist">
        {tabs.map((tab, index) => (
          <button
            key={tab.label}
            role="tab"
            onClick={() => setActiveTab(index)}
          >
            {tab.label}
          </button>
        ))}
      </div>
      <div role="tabpanel">
        {/* childrenとして渡されたServer Componentがここに表示される */}
        {tabs[activeTab].content}
      </div>
    </div>
  );
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// app/dashboard/page.tsx (Server Component)
import TabContainer from '@/components/TabContainer';
import UserProfile from '@/components/UserProfile'; // Server Component
import AnalyticsData from '@/components/AnalyticsData'; // Server Component

// これらのコンポーネントは重いデータフェッチを行うと仮定
async function UserProfile() { /* ... */ }
async function AnalyticsData() { /* ... */ }

export default function DashboardPage() {
  const tabs = [
    { label: 'Profile', content: <UserProfile /> },
    { label: 'Analytics', content: <AnalyticsData /> }
  ];

  return (
    <main>
      <h1>Dashboard</h1>
      {/* Client ComponentにServer ComponentをPropsとして渡す */}
      <TabContainer tabs={tabs} />
    </main>
  );
}

このパターンでは、タブの切り替えという状態管理はクライアントで行いつつ、各タブの中身はサーバーで完全にレンダリングされます。これにより、初期表示時に不要なタブのコンテンツまでクライアントに送られることがなくなり、パフォーマンスが向上します。

パターン3: クライアントサイドでのデータフェッチが依然として有効な場合

RSCが強力だからといって、クライアントサイドでのデータフェッチが完全になくなるわけではありません。SWRやTanStack Query (旧React Query) は、特定のユースケースにおいて依然として非常に有効です。

主なユースケース:

• ユーザーの操作に頻繁に反応するデータ: 検索ボックスのサジェスト機能、無限スクロール、頻繁に更新されるダッシュボードなど。
• クライアントの状態に依存するデータ: 認証状態（ログインしているユーザーの情報など）に基づいて取得するデータ。
• 複雑なキャッシュ戦略やミューテーション管理: オプティミスティックUIアップデートなど、高度なUI/UXを実現したい場合。

RSCは初期ロードのパフォーマンス最適化に絶大な効果を発揮しますが、ロード後のクライアント上でのリッチなデータインタラクションは、これらのライブラリが得意とする領域です。RSCとクライアントデータフェッチライブラリは、対立するものではなく、共存し補完し合う関係と捉えるのが正解です。

現場で使える実践的なTips

Tip 1: "use client"はできるだけ末端（Leaf）のコンポーネントに設定する

"use client"は境界線であり、一度宣言されるとその配下のすべてのコンポーネントがClient Componentになります。そのため、できるだけコンポーネントツリーの末端、つまり本当にインタラクティブ性が必要な最小単位のコンポーネントに設定することが重要です。

悪い例: ページ全体をClient Componentにしてしまう

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// app/dashboard/layout.tsx
"use client"; // ← アンチパターン！

import Header from '@/components/Header'; // Client Componentになる
import Sidebar from '@/components/Sidebar'; // Client Componentになる
import MainContent from '@/components/MainContent'; // Client Componentになる

export default function DashboardLayout({ children }) {
  // ...
}

良い例: インタラクティブな部分だけを分離する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

// app/dashboard/layout.tsx (Server Component)
import UserMenu from '@/components/UserMenu'; // Client Component
import Sidebar from '@/components/Sidebar'; // Server Component
import MainContent from '@/components/MainContent'; // Server Component

export default function DashboardLayout({ children }) {
  return (
    <div>
      <header>
        <nav>...</nav>
        <UserMenu /> {/* インタラクティブな部分だけがClient Component */}
      </header>
      <Sidebar />
      <MainContent>{children}</MainContent>
    </div>
  );
}

Tip 2: Server Actionsでデータ更新をシンプルにする

フォーム送信やデータ更新（Mutation）のために、もはやAPIエンドポイントを自前で用意する必要はありません。Server Actionsを使えば、サーバーサイドで実行される関数をクライアントコンポーネントから直接、安全に呼び出せます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// app/actions.ts
"use server"; // ファイルの先頭に記述

import db from '@/lib/db';
import { revalidatePath } from 'next/cache';

export async function addPost(formData: FormData) {
  const title = formData.get('title') as string;
  
  await db.post.create({ data: { title } });

  // 関連するページのキャッシュをクリアして再描画をトリガー
  revalidatePath('/posts');
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// components/AddPostForm.tsx (Client Component)
"use client";

import { addPost } from '@/app/actions';

export default function AddPostForm() {
  return (
    <form action={addPost}>
      <input type="text" name="title" required />
      <button type="submit">Add Post</button>
    </form>
  );
}

formタグのaction属性に関数を渡すだけで、フォーム送信時にサーバー上のaddPost関数が実行されます。APIルートの作成、fetchの呼び出し、ローディング状態の管理といった定型的なコードが大幅に削減され、開発体験が飛躍的に向上します。

Tip 3: SuspenseとStreamingで体感速度を向上させる

ページの特定の部分でデータ取得に時間がかかる場合でも、Suspenseを使うことで他の部分の表示をブロックすることなく、UIを段階的に表示（Streaming）できます。

Next.jsでは、loading.tsxという規約ファイルを使うことで、これを簡単に実現できます。

例: 記事詳細ページとコメント欄 記事本体はすぐに表示したいが、コメントの読み込みには時間がかかるとします。

app/
└ posts/
  └ [slug]/
    ├ page.tsx      // 記事本体を表示するServer Component
    └ loading.tsx   // page.tsxのレンダリング中に表示されるUI

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// app/posts/[slug]/page.tsx
import PostContent from '@/components/PostContent';
import Comments from '@/components/Comments';
import { Suspense } from 'react';

export default function PostPage({ params }) {
  return (
    <div>
      {/* 記事本体はすぐにレンダリングされる */}
      <PostContent slug={params.slug} />

      {/* コメントはデータ取得が終わるまでフォールバックUIを表示 */}
      <Suspense fallback={<p>Loading comments...</p>}>
        <Comments slug={params.slug} />
      </Suspense>
    </div>
  );
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// components/Comments.tsx (Server Component)
async function getComments(slug) {
  await new Promise(resolve => setTimeout(resolve, 2000)); // 意図的に遅延
  // ...
}

export default async function Comments({ slug }) {
  const comments = await getComments(slug);
  // ...
}

この構成により、ユーザーはまず記事本体を読み始めることができ、その間にコメントが非同期でロードされます。これにより、実際の読み込み時間が同じでも、体感速度は劇的に改善されます。

まとめ

React Server Componentsは、単なる新機能ではなく、Reactアプリケーションの設計思想そのものを変える、大きなパラダイムシフトです。

本記事の要点をまとめます。

1. デフォルトはServer Component: すべてのコンポーネントはサーバーで実行されるものと考え、インタラクティブ性が必要な最小単位だけを"use client"でClient Componentに切り出す。
2. データフェッチの主戦場はサーバーへ: async/awaitをServer Componentで直接使い、データソースの近くでデータを取得する。useEffectでのデータフェッチは、クライアントでのインタラクションに応じた動的な取得に限定される。
3. "use client"は境界線: このディレクティブは、サーバーとクライアントの世界を分ける重要な役割を果たす。ツリーのなるべく末端に配置することを心がける。
4. パターンを使い分ける: 「Propsでデータを渡す」「childrenでコンポーネントを埋め込む」といった基本的なパターンをマスターし、コンポーネントの責務を明確に分離する。
5. エコシステムを賢く利用する: Server Actionsでミューテーションを簡略化し、SuspenseとStreamingでUXを向上させる。SWRやTanStack Queryも、依然としてクライアントサイドでの複雑なデータ管理に有効。

最初は戸惑うことも多いかもしれません。しかし、このサーバーとクライアントの新しい協調モデルを理解し、使いこなすことができれば、これまで以上に高速で、スケーラブルで、そして開発者体験の良いアプリケーションを構築できることは間違いありません。

さあ、今日からあなたのReact開発に、Server Componentsの力を取り入れてみませんか？

はじめに

テキストベースのチャットボットや文章生成AIが当たり前になった今、開発者の関心は次のステージ、すなわち「マルチモーダルAI」へと急速にシフトしています。ユーザーがアップロードした画像を認識して説明を生成したり、音声で指示を受け付けたりするアプリケーションは、もはやSFの世界の話ではありません。

しかし、このようなリッチな体験を実現しようとすると、開発者は多くの課題に直面します。

• 「画像データをどうやってフロントエンドからサーバーに送ればいいんだろう？」
• 「OpenAI、Google、Anthropic… 各社で微妙に違うマルチモーダルAPIの仕様を吸収するのが大変だ」
• 「Base64エンコード？ファイルアップロード？ストリーミングUIとどう組み合わせるの？」

これらの悩みは、AIアプリケーションのアイデアを形にする上で大きな障壁となっていました。

そんな中、フロントエンド開発者にとっての福音とも言えるVercel AI SDKが、待望のマルチモーダル対応を大幅に強化しました。このアップデートにより、これまで複雑だった画像や音声データのハンドリングが驚くほどシンプルになり、開発者は本来注力すべきアプリケーションのコアロジックとユーザー体験の向上に集中できるようになったのです。

この記事では、プロの技術ブロガーとして、Vercel AI SDKの最新機能を徹底的に掘り下げます。具体的なコード例を交えながら、画像や音声といった非テキストデータを活用した次世代AIアプリケーションを、いかに効率的に、そして高速に構築できるかをご紹介します。この記事を読み終える頃には、あなたもマルチモーダルAIアプリ開発の最前線に立つ準備が整っているはずです。

なぜ今、マルチモーダルAIとVercel AI SDKなのか？

この新機能の詳細に入る前に、なぜこのトピックがこれほどまでに重要なのか、その背景と課題を整理しておきましょう。

マルチモーダルAIの台頭とユーザー体験の革新

GPT-4oやClaude 3、Geminiといった最新のLLM（大規模言語モデル）は、テキストだけでなく画像、音声、さらには動画までも理解・生成する能力（マルチモーダル能力）を獲得しています。これにより、可能になるアプリケーションの幅は飛躍的に広がりました。

• ビジュアルQ&A: ホワイトボードの写真を撮って「この図をコードに書き起こして」と指示する。
• デザイン支援: Webサイトのスクリーンショットをアップロードして「このデザインの改善点を指摘して」と依頼する。
• 音声アシスタント: 音声で「今日の天気と、それに合った服装を提案して」と話しかける。

これらはほんの一例ですが、人間が普段行うような、複数の感覚情報を組み合わせたコミュニケーションをAIと行えるようになることで、ユーザー体験はより直感的で豊かなものになります。このトレンドに適応できないアプリケーションは、近い将来、時代遅れと見なされてしまうかもしれません。

従来の実装における複雑さという「壁」

アイデアはあっても、それを実現する道のりは平坦ではありませんでした。マルチモーダルAIアプリを自前で実装しようとすると、以下のような複雑な処理に直面します。

1. フロントエンドでのデータハンドリング:

   • ユーザーが選択した画像や音声ファイルをJavaScriptで読み込み、適切な形式（多くはBase64文字列やバイナリデータ）に変換する必要があります。
   • 大きなファイルの場合、UIがフリーズしないよう非同期処理を適切に管理しなければなりません。

2. クライアント・サーバー間のデータ転送:

   • 変換したデータをHTTPリクエストのボディに含めてサーバーに送信します。JSONペイロードにBase64文字列を埋め込むのが一般的ですが、データサイズが大きくなりがちで、リクエストサイズの制限に抵触する可能性もあります。

3. バックエンドでのAPI差異の吸収:

   • サーバーサイドでは、受け取ったデータを各AIベンダーのAPI仕様に合わせて再度整形する必要があります。例えば、OpenAIのAPIとAnthropicのAPIでは、画像データの渡し方が異なります。
   • 新しいモデルが登場したり、API仕様が変更されたりするたびに、コードの修正を迫られます。

4. ストリーミングとの組み合わせ:

   • AIの応答をリアルタイムでユーザーに表示するストリーミングは、現代のAIチャットUIには不可欠です。しかし、これにマルチモーダルな入力を組み合わせると、状態管理やエラーハンドリングはさらに複雑になります。

これらの課題は、開発者から多くの時間とエネルギーを奪い、イノベーションの足かせとなっていました。

Vercel AI SDKがもたらす解決策

Vercel AI SDKは、まさにこの「壁」を打ち破るために生まれました。ReactやNext.jsといったモダンなWebフレームワークと深く統合し、AIアプリケーション開発における定型的な処理を美しく抽象化してくれます。

今回のマルチモーダル対応強化により、SDKは以下の価値を提供します。

• 統一されたAPI: どのLLMを使うかに関わらず、同じような記述で画像やテキストを送信できます。
• シンプルなデータ形式: フロントエンドでファイルを読み込んだら、あとはSDKの関数に渡すだけ。面倒なエンコードやリクエストの組み立てはSDKが裏側で処理してくれます。
• Generative UIとのシームレスな統合: streamUI や generateUI といった革新的な機能と組み合わせることで、「画像を入力として、動的なUIコンポーネントを生成・ストリーミングする」といった高度なアプリケーションも驚くほど簡単に実装できます。

次章から、この強力なSDKを使って、実際にマルチモーダルアプリケーションを構築していく手順を詳しく見ていきましょう。

具体的な実装解説：画像と音声でAIと対話する

ここからは、Vercel AI SDKを使ってマルチモーダルアプリケーションを構築する具体的な方法を、コードを交えてステップバイステップで解説します。今回はNext.js App Routerを使った実装を例に進めます。

1. 環境構築

まずは、Next.jsプロジェクトをセットアップし、必要なパッケージをインストールします。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Next.jsプロジェクトの作成
npx create-next-app@latest vercel-ai-multimodal-app

# プロジェクトディレクトリに移動
cd vercel-ai-multimodal-app

# Vercel AI SDKと関連パッケージのインストール
npm install ai zod-to-json-schema

# UIのためにshadcn/uiなどを入れておくと便利です
# (本記事では省略しますが、実際の開発では推奨します)
npx shadcn-ui@latest init
npx shadcn-ui@latest add input button

次に、プロジェクトのルートに .env.local ファイルを作成し、使用するAIモデルのAPIキーを設定します。今回はOpenAIのGPT-4oを例にします。

OPENAI_API_KEY="sk-..."

2. 基本的な画像入力チャットの実装

最も基本的なユースケースとして、「ユーザーが画像をアップロードし、その画像に関する質問をテキストで入力できるチャットUI」を実装します。

データの流れる仕組み

実装に入る前に、全体のデータの流れを把握しておきましょう。

sequenceDiagram
    participant Client as ブラウザ (Reactコンポーネント)
    participant Server as Next.jsサーバー (Server Action)
    participant OpenAI as OpenAI API (GPT-4o)

    Client->>Client: ユーザーが画像とテキストを入力
    Client->>Client: 画像をBase64文字列に変換
    Client->>Server: Server Actionを呼び出し (テキスト + Base64画像)
    Server->>OpenAI: Vercel AI SDKを使いAPIリクエストを整形・送信
    OpenAI-->>Server: テキスト応答をストリーミング
    Server-->>Client: 応答をクライアントにストリーミング
    Client->>Client: ストリーミングされたテキストをリアルタイムで表示

Vercel AI SDKは、特にサーバーとOpenAI API間の通信を劇的に簡素化してくれます。

サーバーサイド：Server Actionの作成

まず、AIとの通信を担うサーバーサイドのロジックを app/actions.ts に実装します。React Server Components（RSC）とServer Actionsの組み合わせは、Vercel AI SDKと非常に相性が良いです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

'use server';

import { streamUI } from 'ai/rsc';
import { openai } from '@ai-sdk/openai';
import { ReactNode } from 'react';
import { z } from 'zod';

// APIキーを環境変数から取得
// Next.jsでは、`process.env`で自動的に.env.localを読み込みます
// const openaiApiKey = process.env.OPENAI_API_KEY;

export async function continueConversation(
  history: { role: 'user' | 'assistant'; content: string; data?: any }[],
): Promise<{
  messages: { role: 'user' | 'assistant'; content: string; data?: any }[];
  ui: ReactNode;
}> {
  const { messages, ui } = await streamUI({
    model: openai('gpt-4o'), // 最新のマルチモーダルモデルを指定
    // system: 'あなたは優秀なアシスタントです。', // 必要に応じてシステムプロンプトを設定
    messages: history.map((message) => ({
      role: message.role,
      content: message.content,
      // dataプロパティに画像データが含まれている場合、それをcontentに含める
      ...(message.data && {
        content: [
          { type: 'text', text: message.content },
          ...message.data.images.map((img: string) => ({
            type: 'image',
            image: Buffer.from(img.split(',')[1], 'base64'),
          })),
        ],
      }),
    })),
    text: ({ content, done }) => {
      if (done) {
        // AIの応答が完了したら、そのメッセージを履歴に追加
        history.push({ role: 'assistant', content });
      }
      return <div>{content}</div>;
    },
    // 将来的にUIコンポーネントを生成する場合のスキーマ
    // zodスキーマを定義しておくことで、構造化されたUIを生成可能
    // schema: z.object({
    //   ...
    // })
  });

  return {
    messages: history,
    ui,
  };
}

ポイント解説:

• 'use server': このファイルがサーバーサイドでのみ実行されることを示します。
• streamUI: Vercel AI SDKのコア機能の一つ。テキストだけでなく、Reactコンポーネント（UI）そのものをストリーミングできます。
• openai('gpt-4o'): 使用するモデルを簡単に指定できます。@ai-sdk/anthropic や @ai-sdk/google を使えば、ClaudeやGeminiも同様に扱えます。
• messagesの整形: history 配列をループし、AI SDKが要求する形式に変換しています。
• マルチモーダル入力: ユーザーメッセージに data.images（Base64文字列の配列）が含まれている場合、content をテキストと画像のオブジェクト配列に変換しています。{ type: 'image', image: ... } という形式が重要です。SDKはこの形式を解釈し、モデルに適切に送信してくれます。
• Base64からBufferへ: image プロパティには、Base64文字列からデコードしたBufferを渡しています。これにより、SDKが効率的にデータを処理できます。

クライアントサイド：チャットUIの実装

次に、ユーザーが操作するフロントエンド部分を app/page.tsx に実装します。

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

'use client';

import { useState, useRef, ChangeEvent, FormEvent, ReactNode } from 'react';
import { useActions, useUIState } from 'ai/rsc';
import { continueConversation } from './actions';
import Image from 'next/image';

// メッセージの型定義
type Message = {
  role: 'user' | 'assistant';
  content: string;
  // 画像データを保持するためのオプショナルなプロパティ
  data?: {
    images?: string[];
  };
};

export default function Home() {
  const [inputValue, setInputValue] = useState('');
  const [messages, setMessages] = useUIState<typeof continueConversation>([]);
  const { continueConversation: performAction } = useActions<typeof continueConversation>();

  const [imageFiles, setImageFiles] = useState<string[]>([]);
  const fileInputRef = useRef<HTMLInputElement>(null);

  // ファイルが選択されたときのハンドラ
  const handleFileChange = (e: ChangeEvent<HTMLInputElement>) => {
    const files = e.target.files;
    if (!files) return;

    const newImageFiles: string[] = [];
    Array.from(files).forEach((file) => {
      const reader = new FileReader();
      reader.onloadend = () => {
        if (typeof reader.result === 'string') {
          newImageFiles.push(reader.result);
          // すべてのファイルの読み込みが終わったらstateを更新
          if (newImageFiles.length === files.length) {
            setImageFiles((prev) => [...prev, ...newImageFiles]);
          }
        }
      };
      reader.readAsDataURL(file); // ファイルをBase64文字列として読み込む
    });
  };

  // フォーム送信時のハンドラ
  const handleSubmit = async (e: FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    if (!inputValue && imageFiles.length === 0) return;

    // 現在の入力値と画像でユーザーメッセージを作成
    const userMessage: Message = {
      role: 'user',
      content: inputValue,
      data: {
        images: imageFiles,
      },
    };

    // UIStateを更新し、アクションを実行
    setMessages((currentMessages) => [...currentMessages, userMessage]);
    
    const response = await performAction([
        ...messages,
        userMessage,
      ]);
    
    setMessages(response.messages);

    // 送信後に入力と画像をクリア
    setInputValue('');
    setImageFiles([]);
    if (fileInputRef.current) {
        fileInputRef.current.value = '';
    }
  };

  return (
    <div className="flex flex-col w-full max-w-2xl mx-auto py-8">
      {/* メッセージ表示エリア */}
      <div className="flex-grow mb-4 space-y-4">
        {messages.map((msg, index) => (
          <div key={index} className={`flex ${msg.role === 'user' ? 'justify-end' : 'justify-start'}`}>
            <div className={`p-3 rounded-lg ${msg.role === 'user' ? 'bg-blue-500 text-white' : 'bg-gray-200'}`}>
              {/* ユーザーメッセージの画像プレビュー */}
              {msg.data?.images?.map((img, i) => (
                  <Image key={i} src={img} alt="uploaded image" width={200} height={200} className="rounded-md mb-2" />
              ))}
              {/* テキストコンテンツ */}
              <p>{typeof msg.content === 'string' ? msg.content : "UI Component"}</p>
            </div>
          </div>
        ))}
      </div>

      {/* 入力フォーム */}
      <form onSubmit={handleSubmit} className="flex flex-col gap-2">
        {/* 画像プレビュー */}
        {imageFiles.length > 0 && (
          <div className="flex gap-2 p-2 border rounded-md">
            {imageFiles.map((src, index) => (
              <Image key={index} src={src} alt="preview" width={80} height={80} className="rounded-md object-cover" />
            ))}
          </div>
        )}
        <div className='flex gap-2'>
            <input type="file" accept="image/*" multiple onChange={handleFileChange} ref={fileInputRef} className="flex-1 p-2 border rounded-md"/>
            <input
                type="text"
                value={inputValue}
                onChange={(e) => setInputValue(e.target.value)}
                placeholder="画像について質問..."
                className="flex-[3] p-2 border rounded-md"
            />
            <button type="submit" className="px-4 py-2 bg-blue-600 text-white rounded-md">
                送信
            </button>
        </div>
      </form>
    </div>
  );
}

ポイント解説:

• 'use client': このコンポーネントがクライアントサイドで動作することを示します。
• useUIState と useActions: Vercel AI SDKが提供するフックです。useUIState はUIの状態（この場合はメッセージ履歴）を管理し、useActions はServer Actionをクライアントサイドから安全に呼び出すためのものです。
• ファイルハンドリング:
  1. <input type="file"> でユーザーに画像を選択させます。multiple 属性で複数選択を許可しています。
  2. handleFileChange 内で FileReader APIを使用し、選択されたファイルを Base64形式のデータURL に変換しています。これが、サーバーに送信する画像の形式になります。
  3. useState (imageFiles)でBase64文字列を保持し、プレビュー表示に利用します。
• データ送信:
  1. handleSubmit で、テキスト入力 (inputValue) と画像 (imageFiles) をまとめて userMessage オブジェクトを作成します。
  2. performAction（実体は continueConversation）を呼び出す際に、この userMessage を含んだメッセージ履歴を渡します。
  3. サーバーサイド（actions.ts）では、この userMessage.data.images を見て、マルチモーダル入力として処理します。

これで、画像とテキストを同時に送信できる基本的なチャットアプリケーションが完成しました。驚くほどボイラープレートコードが少ないことにお気づきでしょうか。SDKが面倒な部分をすべて引き受けてくれているのです。

3. 応用編：音声入力のハンドリング

Vercel AI SDKは直接的な音声処理機能は持ちませんが、他のライブラリと組み合わせることで、音声入力アプリケーションも簡単に構築できます。ここでは「ユーザーが録音した音声を文字起こしし、そのテキストをLLMに送信する」という流れを考えます。

データの流れる仕組み

sequenceDiagram
    participant Client as ブラウザ (Reactコンポーネント)
    participant Server as Next.jsサーバー (API Route)
    participant OpenAI_STT as OpenAI Whisper API
    participant OpenAI_LLM as OpenAI LLM API (GPT-4o)

    Client->>Client: ユーザーがマイクで録音
    Client->>Server: 音声ファイル (Blob) をAPI Routeに送信
    Server->>OpenAI_STT: Whisper APIに音声データを転送し文字起こしを依頼
    OpenAI_STT-->>Server: 文字起こしされたテキストを返す
    Server->>OpenAI_LLM: Vercel AI SDKを使い、テキストをLLMに送信
    OpenAI_LLM-->>Server: テキスト応答をストリーミング
    Server-->>Client: 応答をクライアントにストリーミング
    Client->>Client: 応答をリアルタイムで表示

このシナリオでは、音声データを一旦サーバーに送り、Whisper APIなどで文字起こしするステップが加わります。

実装のポイント

1. クライアントサイド:

   • react-media-recorder や react-use-microphone といったライブラリを使って、ブラウザのマイクから音声を録音し、Blobオブジェクトとして取得します。
   • 取得したBlobを FormData に詰めて、Next.jsのAPI Routeに fetch でPOSTします。

2. サーバーサイド（API Route）:

   • API Route (例: app/api/transcribe/route.ts) でリクエストを受け取ります。
   • formidable のようなライブラリを使って、マルチパートフォームデータをパースし、音声ファイルを取得します。
   • 取得した音声ファイルをOpenAIのWhisper APIに送信して文字起こしをします。これには openai ライブラリの audio.transcriptions.create メソッドが使えます。
   • 文字起こししたテキストを、前述の continueConversation のようなServer Actionに渡すか、あるいはこのAPI Route内で直接Vercel AI SDKの streamText などを使ってLLMに送信します。

このように、Vercel AI SDKはエコシステムの他のツールと柔軟に組み合わせることができ、音声という異なるモダリティもシームレスにAIアプリケーションのワークフローに組み込むことが可能です。

メリットとデメリット（あるいは注意点）

Vercel AI SDKのマルチモーダル対応は非常に強力ですが、万能ではありません。そのメリットと、利用する上で注意すべき点を整理します。

メリット

• 圧倒的な開発速度: 面倒なAPI仕様の差異吸収、データエンコード、ストリーミング制御などをSDKが担うため、開発者は数行のコードでマルチモーダル機能を実装できます。
• コードの可読性と保守性: 宣言的なAPI設計により、何をしているかが分かりやすいコードになります。モデルを openai('gpt-4o') から anthropic('claude-3-opus-20240229') に変更するのも一行で済みます。
• Generative UIとの相性抜群: 画像を入力として、その説明文だけでなく、関連商品を表示するカードコンポーネントや、分析結果を可視化するグラフコンポーネントなどを動的に生成・ストリーミングできます。これは他のライブラリにはない大きな強みです。
• Vercelプラットフォームとの親和性: Vercelへのデプロイがスムーズなのはもちろん、Serverless Functionsの実行時間制限やペイロードサイズの制限などを考慮した設計になっています。

デメリット・注意点

• 抽象化のトレードオフ: SDKは便利な反面、内部実装を隠蔽します。非常にニッチなAPIパラメータを使いたい場合や、特殊な認証フローを実装したい場合には、SDKの提供するインターフェースでは対応できない可能性があります。
• クライアントサイドのパフォーマンス: 特に画像をBase64にエンコードする処理は、画像のサイズが大きいとクライアントのCPUとメモリを消費します。ユーザー体験を損なわないよう、後述するTipsで紹介するような前処理が重要になります。
• コスト管理の徹底: マルチモーダルAPIは、テキストのみのAPIに比べて高価になる傾向があります。特に高解像度の画像を頻繁に送信すると、API利用料が想定外に膨れ上がる可能性があります。入力画像の解像度や枚数に制限を設けるなどの対策が不可欠です。

現場で使える実践的なTips

最後に、開発現場でマルチモーダルAIアプリを運用していく上で役立つ、より実践的なテクニックをいくつかご紹介します。

1. クライアントサイドでの画像圧縮

ユーザーがアップロードする画像は、スマートフォンで撮影した高解像度の写真など、数MBに及ぶことがよくあります。これをそのままBase64にエンコードして送信すると、以下の問題が発生します。

• アップロードに時間がかかり、ユーザー体験が悪い。
• APIリクエストのペイロードが大きくなりすぎる。
• LLMのAPIコストが高くなる（多くのモデルは画像解像度に応じてコストが変動する）。

そこで、browser-image-compressionのようなライブラリを使い、画像をサーバーに送信する前にクライアントサイドで圧縮・リサイズするのが非常に効果的です。

1

npm install browser-image-compression

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

import imageCompression from 'browser-image-compression';

const handleFileChange = async (e: ChangeEvent<HTMLInputElement>) => {
  const file = e.target.files?.[0];
  if (!file) return;

  console.log(`Original file size: ${file.size / 1024 / 1024} MB`);

  const options = {
    maxSizeMB: 1, // 最大ファイルサイズ
    maxWidthOrHeight: 1024, // 最大幅・高さ
    useWebWorker: true, // Web Workerを使ってUIスレッドをブロックしない
  };

  try {
    const compressedFile = await imageCompression(file, options);
    console.log(`Compressed file size: ${compressedFile.size / 1024 / 1024} MB`);

    // この圧縮されたファイルをFileReaderでBase64に変換して送信する
    // ...
  } catch (error) {
    console.error(error);
  }
};

この一手間を加えるだけで、アプリケーションのパフォーマンスと運用コストを劇的に改善できます。

2. 堅牢なUI/UXの構築

AIの応答には時間がかかるため、ユーザーが「今、何が起きているのか」を理解できるようなUI/UXが不可欠です。

• ローディング状態の明示: APIにリクエストを送信してから応答が返ってくるまでの間、ボタンを無効化したり、スピナーやスケルトンスクリーンを表示したりしましょう。
• 画像の即時プレビュー: URL.createObjectURL() を使えば、ファイルを読み込みながらすぐにプレビューを表示できます。ユーザーは自分が正しい画像をアップロードしたことを即座に確認できます。
• エラーハンドリングとフィードバック: ファイル形式が不正な場合、ファイルサイズが大きすぎる場合、API通信に失敗した場合など、想定されるエラーを適切にキャッチし、「〜のため処理に失敗しました。もう一度お試しください」といった具体的なメッセージをユーザーに提示しましょう。

3. コストとセキュリティの考慮

• 入力制限: ユーザーが一度にアップロードできる画像の枚数や、合計ファイルサイズに上限を設けましょう。これにより、意図しない高額なAPI利用を防ぎます。
• 認証とレートリミット: 誰でも無制限にAPIを呼び出せる状態は非常に危険です。NextAuth.jsなどでユーザー認証を導入し、ユーザーごとにAPI呼び出し回数の制限（レートリミット）を設けることを強く推奨します。

まとめ

本記事では、Vercel AI SDKの強力な新機能であるマルチモーダル対応について、その重要性から具体的な実装方法、そして実践的なTipsまでを網羅的に解説しました。

Vercel AI SDKは、これまで専門家でなければ困難だったマルチモーダルAIアプリケーションの開発を、フロントエンド開発者にとって身近なものへと変えてくれました。煩雑なデータハンドリングやAPIの差異を抽象化することで、私たちはより創造的な作業、すなわち「AIを使ってどのような新しいユーザー体験を創造するか」に集中することができます。

画像認識チャット、デザインレビューツール、ビジュアル検索エンジンなど、あなたのアイデアを形にするためのツールは、かつてないほどシンプルで強力なものになりました。もちろん、コスト管理やパフォーマンスチューニングといった実践的な課題は残りますが、それらを乗り越えた先には、ユーザーをあっと驚かせるような革新的なアプリケーションが待っています。

テキストの時代から、画像、音声、そしてUIが融合するマルチモーダルの時代へ。Vercel AI SDKは、その大きな潮流に乗るための、最も確かな羅針盤となるでしょう。さあ、あなたもこの新しいツールを手に、次世代のAIアプリケーション開発に挑戦してみてはいかがでしょうか。