GraphQL スタック 2026 完全ガイド — Apollo Router · Hasura · GraphQL Yoga · Relay · urql · Hot Chocolate · gqlgen · Strawberry · WunderGraph 徹底解説

プロローグ — 2026年、GraphQL は死んだのか

2023年、GitHub は一部の API を REST に戻し、2024年には「GraphQL is dead」というブログがほぼ毎月一本上がっていた。しかし2026年現在、GraphQL は死んでいない。それどころか、Apollo が買収した Stellate、WunderGraph の Cosmo Router、Inigo、Grafbase といったゲートウェイ市場が新たに生まれ、Mercari · Coupang · LINE Yahoo · Netflix · GitHub の内部などの巨大組織は今も Federation でモノリスを分解し続けている。

GraphQL は死んでいない。ただ「簡単な API」という席から「巨大な分散グラフを組み立てるインフラ」という席に引っ越しただけだ。 小さなチームには tRPC のほうが自然だ。しかし数十〜数百のマイクロサービスを単一のグラフとして表現する必要がある組織には、依然 GraphQL が答えである。

この記事は2026年の GraphQL エコシステムを俯瞰する。ゲートウェイ · DB-ファースト · サーバーフレームワーク · クライアント · ツール · 標準 · 代替技術。そして韓国 · 日本企業の導入事例まで。

この記事で扱うこと:

2026年の GraphQL マップ — 誰が作り、誰が使うか
GraphQL スペック 2024-25 と Composite Schemas WG
「GraphQL は死んだ」論争の整理
Federation v2 vs Schema Stitching vs Module Federation
Apollo Router — Rust で書き直した Federation 2 ゲートウェイ
Apollo Server 4 と Apollo Client 3.11+
GraphQL Yoga 5 — The Guild のオールインワンサーバー
graphql-mesh と GraphQL Hive
Hasura v2 と PostGraphile 5 — DB-ファースト陣営
Supabase GraphQL と WunderGraph
Stellate · Inigo · Cosmo · Grafbase — ゲートウェイ戦争
Relay 18 · urql 4 · Apollo Client 3.11 クライアント比較
GraphQL Code Generator と型安全性
Node.js サーバー — Mercurius · Pothos · NestJS · TypeGraphQL
Python — Strawberry · Ariadne · Graphene
Go — gqlgen · graphql-go
Rust — async-graphql · juniper
JVM · .NET · Ruby · Elixir · PHP · Swift
Subscriptions と graphql-ws
N+1 問題と DataLoader パターン
Persisted Queries と信頼可能なクエリ
GraphQL vs REST vs tRPC vs gRPC
韓国 · 日本企業の GraphQL 導入
参考資料

1章 · 2026年の GraphQL マップ

まず全体像。GraphQL を取り巻くツールは大きく5陣営に分かれる。

ゲートウェイ陣営 — 複数のサブグラフを単一のグラフに合成するルーター。Apollo Router (Rust, Apollo)、Cosmo Router (WunderGraph)、Inigo、Stellate (Apollo の子会社)、Grafbase がこの市場で競う。Apollo Router は Federation 2 の事実上の標準だが、ライセンスが Elastic v2 に変わってから Cosmo Router が Apache-2.0 の代替として人気を集めている。

サーバーフレームワーク陣営 — 単一サービス内で GraphQL スキーマとリゾルバーを定義する。Node.js の Apollo Server 4、GraphQL Yoga 5、Mercurius、NestJS GraphQL、Python の Strawberry、Ariadne、Go の gqlgen、.NET の Hot Chocolate、Ruby の graphql-ruby、Elixir の Absinthe。

DB-ファースト陣営 — データベースのスキーマから GraphQL スキーマを自動生成する。Hasura v2、PostGraphile 5 (Benjie Gillam)、Supabase GraphQL。CRUD 比重が高いサービスでコードを90%削減できる。

