gRPCとRESTの違い — 「商品を読む」と「処理を呼ぶ」から比べる

ひよこ

商品情報を別のサービスから取りたいんだけど、gRPCとRESTはどう違うの？

ペンギン先生

RESTはリソースとその表現を扱う設計スタイル、gRPCは離れたメソッドを呼ぶRPCの仕組みだよ。商品をURLで読むHTTP APIの例と、GetProductという処理を呼ぶ例で比べよう。JSONはRESTで必須ではなく、gRPCは通常Protobufの定義を使うんだ。

ひよこ

バイナリって、0と1のやつだよね？それだと開発のときにデバッグしにくくないの？

ペンギン先生

JSONはテキストとして確認しやすいけれど、Protobufのバイナリはデコードが必要だよ。gRPCでは.protoの定義や、有効化されたリフレクションを使ってメッセージの構造を調べられるんだ。

ひよこ

.protoファイルって何なの？

ペンギン先生

APIの「設計図」みたいなものだよ。どんなデータをやり取りするか、どんなメソッドがあるかを.protoファイルに定義しておくと、そこからサーバーとクライアントのコードが自動生成されるんだ。RESTだとOpenAPIのドキュメントを書いて、そこからコードを生成することもあるけど、gRPCはコード生成が標準フローに組み込まれているのが大きな特徴だね。

ひよこ

コードが自動で作られるのは便利そう！通信の速さにも違いがあるの？

ペンギン先生

通常のgRPCはHTTP/2を使うよ。ただしREST APIもHTTP/2を利用できるから、HTTPのバージョンだけで速さは決められない。メッセージ形式や処理内容、接続の使い方も関係するんだ。

ひよこ

HTTP/2ってそんなにすごいの？RESTでもHTTP/2は使えるよね？

ペンギン先生

その通り。Protobufの符号化が通信量や処理負荷を減らせる場合はあるけれど、データの大きさ、圧縮、サーバーの処理などで結果は変わるよ。同じ条件で測定して選ぼう。何倍速いと一律には言えないんだ。

ひよこ

じゃあストリーミングっていうのも聞いたことがあるけど、どういうことなの？

ペンギン先生

gRPCは1要求・1応答のUnaryに加え、サーバーだけ、クライアントだけ、双方向の3種類のストリーミングを定義できるよ。複数メッセージを継続的に扱う用途で役立つんだ。HTTP APIでも連続送信する設計は可能なので、RESTが一切ストリーミングできないという意味ではないよ。

ひよこ

用途に合う通信の形を選ぶんだね。ブラウザでも使える？

ペンギン先生

通常のgRPCとブラウザ向けgRPC-Webは区別する必要があるよ。公式grpc-webはプロキシ経由で接続し、2026年10月9日の資料ではUnaryとgrpcwebtextモードのサーバーストリーミングに対応している。クライアント側・双方向ストリーミングは未対応なんだ。

ひよこ

なるほど、場所によって使い分けるんだね！結局どう選べばいいのかな？

ペンギン先生

ブラウザや多様な外部利用者から扱いやすいHTTP APIが必要か、型定義とコード生成、ストリーミングをそろえたいかで考えるとよいよ。gRPCならプロキシや運用ツールの対応も確認する。公開用と内部通信用で方式を分ける構成も選択肢だね。

まずは同じ「商品名と値段」を頼んでみる

通販の商品カードに「マグカップ・1200円」を表示したいとします。データが別サービスにあるとき、やり取りの契約をどう作るかを比べます。以下は設計を読む例で、接続できる公開APIではありません。

同じ商品を表示できても、URLやHTTPの意味を中心に契約するのか、型付きのメソッドとメッセージを中心に契約するのかが違います。URLとGETだけでRESTのすべての制約を満たすわけではありません。

gRPCの定義の最小例です。フィールド番号は用途を持つので、あとから見た目のために振り直しません。

syntax = "proto3";
package shop;

service Catalog {
  rpc GetProduct (ProductRequest) returns (Product);
}
message ProductRequest {
  int32 id = 1;
}
message Product {
  string name = 1;
  int32 price_yen = 2;
}

この定義からコードを生成し、サーバー側の処理・起動とクライアント側の呼び出しを別に実装します。定義だけで商品DBが用意されるわけではありません。

選ぶ前に、3つを確認する

1. 誰が呼ぶか：ブラウザや外部の多様な利用者なら、HTTP APIの扱い方が合うかを確認。gRPC-Webを使うなら通常のgRPCとは別に、プロキシと対応モードを見る。
2. 通信の形は何か：1要求・1応答か、複数メッセージを送るか。gRPCは4種類を定義できるが、HTTP APIでも連続送信する設計は可能。
3. 運用できるか：ログ、期限、認証、プロキシ、コード生成、変更時の互換性を確認する。HTTP/2やバイナリ形式だけで速さの勝敗は決まらない。

商品を1件読むAPIで、扱いやすさ・エラー時の見え方を比較するところから始めると判断しやすくなります。内部通信用と公開用で方式を分けることもできます。

期限とAPI変更で確認すること

リフレクションによるAPI定義の取得には、サーバー側での有効化が必要です。期限を下流RPCへ伝える機能は、JavaやGoでは既定で対応し、C++では明示的な有効化が必要など、言語によって異なります。クライアント側の期限設定も確認します。

proto3の新しいフィールド追加は、バイナリ通信形式の互換性を保つ変更です。ただし、既定値やアプリの処理が正しく動くかは別に確認します。削除したフィールド番号は再利用せず、JSONへ変換する場合は別の互換性ルールにも注意します。

HTTPの基本ならHTTPの仕組み、取得項目の設計を比べるならRESTとGraphQLへ。

参考資料

2026年10月9日確認。

• Fielding — REST — RESTの設計制約
• gRPC — Core concepts — 定義と4種類のRPC
• gRPC — Deadlines — 期限設定と伝播条件
• gRPC — Reflection — 明示的な有効化
• gRPC-Web — README — プロキシと対応するストリーミング
• Protobuf — proto3 — 定義とフィールド番号・互換性