GraphQL vs REST API、実際のプロジェクトで使い分けた話【2026年版】
GraphQLとREST APIの違いを初心者向けに比較表で解説。フリーランスエンジニアの実体験から、どちらを選ぶべきか・いつGraphQLを使うべきかの判断基準をまとめました。
※当サイトはアフィリエイトプログラムに参加しています。記事内のリンクから商品を購入すると、当サイトに報酬が支払われることがあります。詳しくはプライバシーポリシーをご覧ください。
「GraphQLとRESTって、何が違うの？どっちを覚えればいいの？」
正直、当時の僕も半年くらい迷っていました。「GraphQLの方がモダンらしい」「でもRESTが主流らしい」「結局どっちを勉強すれば…」という状態で、とりあえずRESTを覚えてその後GraphQLも触ったんですが——どっちを選ぶかは、用途次第でした。
結論から言うと、初心者が最初に学ぶべきはREST API。GraphQLは「チーム規模」と「データ構造の複雑さ」が一定水準を超えたときに初めて輝く技術です。
4月に参画したSaaSの案件でGraphQLが採用されていて、久しぶりにがっつり触りました。正直「このプロジェクトにはRESTの方が合ってたな」という感想もあります。その話も後で書きます。
REST APIとは何か
REST APIは「URLとHTTPメソッドでデータのやり取りを行う」シンプルな設計です。
GET /users/123 → ユーザー情報を取得
POST /users → ユーザーを作成
PUT /users/123 → ユーザー情報を更新
DELETE /users/123 → ユーザーを削除たとえばユーザー情報を取得すると、こんなレスポンスが返ってきます。
GET /users/123
{
"id": 123,
"name": "中村ソウマ",
"age": 33,
"email": "souma@example.com",
"role": "admin",
"created_at": "2024-03-15"
}シンプルで直感的。ブラウザのURLバーで直接叩けるし、curl一発で動作確認できます。
ここがポイントなんですが、RESTはHTTPの仕様をそのまま使っているので、Web開発を学んでいれば自然と馴染める設計思想です。REST APIの基礎は別の入門記事で詳しく解説しています。
GraphQLとは何か
GraphQLはFacebookが2015年に公開したクエリ言語です。**「クライアント側が必要なフィールドを指定してデータを取る」**のが最大の特徴です。
# GraphQLのクエリ例
query {
user(id: 123) {
name
age
posts {
title
createdAt
}
}
}このクエリを送ると、こう返ってきます。
{
"data": {
"user": {
"name": "中村ソウマ",
"age": 33,
"posts": [
{ "title": "GraphQL入門", "createdAt": "2026-04-15" }
]
}
}
}注目してほしいのは、emailもroleもcreated_atも返ってきていない点です。必要なname、age、postsだけを取ってきています。これをオーバーフェッチの解消といいます。
REST vs GraphQL 比較表
| 項目 | REST API | GraphQL |
|---|---|---|
| エンドポイント | 複数（/users, /posts…） | 単一（/graphql） |
| データ取得 | サーバー側が決めた形式 | クライアントが必要なフィールドを指定 |
| オーバーフェッチ | 起きやすい | 起きにくい |
| アンダーフェッチ | 複数リクエストが必要な場合も | 1リクエストで関連データをまとめて取得 |
| 型システム | 任意（OpenAPIで補完可） | スキーマ定義が標準 |
| 学習コスト | 低い | 中〜高 |
| デバッグ方法 | ブラウザ・curl で直接確認 | GraphQL Playground 等の専用ツール |
| キャッシュ | ブラウザ標準キャッシュが使いやすい | 別途設定が必要（Apollo Client等） |
| 主な採用事例 | ほとんどのWebサービス | GitHub, Shopify, Netlify, Twitter |
ここがポイントなんですが、**どちらが「優れている」かではなく、「どちらが今のプロジェクトに合っているか」**という観点で選ぶことが重要です。
実際に使い分けた体験談：4月の案件でわかったこと
GW前の4月上旬に参画したSaaS案件で、バックエンドがGraphQL（Apollo Server）でした。フロントはNext.jsで、僕は主にフロントエンドを担当したのでApollo Clientを久しぶりに書くことになりました。
良かった点:
- 画面ごとに「必要なデータだけ取る」クエリを書けるので、APIコールの無駄がない
- バックエンドとGraphQLスキーマを型定義として共有できるので、TypeScriptとの親和性が高い
- ユーザー情報＋その投稿一覧を1リクエストで取れる
微妙だった点（本音）:
正直に書きます。
- 小〜中規模のSaaSで、エンドポイントの数がそこまで多くなかった。RESTでもN+1問題は起きなかったと思う
- Apollo Clientの設定・キャッシュ戦略の学習コストが想定より高かった
- バックエンドエンジニアがGraphQLに不慣れだったので、リゾルバ（データを取ってくる関数）の設計が複雑になった
（ここを書くのに30分悩んだ）
正直に言うと、このプロジェクトのサイズではRESTの方がシンプルで良かったと思っています。GraphQLの恩恵より、学習コストと設定の複雑さの方が上回っていました。
GraphQLが輝くケース、RESTが合うケース
GraphQLを選ぶべき状況
- フロントエンドが複数プラットフォーム（Web・iOS・Androidで同じAPIを使い回す）
- 画面ごとにデータの組み合わせが大きく異なる（ECサイトのトップページ、商品ページ、マイページで必要なデータが全然違う）
- チームが大きく、フロント/バックエンドが明確に分かれている
- GitHub・Shopifyのような外部開発者向けのAPIを公開する
GitHub APIもShopify Admin APIもGraphQLを採用しています。理由は「利用者ごとに必要なデータが違うから」です。
RESTを選ぶべき状況
- 小〜中規模のWebアプリやSaaS
- APIエンドポイントの数が20〜30以下で管理できる
- チームにGraphQLの経験者がいない
- シンプルさとメンテナンス性を優先したい
端的に言えば、ほとんどの初心者〜中級者の個人開発・小規模プロダクトはRESTで十分です。
初心者はどちらを先に学ぶべきか
これは迷わずREST APIを先に学んでください。理由は3つです。
- REST APIの概念を理解しないと、GraphQLの価値もわからない。GraphQLが解決しようとしている「オーバーフェッチ問題」「N+1問題」を理解するには、まずRESTの仕組みを知る必要があります。
- 転職・フリーランス案件の大半はREST。GraphQLを採用しているプロジェクトも増えていますが、まだREST APIが主流です。
- 学習コストが低い。RESTはブラウザのURLバーで動作確認できますが、GraphQLは専用ツールが必要です。
プログラミング的に言うなら、「GraphQLはRESTの問題を解決するための上位互換ではなく、別の道具」です。ハンマーとドライバーのどちらが優れているかを議論するより、状況に応じて使い分けることが大事です。
JavaScript入門でAPI通信の基本を学んだ後、まずRESTを実装してみることをおすすめします。バックエンドとフロントエンドの役割を理解するには、この記事も参考になります。
GraphQLの実装を試してみたい人へ
試すならApollo Server + Apollo Clientの組み合わせが定番です。Node.js環境があれば、以下のコードで動作確認できます。
// Apollo Serverの最小構成（Node.js）
import { ApolloServer } from "@apollo/server";
import { startStandaloneServer } from "@apollo/server/standalone";
// スキーマ定義
const typeDefs = `
type User {
id: ID!
name: String!
age: Int!
}
type Query {
user(id: ID!): User
users: [User!]!
}
`;
// リゾルバ（実際にデータを返す関数）
const users = [
{ id: "1", name: "中村ソウマ", age: 33 },
{ id: "2", name: "田中太郎", age: 25 },
];
const resolvers = {
Query: {
user: (_, { id }) => users.find((u) => u.id === id),
users: () => users,
},
};
const server = new ApolloServer({ typeDefs, resolvers });
const { url } = await startStandaloneServer(server, {
listen: { port: 4000 },
});
console.log(`Server ready at: ${url}`);TypeScriptと組み合わせると、スキーマから型を自動生成できてさらに強力になります。SQL・データベースの基礎も理解しておくと、リゾルバでDBからデータを取り出す実装がスムーズになります。
よくある質問
Q: GraphQLはRESTより常に速いんですか？
A: 必ずしもそうではありません。GraphQLの「必要なデータだけ取る」特性はネットワーク転送量を減らせますが、バックエンドでのリゾルバ処理が複雑になると遅くなることもあります。特にN+1問題（関連データを1件ずつDBに取りに行く問題）はDataLoaderなどで別途対策が必要です。速度は実装次第です。
Q: REST APIとGraphQLを同じプロジェクトで混在させていいですか？
A: 技術的には可能ですが、チームが混乱しやすいのであまりおすすめしません。段階的に移行する場合は「新機能はGraphQL、既存はREST」という切り分けで運用しているチームもあります。移行コストと現場の学習コストを天秤にかけて判断してください。
Q: フリーランスでGraphQLの案件はありますか？
A: あります。ただしREST案件と比べるとまだ少数です。フリーランスとして独立を考えているなら、RESTを確実に扱えることが前提で、GraphQLは「できれば加点」というポジションです。フリーランスエンジニアの案件獲得については、こちらの記事が参考になります。
Q: GraphQLを学ぶなら何から始めればいいですか？
A: 公式チュートリアル（graphql.org）が最も正確です。実装を学ぶなら「Apollo Server + Apollo Client」の組み合わせが日本語資料も多くおすすめです。RESTの基礎が固まってから取り組むと理解が早いです。独学全体のロードマップはこちらの記事も参考にしてください。
Q: tRPCとGraphQLはどう違うんですか？
A: tRPCはTypeScript前提で型安全にAPIを呼び出せる仕組みです。GraphQLのようにスキーマ言語を別途書く必要がなく、Next.jsフルスタック構成と非常に相性が良いです。「GraphQLほど複雑にしたくないが、型安全は欲しい」という場合にtRPCを選ぶチームが増えています。
まとめ
- REST API: シンプル、学習コスト低い、ほとんどの場面で十分
- GraphQL: 複数クライアント・複雑なデータ構造・大規模チームで輝く
- 初心者はまずRESTを: GraphQLの価値はRESTの経験があって初めてわかる
「どちらが優れているか」ではなく、「どちらが今のプロジェクトに合っているか」で選ぶ。これは断言できます。
プログラミング独学のロードマップ全体については独学プログラミングの最短ロードマップをあわせてご覧ください。
独学に限界を感じたら:
APIの設計やデータベース設計は、独学だと「なぜそう設計するのか」の背景を理解しにくい領域です。現役エンジニアのメンタリングを受けながら学べる環境があると、理解の速度が体感2〜3倍変わります。
この記事を書いた人: 中村ソウマ / フリーランスフロントエンドエンジニア。文系・営業職→独学8ヶ月でエンジニア転職。React/Next.js専門。
【2026年4月追記】RESTとGraphQL以外の選択肢：tRPC
この記事を書いた後、改めて感じたのはtRPCの存在感の増加です。
tRPCは「フロントとバックエンドで型を共有しつつ、GraphQLほど複雑にしない」というアプローチです。特にNext.jsフルスタック（App Router + Server Actions）との組み合わせで使われています。「REST, GraphQL, tRPC」の3択になってきた現在でも、「チームの技術スタックとプロジェクト規模で決まる」という原則は変わりません。
