LabHub

ブログ

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

2026-05-16 · 27 分で読めます · #graphql#apollo#graphos#graphql-yoga#urql#relay#pothos#nexus#hasura#hot-chocolate#gqlgen#strawberry#stellate#federation#deep-dive#japanese

한국어English日本語

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

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

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

本記事は、その市場の上にどんなツールがどう陣取っているか、そして 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 の事実関係を整理する。

大きな流れは 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 者の違いを表で。

項目GraphQLtRPCREST(OpenAPI)
スキーマSDL、明示的TS 型から推論OpenAPI / JSON Schema
呼び出しモデルQuery / Mutation / Subscription関数呼び出しHTTP メソッド + URL
型安全強(codegen)非常に強(型推論)ツール次第
言語全言語クライアントTS 専用全言語
キャッシュ正規化キャッシュ、CDN(Stellate)シンプル(アプリキャッシュ)HTTP キャッシュ親和
適所モバイル、BFF、フェデレーション単一 TS フルスタック公開 / 内部 RPC、単純 CRUD
学習曲線急ほぼなし低い
ペイロードクライアント定義関数シグネチャサーバ定義

意思決定ツリー。

  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 の主要変更

最小構成。

// 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 の主要変更

// 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>
}

強み

弱み

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

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 の背後に置くパターンが一般的。

強み

弱み

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

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

主要な違い

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>
}

強み

弱み

urql を選ぶとき

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

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

主要概念

// 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 の新機能

強み

弱み

Relay を選ぶとき

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 の強み

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 まで進むうちにいくつかの問題が生じた。

DDN(Data Delivery Network)

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

強み

弱み

Hasura DDN を選ぶとき

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

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

Hot Chocolate(.NET — ChilliCream)

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)

Strawberry(Python)

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)

言語別選択ガイド

言語第一選択備考
TypeScript / NodeApollo Server 5 or GraphQL Yoga 5 + Pothosフェデレーションなら Apollo Router
PythonStrawberryGraphene はレガシー
Gogqlgenほぼ独占
.NETHot Chocolateほぼ独占
Rustasync-graphqljuniper は保守的
Java / KotlinDGS(Netflix)or graphql-javaSpring Boot なら DGS
Rubygraphql-ruby(GitHub 維持)Shopify・GitHub が使用
ElixirAbsintheほぼ独占

11. Stellate — GraphQL CDNキャッシュ

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

主要概念

利用イメージ

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

強み

弱み

12. Federation 2 + subgraph compositionパターン

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

主要ディレクティブ

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 の運用パターン

アンチパターン

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(再整理)

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

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

Kakao

LINE(LY グループ)

Mercari

ZOZO

共通パターン

韓国・日本ともに「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

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-graphql-ecosystem-2026-apollo-graphos-yoga-urql-relay-pothos-hasura-ddn-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます