REST と GraphQL の違い：どちらを使うべきか？

REST と GraphQL は、APIを設計する2つの方法です。API とは、アプリの画面（や他のプログラム）がバックエンドにデータを要求する際の取り決めです。REST では、/customers や /orders のように、対象ごとに別々のURLがあり、それぞれが決まった形のデータを返します。GraphQL では、通常URLは1つだけで、呼び出し側は必要なフィールドを列挙したクエリを送ります。AIで作るほとんどのアプリにとって、REST のほうがシンプルで良い初期選択です。

AIでアプリを作るときに重要な理由

AIアプリビルダーに「バックエンドのあるアプリを作って」と頼むと、フロントエンドとバックエンドがどう通信するかを決める必要があります。毎回あなたが決める必要はありませんが、コード、ドキュメント、外部サービスとの接続では、これらの用語を目にすることになります。サービスによっては一方の方式しか提供していません。多くのサービスは REST API を公開していますが、Shopify や GitHub のように、GraphQL も提供している、あるいはGraphQLを優先しているサービスもあります。違いを知っておくと、目の前のものが何か理解でき、不要な複雑さを避けられます。「API」という言葉に馴染みがなければ、まず APIとは何か をご覧ください。

日常的な例えで

REST はレストランの定食メニューのようなものです。 各料理（エンドポイント）は、厨房が決めた形で出てきます。「顧客」の料理を注文すると、名前だけが欲しくても、名前、メールアドレス、住所、登録日を含む一皿全部が届きます。顧客の最近の注文も欲しい場合は、別の料理を注文することになります。

GraphQL は1人のウェイターに単品で注文するようなものです。 欲しいものを正確に書き出します。「顧客の名前と、直近3件の注文の日付と合計金額」です。注文は1回、届くのは1皿、その中身は頼んだものだけです。ただし、厨房は客が書きうるあらゆる組み合わせに対応できるように準備されている必要があります。

同じリクエストを両方の方式で

顧客のページで、顧客の名前と直近3件の注文が必要だとします。

REST の場合、通常は2回のリクエストになります。

GET /api/customers/42
GET /api/customers/42/orders?limit=3

最初のレスポンスには、ページに必要な量より多くの情報が含まれることがあります。

{ "id": 42, "name": "Lena Park", "email": "lena@example.com", "address": "…", "createdAt": "…" }

GraphQL の場合は、1つのエンドポイント（例えば /graphql）に、クエリを載せた POST を1回送ります。

query {
  customer(id: 42) {
    name
    orders(last: 3) {
      date
      total
    }
  }
}

レスポンスは、クエリの形をそのまま反映します。

{
  "data": {
    "customer": {
      "name": "Lena Park",
      "orders": [
        { "date": "2026-09-20", "total": 48.0 },
        { "date": "2026-09-02", "total": 19.5 },
        { "date": "2026-08-15", "total": 72.25 }
      ]
    }
  }
}

どちらも JSON を返します。違いは、形を決めるのが誰かという点です。REST ではサーバーが決め、GraphQL ではサーバーのスキーマが許す範囲内で呼び出し側が決めます。

並べて比較

それぞれが向いている場面

REST を選ぶ場合：

• 予約システム、CRM、ダッシュボード、ストアなど、一般的なアプリを作るとき。
• 1つのフロントエンドが1つのバックエンドと通信し、両方を自分で管理しているとき。
• デバッグ、キャッシュ、セキュリティ確保を最も簡単にしたいとき。
• 他のサービスがあなたのアプリを呼び出すとき（Webhook やほとんどの連携は REST 風のエンドポイントを想定しています）。

GraphQL を検討する場合：

• Web サイト、モバイルアプリ、パートナーとの連携など、複数の異なるクライアントが、同じデータの異なる部分を必要とするとき。
• データが深く関連しており（商品、バリエーション、レビュー、販売者、在庫）、画面が多様な組み合わせでそれらを組み合わせる必要があるとき。
• 主要なAPIとして GraphQL を提供しているサービスを利用するとき。

役立つ目安として、GraphQL が必要かどうかわからないなら、おそらく必要ありません。後から追加するほうが、後から取り除くより簡単です。

主な用語

よくある誤解

• 「GraphQL は新しいから優れている」。 特定の問題を解決するものです。フロントエンドが1つだけの単一のアプリでは、大きな利点がないまま作業を増やすことがよくあります。
• 「GraphQL はデータベースだ」。 違います。APIのレイヤーです。その裏側では、サーバーは引き続き データベース からデータを読み取ります。
• 「GraphQL は常に速い」。 リクエスト数が減ると、遅いモバイル回線では助かることがありますが、上限のないクエリは大量のデータを読み込むことがあります。性能はバックエンドに左右されます。
• 「REST は厳密な標準だ」。 実際には「REST API」という言葉は、リソースのURL、HTTPメソッド、JSON をゆるく指すことが多いです。良いAPIの多くは、正式なルールから少し外れています。
• 「ステータス200なら成功している」。 GraphQL では errors フィールドを確認してください。リクエストは一部だけ失敗していても、200を返すことがあります。

AIビルダーへの依頼例

• 「特に理由がなければ、JSON を使ったシンプルな REST API を使ってください。GraphQL が必要だと思う場合は、その理由を説明してください。」
• 「すべてのエンドポイント、それぞれが返すもの、そして誰が呼び出せるかを一覧にしてください。」
• 「顧客ページでは、ページが使うフィールドだけを返してください。」
• 「一覧のエンドポイントにはページネーションを追加して、一度に数千行を返さないようにしてください。」
• 「このサービスは GraphQL API しか提供していません。サーバーから呼び出し、キーはシークレットに保存し、必要なフィールドだけをリクエストしてください。」
• 「適切な HTTP ステータスコードと、JSON 形式のエラーメッセージを返してください。」

Mythex での REST と GraphQL

Mythex のドキュメントには、スターターのプロンプトを使って REST API バックエンドを構築する レシピがあります。バックエンドは、ウェブアプリと並べて Node、Python（FastAPI）、C#、Java で実行できます。ドキュメントには GraphQL のテンプレートは記載されていないため、必要な場合は、その理由とあわせて明示的に依頼してください。サードパーティの GraphQL API を呼び出すのは、他の外部サービスと同じように動作します。詳しくは 任意のAPIと連携する をご覧ください。関連する記事として、フロントエンドとバックエンドの違い と REST API の作り方 もあります。

よくある質問