gRPC入門 - HTTP/2とProtocol Buffersで作る高速なサービス間通信

マイクロサービス間の通信方式を選ぶとき、REST以外の選択肢として必ず名前が挙がるのがgRPCです。「HTTP/2を使っている」「Protocol Buffersでシリアライズする」くらいは聞いたことがあっても、なぜそれが速いのか、RESTやGraphQLと何が違うのか、実際にどんな企業が使っているのかは意外と整理されていません。この記事では、grpc.io・CNCF・protobuf.devを一次ソースに、gRPCの技術的な仕組みから採用事例、主要ツールまでを整理します。

gRPCとは何か

gRPCの起源はGoogle社内にあります。Googleは10年以上にわたり、社内のマイクロサービス群を結ぶ汎用RPC基盤「Stubby」を使ってきました。2015年3月、Googleは次世代版のStubbyを構築し、これをオープンソース化することを決めました。これが現在のgRPCです。

オープンソース化後、gRPCはCloud Native Computing Foundation(CNCF)にホストされるプロジェクトとなりました。2017年2月16日、gRPCはCNCFにIncubatingレベルのプロジェクトとして受理されています。2026年8月時点でもCNCFのステータスはIncubatingのままで、卒業(Graduated)はしていません。卒業申請のIssue(cncf/toc#2101)は進行中で、2026年3月24日に技術レビューの更新があったことが確認できます。

技術的基盤

gRPCが速いと言われる理由は、大きく分けて2つの要素にあります。HTTP/2の上に構築されていることと、Protocol Buffersでシリアライズすることです。

HTTP/2の上で動く

gRPCはHTTP/2を通信基盤として使い、コネクションプーリング・多重化(マルチプレクシング)・KeepAliveといったHTTP/2の機能を活用します。1本のTCPコネクション上で複数のリクエスト/レスポンスを並行してやり取りできるため、HTTP/1.1のようにリクエストごとに新しい接続を張る必要がありません。HTTP/2そのものの仕組みは、UDPベースのHTTP/3への移行を扱ったHTTP/3とQUIC入門も参考になります。

Protocol Buffers(protobuf)によるシリアライズ

gRPCはインターフェース定義言語(IDL)としてProtocol Buffersを採用しており、サービスインターフェースとペイロードのメッセージ構造の両方を.protoファイルに記述します。JSONのようなテキスト形式ではなくバイナリ形式でシリアライズされるため、ペイロードは小さく、パース処理も軽くなります。

.protoファイルの基本的な書き方は次のようになります(protobuf.dev公式のproto3構文準拠)。

syntax = "proto3";
 
message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 results_per_page = 3;
}

各フィールドの末尾にある数字(= 1など)はフィールド番号です。フィールド番号は1から536870911までの範囲で指定でき、頻出するフィールドには1から15を割り当てると、バイナリエンコード時に1バイトで収まり効率的です。フィールド名は変更しても互換性が保たれますが、フィールド番号は一度使ったら変更しないのが鉄則です。

なお、proto3ではproto2にあったrequiredフィールドが廃止されており、フィールドは基本的に省略可能で、指定しなければ暗黙のデフォルト値(文字列なら空文字、数値なら0など)が使われます。

4つの通信パターン

gRPCの大きな特徴のひとつが、単純なリクエスト/レスポンスだけでなくストリーミングを第一級でサポートしている点です。gRPCが定義する通信パターンは4種類あります。

RESTでこれと同等のリアルタイム性を出そうとすると、WebSocket・SSE・ポーリングの使い分けで扱ったような別プロトコルの導入が必要になりますが、gRPCではストリーミングが標準機能として組み込まれています。

RESTとの違い

gRPCとRESTは設計思想が異なります。grpc.ioの公式FAQでは、次のような違いが挙げられています。

とくに重要なのが、ブラウザから直接gRPCサーバーへ通信できないという制約です。ブラウザはHTTP/2のトレイラーやバイナリフレーミングを直接扱えないため、素のgRPCをブラウザから呼び出すことができません。これを解決するのがgRPC-Webで、ブラウザ向けのプロトコルとネイティブgRPCとの間で変換を行うために、Envoyプロキシなどの仲介役が必要になります。REST APIの設計原則そのものについてはREST API設計の基礎と冪等性も参照してください。

GraphQLとの違い

GraphQLとの比較については、grpc.ioやGraphQL公式による直接の一次情報は見当たりませんでした。ただし一般的には、gRPCは内部API・マイクロサービス間通信でのパフォーマンスを重視する場面、GraphQLはクライアント向けに公開するAPIで、クライアントごとに異なるデータ要件へ柔軟に対応したい場面、という使い分けがされていると言われています。両者は競合というより、後述するExpedia Groupの事例のように併用されるケースもあるようです。

実際のユースケース・採用例

gRPCの採用事例は、grpc.io公式のShowcaseページで紹介されています。確認できる範囲では、次のような企業が掲載されています。

いずれもgrpc.io公式Showcaseに掲載されている事例で、動画配信・決済・広告配信基盤といった、レイテンシとスループットがシビアに問われる領域での採用が目立ちます。

