GraphQLエコシステム2026 — Apollo / GraphOS / Yoga / urql / Relay / Pothos / Hasura DDN 徹底比較

プロローグ — 「GraphQLは死んだ」が死んだ

2023年頃から、X(旧 Twitter)、Reddit、HN には定期的に「GraphQL is dead」系の投稿が流れていた。tRPC が急速に台頭し、Netflix のフェデレーション事例への懐疑論が増え、Shopify が一部新規 API を REST に戻したことが何度も引用された。2024年にはあるカンファレンス基調講演で「GraphQL はマイクロサービスのように使われすぎたツールだ」と言われ、議論が再燃した。

2026年5月現在、その議論の結末は比較的はっきりしている。

• GraphQL は死んでいない。ただし「すべての API のデフォルト」という幻想は死んだ。
• GraphQL は明確な領域(BFF、モバイルクライアント、フェデレーションされたバックエンド、公開 API)でより強くなった。
• 小さな単一バックエンドや内部 RPC は tRPC、gRPC、REST が持っていった。
• それでも市場は大きい。State of JS、JetBrains、StackOverflow の 2025 年調査で、GraphQL 利用率は 30〜40% で安定している。

本記事は、その市場の上にどんなツールがどう陣取っているか、そして 2026 年に新規プロジェクトを始めるとき何を選ぶべきかを整理する。Apollo / GraphOS のマネージド陣営、Yoga / Mesh / urql / Pothos の The Guild 陣営、Relay / Pothos / Nexus のコードファースト陣営、Hasura DDN / Hot Chocolate / gqlgen / Strawberry / graphql-rust の言語別サーバ、Stellate のインフラまで — 1本で見る。

1. 2026年のGraphQLエコシステム — 「GraphQLは死んだ」議論のあと

まず 2025〜2026 の事実関係を整理する。

• Apollo は依然市場 1 位。Server 5(2025 年)、Client 4 が標準スタック。
• GraphOS は Apollo のマネージドフェデレーション基盤。Apollo Studio は GraphOS に吸収。
• The Guild は OSS 陣営の対抗。GraphQL Yoga 5、Mesh 1、GraphQL Code Generator、Envelop、GraphQL Hive。
• urql(Formidable、後に Hasura が一部後援)は Apollo Client の軽量版。v5 で React 19 / Suspense 統合。
• Relay は Meta が維持。v18 で React 19 / Server Component 対応。
• Pothos は TypeScript コードファーストの新標準。Nexus は事実上メンテモード。
• Hasura は v2 期の問題(スケール、ロックイン、ライセンス)を DDN(2024)で整理。
• 言語別サーバは Hot Chocolate(.NET)、gqlgen(Go)、Strawberry(Python)、async-graphql / juniper(Rust)。
• インフラは Stellate(GraphQL CDN)、Apollo Router、Hive、Inigo、Tyk の GraphQL Proxy。

大きな流れは 3 つ。

1. フェデレーションの一般化 — 「1 社 = 1 グラフ」の単一巨大スキーマは消えた。ドメイン別 subgraph + ゲートウェイが標準。
2. コードファーストの台頭 — SDL ファーストではなく、コード(TypeScript / Python / .NET)からスキーマを推論。Pothos、Strawberry、Hot Chocolate、gqlgen すべて同じ流れ。
3. REST / tRPC との共存 — GraphQL は BFF・集約・フェデレーション層、tRPC / REST は内部・単一サーバ。宗教戦争は終わった。

本稿の出発点はこの 3 つ。

2. GraphQL vs tRPC vs REST — いつ何を選ぶか

最も多い質問から。3 者の違いを表で。

意思決定ツリー。

1. フロントとバックが同じ TS モノレポで他言語が絡まないなら、tRPC が最速。
2. **モバイルや複数クライアント(iOS / Android / Web / 組み込み)**があり、必要なフィールドが各自異なるなら GraphQL。
3. 複数チームのバックエンドを 1 つに見せる必要があるなら GraphQL Federation。
4. 公開 API、外部パートナー連携、単純 CRUDなら REST(OpenAPI)が安全。
5. 内部マイクロサービス間呼び出し、高スループットなら gRPC。

