**gRPC：サービス定義から通信フォーマットへ**

前回の投稿（パート 1 と パート 2）では

Protocol Buffers を解明し、データがどのようにコンパクトなバイナリへエンコードされるかを学びました。
しかし Protobuf はあくまでペイロードです。マイクロサービス間でこのデータを送受信するには
トランスポートプロトコル ― gRPC が必要になります。

多くの開発者は gRPC を日常的に使っていますが、実際にどのように動作しているかを 裏側まで眺める人は少数です。この記事では基本的な部分を越えて
gRPC のプロトコルスタック全体（上位のサービスアーキテクチャ・ストリーミングモデルから
低レベルの HTTP/2 フレームとバイト単位のワイヤフォーマットまで）を探っていきます。

コントラクトファースト哲学

gRPC の中心にあるのは「コントラクトファースト」です。REST では API ドキュメント（例：OpenAPI）が 後付けになることが多いですが、gRPC は Protocol Buffers (

.proto

package fruit.v1;

service FruitService {
  // Unary: 単純なリクエスト → レスポンス
  rpc GetFruit(GetFruitRequest) returns (Fruit);

  // Server streaming: 一つのリクエスト → 複数のレスポンス
  rpc ListFruits(ListFruitsRequest) returns (stream Fruit);

  // Client streaming: 多数のリクエスト → 一つのレスポンス
  rpc Upload(stream Fruit) returns (UploadSummary);

  // Bidirectional streaming: 双方向に多数のメッセージをやり取り
  rpc Chat(stream ChatMessage) returns (stream ChatMessage);
}

この定義が真実の源です。1 つのファイルから

protoc

ストリーミングモデル

gRPC がネイティブにサポートするストリーミングは重要な差別化要因です。
「チャンク転送エンコーディング」ではなく、ファーストクラスの API セマンティクスとして扱われます。

実際のデータに加えて、gRPC はメタデータ（HTTP ヘッダーに似たキー–バリューのリスト）も送信できます。
キーは大文字小文字を区別せず、

grpc-

-bin

• 認証 – 例：

  Authorization: Bearer <token>

• トレーシング – 例：

  transport-id: 12345

• インフラのヒント – 例：ロードバランサやプロキシへの指示

メタデータはクライアント側（呼び出し開始時）とサーバー側（ヘッダーとして開始時、トレーラーとして終了時）の両方から送信可能です。

裏側：トランスポート層

gRPC は HTTP/2 の上に構築されており、その高度な機能を利用してストリーミングを実現します。

• ストリーム – すべての gRPC 呼び出しは単一の HTTP/2 ストリームにマップされます。これにより、1 本の TCP 接続で数千のアクティブ呼び出しを複合でき、HTTP/1.1 のヘッド・オブ・ライン問題を回避します。
• URL 構築 – パスは

  .proto

  定義から自動生成されます：

  /{Package}.{Service}/{Method}

  。
  例:

  GetFruit

  の場合、URL は

  /fruit.v1.FruitService/GetFruit

  になります。

HTTP/2 フレームと gRPC 呼び出し

典型的な gRPC 呼び出しは 3 段階で構成され、それぞれが HTTP/2 フレームに対応します：

1. リクエストヘッダーとメタデータ（HEADERS フレーム）：

   :path

   、

   :method

   (

   POST

   ) と

   content-type: application/grpc

   を含みます。
2. データメッセージ（DATA フレーム）：実際の protobuf ペイロードです。
3. レスポンストレーラー（HEADERS フレーム）：呼び出しの最終状態を示します。

メタデータは HTTP/2 ヘッダーとして送信され、文字列値はそのまま、バイナリ値は

-bin

長さ付きフレーミング

各 HTTP/2 DATA フレーム内で、gRPC は protobuf メッセージを 5 バイトのヘッダーでラップします：

0

1

例 – 前述の

Fruit

• Protobuf ペイロード：

  08 96 01 12 05 41 70 70 6c 65

  （10 バイト）
• ヘッダー：

  00 00 00 00 0a

• 最終 gRPC フレーム：

  00 00 00 00 0a 08 96 01 12 05 41 70 70 6c 65
  

ヘッダーにより、受信側は各メッセージの正確なバイト数を読み取れるため、ストリーミングがスムーズになります。

ステータスとトレーラー

REST（HTTP ステータスコード）とは異なり、gRPC は常に HTTP 200 OK を返します。実際のアプリケーションステータスは最後の HTTP/2 トレーラーフレームで送られます：

grpc-status: 0
grpc-message: OK

grpc-status

NOT_FOUND

UNAVAILABLE

より詳細なエラー情報を提供するために、gRPC は protobuf メッセージ（

google.rpc.Status

grpc-status-details-bin

message Status {
  int32 code = 1;                 // 例：3=INVALID_ARGUMENT
  string message = 2;             // 開発者向けエラーテキスト
  repeated google.protobuf.Any details = 3;
}

クライアントはこのトレーラーをデコードして、構造化されたエラー情報を取得できます。

圧縮

モバイルネットワークなどで帯域幅を節約するために圧縮が有効です。

1. ネゴシエーション – クライアントは

   grpc-accept-encoding: br,gzip,identity

   を送ります。
2. エンコーディング選択 – サーバーは

   grpc-encoding: br

   （例）で応答します。
3. メッセージごとのフラグ – 5 バイトヘッダーのバイト 0 が

   1

   に設定されます。
4. ペイロード – 選択したアルゴリズムで圧縮されたデータです。

例：Brotli 圧縮された “Apple” ペイロード

01 00 00 00 0e <圧縮バイト列>

構造は変わらず、フラグと長さだけが異なります。

他のトランスポート

gRPC は通常 TCP/IP + HTTP/2 上で動作しますが、他のトランスポートでも動かせます：

• Unix ドメインソケット – ローカル IPC に最適でネットワークスタックをバイパスします。
• Named Pipes – Windows 版 Unix ソケット。

この柔軟性により、gRPC はコンポーネント間のユニバーサルな接続手段として機能し、世界中どこにいても、同じチップ上でも使用できます。

ブラウザギャップ（gRPC‑Web）

ブラウザは標準 gRPC に必要な低レベル HTTP/2 フレーミング制御（例：トレーラーの読み取り）ができません。gRPC‑Web はプロトコルを適応させます：

• トレーラーをデータストリーム本文内にエンコードし、ブラウザが HTTP トレーラーを読む必要がなくなります。
• テキストベース（Base64）エンコーディングをサポートしてバイナリ制約を回避します。

gRPC‑Web については次回の投稿で詳しく解説します。

締めくくりの考え方

gRPC は単なるシリアライズフォーマットではなく、API を定義・生成・消費する方法を標準化した完全なエコシステムです。

.proto

さらに読む

• gRPC ベストプラクティス – API 設計・バージョニング・パフォーマンスヒント
• 公式 gRPC ドキュメント – コアコンセプト、アーキテクチャ、ライフサイクル
• gRPC HTTP/2 トランスポート仕様書 – gRPC 用の公式 HTTP/2 スペック
• Protocol Buffers（パート 1 & 2） – Protocol Buffers フォーマットの詳細解析