この記事の要点

gRPC は Google が開発した高速な RPC (遠隔手続き呼び出し) フレームワーク。HTTP/2 を土台に動作する データのやり取りには Protocol Buffers (protobuf) を使い、バイナリ形式でコンパクト・高速にシリアライズする サービスとメッセージの定義を .proto ファイル (IDL) に書き、そこから各言語のクライアント/サーバコードを自動生成する 通常の 1 対 1 呼び出しに加え、サーバストリーミング・クライアントストリーミング・双方向ストリーミングに対応する マイクロサービス間の内部通信で広く使われる。多言語対応で、異なる言語のサービス同士を型安全につなげる

概要

gRPC は Google が開発・公開している RPC (Remote Procedure Call: 遠隔手続き呼び出し) フレームワークです。RPC とは「ネットワーク越しの関数を、あたかも手元の関数のように呼び出す」仕組みのことで、gRPC はその通信に HTTP/2 を、データ形式に Protocol Buffers（.proto） を採用することで、高速・低オーバーヘッド・多言語対応を実現しています。REST/JSON な Web API に比べてコンパクトで高速なため、特にマイクロサービス間の内部通信で広く使われます。親セクションは Web通信プロトコル です。

仕組み

gRPC の中心にあるのは IDL (インターフェース定義言語) としての .proto ファイルです。ここにサービス (呼び出せるメソッド群) とメッセージ (やり取りするデータ構造) を定義します。

• コード生成: .proto から protoc コンパイラが各言語のクライアント/サーバの雛形コードを自動生成します。開発者はネットワーク処理を書かずに、生成された関数を呼ぶだけで通信できます。
• Protocol Buffers でシリアライズ: 送受信するデータは protobuf でバイナリ化されます。JSON より小さく・速く・型が明確で、フィールド番号によるスキーマ進化 (前方/後方互換) もしやすくなっています。
• HTTP/2 上で多重化・ストリーミング: 土台が HTTP/2 のため、1 接続で多数の呼び出しを多重化でき、ストリーミングも自然に扱えます。

gRPC のメソッドには 4 つの通信パターンがあります。1 リクエスト 1 レスポンスの ユーナリ、サーバが連続して返す サーバストリーミング、クライアントが連続して送る クライアントストリーミング、双方が同時に流す 双方向ストリーミング です。

実用例

まずサービスとメッセージを .proto に定義します。タグ記号などはコード内で正しく表示されるよう記述しています。

# greeter.proto (IDL)
syntax = "proto3";
package greeter;

service Greeter {
  // ユーナリ呼び出し
  rpc SayHello (HelloRequest) returns (HelloReply);
  // サーバストリーミング
  rpc SayHelloStream (HelloRequest) returns (stream HelloReply);
}

message HelloRequest {
  string name = 1;
}
message HelloReply {
  string message = 1;
}

# .proto から各言語のコードを生成 (例: Python)
python -m grpc_tools.protoc -I. \
  --python_out=. --grpc_python_out=. greeter.proto

# 生成コードを使った呼び出し (擬似)
# stub = GreeterStub(channel)
# reply = stub.SayHello(HelloRequest(name="world"))
# print(reply.message)

クライアントは生成された stub.SayHello(...) をローカル関数のように呼ぶだけで、内部的に HTTP/2 + protobuf で通信が行われます。

主な用途

• マイクロサービス間通信: サービス同士を低遅延・低オーバーヘッドでつなぐ内部 API として最有力。
• 多言語混在環境: Go・Java・Python・Node など異なる言語のサービスを、共通の .proto で型安全に連携させる。
• ストリーミング処理: ログ・センサー・株価など連続データの送受信に双方向ストリーミングを使う。
• モバイル/IoT のバックエンド: コンパクトなバイナリで通信量を抑えたい場面。

REST/JSON との比較

項目	gRPC	REST/JSON
データ形式	Protocol Buffers (バイナリ)	JSON (テキスト)
土台	HTTP/2	主に HTTP/1.1・HTTP/2
スキーマ	.proto で厳格に定義	緩い (OpenAPI 等は任意)
ストリーミング	双方向まで対応	基本は要求-応答
ブラウザ直接利用	不可 (要 gRPC-Web)	容易
人間可読性	低い (バイナリ)	高い

注意点

• ブラウザから直接は使えない: ブラウザは生の gRPC を扱えないため、Web フロントからは gRPC-Web とプロキシ (Envoy 等) が要る。公開 Web API には REST の方が無難なことも多い。
• バイナリでデバッグしにくい: 中身が protobuf なので、JSON のようにそのまま目視できない。grpcurl などの専用ツールを使う。
• .proto の互換管理: フィールド番号の使い回しや型変更はスキーマ互換を壊す。番号は欠番化し、再利用しないなどの運用ルールが要る。詳しくは Protocol Buffers（.proto） を参照。
• 学習コストとインフラ対応: HTTP/2 前提のため、ロードバランサや監視が HTTP/2・gRPC に対応している必要がある。

関連リンク

• Web通信プロトコル
• HTTP/2
• Protocol Buffers（.proto）
• HTTP/3(QUIC)
• プロトコル