GraphQLとは

GraphQL（グラフキューエル）とは、APIに対してクエリ言語を使ってリクエストができるように定められたオープンソース仕様です。
クエリ言語とはデータベース等から必要なデータを取得する際に使われる言語・書式であり、その代表例としてリレーショナルデータベースにおけるSQL(Structured Query Language)が挙げられます。
しかしながら、GraphQLとSQLは以下の点で異なります。

• SQLはデータベースに対するクエリに使われるのに対して、GraphQLはAPIに対するリクエストに使われます
• SQLは自然言語を意識した構文であるのに対して、GraphQLはJSON形式に近い形式を使います

GraphQLは、2012年にMeta Platforms（旧 Facebook）社がモバイルアプリケーションを開発するにあたり、策定されました。
その目的は従来のRESTAPIが抱える以下の課題を解消することでした。

• オーバーフェッチ : データ取得時における不要な項目の混在
• アンダーフェッチ : 1回の呼出で必要なデータが揃わない(複数回呼出が必要)

GraphQLそのものは特定の実装ではなく仕様を指しており、Meta 社（旧 Facebook）による JavaScript 向けのリファレンス実装は GraphQL.js になります。
2015年にこれらがオープンソース化 され、2019年には中立的な非営利組織であるGraphQL Foundationが設立されました。以降、コミュニティによるオープンな議論と標準化が進み、持続的に発展しています。
GraphQLの仕様は継続的に改訂されており、2025年9月にはSeptember 2025 Editionとしておよそ4年ぶりに仕様が改定され、OneOf入力オブジェクトやスキーマ座標、イントロスペクションの拡張など、新しい仕様が多く導入されました。

主な特徴

クライアント主導の柔軟なデータ取得
クライアントが「どの型の、どのフィールドを、どの入れ子構造で欲しいか」をクエリで宣言し、クエリの構造がそのままレスポンスの構造に反映されます。(次章「REST APIとGraphQLの比較」参照)
これにより、REST APIで問題になりがちなオーバーフェッチとアンダーフェッチを同時に抑制できます。

• 単一エンドポイントでの集約アクセス
  GraphQLサーバは1つのエンドポイントで複数のリソースを扱うことができます。
  これは複数サービスやマイクロサービスの結果をまとめて取得するBFF （Backend for Frontend） 的な役割にも向いています。
• 強い型付けとスキーマ駆動開発
  スキーマには、スカラー型・オブジェクト型・インターフェース・ユニオン・列挙型・入力オブジェクトなど、APIを構成する型がすべて定義されます。
  型システムが仕様で厳密に定義されているため、ツールやコード生成の基盤として利用できます。
• イントロスペクションと豊富なツール群
  GraphQLには「イントロスペクション」という仕組みがあり、GraphQLサーバに「どのような型やフィールドがあるか」を問い合わせることができます。
  たとえば、`__schema`や`__type`といった特別なフィールドをクエリすることで、サーバのスキーマ構造をそのままデータとして取得できます。
  スキーマビューアやドキュメント生成ツール、GraphiQLのような対話型IDEはこれを利用しています。
  
  また、2025年9月には主に以下の仕様拡張が行われました。(一部抜粋)
• OneOf入力オブジェクトと `@oneOf` ディレクティブ
  入力オブジェクトに対して「複数フィールドのうち ちょうど1つだけ を指定させる」といった制約を表現できる `OneOf` 入力オブジェクトと `@oneOf` ディレクティブが追加されました。
  フォーム入力や検索条件など、排他的な入力を扱うユースケースでバリデーションと自己記述性が向上します。
• イントロスペクションの拡張（`isOneOf`, `includeDeprecated` など）
  イントロスペクション用の `__Type` 型に `isOneOf` フィールドが追加され、型がOneOf入力オブジェクトかどうかをツール側から判別できるようになりました。
  また `inputFields(includeDeprecated: Boolean)` など、非推奨フィールドを含めるかどうかを制御する引数が追加され、スキーマの進化と互換性管理がやりやすくなっています。
• Schema Coordinates（スキーマ座標）の明確化
  `Type.field(argName: Type)` のように、スキーマ要素を一意に指し示すための「スキーマ座標」の記法が正式に仕様化されました。
  これにより、ログ・モニタリング・ドキュメント・ツール間でフィールドや引数を指す際の表記が統一されます。
• リアルタイム更新・ストリーミングへの対応
  GraphQLはクエリ（読み取り）、ミューテーション（変更）に加えて、サブスクリプションを通じたイベント駆動のリアルタイム配信も扱うことができます。
  September 2025 Edition ではサブスクリプションの「ソースストリーム」「レスポンスストリーム」扱いやストリームレスポンス形式が明確化されました。

REST APIとGraphQLの比較

以下のスキーマを例として、REST APIとGraphQLの比較を示します。

type Query {
  droid(id: ID!): Droid
}

enum Episode {
  NEWHOPE  EMPIRE  JEDI
}

