GraphQL時代でもREST APIがなくならない理由

この記事の最終更新日: 2026年5月21日

近年、API設計の選択肢として GraphQL がよく使われるようになりました。

GraphQLは、クライアントが必要なデータだけを指定して取得できる便利な仕組みです。

たとえば、REST APIでは複数のエンドポイントを呼び出す必要がある場面でも、GraphQLなら1回のリクエストで必要なデータをまとめて取得できることがあります。

そのため、次のように感じる人もいるかもしれません。

GraphQLがあるならREST APIはもう古いのでは？
これからは全部GraphQLになるのでは？
REST APIを学ぶ意味はまだあるの？
新規開発ではGraphQLを使うべきなの？

結論から言うと、GraphQL時代でもREST APIはなくなりません。

GraphQLは非常に強力な選択肢ですが、REST APIにはREST APIの強みがあります。

むしろ実務では、GraphQLとREST APIは競合というより、用途に応じて使い分けるものです。

この記事では、GraphQL時代でもREST APIがなくならない理由を、初心者にもわかりやすく解説します。

まずREST APIとは何か

REST APIとは、HTTPメソッドとURLを使って、リソースに対する操作を表現するAPI設計の考え方です。

たとえば、ユーザー情報を扱うAPIなら、次のように設計します。

GET /users
GET /users/1
POST /users
PATCH /users/1
DELETE /users/1

それぞれの意味は次の通りです。

REST APIでは、URLで「何を対象にするか」を表し、HTTPメソッドで「何をするか」を表します。

シンプルでわかりやすく、Web開発の現場で長く使われてきた設計スタイルです。

GraphQLとは何か

GraphQLは、クライアントが欲しいデータの形を指定して取得できるAPIの仕組みです。

REST APIでは、サーバー側が用意したエンドポイントごとにレスポンス形式が決まっています。

一方、GraphQLでは、クライアントが次のように取得したいフィールドを指定できます。

query {
  user(id: 1) {
    id
    name
    email
    posts {
      id
      title
    }
  }
}

このリクエストでは、ユーザー情報と、そのユーザーが投稿した記事一覧をまとめて取得しています。

レスポンスは、リクエストで指定した形に近いJSONで返ります。

{
  "data": {
    "user": {
      "id": 1,
      "name": "山田太郎",
      "email": "yamada@example.com",
      "posts": [
        {
          "id": 10,
          "title": "REST APIの基本"
        }
      ]
    }
  }
}

GraphQLの大きな特徴は、クライアントが必要なデータだけを指定できる ことです。

GraphQLが便利な理由

GraphQLが注目される理由は、REST APIで起きやすい問題を解決しやすいからです。

代表的なメリットは次の通りです。

たとえば、ユーザー詳細画面で次のデータが必要だとします。

• ユーザー名
• メールアドレス
• 投稿一覧
• 投稿へのコメント数
• フォロワー数

REST APIでは、設計によっては複数のAPIを呼ぶ必要があります。

GET /users/1
GET /users/1/posts
GET /users/1/followers

GraphQLなら、1回のリクエストでまとめて取得できる場合があります。

そのため、複雑な画面を持つアプリではGraphQLが便利です。

それでもREST APIがなくならない理由

GraphQLは便利です。

しかし、それでもREST APIはなくなりません。

理由は主に次の通りです。

1. REST APIはシンプルで理解しやすい
2. HTTPの仕組みと相性が良い
3. CRUD中心のAPIではRESTで十分なことが多い
4. キャッシュやログ、監視が扱いやすい
5. 外部公開APIではRESTの方が使いやすいことが多い
6. 学習コストと運用コストが低い
7. 既存システムで広く使われている
8. GraphQLにも設計・運用の難しさがある

それぞれ詳しく見ていきます。

理由1：REST APIはシンプルで理解しやすい

REST APIの大きな強みは、シンプルさです。

たとえば、次のAPIを見れば、多くのエンジニアは意味をすぐに理解できます。

GET /articles

これは記事一覧を取得するAPIです。

POST /articles

これは記事を作成するAPIです。

DELETE /articles/1

これはIDが1の記事を削除するAPIです。

このように、REST APIはURLとHTTPメソッドの組み合わせで意味が伝わりやすいです。

一方、GraphQLでは、次のようなクエリを理解する必要があります。

query {
  articles {
    id
    title
    author {
      id
      name
    }
  }
}

GraphQLにはGraphQLの読みやすさがありますが、REST APIに比べると、最初に覚える概念は多くなります。

REST APIでは、最低限次の知識があれば使い始められます。

• URL
• HTTPメソッド
• JSON
• ステータスコード
• リクエスト
• レスポンス