クライアント陣営 — ブラウザ · モバイルから GraphQL を呼び出す。Apollo Client 3.11+ (シェア1位)、Relay 18 (Meta)、urql 4 (Formidable · 現在は The Guild)、graphql-request + TanStack Query (DIY)、Houdini (SvelteKit)。Apollo iOS · Apollo Kotlin がモバイル陣営。

標準 · ツール陣営 — 仕様とガバナンス。GraphQL Foundation 傘下の GraphQL WG と Composite Schemas WG。The Guild は Hive · Mesh · Tools · YogaServer といったオープンソースツールの束。Apollo は Stellate を買収しエッジキャッシュ市場を押さえた。

この5陣営が毎年配置を変えるのが、GraphQL エコシステムを追いにくくしている主因だ。

2章 · GraphQL スペック 2024-25 と Composite Schemas WG

GraphQL スペック自体は2024-25年の間、比較的保守的に進化した。2024年10月の GraphQL 2024 候補案で次のものが整った。

@oneOf 入力オブジェクト — クライアントが正確に1つのフィールドだけを送る必要のある union 風の入力。長く非標準だったパターンが正式なディレクティブになった。
クライアント制御の nullability — field! でクライアントが明示的に non-null を強制し、サーバーが null を返した場合はクライアントが nullable な親へエラーを伝播する。
defer / stream — 部分結果をストリーミングする応答。重いクエリの first-contentful-paint を短縮する。2024-25年にクライアント · サーバー両側で GA。
サブグラフ合成 — GraphQL Foundation 傘下の Composite Schemas WG が2025年に発足。Apollo Federation 2 の標準化を試みる。WunderGraph · ChilliCream (Hot Chocolate) · The Guild · Apollo がすべて参加。

Composite Schemas WG の意味: Federation 2 がもはや Apollo 単独の仕様ではないという宣言だ。Cosmo Router が Federation 2 互換を主張できる根拠はここにある。2026年現在、標準作業は1.0を目指して進行中で、2027年の正式採択が目標。

3章 · 「GraphQL は死んだのか」論争

2023-24年の間に次のような出来事が重なった。

GitHub が一部の API を REST に戻した (正確には GraphQL を削除したのではなく、REST を併存させた)。理由: モバイルクライアントでのキャッシュ効率、外部統合者の学習コスト。
Shopify は Storefront API を GraphQL に統合したが、同時に「単純利用者」向けの admin REST も維持すると発表した。
Meta 内部で React Server Components が定着するにつれ、「Relay + GraphQL」の一部を RSC + サーバーアクションが置き換えるという分析が出た。
tRPC が Node.js フルスタック陣営で急速に定着し、「GraphQL なしでも型安全な API」の代替として登場した。

これらの流れが重なって「GraphQL はもう終わった」という印象を生んだ。しかし実態は違う。

エンタープライズではいまだに成長中だ。 Netflix の DGS、Mercari の Apollo Federation、GitHub 内部の単一グラフ、Coupang の ELK フロント、LINE Yahoo の Hasura 導入 — いずれも2024-26年で拡大した。
Federation 2 が事実上のインターフェースになった。 小さなチームが自分で書かなくても、SaaS の API ゲートウェイは Apollo Router で組まれていることが多い。
GraphQL は「簡単な API」から「分散グラフ合成インフラ」という席へ移った。 その席では REST · tRPC · gRPC は GraphQL を置き換えない。

結論: GraphQL は死んでいない。ただ「どこでも使う既定のオプション」の席から下りて、「特定の問題 (分散グラフ合成) を解くツール」の席に移っただけだ。2026年に GraphQL を新規導入するなら、まず自分がその席にいるかを確認すべきだ。

4章 · Federation v2 vs Schema Stitching vs Module Federation

複数のサブグラフを1つに合成する三つのアプローチがある。

