gRPCとは？RESTとの違い・仕組み・マイクロサービス活用例を解説

gRPCは、サービス同士がネットワーク上で高速にデータをやり取りできるリモートプロシージャコール（RPC）技術です。従来のREST APIのようにHTTPリクエストを手作業で構築し、JSONでデータを送受信する必要はありません。gRPCでは、利用可能なメソッドとデータ構造をあらかじめ定義し、クライアントとサーバー双方が自動で生成されたインターフェースを通じて通信を行います。

gRPCの仕組みと特徴

gRPCはProtocol Buffersによるデータのコンパクトなシリアライズと、HTTP/2によるリクエスト転送を基盤としています。この組み合わせは、数十〜数百の内部サービスが互いに頻繁に関数を呼び出し合うマイクロサービスアーキテクチャで特に有効です。

ただし、gRPCはRESTの完全な代替ではありません。gRPCは高速かつ厳密な型付けによるサービス間通信を得意とし、RESTはパブリックAPIやブラウザ、シンプルなWeb統合に適しています。

gRPCとは？どんな場面で役立つのか

gRPCはリモートプロシージャコール（RPC）フレームワークであり、あるサービスがネットワーク越しに他のサービスの関数を、まるで自分のプログラム内のメソッドのように呼び出せるのが特徴です。

例えば、ECサイトでは商品カタログ、決済、配送などがそれぞれ独立したサービスとして構成されます。注文サービスが配送費を知りたい場合、ロジスティクスサービスのGetDeliveryPriceといったメソッドを呼び出します。gRPCがパラメータをメッセージに変換し、ネットワークを通じて送信・応答をアプリケーションに返します。

gRPCを簡単に説明すると

REST APIはリソースのURLを指定し、例えばGET /users/42のようなリクエストでJSON形式のデータを取得します。一方、gRPCではリソースのアドレスではなく、サービスのメソッド（例：GetUser, CreateUser, DeleteUser）を定義し、プログラムの関数呼び出しのように利用します。

ネットワークの遅延やサーバーの一時的な利用不可、接続エラー、タイムアウトなどの問題は依然として存在しますが、gRPCはこれらの通信を厳格かつ便利に抽象化します。

gRPC APIの構造

gRPC APIは事前に定義されたコントラクト（契約）から始まります。利用可能なサービス・メソッド・メッセージ構造はProtocol Buffers言語で記述されます。

GetUser(UserRequest) → UserResponse

この記述からgRPCツールがクライアント・サーバー双方のコードを自動生成します。両者はどんなメソッドがあり、どんなパラメータ・レスポンスが必要か分かった状態でやり取りできます。

特に、Go・Java・Pythonなど異なる言語で書かれたサービス同士でも、共通の.protoファイルがあればやりとりが可能です。

gRPCの主な用途

gRPCは内部サービス間通信に最適です。マイクロサービス環境では、認証・カタログ・注文DB・決済・レコメンドなど複数のサービスが1つのユーザーリクエストで連携します。このとき、メッセージの軽量さやAPIの厳密さ、自動コード生成が大きな利点になります。

そのため、gRPCはバックエンド基盤や分散システム、内部APIで多用されます。パブリックAPI用途では、RESTの方がHTTPツールやブラウザから直接扱いやすいケースが多いです。

アプリケーションを独立したサービスに分ける理由や、その利点・課題については、「マイクロサービスアーキテクチャ：利点・課題・2026年のトレンド」の記事で詳しく解説しています。

gRPCの仕組み：Protocol Buffers・HTTP/2・メソッド呼び出し

gRPCの通信の流れは次の通りです。まず、開発者が.protoファイルでサービスとメソッドを定義し、それをもとにクライアント・サーバー両方のコードを自動生成します。メソッド呼び出し時、パラメータはバイナリメッセージに変換され、ネットワーク経由でサーバーに送信・復元されます。

Protocol Buffersによるサービス定義

gRPC APIのほとんどは、Protocol Buffers（Protobuf）形式で記述されます。これはデータのシリアライズとメッセージ構造の定義言語を兼ねています。

message UserRequest {
  int32 id = 1;
}

