【保存版】モダンAPI入門：GraphQL, gRPC, WebSocket, HTTP/3の基礎と選び方
1 はじめに
Web開発の現場では長らく「REST API」が標準として君臨してきましたが、近年、アプリケーションの複雑化や通信環境の変化に伴い、新しい通信技術（モダンAPI）の採用が進んでいます。
「モバイル回線でも高速に表示したい」「リアルタイムなチャット機能を実装したい」「マイクロサービス間の通信を最適化したい」――こうした現代の課題は、従来のRESTだけでは解決が難しくなっています。
本記事では、次世代のスタンダードとなりつつあるGraphQL, gRPC, WebSocket、そして基盤となるプロトコルHTTP/3 (QUIC)について、それぞれの特徴と使いどころを解説します。
2 ビギナー向け・ドキュメント
まずは、各技術が「何のために生まれたのか」という背景と基本概念を整理します。
1. GraphQL (グラフ・キューエル)
Meta (旧Facebook) が開発したクエリ言語です。 * 特徴: クライアント（フロントエンド）が「欲しいデータ」を具体的に指定して取得できます。 * RESTとの違い: RESTでは複数のURLを叩く必要があった情報を、1回のリクエストでまとめて取得できます（Overfetching/Underfetchingの解消）。
2. gRPC (ジー・アールピーシー)
Googleが開発した、高性能なRPC（Remote Procedure Call）フレームワークです。 * 特徴: Protocol Buffersというバイナリ形式を使ってデータをシリアライズ（軽量化）するため、通信が非常に高速です。 * 用途: 主にサーバー同士の通信（マイクロサービス間）で威力を発揮します。
3. WebSocket (ウェブソケット)
サーバーとクライアント間で「双方向通信」を実現するプロトコルです。 * 特徴: 一度接続を確立すると、その後はサーバー側から能動的にデータをプッシュできます。 * 用途: チャット、オンラインゲーム、株価チャートなど、リアルタイム性が求められる機能。
4. HTTP/3 (QUIC)
Web通信の基盤であるHTTPプロトコルの最新メジャーバージョンです。 * 特徴: 従来のTCPではなく、UDPベースの「QUIC」という技術を採用。通信の確立が速く、パケットロス時の遅延（Head-of-Line Blocking）を防ぎます。
公式ドキュメント・推奨リソース
- GraphQL公式サイト: 入門ガイドやPlaygroundが充実しています。
- gRPC公式サイト: 各言語（Go, Java, Python等）ごとの実装ガイドがあります。
- MDN Web Docs: WebSocket API: ブラウザ側の実装仕様について詳細に書かれています。
3 会話集
技術選定の会議や、メンバーへの説明で使える「比較」と「例え話」です。
ケース1：フロントエンドエンジニアから「GraphQLを使いたい」と言われたら
エンジニア: 「RESTだと画面表示に必要なデータを集めるのにAPIを3回も叩かないといけなくて... GraphQLにしませんか？」
あなた: 「なるほど。『ビュッフェ形式』にしたいということだね。」
エンジニア: 「ビュッフェですか？」
あなた: 「RESTは定食メニューだから、食べたくない小鉢もついてくるし、足りなければ別の定食も頼まないといけない（Over/Underfetching）。でもGraphQLなら、好きな具材を好きなお皿に、一度で盛ってこれるからね。通信回数が減ってスマホユーザーにはメリットが大きそうだ。」
ケース2：マイクロサービス化で「gRPC」を提案する場合
あなた: 「バックエンドのサービス間通信はRESTのJSONではなく、gRPCに切り替えましょう。」
上司: 「JSONじゃダメなのか？」
あなた: 「JSONは人間には読みやすいですが、機械が読むにはデータが重すぎます。gRPCは『圧縮された暗号のようなバイナリデータ』を送るため、サイズが小さく爆速です。内部通信のような大量のやり取りが発生する場所では、この軽さがシステム全体の性能を左右します。」
4 より深く理解する為に
各技術の適材適所を理解するための比較と、HTTP/3の革新性について深掘りします。
技術選定マトリクス
| 技術 | データ形式 | 主な用途 | 強み | 弱点 |
|---|---|---|---|---|
| REST | JSON | 一般的なWeb API | シンプル、キャッシュが容易 | 通信回数が増えがち |
| GraphQL | JSON | モバイルアプリ、BFF | 必要なデータだけ取得、型定義 | クエリが複雑化、キャッシュが難しい |
| gRPC | Protocol Buffers (バイナリ) | マイクロサービス間通信 | 高速、厳格な型定義 | ブラウザから直接扱いづらい |
| WebSocket | テキスト/バイナリ | チャット、通知 | リアルタイム双方向 | サーバーのリソース消費が大きい |
HTTP/3 (QUIC) が解決する「Head-of-Line Blocking」問題
従来のHTTP/2（TCP）では、パケットが一つでも欠落すると、その後ろのデータがすべて待たされる「渋滞」が起きていました。 HTTP/3（UDPベースのQUIC）では、各ストリームが独立しているため、一つのパケットがロスしても、他のデータの転送は止まりません。 これにより、不安定なモバイル回線でもサクサク動くWeb体験が可能になります。
5 関連ワード
開発現場で頻出する周辺用語です。
| 用語 | 解説 |
|---|---|
| Schema (スキーマ) | データの構造定義。GraphQLやgRPCでは、あらかじめ「どんなデータを送るか」を厳格に定義する必要がある（Schema First開発）。 |
| Protocol Buffers (Protobuf) | gRPCで使用されるデータの直列化フォーマット。XMLやJSONよりはるかにサイズが小さく、パース（解析）が速い。 |
| N+1問題 | GraphQLなどで発生しやすいパフォーマンス問題。データ一覧を取得した後、その個々のデータに関連する情報を取得するために、無駄に大量のクエリが発行されてしまう現象。 |
| BFF (Backend For Frontend) | フロントエンド専用のバックエンド。ここで複数のマイクロサービス（gRPCなど）を束ねて、フロントエンドにはGraphQLで返す、といった構成が人気。 |
6 要点チェック
モダンAPI技術導入の際の判断基準を整理しましょう。
- [ ] 柔軟性: クライアント側でデータ要求をコントロールしたいなら GraphQL。
- [ ] パフォーマンス: 内部通信や速度最優先なら gRPC。
- [ ] 即時性: サーバーからユーザーへ通知を送りたいなら WebSocket。
- [ ] 次世代通信: 不安定な回線でも高速に通信させたいなら HTTP/3 の対応を検討する。
- [ ] 型安全性: GraphQLとgRPCはスキーマ（型）があるため、開発時のミスを減らしやすい。