Schema Stitching (deprecated) — Apollo Server 2 時代の古いやり方。各サービスのスキーマをゲートウェイで合体させ、衝突はゲートウェイ自身がリゾルバーを書いて解決する。運用が難しく Federation 1 に置き換えられ、Federation 2 が登場して事実上消えた。一部の The Guild ツール (graphql-tools の stitching モジュール) は2026年も生きている。

Apollo Federation v1 — 2019年発表。@key · @external · @requires · @provides のディレクティブでサブグラフを定義する。ゲートウェイがクエリプランを作り、各サブグラフへ分岐する。

Apollo Federation v2 — 2022年 GA。v1 の弱点を整理した。共有型 (@shareable)、インターフェースオブジェクト (@interfaceObject)、エントリポイントの上書き (@override)、共有入力オブジェクトなど、v1 で扱いにくかったパターンを標準化。2026年現在、事実上の標準。

Module Federation (Webpack/Rspack) — 名前は似ているが、まったく別物だ。フロントエンドのマイクロフロントエンドバンドル合成である。GraphQL Federation と混同しないこと。

Apollo Federation 2 を導入する際に最も大きな判断は「サブグラフをどう分けるか」だ。ドメイン境界 (Domain Boundary) が正解であり、データソース基準ではない。Mercari の事例でも、最初は DB 基準で分けたが、後にドメイン基準で再構成した。

5章 · Apollo Router — Rust で書き直した Federation 2 ゲートウェイ

Apollo のゲートウェイには2世代ある。

Apollo Gateway (Node.js) — 2019年リリース。JavaScript で書かれた Federation ゲートウェイ。単一インスタンス性能が1k RPS 程度という限界があった。
Apollo Router (Rust) — 2022年 GA。Apollo Gateway を Rust で完全に書き直した。同じハードウェアで10倍以上のスループット、p99 レイテンシも半分以下に。

Apollo Router 1.x の中核機能。

クエリプランナー — 受け取ったクエリをどのサブグラフに分岐するかをグラフで計算。
Rhai · Coprocessor — ゲートウェイ内のカスタムロジック (認証、変換、ロギング)。Rhai は埋め込みスクリプト、Coprocessor は外部プロセス RPC。
テレメトリ — OpenTelemetry が1級。トレース · メトリクス · ログがすべて OTel。
クエリプランナーキャッシュ — 同じクエリのプランをキャッシュ。
Persisted Queries — クライアントが事前登録したクエリハッシュだけを受け付ける (セキュリティ)。

ライセンスの注意点: 2024年に Apollo Router 1.x は Elastic License v2 へ移行した。SaaS での再販が禁止され、Apollo がホストする GraphOS と競合する用途が制限される。この条件が重い組織は Cosmo Router · Hot Chocolate Fusion · The Guild の Hive Router などの Apache-2.0 代替を探し始めた。

# router.yaml — Apollo Router 設定例
supergraph:
  listen: 0.0.0.0:4000
  introspection: false
telemetry:
  metrics:
    prometheus:
      enabled: true
traffic_shaping:
  router:
    timeout: 30s
  all:
    deduplicate_query: true

6章 · Apollo Server 4 と Apollo Client 3.11+

Apollo のもう2つの柱。

Apollo Server 4 (2023年 GA)。単一グラフサーバー (Federation サブグラフとしても使える)。v3 から v4 で Express · Fastify · Lambda · Cloudflare Workers のアダプターが分離された。コアは transport-agnostic。

// Apollo Server 4 minimal
import { ApolloServer } from '@apollo/server'
import { startStandaloneServer } from '@apollo/server/standalone'

const server = new ApolloServer({
  typeDefs: `
    type Query { hello: String }
  `,
  resolvers: {
    Query: { hello: () => 'world' },
  },
})

const { url } = await startStandaloneServer(server, { listen: { port: 4000 } })
console.log(`server ready at ${url}`)

Apollo Client 3.11+ (2024年)。市場シェア1位のクライアント。React · Vue · Angular · Svelte · 一般 JS すべてで使われる。中核機能。

