gRPCとは｜RESTとの違い・Protocol Buffersと使いどころ

gRPCとは｜「関数を呼ぶ」発想の通信フレームワーク

gRPCは、別マシン上のメソッドをローカルのオブジェクトのように呼び出せるようにするRPCフレームワークです。公式ドキュメントでも「クライアントアプリケーションが、別のマシンにあるサーバーアプリケーションのメソッドを、あたかもローカルオブジェクトのように直接呼び出せる」と説明されています（Introduction to gRPC）。

RESTとの発想の差はここに尽きます。RESTは「リソースを表すURLに対してHTTPメソッドを送る」。gRPCは「サービスに生えているメソッドを名前で呼ぶ」。

読み方は「ジーアールピーシー」。名前の由来はgRPC Remote Procedure Callsという再帰的な略で、リリースごとに先頭のgの意味を変えるという遊びが公式に続いています。

RPCという考え方は新しくない

リモートの手続きを呼ぶという発想自体は、CORBAやSOAP、Javaの分散オブジェクトの時代からありました。過去のRPCが扱いづらかった理由は、独自プロトコルとベンダー依存の実装、そして人間には読めない定義ファイルの複雑さにあります。

gRPCが受け入れられたのは、この部分をHTTP/2とProtocol Buffersという公開された標準に置き換えたためです。Googleが社内で使っていたStubbyという基盤を、外部でも使える形に再設計したものが出自にあたります。

HTTP/2を土台にしている意味

gRPCはHTTP/2をトランスポートに使います。実務でこれが効くのは主に3点です。

第一に、1本のTCPコネクション上で複数のリクエストを並行に流せます。REST＋HTTP/1系で起きがちな「コネクション数がボトルネックになる」状況を避けやすくなります。

第二に、ヘッダが圧縮されます。小さなリクエストを高頻度で投げる内部通信では、ヘッダのオーバーヘッド比率が無視できません。

第三に、ストリームが双方向に流せます。後述する4つの通信方式が成立するのは、この性質があるからです。

裏を返すと、HTTP/2をそのまま通せない経路では、追加のプロキシや変換レイヤーが必要になりやすいということです。古いロードバランサやプロキシを挟む構成では、ここが最初の関門になります。

ミニFAQ：基礎まわり

Q. gRPCはHTTPを使っていないのですか？

使っています。HTTP/2のフレーム上にgRPC独自の規約を載せた形です。ただしパスは「/パッケージ名.サービス名/メソッド名」という固定的な構造で、RESTのようにURL設計で意味を表現することはしません。

Q. 必ずProtocol Buffersを使う必要がありますか？

既定ではProtocol Buffersを使いますが、シリアライズ形式は差し替え可能な設計です。実務ではほぼ既定のまま運用されます。

Protocol Buffersの基礎｜スキーマを先に決める

Protocol Buffers（protobuf）は、構造化データを定義してバイナリにシリアライズする仕組みです。gRPCにおいては、インターフェース定義言語（IDL）とメッセージ形式の両方を兼ねます。

順番としては、まずprotoファイルを書く。次にコード生成する。その後に実装を書く。この「スキーマファースト」の流れが、RESTでOpenAPIを後付けするやり方との一番の体感差になります。スキーマ駆動の考え方自体はOpenAPIとは｜Swaggerとの違い・仕様書の書き方と運用で扱っている論点と共通します。

protoファイルに書く要素

protoファイルに記述する主な要素は次のとおりです。

型と文法の詳細はProtocol Buffers公式のProto3ガイドにまとまっています。

フィールド番号には地味な性能上の癖があります。1〜15番はバイナリ上で1バイトで表現でき、16番以降は2バイトになる。高頻度で送るフィールドを若い番号に寄せる、という設計判断はここから来ています。

コード生成の流れ

protocというコンパイラにprotoファイルを渡すと、指定した言語のクライアントスタブとサーバーの基底クラスが生成されます。開発者が書くのは、生成された基底クラスを継承したサーバー実装と、生成済みクライアントを呼ぶ側のコードです。

公式がサポートする言語は、C#/.NET、C++、Dart、Go、Java、Kotlin、Node、Objective-C、PHP、Python、Ruby、Rust、Swiftです。言語をまたぐ通信で型が揃うのは、同じprotoから各言語のコードを生成しているためです。

Goとの相性の良さがよく話題になりますが、これは公式サポートの厚さに加えて、Goがサービス間通信の多い領域で採用されやすいという事情も重なっています。言語側の特徴はGo言語（Golang）とは？ 特徴・用途から年収・将来性まで解説を参照してください。

