gRPCとは？定義・仕組み・RESTとの違いをまとめて解説

gRPCは、Googleが2015年に公開したRPC（リモートプロシージャコール）フレームワークです。インターフェース定義にProtocol Buffers、通信にHTTP/2を使い、別サーバー上の関数をあたかも手元のメソッドのように呼び出せます。マイクロサービス間の高速通信で採用が広がる一方、ブラウザから直接呼べないなどRESTと使い分けが要る技術でもあります。この記事では、gRPCの定義と仕組み、4つの通信方式、REST APIとの違いと使い分け、メリット・デメリット、導入の第一歩までを一度に整理します。

まとめ：gRPCとは何かを一言で

• 定義：Protocol Buffersで定義した契約（.proto）をもとに、HTTP/2上で関数を呼び出すRPCフレームワーク。2015年にGoogleが公開し、2017年からCNCFのインキュベーションプロジェクト。
• 速さの理由：JSONではなくバイナリのProtocol Buffersでやり取りし、HTTP/2の多重化・ヘッダー圧縮・双方向ストリーミングを使うため、通信量が小さく低遅延。
• 通信方式は4つ：Unary（1対1）／サーバーストリーミング／クライアントストリーミング／双方向ストリーミング。
• RESTとの違い：RESTは人が読めるJSONでブラウザから直接叩けるのが強み。gRPCは契約が厳密で高速だが、ブラウザから使うにはgRPC-Web/Connectが必要。
• 向く場面：社内マイクロサービス間、リアルタイム双方向通信、多言語混在システム。公開Web APIやブラウザ直結にはRESTが無難。

gRPCとは何か：定義とGoogleが開発した背景

定義：Protocol Buffersを使うRPCフレームワーク

gRPCの「RPC」はRemote Procedure Call（リモートプロシージャコール）の略で、ネットワーク越しのサーバー上の処理を、ローカル関数を呼ぶのと同じ書き方で実行する仕組みを指します。gRPCはそのRPCを、Protocol Buffersという定義言語で「どんな関数がどんな引数と戻り値を持つか」を契約として記述し、その契約からクライアント・サーバー双方のコードを自動生成して実現します。通信路にはHTTP/2を用います。頭の「g」はリリースごとに意味づけが変わる遊び心のある略で、gRPC公式は毎回異なる単語を当てています（公式は「gRPC Remote Procedure Calls」という再帰的な略として説明しています）。

開発の背景：社内基盤Stubbyから2015年の公開、そしてCNCFへ

Googleは自社の膨大なマイクロサービスを結ぶために「Stubby」という内製RPC基盤を長年使っていました。これを標準規格のHTTP/2と組み合わせて再設計し、オープンソースとして2015年に公開したのがgRPCです。2017年2月にCNCF（Cloud Native Computing Foundation）へ寄贈されてインキュベーションプロジェクトとなり、クラウドネイティブな通信技術として位置づけられました。RESTが2000年代のWeb APIを支えたのに対し、gRPCはサービス間（サーバー同士）の内部通信を主戦場として設計されている点が出発点の違いです。

gRPCの仕組み：RPC・Protocol Buffers・HTTP/2

RPC（リモートプロシージャコール）：関数呼び出しの感覚で通信するモデル

RPCは、リモートのサーバーが公開する手続き（関数）を、通信の詳細を意識せずに呼び出すモデルです。開発者は「どのURLにどんなJSONをPOSTするか」ではなく「GetUser(id)を呼ぶ」という関数呼び出しの感覚でコードを書けます。リクエストの組み立て・送信・受信・復元といった定型処理は、生成されたスタブ（クライアント側の代理コード）が肩代わりします。

RPC自体はgRPC固有の考え方ではありません。スキーマもコード生成も使わず、JSONの本文にメソッド名を書いて単一のエンドポイントへPOSTする軽量な方式もあり、代表がJSON-RPC 2.0です。PHPでの実装例はLaravel Sajyaとは？JSON-RPC 2.0サーバーの実装手順とエラー処理で扱っています。

Protocol Buffers（.proto）の役割

Protocol Buffersは、サービスとメッセージの構造を記述するインターフェース定義言語（IDL）兼シリアライズ形式です。まずuser.protoのような.protoファイルに契約を書き、そこからGoやPython、Javaなど各言語のコードを生成します。データはJSONのようなテキストではなくバイナリにエンコードされるため、サイズが小さく解析も速くなります。契約が先に決まる「スキーマファースト」なので、クライアントとサーバーの認識ズレが起きにくいのも特徴です。

syntax = "proto3";

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

message UserRequest {
  int32 id = 1;
}

message UserReply {
  string name = 1;
}

HTTP/2が支える多重化とストリーミング

gRPCの通信路はHTTP/2です。1本のTCP接続上で複数のリクエストを並行して流す多重化、ヘッダーを圧縮する仕組み、そして接続を張りっぱなしにしたままデータを流し続けるストリーミングを備えます。これによりHTTP/1.1で問題になりがちな接続の張り直しやヘッドオブラインブロッキングを避け、低遅延な連続通信が可能になります。なお通信はUDPではなくHTTP/2（TCP上）で行われます。UDP/TCPの扱いや実装レベルの詳細はgRPCの仕組みとUDP/TCPの扱いを実装例で解説した記事で掘り下げています。

gRPCの4つの通信方式

gRPCは.protoのサービス定義で、以下4種類のメソッドを宣言できます。単発の呼び出しから双方向のリアルタイム通信まで、用途に合わせて選べるのがRESTにない柔軟性です。

gRPCとREST APIの違いと使い分け

比較表で見る主な違い