2026 年の現実は、1 社にこれら全部がある。公開 API は REST、モバイル / Web BFF は GraphQL、内部サービス間は gRPC、TS 単一フルスタックは tRPC。「1 つだけ選べ」という問いはもう古い。

3. Apollo Server 5 / Client 4 — 標準の座

Apollo は 2025 年に Server 5 と Client 4 をリリースした。この 2 つのメジャーは一緒に語って初めて意味がある。

Apollo Server 5 の主要変更

• Node.js 18 以下のサポート終了、ESM 優先。
• @apollo/server に統合(従来の apollo-server-express、apollo-server-fastify などを 1 つに)。
• 標準統合ヘルパーは startStandaloneServer、expressMiddleware、koaMiddleware。
• HTTP/2、gRPC 変換サポート拡大。
• 組み込みプラグインの整理(ランディングページ、使用量レポート、キャッシュ制御)。

最小構成。

// server.ts
import { ApolloServer } from '@apollo/server'
import { startStandaloneServer } from '@apollo/server/standalone'
import { typeDefs } from './schema'
import { resolvers } from './resolvers'

const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: process.env.NODE_ENV !== 'production',
})

const { url } = await startStandaloneServer(server, {
  listen: { port: 4000 },
  context: async ({ req }) => ({
    user: await getUserFromToken(req.headers.authorization),
  }),
})

console.log(`Apollo Server ready at ${url}`)

Apollo Client 4 の主要変更

• React 19 / Suspense が一級市民。useSuspenseQuery、useReadQuery が標準。
• キャッシュポリシーの簡素化。正規化キャッシュは継続。
• defer / stream ディレクティブ対応。
• ローカル状態管理は reactive vars 中心(Apollo Link State は廃止)。
• バンドルサイズ削減(Tree shaking 強化)。

// client.ts
import { ApolloClient, InMemoryCache, HttpLink } from '@apollo/client'

export const client = new ApolloClient({
  link: new HttpLink({ uri: '/graphql' }),
  cache: new InMemoryCache(),
})

React での使用。

import { useSuspenseQuery } from '@apollo/client/react'
import { gql } from '@apollo/client'

const ME = gql`
  query Me {
    me {
      id
      name
      email
    }
  }
`

export function Profile() {
  const { data } = useSuspenseQuery(ME)
  return <div>{data.me.name}</div>
}

強み

• 最も成熟。ほぼすべてのパターンがドキュメント化されている。
• フェデレーションツール(Rover、Studio、Router)との統合。
• エンタープライズサポート。

弱み

• バンドルは依然大きい。Client だけで圧縮後 50KB+。
• 「Apollo は重い」という印象が定着しており、新規チームは urql を先に検討。
• Apollo Studio が GraphOS に吸収され、無料枠が縮小。

4. GraphOS — Apolloのマネージドフェデレーション

GraphOS は Apollo が作るフェデレーション基盤。主要コンポーネントは 3 つ。

1. Apollo Router — Rust で書かれたゲートウェイ。subgraph ルーティング、クエリプランニング、キャッシュ。
2. Schema Registry — subgraph スキーマの中央保管庫。変更検出、互換性チェック。
3. Studio(GraphOS UI) — 使用量メトリクス、クエリ解析、運用ツール。

Apollo Router

Apollo Router は従来の Apollo Gateway(Node 製)を置き換える Rust 製ゲートウェイ。スループットは桁違いに速く、メモリ使用量も少ない。2026 年時点で新規にフェデレーションゲートウェイを構築するならほぼ無条件で Router。

# router.yaml
supergraph:
  introspection: false
include_subgraph_errors:
  all: true
telemetry:
  exporters:
    metrics:
      prometheus:
        enabled: true
    tracing:
      otlp:
        enabled: true
        endpoint: http://otel:4317

料金モデル

GraphOS は Serverless(無料)、Dedicated(有料)、Enterprise の 3 階層。無料枠で小規模チームは十分動くが、運用トラフィックが増えるとすぐ有料に移る必要がある。Apollo のビジネスモデルが GraphOS に依存しているため、2024〜2025 にかけて値上げが一度あった。

代替

GraphOS の代替は GraphQL Hive(The Guild)、Inigo、Stellate(主にキャッシュ)。Hive は OSS でセルフホストも可能で、より軽量なフェデレーション運用を望むチームに人気。2026 年に新規スタートなら Apollo Router + Hive の組み合わせも十分合理的。

