tRPCとは｜型安全なAPIの仕組み・使い方・GraphQL/RESTとの違い

tRPCとは｜TypeScript前提の型安全API

tRPCとは「TypeScript Remote Procedure Call」の略称です。サーバー側で書いた関数を、クライアントからまるでローカル関数のように呼び出せる仕組みで、その呼び出しに完全な型安全性が備わります。前提となるTypeScriptの基礎については、TypeScriptとは？JavaScriptとの違いや年収、将来性を参照してください。

tRPCの定義と主な特徴

tRPCの中核は「型情報の共有」にあります。サーバー側で定義したエンドポイント（procedureと呼びます）の入出力の型が、TypeScriptの型推論だけでクライアント側に伝わる仕組みです。

主な特徴は次のとおりです。

• コード生成不要：GraphQLのようなスキーマ定義や、OpenAPIのようなIDLは不要

• ランタイム依存が少ない：一般に、型生成物を大量に持ち込む構成に比べると、クライアント側のバンドルへの影響を抑えやすい

• フレームワーク中立：Next.js・Express・Fastify・Node.js・Bunなど複数のアダプタに対応

• バッチング／サブスクリプション対応：複数リクエストの自動集約やリアルタイム通信も可能

公式ドキュメント（tRPC Docs）では「end-to-end typesafe APIs made easy」と表現されており、フロントエンドとバックエンドの境目に立ちがちな「型ズレ」問題を、TypeScript一本で解消するのが狙いです。

生まれた背景と2021年以降の普及

tRPCは2021年にAlex Johansson氏（コミュニティではKATTとして知られる）が公開したOSSです。Next.js・TypeScript・React Queryを組み合わせたフルスタックアプリで「型ズレをなくしたい」という要望が起点になっています。

その後、Vercelを中心としたNext.jsコミュニティで採用が広がり、T3スタック（Next.js＋TypeScript＋Prisma＋tRPC＋Tailwind＋NextAuth）と呼ばれる構成の一部として知られるようになりました。本記事執筆時点では、TypeScriptフルスタック開発の有力な選択肢として扱われる場面が増えています。

「型が自動で伝わる」体験の意味

従来のREST APIやGraphQLでは、サーバー側の変更をクライアント側に反映するために、次のような手順が必要でした。

• OpenAPIスキーマから型を再生成する

• GraphQLスキーマからコードジェネレータで型を作り直す

• 手書きの型定義ファイルを更新する

tRPCではこの中間工程がなくなります。サーバー側のprocedureの引数や戻り値を変更した瞬間に、その型がクライアント側の呼び出し箇所でエラーとして検出されます。ビルドを回すよりも前に、IDE上で赤線が引かれるイメージです。

tRPCに関するミニFAQ

Q. tRPCはフレームワークですか？

A. いいえ、ライブラリです。Next.jsやExpressといったフレームワークの上に載せて使います。

Q. サーバーサイドはTypeScript必須ですか？

A. はい。tRPCは型情報を共有する設計なので、サーバーとクライアントの両方がTypeScriptで書かれていることが前提になります。

tRPCの仕組み｜Router・Procedure・Clientの3構造

tRPCは大きく3つの構成要素で成り立ちます。この3つを頭に入れれば、公式ドキュメントの解説も迷いにくくなります。

サーバー側：appRouterとprocedure

サーバー側の中心は「Router」と「Procedure」です。

• Router：エンドポイントの集合。関連するprocedureをネストしてまとめる単位

• Procedure：個別のエンドポイント。読み取り用のquery（GET相当）か、書き込み用のmutation（POST相当）で定義する

• appRouter：アプリ全体のルート。ここで定義した型が、そのままクライアント型のソースになります

公式クイックスタート（tRPC Quickstart）では、TypeScript 5.7.2以上と、strictモードでの利用が推奨されています。バックエンドをExpressやNestJSで組む場合の使い分けについては、NestJSとは？Express.jsとの違い・特徴・案件単価も参考になります。

クライアント側：AppRouter型のimportで型伝播

クライアント側では、サーバー側で定義したAppRouter型の型情報だけをimportします。実装コードは持ち込みません。この「型だけ持ってくる」設計が、tRPCの安全性と軽さの両立を実現している要点です。

具体的には、サーバー側で「export type AppRouter = typeof appRouter」のように型をexportし、クライアント側では「import type { AppRouter }」のように型だけを取り込みます。実装本体はサーバーに残り、クライアント側のバンドルにはサーバーコードが混入しません。

