API設計の選択肢が増えた
2026年のWeb開発では、APIの設計パターンに複数の選択肢がある。RESTが依然として主流だが、GraphQLとtRPCがそれぞれ異なるユースケースで存在感を示している。
本記事では、3つのアプローチを公平に比較し、プロジェクトの要件に応じた選び方を解説する。
REST — 安定性と互換性の王道
RESTful APIは、HTTPメソッド（GET/POST/PUT/DELETE）とURLでリソースを操作するアーキテクチャスタイルだ。
強み
- 学習コストが低い: HTTPの基本を知っていれば理解できる
- キャッシュが容易: HTTP標準のキャッシュヘッダーがそのまま使える
- ツールエコシステムが充実: Swagger/OpenAPI、Postman、各言語のHTTPクライアント
- マイクロサービス間通信に適する: サービス間の疎結合を保ちやすい
弱み
- Over-fetching/Under-fetching: エンドポイントが返すデータの粒度が固定されがち
- N+1リクエスト問題: 関連データを取得するために複数回のリクエストが必要
- 型安全性がない: レスポンスの型はドキュメント頼み（OpenAPIで緩和可能）
向いているケース
- 公開API（サードパーティ向け）
- マイクロサービス間通信
- シンプルなCRUD操作中心のアプリケーション
GraphQL — 柔軟なデータ取得
GraphQLは、クライアントが必要なデータを正確に指定して取得できるクエリ言語だ。
query {
user(id: "123") {
name
posts(first: 5) {
title
commentCount
}
}
}強み
- Over-fetching解消: クライアントが必要なフィールドだけを要求
- 1リクエストで複数リソース取得: ネストしたデータを1回のクエリで取得
- 強い型システム: スキーマで全フィールドの型が定義される
- フロントエンド主導の開発: バックエンドの変更なしにクライアントがデータ取得を最適化できる
弱み
- キャッシュが難しい: URLベースのキャッシュが使えない（Apollo Clientなどのクライアントライブラリで対応）
- N+1問題はバックエンドに移動: リゾルバーの設計を誤るとDB負荷が増大
- 学習コスト: スキーマ定義、リゾルバー、クライアントライブラリの理解が必要
- セキュリティの複雑さ: 深いネストや再帰的なクエリの制限が必要
向いているケース
- 複数のフロントエンド（Web/iOS/Android）を持つサービス
- データ構造が複雑で、関連性の深いドメイン
- フロントエンドチームの自律性を高めたい組織
tRPC — フルスタックTypeScriptの型安全
tRPCは、TypeScriptの型をサーバーとクライアント間で直接共有するRPCフレームワークだ。
// サーバー側
const appRouter = router({
getUser: publicProcedure
.input(z.object({ id: z.string() }))
.query(({ input }) => {
return db.user.findUnique({ where: { id: input.id } });
}),
});
// クライアント側 — 型が自動で推論される
const user = await trpc.getUser.query({ id: '123' });
// user の型は { id: string; name: string; ... } と自動推論強み
- 完全な型安全: サーバーの型がクライアントにそのまま伝播
- コード生成不要: OpenAPIやGraphQL Codegenのようなコード生成ステップが不要
- 学習コストが低い: TypeScriptとZodを知っていればすぐに使える
- 開発速度: 型エラーがIDE上で即座にフィードバックされる
弱み
- TypeScript限定: サーバーもクライアントもTypeScript（またはJS）が前提
- モノレポ向き: 型共有のために同じリポジトリにいる必要がある
- 公開API向きではない: 外部パートナーにtRPCクライアントを使わせるのは非現実的
- エコシステムが小さい: RESTやGraphQLに比べてツールやドキュメントが限定的
向いているケース
- Next.js / Astroでのフルスタック開発
- TypeScriptモノレポのプロジェクト
- 社内ツールや管理画面
- プロトタイピング（型安全で高速に開発）
比較表
| 項目 | REST | GraphQL | tRPC |
|---|---|---|---|
| 型安全性 | △（OpenAPIで改善） | ○ | ◎ |
| 学習コスト | ◎ | △ | ○ |
| パフォーマンス | ○ | ○（設計次第） | ○ |
| キャッシュ | ◎ | △ | △ |
| 公開API向き | ◎ | ○ | ✕ |
| モバイル対応 | ◎ | ◎ | △ |
| ツール充実度 | ◎ | ○ | △ |
| コード生成 | 不要/任意 | 推奨 | 不要 |
選び方のフローチャート
- 外部公開するAPIか？ → Yes → REST（+ OpenAPI）
- 複数プラットフォーム（Web + iOS + Android）？ → Yes → GraphQL
- TypeScriptモノレポか？ → Yes → tRPC
- シンプルなCRUDか？ → Yes → REST
- 複雑な関連データの取得が多いか？ → Yes → GraphQL
ハイブリッドアプローチ
実際のプロジェクトでは、1つのアプローチに固執する必要はない。
- 外部向け: REST + 内部向け: tRPC — 公開APIはRESTで標準的に提供し、管理画面はtRPCで高速開発
- BFF（Backend for Frontend）にGraphQL — バックエンドのマイクロサービスはREST、フロントエンド向けのBFF層にGraphQLを置く
- 段階的移行 — 既存のREST APIを維持しつつ、新機能はtRPCで開発
まとめ
「RESTが正解」だった時代は終わり、プロジェクトの要件に応じて最適なアプローチを選ぶ時代になった。
とはいえ、迷ったらRESTから始めるのが安全だ。RESTは十分に成熟しており、OpenAPIで型安全性を補強できる。GraphQLやtRPCは、その必要性が明確になったときに導入すればよい。
重要なのは、各アプローチの「強み」と「弱み」を理解し、技術選定の根拠を持つことだ。