tRPC（ティー・アール・ピー・シー）は、TypeScript製のフルスタックアプリケーション向けに設計された、型安全なRPCフレームワークです。2020年にAlex Johansson氏が公開して以降、Next.jsやNuxt系プロジェクトを中心に急速に普及し、現在ではフロントエンドとバックエンドをTypeScriptで一気通貫に開発するスタイルの代表格となっています。もっとも特徴的なのは「型をネットワーク越しに共有する」という発想で、サーバ側で定義したルーターの型情報をクライアントへimportするだけで、リクエスト・レスポンスの型がIDE上で完全に補完される体験を実現しています。OpenAPIや独自スキーマ定義言語を持たず、TypeScriptの型システムそのものをAPI契約として扱う設計が、開発速度と品質を両立させる新しいアプローチとして注目されています。
この記事の目次
- tRPCを支える3つの中核要素
- tRPCを用いた開発フロー
- tRPC採用時のチェックポイント
- tRPCとREST／GraphQLの比較
- まとめ
tRPCを支える3つの中核要素
tRPCの中心となるのは「Router」と「Procedure」という2つの概念です。サーバ側ではinitTRPC.create()で生成したビルダーを使い、router({...}) の中に複数のProcedureを宣言します。Procedureはquery（取得系）またはmutation（更新系）として定義し、Zodなどのバリデーションスキーマで入力を厳密に検査したうえで、TypeScript関数として実装します。
クライアント側はサーバ側のRouterの「型だけ」をimportし、createTRPCProxyClientやReact Queryと統合したcreateTRPCReactを使って呼び出します。trpc.user.byId.query({ id }) のようにフィールドアクセス感覚でAPIを呼び出せ、引数の型・戻り値の型はサーバ側の実装から完全に推論されます。型情報のみがビルド時に共有されるためバンドルサイズは肥大せず、IDEのリアルタイム補完・型エラー検出が強力に効きます。
tRPCを用いた開発フロー
tRPCを用いた典型的なフローは、まずモノレポやNext.jsプロジェクト内でサーバ側のappRouterを定義するところから始まります。次に、appRouterの型だけをexport type AppRouter = typeof appRouterとして公開し、クライアント側ではimport type { AppRouter } from "..."のように取り込んでクライアントを初期化します。実際のRouter実装はクライアントに送られず、型情報のみがコンパイル時に共有される構成です。
ReactアプリケーションではcreateTRPCReactを使うことで、各Procedureが自動的にReact Queryのhookとして公開されます。trpc.user.byId.useQuery({ id }) のようにuseQuery／useMutationを呼ぶだけで、キャッシュ管理・ローディング状態・エラー処理・楽観的更新といったReact Queryの全機能が手に入ります。Server Side Rendering（SSR）にも対応しており、Next.jsとの統合ではgetServerSidePropsの中でデータをプリフェッチして、クライアント側のサスペンスを抑える設計も容易に組めます。
tRPC採用時のチェックポイント
tRPCを採用するうえで最も重要な前提は、フロントとバックエンドの両方がTypeScriptで実装され、できれば同一リポジトリ（モノレポ）で管理されていることです。型情報の共有はビルド時のimportに依存するため、別言語のクライアント（Python・Goなど）や外部の第三者にAPIを公開する用途には基本的に不向きで、その場合はOpenAPI＋RESTの方が向いています。
Procedureの入力検証はZod・Yup・Valibotなどのバリデーションライブラリと組み合わせて行うのが定石で、サーバ側だけでなくクライアント側にも同じスキーマが流通するため、フォーム検証との統合もしやすくなります。また、Next.jsのEdge Runtimeやサーバレス環境を利用する場合、tRPCのバージョンとアダプタが対応しているかを確認する必要があります。全体としては、社内向けのフルスタックTypeScriptアプリで最も価値を発揮する技術選定となります。
tRPCとREST／GraphQLの比較
tRPCとREST／GraphQLは、思想と適用領域が大きく異なります。REST（OpenAPI）やGraphQL（SDL）は、JSONやスキーマ言語を介してAPIの契約を言語非依存に表現するため、TypeScript以外のクライアントや第三者の利用者にも提供可能な「広く開かれた契約」を作るのに適しています。公開APIや、フロント／バックでスタックが異なるシステムでは引き続きこれらが第一選択肢です。
一方tRPCは、契約を言語非依存に表現することを諦める代わりに、TypeScriptの型システムそのものをAPI契約として活用し、スキーマ生成の中間工程を完全になくします。結果として、社内利用のフルスタックTypeScriptアプリでは「API設計」「クライアント生成」「型同期」といった工程をほぼ意識せずに開発できる体験が得られます。公開APIにはRESTやGraphQL、社内のTypeScript閉じた世界にはtRPC、という形で適材適所に使い分けるのが現実的な指針となります。
まとめ
tRPCは、TypeScriptの型システムを「APIの契約」としてそのまま使うという発想で、フロントとバックエンドの開発体験を劇的に改善するフレームワークです。スキーマ生成や中間ファイルを必要とせず、React Queryと統合したフックを通じてクライアント実装を圧倒的にシンプルにできます。言語非依存性が必要な公開API向けではありませんが、TypeScriptで閉じたフルスタック開発においては、もっとも生産性の高い選択肢のひとつとして急速に存在感を増している技術です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント