まず押さえる5つの判断軸

REST か gRPC かは、技術の好みではなくシステムが置かれた条件で決まる。実務で効くのは次の5軸だ。

判断軸問い傾向
① 公開範囲API を叩くのは社外の不特定多数か、自社の内部サービスか外部 → REST / 内部 → gRPC
② クライアントブラウザが直接叩くかブラウザ直 → REST
③ レイテンシ／流量サービス間の往復回数・スループットが性能を左右するか高負荷・低遅延 → gRPC
④ 通信形態ストリーミングや双方向通信が要るかストリーミング → gRPC
⑤ チーム／基盤protobuf・HTTP/2・L7LB の運用に耐えられるか整備が薄い → REST

💡 軸の優先順位

多くの場合、最初に効くのは①公開範囲と②クライアントだ。ブラウザや社外が叩くなら、性能を理由に gRPC を選んでも周辺コスト（gRPC-Web・プロキシ）で相殺されがち。性能軸（③④）は「内部通信」と確定してから効いてくる。

選定の判断フロー

上の軸を上から順に当てていくと、自然に落とし所が決まる。

Q1 ブラウザや社外の不特定クライアントが直接叩くか？
→ YES なら REST。汎用性・キャッシュ・デバッグ性が勝る。（gRPC を使うなら gRPC-Web＋プロキシ前提）
Q2 NO（内部サービス間）。双方向／ストリーミング通信が要るか？
→ YES なら gRPC。ストリーミングが第一級機能。
Q3 NO。サービス間の往復が多く、レイテンシ／スループットが性能課題か？
→ YES なら gRPC。protobuf＋HTTP/2 多重化が効く。
Q4 NO。HTTP/2・L7LB・protobuf を運用できる体制があるか？
→ 体制が薄いなら REST で十分。整っているなら型の厳密さを取りに gRPC でもよい。

⚠️ このフローは「内部通信ほど gRPC 寄り」という偏りを持つ

あくまで一般的傾向であり、内部通信でも「数も流量も少ない管理用 API」なら REST のほうが運用が楽なことは多い。フローは出発点であって、最後は具体的なトラフィックと体制で微調整する。

REST に倒すべきケース

公開 API / Web API
社外の開発者やパートナーが叩く。ドキュメントと汎用性が最重要で、誰でも curl で試せることに価値がある。
ブラウザ・モバイルの直接通信
フロントが直接叩く層。HTTP キャッシュ・CDN・標準ライブラリの恩恵が大きい。
単純な CRUD・管理画面
流量が少なく、リソース指向に綺麗に収まる。gRPC の周辺コストが見合わない。
基盤が HTTP/1.1 前提
既存の LB・WAF・監視が HTTP/2 を完全に通せない、または整備の余力がない。

gRPC に倒すべきケース

マイクロサービス間通信
内部で多数のサービスが高頻度に通信する。型の厳密さと低レイテンシが効く中核ユースケース。
低レイテンシ・高スループット
1リクエストの裏で何度も往復する。protobuf の軽さと HTTP/2 多重化が積み上がって効く。
ストリーミング・双方向
進捗配信・リアルタイム同期・大量データのアップロード集約など。
多言語・多チームの厳密な契約
Go・Java・Python などが混在し、.proto を単一の契約として共有したい。

併用という現実解

実際の多くのシステムは「どちらか一方」ではなく両方を層ごとに使い分ける。 典型は「外向きは REST、内部は gRPC」だ。エッジ（BFF / API Gateway）で外部からの REST/JSON を受け、 そこから先のサービス間通信は gRPC で行う。フロントの扱いやすさと、内部の効率を両取りできる。

構成イメージ — 外向きREST / 内部gRPC 
[ブラウザ/モバイル]
      |  REST + JSON（扱いやすい・キャッシュ可）
      v
[ BFF / API Gateway ]
      |  gRPC（型安全・低レイテンシ）
      +--> [UserService]
      +--> [OrderService]
      +--> [PaymentService]
            |  gRPC
            v
        サービス間は protobuf で高速通信

さらに「1つの定義から REST と gRPC の両方を提供したい」場合は gRPC-Gateway が定番だ。 .proto にHTTPマッピングを書いておくと、gRPC サーバーの前段に REST/JSON ↔ gRPC を変換するリバースプロキシを自動生成できる。 1つの契約から両方のインターフェースを生やせるため、移行期や「内部は gRPC・外部にも JSON を出したい」ケースで効く。

💡 併用の代表パターン

① BFF パターン：エッジで REST を受け内部を gRPC 化。② gRPC-Gateway：1つの .proto から REST と gRPC を同時提供。③ サービスメッシュ：Envoy 等で gRPC の LB・リトライ・可観測性を基盤側に寄せる。

選定でやりがちな誤り

ありがちな判断なぜ危ういか
「速いから全部 gRPC」ブラウザ・外部公開層では gRPC-Web/プロキシのコストが性能利得を相殺する
「枯れてるから全部 REST」高頻度のサービス間通信では往復コストと型のゆるさが後で効いてくる
「流行ってるから gRPC」L7LB・専用監視・デバッグ手段の整備コストを見積もっていない
性能を計測せず選ぶ多くのシステムのボトルネックは DB や N+1 であり、プロトコル差ではないことが多い

✅ 次の章では…

PART 04 では、実際に「JSON/REST で作った内部 API を gRPC へ移行する」ケーススタディを扱う。同一エンドポイントの REST 版と gRPC 版のコードを並べて対比し、.proto の起こし方から段階的移行（gRPC-Gateway 併用・ストラングラーパターン）、ハマりどころまでを具体的に見ていく。

→ PART 04 — REST→gRPC 移行ケーススタディへ