gRPC（ジーアールピーシー）とは？読み方・Googleが作ったHTTP/2 RPCの仕組み・Protocol Buffers・ストリーミング・RESTとの違いを完全解説

Q: gRPCのgは何の略ですか？

公式FAQによると gRPC Remote Procedure Calls の頭文字を取った再帰略号で、リリースごとに別の単語に置き換える運用がされています。

Q: gRPCのセキュリティはどう確保しますか？

gRPCは標準でTLS mTLS をサポートしており、認証はJWT・OAuthトークンをmetadataで渡す形が一般的です。

gRPC（ジーアールピーシー）とは、Googleが2015年に公開した高性能リモートプロシージャコール（RPC）フレームワークのこと。HTTP/2をトランスポートに採用し、Protocol Buffersをインタフェース記述言語（IDL）として使うことで、JSONベースのREST APIに比べて低レイテンシ・小ペイロードを実現する。マイクロサービス間通信、双方向ストリーミング、多言語環境の通信基盤として広く採用されている。

例えるなら、gRPCは「電話の専用線」、RESTは「Eメール」。RESTがどこにでも届く汎用的な通信であるのに対し、gRPCはサービス間の高頻度・低レイテンシ通信に特化した「直結回線」だと考えると違いがイメージしやすい。実務ではマイクロサービス間API、内部データプレーン、エッジ・モバイル通信などで頻繁に採用される。

gRPCとは

gRPCとは、Googleが2015年8月にオープンソースとして公開したRPC（Remote Procedure Call）フレームワークである。HTTP/2の多重化・サーバープッシュ機能と、Protocol Buffersによる効率的なバイナリシリアライズを組み合わせ、単一接続で双方向ストリーミングを可能にする。CNCF（Cloud Native Computing Foundation）に採用されているプロジェクトで、Kubernetes・Envoy・etcdなど多くのクラウドネイティブツールが内部通信に利用している。

gRPCの「g」は当初は「Google」の頭文字だったが、現在では公式に「gRPC Remote Procedure Calls」の頭文字を取った再帰略号として説明されており、リリースごとに別の単語に変わるという遊び心のある仕様もある。ここが重要なポイントです。試験などで「gRPCのgは何の略か？」と問われた場合、Googleと答えるのは厳密には不正確になります。

gRPCの読み方

ジーアールピーシー

グラルピック（ごく一部の英語圏での口語的読み）

gRPCの仕組み

gRPCの動作は「IDL定義 → コード生成 → ランタイム呼出し」の3段階に分かれる。まず.protoファイルにサービスとメッセージを定義し、protocコンパイラで多言語（Go・Python・Java・C++・Rust等）のクライアント・サーバーコードを自動生成する。生成されたコードは内部でHTTP/2フレームを送受信し、Protocol Buffersでバイナリシリアライズする。

gRPCの構成

.proto
(IDL定義)

→

protoc
(多言語コード生成)

→

HTTP/2 + Protobuf
(実行時通信)

4種類のRPC

gRPCはHTTP/2の双方向ストリームを活用して以下4種のRPCをサポートする。RESTでは表現が難しいリアルタイム通信パターンに対応できる点が大きな差別化ポイントです。

Unary RPC — リクエスト1件・レスポンス1件。最も基本的な形（HTTP REST に近い）。
Server Streaming RPC — リクエスト1件に対しサーバーが複数レスポンスを返す。
Client Streaming RPC — クライアントが複数リクエストを送り、サーバーが1件返す。
Bidirectional Streaming RPC — 両方向で独立にストリームを送受信。チャットや株価配信に最適。

HTTP/2とProtocol Buffersの役割

HTTP/2は単一TCP接続で複数ストリームを多重化でき、ヘッダ圧縮（HPACK）も効く。Protocol BuffersはJSONより圧倒的にコンパクトで、独立ベンチマークではJSONを置き換えることでシリアライズ済みメッセージサイズが10倍縮小、小ペイロードでのレイテンシが最大77%低下するといった結果が報告されている。最新版のgRPCはv1.76（2025年10月リリース）で、Protocol Buffersは2008年にOSS化されv3に至っている。

