tRPCは『TS同士の対話』を最短化する
tRPCは2021年に登場したTypeScript専用のRPCフレームワークで、サーバ側の関数定義をクライアント側で『そのまま型として利用できる』点が革新的です。OpenAPIスキーマ・GraphQL Schema・Protocol Buffers・コード生成、これら全てが不要。Next.js・Remix・SvelteKit等のフルスタックTSアプリで急速に標準ポジションを取り、Airbnb・Linear・Vercel等の採用事例が公開されています。
tRPC採用を検討すべき5つのシグナル
- フロントとバックがTypeScriptで書かれている（モノレポ前提）
- OpenAPIスキーマの管理が手間で『型がズレる』事故が頻発
- GraphQLはオーバーキル・コード生成は遅い
- 新規プロジェクトでスピード重視・型安全重視
- 外部APIを公開する必要がない（内部フロント←→バックのみ）
REST/GraphQL/tRPC実務比較
REST: 外部公開API・多言語クライアント前提なら最善。型安全は別途OpenAPIで管理。
GraphQL: 複数クライアント・複雑なデータ取得要件があれば強い。学習コスト・運用負荷あり。
tRPC: フロント・バック両方TSで完結する内部APIに最適。コード共有が完璧、ただしTS以外のクライアントとは相性悪い。
tRPC実装の基本パターン
(1) Router定義: router({ userById: publicProcedure.input(z.string()).query(({ input }) => db.user.find(input)) })
(2) Client生成: const trpc = createTRPCClient<AppRouter>({ url })でサーバの型を全て継承
(3) Query/Mutation: React/Vue/Svelte等のクライアントからtrpc.userById.useQuery('id')のように呼ぶ
(4) ミドルウェア: 認証・ロギング・レート制限を関数チェーンで実装
(5) Subscription: WebSocket経由のリアルタイム購読も対応
tRPCが向かないケース
(1) 外部公開API: REST/GraphQLにすべき。tRPCは内部API専用と割り切る
(2) マイクロサービス間通信: gRPC・Kafkaなどメッセージング基盤が適切
(3) モバイルアプリ（Native）: Swift/Kotlinとの型共有はできない
(4) GraphQL生態系への依存: Apollo・Relayの周辺ツール資産があるなら無理に置き換える価値薄い
(5) 大規模チーム: フロント・バック分業が明確な大規模チームではOpenAPIの方が役割分担と相性が良いことも
本番運用の3つの注意点
- バンドルサイズ: 全Routerをクライアントに型として継承すると、巨大プロジェクトでビルドが遅くなる。Router分割を意識
- エラーハンドリング: tRPC独自のエラー型を理解しないとフロントでハマる。
TRPCErrorでステータスコード設計 - テスト: Routerは普通の関数として直接テスト可能だが、ミドルウェアの組み合わせテストは要計画
30日学習プラン
- 1週目: Next.js App Router + tRPC v11でCRUDアプリを構築
- 2週目: Zodバリデーション・Cookie認証・エラー型設計を習得
- 3週目: React Queryとの連携・楽観的更新・キャッシュ無効化パターン
- 4週目: 本番デプロイ・テスト・モニタリングまでの一連の運用を試す
関連リンク
API設計の選択肢は API設計選び方、GraphQL実装は GraphQL実践、Next.jsとの組み合わせは Next.js深掘り を参照してください。Honoとの比較は Hono深掘り もどうぞ。