REST・GraphQL・gRPC・tRPCの違いは？APIの選び方を比較

ひよこ

REST APIってもう古いの？

ペンギン先生

新しい方式があるから不要、とは言えないよ。選ぶ基準は利用者と必要な機能。RESTはアーキテクチャの制約を示す考え方で、単にHTTPでJSONを返せば厳密なRESTになるわけでもないんだ。

ひよこ

REST系のHTTP APIはどんなときに便利？

ペンギン先生

リソースをURLで表し、HTTPのメソッドやステータスを使う設計は、さまざまな言語のクライアントから扱いやすいよ。キャッシュも設計できるけれど、認証された応答や更新後の扱いは自分で決める必要があるんだ。

ひよこ

GraphQLは何が違うの？

ペンギン先生

クライアントが必要なフィールドを選んで取得できるよ。関連データを1回の問い合わせにまとめやすい。ただしサーバー内部のDBアクセスまで1回になるわけではないし、重いクエリへの制限も必要だよ。

ひよこ

RESTだと不要なデータを必ず返すの？

ペンギン先生

必ずではないよ。必要なフィールドや用途別のエンドポイントを設計する方法もある。GraphQLが解決しやすい課題はあるけれど、RESTの設計を改善する選択肢とも比べよう。

ひよこ

gRPCは何を重視しているの？

ペンギン先生

サービスとメソッドを定義して呼び出すRPCの仕組みで、型のあるメッセージやストリーミングを使えるよ。言語をまたぐサービス間通信が候補になる。ブラウザではgRPC-Webなどの対応経路と制約を確認する必要があるんだ。

ひよこ

tRPCはgRPCの軽量版？

ペンギン先生

別の仕組みだよ。tRPCはTypeScriptのサーバーとクライアントで型を共有し、手続きを呼び出す開発体験を重視する。コード生成用の別スキーマを省けても、procedureの定義や実行時の入力検証・認可は必要だよ。

ひよこ

どれなら速くて安全なの？

ペンギン先生

名前だけでは決められないね。転送量、DBへの問い合わせ、キャッシュ、認可、重いリクエストへの制限を含めて設計しよう。バイナリだから必ず速い、型があるから不正入力も防げる、とは限らないんだ。

ひよこ

既存のAPIは乗り換えるべきかな？

ペンギン先生

まず現在困っていることを特定しよう。画面ごとの取得形が頻繁に変わる、サービス間でストリームが必要、TypeScriptで型を共有したい、といった具体的な理由があれば検証する。流行や根拠のないシェア予測だけで移行しなくていいよ。

API方式の比較表

これは用途を限定する表ではありません。GraphQLの公開APIもありますし、内部向けREST APIも作れます。

gRPCとtRPCで迷ったら

Go・Javaなど複数言語でサービスを接続し、明示的なサービス定義を共有したい場合はgRPCを検討します。TypeScriptのフロントとバックを協調して開発し、型推論を活用したい場合はtRPCが候補です。どちらも、型定義だけでは利用者の権限を確認できません。

移行を決める小さな検証

代表的な画面1つについて、リクエスト回数、転送量、DBクエリ数、応答時間を測ります。認可違反や入力エラーも試します。GraphQLでHTTPの往復を減らせても、リゾルバーごとのDB読み取りが増えれば改善にならない場合があります。

参考資料

確認日：2026年9月26日。製品の仕様・料金・対応環境は導入時にも確認してください。

• Fielding: REST architectural style：ステートレス・キャッシュ・統一インターフェース。
• GraphQL: Queries：フィールド選択と関連データ取得。
• gRPC core concepts：サービス定義、RPCの種類、ストリーミング。
• gRPC-Web tutorial：ブラウザからのプロキシ構成。
• tRPC concepts：procedure・context・middleware・validation。