GraphQL設計原則

状況: MAU 200万人のSNSアプリ。タイムライン表示にREST APIを使っており、1画面の表示に平均3.2回のAPIコールが必要だった。

RESTの場合: タイムラインを表示するのに /posts → /users/{id} → /posts/{id}/comments と3回APIを叩く必要がある。

GraphQLの場合:

query Timeline {
  posts(first: 20) {
    id
    content
    createdAt
    author {
      name
      avatarUrl
    }
    comments(first: 3) {
      content
      author { name }
    }
  }
}

1リクエストで、投稿・著者情報・コメントを必要なフィールドだけ取得。

APIコール数3.2回→1回、データ転送量65%削減、表示速度3倍。1エンドポイントで必要なデータだけを取得する——それだけでこの差がつく。

状況: 従業員60名のプロジェクト管理SaaS。Web・iOS・Android向けにそれぞれ専用のREST APIエンドポイントを作っており、APIエンドポイント数が142個に膨れ上がっていた。

問題: 新機能追加のたびに3プラットフォーム分のAPIを作成・テスト。バックエンドチーム4名がAPI作成だけで工数の40%を消費。

GraphQL化:

• 共通スキーマ1つで3プラットフォームに対応
• Webは詳細データ（ガントチャート情報含む）を取得
• モバイルはサマリーデータのみ取得（同じエンドポイント）
• クライアントが必要なフィールドを選ぶので、専用エンドポイント不要

APIエンドポイント142→1、API開発工数5人日→1.5人日。「クライアントが必要なデータを選ぶ」仕組みにより、プラットフォーム別APIという概念自体が消えた。

状況: 地方自治体が運営する観光情報プラットフォーム。宿泊施設・飲食店・観光スポットなど1,200件のデータをREST APIで提供していたが、データ利用パートナー（旅行サイト、地図アプリ等）ごとに欲しいデータが異なり、カスタムエンドポイントの要望が絶えなかった。

GraphQL化の効果:

• 旅行サイトA: 宿泊施設の空室情報と料金だけを取得
• 地図アプリB: 緯度経度と営業時間だけを取得
• グルメサイトC: 飲食店のメニューと口コミだけを取得
• パートナーが自分で必要なフィールドを選べるので、カスタムAPI開発がゼロに

パートナー対応の開発工数、月40時間→2時間。APIパートナー数は1年で5社→18社に。カスタムAPI開発から解放されたことで、むしろデータ利用者が増えた。