Day 048 — gRPC/Protocol Buffers実装: サービス定義からのコード生成の仕組みと標準ライブラリnet/rpcによる疑似体験

📚 背景知識（読んでから問題へ）

Day 047までのジェネリクス応用で「型集合」というコンパイル時の抽象化を扱いましたが、今日のテーマはプロセス境界を越える通信、すなわちサービス定義からコードを生成するという別種の抽象化です。

gRPCは「.protoファイルにサービスとメッセージを1回書けば、Go・Java・Python・TypeScriptなど複数言語のクライアント/サーバーコードを自動生成できる」という契約駆動（contract-first）の思想に基づくRPCフレームワークです。典型的な.proto定義は次のようになります。

syntax = "proto3";
package greeter;

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

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

このファイルに対してprotoc（Protocol Buffersコンパイラ）と2つのプラグインを実行すると、以下のコードが自動生成されます。

• protoc-gen-go: HelloRequest・HelloReplyに対応するGoの構造体（各フィールドへのgetterメソッド、proto.Marshal/proto.Unmarshalで使われるバイナリシリアライズ用のメタデータ付き）
• protoc-gen-go-grpc: GreeterServerインターフェース（開発者が実装すべきメソッド群）、GreeterClientインターフェース（クライアントが呼び出せるメソッド群）、RegisterGreeterServer関数、NewGreeterClientコンストラクタ

つまり開発者が手で書くのは「.protoファイル」と「GreeterServerインターフェースの実装（ビジネスロジック）」だけで、シリアライズ・デシリアライズ・HTTP/2フレーミング・言語間のスタブコードはすべて生成されます。

net/rpcはGo標準ライブラリに含まれる、コード生成なしのシンプルなRPCパッケージです。gRPCほどの機能（HTTP/2多重化・双方向ストリーミング・多言語対応）はありませんが、「サービスを定義する」「メソッドのシグネチャに規約がある」「クライアントはメソッド名を文字列で呼び出す」という、RPCフレームワーク共通の骨格を体験するには十分です。net/rpcでRPCとして公開されるメソッドには、以下の規約があります。

• メソッドはエクスポートされている（大文字始まり）
• 引数は2つ: (args *ArgsType, reply *ReplyType) error
• 第2引数（reply）はポインタ型でなければならない
• 戻り値はerror型1つだけ

この規約はまさに、gRPCでprotoc-gen-go-grpcが生成するGreeterServerインターフェースのメソッドシグネチャ（SayHello(ctx context.Context, req *HelloRequest) (*HelloReply, error)）と同じ発想——「引数と戻り値の型を固定した規約に沿わせることで、フレームワーク側がリフレクションや生成コードを使って任意のメソッドを一様に呼び出せるようにする」——の縮小版です。

📝 問題

1. 上記の.proto定義（Greeterサービス、SayHelloメソッド）に対してprotoc + protoc-gen-go + protoc-gen-go-grpcを実行した場合、生成される主要な要素（メッセージ構造体・サーバー側インターフェース・クライアント側インターフェース・登録関数）をそれぞれ1〜2文で説明してください。
2. 標準ライブラリのnet/rpcだけを使い、Greeterサービス相当の疑似gRPC体験を実装してください。要件:
   • HelloRequest{Name string} / HelloReply{Message string}という、.protoのmessageに相当する構造体を定義する
   • net/rpcの規約に従うSayHelloメソッドを実装する（Nameが空文字列の場合はエラーを返す）
   • main関数内でサーバーとクライアントの両方を1プロセス内に立ち上げ、client.Call("Greeter.SayHello", ...)で呼び出して結果を表示する
   • 空文字列を渡した場合にエラーが返ることも確認する
3. 以下のコードは(2)と似た実装ですが、go run main.goを実行するとサーバーが正しく起動しません。何が問題か指摘し、修正してください。

   type Greeter struct{}
   
   type HelloRequest struct {
   	Name string
   }
   
   type HelloReply struct {
   	Message string
   }
   
   // 引数の型に注目
   func (g *Greeter) SayHello(req HelloRequest, reply HelloReply) error {
   	reply.Message = "Hello, " + req.Name + "!"
   	return nil
   }