正規化キャッシュ — レスポンスを正規化グラフとして保存。複数のクエリに登場する同じオブジェクトは1度だけ保存される。
リアクティブ — キャッシュが変わると、購読しているコンポーネントが自動で再レンダリング。
楽観的 UI — サーバー応答前に UI を先に更新、失敗時にロールバック。
ページネーション · フラグメント · @client ローカルリゾルバー。

Apollo Client は強力だがバンドルが重い (ライブラリだけで gzip 35-40KB)。小さなアプリには負担になる。そこに urql · graphql-request の席が生まれる。

7章 · GraphQL Yoga 5 — The Guild のオールインワンサーバー

The Guild が作り、Node · Bun · Deno すべてで動く GraphQL サーバー。2023年に GraphQL Yoga 4 で大規模な書き直しを経て、2024-25年に v5 として定着した。

中核となる価値。

Web Standards — Fetch API ベース。Cloudflare Workers · Deno · Bun · Vercel Edge でそのまま動く。
Envelop プラグイン — 認証 · キャッシュ · トレース · コスト分析。The Guild の他のプラグインをそのまま挿入できる。
SSE による Subscriptions — WebSocket が重い環境向けに Server-Sent Events で購読を提供。
Federation サブグラフ — Apollo Federation 2 のサブグラフとしてそのまま使える。

Apollo Server 4 との違いは「オールインワン」の深さだ。Yoga は即座に動く既定値が多く、Apollo Server はよりミニマル。

// GraphQL Yoga 5
import { createYoga, createSchema } from 'graphql-yoga'
import { createServer } from 'node:http'

const yoga = createYoga({
  schema: createSchema({
    typeDefs: 'type Query { hello: String }',
    resolvers: { Query: { hello: () => 'yoga' } },
  }),
})

createServer(yoga).listen(4000)

8章 · graphql-mesh と GraphQL Hive

The Guild のもう2つの大きなツール。

graphql-mesh — REST · gRPC · SOAP · OpenAPI · Postgres · MongoDB · Federation を全部 GraphQL として合成するゲートウェイ。つまりバックエンドが GraphQL でなくても GraphQL ゲートウェイを作れる。移行ツールとしてもよく使われる。

GraphQL Hive — スキーマレジストリ + モニタリング。どのクライアントがどのフィールドをどのくらい使っているかのテレメトリを集める。Apollo の GraphOS Studio に対する位置のオープンソース代替。セルフホスト可能。

Hive と Apollo Studio の最大の差はライセンスだ。Hive は MIT オープンソース、Studio は SaaS のみ。セルフホストが必須の組織 (公的機関 · 金融 · ヘルスケア) は Hive を選ぶ。

9章 · Hasura v2 と PostGraphile 5 — DB-ファースト陣営

「DB スキーマから GraphQL スキーマを自動生成する」パターン。

Hasura v2 — Haskell で書かれた最も有名な DB-ファーストゲートウェイ。PostgreSQL · MySQL · MS SQL Server · BigQuery · Snowflake などをすべてサポート。権限 (roles · permission rules)、Actions (ユーザー定義のビジネスロジック)、Remote Schemas (他の GraphQL サービスのマージ)、Events (DB の変更 → Webhook) などが1級市民。ライセンスは Apache-2.0 (オープンソース)。

PostGraphile 5 (Benjie Gillam) — Postgres 専用。PostGraphile は Postgres のイントロスペクションを深く活用する。Smart Tags · カスタム plpgsql 関数 → GraphQL フィールドのマッピング。2024-25年に v5 (Grafast ベース) で大規模な書き直し。Apollo の N+1 問題を plan-based 実行で解くのが特徴。

DB-ファーストが適する場面: ビジネスロジックより CRUD が多いサービス、管理ツール、内部ツール、MVP 段階。ビジネスロジックが厚くなれば結局コードを書くことになり、その時点で Apollo Server や Yoga へ移行することになる。