gRPCとRESTは対立する技術ではなく、得意分野が異なります。RESTは人が読めるJSONとHTTPの汎用性が強み、gRPCは契約の厳密さと速度が強みです。

REST自体の定義やGraphQLとの位置づけはGraphQLとREST APIの違いを比較した記事もあわせて参照すると、3方式の住み分けが整理できます。

どちらを選ぶべきか

判断基準はシンプルです。社内のサービス同士を高速につなぐならgRPC、外部の不特定多数やブラウザに公開するAPIならRESTが基本線です。gRPCはブラウザから直接呼べず、通信内容がバイナリで人の目で追いにくいため、公開APIの入口に置くと開発者体験や運用の負担が上がります。逆に、社内マイクロサービス間の低遅延通信や、進捗・チャットのようなストリーミングが要る場面では、RESTを無理に使うよりgRPCが素直です。フロントエンドから使いたい場合は、gRPC-WebやConnectをRemix環境で扱う方法を解説した記事のようにブラウザ対応の層を挟む構成を検討します。

gRPCの主な用途

gRPCが力を発揮するのは、次のようなサーバー間・多言語・リアルタイムの通信です。

• マイクロサービス間通信：多数のサービスが頻繁に呼び合う構成で、通信量と遅延を抑えられる。モジュラモノリスとマイクロサービスの違いを解説した記事のように、分割アーキテクチャの内部接続に向く。
• リアルタイム・双方向通信：双方向ストリーミングでチャットや位置同期、進捗通知などを効率的に実装できる。
• 多言語混在システム：同じ.protoからGo・Python・Java・Ruby・C++など各言語のコードを生成でき、言語をまたいでも契約がぶれない。

gRPCのメリットとデメリット

メリット

• 通信が速く軽い：バイナリシリアライズとHTTP/2により、JSON+HTTP/1.1より転送量が小さく低遅延。
• 契約が明確：.protoが単一の正となり、クライアント・サーバーの型ずれや仕様認識の食い違いを防ぐ。
• ストリーミング対応：4つの通信方式で、単発から双方向リアルタイムまで一貫した書き方で扱える。
• 多言語のコード生成：定義から各言語のスタブを自動生成でき、実装の手戻りが減る。

デメリットと採用を避けるべき場面

gRPCは万能ではありません。ブラウザから公開する一般向けWeb API、外部パートナーに広く配る予定のAPI、cURLやブラウザでの手軽な動作確認を重視する場面では、gRPCを第一候補にすべきではありません。理由は、ブラウザが直接gRPCを話せずgRPC-Web/Connectなどの追加層が要ること、通信がバイナリでログやデバッグで中身を目視しにくいこと、そして.protoやコード生成といった学習・環境整備のコストが初期にかかることです。これらが不要でHTTP+JSONで足りるなら、RESTのほうが総コストは低く済みます。逆に社内サービス間の高頻度通信では、これらの欠点よりも速度と契約の恩恵が勝ちます。

gRPCの始め方：.protoからコード生成まで

gRPCの開発は「契約を書く→コードを生成する→中身を実装する」の順で進みます。先ほどの定義をuser.protoとして保存したら、Protocol Buffersコンパイラ（protoc）で各言語のスタブを生成します。Pythonの例は次のとおりです。

python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. user.proto

生成された基底クラスを継承してサーバー側の処理を書き、クライアントは生成済みスタブを呼ぶだけで通信できます。実際のサーバー実装例やコードの全体像はgRPCの実装例つき解説記事で確認できます。

gRPCのセキュリティ：TLSとmTLSの基礎

gRPCの通信は、HTTP/2上のTLSで暗号化するのが基本です。サーバー証明書でサーバーを認証する通常のTLSに加え、クライアント側にも証明書を持たせて相互に認証するmTLS（相互TLS）を使えば、サービス間で「相手が正規のサービスか」を検証できます。マイクロサービス内部の通信では、このmTLSによる相互認証がよく用いられます。認証・認可の実装やトークン連携など運用寄りの詳細は本記事の範囲を超えるため、一次情報としてgRPC公式の認証ガイドで最新の方式を確認してください。

よくある質問（FAQ）

gRPCはREST APIの置き換えですか？

いいえ。用途が異なります。社内サービス間の高速通信はgRPC、ブラウザや外部公開のWeb APIはRESTというように併用するのが一般的です。同じシステム内で両方を使い分ける構成も珍しくありません。

gRPCはブラウザから直接使えますか？

そのままでは使えません。ブラウザはHTTP/2のgRPCフレームを直接扱えないため、gRPC-WebやConnectといった中間層を挟む必要があります。フロントエンドで使う場合はこの構成が前提になります。

gRPCはUDPを使いますか？

使いません。gRPCの通信はHTTP/2、つまりTCP上で行われます。UDP/TCPの扱いや誤解しやすい点は実装解説記事で詳しく触れています。

Protocol Buffersは必須ですか？

標準ではProtocol Buffersを使います。gRPC自体は他のシリアライズ形式も理論上は差し替え可能ですが、実務ではほぼProtocol Buffers（.proto）が前提です。

gRPCの学習は難しいですか？

RESTに比べると、.protoの記述やコード生成の環境構築という初期ハードルがあります。ただし一度整えれば、契約からコードが生成され型安全に通信できるため、規模が大きいシステムほど恩恵が大きくなります。

関連記事

• gRPCとは？仕組み・RESTとの違い・UDP/TCPの扱いを実装例つきで解説
• gRPCとConnectをRemix環境で扱う背景とその重要性について
• REST APIとGraphQLの違いと使い分け｜選定基準と運用コスト
• モジュラモノリスとは何か？その基本概念と特徴を解説
• Laravel Sajyaとは？JSON-RPC 2.0サーバーの実装手順とエラー処理