4. net/rpcと実際のgRPCの違いを3点（トランスポート層・シリアライズ形式・多言語対応）挙げ、実務で「まずnet/rpcのような軽量な手段で十分な場面」と「gRPCの導入コスト（.proto管理・コード生成パイプライン・外部依存）を払ってでも採用すべき場面」をそれぞれ1つ具体的に述べてください。

🔍 ヒント（段階的開示）

📋 コピーpackage main

import (
	"fmt"
	"log"
	"net"
	"net/rpc"
)

type Greeter struct{}

type HelloRequest struct{ Name string }
type HelloReply struct{ Message string }

func (g *Greeter) SayHello(req *HelloRequest, reply *HelloReply) error {
	// TODO: req.Name が空文字列ならエラーを返す
	// TODO: reply.Message を組み立てる
	return nil
}

func main() {
	rpc.Register(new(Greeter))
	listener, _ := net.Listen("tcp", "127.0.0.1:0")
	go func() {
		for {
			conn, err := listener.Accept()
			if err != nil {
				return
			}
			go rpc.ServeConn(conn)
		}
	}()

	client, _ := rpc.Dial("tcp", listener.Addr().String())
	var reply HelloReply
	// TODO: client.Call("Greeter.SayHello", ...) を呼ぶ
	fmt.Println(reply.Message)
}

✅ 模範解答

(1) protocが生成する主要な要素:

• メッセージ構造体（protoc-gen-goが生成）: HelloRequest・HelloReplyという、.protoのmessage定義に対応するGo構造体。各フィールドへのGetName()のようなgetterメソッドと、proto.Marshal/proto.Unmarshalによるバイナリシリアライズに必要な内部メタデータを持つ
• サーバー側インターフェース（protoc-gen-go-grpcが生成）: GreeterServerインターフェース。SayHello(context.Context, *HelloRequest) (*HelloReply, error)のようなメソッドシグネチャが定義され、開発者はこれを実装した構造体を用意する
• クライアント側インターフェース（同上）: GreeterClientインターフェースと、それを実装する非公開の構造体・NewGreeterClient(conn)コンストラクタ。呼び出し側はこのインターフェース越しにメソッドをまるでローカル関数のように呼び出せる
• 登録関数（同上）: RegisterGreeterServer(s *grpc.Server, srv GreeterServer)。grpc.Serverにサービス実装を紐付け、gRPCのリクエストルーティングテーブルに登録する

(2) net/rpcによる疑似gRPC体験（完全なコード）:

📋 コピーpackage main

import (
	"fmt"
	"log"
	"net"
	"net/rpc"
)

// Greeter は「.proto の service Greeter { rpc SayHello(...) }」から
// protoc-gen-go-grpc が生成する GreeterServer インターフェースに相当する、
// 手書きの疑似スタブ。
type Greeter struct{}

// HelloRequest / HelloReply は protoc-gen-go が
// message HelloRequest { string name = 1; } から生成する構造体に相当する。
type HelloRequest struct {
	Name string
}

type HelloReply struct {
	Message string
}

// SayHello は net/rpc が要求する規約
// 「エクスポートされたメソッド、引数は (args *ArgsType, reply *ReplyType) error」
// を満たす。実際のgRPCではこのメソッドは
// func (g *Greeter) SayHello(ctx context.Context, req *HelloRequest) (*HelloReply, error)
// という、context.Contextを第1引数に取る形で書く。
func (g *Greeter) SayHello(req *HelloRequest, reply *HelloReply) error {
	if req.Name == "" {
		return fmt.Errorf("name is required")
	}
	reply.Message = "Hello, " + req.Name + "!"
	return nil
}

func main() {
	// --- サーバー側 ---
	if err := rpc.Register(new(Greeter)); err != nil {
		log.Fatal(err)
	}

	listener, err := net.Listen("tcp", "127.0.0.1:0") // ポート0 = OSに空きポートを割り当てさせる
	if err != nil {
		log.Fatal(err)
	}
	defer listener.Close()

	go func() {
		for {
			conn, err := listener.Accept()
			if err != nil {
				return // listener.Close() された後はここで抜ける
			}
			go rpc.ServeConn(conn)
		}
	}()

	// --- クライアント側 ---
	client, err := rpc.Dial("tcp", listener.Addr().String())
	if err != nil {
		log.Fatal(err)
	}
	defer client.Close()

	var reply HelloReply
	if err := client.Call("Greeter.SayHello", &HelloRequest{Name: "Gopher"}, &reply); err != nil {
		log.Fatal(err)
	}
	fmt.Println(reply.Message)

	// 空文字列を渡すとサーバー側のバリデーションでエラーになることを確認する
	var errReply HelloReply
	err = client.Call("Greeter.SayHello", &HelloRequest{Name: ""}, &errReply)
	fmt.Println("エラーケース:", err)
}

