tRPC とは何か？TypeScript で型安全な API を作る仕組みと REST / GraphQL との使い分け

tRPC ってよく聞くけど、結局 REST と何が違うの？ GraphQL でいいのでは？ 「モノレポなら使うべき？」 ── TypeScript フルスタックで開発する案件が増えるほど、tRPC の名前は外せない存在になってきました。

ざっくり言うと、tRPC は サーバが書いた TypeScript 型を、クライアントから直接 import して呼び出せる ことを最大の売りにした API ライブラリです。 OpenAPI のスキーマ定義や GraphQL の SDL を介さず、TypeScript の型システムをそのまま API 契約として使う という割り切りで、「型を書く時間 = API 契約を書く時間」 という体験を実現します。

この記事では、2026年5月時点の tRPC を、「何を解決するのか・REST / GraphQL との違い・どう書くのか・どこで効くか・どこでは向かないか」 の順で整理します。

tRPC が解決した問題

「なぜ tRPC が広まったか」 は、フロントエンドエンジニアが 「API 開発のたびに同じ作業をしている」 という不満の歴史を見ると分かります。

tRPC は サーバとクライアントが同じリポジトリ(or モノレポ)にあるなら、TS 型をそのまま共有すればいいじゃないか という、ある意味で開き直った発想で、これらの問題を一気に解消しました。

基本の使い方 — 「Procedure」 と 「Router」

最小例で雰囲気を確認します。

// server/router.ts
import { initTRPC } from '@trpc/server';
import { z } from 'zod';

const t = initTRPC.create();

export const appRouter = t.router({
  user: t.router({
    byId: t.procedure
      .input(z.object({ id: z.string() }))
      .query(async ({ input }) => {
        return await db.user.findUnique({ where: { id: input.id } });
      }),
    create: t.procedure
      .input(z.object({ name: z.string(), email: z.string().email() }))
      .mutation(async ({ input }) => {
        return await db.user.create({ data: input });
      }),
  }),
});

export type AppRouter = typeof appRouter;

クライアント側はこうなります。

// client.ts
import { createTRPCProxyClient, httpBatchLink } from '@trpc/client';
import type { AppRouter } from '../server/router';

const trpc = createTRPCProxyClient<AppRouter>({
  links: [httpBatchLink({ url: '/trpc' })],
});

const user = await trpc.user.byId.query({ id: '42' });
const created = await trpc.user.create.mutate({ name: 'Alice', email: 'a@example.com' });

ポイント:

• サーバの 「AppRouter」 型を クライアントが 「import type」 するだけ で、利用できるエンドポイント、引数、戻り値の型が完全に揃う。
• 「query」 は GET 系の参照、「mutation」 は POST/PUT/DELETE 系の更新、と概念的に分ける。
• 入力検証は Zod をそのまま使う(Yup / Valibot 等もアダプタ経由で可)。

「スキーマ生成のコマンドを叩く必要がない」 のが、地味だが体験を大きく変える点です。

REST / GraphQL との比較

3つを並べると、それぞれの立ち位置が見えやすくなります。

要点は 「 API を誰が・何で呼ぶか」 で選ぶ:

• 外部に公開、複数言語クライアント → REST
• 大規模、複雑なクエリ要件、複数チーム → GraphQL
• 内製、サーバもクライアントも TypeScript → tRPC

「どれが優れているか」 ではなく、「案件の境界条件にどれが合うか」 で決める道具立てです。

React Query との統合

tRPC が普段使いで快適に感じるもう1つの理由が、React Query(TanStack Query)との深い統合 です。

// 通常版 React Query を意識せずに使える
const { data, isLoading, error } = trpc.user.byId.useQuery({ id: '42' });

const create = trpc.user.create.useMutation({
  onSuccess: () => {
    trpc.user.byId.invalidate({ id: '42' });
  },
});

「fetch を直接書く / axios を呼ぶ」 が、「React Query のフック + 型安全な引数 + 自動キャッシュ無効化」 に置き換わります。 キャッシュ、リトライ、optimistic update など React Query の機能はそのまま使え、「データ取得の標準的なコードベース」 が一気に手に入る、というのが現場の体感です。

どこで効くか — tRPC が活きる案件

実務で 「tRPC を選んでよかった」 となる構成は、おおむね決まっています。

「完全に内向きの TS スタック」 のときに、tRPC は最も大きな威力を発揮します。 逆に 「 外向きの API として公開する」 場合は、後述のように tRPC ではなく REST / GraphQL の方が自然 です。