主要ツール

gRPCの開発・運用でよく使われるツールを押さえておきます。

• protoc: Protocol Buffers公式のコンパイラです。.protoファイルから各言語向けのクラスやスタブコードを生成します。
• buf: protocを置き換えることを目指すモダンなツール群です。高速なコンパイラに加え、フォーマッタ・リンター・破壊的変更の検出機能、そしてスキーマを一元管理するBuf Schema Registry(BSR)を備えています。
• grpcurl: 「gRPC版のcurl」と呼ばれるコマンドラインツールです。コマンドラインからgRPCメソッドを呼び出せ、ストリーミングにも対応しています。
• evans: ktr0731氏によるgRPCクライアントです。REPLモードとCLIモードの両方を備え、gRPC reflectionオプションにも対応しています。

これらのツールを組み合わせることで、.proto定義からコード生成、動作確認までを一通りカバーできます。

2026年時点のエコシステム

grpc/grpcリポジトリの最新リリースはv1.83.0(コードネーム「garden」)です。PyPIのgrpcioパッケージでの公開日は2026年7月23日で、活発にメンテナンスが続けられています。前述の通り、CNCFプロジェクトとしてのステータスは2026年8月時点でも引き続きIncubatingです。

コード例

.protoファイルで、単純な挨拶を返すGreeterサービスを定義してみます。Unary RPCのSayHelloと、Server streaming RPCのSayHelloStreamを持つ例です。あくまで概念を示すサンプルであり、実際に動作確認したものではない点に注意してください。

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;
}

rpc SayHelloStreamの戻り値に付いているstreamキーワードが、Server streaming RPCであることを示しています。この.proto定義をprotocやbufでコンパイルすると、各言語向けのサーバースタブとクライアントスタブが生成されます。Goでのサーバー実装は概念的には次のような形になります(実際に動くコードとしてではなく、処理の流れを示す疑似コードとして読んでください)。

type server struct {
    greeter.UnimplementedGreeterServer
}
 
// Unary RPC: 単一リクエストに単一レスポンスを返す
func (s *server) SayHello(ctx context.Context, req *greeter.HelloRequest) (*greeter.HelloReply, error) {
    return &greeter.HelloReply{Message: "Hello, " + req.GetName()}, nil
}
 
// Server streaming RPC: 複数のレスポンスを順に送り返す
func (s *server) SayHelloStream(req *greeter.HelloRequest, stream greeter.Greeter_SayHelloStreamServer) error {
    for i := 0; i < 3; i++ {
        reply := &greeter.HelloReply{Message: fmt.Sprintf("Hello #%d, %s", i, req.GetName())}
        if err := stream.Send(reply); err != nil {
            return err
        }
    }
    return nil
}

SayHelloを呼び出すと単一のHelloReplyが1回返り、SayHelloStreamを呼び出すとHelloReplyが複数回にわたって送られてくる、というイメージです。実際の呼び出し確認には、前述のgrpcurlやevansが使えます。

まとめ

• gRPCはGoogle社内のRPC基盤「Stubby」を源流とし、2015年3月にオープンソース化が決定、2017年2月にCNCFのIncubatingプロジェクトとなった
• HTTP/2の多重化とProtocol Buffersのバイナリシリアライズが、gRPCのパフォーマンスの基盤になっている
• 通信パターンはUnary/Server streaming/Client streaming/Bidirectional streamingの4種類で、ストリーミングが標準機能として組み込まれている
• RESTとは静的パス・エラー表現・ペイロード形式が異なり、ブラウザから直接呼ぶにはgRPC-Webが必要
• GraphQLとの使い分けは一般論として「内部通信はgRPC、公開APIはGraphQL」と言われるが、Expedia Groupのように併用する例もある
• Salesforce・Datadog・Cloudflareなど、レイテンシとスループットがシビアな領域での採用がgrpc.io公式Showcaseで確認できる
• protoc・buf・grpcurl・evansを組み合わせれば、定義からコード生成、動作確認まで一通りカバーできる

サービス間通信の性能が課題になり、かつクライアントとサーバーの両方を自分たちでコントロールできるなら、gRPCは有力な選択肢になります。逆に、ブラウザから直接叩く公開APIや、外部の第三者に使ってもらうAPIであれば、RESTやGraphQLのほうが素直な場面も多いはずです。

参考リンク

• gRPC - About
• gRPC - CNCF Project
• cncf/toc Issue #2101(gRPC卒業申請)
• gRPC - Core concepts, architecture and lifecycle
• gRPC - FAQ
• Protocol Buffers - Language Guide (proto3)
• grpc/grpc-web
• Envoy - gRPC-Web filter
• gRPC - Showcase
• fullstorydev/grpcurl
• ktr0731/evans
• buf - Ecosystem
• bufbuild/buf
• grpc/grpc Releases
• grpcio - PyPI
• REST API設計の基礎と冪等性(当ブログ)
• WebSocket・SSE・ポーリングの使い分け(当ブログ)
• HTTP/3とQUIC入門(当ブログ)