スマートフォンのアプリやWebサイトって、サーバーからデータをもらう仕組みで動いてるよね。いろんな情報が必要な時に、毎回「あ、この情報もください」「あ、あの情報も」って何度ももらわないといけない…そんなめんどくささを全部解決しちゃう新しい方法が「GraphQL」なんだ。この記事を読めば、「あ、こういうことか！」ってGraphQLの便利さが必ず理解できるよ。
- GraphQLは データをもらう新しい仕組み で、自分がほしい情報だけを自由に選んで取ってこられる
- 従来のREST APIは 決まった形のセット をもらうのに対し、GraphQLは カスタマイズ自由
- アプリやWebサイトが 効率よくデータ通信 できるので、スマートフォンのバッテリーやネット通信量も節約できる
もうちょっと詳しく
GraphQLという名前は「Graph Query Language」の略で、「つまりグラフ状のデータを質問する言葉」という意味。データがグラフのようなつながり構造を持っていて、その中から自分たちが欲しい部分だけを「質問」する形でもらえるんだ。REST APIは「/users」とか「/products」みたいに、決まったURL（つまりルート・入口）に行ったら、そこにある全部の情報がもらえる仕組み。でもGraphQLは、たったひとつの入口からでも「このユーザーの名前と、その人がいいねした商品の値段だけください」みたいな複雑な質問ができるんだよ。
GraphQLはデータの構造と取得方法がセットになった言語。自由度がすごく高い。
⚠️ よくある勘違い
→ GraphQLはデータベースではなく、データベースやサーバーからデータをもらう「質問の方法」。具体例で言えば、ファイル棚（データベース）そのものじゃなくて、図書館員にリクエストする「用紙の様式」みたいなもの。
→ 正解。データベースやサーバーから「どうやってデータをもらうか」のルールを決める方法。どんなデータベースの前でも使える。
[toc]
REST APIとGraphQL、いったい何が違う？
まずね、API（つまり「アプリやサイトがサーバーに『データちょうだい』って頼む仕組み」）について説明するから、ついてきてよ。
昔からあるREST APIっていう方法を考えてみようか。例えば、Twitterのアプリでユーザー情報をもらう場合、「https://api.twitter.com/users/tanaka」っていうURLにアクセスする。すると、田中さんの名前、プロフィール画像、フォロワー数、つぶやき数…いろんな情報がまとめて返ってくるんだ。「セットメニュー」で例えると、ハンバーガー、ポテト、ドリンク、デザートがセットになってくるみたいに。
ところが、「あれ、私は名前とプロフィール画像だけでいいのに、フォロワー数なんかいらないな」ってことも多い。特にスマートフォンで、通信量が限られてるときはね。でもREST APIだと、「セットだから全部ついてくる」ってわけ。もし名前だけほしいなら、わざわざ別のURL「https://api.twitter.com/users/tanaka/name」みたいなのを作んなきゃいけない。
だから、データが増えたり、欲しい組み合わせが増えたりすると、作るべきURLが…10個、100個、1000個になっちゃう。プログラマーは「あ、こういう情報の組み合わせが欲しいニーズがあるんだ」ってわかるたびに、新しいURLを追加しないといけなくなって、すごく大変なんだ。
その点GraphQLは全然違う。GraphQLなら、たったひとつの入口（つまりURL）があって、そこに「こういう情報が欲しい」という『質問』を送る。その質問の内容は、プログラマーが決めるのではなく、データがほしい側（つまりアプリやWebサイト）が自由に決められるんだ。
「田中さんの名前とプロフィール画像をください」なら、そういう質問を送る。「すべてのユーザーの名前とフォロワー数をください」という質問も送れる。つまり、質問の自由度が圧倒的に高い。これがGraphQLのいちばん大きな特徴だよ。
GraphQLの仕組み：「質問」と「答え」
では、GraphQLで実際にどうやってデータをもらうのか、説明しようか。
GraphQLを使うときは、プログラマーが「クエリ」（つまり「質問」）という文を書く。例えば、こんな感じ。
「ユーザーID番号123の、名前とメールアドレスをください」
これをGraphQL言語（つまりGraphQLのルールに従った書き方）で書くと、こんなふうになる：
“`
query {
user(id: 123) {
name
email
}
}
“`
これって、なんか読みやすくない？「ユーザーのid123の、名前とメールが欲しい」ってことがはっきり書いてある。REST APIなら「/users/123」とか「/users/123/profile」みたいな、ちょっと暗号的なURLを覚えなきゃいけないのに、GraphQLなら「何がほしいか」が直接に書けるわけ。
そして、サーバーがこの質問を受け取ると、「なるほど、名前とメールアドレスだけなんだね」と理解して、その二つだけを返してくる。返ってくる答え（つまりレスポンス）は、こんな感じ：
“`
{
“user”: {
“name”: “田中太郎”,
“email”: “tanaka@example.com”
}
}
“`
見て、すごくシンプルでしょ？質問と同じ形の答えが返ってくる。これがGraphQLのスマートなところ。つまり、質問の形と答えの形が似てるから、すごく直感的に理解できるんだ。
もし、プロフィール画像のURLも追加で欲しくなったら、質問に「profileImageUrl」を足すだけ。REST APIみたいに「あ、新しいエンドポイント（つまり入口）を作らなきゃ」って心配しなくていい。既に存在する入口に、違う質問を送るだけで済むんだよ。
GraphQLを使うと、何がメリット？
じゃあ、GraphQLを使うと、具体的には何が良くなるのか、考えてみようか。
まず第一に、通信量が減る。これ、すごく大事。スマートフォンのアプリだと、毎月の通信量制限がある人も多いよね。REST APIで不要な情報まで全部もらってると、その分だけネット通信量が増えちゃう。でもGraphQLなら「このデータだけください」と言えるから、無駄がない。だからスマートフォンのバッテリーも長持ちするし、通信速度も速く感じるんだ。
第二に、プログラマーの仕事が減る。REST APIだと、「あ、こういう情報が欲しいケースが出てきた」ってわかるたびに、新しいエンドポイント（つまり入口）を作らないといけない。それって、テストもしなきゃいけないし、バグが出たら対応もしなきゃいけない。すごく手間だ。でもGraphQLなら、一つの入口でどんな質問にも対応できるから、新しいエンドポイントを作る手間がぐっと減るんだ。
第三に、フロントエンドの開発が簡単になる。フロントエンドっていうのは、ユーザーが見る画面（つまりブラウザやアプリの見た目）の部分。フロントエンド開発者は「あ、このボタンを押したら、このデータを取ってきたい」って思ったら、GraphQLで質問を書くだけ。REST APIみたいに「あ、どのエンドポイントを呼べばいいんだろう？」って調べたり、ドキュメント（つまり説明書）を読む手間がない。ほしいデータの構造を見てれば、自動的に質問を作れるくらい、GraphQLは直感的だからね。
さらに、型システムがある。「型」っていうのは「このデータは文字、このデータは数字」みたいに、データの種類が決まってる仕組みのこと。GraphQLには最初からこの型システムがあるから、「あ、このデータは必ず文字列だ、だから数字の計算には使えない」ってわかる。REST APIだと、ドキュメントに「このフィールドは数字です」って書いてあっても、プログラマーが「あ、ドキュメント見忘れた」ってなったら、バグが出ちゃう。でもGraphQLなら、型システムがあるから、プログラムが「あ、これはダメだ」って自動的に教えてくれるんだ。これをスキーマ駆動開発っていう。
GraphQL、デメリットもあるよ
いいことばっかり言ってると嘘くさいから、デメリットも説明しなきゃ。GraphQLにもむろん、課題があるんだ。
まず、複雑さ。REST APIって、本当にシンプルだ。「このURLを呼んだら、こういうデータが返ってくる」って、ほぼそれだけ。初心者でも理解しやすい。でもGraphQLは、質問を正しく書かなきゃいけないし、スキーマ（つまりデータの構造のルール）も理解しなきゃいけないし、いろいろ学ばなきゃならないことが増える。
次に、キャッシュが難しい。「キャッシュ」っていうのは「さっき取ってきたデータを、また取ってくる前に、もう一度同じデータが必要になったら、そのままのデータを使う」という仕組みのこと。つまり、同じ質問に対して毎回サーバーに聞かないで、前の答えを再利用する。こうすると、サーバーの負担が減るし、アプリも速くなるんだ。でもGraphQLは、質問の形が人によって違うから、「あ、この質問はさっき答えたやつだ」って判断が難しい。REST APIなら「/users/123」っていうURL単位でキャッシュできるけど、GraphQLは「質問の細かい内容」まで見なきゃならんから、複雑になるんだ。
また、エラーが複雑。REST APIだと、「ユーザーが見つかりません」なら404エラーが返ってくる。「何か問題です」なら500エラーが返ってくる。すごくシンプルな「エラーの言葉」で済む。でもGraphQLは、質問が複雑だから、エラーも複雑。「ユーザーの名前は取ってこられたけど、メールアドレスは権限がなくて取ってこられませんでした」みたいな、部分的なエラーが発生することもある。プログラマーがエラーを正しく処理する難しさが増すんだ。
GraphQLって、実は身近なところで使われてる
最後に、GraphQLが実際に、どんなところで使われてるのか、説明しておこう。有名なところでいえば、Facebook（今のMeta）が作ったくらい、大きな企業が支えてる技術。Twitter、GitHub、Shopifyなんかも、GraphQLを使ってる。
例えば、GitHubっていう、プログラマーが一緒に仕事するサイトがあるんだけど、ここのAPIがGraphQL。もし「このリポジトリ（つまり作品保存場所）のコード数とコミット数（つまり変更の記録）の合計をください」って質問できるから、いちいち別のAPIを呼ぶ必要がない。便利だよね。
あるいは、Shopifyっていう、オンラインショップを作るプラットフォームでも、GraphQLが使われてる。ショップのオーナーが「この商品の値段と在庫数をください」って聞きたいときに、GraphQLなら簡単に質問できる。
つまり、GraphQLは「大きなデータを、たくさんの人が、いろんな形で使う必要があるサービス」で、特に活躍する技術なんだ。データがシンプルで、アクセスする人も少ないなら、REST APIで十分。でも「いろんなデータの組み合わせが必要」「アクセス人数が多くて、通信量を最小限にしたい」って場面では、GraphQLは本当に強いんだ。