『REST 万能』の時代から『用途別選択』の時代へ
2026年では gRPC・REST・GraphQL・tRPC が並存し、用途別に最適解が変わります。本記事では編集部の視点で、gRPC と REST の比較を公開情報をもとに整理します。REST API設計 もご参考に。
プロトコルレベルの違い
(1) REST：HTTP/1.1/2/3・JSON/XML・テキストベース。(2) gRPC：HTTP/2・Protocol Buffers・バイナリ。(3) 転送効率：gRPC が1.5〜10倍小さい(公開情報をもとに)。(4) パース速度：gRPC の方が速い。(5) 互換性：REST の方が広範。
スキーマと型安全
(1) gRPC：.proto ファイル+codegen で型同期。(2) REST：OpenAPI で型生成可能だが必須でない。(3) 言語間互換：両方とも複数言語対応。(4) バージョニング：proto のリザーブ機能が便利。(5) スキーマレジストリ連携。API バージョニング もご参考に。
ストリーミングサポート
(1) gRPC：双方向ストリーミング標準対応。(2) REST：SSE / Long Polling / WebSocket。(3) レイテンシ：gRPC の方が低い。(4) LLM ストリーミング：SSE が広く使われる。(5) ゲーム/リアルタイム：gRPC または WebSocket。SSE 実装 もご参考に。
ブラウザ対応
(1) REST：ネイティブ対応・fetch API。(2) gRPC：grpc-web 経由・サーバープロキシ必要。(3) Connect-RPC：両方をシンプルに統合。(4) ペイロードサイズ：gRPC が小さい。(5) デバッグ：REST の方が容易(JSON)。
マイクロサービス間通信
(1) 内部通信：gRPC の利点最大。(2) 外部公開：REST が一般的。(3) パフォーマンス：gRPC で大幅改善。(4) サービスメッシュ：gRPC との親和性高。(5) ハイブリッド：内部 gRPC・外部 REST。マイクロサービス設計 も合わせて。
エコシステム成熟度
(1) REST：ドキュメント/ツール/コミュニティ最大。(2) gRPC：成熟しつつあるが REST に及ばず。(3) 言語ライブラリ：両方とも主要言語サポート。(4) 監視ツール：両方対応進行中。(5) 採用人材：REST が圧倒的に多い。
判断軸まとめ
(1) 外部公開API → REST(or GraphQL)。(2) 内部マイクロサービス → gRPC。(3) 双方向ストリーミング → gRPC。(4) ブラウザ直接呼出 → REST/SSE/WebSocket。(5) パフォーマンス重視 → gRPC。gRPC 実践 もご参考に。
失敗しがちなパターン
(1) 全部 gRPC：開発体験悪化。(2) 外部公開 gRPC：消費者の負担。(3) REST のみで性能不足：gRPC を選ばず後悔。(4) プロトコル変更が困難：早期判断不足。(5) 両方混在でカオス。対策は、(1)用途別選択、(2)外部はREST、(3)早期PoC、(4)Connect-RPC、(5)アーキテクト合意、です。