10章 · Supabase GraphQL と WunderGraph

Supabase GraphQL — Supabase の Postgres 上に自動で GraphQL エンドポイントを作る。内部的に pg_graphql 拡張を使う。この拡張は Postgres 内部で SQL を実行して GraphQL を処理するため、N+1 問題がない。欠点は権限モデルが Postgres RLS に従属する点。

WunderGraph — 最初は Federation ゲートウェイとして始まり、いまではフルスタック BaaS に近づいた。Cosmo Router · Cosmo Studio · Cosmo CDN で構成。RPC スタイルの API と GraphQL を同時に公開するのが特徴。「Operations」の概念でクライアントが GraphQL クエリを直接送らず、登録済みの操作だけを呼び出す。

# WunderGraph operations パターン — クライアントは事前にサーバーへ登録
query Users {
  users {
    id
    name
  }
}

11章 · Stellate · Inigo · Cosmo · Grafbase — ゲートウェイ戦争

2024-26年の間に GraphQL ゲートウェイ市場が本格的に分化した。

Stellate (旧 GraphCDN) — Apollo が2023年に買収。CDN エッジで GraphQL レスポンスをキャッシュする。POST リクエストは通常 CDN のキャッシュ対象外だが、Stellate はクエリハッシュを使ってキャッシュする。

Inigo — ゲートウェイ + セキュリティ + 可観測性を束ねた SaaS。Apollo Router の代替。Rust で書かれている。

Cosmo Router (WunderGraph) — Apache-2.0 ライセンス。Federation 2 互換。Apollo Router のライセンス負担を避けたい組織が選ぶ。Cosmo Studio (ダッシュボード) · CDN とパッケージ化。

Grafbase — エッジ GraphQL プラットフォーム。自前ゲートウェイ + スキーマレジストリ + エッジキャッシュ。Cloudflare Workers 上で動く。

Hot Chocolate Fusion — ChilliCream (.NET 陣営) が作った Federation 互換のゲートウェイ。.NET 陣営の Apollo Router。

Hive Router — The Guild が新たに作った Apache-2.0 ゲートウェイ。GraphQL Hive と統合。

ゲートウェイ市場の判断軸: ライセンス (Apache vs Elastic)、Federation 互換性 (ほとんどが Federation 2)、エッジ対応 (Cloudflare/Vercel/Fastly)、可観測性 (Hive vs Studio)。

12章 · Relay 18 · urql 4 · Apollo Client 3.11 クライアント比較

3つのクライアントの決定的な差。

Apollo Client 3.11 — 市場シェア1位。すべての機能。正規化キャッシュ。欠点はバンドルサイズ (gzip 35-40KB)。

Relay 18 (Meta) — Facebook 内部で使われているクライアント。Fragment-driven。コンポーネントが自分に必要なフィールドを fragment で宣言し、Relay がそれを集めて最適なクエリを作る。コンパイラがコンパイル時にクエリを正規化 · 最適化する。学習コストが急だが、大規模アプリで最も効率的。Meta · GitHub の一部 · Stripe の一部で使用。

urql 4 (Formidable → The Guild) — ミニマル。既定バンドル gzip 5-10KB。Exchange の仕組みで正規化キャッシュ · 認証 · リトライを差し込める。小さなアプリから大きなアプリまで段階的に拡張できる。

graphql-request + TanStack Query — DIY。graphql-request は fetch ベースの最小クライアント。TanStack Query がキャッシュ · リトライ · 購読を担当。最も軽いセットアップだが、GraphQL 固有の正規化キャッシュなどは自前で書く必要がある。

Houdini — SvelteKit · Kit · Vite のための GraphQL クライアント。コンパイル時コード生成でランタイムを最小化。