interface Character {
  id: ID!
  name: String!
  friends: [Character]
  appearsIn: [Episode]!
}

type Human implements Character {
  id: ID!
  name: String!
  friends: [Character]
  appearsIn: [Episode]!
  starships: [Starship]
  totalCredits: Int
}

type Droid implements Character {
  id: ID!
  name: String!
  friends: [Character]
  appearsIn: [Episode]!
  primaryFunction: String
}

• (参考) Schemas and Types

次にクライアントはdroidの`name`、`appearsIn`とfriends の`name`だけが必要だとします。
REST APIの場合、以下のようにしてデータを取得します。

リクエスト

GET /droids/2000

レスポンス

{
    “id”: “2000”,
    “name”: ”C-3PO“
    “friends”: [“1000”, “1002”],
    “appearsIn”: [“NEWHOPE”, “EMPIRE”, “JEDI”],,
“primaryFunction”: “…”
}

しかしこれではfriendsの`name`が取得できていません。そのため、以下のような呼び出しが追加で必要になってしまいます。

リクエスト

GET /characters/1000
GET /characters/1002

このように、必要な情報を1度で取得できず、追加リクエストが必要になることをアンダーフェッチと呼んでいます。
この追加リクエストを減らすためにサーバがfriendsを丸ごと埋め込んで返すエンドポイントを用意したとします。その場合、以下のようになります。

リクエスト

GET /droids/2000?include=friends

レスポンス

{
    “id”: “2000”,
    “name”: ”C-3PO“
    “appearsIn”: [“NEWHOPE”, “EMPIRE”, “JEDI”],,
“primaryFunction”: “…”
    “friends”:[
      {
        “id”: “1000”,
        “name”: ”…“
        “appearsIn”: [“…”],,
“starShips”: “…”,
“totalCredis”: 123
      },
      {
        “id”: “1002”,
        “name”: ”…“
        “appearsIn”: [“…”],,
“primaryFunction”: “…”,
      }
],
}

そうすると今度は本来必要としているfriendsの`name`以外の不要な情報まで取得してしまうことになります。これがオーバーフェッチです。
このアンダーフェッチ、オーバーフェッチがREST APIにおけるデータ取得を非効率なものにしています。

次にGraphQLによるクエリの例を示します。GraphQLではクライアントが必要なフィールドだけを指定することができます。

クエリ

query DroidDetail {
  droid(id: “2000”) {
    name
    appearsIn
    friends {
      name
    }
  }
}

レスポンス

{
  “data” : {
    “droid”: {
      “name”: “C-3PO”,
      “appearsIn”: [“NEWHOPE”, “EMPIRE”, “JEDI”],
      “friends”:[
        { “name”: “…” },
        { “name”: “…” }
      ]
    }
  }
}

このようにGraphQLでは1回のクエリで必要な情報だけを取得することができ、REST APIにおけるアンダーフェッチ、オーバーフェッチの問題を同時に解消することが可能になります。

メリット・デメリット

類似プロダクト

ユースケース

GitHubをはじめ、YouTube、Yelp、RedditなどのさまざまなサイトでGraphQL API が公開されています。

動作環境

GraphQL自体は「仕様」であり、特定のOSやミドルウェアに依存しません。
各言語に対応したサーバ、クライアント、ツール等の実装はGraphQL 公式サイトの「COMMUNITY > TOOLS AND LIBRARIES」に紹介されています。
動作環境についてはそれぞれの実装に依存するため、そちらを確認してください。

GraphQLのライセンス

GraphQLは仕様そのものと各実装でライセンスが異なります。

• GraphQL仕様（GraphQL Specification Project）
  GraphQL仕様は Open Web Foundation Final Specification Agreement 1.0（OWFa 1.0）のもとで提供されています。
  OWFaはWeb技術仕様への著作権を許諾し、特許権の行使を制限することで、誰でも自由に使用・実装できるライセンスです。
  さらに、同プロジェクトでは仕様以外の成果物について、ソースコードは MIT License、データセットは CC0 1.0 というライセンス構成を採用しています。
• リファレンス実装 GraphQL.js
  JavaScript向けリファレンス実装である GraphQL.js は MIT License で提供されており、多くのGraphQLサーバ・ツールがこれをベースにしています。
• その他の実装
  多くのサーバ／クライアント実装は MIT License や Apache License 2.0 など商用利用しやすいOSSライセンスを採用していますが、利用時には各プロダクト（フレームワークやSaaS製品）のライセンス条件を個別に確認する必要があります。

参考情報

• GraphQLの公式サイト
• GraphQL仕様（September 2025 Edition）
• GraphQL仕様ワーキングドラフト
• GraphQL Specification Project（仕様リポジトリ）
• GraphQL.js（JavaScriptリファレンス実装）
• GitHub GraphQL APIドキュメント

オープンソース年間サポートサービス

OpenStandiaではOSSを安心してご利用いただけるように、オープンソース年間サポートサービスをご提供しております。
サポートしているOSSは下記ページをご参照ください。

• サポートOSS一覧