5. GraphQL Yoga 5 + Mesh 1(The Guild) — 軽量陣営

The Guild は GraphQL OSS エコシステムを事実上牽引するコレクティブ。2026 年の主力プロジェクト。

• GraphQL Yoga 5 — 軽量 GraphQL サーバ。Apollo Server の代替。
• GraphQL Mesh 1 — 複数データソース(REST、OpenAPI、gRPC、DB)を自動で GraphQL 化。
• Envelop — GraphQL サーバプラグインフレームワーク。
• GraphQL Code Generator — スキーマから TS / Java / Swift コード生成。
• Hive — スキーマレジストリ・可観測性(GraphOS 代替)。
• GraphQL Tools — schema stitching、mocking、scalars などのユーティリティ。

GraphQL Yoga 5

Yoga は「Express と Apollo Server のいいとこ取りを軽量に」というコンセプト。v5 で Node 18+、Fetch API ベース、Bun / Deno 互換、エッジランタイム(Vercel / Cloudflare)一級対応。

// yoga.ts
import { createYoga, createSchema } from 'graphql-yoga'
import { createServer } from 'node:http'

const yoga = createYoga({
  schema: createSchema({
    typeDefs: /* GraphQL */ `
      type Query {
        hello: String!
      }
    `,
    resolvers: {
      Query: {
        hello: () => 'Hello from Yoga 5',
      },
    },
  }),
})

createServer(yoga).listen(4000)

GraphQL Mesh 1

Mesh は複数ソース(REST、gRPC、OpenAPI、JSON Schema、Postgres、MongoDB)を自動で GraphQL に合流させる。v1 で設定がシンプルになり、フェデレーション統合が強化。Mesh で作った subgraph を Apollo Router の背後に置くパターンが一般的。

強み

• 軽量。Yoga は Apollo Server の半分以下のサイズ。
• Web 標準(Request / Response)ベース。どこでも動く。
• OSS、商用ロックインなし。

弱み

• フェデレーション運用は Hive を別途立てる必要(GraphOS ほど統合されていない)。
• ドキュメントは Apollo ほど豊富ではない。
• エンタープライズサポートは The Guild のコンサルに依存。

6. urql 5(Formidable) — Apollo Clientの代替

urql は Formidable 製の軽量クライアント。「Apollo が重い」と思う人が最初に見る代替。v5 で React 19、Suspense、Server Component を一級サポート。

主要な違い

• バンドル約 10KB(Apollo Client の 1/5)。
• Exchange(ミドルウェア)ベース。キャッシュ・認証・リトライなどを組み合わせる。
• デフォルトは document cache。正規化キャッシュは @urql/exchange-graphcache でオプトイン。

import { Client, fetchExchange, cacheExchange, Provider } from 'urql'

const client = new Client({
  url: '/graphql',
  exchanges: [cacheExchange, fetchExchange],
})

function App() {
  return (
    <Provider value={client}>
      <Profile />
    </Provider>
  )
}

React コンポーネント。

import { useQuery } from 'urql'

const ME = `
  query Me {
    me { id name }
  }
`

function Profile() {
  const [result] = useQuery({ query: ME })
  if (result.fetching) return <p>Loading...</p>
  if (result.error) return <p>Error</p>
  return <p>{result.data.me.name}</p>
}

強み

• 軽い。バンドルサイズに敏感なモバイル Web・embed ウィジェットに最適。
• API がシンプル。初めて触る人でも 30 分で慣れる。
• React / Vue / Svelte / Preact すべてサポート。

弱み

• 正規化キャッシュは別パッケージ。デフォルトは document cache(クエリ単位)。
• フェデレーション運用ツールはない(クライアントのみ)。
• コミュニティは Apollo の 1/10 程度。

urql を選ぶとき

• バンドルが重要な embed ウィジェット、マーケサイト。
• 正規化が不要な単純なページ。
• Apollo Client の複雑さが負担になる小規模チーム。

7. Relay 18(Meta) — Facebook社内標準

Relay は Meta が作り社内で使う GraphQL クライアント。Apollo / urql とは哲学が違う。「性能のためにコンパイル時に最大限保証する」立場。

主要概念