クライアント	バンドル (gzip)	正規化キャッシュ	学習コスト	適合先
Apollo Client	35-40KB	1級	中	一般的な React/Vue アプリ
Relay	25-30KB	1級 (コンパイル)	急	Meta 規模のアプリ
urql	5-10KB	exchange で追加	低	ミニマル · 段階的
graphql-request	1-2KB	なし	低	単純な fetch パターン
Houdini	コンパイル	1級	中	SvelteKit アプリ

13章 · GraphQL Code Generator と型安全性

GraphQL 自体は型システムを持つが、TypeScript と自動で繋がるわけではない。この橋を架けるのが GraphQL Code Generator (The Guild)。

サーバースキーマから TypeScript の型を生成。
クライアントのクエリから、呼び出し関数の引数 · 結果の型を生成。
React Hook · Vue Composable · Svelte Store を生成。

# codegen.yml
schema: ./schema.graphql
documents: ./src/**/*.graphql
generates:
  src/gql/:
    preset: client
    plugins: []

@graphql-codegen/client-preset を使うと、graphql() タグ関数がコンパイル時にクエリの型を推論する。この方法で Apollo Client · urql · graphql-request すべてで型安全なクエリが書ける。

14章 · Node.js サーバー — Mercurius · Pothos · NestJS · TypeGraphQL

Node.js 陣営にはサーバーの選択肢が多すぎる。整理する。

graphql-js — GraphQL の公式 JavaScript 実装。他のあらゆるライブラリの基盤。直接使うには低レベルすぎる。

Apollo Server 4 — 最も普及。transport-agnostic。

GraphQL Yoga 5 (The Guild) — Web Standards · オールインワン。

Mercurius — Fastify 陣営。同じコードを Apollo Server より速く動かす。Fastify をすでに使っているチームには自然。

Pothos (旧 GiraphQL) — code-first · TypeScript 優先。スキーマを TS コードで定義すると、SDL が自動生成される。型推論が強く、IDE の自動補完がほぼ完璧。2024-26年に急速に定着した。

TypeGraphQL — デコレータ駆動。NestJS スタイルのクラス + デコレータでスキーマを定義。2024年に v2 で大規模な書き直し。

NestJS GraphQL — NestJS フレームワークの GraphQL モジュール。Apollo Server または Mercurius の上で動作。エンタープライズ Node 陣営での事実上の標準。

// Pothos minimal
import SchemaBuilder from '@pothos/core'

const builder = new SchemaBuilder({})
builder.queryType({
  fields: (t) => ({
    hello: t.string({ resolve: () => 'world' }),
  }),
})

export const schema = builder.toSchema()

15章 · Python — Strawberry · Ariadne · Graphene

Python 陣営の3つのプレイヤー。

Strawberry GraphQL — データクラス + デコレータスタイル。最もモダンで、2024-26年で最もシェアを伸ばした。FastAPI · Django · Flask への統合がすべて1級。Federation 2 対応。Apollo Studio · Hive と連携。

# Strawberry minimal
import strawberry

@strawberry.type
class Query:
    @strawberry.field
    def hello(self) -> str:
        return "world"

schema = strawberry.Schema(query=Query)

Ariadne — schema-first。SDL を直接書き、リゾルバーを関数として登録する。Django · FastAPI 統合あり。Strawberry より少し明示的。

Graphene — 古いライブラリ。Python 陣営に GraphQL を最初に持ち込んだ。Django · Flask · SQLAlchemy 統合が豊富だが、v3 以降の更新が遅い。新規プロジェクトはほとんど Strawberry へ。

16章 · Go — gqlgen · graphql-go

Go 陣営は比較的整理されている。

gqlgen (99designs → コミュニティ)。schema-first · コード生成。SDL を書くと gqlgen が Go の構造体とリゾルバーインターフェースを生成。コンパイル時に型安全。2026年現在、Go 陣営の事実上の標準。

// gqlgen が生成するリゾルバー形状
func (r *queryResolver) Hello(ctx context.Context) (string, error) {
    return "world", nil
}

