SOAP / REST / gRPC の選び方 — 内部通信とエッジ API で違う

3 プロトコルの歴史的背景

年	プロトコル	背景
1998	SOAP	企業間接続 (B2B)、エンタープライズ要件 (トランザクション・セキュリティ)
2000	REST	原案は Roy Fielding 博士論文、HTTP 準拠でシンプルに
2016	gRPC	Google 内部の Stubby を OSS 化、マイクロサービス間通信の高性能化

3 つは同時期に競合しているわけでなく、時代のニーズとともに進化してきました。 今は 3 つが用途別に併存しているのが実情です。

一行比較

観点	SOAP	REST	gRPC
メッセージ形式	XML	JSON / XML / …	Protocol Buffers (バイナリ)
トランスポート	HTTP / SMTP / TCP	HTTP	HTTP/2
スキーマ定義	WSDL (必須)	OpenAPI (推奨、必須ではない)	.proto (必須)
速度	遅い	中	速い
人が読める	○ (XML)	◎	✕ (バイナリ)
ストリーミング	無	SSE / WebSocket (別途)	ネイティブ (uni/bi/stream)
主な用途	B2B レガシー、金融	Web API 一般	マイクロサービス間

SOAP

概要

XML でフォーマットされたメッセージを HTTP (や SMTP / TCP) で送受信するプロトコル。WSDL で IF を定義。

いつ使う

• 既存の SOAP 資産 (レガシー B2B 接続) と連携する必要がある
• WS-* 系の強い要件 (WS-Security、WS-Transaction) が必須

使わない理由

• XML のオーバーヘッド大
• REST / gRPC に比べ開発生産性で劣る
• 新規プロジェクトで採用する積極的理由はほぼ無い

現代での位置づけ

銀行・保険の基幹システム連携、政府・公共機関の電子取引など、長寿命システムの保守で接する機会がある程度。 新規開発で第一選択に挙がることはまれ。

REST

概要

HTTP のメソッド (GET / POST / PUT / DELETE / PATCH) とリソース URL (/users/123) を使って CRUD を表現するアーキテクチャスタイル。 通常 JSON でデータを交換。

いつ使う

• 外部公開 API (パートナー / 開発者向け SDK)
• フロントエンド (SPA / モバイル) からのアクセス
• とにかく 分かりやすさ ・ ブラウザからもデバッグ可能性 重視
• 第三者のライブラリ・ツール (Postman / curl) との親和性

サンプル

GET /api/v1/users/123 HTTP/1.1
Authorization: Bearer xxx

→ 200 OK
Content-Type: application/json
{
  "id": 123,
  "name": "Taro",
  "email": "taro@example.com"
}

落とし穴

• 真の RESTful (HATEOAS) まで厳守する実装は少ない。実質「HTTP + JSON」のことを REST と呼ぶ
• バージョニング (/v1/ vs ヘッダ) の統一ルールを早めに決める
• レスポンス形式の揺れ (snake_case / camelCase) で後悔する

エコシステム

OpenAPI 3.0 (旧 Swagger) が事実上の標準。Spec-first でサーバ・クライアントコードを自動生成するフロー (OpenAPI Generator / openapi-typescript 等) が普及。

gRPC

概要

Google が開発した RPC フレームワーク。Protocol Buffers (.proto) でスキーマを定義し、HTTP/2 上でバイナリ通信。

いつ使う

• マイクロサービス間の社内通信 (低レイテンシ重要)
• 複数言語 (Java / Go / Python / Node / Ruby / C++ …) のクライアント / サーバを統一スキーマで管理
• 双方向ストリーミング (リアルタイムデータ配信)
• ネットワーク帯域が限られる組み込み / モバイル

サンプル

// user.proto
syntax = "proto3";
package example;

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc StreamUsers (stream GetUserRequest) returns (stream User);
}

message GetUserRequest { string id = 1; }
message User { string id = 1; string name = 2; string email = 3; }

# コード生成 (Java)
protoc --java_out=./src user.proto

落とし穴

• ブラウザから直接呼べない (HTTP/2 + binary のため) → gRPC-Web / envoy proxy が必要
• デバッグが難しい (バイナリ)、Postman / curl は代替ツール (grpcurl) が必要
• 大規模組織では proto ファイルの管理方針 (モノレポ or buf registry) を決めないと無法地帯

エコシステム

• Buf (buf.build): proto 管理のデファクト。CI で破壊的変更検出
• Connect: gRPC + REST + 開発体験の良さを兼ねた新しいプロトコル (gRPC 互換、ブラウザ対応)- Envoy / Istio: サービスメッシュで gRPC トラフィックを管理## 選び方チャート``` API の相手は？ ├── 外部 (パートナー / 一般開発者) → REST (OpenAPI) ├── ブラウザ / モバイル → REST ├── 社内マイクロサービス → gRPC or REST │ ├── 性能優先・多言語 → gRPC │ └── シンプルさ優先 → REST └── レガシー B2B (WS-*) → SOAP (仕方なく)

実際の大きなシステムでは 混在 が普通:

- エッジ (外部公開) = REST
- 内部マイクロサービス = gRPC
- 旧 B2B 連携 = SOAP (隔離)

## 2024+ の動向

- REST は依然として外部 API の第一選択。GraphQL との競合も落ち着きつつあり、REST + OpenAPI が主流
- gRPC はマイクロサービス内部で確固たる地位。Connect が選択肢を広げた
- SOAP は新規採用はほぼ無い。既存システムの保守コストを削減する方向
- tRPC (TypeScript 内 API) や GraphQL (柔軟クエリ) など、用途別特化の選択肢も増加

## まとめ

- 「どれが最強か」ではなく 相手と目的で選ぶ
- 外部公開・ブラウザ・モバイル → REST (OpenAPI で型安全化)
- 社内マイクロサービス間 → gRPC (Buf で管理)
- B2B レガシー → SOAP (接続する必要があるときだけ)
- 混在運用になるのが普通、ゲートウェイで変換するパターンも多い