• Fragment colocation — コンポーネントが自分に必要なフィールドを直接宣言。
• Compiler — ビルド時にクエリを解析・最適化。persisted queries を自動生成。
• Store — 正規化されたクライアントサイドデータベース。
• Suspense + Concurrent — React 18+ の Suspense / Concurrent Mode と深く統合。
• GraphQL Server 要件 — Connection 仕様(cursor-based pagination)、Node インターフェース(global ID)など。

// UserProfile.tsx
import { useFragment, graphql } from 'react-relay'

const UserProfileFragment = graphql`
  fragment UserProfile_user on User {
    name
    avatarUrl
  }
`

export function UserProfile({ user }: { user: UserProfile_user$key }) {
  const data = useFragment(UserProfileFragment, user)
  return <h1>{data.name}</h1>
}

Relay 18 の新機能

• React 19 / Server Component 対応。
• Relay Resolvers GA — クライアントサイドの派生フィールド。
• Data-driven Dependency(DDD) — コンポーネントとデータペイロードを同時に fetch。
• Live Queries ベータ。

強み

• 大規模アプリで最高の性能。Meta が Facebook / Instagram / WhatsApp で実証。
• ビルド時解析。ランタイムオーバーヘッド最小。
• Concurrent React との統合が最も深い。

弱み

• 学習曲線が急。Apollo の 3〜5 倍。
• サーバが Relay 規約に従う必要(Connection、Node)。
• 小規模チームには過剰インフラ。

Relay を選ぶとき

• 画面が数百ある大型 SPA。
• Facebook / Pinterest / Linear のようなデータ集約アプリ。
• Meta 出身エンジニアが多いチーム。

8. Pothos — TypeScriptコードファーストスキーマビルダー

Pothos(旧 GiraphQL)は TypeScript で GraphQL スキーマをコードファーストに定義するライブラリ。2024〜2025 に Nexus を退けて事実上の標準になった。

コードファーストとは何か、なぜいいのか

伝統的な SDL ファーストワークフロー。

1. schema.graphql に型を SDL で書く。
2. graphql-codegen で TS 型を生成。
3. リゾルバでその型を import。

これは 1 つの変更に 2 ステップ必要。コードファーストは逆。

1. TS でスキーマをビルダー API で書く。
2. ビルダーが SDL を自動生成。

Pothos の例

// schema.ts
import SchemaBuilder from '@pothos/core'

const builder = new SchemaBuilder({})

const User = builder.objectRef<{ id: string; name: string }>('User')

builder.objectType(User, {
  fields: (t) => ({
    id: t.exposeID('id'),
    name: t.exposeString('name'),
  }),
})

builder.queryType({
  fields: (t) => ({
    me: t.field({
      type: User,
      resolve: () => ({ id: '1', name: 'Alice' }),
    }),
  }),
})

export const schema = builder.toSchema()

Pothos の強み

• 型安全性が最強。リゾルバの戻り値型まで推論。
• プラグインエコシステムが豊富 — Prisma、Drizzle、Relay、Federation、Scope Auth。
• codegen ステップ不要。
• フェデレーション(Subgraph)一級対応。

Nexus との比較

Nexus は Pothos より先に出て一時は標準だった。しかし型推論で Pothos が強く、Nexus メンテナの活動が減ったことで事実上座を譲った。新規はほぼ Pothos。

Prisma 統合例

import SchemaBuilder from '@pothos/core'
import PrismaPlugin from '@pothos/plugin-prisma'
import { prisma } from './prisma'

const builder = new SchemaBuilder<{
  PrismaTypes: PrismaTypes
}>({
  plugins: [PrismaPlugin],
  prisma: { client: prisma },
})

builder.prismaObject('User', {
  fields: (t) => ({
    id: t.exposeID('id'),
    name: t.exposeString('name'),
    posts: t.relation('posts'),
  }),
})

Prisma モデルから GraphQL 型をほぼ自動生成し、N+1 もプラグインが自動解決。

9. Hasura DDN — 新アーキテクチャ

Hasura は Postgres・SQL Server・BigQuery などの DB 上に GraphQL API を自動生成するツールとして有名になった。しかし v2 まで進むうちにいくつかの問題が生じた。

