💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 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-ファースト · サーバーフレームワーク · クライアント · ツール · 標準 · 代替技術。そして韓国 · 日本企業の導入事例まで。

この記事で扱うこと:

1. 2026年の GraphQL マップ — 誰が作り、誰が使うか

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

3. 「GraphQL は死んだ」論争の整理

4. Federation v2 vs Schema Stitching vs Module Federation

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

6. Apollo Server 4 と Apollo Client 3.11+

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

8. graphql-mesh と GraphQL Hive

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

10. Supabase GraphQL と WunderGraph

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

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

13. GraphQL Code Generator と型安全性

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

15. Python — Strawberry · Ariadne · Graphene

16. Go — gqlgen · graphql-go

17. Rust — async-graphql · juniper

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

19. Subscriptions と graphql-ws

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

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

22. GraphQL vs REST vs tRPC vs gRPC

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

24. 参考資料

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

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

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 {

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 クライアント。コンパイル時コード生成でランタイムを最小化。

| --- | --- | --- | --- | --- |

| Apollo Client | 35-40KB | 1級 | 中 | 一般的な React/Vue アプリ |

| graphql-request | 1-2KB | なし | 低 | 単純な fetch パターン |

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

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

@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 {

author { name }

}

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

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

// DataLoader minimal

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)

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

22章 · GraphQL vs REST vs tRPC vs gRPC

2026年の全体像。

| --- | --- | --- | --- | --- | --- |

> **推奨領域**:

> - 公開 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 データグラフとして活用。

**日本**

- **メルカリ** — Apollo Federation 2 の本格採用者。マイクロサービスを数十のサブグラフに分解。カンファレンス発表も多い。

- **LINE ヤフー** — Hasura を社内ツール · 管理画面に広く導入。Postgres ベースの社内ツールの約90%が Hasura 上で動く。

- **サイバーエージェント** — gqlgen ベースの Go マイクロサービス。広告 · ゲームのバックエンドで使用。

- **DeNA** — graphql-ruby + Rails の一部モバイルゲームバックエンド。

- **マネーフォワード** — 会計 · 決済ドメインで Apollo Federation の導入を発表 (2024)。

> **共通パターン**: 韓国 · 日本企業ともに「最初は単一グラフで始める → ビジネスが大きくなったら Federation に分解」という経路をたどる。最初から Federation で行く事例はまれ。

24章 · 参考資料

**スペック · 標準**

- GraphQL スペック: https://spec.graphql.org/

- GraphQL Foundation: https://graphql.org/foundation/

- Composite Schemas WG: https://github.com/graphql/composite-schemas-wg

- Federation v2 仕様: https://www.apollographql.com/docs/federation/

**Apollo**

- Apollo Router: https://www.apollographql.com/docs/router/

- Apollo Server 4: https://www.apollographql.com/docs/apollo-server/

- Apollo Client: https://www.apollographql.com/docs/react/

- Stellate (旧 GraphCDN): https://stellate.co/

**The Guild**

- GraphQL Yoga: https://the-guild.dev/graphql/yoga-server

- GraphQL Hive: https://the-guild.dev/graphql/hive

- graphql-mesh: https://the-guild.dev/graphql/mesh

- GraphQL Code Generator: https://the-guild.dev/graphql/codegen

- graphql-ws: https://github.com/enisdenjo/graphql-ws

**DB-ファースト**

- Hasura: https://hasura.io/

- PostGraphile 5: https://postgraphile.org/

- Supabase GraphQL: https://supabase.com/docs/guides/graphql

**WunderGraph · Cosmo**

- WunderGraph: https://wundergraph.com/

- Cosmo Router: https://cosmo-docs.wundergraph.com/

**サーバーフレームワーク**

- Strawberry GraphQL: https://strawberry.rocks/

- gqlgen: https://gqlgen.com/

- async-graphql: https://async-graphql.github.io/

- Hot Chocolate: https://chillicream.com/docs/hotchocolate/

- DGS (Netflix): https://netflix.github.io/dgs/

- Absinthe: https://hexdocs.pm/absinthe/

- graphql-ruby: https://graphql-ruby.org/

- Pothos: https://pothos-graphql.dev/

**クライアント**

- Relay: https://relay.dev/

- urql: https://commerce.nearform.com/open-source/urql/

- Houdini: https://houdinigraphql.com/

**ツール · パターン**

- DataLoader: https://github.com/graphql/dataloader

- graphql-shield: https://github.com/dimatill/graphql-shield

この記事は2026年5月時点である。ゲートウェイ市場と Composite Schemas WG は速いペースで動いている。Apollo Federation の標準化作業が1.0に到達する時点が次の変曲点になる。