後方互換を壊さない変更・壊す変更

protobufは「フィールド番号でデータを識別する」設計なので、互換性の判断基準が独特です。

クライアントとサーバーを同時にデプロイできない環境では、この表がそのまま事故防止のチェックリストになります。バージョンごとのサポート期間はProtocol Buffersのバージョンサポート方針で公開されているため、採用時に確認しておくと安全です。

なお、本記事執筆時点で公開されている情報をもとに記述していますが、protobufは定期的にリリースが更新されます。実際のバージョン選定は公式のリリースノートで最新安定版を確認してから決めてください。

ミニFAQ：protoファイルの運用

Q. protoファイルはどこに置くのが定石ですか？

サービスごとのリポジトリに置く方式と、専用の共有リポジトリに集約する方式があります。複数チームが同じスキーマを参照する段階になると、共有リポジトリ＋バージョンタグの運用に寄せるケースが多く見られます。最適な切り替え時期は組織規模やデプロイ頻度で変わります。

gRPCとRESTの違い｜5つの観点で比較

結論として、両者は置き換え関係ではなく使う場所が違う技術です。RESTが不得意な領域をgRPCが埋める、という関係が実態に近いと考えてください。

REST側の設計原則やHTTPメソッドの使い分けはREST APIとは｜設計原則・HTTPメソッド・GraphQL/gRPCとの違いで扱っているため、本記事では深追いしません。

「速い」という評価の読み方

gRPCの紹介ではペイロードサイズの小ささがよく強調されます。同等の構造をJSONとprotobufで表現した場合、protobufのほうがペイロードは小さくなる傾向があります。ただし差の大きさはデータ構造・フィールドの型・圧縮の有無で変わるため、公開されているベンチマークの倍率をそのまま自分の系に当てはめることはできません。

ただし、ここは注意して読む必要があります。

差が効くのは、小さなメッセージを高頻度でやり取りする内部通信です。1リクエストあたりのビジネスロジックが重い処理や、DBアクセスが支配的な処理では、シリアライズ形式の差は全体のごく一部にしかなりません。「gRPCにしたのに速くならない」という相談は、だいたいこのパターンに当たります。

判断材料としては、シリアライズ処理とネットワーク転送が処理時間のどれくらいを占めているかを先に測る。そこが数パーセントなら、性能目的での移行は割に合いません。

ブラウザから直接は呼べない

一般的なgRPCを、ブラウザのJavaScriptからそのまま扱うのは困難です。ブラウザ側でHTTP/2のフレームを細かく制御できないためで、通常はプロキシ層を挟むことになります。

回避策として用意されているのがgRPC-Webで、ブラウザとサーバーの間にプロキシを挟んで変換します（gRPC-Webの基礎）。動きますが、プロキシが1層増えることと、サポートされる通信方式に制限があることは念頭に置いてください。

フロントエンドとバックエンドの間で型安全を取りたいという動機であれば、TypeScript前提の選択肢もあります。用途の違いはtRPCとは｜型安全なAPIの仕組み・使い方・GraphQL/RESTとの違いで整理されています。画面ごとに必要なデータだけを取りたいという要求ならGraphQLとは？REST APIとの違い・メリット・案件動向・将来性をフリーランス視点で解説が近い領域です。

4つの通信方式と使い分け

gRPCは4種類のRPCを扱えます。公式の定義はCore conceptsに記載されています。

まずはUnaryから始める

新規にgRPCを入れる場合、最初の数本はUnaryで書くのが無難です。RESTからの移植で構造が変わらず、デバッグもしやすい。

ストリーミングは強力ですが、途中切断の扱い、バックプレッシャー、再接続時の重複排除といった論点が一気に増えます。最初からここに踏み込むと、gRPCの学習ではなく分散システムの学習になってしまいます。

双方向ストリーミングが刺さる領域

双方向ストリーミングを標準の枠内で扱えることは、WebSocketを自前で組む場合と比べた明確な利点です。メッセージの型がprotoで定義されるため、「どんなイベントが飛んでくるか」がコードに現れます。

リアルタイム性が主題になる領域の案件感はリアルタイム通信エンジニアのフリーランス案件｜単価相場と必要スキルにまとまっています。

ただし、非同期のメッセージングを求めているならブローカーを挟む構成のほうが素直なケースもあります。到達保証やリトライ、順序制御まで必要ならApache Kafkaとは｜分散イベントストリーミング基盤の仕組み・用途・案件単価を解説で扱う領域を検討してください。gRPCのストリーミングはあくまで接続が生きている間の話です。