httpBatchLinkとリクエストのバッチング

tRPCクライアントは、複数のprocedure呼び出しを1つのHTTPリクエストにまとめるhttpBatchLinkを標準提供しています。1つの画面で複数のuseQueryが同時に走るReactアプリでは、ネットワーク往復を抑える効果があります。

Zod・Valibot・Yupなどによるバリデーション

tRPCそれ自体はバリデーションライブラリを持ちません。実装では、Zodなどを入力バリデータとして渡し、入力値の型チェックとランタイムバリデーションを兼ねる書き方が一般的です。公式のサンプルコードでもZodが例示されています。

Zod以外に、Valibot・Yup・ArkTypeなど複数のバリデータをサポートしており、既存プロジェクトで使っている物に合わせられます。

仕組みに関するミニFAQ

Q. 通信プロトコルは独自ですか？

A. いいえ、標準的なHTTPとJSONです。バイナリではないため、ブラウザの開発者ツールでレスポンスをそのまま確認できます。

Q. WebSocketには対応していますか？

A. はい。wsLinkと呼ばれるリンク実装を使うと、サブスクリプションをWebSocket経由で扱えます。

tRPCとGraphQL・REST・gRPCの違い

APIの選択肢は年々増えています。tRPCの位置を理解するには、他のAPI設計と比較するのが早道です。

REST APIとの違い

REST APIはHTTPメソッド（GET・POST・PUT・DELETE）とURLでリソースを操作する、最も広く使われるAPI設計です。詳しくは既存記事REST APIとは｜設計原則・HTTPメソッド・GraphQL/gRPCとの違いで解説しています。

RESTと比較したtRPCの違いは次のとおりです。

• 型情報の扱い：RESTは仕様書（OpenAPIなど）を介して型を共有するのが一般的。tRPCはTypeScriptの型推論だけで共有

• サーバー側言語の自由度：RESTは任意の言語で実装できる。tRPCはTypeScript限定

• 公開APIとしての適性：RESTは公開・外部連携に向く。tRPCは内部API向き

• キャッシュ：RESTはHTTPキャッシュとの相性が良い。tRPCも活用可能だが、GET相当のqueryに限る

GraphQLとの違い

GraphQLはクライアントが必要なフィールドだけをリクエストできる、柔軟なAPIクエリ言語です。詳しくは既存記事GraphQLとは？REST APIとの違い・メリット・案件動向で解説しています。

• スキーマの必要性：GraphQLはSDL（Schema Definition Language）でスキーマを定義。tRPCは不要

• フィールド選択：GraphQLはクライアント側で必要なフィールドを選べる。tRPCはprocedureが返す型そのまま

• 学習コスト：GraphQLはリゾルバ・スキーマ・キャッシュ設計など概念が多い。tRPCはTypeScript経験があれば導入しやすい部類

• クロス言語：GraphQLは多言語対応。tRPCはTypeScript前提

gRPCとの位置関係

gRPCはProtocol Buffersを使ったバイナリ通信の高性能RPCです。マイクロサービス間通信で採用されることが多く、名前は似ていますがtRPCとは想定用途が異なります。

• プロトコル：gRPCはHTTP/2＋Protobuf。tRPCはHTTP＋JSON

• 想定用途：gRPCはサービス間通信・低遅延要件。tRPCはフルスタックのフロントエンドとバックエンドの橋渡し

• 言語：gRPCは多言語。tRPCはTypeScript

4種比較表（このページの独自整理）

主要APIプロトコルを、フリーランスエンジニアが案件で判断しやすい観点で並べました。

上記は「案件でこれを選ぶ／選ばない」の判断に直結する観点だけを絞ってあります。より詳細な技術特性は各プロトコルの公式ドキュメントを確認してください。

比較に関するミニFAQ

Q. tRPCはGraphQLの後継ですか？

A. 後継というより、想定用途がやや重なる別物です。GraphQLは公開APIや複雑なフィールド選択に強く、tRPCは内部APIの型安全とDXに強みがあります。両方を併用する構成もあります。

tRPCが向くケース・向かないケース

技術選定の判断は「向く／向かない」を先に切り分けると迷いが減ります。以下のチェックリストは、案件参画前に確認するとミスマッチを防げます。

向くケース

• TypeScriptモノレポ：フロントとバックエンドが同じリポジトリで、両方TypeScriptで書かれている

