この技術でできること
- 通信回数や通信データ量の無駄をなくすことで、画面の表示速度（パフォーマンス）を劇的に向上できる
- 「データ取得中（ローディング）」「エラー」のUI表示を、システムの実態に即して無理なくデザインに組み込める
- フロントエンド（UI）とバックエンド（データ）の開発を並行して進めるための明確な境界線（契約）を作れる
例: 「ユーザーのプロフィール情報」と「そのユーザーの最近の投稿10件」を別々のAPIで2回に分けて取得（通信の無駄）するのではなく、特定の画面の仕様に合わせて1回の通信でまとめて返すAPI（またはGraphQL等の技術）を用意することで、画面の「表示のもたつき」や「二段階のローディング表示」を防ぐことができます。
なぜ難しいか
APIは「画面の構造（UI）」と「データベースの構造」という、形が全く違う2つの世界を翻訳する場所だからです。
データベースはデータを効率よく綺麗に保存するために関係性（リレーション）を細かく分割していますが、画面（UI）はユーザーに見せるために様々な情報を一つのビューに混ぜ合わせています。この乖離を埋めるため、「誰がデータベースの情報を画面用に組み立てるか（フロント側で何回も通信して組み立てるか、バックエンド側で1つの塊にして送るか）」という重い設計判断が必要になります。
設計プロセスの判断ポイント（Before/After）
パターン: Over/Under Fetching（データの取りすぎと足りなさ）
Before（現実の悪い例）:
UI側で単に「ユーザー一覧のリスト（名前とアイコンのみ）」を出したいだけなのに、既存の GET /users APIを叩き、全ユーザーの詳細情報（年齢、住所、決済履歴などの重いデータ）まで一緒に取得してしまう（Over Fetching）。
→ 通信量が無駄に増大し、モバイル回線での表示が著しく遅くなる。
After（現実的な整理）: ユースケースに合わせて、一覧用の軽量なAPI（名前とアイコンURLだけを返す）と、詳細プロフィール用のAPIを事前に分けて設計する。またはGraphQLなどを用いて「UI側から必要な項目だけを指定して受け取る」技術を採用する。
なぜ改善されるか（なぜ現実的か）: 「画面に必要なデータ量」と「ネットワークに乗せるデータ量」が一致することで、通信遅延という最大のUXボトルネックが解消されるからです。
代替手段: バックエンド改修が重い場合は、フロントエンドのすぐ裏にBFF（Backends For Frontends：UI用のデータ組み替え専用サーバー層）を置き、そこで既存の重いAPIのデータを必要な分だけに整形してから画面に渡す仕組みを作る。
アンチパターンと衝突（デザイナー × エンジニア）
❌ 「このダッシュボード画面用に、全部のデータを1発で返して」
デザイナーの視点: ダッシュボードを開いた時、グラフも新着通知もプロフィールも同時にパッ！と表示されてほしい。だから1つのAPIで全部のデータを一括で返してほしい。（品質＝ローディングを感じさせないシームレスな表示） エンジニアの視点: 異なるデータベースの集計結果を1つにまとめようとすると、一番遅い処理（複雑なグラフの集計）が終わるまでAPI全体が結果を返せなくなる。結果、何もない真っ白な画面が5秒間続く最悪の事態になる。（品質＝部分ごとの効率的な通信と分散エラー耐性）
なぜ衝突するか（品質の定義差）: デザイナーは「表示タイミングの一致」を求めますが、バックエンドエンジニアは「サーバーの負荷分散と最速の初期応答時間（TTFB：最初の応答が返るまでの時間 等）」を重視しているためです。
どう合意するか:
- 画面を「一瞬で出したい軽い重要データ（通知等）」と「遅れて表示してもよい重いデータ（グラフ等）」に切り分ける。
- データの種類ごとに個別にAPIを取得し、「スケルトンスクリーン」を活用して部分的に段階表示していくUIを一緒に設計する。
実践チェックリスト
最低ライン（Must）
[ ] UIデザイン上に「非同期（データの取得待ち）」が発生する場所を理解し、プレースホルダーを用意している [ ] 「この情報を出すために裏側でどんな通信が発生するか」を大まかにエンジニアと確認している
理想ライン（Better）
[ ] APIの取得失敗（通信エラー）だけでなく、取得結果が0件だった場合（Empty State）のUIも定義している [ ] エンジニアと「この画面を最速で表示するために、どのデータを優先して取得すべきか」を議論できている
関連技術
前提となる技術
- 状態管理 — 取得したAPIのデータをフロントエンドでどう保持するかの受け皿
次に学ぶ技術
- パフォーマンス最適化 — API設計の良し悪しが直結する、速度のUXへの反映領域
まとめ
- この技術の本質: クライアント（UI）とサーバー（データ）の間に結ばれる「データ交換の契約書」
- 体験への影響: 表示のもたつき、ローディングの美しさ、エラー時の不快感など、通信を挟むすべての体験を決める
- 実務での判断軸: 「この画面に必要な表示を、サーバーへの問い合わせ方（通信回数・順序）から逆算して最適化できているか？」
- 次に学ぶべき技術: パフォーマンス最適化（APIからのデータをブラウザ上でいかに速く「体感」させるかを学ぶ）
目的別のおすすめ:
- データを受け取った後の表示最適化なら → パフォーマンス最適化
- アプリ全体の分離の構造を知るなら → アーキテクチャパターン
