GraphQL — クライアントが欲しいデータだけ取れる柔軟なAPI

GraphQLは2012年にFacebook（現Meta）が社内開発を始め、2015年にOSS化したAPIクエリ言語＆ランタイムです。「クライアントが欲しいフィールドを指定し、サーバはその通りに返す」という設計で、RESTでは複雑になりがちなモバイルアプリ・複合UIのデータ取得を劇的にシンプルにしました。現在はGraphQL Foundation（Linux Foundation配下）が運営し、Facebook、GitHub、Shopify、Airbnbなどで広く採用されています。

この記事の目次

1. GraphQLの基本
2. RESTとの比較
3. 代表的なフレームワーク
4. GraphQLの落とし穴と対策
5. まとめ

GraphQLの基本

GraphQLはサーバ側でスキーマ（型定義）を宣言し、クライアントはそのスキーマに従ってクエリを書きます。「ユーザ名と直近の投稿3件だけ欲しい」のような細かい要求を、1リクエストで取得できるのが大きな特徴です。

RESTのように /users、/users/:id/posts のように複数エンドポイントを叩く必要がなく、全部 /graphql という単一エンドポイントへPOSTし、本文にクエリを書きます。操作はクエリ（読み取り）とミューテーション（書き込み）、リアルタイムはサブスクリプションで明確に分けます。

RESTとの比較

GraphQLの最大の利点は「Over-fetching / Under-fetching の解消」。RESTでは「APIが返す情報の一部しか使わない（オーバーフェッチ）」「複数エンドポイントを叩く必要がある（アンダーフェッチ）」が起きがちですが、GraphQLならクライアントが欲しい分だけを正確に1リクエストで取れます。

一方、HTTPキャッシュ（GET URL単位のキャッシュ）が効きにくい、N+1クエリ問題が起きやすい、公開APIではバージョニング・レート制限の設計が複雑になる、といったRESTにはない難しさもあります。

代表的なフレームワーク

GraphQL の代表的なツールチェーンは Apollo（サーバ＆クライアント両方）。Node.jsベースで圧倒的に普及しており、React/Vue/Angularのフロントエンド統合からサーバ実装まで一通り揃います。

Hasuraは「PostgreSQLなどのDBから自動でGraphQLサーバを生成する」OSSで、開発スピード重視のスタートアップに人気。RelayはFacebook純正のクライアントで大規模本格運用向き。規模・要件に応じて選び分けます。

GraphQLの落とし穴と対策

GraphQLで初心者がハマるのが「N+1クエリ問題」。ユーザ一覧 + 各ユーザの投稿、というクエリを素直に書くと、ユーザ取得1回＋投稿取得N回のSQLが走って遅くなります。対策は DataLoader と呼ばれるバッチ化＆キャッシュのライブラリで、Apolloでは標準的に推奨されています。

公開GraphQL APIでは、悪意あるクエリでサーバを落とす攻撃も可能。クエリの深さ制限・複雑度制限（GraphQL Query Cost Analysis）、レート制限などを必ず設定するのが本番運用の鉄則です。

まとめ

GraphQLはモバイル・複合UI時代のAPI設計の有力選択肢として、現代Web開発に定着しました。RESTと役割を分担しつつ、適切な場面で使えば開発生産性とユーザー体験を大きく改善できます。

※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。