• 単一巨大メタデータファイルがチーム協業を阻害。
• 複数 DB、非 DB データソースが扱いにくい。
• Cloud ライセンスと OSS ライセンスの変化でコミュニティが揺れた。
• 性能・スケーリングが運用で頭痛の種。

DDN(Data Delivery Network)

2024 年に発表された Hasura DDN は v2 の限界を整理した新アーキテクチャ。

• Subgraph 単位でメタデータ分割 — ドメイン別チームが独立作業。
• Data Connectors — Postgres だけでなく ClickHouse、MongoDB、REST、gRPC などを一級市民として扱う。
• ローカルファースト — CLI でローカル開発、GitOps 親和。
• GraphQL Federation 互換 — DDN subgraph を Apollo Router の背後に置ける。

強み

• DB 上の自動 CRUD は依然最強。数日でフルスタックバックエンドを立てられる。
• 権限(Permission)を SDL で宣言的に定義。
• 複数ソースを 1 グラフに合流するシナリオに強い。

弱み

• v2 → v3(DDN)の移行は事実上新規作業。
• Cloud 価格が高いという声が依然。
• 自由度の高いビジネスロジックは結局別サービスに切り出される。

Hasura DDN を選ぶとき

• データモデルが明確で CRUD 中心のバックオフィス / 管理コンソール。
• 複数 DB・SaaS API を 1 グラフに集約することが多いチーム。
• 高速プロトタイプ。

10. Hot Chocolate(.NET) / gqlgen(Go) / Strawberry(Python) / graphql-rust

JS / TS の外の言語エコシステムも整理する。

Hot Chocolate(.NET — ChilliCream)

• .NET の事実上の標準。2026 年にメジャー 14 リリース。
• コードファースト基本。属性ベースのスキーマ定義。
• Federation、Subscriptions、Persisted Queries などすべて対応。
• Banana Cake Pop という GraphQL IDE を提供。

public class Query
{
    public Book GetBook() =>
        new Book { Title = "C# in Depth", Author = new Author { Name = "Jon Skeet" } };
}

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

var app = builder.Build();
app.MapGraphQL();
app.Run();

gqlgen(Go — 99designs)

• Go で最も人気。SDL ファースト + コード生成。
• schema.graphqls に SDL を書き、gqlgen generate でリゾルバインターフェースを生成。
• DataLoader、Federation、Subscriptions 対応。
• 99designs / Vista が維持。

Strawberry(Python)

• Python で最も急成長中。Graphene の代替。
• 型ヒントベースのコードファースト。デコレータでスキーマ定義。
• Django / FastAPI 統合優秀。
• Federation、Subscriptions 対応。

import strawberry

@strawberry.type
class User:
    id: strawberry.ID
    name: str

@strawberry.type
class Query:
    @strawberry.field
    def me(self) -> User:
        return User(id="1", name="Alice")

schema = strawberry.Schema(query=Query)

graphql-rust(async-graphql / juniper)

• Rust 陣営は 2 つに分かれる。async-graphql(より活発)、juniper(古参標準)。
• async-graphql は Federation、Subscriptions、Apollo Tracing まで対応。
• Actix、Axum、Warp、Rocket などの Web フレームワークと結合。
• 性能は圧倒的。Rust で GraphQL サーバを書く理由はそこにある。

言語別選択ガイド

11. Stellate — GraphQL CDNキャッシュ

GraphQL の弱点の 1 つはキャッシュ。同じクエリでも変数によって応答が変わり、すべてのリクエストが POST なので標準 HTTP キャッシュが効きにくい。Stellate はその問題のための GraphQL 専用 CDN。

主要概念

• クエリ別キャッシュ — クエリハッシュ + 変数でキー生成、結果をキャッシュ。
• Edge cache — 世界中の PoP からキャッシュ応答。
• 自動無効化(invalidation) — Mutation がどの型を変えるかを追跡し、関連キャッシュを失効。
• Rate limiting / Persisted queries も同時に。

利用イメージ

Stellate に GraphQL エンドポイントを登録すると、その前段に CDN URL が発行される。クライアントは元のエンドポイントの代わりに Stellate URL を呼び出す。クエリ応答は数秒〜数分キャッシュされ、Mutation が発生すると関連キャッシュが自動失効。

強み

