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

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

ざっくり言うと、tRPC は サーバが書いた TypeScript 型を、クライアントから直接 import して呼び出せる』</strong> ことを最大の売りにした API ライブラリです。 OpenAPI のスキーマ定義や GraphQL の SDL を介さず、<strong> 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』 型を <strong>クライアントが 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 は最も大きな威力を発揮します。 逆に <strong> 外向きの 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 ステータスコードの記事](/articles/representative-http-status-codes-explained) で触れた 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』 以降は安定して使われています。<strong> 設計が割り切られているがゆえに、ライブラリとしての複雑性は小さく、運用上のトラブルは少なめ』というのが現場の評価です。

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

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

Q. Zod は必須ですか？

A. 必須ではないですが、事実上の標準コンビ』 です。Zod を使うと <strong> 入力検証 + 型推論 + 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 通信』</strong> という意味では REST と同等のオーバーヘッドで、バッチング(`httpBatchLink』)』 で複数 procedure をまとめて送ることで、むしろ通信回数を減らせる場面もあります。

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

A. TypeScript と Zod を知っていれば、半日〜1日で書き始められる』</strong> 程度です。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: 公式