初心者や小規模チームにとって、このシンプルさは大きなメリットです。

理由2：HTTPの仕組みと相性が良い

REST APIは、HTTPの仕組みをそのまま活かしやすいです。

たとえば、HTTPメソッドにはそれぞれ役割があります。

また、HTTPステータスコードも自然に使えます。

REST APIでは、HTTPの標準的な仕組みとAPIの意味が一致しやすいです。

GET /users/1

ユーザーを取得します。

404 Not Found

ユーザーが見つかりません。

このように、HTTPそのものの意味を活かせるのがREST APIの強みです。

GraphQLでもHTTPを使うことは多いですが、基本的には1つのエンドポイントに対してPOSTでクエリを送る形になりやすいです。

POST /graphql

そのため、HTTPメソッドやステータスコードだけでは、どのデータを取得・変更しているのかが見えにくくなることがあります。

理由3：CRUD中心のAPIではRESTで十分なことが多い

多くの業務システムやWebアプリでは、基本的な操作はCRUDです。

CRUDとは、次の4つの操作です。

たとえば、タスク管理アプリなら次のように設計できます。

GET    /tasks
GET    /tasks/1
POST   /tasks
PATCH  /tasks/1
DELETE /tasks/1

これだけで、基本的な機能は十分に作れます。

商品管理、ユーザー管理、記事管理、予約管理なども、かなりの部分はREST APIで自然に表現できます。

GET    /products
POST   /products
PATCH  /products/1
DELETE /products/1

このように、リソース中心のCRUD操作が多いシステムでは、REST APIは今でも非常に使いやすいです。

GraphQLを使うメリットが大きいのは、複数の関連データを柔軟に取得したい場合や、画面ごとに必要なデータ構造が大きく異なる場合です。

逆に、単純なCRUD中心のAPIでは、REST APIの方がシンプルで扱いやすいことも多いです。

理由4：キャッシュを扱いやすい

REST APIは、HTTPキャッシュと相性が良いです。

たとえば、次のようなGETリクエストがあります。

GET /articles/1

このレスポンスは、条件によってはブラウザやCDNでキャッシュできます。

Cache-Control: public, max-age=300

記事詳細や商品情報、公開プロフィールなど、頻繁に変わらないデータはキャッシュしやすいです。

REST APIでは、URL単位でキャッシュを考えやすいです。

GET /articles/1
GET /products/100
GET /categories

一方、GraphQLでは多くの場合、同じ /graphql エンドポイントに対して異なるクエリを送ります。

POST /graphql

そのため、HTTPレイヤーで単純にURL単位のキャッシュを行うのが難しくなります。

もちろん、GraphQLでもキャッシュはできます。

ただし、クエリ単位、フィールド単位、クライアントキャッシュなど、設計が少し複雑になりがちです。

単純なキャッシュ戦略を取りたい場合、REST APIは今でも扱いやすいです。

理由5：ログや監視がわかりやすい

REST APIは、ログや監視でも意味を読み取りやすいです。

たとえば、アクセスログに次のように残っていたとします。

GET /users/1 200
PATCH /users/1 200
DELETE /users/1 204

これを見るだけで、だいたい何が起きたかわかります。

• ユーザー1を取得した
• ユーザー1を更新した
• ユーザー1を削除した

一方、GraphQLではログ上は次のようになりがちです。

POST /graphql 200
POST /graphql 200
POST /graphql 200

これだけでは、何のクエリやミューテーションが実行されたのかわかりません。

もちろん、GraphQLでもoperation nameやクエリ内容をログに出せば追跡できます。

しかし、REST APIのようにURLとHTTPメソッドだけで概要を把握することは難しくなります。

運用面では、次のような観点でREST APIが扱いやすいです。

• どのAPIがよく呼ばれているか
• どのAPIでエラーが多いか
• どの削除APIが実行されたか
• レスポンス時間が遅いエンドポイントはどれか
• 権限エラーが多いAPIはどれか

監視やログ分析のしやすさは、実務ではかなり重要です。

理由6：外部公開APIではRESTの方が使いやすいことが多い

外部の開発者にAPIを公開する場合、REST APIは今でも強い選択肢です。

たとえば、外部利用者に次のようなAPIを提供するとします。

GET /v1/products
GET /v1/products/{id}
POST /v1/orders
GET /v1/orders/{id}

REST APIは、curlやPostmanなどで簡単に試せます。

curl https://api.example.com/v1/products

また、APIドキュメントも比較的書きやすいです。

GET /v1/products
商品一覧を取得する

POST /v1/orders
注文を作成する

外部公開APIでは、利用者がGraphQLに慣れているとは限りません。