• 同じ GraphQL クエリを頻繁に叩くモバイルアプリ・ホーム画面で効果大。
• バックエンドにほぼ手を入れずキャッシュを導入。
• Apollo、urql、Relay などクライアント無関係。

弱み

• 有料 SaaS。価格はトラフィック比例。
• ユーザ別に異なる応答が必要なクエリはキャッシュ効率が低下。
• 自前(Apollo Router + Redis + Varnish)で代替可能。

12. Federation 2 + subgraph compositionパターン

GraphQL Federation は複数 subgraph(独立サービスのグラフ)を 1 つの supergraph に合流させる方式。Apollo が標準を定義し、v2.x で安定。

主要ディレクティブ

• @key(fields: "id") — エンティティの識別子定義。
• @extends — 他 subgraph の型を拡張。
• @external / @requires / @provides — フィールド依存を明示。
• @shareable — 同じフィールドを複数 subgraph で定義可能。
• @inaccessible — 外部公開対象から除外(内部専用)。

Subgraph 例(Users)

type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}

type Query {
  me: User
  user(id: ID!): User
}

Subgraph 例(Orders)

extend type User @key(fields: "id") {
  id: ID! @external
  orders: [Order!]!
}

type Order @key(fields: "id") {
  id: ID!
  total: Float!
}

ゲートウェイ(Apollo Router)が両 subgraph を合成して supergraph を作り、クエリプランナが me { orders { total } } を 2 つの subgraph に分割発行する。

Subgraph composition の運用パターン

• ドメイン単位の分割 — チーム = subgraph が最も一般的なマッピング。
• 共有 entity は 1 箇所が所有 — User は Users subgraph がオーナー、他は extends。
• CI 統合 — PR ごとに Rover でスキーマチェック、互換性違反をブロック。
• 段階的導入 — 巨大モノリスグラフを subgraph に分割するのは通常四半期単位。

アンチパターン

• 細かすぎる分割 — subgraph が 20+ になると運用地獄。
• すべての entity をすべての subgraph で公開 — @inaccessible を積極活用。
• subgraph 間依存が深すぎる — 1 クエリが 5 段階を経るとレイテンシが崩壊。

13. Persisted Queries / defer / stream / Live Queries

2025〜2026 で安定化した GraphQL 高度機能を押さえる。

Persisted Queries

クライアントはクエリ本文ではなくハッシュのみを送り、サーバは事前登録済みクエリを実行する。効果は 2 つ。

1. ネットワーク節約 — モバイルで大きなクエリペイロードを毎回送らずに済む。
2. セキュリティ — クライアントが任意クエリを送れない。攻撃面が縮小。

Apollo Persisted Queries、Hive Persisted Documents、Relay Persisted Queries はすべて同じコンセプト。モバイル・embed クライアントでは事実上必須。

@defer / @stream

大きな応答を一度に送らず、一部を先に送って残りをストリーミング。

query Profile {
  me {
    id
    name
    ... on User @defer {
      slowField
    }
  }
}

サーバはチャンク応答(multipart/mixed)で一部データを先送する。大きなページの初期レンダリング時間を大幅短縮できる。Apollo Server 5、Yoga 5、Hot Chocolate すべて対応。

Live Queries

クエリ結果が変わると自動でクライアントに更新がプッシュされる。Subscription と似ているが — Subscription は明示的にチャンネルを購読する一方、Live Query は通常のクエリを送るとサーバが変更を検出して再プッシュ。

Relay 18 がベータ対応、Yoga・Hot Chocolate にも実験実装。標準化はまだ進行中だが、チャットやダッシュボードなどのシナリオで魅力的。

Subscriptions(再整理)

• WebSocket または SSE 上で動作。
• Apollo Server は graphql-ws 推奨(レガシーの subscriptions-transport-ws は deprecated)。
• サーバレス環境(Vercel、Cloudflare Workers)では SSE または Pub/Sub(Ably、Pusher)の組み合わせが一般的。

14. 韓国(Kakao、LINE)/ 日本(Mercari、ZOZO)のGraphQL利用

韓国と日本の大手企業が GraphQL をどう使っているかを、公開資料ベースで整理する。

Kakao