graphql-go (graphql-go/graphql) — より古いライブラリ。スキーマを Go コードで定義 (code-first)。新規プロジェクトはほとんど gqlgen へ。

gophers/graphql-go — もう1つの選択肢。SDL + リゾルバー関数のマッチングが簡単で、小規模プロジェクトに人気。

17章 · Rust — async-graphql · juniper

Rust 陣営も2つのプレイヤーに集約。

async-graphql 7 — 最も活発な Rust GraphQL サーバー。データローダー · 購読 · Federation 2 · Apollo Studio トレースをすべて対応。Actix · Axum · Warp · Poem などほぼすべての Rust Web フレームワークと統合。

// async-graphql minimal
use async_graphql::{Object, Schema, EmptyMutation, EmptySubscription};

struct Query;

#[Object]
impl Query {
    async fn hello(&self) -> &'static str { "world" }
}

let schema = Schema::new(Query, EmptyMutation, EmptySubscription);

juniper — より古い Rust ライブラリ。async-graphql 登場前は最も人気だった。今もメンテされているが、新規プロジェクトは async-graphql 寄り。

18章 · JVM · .NET · Ruby · Elixir · PHP · Swift

他の言語陣営を一気に。

JVM — graphql-java (低レベル実装)、DGS Framework (Netflix が作った Spring 統合)、Sangria (Scala)。Netflix が DGS をオープンソースにしたことで JVM 陣営の事実上の標準になった。

.NET — Hot Chocolate 13 (ChilliCream)。最も人気。code-first。Federation 2 (Hot Chocolate Fusion)。GraphQL.NET の方が古いが、Hot Chocolate がモダン標準。

// Hot Chocolate minimal
public class Query {
    public string Hello() => "world";
}

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddGraphQLServer().AddQueryType<Query>();
var app = builder.Build();
app.MapGraphQL();
app.Run();

Ruby — graphql-ruby。GitHub が作ったライブラリで Ruby 陣営の事実上の標準。Shopify · GitHub 自身が深く使う。

Elixir — Absinthe。Phoenix 統合。関数型スタイルの整った schema-first。購読を Phoenix Channels の上で自然に動かす。

PHP — Lighthouse (Laravel 統合)、webonyx/graphql-php (低レベル)、GraphQLite (Symfony · Laravel · Slim すべて対応)。

Swift / Apple — Apollo iOS (Apollo 公式の iOS クライアント)。graphql-swift はほぼ死んでいる。iOS は事実上 Apollo iOS が唯一の選択肢。

19章 · Subscriptions と graphql-ws

GraphQL 購読の輸送方法。

graphql-ws プロトコル — The Guild が標準化した新しい WebSocket プロトコル。古い Apollo の subscriptions-transport-ws を置き換える。2026年現在、事実上の標準。

SSE (Server-Sent Events) — GraphQL Yoga と The Guild が推す代替。WebSocket が重い環境 (サーバーレス · エッジ · 一部ファイアウォール越し) で自然。HTTP/2 ベース。

HTTP multipart — defer · stream の輸送機構。

// graphql-ws メッセージフロー (概念)
client -> connection_init
server -> connection_ack
client -> subscribe (id, query, variables)
server -> next (id, payload) (繰り返し)
server -> complete (id)

推奨: 新規プロジェクトは graphql-ws プロトコルへ。Apollo の古いプロトコルは deprecated。サーバーレス · エッジが優先なら SSE は魅力的な代替。

20章 · N+1 問題と DataLoader パターン

GraphQL サーバーで最も頻繁な落とし穴。

# このクエリ一行が、雑なリゾルバーでは数百回の DB 呼び出しになる
query {
  posts {
    id
    author { name }
  }
}

posts が100件あれば author 取得のクエリが100回別々に走る。これが N+1 問題だ。