gRPCが向く場面・向かない場面

判断は単純です。呼ぶ側と呼ばれる側の両方を自分たちでコントロールできるか。ここが分岐点になります。

採用に向く条件

• サービス間の内部通信で、クライアントもサーバーも社内にある

• 複数言語のサービスが混在していて、型定義を一元化したい

• 小さなリクエストを高頻度で投げる（1秒あたり数百回以上のオーダー）

• ストリーミングが要件に入っている

• Kubernetes上などでサービス間の呼び出し経路を制御できる

マイクロサービス構成でよく名前が挙がるのはこのためです。分割の判断そのものはマイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説で扱っています。

見送るべき条件

• 不特定多数の外部開発者に公開するAPIである

• ブラウザから直接叩く必要があり、プロキシ層を増やしたくない

• curlでの疎通確認や手動テストの手軽さを重視する現場である

• HTTP/2を通せない機器やプロキシが経路に存在する

• サービスが1〜2個で、当面分割の予定もない

最後の条件は見落とされがちです。モノリス1本の構成にgRPCを入れても、スキーマ管理の手間だけが増えます。

判断フロー

1. 呼び出し元はブラウザか → はい なら REST／GraphQL を優先

2. 呼び出し元・先の両方が自社管理か → いいえ なら REST を優先

3. 高頻度呼び出しかストリーミング要件があるか → いいえ なら REST でも足りる

4. 経路のプロキシ・LBがHTTP/2に対応しているか → いいえ なら先にインフラ側を確認

5. すべて通過 → gRPCの採用を検討する段階

実装後に詰まりやすい運用論点

gRPCの学習でつまずくのは文法ではありません。動いた後に出てくる、次の5点です。

エラーハンドリングはステータスコードで表す

gRPCはHTTPステータスコードではなく、独自のステータスコード体系を持ちます。NOT_FOUND、INVALID_ARGUMENT、DEADLINE_EXCEEDED、UNAVAILABLEといった値で、コード一覧はgRPCのステータスコードに公開されています。

RESTの4xx／5xxに慣れていると、ここのマッピングで一度立ち止まります。特にUNAVAILABLEはリトライ可能、INVALID_ARGUMENTはリトライ不可、といった性質の違いをクライアント側の実装に落とす作業が要ります。

デッドラインは必ず設定する

gRPCにはデッドライン（タイムアウト）の仕組みがあり、指定時間を超えるとDEADLINE_EXCEEDEDで終了します。サーバー側からもRPCがタイムアウト状態かを確認できます。

問題は、クライアント実装によっては既定のデッドラインが実質無制限、または明示設定を前提にしていることです。既定値は言語・ライブラリ・ラッパーの実装で異なるため、採用するクライアントのドキュメントで必ず確認してください。設定し忘れると、障害時に呼び出しが滞留してスレッドやコネクションを食い潰します。サービス間呼び出しでは、まず数百ミリ秒〜数秒のオーダーで上限を決める。これが最初にやる設定です。

キャンセルの仕組みも用意されており、クライアント・サーバーのどちらからでもRPCを即座に打ち切れます。

負荷分散はL7かクライアント側制御を前提に考える

ここが最大の落とし穴です。

gRPCはHTTP/2の長寿命コネクションを使い回します。TCPレベル（L4）のロードバランサを挟むと、一度確立したコネクションが特定のサーバーに貼り付いたままになる。結果として、サーバーを増やしても負荷が分散しません。

対処としては、HTTP/2を理解するL7ロードバランサを使うか、クライアント側で分散する仕組みを入れるか、サービスメッシュに委ねるかのいずれかになります。メッシュを使う構成はIstioとは｜サービスメッシュの仕組み・Kubernetes運用での役割を解説で扱う領域です。

デバッグの勝手が変わる

バイナリで流れるため、ブラウザの開発者ツールやcurlでそのまま中身を見ることができません。grpcurlのようなCLIツールや、サーバーリフレクションを有効にしてGUIクライアントから叩く、といった手段に切り替えることになります。

分散トレースを入れておくと調査が現実的になります。計装の標準についてはOpenTelemetryとは｜可観測性標準の仕組み・導入の流れ・案件動向を参照してください。

スキーマの破壊的変更をCIで止める

protoの変更が互換性を壊していないかは、レビューの目視だけでは抜けます。破壊的変更を検出するリンターをCIに組み込み、フィールド番号の変更や削除を機械的に弾く運用にしておくと事故が減ります。