REST APIなら、多くの開発者が基本を理解しています。

また、HTTPメソッド、URL、ステータスコード、認証ヘッダーといったWebの標準的な仕組みに乗せやすいです。

そのため、外部向けAPIではREST APIが選ばれることが今後も多いでしょう。

理由7：学習コストが低い

REST APIは、Web開発を学ぶうえで避けて通れない基礎です。

学ぶ内容は次のようなものです。

• HTTPメソッド
• URL
• リクエスト
• レスポンス
• JSON
• ステータスコード
• 認証ヘッダー

これらはREST APIだけでなく、Web開発全体で役立つ知識です。

一方、GraphQLを使うには、追加で次のような概念を理解する必要があります。

• Query
• Mutation
• Schema
• Type
• Resolver
• Fragment
• Subscription
• DataLoader
• N+1問題
• GraphQL用の認可設計
• クライアントキャッシュ

GraphQLは強力ですが、その分、学ぶことも増えます。

チーム全体がGraphQLに慣れていない場合、導入によって開発効率が下がることもあります。

特に小規模なプロジェクトや初心者中心のチームでは、REST APIの方が始めやすいです。

理由8：既存システムでREST APIが広く使われている

REST APIは、すでに多くのシステムで使われています。

既存のWebアプリ、スマホアプリ、社内システム、外部連携APIなど、REST APIで作られたシステムは非常に多いです。

そのため、GraphQLが便利だからといって、すぐにすべてがGraphQLに置き換わるわけではありません。

既存APIを変更するには、次のようなコストがあります。

• フロントエンドの修正
• スマホアプリの修正
• 外部連携先への影響
• APIドキュメントの更新
• テストの作り直し
• 認証・認可の再設計
• 運用監視の見直し

特にスマホアプリや外部公開APIでは、既存クライアントとの互換性を簡単には壊せません。

そのため、既存のREST APIは長く使われ続けます。

理由9：GraphQLにも難しさがある

GraphQLは便利ですが、万能ではありません。

実務で使うと、GraphQL特有の難しさも出てきます。

代表的なものは次の通りです。

GraphQLでは、クライアントが自由にデータ構造を指定できます。

これは大きなメリットですが、サーバー側から見ると、重いクエリを投げられる可能性もあります。

たとえば、深いネストのクエリや大量の関連データ取得があると、サーバー負荷が高くなることがあります。

そのため、実務では次のような対策が必要になります。

• クエリの深さ制限
• 複雑度制限
• DataLoaderの導入
• N+1対策
• フィールド単位の認可
• operation nameのログ出力
• レート制限
• スキーマ設計ルール

GraphQLを導入すれば自動的にAPI設計が楽になるわけではありません。

むしろ、GraphQLを正しく運用するには、それなりの設計力が必要です。

REST APIとGraphQLの違い

REST APIとGraphQLの違いを整理すると、次のようになります。

どちらが上というより、得意分野が違います。

REST APIが向いているケース

REST APIが向いているのは、次のようなケースです。

CRUD中心のシンプルなAPI
外部公開API
管理画面向けAPI
キャッシュを活用したいAPI
ログや監視をわかりやすくしたいAPI
チームがGraphQLに慣れていない場合
小規模〜中規模のWebアプリ
既存システムとの連携

たとえば、ユーザー管理や商品管理のようなAPIならRESTで十分なことが多いです。

GET    /users
POST   /users
PATCH  /users/1
DELETE /users/1

この設計はシンプルで、ドキュメントも書きやすく、テストもしやすいです。

GraphQLが向いているケース

GraphQLが向いているのは、次のようなケースです。

画面ごとに必要なデータが大きく違う
関連データをまとめて取得したい
モバイルアプリで通信量を減らしたい
フロントエンド主導でデータ取得を柔軟にしたい
複数のバックエンドAPIを統合したい
BFFとしてAPIを集約したい
型安全な開発体験を重視したい

たとえば、SNSのプロフィール画面を考えてみます。

必要なデータは多いです。

• ユーザー情報
• 投稿一覧
• フォロワー数
• フォロー中かどうか
• 最近のコメント
• プロフィール画像
• 関連ユーザー

REST APIでは複数のAPI呼び出しが必要になるかもしれません。

GET /users/1
GET /users/1/posts
GET /users/1/followers
GET /users/1/comments

GraphQLなら、必要なデータを1つのクエリで表現しやすいです。

query {
  user(id: 1) {
    id
    name
    avatarUrl
    followerCount
    isFollowing
    posts {
      id
      title
      commentCount
    }
  }
}

このように、複雑な画面にはGraphQLが向いています。