実行結果（実測。go1.21以降で確認済み）:

📋 コピーHello, Gopher!
エラーケース: name is required

(3) バグの指摘と修正:

問題のコードはSayHelloの引数が(req HelloRequest, reply HelloReply) errorとなっており、第2引数replyがポインタ型ではありません。net/rpcの規約では「第2引数はポインタでなければならない」（サーバー側が呼び出し結果をこの引数越しに書き込んで返すため、値渡しでは呼び出し元に結果が伝わらない）ため、rpc.Registerはこのメソッドを呼び出し可能なRPCメソッドとして登録できません。

📋 コピー$ go run main.go
2026/09/14 12:00:00 rpc.Register: type Greeter has no exported methods of suitable type
2026/09/14 12:00:00 rpc.Register: type Greeter has no exported methods of suitable type
exit status 1

（実測。go1.26で確認済み。メッセージが2回出るのは、net/rpc内部の登録処理が一度log.Printlnでログ出力し、続けてRegisterが返したerrorをこのコード自身がlog.Fatal(err)でも出力しているためです。Goのバージョンによって行数や文言は多少異なる場合がありますが、「no exported methods of suitable type」（この型には適切なシグネチャのエクスポート済みメソッドが1つもない）という趣旨のメッセージが出る点は共通です。）

修正は、第1引数・第2引数をともにポインタ型に揃えることです。

📋 コピーfunc (g *Greeter) SayHello(req *HelloRequest, reply *HelloReply) error {
	reply.Message = "Hello, " + req.Name + "!"
	return nil
}

(4) net/rpcと実際のgRPCの違い（3点）と使い分け:

• net/rpcのような軽量な手段で十分な場面: 社内の小規模なGo製バッチジョブ群同士が、同じGoプロセス群の中だけで単純なジョブ委譲を行うようなケース。将来的に他言語クライアントを想定しておらず、.proto管理やコード生成パイプラインを整備するコストに見合わない小規模なツールに向く
• gRPC導入コストを払ってでも採用すべき場面: マイクロサービス間通信で、Goで書かれたサービスとJava/Pythonで書かれたサービスが混在し、かつ高頻度・低レイテンシな通信が要求される場合。.protoをサービス間の契約として一元管理でき、双方向ストリーミングやデッドライン伝播などgRPC標準機能が実務要件に直結する

🪜 Step-by-Step 解説

💡 設計思想・なぜこう書くのか

🌐 他言語との比較

🏆 実務での使いどころ

• マイクロサービス間の内部通信: 複数の言語で書かれたサービス群が混在する組織で、.protoをサービス間契約の「単一の真実源」として管理し、破壊的変更をコードレビューの中で検出する
• ストリーミングが必要なAPI: リアルタイムのログ配信・進捗通知など、双方向ストリーミングが必要な場面ではgRPCのストリーミングRPCが素のREST/JSONより自然に設計できる
• 公式ツールチェーンへの接続: 実際に手を動かす場合はbrew install protobuf（または各OSのパッケージマネージャ）でprotoc本体を、go install google.golang.org/protobuf/cmd/protoc-gen-go@latestとgo install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latestでGo用プラグインを導入し、google.golang.org/grpcモジュールをgo.modに追加するところから始める

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: 実際にprotocとgoogle.golang.org/grpcをインストールできる環境があれば、今日の.proto定義から本物のGreeterServer/GreeterClientを生成し、net/rpc版と比べて「引数にcontext.Contextが増える」「ストリーミングRPCが追加できる」といった違いを直接観察してみましょう
• 次回予告: ミドルウェア設計パターン — http.Handlerのチェーン設計を扱います

🎯 自己評価

自分の回答

気づき・メモ