gRPCの使い方・実例

基本的な使い方（Quick Start）

下記は.proto定義からPythonクライアントを呼び出すまでの最小例。公式チュートリアルの構文に準拠した形に整えてある。

# greeter.proto
syntax = "proto3";

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

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

# Python クライアント例
import grpc
import greeter_pb2, greeter_pb2_grpc

with grpc.insecure_channel("localhost:50051") as channel:
    stub = greeter_pb2_grpc.GreeterStub(channel)
    response = stub.SayHello(greeter_pb2.HelloRequest(name="World"))
    print(response.message)

よくある実装パターン

パターンA: マイクロサービス間のUnary RPC

# 注文サービスが在庫サービスに在庫数を問い合わせる
response = stub.GetStock(StockRequest(sku="ABC-001"))

向いているケース: バックエンドの内部API。低レイテンシ・型安全性・多言語サポートが必要な場面に最適。実務ではJSON REST APIから移行するチームが多いです。

避けるべきケース: ブラウザから直接叩くケース。ブラウザはHTTP/2のtrailerを直接扱えないため、gRPC-Webプロキシ経由でないと使えない。覚えておきましょう。

パターンB: Server Streamingでログ配信

# サーバーがログをストリームで送り続ける
for log_entry in stub.StreamLogs(LogRequest(service="orders")):
    print(log_entry.message)

向いているケース: 監視ダッシュボードへのログ配信、株価ティック配信、IoTデバイスからのテレメトリ集約など。1接続で長時間ストリームを保てる点が強み。

避けるべきケース: 短期間に大量の小要求が発生する用途。ストリーム維持のオーバーヘッドがUnary RPCより重くなる場面がある。

パターンC: Bidirectional Streamingでチャット

# 双方向で同時にストリームを流す
async def chat(stub):
    async for response in stub.Chat(generate_messages()):
        print(response.text)

向いているケース: チャットアプリ、対戦ゲームのリアルタイム通信、共同編集機能。WebSocketと近い使用感で型安全性が高い。

アンチパターン: gRPCをパブリックAPIとして公開

# 絶対NG
# gRPC over HTTP/2 trailer を直接公開しても多くのクライアントが扱えない
# パブリックAPIなら REST + OpenAPI、または gRPC-Gateway 経由の REST 変換層を用意すべき

gRPCはサービス間通信に最適だが、外部公開APIとしては未だRESTやOpenAPIの方が普及している。実務ではgRPC-Gatewayを使ってRESTファサードを自動生成する手法が一般的です。

gRPCのメリット・デメリット

メリット

低レイテンシ・小ペイロード — Protocol BuffersはJSONより数倍〜10倍コンパクト
多言語サポート — Go・Python・Java・C++・Rust・Node.js等
双方向ストリーミング — HTTP/2の多重化を活用
型安全 — 自動生成コードでコンパイル時に契約違反を検出
ロードバランシング・認証・タイムアウトが標準装備

デメリット・注意点

ブラウザ非対応 — gRPC-Web経由でないと直接叩けない
デバッグが難しい — バイナリ通信のため curl で直接叩けない
仕様変更時のスキーマ管理 — 後方互換ルールの遵守が必要
学習コスト — protoc・コード生成ワークフローへの慣れが必要

gRPCとREST・GraphQLの違い

gRPCはしばしばREST・GraphQLと並べて比較される。三者は「サービス間通信のプロトコル」という大枠は同じだが、データ形式・通信モデル・適性が異なる。

観点	gRPC	REST	GraphQL
データ形式	Protocol Buffers（バイナリ）	JSON（テキスト）	JSON（テキスト）
トランスポート	HTTP/2	HTTP/1.1 or 2	HTTP/1.1 or 2
通信モデル	単発＋4種ストリーミング	基本的に単発	単発＋subscription
主な用途	マイクロサービス間API	パブリックAPI全般	柔軟なクエリAPI
ブラウザ対応	gRPC-Web経由でのみ	ネイティブ対応	ネイティブ対応