← Back to Home

REST APIからの脱却：Next.jsでのtRPCとGraphQLによる型安全なデータフェッチ

#Next.js#TypeScript#Backend#Frontend

Web開発におけるデータ通信の主役といえば、長らく「REST API」でした。 しかし、2026年現在のモダンなTypeScriptエコシステムにおいて、特にフルスタックなフレームワーク（Next.jsなど）を使用する際、REST APIの限界が指摘されるようになっています。

この記事では、なぜREST APIから脱却する動きがあるのか、そしてその代替として強力な**「tRPC」と「GraphQL」**について、実務目線で比較解説します。

tRPC and GraphQL Data Flow

1. REST APIの何が問題なのか？

REST API自体が悪いわけではありません。単純なCRUD（作成、読み取り、更新、削除）を作るには最も手軽です。 しかし、フロントエンドとバックエンドの両方をTypeScriptで書く環境では、以下の問題が顕著になります。

  1. 二重管理の苦痛: バックエンド（例えばNode.js/Express）で定義した型（Userの構造など）を、フロントエンドでもう一度手書きで定義し直す必要があります。
  2. 変更の同期漏れ: バックエンド側でUser型に age プロパティを追加した場合、フロントエンド側の担当者に「API変えたよ」と漏れなく口頭やチャットで伝える必要があります。伝え漏れると「値が来ない」といった実行時エラー（Runtime Error）の温床になります。
  3. オーバーフェッチ/アンダーフェッチ: 「今回はユーザーの名前だけ欲しい」という画面でも、/users/1のエンドポイントを叩くと同じ固定の形（プロフィール画像、住所、等々）の肥大化したデータが全て返ってきがちです。

2. 次世代の選択肢「tRPC」

もし、あなたが「フロントエンドもバックエンドもTypeScriptで書いている（Monorepo構成など）」のであれば、現在最もパワフルな選択肢となるのが tRPC (TypeScript RPC) です。

tRPCの最大の特徴：『エンドツーエンドの型安全』

tRPCを使うと、バックエンドで定義した関数とその戻り値の型が、自動的にフロントエンドに推論（インポート）されます。 スキーマ定義ファイル（.graphqlなど）を書いたり、コード生成ツール（CodeGen）を走らせる必要すらありません。

// --- バックエンド (tRPC Router) ---
import { initTRPC } from '@trpc/server';
import { z } from 'zod'; // バリデーションライブラリ

const t = initTRPC.create();

export const appRouter = t.router({
  // ユーザーを取得する手続き(procedure)
  getUser: t.procedure
    .input(z.object({ id: z.string() })) // 入力にはidが必要
    .query(({ input }) => {
      // DBから取得する疑似コード
      return { id: input.id, name: 'Taro', age: 25 }; 
    }),
});

// フロント側のクライアント用に型だけをエクスポート
export type AppRouter = typeof appRouter; 

// --- フロントエンド (Next.js / React) ---
import { trpc } from '../utils/trpc'; // 上記の型を読み込んだクライアント

export function UserProfile({ id }: { id: string }) {
  // 自動的に入力補完(Autocomplete)が効き、取得するデータの型も保証される！
  const { data, isLoading } = trpc.getUser.useQuery({ id });
  
  if (isLoading) return <p>Loading...</p>;
  
  // もしバックエンドで `age` が削除されたら、エディタ上でここが赤線（コンパイルエラー）になる！
  return <p>{data.name} ({data.age}歳)</p>; 
}

この「APIが変わったら、フロントエンドのエディタ画面ですぐにエラーとして赤線が引かれる」という体験は、一度味わうとREST API＋手書きの型定義には二度と戻れなくなるほどの開発体験（DX）の向上をもたらします。

3. なぜGraphQLも有力な選択肢なのか？

フロントもバックもTypeScriptならtRPCが最強」と言いましたが、世の中すべてのプロジェクトがそうとは限りません。

  • バックエンドが Go、Rust、Java、Ruby な場合
  • サードパーティ（外部の企業など）にAPIを公開したい場合
  • モバイルアプリ（iOS/Android）からも同じAPIを使いたい場合

このような、複数言語・複数プラットフォームが混在する巨大プロジェクトの場合は、言語に依存しない共通のスキーマ言語を持つ GraphQL が依然として圧倒的な強さを誇ります。

GraphQLの特徴

  1. 必要なデータだけを要求できる: フロントエンド側から「IDと名前だけをくれ（年齢等の他のデータは要らない）」とクエリ文を投げるため、モバイル回線のような細い通信環境でのパフォーマンス最適化（オーバーフェッチの防止）に優れています。
  2. 明確なスキーマ: .graphql ファイルが「APIの仕様書」そのものとして機能します。

4. Next.js App Router時代の実装方針

Next.js 13以降で登場した「App Router」と「React Server Components (RSC)」により、データフェッチの考え方がまた少し変わってきました。

サーバーコンポーネント内では、ブラウザを介さずにfetch()を使って直接バックエンドと通信できますし、データベース（Prisma等）に直接アクセスすることも推奨されるようになりました。これにより、tRPCのようなミドルウェアを挟まなくても、サーバーコンポーネント内で直接DBの型を利用するといった「新しい型安全なデータフェッチ」が広がりつつあります。

5. まとめ

2026年のモダン開発環境において、REST APIの採用は小規模プロジェクトかレガシーシステムとの連携に留まりつつあります。フロントとバックの一貫した型安全性を確保することは、大規模になるほどバグの減少と開発スピードの向上に直結します。

  • チーム内でTypeScriptをフル活用できるなら tRPC
  • 複数言語・チームを跨ぐプラットフォームを作るなら GraphQL
  • Next.jsなどのメタフレームワークの機能（Server Components）に乗り換える

自分のチームの技術スタックに合わせ、ぜひ次世代のAPI設計を取り入れてみてください。