Protobuf が『分散システムのデファクト』を維持
Protocol Buffers（Protobuf）はGoogleが開発した高速バイナリシリアライゼーション規格で、gRPCの基盤として広く採用されています。JSON比3〜10倍速・サイズ1/5の効率を実現し、マイクロサービス間通信・モバイルアプリ・IoTデバイスで本番運用されます。Google・Netflix・Uber等が大規模採用、新規プロジェクトでも依然として主要な選択肢として2026年定着しています。
採用すべき5つのシグナル
- マイクロサービス間通信の効率化が必要
- モバイルアプリで通信量を削減したい
- 強い型安全性で API契約を担保したい
- 多言語クライアントの統一的なSDK
- gRPC採用前提
主要機能
- Schema定義: .protoファイルでメッセージ定義
- Code Generation: 各言語のSDK自動生成
- 後方互換性: フィールド追加・削除でも互換維持
- バイナリ効率: JSON比5倍小さい
- パーシング速度: JSON比5〜10倍速
- 多言語対応: Java/C++/Python/Go/JS/Rust等
JSON/MessagePack/Protobuf比較
JSON: テキスト・人間可読・サイズ大きい・遅い・ブラウザ標準。
MessagePack: バイナリ・スキーマレス・JSON互換・中速。
Protobuf: バイナリ・スキーマあり・最速・型安全・コード生成。
Cap'n Proto: Protobuf類似・ゼロコピー・新興。
使い分け: ブラウザ向けJSON・モバイル/サービス間Protobuf。
実装パターン
(1) .protoファイル定義: message User { string name = 1; int32 age = 2; }
(2) コード生成: protoc --java_out=... --python_out=...
(3) シリアライズ: user.SerializeToString()
(4) デシリアライズ: user.ParseFromString(bytes)
(5) gRPC統合: serviceとして公開
本番採用の判断基準
- 本番実績: Google・Netflix・Uber・各種大企業
- パフォーマンス: JSON比5〜10倍速・大規模通信で実証
- 多言語SDK: 主要言語すべて対応
- 後方互換性: フィールド変更でも既存クライアント維持
- 移行コスト: JSON APIからの段階移行は可能
採用しない方が良いケース
- ブラウザ向けAPI（JSON が標準）
- 小規模アプリ・通信量が課題でない
- スキーマ進化が頻繁すぎる
- 開発者がProtobuf未経験
- デバッグ重視（バイナリで可読性なし）
実装で詰まる3つの落とし穴
- スキーマ管理: .protoファイルのバージョン管理・配布
- フィールド番号: 一度使った番号は変更しない
- 後方互換性違反: required→optional等の変更
30日学習プラン
- 1週目: Protobuf基礎・.proto定義・コード生成
- 2週目: gRPC統合・サービス定義
- 3週目: 後方互換性・スキーマ進化
- 4週目: 本番デプロイ・性能計測
関連リンク
gRPCは gRPC実践、API設計は API設計選び方、マイクロサービスは マイクロサービス実践 を参照してください。