message UserResponse {
  int32 id = 1;
  string name = 2;
}

このように、リクエストにはユーザーID、レスポンスにはIDと名前が含まれることが事前に決まっています。クライアントとサーバーは、やりとりするデータの構造を厳密に把握できます。

JSONと異なり、Protobufはフィールド名ではなく数値IDを使うため、メッセージサイズが小さくなります。これは小さなメッセージが大量にやりとりされる環境で特に有効です。

service UserService {
  rpc GetUser(UserRequest) returns (UserResponse);
}

このようにサービスのメソッドも.protoファイルで定義します。

クライアント・サーバーコードの自動生成

gRPCの大きな強みは、.protoコントラクトからクライアント・サーバーのコードを自動生成できる点です。クライアント側にはstubと呼ばれるオブジェクトが作られ、例えば次のように関数として利用できます。

user = client.GetUser(request)

この背後で、リクエストのシリアライズやネットワーク送信、サーバーでの処理やレスポンスのデシリアライズが自動で行われます。

サーバー側はメソッドのビジネスロジックのみを実装すればよく、双方で同じコントラクトを使うことで、不一致によるエラーを減らせます。

サービス間リクエストの流れ

gRPCの呼び出しでは、クライアントがメソッドを呼び出すと、パラメータがProtocol Buffersでバイナリ化されます。リクエストはHTTP/2経由でサーバーに送信され、サービス名やメソッド名、メタデータなども付与されます。

サーバーはメッセージを受信後、デシリアライズして適切なハンドラーに引き渡し、ビジネスロジックを実行。レスポンスも再びバイナリ化されてクライアントに返されます。開発者は関数や構造体として扱うだけで、通信部分はgRPCが抽象化します。

HTTP/2の役割

gRPCの高効率な通信を支えるのがHTTP/2です。HTTP/1.1では多数の並行リクエスト時に複数コネクションが必要でしたが、HTTP/2は一つのTCPコネクション上で複数ストリームを多重化できます。

例えば、1つのサービスが同時に別サービスへ複数リクエストを送る場合、それぞれ独立したストリームで並行処理できます。

また、HTTP/2は双方向ストリーミングもサポートし、クライアントとサーバーが同時に複数メッセージをやりとりできます。これはgRPCのストリーミング機能を実現するのに不可欠です。

gRPCが高速な理由

gRPCの高速性は、複数の技術の組み合わせによるものです。バイナリメッセージによるデータサイズ削減、HTTP/2による効率的なコネクション利用、ストリーミングによる多メッセージ伝送が主な要因です。

特に内部システムで数千・数万の短いリクエストが発生する環境では、小さなパケットサイズと低いネットワークコストがパフォーマンス向上に直結します。

Protocol Buffersのバイナリフォーマット

REST APIは人間に分かりやすいJSONを使いますが、フィールド名や構造も毎回送信されるためデータ量が増えます。

{
  "id": 42,
  "name": "Alex"
}

一方でProtocol Buffersは数値IDを使い、事前に定義したスキーマに基づいてバイナリ形式でやりとりします。これによりデータ転送量が抑えられ、シリアライズ・デシリアライズも高速化されます。

ただし、データベース処理などがボトルネックの場合、ネットワーク最適化だけでは応答速度全体には大きく影響しません。

持続的なコネクションと多重化

HTTP/2による多重化で、一つのコネクション上で複数リクエストを同時処理できます。これにより、商品価格・在庫・ユーザー情報・配送オプションなどの並列取得が可能になり、マイクロサービス間の連携が効率化されます。

gRPCのストリーミング

gRPCはストリーミング通信をサポートしており、4つのモードがあります。

• Unary: 1リクエスト-1レスポンス。REST APIに最も近い。
• Server streaming: クライアントが1リクエストを送り、サーバーが複数レスポンスを返す。大量データの分割送信などに最適。
• Client streaming: クライアントが複数メッセージをサーバーに送り、サーバーが1レスポンスを返す。
• Bidirectional streaming: クライアントとサーバーが同時に複数メッセージをやりとりできる。

これにより、リアルタイム性や大量データ転送が求められるシステムでも効率的な通信が可能です。