どこでは向かないか — tRPC の限界

「流行っているから tRPC」 で選ぶと、後で痛い目を見る場面もあります。

「内向き TS なら tRPC、外向きや複雑な要件なら別」 という判断軸を持っておくと、選定で迷いが減ります。

認証・認可・ミドルウェア

tRPC は procedure ミドルウェア という仕組みで、認証・認可・ロギング・レート制御などを共通化できます。

const isAuthed = t.middleware(async ({ ctx, next }) => {
  if (!ctx.user) throw new Error('UNAUTHORIZED');
  return next({ ctx: { ...ctx, user: ctx.user } });
});

export const protectedProcedure = t.procedure.use(isAuthed);

// 使うとき
export const appRouter = t.router({
  me: protectedProcedure.query(({ ctx }) => ctx.user),
});

「保護したい procedure は protectedProcedure を使う」 と決めるだけで、認証チェックが一律にかかる、という設計です。 HTTP ステータスコードの記事 で触れた 「401 / 403 を返す境界」 を、tRPC では `エラーコード(「UNAUTHORIZED」 「FORBIDDEN」)」 として表現できる仕組みも持っています。

モノレポでの典型構成

tRPC が真価を発揮するのは、モノレポでの構成です。

「API の追加 = サーバの router にメソッドを増やす」 だけで、クライアント側は即座に補完が効く ─ という体験が、現代の TS フルスタックにおける tRPC の魅力の核心です。

AI 時代の tRPC 観

AI を組み込んだ TS アプリでも、tRPC の役割は重要になっています。

「小さなチームが AI で爆速に開発する」 文脈で、tRPC は事実上のスタンダードのひとつになっています。 「内向き / TypeScript / モノレポ」 が揃った瞬間に、tRPC の合理性は最大化される、というのが2026年現在の景色です。

tRPC に関するよくある質問

Q. tRPC は本番運用に耐えますか？

A. 十分耐えています。Vercel・Cal.com・PlanetScale など多くの著名プロダクトで本番採用実績があり、「v10」 以降は安定して使われています。設計が割り切られているがゆえに、ライブラリとしての複雑性は小さく、運用上のトラブルは少なめというのが現場の評価です。

Q. REST / GraphQL を捨てて全部 tRPC にすべきですか？

A. いいえ。内向きは tRPC、外向き API は REST / GraphQL の使い分けが現実的です。同じ会社の中で、「社内ツールは tRPC、公開 API は REST」 という二刀流の構成も普通にあります。

Q. Zod は必須ですか？

A. 必須ではないですが、「事実上の標準コンビ」 です。Zod を使うと 「 入力検証 + 型推論 + tRPC procedure の型」 が全部1つの定義で済む ので、これを採用しないのはむしろ手間が増えやすいです。Valibot などのアダプタも存在します。

Q. SSR / Next.js での扱いはどうなりますか？

A. tRPC は Next.js を一級サポート しています。「@trpc/next」 で SSR / SSG / RSC との統合を提供し、「サーバコンポーネントから直接 procedure を呼ぶ」 ような構成も可能です。Next.js + tRPC は現在の TS フルスタック開発で頻出するセットです。

Q. パフォーマンスは REST より劣りますか？

A. 大差ありません。HTTP の上で動く JSON 通信 という意味では REST と同等のオーバーヘッドで、`バッチング(「httpBatchLink」)」 で複数 procedure をまとめて送ることで、むしろ通信回数を減らせる場面もあります。

Q. tRPC の学習コストはどのくらい？

A. TypeScript と Zod を知っていれば、半日〜1日で書き始められる 程度です。「procedure / router / client / React Query」 の4語と、「query / mutation / input / output」 の4語を押さえれば、最初のエンドポイントは作れます。

Q. tRPC を採用すると、技術ロックインは厳しいですか？

A. ある程度はあります。「tRPC で書いた procedure を REST にエクスポート」 するアダプタもありますが、設計の根っこは TS の型共有前提なので、「完全に別技術に移行する」 ときは書き直しに近い作業が発生します。これも 「内向きの内製案件で使う」 という前提なら問題になりにくい、というのが多くの判断です。

参考リンク

• tRPC: 公式サイト
• tRPC: GitHub
• TanStack Query(React Query): 公式
• Zod: 公式
• Next.js: App Router
• T3 Stack: 公式
• Turborepo: 公式