• Next.jsのBFF層：フロントエンドの近くに置く軽量なAPI層として使う

• 小〜中規模の内部API：社内ツール・管理画面・SaaSダッシュボードなど、クライアントを絞れる場面

• PoC・スタートアップの初期プロダクト：短期間で機能を出したい局面

• 既存のReact＋TanStack Query構成に載せる場合：フックの延長で使えるため学習コストが低い

向かないケース

• 公開API：外部の開発者に提供するAPIはRESTかGraphQLが無難

• 多言語クライアント：モバイル（SwiftやKotlin）や他サービス（PythonやGoなど）から呼ばれる場合

• モバイルアプリ単独：iOSやAndroid単体で使うAPIはRESTのほうがエコシステムが整っている

• サービス間通信：低遅延要件が強いマイクロサービスはgRPCが有力

• クライアントとサーバーのデプロイサイクルが独立している場合：型の同期が難しくなり、tRPCの利点が薄れる

導入判断チェックリスト（このページの独自整理）

案件のスタック情報を受け取ったら、次の順序でチェックしてみてください。3つ以上「はい」ならtRPC適性が高いと判断できます。

1. サーバー側はTypeScriptで書かれていますか？

2. クライアントもTypeScript（Reactなど）ですか？

3. 同一リポジトリまたは型共有可能なパッケージ構成ですか？

4. 公開API（外部開発者に提供）ではなく、社内向け・自社アプリ向けですか？

5. 主なクライアントはブラウザ＋SPAですか？（モバイル・多言語クライアントが主軸ではない）

6. TanStack QueryなどのReactデータフェッチライブラリを既に使っていますか？

目安として、3つ以上「はい」ならtRPCを前向きに検討しやすい構成です。1〜2つなら、GraphQLや素のREST＋型生成のほうが安定するケースが多くなります。最終的には案件の要件・チーム構成で判断してください。

向き不向きに関するミニFAQ

Q. モバイルアプリも将来的に作る可能性がある場合はどうすべきですか？

A. 選択肢は2つあります。一つはtRPCをWeb向けにだけ使い、モバイル向けには別途RESTを用意する構成。もう一つは最初からRESTかGraphQLに寄せる構成です。要件次第ですが、モバイルが主軸になりそうな案件では後者が無難です。

Next.jsでtRPCを使う最小手順

ここでは実装コードの詳細ではなく、構成の全体像を掴むための最小手順を示します。実際のコードは公式クイックスタート（tRPC Quickstart）とNext.js統合ドキュメントを合わせて参照してください。

依存関係と最小ファイル構成

Next.js（App Router）＋tRPC v11の代表的な最小構成では、次のパッケージを導入します。実装方式によっては追加パッケージが必要になる場合があります。

• @trpc/server

• @trpc/client

• @trpc/react-query

• @tanstack/react-query

• zod（バリデーションで使う場合）

ファイル構成の最小例は次のとおりです。

• server/trpc.ts：tRPC初期化ファイル

• server/routers/_app.ts：appRouterの定義ファイル

• app/api/trpc/[trpc]/route.ts：Route HandlerによるAPIエントリ

• lib/trpc.ts：クライアント側の呼び出しユーティリティ

循環参照を避けるため、tRPC初期化ファイルとappRouter定義ファイルは分けます。これは実務でよくある詰まりポイントの一つです。基盤となるNode.jsの実行環境や、Express.jsなどのアダプタとの関係も整理しておくと、後段の実装がスムーズになります。

appRouter定義とprocedureの書き方の要点

procedureはquery（読み取り）かmutation（書き込み）で定義します。入力バリデータとしてZodスキーマを渡すと、入力値の型とランタイム検証が同時にかかります。

• publicProcedure：認証不要のprocedure

• protectedProcedure：認証必須のprocedure（middlewareで実装）

• 入力バリデーション：Zodスキーマをinput指定で受ける

• ハンドラ本体：queryかmutationで処理を書く

クライアントからのuseQuery呼び出しの要点

クライアント側では、tRPCのproxyオブジェクト経由でprocedureを辿り、TanStack Queryのフックとして呼び出します。感覚としてはTanStack QueryのuseQueryとほぼ同じですが、引数と戻り値の型がサーバー側から自動で伝わる点が異なります。

• useQuery：データ取得

• useMutation：更新系

• useInfiniteQuery：ページング

• useSubscription：WebSocketサブスクリプション

