GraphQL サーバーは『複数選択肢から最適を選ぶ』
GraphQL サーバー実装の選択肢が多様化し、用途別に最適なフレームワークが分かれています。本記事では、npm の公式レジストリと各プロジェクトの公式ドキュメントで確かめた数字（2026年10月16日時点）をもとに、主要な選択肢を整理します。GraphQL 実践ロードマップ もご参考に。
主要なライブラリ
(1) Apollo Server：エコシステム最大。(2) GraphQL Yoga：軽量・モダン。(3) Mercurius：Fastify 統合。(4) Pothos：型安全スキーマビルダー。(5) Hot Chocolate：.NET 向け。
数字で見る主要ライブラリ
npm の公式ダウンロード統計（api.npmjs.org）で、2026年9月の1か月のダウンロード数を1年前と比べました。
| パッケージ | 2026年9月 | 2025年9月 | 伸び | 最新版（2026年10月16日時点） |
|---|---|---|---|---|
| @apollo/server | 1,206万 | 597万 | 約2.0倍 | 5.5.1（Node.js 20以上） |
| graphql-yoga | 745万 | 264万 | 約2.8倍 | 5.24.6 |
| @pothos/core | 192万 | 47万 | 約4.1倍 | 4.15.1 |
| mercurius | 80万 | 37万 | 約2.1倍 | 16.12.0 |
| apollo-server（旧パッケージ） | 65万 | 88万 | 約0.74倍 | 3.13.0（非推奨） |
※npm のダウンロード数（api.npmjs.org の月間集計、1万未満は四捨五入）。CI の自動インストールなども含むため、利用者数そのものではありません。最新版・必要な Node.js のバージョンは npm レジストリの登録情報。
ダウンロード数では Apollo Server が最も多く、Yoga がそれに続きます。伸び率では Pothos が約4.1倍と目立ちます。一方、旧パッケージの apollo-server は減っていて、npm 上でも「v2・v3 はサポート終了（2023年10月22日・2024年10月22日）、機能は @apollo/server に移った」と非推奨の表示が出ています。土台となる graphql（GraphQL.js）は2026年9月に約1億9,960万ダウンロードで、2026年6月にメジャー版の17.0.0が公開されました。N+1 対策で使う dataloader も約5,743万ダウンロードあります。
Node.js のバージョンに注意
npm に登録されている最新版の動作条件（engines）を見ると、ライブラリごとに求める Node.js のバージョンが違います。@apollo/server 5.5.1 は Node.js 20 以上、graphql-yoga 5.24.6 は Node.js 18 以上、mercurius 16.12.0 は Node.js 20.9 以上または 22 以上です。土台の graphql 17.0.2 は Node.js 22・24・25、または26以上を条件にしています。graphql を 16 から 17 に上げると、古い Node.js では動かなくなる可能性があるので、サーバーのライブラリと graphql 本体、実行環境の Node.js をまとめて確認してから更新しましょう。最新版の公開は、graphql-yoga と mercurius が2026年10月中旬、@pothos/core が9月中旬で、いずれも更新が続いています。
Apollo Server の特徴
(1) 実績豊富：大規模採用多数。(2) Federation 公式サポート。(3) DataLoader 統合。(4) 監視ツール：Apollo Studio。(5) 料金体系：サーバー本体は MIT ライセンスのOSS、監視などの一部は有料のサービス。
バージョンの切り替えには注意が必要です。npm の登録情報では、Apollo Server v4 は2026年1月26日でサポート終了（end-of-life）となり、現在の主流は2025年7月に出た v5 です。v5 の最新版は Node.js 20 以上を求めています。v4 のまま動かしているプロジェクトは、Node.js のバージョンとあわせて移行の計画を立てましょう。
GraphQL Yoga の特徴
(1) 軽量・依存最小。(2) Plugin システム(Envelop)。(3) Edge 対応。(4) The Guild メンテ：活発。(5) Subscriptions：標準は Server-Sent Events（GraphQL over SSE の distinct connections mode）。WebSocket を使う場合は graphql-ws と組み合わせ（公式ドキュメントより）。
Pothos でのスキーマ定義
(1) コードファースト。(2) TypeScript フル活用。(3) Relay 仕様サポート。(4) Prisma 統合：自動スキーマ生成。(5) Plugin 豊富。TypeScript 上級 もご参考に。
N+1 対策 (DataLoader)
(1) DataLoader：バッチ化+キャッシュ。(2) 1リクエスト内でのキャッシュ。(3) 関連エンティティの効率取得。(4) Prisma 統合パターン。(5) 計測：APM で確認。Observability 実践 もご参考に。
本番運用
(1) クエリ複雑度制限：DoS 対策。(2) persisted queries：許可済クエリのみ。(3) レスポンスキャッシュ。(4) 監視：クエリ別レイテンシ。(5) セキュリティ：認可は resolver で。API レート制限 も合わせて。
失敗しがちなパターン
(1) N+1 を放置。(2) 巨大クエリ無制限：負荷爆発。(3) 認可ロジック散在。(4) エラーレスポンス曖昧。(5) スキーマ放置：deprecation 不在。対策は、(1)DataLoader 必須、(2)複雑度制限、(3)Plugin 集約、(4)errors 形式統一、(5)定期 deprecation、です。
この記事のデータの出典
- npm ダウンロード統計（api.npmjs.org、2025年9月・2026年9月の月間）と npm レジストリの登録情報（2026年10月16日確認）
- GraphQL Yoga 公式ドキュメント「Subscriptions」（The Guild、2026年10月16日確認）