• 一部社内サービスで 2017 年頃から導入。
• Channel Talk のような外部 SaaS も一部 GraphQL API を提供。
• カカオスタイル(Zigzag)などグループ企業が BFF に GraphQL を積極利用。Apollo Server + Apollo Client の組み合わせが一般的。
• Kakao 技術ブログにフェデレーション・キャッシュ関連の投稿が多い。

LINE(LY グループ)

• LINE のモバイルメッセージング一部 API で GraphQL を内部利用。
• LY(LINE × Yahoo!)合併後、Yahoo! Japan の一部サービスでも GraphQL 採用。
• LINE エンジニアリングブログにフェデレーション導入事例の記事あり。

Mercari

• Mercari は GraphQL を比較的早期に導入(2019 年頃のモバイルクライアント)。
• マイクロサービスバックエンドの上に BFF として GraphQL を利用。フェデレーション事例を Mercari エンジニアリングブログで公開。
• 子会社の Souzoh も同じスタック。

ZOZO

• ZOZO Technologies が一部新規サービスで GraphQL 採用。
• Codegen ベースのワークフロー(Apollo + graphql-codegen + TypeScript)。
• WEAR など自社アプリで BFF 形態で利用。

共通パターン

• モバイル BFF — iOS / Android アプリに必要なフィールドのみ返すため GraphQL。
• レガシー統合 — REST / gRPC マイクロサービスの上に GraphQL Mesh またはフェデレーションゲートウェイ。
• Apollo 優勢、Yoga / Pothos が漸増 — 新規は Pothos 導入事例が増加。
• 社内スキーマレジストリ — GraphOS の代わりに Hive をセルフホストする事例が日本に多い。

韓国・日本ともに「Apollo Server + フェデレーション + Apollo Router + 社内 / SaaS レジストリ」という大枠は似ている。違いは — 韓国は Kakao / Naver のような巨大インハウスバックエンド中心、日本は Mercari / ZOZO のようなモバイルコマース BFF が主流。

結論 — 2026年にGraphQLを新規選定するなら

最後に 1 行ずつの推奨。

1. 新規 Node / TS 単一サーバ — Yoga 5 + Pothos + Prisma。クライアントは urql または Apollo。
2. 新規 Node / TS フェデレーション — Apollo Server 5 + Apollo Router + GraphOS or Hive。クライアントは Apollo Client 4。
3. Meta 級大型 SPA — Relay 18 + Pothos。インフラは自前運用。
4. モバイル BFF — Apollo Server 5 + Apollo Client 4 + Persisted Queries + Stellate。
5. Python — Strawberry + FastAPI / Django。フェデレーションなら Apollo Router の背後に置く。
6. Go — gqlgen + DataLoader。クライアントは言語無関係。
7. .NET — Hot Chocolate 14。ほぼ他の選択肢なし。
8. Rust — async-graphql + Axum。性能が本当に重要なとき。
9. DB 上の自動 CRUD — Hasura DDN。ただし自由度の高いビジネスロジックは別サービスに。

最後に最も重要な 1 つ。「GraphQL か否か」はもはや単一選択ではない。1 社に GraphQL(モバイル BFF)、tRPC(TS フルスタック)、REST(公開 API)、gRPC(内部 RPC)が同時にあるのが普通だ。GraphQL は死んでいない — 適切な場所を見つけただけ。

参考 / References

• GraphQL 公式サイト
• Apollo GraphQL 公式ドキュメント
• Apollo Server 4/5 マイグレーションガイド
• Apollo Client React ドキュメント
• GraphOS 概要
• Apollo Router ドキュメント
• The Guild — GraphQL Yoga
• The Guild — GraphQL Mesh
• The Guild — GraphQL Hive
• The Guild — Envelop
• GraphQL Code Generator
• urql 公式サイト
• Relay 公式サイト
• Pothos GraphQL
• Nexus GraphQL
• Hasura DDN ドキュメント
• ChilliCream Hot Chocolate
• gqlgen (Go)
• Strawberry (Python)
• async-graphql (Rust)
• Juniper (Rust)
• Stellate
• GraphQL Federation 仕様
• Persisted Queries (Apollo)
• GraphQL @defer / @stream 仕様
• graphql-ws
• State of GraphQL 2024 (The Guild)
• Kakao 技術ブログ
• LINE Engineering Blog
• Mercari Engineering Blog
• ZOZO TECH BLOG