段階的導入（既存Next.jsに部分導入する場合）

既存プロジェクトへの導入は「一部の画面から始める」パターンが現実的です。

1. tRPC用のRoute Handlerを追加し、tRPCサーバーを設置する

2. 新しい機能のAPIだけをtRPC procedureとして書く

3. 既存のREST的なエンドポイントは残したまま並行運用する

4. 段階的にtRPCへ寄せていく

いきなり全書き換えを狙う必要はありません。REST APIとの併用は公式でも想定された使い方です。

導入手順に関するミニFAQ

Q. Pages Routerでも使えますか？

A. 使えます。v10系まではPages Router向けの書き方が主流でした。v11でApp Routerにも対応しており、既存プロジェクトの構成に合わせて選べます。

実務でよくある詰まりポイントと対処

導入直後にぶつかりがちな箇所を、公式ドキュメントには載っていない実務目線でまとめます。参画してすぐに詰まると印象が悪くなるため、事前に押さえておきたい部分です。

循環参照エラー：tRPC初期化とappRouter定義を分ける

initTRPCの初期化と、appRouterの定義を同じファイルに書くと、認証middlewareやprotectedProcedureの実装で循環参照が起きます。公式のクイックスタートでも「トラブル回避のためファイルを分けるのが推奨」と明記されています。

• 初期化用ファイル：initTRPCの呼び出しと、publicProcedure・protectedProcedureのexport

• appRouter用ファイル：routerでprocedureを組み立てるexport

• 別ファイル同士で相互importが発生しないよう注意する

認証・middlewareの設計

認証はuseを重ねるmiddlewareパターンが基本です。

• ログイン状態をコンテキストに載せてprocedureに渡す

• protectedProcedureは、コンテキスト上のユーザー情報が存在しない場合にUNAUTHORIZEDエラーを投げる

• ロールベース制御（管理者専用など）は、さらに別のmiddlewareを重ねる

Next.js＋NextAuthの組み合わせでは、サーバー側でセッションを取得し、tRPCのcreateContextでコンテキストに詰める書き方が定着しています。

エラーハンドリングとバリデーション

tRPCは独自のTRPCErrorを持ちます。codeフィールド（HTTPステータスに相当）とmessageを指定してthrowすると、クライアント側で型付きのエラーハンドリングができます。

• BAD_REQUEST：入力バリデーション失敗

• UNAUTHORIZED：未認証

• FORBIDDEN：権限不足

• NOT_FOUND：リソース不在

• INTERNAL_SERVER_ERROR：想定外の例外

Zodのバリデーションエラーは自動的にBAD_REQUESTにマッピングされます。フロント側では、エラーオブジェクトからZodのエラー構造を取り出して、フォームに反映する書き方が一般的です。

モバイル対応・外部連携でRESTが必要になったとき

途中で「外部の会社からAPI連携依頼が来た」「モバイルアプリを別チームが作る」といった変化はよくあります。この場合、tRPC procedureをそのまま外に出すのは無理があるため、次のいずれかで対処します。

• 該当エンドポイントだけRESTに切り出す（Next.js Route Handlerで並行実装）

• tRPCのハンドラを直接呼び出すラッパーを用意する（限定用途）

• 外部向けはOpenAPI＋型生成の別レイヤに切り分ける

「あとから外部公開が必要になる可能性がゼロではない」案件では、内部向けだけtRPC、外部向けはREST、という切り分けを設計段階で仕込むと後戻りが少なくなります。

実務ポイントに関するミニFAQ

Q. tRPCとRESTを1つのプロジェクトで混在させても大丈夫ですか？

A. 混在させて問題ありません。Next.jsのAPI RoutesまたはRoute Handlerは、tRPCのハンドラと通常のREST的ハンドラを同居させられます。

tRPCの案件動向とフリーランスエンジニアのキャリア戦略

技術としての魅力とは別に、フリーランス目線では「案件があるか」「どう探すか」が重要です。ここでは公開案件の観測ベースで整理します。

案件数の現状（公開案件ベースの観測）

2026年7月時点で、主要フリーランスエージェント（レバテックフリーランス、Midworks、ITプロパートナーズなど）の公開求人を検索する限りでは、「tRPC」を必須スキルとして単独で掲げる案件はまだ限定的です。実際には次のようなポジションで見かけるケースが多くなっています。

• Next.js＋TypeScriptのフロントエンド・フルスタック案件で、任意スキル欄にtRPCが挙げられる