gRPCとRESTの比較

gRPCとRESTはどちらもネットワーク越しのデータ交換を担いますが、設計思想や実装方法が大きく異なります。

RESTがパブリックAPIで好まれる理由

RESTの大きな強みは、シンプルなHTTP/JSONインターフェースです。どんなHTTPクライアントでもリクエストを送信・レスポンスを閲覧でき、外部開発者も扱いやすいです。

gRPCは、.protoファイルと専用クライアントがなければ操作が難しく、JavaScriptでのフル機能gRPC利用にはgRPC-Webや追加プロキシが必要です。そのため、Webアプリ・外部向けAPIにはRESTが多く採用されています。

分散システム内部でgRPCが好まれる理由

社内インフラなど、利用者・開発者が限定された環境では、gRPCの厳格な型・自動コード生成が利点になります。コントラクトの型チェックや、異言語間の一貫したAPI利用が容易です。

多数のマイクロサービスが協調する大規模システムでは、ネットワークコードの重複も減り、APIの一貫性も維持できます。

gRPCとRESTの併用

実際には、gRPCとRESTを併用するケースが多いです。例えば、モバイルアプリはパブリックREST APIを呼び出し、バックエンドは内部サービス間でgRPC通信を使うパターンです。またAPIゲートウェイでRESTリクエストをgRPCコールに変換することも可能です。

また、「GraphQLとRESTの違い・比較」の記事では、クライアントが必要なデータだけを指定できるAPI設計手法についても紹介しています。

gRPCとREST、使い分けのポイント

gRPCとRESTの選択は、技術の新旧ではなくシステムの性質に依存します。外部開発者向けやHTTPツールでの簡単なテスト、ブラウザからの利用が求められる場合はRESTが適しています。内部サービス間での大量・頻繁なやり取りにはgRPCが効果的です。

gRPCが向いている場面

• マイクロサービスアーキテクチャ（多数のサービスが短いリクエストを頻繁に連携）
• 複数言語のサービス連携（Go・Java・Pythonなど異言語間で同じ.protoファイルを利用）
• ストリーミング通信（リアルタイムな双方向メッセージ交換が必要な場合）
• APIコントラクトの厳格な型管理が必要な場合（開発時点で型エラーを検出）

RESTが向いている場面

• パブリックAPI（外部開発者やパートナーが利用しやすい）
• Webアプリケーション（ブラウザから直接HTTPリクエストが送れる）
• 小規模なCRUDアプリ（複雑な通信や型管理が不要な場合）
• 言語・ツール非依存のインターフェースが必要な場合

gRPCの制約と注意点

gRPCは人間にとって可読性が低いバイナリメッセージを使うため、テストやデバッグには専用ツールが必要です。また、標準gRPCは主にアプリ同士の通信向けであり、ブラウザ対応にはgRPC-Webやプロキシが求められます。

型定義（.protoファイル）の変更にも注意が必要です。互換性を保ちながら進化させるには、フィールドIDを不用意に変更・削除しないなどの運用ルールが求められます。

また、gRPCの導入だけでシステム全体が高速化するわけではありません。サービス設計自体が非効率なら、gRPCでもボトルネックは解消されません。

gRPCは内部API、頻繁な通信、ストリーミング、厳格な型管理などのニーズに合致する場合に真価を発揮します。パブリックAPIやシンプルなWebサービスにはRESTが依然として有効です。

まとめ

gRPCは、クライアントが事前定義されたコントラクトを通じてリモートのメソッドを呼び出す手法です。Protocol Buffersによるコンパクトかつ厳格なメッセージと、HTTP/2による効率的なデータ転送・ストリーミングを組み合わせています。

gRPCの強みは、マイクロサービスなどの内部分散システムで、複数言語・自動生成コード・統一APIコントラクトによる高速なサービス連携を可能にする点です。大量かつ頻繁な通信が発生する場合、従来のJSON通信より大きな利点があります。

一方、RESTはパブリックAPIやブラウザ、シンプルな統合用途で依然として実用的です。アーキテクチャや利用シーンに応じて、gRPCとRESTを使い分けるのが現代のベストプラクティスです。