DataLoader パターン (Facebook, 2016)。同じティック (tick) に入ってきた ID をバッチでまとめて一度の DB 呼び出しに。結果を ID 順に再分配する。

// DataLoader minimal
import DataLoader from 'dataloader'

const userLoader = new DataLoader(async (ids) => {
  const users = await db.user.findMany({ where: { id: { in: ids } } })
  return ids.map((id) => users.find((u) => u.id === id))
})

// リゾルバー内
const author = await userLoader.load(post.authorId)

このパターンが標準になった理由は単純 — よく動く。ほぼすべての GraphQL サーバーフレームワークが DataLoader を1級でサポートする (async-graphql · gqlgen · Strawberry · Hot Chocolate いずれも)。

PostGraphile 5 の Grafast は別のアプローチを取る。plan-based execution — クエリを受け取った時点で実行計画を作り、DataLoader なしでも N+1 を回避する。コンセプトはより明快だが、実装の難度が非常に高い。

21章 · Persisted Queries と信頼可能なクエリ

GraphQL のセキュリティモデルは難しい。クライアントが任意のクエリを送れるため、悪意あるクライアントが重いクエリでサーバーを枯渇させ得る。

Automatic Persisted Queries (APQ) — クライアントはクエリハッシュだけを送り、サーバーが知らないときだけクエリを受け取る。狙いはキャッシュ効率とペイロード削減。セキュリティ効果は弱い。

Trusted Documents / Persisted Operations — クライアントがサーバーに事前登録したクエリだけ実行可能。外部クライアント (公開 API) には不適合だが、モバイル · Web のような信頼クライアントには最強のセキュリティモデル。WunderGraph の Operations · Relay の persisted queries · Apollo の Trusted Documents はいずれも同じ概念。

Query Complexity / Depth Limit — クエリのコストを事前に計算し、上限を超えたら拒否。graphql-shield · graphql-cost-analysis · Apollo Router の Limits プラグイン。

// 深さ制限の例 (graphql-depth-limit)
import depthLimit from 'graphql-depth-limit'

server.use({ validationRules: [depthLimit(10)] })

22章 · GraphQL vs REST vs tRPC vs gRPC

2026年の全体像。

技術	データ形	型安全 (TS)	発見性	モバイル適合	マイクロサービス合成
GraphQL	クライアント指定	1級 (codegen)	自動 (introspection)	1級	1級 (Federation)
REST	サーバー決定	自前	OpenAPI	まあまあ	自前
tRPC	関数呼び出し	1級 (ネイティブ)	TypeScript LSP	弱い (TS 必須)	まあまあ
gRPC	サーバー決定 (proto)	1級 (codegen)	proto スキーマ	1級	強い

推奨領域:

公開 API · 外部統合 → REST + OpenAPI

内部フルスタック TS アプリ → tRPC

モバイルクライアントが頻繁に異なるデータ形を要求 → GraphQL

サービス間通信 → gRPC + grpc-web または Connect (Buf)

数十〜数百のサービスを単一グラフへ → GraphQL Federation 2

GraphQL が万能ではないことは2026年の合意だ。しかし「分散グラフ合成」が必要な席では、依然 GraphQL がほぼ唯一の選択肢に近い。

23章 · 韓国 · 日本企業の GraphQL 導入

韓国

Coupang — 一部のフロントページ (特に ELK 検索結果ページ) で GraphQL ゲートウェイを運用。モバイルアプリが多様なデータ形を要求する場所で自然に採用された。
Toss — 一部の内部サービスで Apollo Federation を使いマイクロサービスを合成。自前ゲートウェイを運用。
NCsoft — 内部の在庫 · ゲームデータ管理に GraphQL を導入。gqlgen ベース。
Kakao — 一部サービス (特に広告 · 決済) で GraphQL を使う。内部ツール · 管理画面の比重が大きい。
Naver Clova — 一部の AI ツールで GraphQL を RAG データグラフとして活用。

日本