ミニFAQ：運用まわり

Q. RESTとgRPCを1つのサービスで併用できますか？

できます。外部公開用にRESTを残し、内部通信だけgRPCにする構成は現実的な選択です。protoからREST用のゲートウェイを生成する仕組みもあります。

Q. 認証はどうやって載せますか？

メタデータ（キーと値の組のリスト）にトークンを載せる方式が一般的です。RESTのAuthorizationヘッダに相当する位置づけと考えると理解しやすくなります。

学習ロードマップと実践チェックリスト

REST APIの実務経験がある人を前提とすると、Unary RPCで疎通させるところまでは1日1〜2時間の学習で1〜2週間、ストリーミングと運用論点まで含めて手応えを得るには合計2〜3か月が一つの目安になります。以下の期間はあくまで学習計画を立てるための目安で、既存の実務経験や検証環境の有無で変わります。文法より、後半の運用部分に時間が寄ります。

案件で評価されるのは主に段階3以降です。「protoが書ける」だけでは差になりにくく、デッドライン設計とロードバランサの構成まで説明できるかが面談での分かれ目になります。

参画前の確認チェックリストとして、次の項目を押さえておくと初動が早くなります。

• protoファイルの管理場所とバージョニング方針

• クライアント側のデッドラインとリトライの既定値

• ロードバランサがL4かL7か、サービスメッシュの有無

• 破壊的変更を検出するCIの有無

• 外部公開APIとの境界（gRPC-Webやゲートウェイの利用範囲）

gRPCスキルとフリーランス案件の実情

先に短答を書きます。gRPC単体を主題にした募集は多くありません。実務ではGo・Kubernetes・マイクロサービスといった構成の一要素として要件に現れるのが一般的です。

以下の目安は、2026年9月時点で首都圏中心の主要フリーランスエージェント数社の公開案件ページを確認し、要件欄にgRPCの記載があるものを拾った観測ベースの整理です。該当件数自体が多くない領域のため、レンジは参考値として読んでください。非公開で打診される案件は個別条件の幅が大きく、ここには含めていません。

レンジの幅は、商流の深さと求められる裁量の差によるところが大きくなります。言語別・レイヤー別の全体像はバックエンドフリーランスの単価相場｜言語別・レイヤー別レンジと動向、Goに絞った動向はGoフリーランスの単価相場｜高単価案件の条件と獲得ロードマップで整理しています。

自分がどの程度のレンジを狙えるかを確認したい場合は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を把握できます。単価を体系的に引き上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？にまとめています。

実際の募集条件を見たい場合は、サーバーサイドエンジニアの案件一覧やGo言語の案件一覧から要件欄を確認するのが早い方法です。

面談で聞かれやすい論点

案件面談でgRPCに触れられる場合、実装経験の有無より運用の理解を問われるケースが目立ちます。

• なぜRESTではなくgRPCを選んだのか、判断の根拠

• デッドラインとリトライをどう設計したか

• ロードバランサの構成と、分散が効かない問題への対処

• protoの破壊的変更をどう防いだか

これらに自分の言葉で答えられるなら、実装本数が少なくても評価されます。

まとめ

gRPCは、自社で両端を管理できるサービス間通信を、型定義つきで高速にやり取りするための選択肢です。外部公開APIの第一候補ではありません。

要点を整理します。

• 本質は「URLを叩く」から「メソッドを呼ぶ」への発想の転換で、HTTP/2とProtocol Buffersがそれを支えている

• protoファイルはコード生成の起点であり、フィールド番号の扱いが互換性を左右する

• RESTとの比較で効くのは速度よりも、型の一元化とストリーミングの扱いやすさ

• 採用判断の分岐は「呼ぶ側と呼ばれる側の両方を自分たちで制御できるか」

• 実務で差がつくのは文法ではなく、デッドライン設計・L7での負荷分散・破壊的変更の検出

次のステップとしては、まず手元の言語でUnary RPCを1本通し、そのうえでデッドラインを設定してタイムアウト時の挙動を観察してみてください。この2つを押さえると、案件要件を読んだときの解像度が変わります。

参照した一次情報は次のとおりです。

• Introduction to gRPC（gRPC公式）

• Core concepts, architecture and lifecycle（gRPC公式）

• gRPCのステータスコード（gRPC公式）

• gRPC-Webの基礎（gRPC公式）

• Language Guide proto3（Protocol Buffers公式）

• Version Support（Protocol Buffers公式）