フレームワーク活用ガイドひとことで言うと#
Web・モバイル・管理画面など、フロントエンドの種類ごとに専用のバックエンドAPI層を用意するパターン。「1つのAPIで全クライアントを賄う」の限界を突破する。
押さえておきたい用語#
- BFF（Backends for Frontends）
- フロントエンドごとに専用のバックエンドを持たせるアーキテクチャパターンのこと。Web用BFF、モバイル用BFFのように分ける。
- API Aggregation（エーピーアイ アグリゲーション）
- 複数のマイクロサービスからデータを取得し、クライアントが必要な形に組み立てて返す処理を指す。
- Over-fetching（オーバーフェッチング）
- クライアントが実際に必要とする以上のデータをAPIが返してしまう問題。モバイルでは帯域の無駄になる。
- Under-fetching（アンダーフェッチング）
- 1回のAPIコールでは情報が足りず、追加のリクエストが必要になる問題。レイテンシの増加につながる。
BFFの全体像#
こんな悩みに効く#
- 1つの汎用APIでWeb・モバイル・管理画面を賄っており、どのクライアントにも中途半端
- モバイルで不要なデータまで返しており、通信量が膨大
- フロントエンドチームの要望にバックエンドが追いつかない
基本の使い方#
フロントエンドの種類（Web/Mobile/Admin）ごとに1つのBFFが基本。ただし差が小さい場合は無理に分けない。
- Web + Mobile で要件が大きく異なる → 分ける
- iOS + Android で要件がほぼ同じ → 1つのMobile BFFで共有
具体例#
従業員60名のフードデリバリー企業。汎用APIが店舗情報・メニュー・レビュー・配達員情報をまとめて返しており、モバイルの一覧画面の表示に平均1.8秒かかっていた。
Mobile BFFを新設し、一覧画面に必要な「店舗名・評価・配達時間・サムネイル」だけを返すエンドポイントを作成。
| 指標 | 汎用API | Mobile BFF |
|---|---|---|
| レスポンスサイズ | 48KB | 6KB |
| 一覧表示時間 | 1.8秒 | 0.4秒 |
| API呼び出し回数/画面 | 3回 | 1回 |
モバイルアプリのストア評価が 3.2 → 4.1 に改善。Web側は既存APIをそのまま使い続けたので影響ゼロだった。
企業向け経費精算SaaS。経理担当者が月末に数百件の経費を一括承認する必要があるが、汎用APIは1件ずつの処理しかサポートしていなかった。一括承認に15分かかり、顧客離れの原因になっていた。
Admin BFFを新設し、バルク操作用のエンドポイントを実装。
POST /admin/expenses/bulk-approveで最大500件を一括処理- 進捗をWebSocketで返却し、管理画面にプログレスバーを表示
- エラーが発生した件だけを個別に返却
一括承認の所要時間が 15分 → 45秒 に短縮され、月末の経理担当者のストレスが大幅に軽減された。モバイルアプリは従来通り1件ずつの操作フローを維持。
月間PV800万のニュースメディア。Web版はSEOのためにSSR（サーバーサイドレンダリング）が必須だが、モバイルアプリはJSON APIだけでよい。1つのバックエンドで両方に対応しようとして、どちらも中途半端な状態だった。
BFF分割の設計
- Web BFF: Next.jsベースでSSR対応。OGPメタタグ・構造化データ・パンくずリストなどSEO関連の処理を担当
- Mobile BFF: 軽量なREST APIのみ。画像はクライアント画面サイズに合わせたURLを返す
分離後、Web版のCore Web VitalsのLCPが 3.2秒 → 1.4秒 に改善し、検索流入が月間で 23%増加。モバイルアプリ側は不要なHTML生成がなくなりAPI応答が速くなった。
やりがちな失敗パターン#
- BFFにビジネスロジックを入れてしまう — BFFはデータの集約と変換だけを行う。バリデーションや計算ロジックをBFFに書くと、複数BFF間で重複が生まれる
- BFFを細かく分けすぎる — iOS BFF、Android BFF、iPad BFFのように分けると運用コストが爆発する。データ要件が近いクライアントは1つのBFFにまとめる
- BFFとフロントエンドのチームを分けてしまう — BFFはフロントエンドチームが所有すべき。バックエンドチームが管理すると、結局「フロントエンドの要望待ち」になる
- すべてのサービスを毎回呼び出す — 画面に不要なサービスまで呼び出すとレイテンシが増える。画面ごとに必要なサービスだけを呼ぶ
よくある質問#
Q: BFFとAPIゲートウェイは何が違いますか？ A: APIゲートウェイは認証・レート制限・ルーティングなどのインフラ横断的な機能を担う共通レイヤーです。BFFはクライアント（iOS、Web等）ごとに最適化されたデータ集約・変換を行うアプリケーション層です。多くの構成ではAPIゲートウェイの後段にBFFが置かれ、両者は役割が異なります。
Q: BFFはどのチームが所有すべきですか？ A: フロントエンドチームが所有するのが原則です。BFFはUIの要件（必要なフィールド、レスポンス形式）を最もよく知るフロントエンドチームが管理することで、バックエンドチームへの依頼待ちなく素早く変更できます。バックエンドチームが管理するとBFFがボトルネックになりがちです。
Q: iOSとAndroidで別々のBFFを作るべきですか？ A: データ要件が大きく異なる場合は分けることを検討しますが、多くのケースでは1つのモバイルBFFで対応できます。判断基準は「UIの差異がAPIレスポンスに影響するか」です。同じデータを使い表示だけ異なるなら共有、APIの形式や必要フィールドが根本的に異なるなら分離を検討してください。
Q: GraphQLがあればBFFは不要ですか？ A: 代替になる場合があります。GraphQLはクライアントが必要なフィールドを自分でクエリできるため、BFFが担うデータ選択の役割を一部代替します。ただしGraphQLは学習コストが高く、N+1問題などのパフォーマンス課題もあります。REST APIでのオーバーフェッチが問題になっているならBFF、クライアントの多様なクエリ要件に応えたいならGraphQLを検討してください。
まとめ#
BFFはフロントエンドの種類ごとに専用のバックエンド層を置くことで、各クライアントに最適化されたAPIを提供するパターン。汎用APIの 「どのクライアントにも中途半端」 問題を解消し、モバイルの通信量削減やWeb版のSSR対応など、プラットフォーム固有の要件に柔軟に対応できる。BFFはフロントエンドチームが所有し、ビジネスロジックを入れない規律を保つことが成功の鍵になる。