REST APIとGraphQLは共存できる

実務では、REST APIとGraphQLのどちらか一方だけを使う必要はありません。

共存する構成もよくあります。

たとえば、次のような使い分けです。

特に、認証やファイルアップロード、WebhookなどはREST APIで実装されることが多いです。

一方で、画面表示用のデータ集約にはGraphQLが便利なことがあります。

つまり、次のような構成も十分現実的です。

フロントエンド
    ↓
GraphQL API
    ↓
REST API・DB・外部サービス

または、

外部サービス向け → REST API
社内フロントエンド向け → GraphQL

REST APIとGraphQLは対立するものではなく、目的に応じて組み合わせるものです。

「GraphQLがあるからREST APIを学ばなくていい」は間違い

GraphQLを学ぶ価値はあります。

しかし、GraphQLがあるからREST APIを学ばなくていい、という考え方は危険です。

理由はシンプルです。

REST APIは、今でも多くの現場で使われているからです。

実務では、次のような場面でREST APIの知識が必要になります。

• 既存APIの仕様を読む
• 外部APIを利用する
• フロントエンドからAPIを呼ぶ
• バックエンドでAPIを作る
• APIエラーを調査する
• ステータスコードを判断する
• 認証ヘッダーを扱う
• ファイルアップロードを設計する
• Webhookを受け取る

GraphQLを使う現場でも、裏側ではREST APIと連携していることがあります。

そのため、REST APIの基礎は今後も重要です。

初心者はREST APIから学ぶのがおすすめ

初心者がAPIを学ぶなら、まずはREST APIから入るのがおすすめです。

理由は、REST APIを学ぶことでWeb APIの基本が身につくからです。

REST APIを学ぶと、次の知識が身につきます。

• HTTPメソッド
• ステータスコード
• URL設計
• JSON
• リクエストとレスポンス
• 認証・認可
• エラー処理
• API仕様書の読み方

これらはGraphQLを学ぶときにも役立ちます。

GraphQLを理解するにも、HTTPやJSON、認証の知識は必要です。

そのため、学習順としては次の流れが自然です。

1. Webの基本を理解する
2. REST APIを理解する
3. API設計の基本を理解する
4. GraphQLの特徴を理解する
5. REST APIとGraphQLを使い分ける

いきなりGraphQLから入るより、REST APIでAPI通信の基本を押さえた方が理解しやすいです。

実務での判断基準

REST APIとGraphQLのどちらを使うか迷ったら、次の観点で考えるとよいです。

APIはCRUD中心か？
画面ごとに必要なデータが大きく違うか？
関連データをまとめて取得する必要があるか？
外部開発者に公開するAPIか？
チームはGraphQLに慣れているか？
キャッシュやログ監視をどう設計するか？
認可が複雑になりすぎないか？
運用コストに見合うメリットがあるか？

たとえば、単純な管理画面ならREST APIで十分なことが多いです。

一方で、複雑な画面を持つフロントエンドやモバイルアプリではGraphQLが役立つことがあります。

REST APIは「古い技術」ではない

REST APIは、GraphQLより前から広く使われているため、「古い」と言われることがあります。

しかし、古いことと不要であることは違います。

HTTP、SQL、メール、DNSなども長く使われていますが、今でも重要です。

REST APIも同じです。

シンプルで、理解しやすく、HTTPの仕組みに乗りやすいという強みがあります。

新しい技術が出てきたからといって、既存の技術がすぐに消えるわけではありません。

むしろ、REST APIは今後も次のような場面で使われ続けるでしょう。

• 外部公開API
• CRUD中心のAPI
• 管理画面
• シンプルなWebアプリ
• ファイルアップロード
• Webhook
• 既存システム連携
• 社内システム連携

GraphQL時代でも、REST APIは十分に実用的です。

まとめ

GraphQLは、現代のAPI設計において非常に強力な選択肢です。

クライアントが必要なデータだけを指定でき、複雑な画面や関連データの取得に向いています。

しかし、それでもREST APIはなくなりません。

理由は次の通りです。

REST APIとGraphQLは、どちらが絶対に優れているというものではありません。

重要なのは、プロジェクトの目的に合わせて選ぶことです。

CRUD中心でシンプルに作りたいならREST API
複雑な画面データを柔軟に取得したいならGraphQL
外部公開APIならREST APIが扱いやすい
フロントエンド向けのデータ集約ならGraphQLが便利

GraphQL時代でも、REST APIはWeb開発の基礎として残り続けます。

だからこそ、初心者はまずREST APIを理解し、そのうえでGraphQLとの違いを学ぶのがおすすめです。

daigoro

大阪のエンジニアが書いているブログ。