• スタートアップ・自社SaaS企業のフルスタック案件で、T3スタック採用として明記される

• PrismaやNextAuth、Vercelなどモダンな技術セットの一部として登場する

「tRPC単独」ではなく、TypeScript＋Next.js＋TanStack Queryなどのモダンフルスタック文脈で登場する傾向が中心です。

単価に効くスキル組み合わせ

tRPCそれ自体を武器にするというより、周辺スキルを束ねた「フルスタック性」が単価に効きます。

• TypeScript：土台。フロント・サーバー両方の型安全実装に必須

• Next.js：App Router・Route Handler・Server Actionsまで含めた最新機能

• TanStack Query：データフェッチ・キャッシュ設計

• Prisma：ORMとしての実装力（tRPCの後段でDB操作を書ける）

• NextAuth／Auth.js：認証実装

• VercelやCloudflare Workers：デプロイ・エッジ実行

これらを一貫して扱えると、Next.js系フルスタック案件でスコープが広がり、単価交渉の余地が生まれます。

TypeScriptフリーランスの単価目安と案件の探し方

TypeScriptフリーランスの単価は、経験・スキル・稼働条件で幅があります。首都圏中心の公開業務委託案件（週4〜5日・TypeScript／Next.js系）を主要エージェントで検索した観測ベースの目安では、実務経験3〜5年で月額60〜85万円前後、5年以上でNext.jsやフルスタック領域まで対応できると月額80〜110万円前後の募集が見られる傾向です。地方リモート案件・稼働日数の少ない案件では単価幅が下振れするケースもあります。tRPCを含むモダンスタックの経験は、フルスタック対応力の補強材料として評価されやすく、高単価帯の求人で説明材料になりやすい傾向があります。詳細な相場観は既存記事TypeScriptフリーランスの単価相場と案件の探し方にまとめています。

自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方で整理しています。

案件の探し方の実務ポイント

案件検索の際は、tRPC単独のキーワードだけで探すと母数が少なく感じられます。次の探し方が実務的です。

• 「Next.js」「TypeScript」「フルスタック」で絞り、詳細ページで技術スタックを確認する

• スタートアップ・自社SaaS向け求人を優先的に確認する

• スカウト系サービスでスキル欄にtRPCを登録し、逆引きで見つけてもらう

• 技術ブログやOSS活動でtRPC採用事例を発信し、企業側から声がかかる状態を作る

キャリア戦略に関するミニFAQ

Q. tRPCの経験がまだ浅くても案件に応募できますか？

A. tRPCが必須要件の案件は少ないため、Next.js＋TypeScriptの実務経験が中心的な評価軸になります。tRPCは「使える」レベルであれば加点材料として十分です。

Q. バックエンドが別言語（GoやPythonなど）の案件でもtRPCの知識は活きますか？

A. 直接的には使いません。ただし「型安全なAPIコントラクトを設計する」という発想は他プロトコルにも応用できます。REST＋OpenAPI＋型生成、gRPCなど、他の型安全アプローチと横断的に理解しておくと強いです。

まとめ

tRPCは、TypeScript同士のWebアプリでAPIの型ズレを減らしたいときに有力な選択肢となるライブラリです。Next.js＋TypeScript＋TanStack Queryの構成に最も刺さり、社内向け・自社サービス内のAPI層で強みを発揮します。コード生成やスキーマ定義は不要で、TypeScriptの型推論だけでクライアントとサーバー間の型を共有できます。

要点をあらためて整理します。

• tRPCはTypeScript前提の型安全RPCで、スキーマ定義・コード生成が不要

• サーバー側のAppRouter型をimport typeするだけで、クライアントに型が伝わる

• 向くのはTypeScriptモノレポ・Next.jsのBFF・小〜中規模の内部API

• 公開API・多言語クライアント・モバイル単独ならREST・GraphQLが無難

• 実務ではファイル分割・middleware設計・エラーハンドリングの型付けが押さえどころ

• 案件は「Next.js＋TypeScript＋モダンフルスタック」の中で登場する

次のステップとしては、公式クイックスタートを一度写経し、create-t3-appで生成したテンプレートを触って、自分のプロジェクトに部分導入するのが実務でよく使われるルートです。TypeScriptフリーランスとしての幅を広げる観点でも、押さえておいて損のないスキルセットです。

参照した一次情報

• tRPC 公式ドキュメント

• tRPC Quickstart

• tRPC React Query統合