アーキテクチャパターン

BFF（Backend for Frontend）びーえふえふ

Backend for FrontendAPI設計マイクロサービスフロントエンド最適化APIゲートウェイSPA

BFFって何？ベストフレンドフォーエバーのこと？

簡単に言うとこんな感じ！

ちょっと違うよ笑。BFFは「Backend for Frontend（バックエンド・フォー・フロントエンド）」の略で、スマホアプリ用・Web用・TV用など、それぞれの画面専用に「通訳係のサーバー」を用意するパターンのことなんだ。お客さん（画面）によって欲しい情報の形が違うから、専用の窓口を作ってあげるイメージだよ！

BFF（Backend for Frontend）とは

BFF（Backend for Frontend）とは、フロントエンド（画面側）の種類ごとに専用のバックエンド層を設けるアーキテクチャパターンです。スマートフォンアプリ、Webブラウザ、スマートTV、IoTデバイスなど、クライアントの種類が増えるにつれて「それぞれが必要とするデータの形や量が違う」という問題が生じます。BFFはその解決策として、各クライアント専用の中間サーバーを置くことで、それぞれに最適化されたAPIを提供します。

従来は「1つの汎用API」を全デバイスで共有するスタイルが多く使われていましたが、汎用APIは「モバイルには不要なデータが大量に含まれる」「複数のAPIを何度も呼び出す必要がある」といった非効率を生みがちでした。BFFを挟むことで、クライアントが必要な形にデータを整形・集約してから渡すことができます。これにより、フロントエンドの開発チームはバックエンドの都合を気にせず、自分たちに最適なAPIを手に入れられます。

このパターンは2015年にSoundCloudのエンジニア、Sam Newmanによって広く知られるようになりました。マイクロサービス構成（機能ごとに小さなサービスを分割する設計）と相性がよく、多くの大規模サービスで採用されています。

BFFの構造と仕組み

BFFは「クライアントとバックエンドサービスの間に立つ専用の翻訳レイヤー」です。どのような役割を担うかを整理すると以下のようになります。

役割	説明
データ集約	複数のマイクロサービスへのリクエストをまとめて1回の応答にする
データ整形	各クライアントに不要なフィールドを削除・必要な形に変換する
認証・認可の代理	クライアントに代わってトークン検証などを行う
プロトコル変換	REST/GraphQL/gRPCなど、クライアントに合った形式で応答する
エラーハンドリング	バックエンドのエラーをクライアントに合わせた形に整える

BFFを「専用窓口」で覚えよう

役所の窓口に例えると覚えやすいです。市役所には「戸籍担当」「税務担当」「福祉担当」と部署が分かれています（＝マイクロサービス）。でも一般市民（＝フロントエンド）がそれぞれの窓口を自分で回るのは大変。そこで「総合案内デスク（＝BFF）」が「あなたに必要な書類」をまとめて用意してくれる、というイメージです。

誰が何をするか：責任の分離

【BFFなし】                      【BFFあり】
                                  
 スマホアプリ ──┐               スマホアプリ ──→ BFF(モバイル用) ──┐
 Webブラウザ ──→ 汎用API         Webブラウザ ──→ BFF(Web用)       ├→ マイクロサービス群
 スマートTV ──┘                 スマートTV  ──→ BFF(TV用)         └──（注文/商品/ユーザー等）
 
 ↑ 全デバイスが同じ重い              ↑ 各デバイスが自分専用の
   APIを叩く。過不足あり              軽量APIを叩ける

歴史と背景

2010年代初頭：スマートフォンの急速な普及により、WebとモバイルでAPIを共有する設計の限界が顕在化。モバイル向けには通信量の削減・応答速度の改善が求められるように
2015年：SoundCloudのSam Newmanが「Pattern: Backends For Frontends」として体系的に整理・公開。マイクロサービスアーキテクチャの普及とともに注目を集める
2016年〜：Netflix・Amazon・Facebookなどの大規模サービスが独自にBFFパターンを採用していたことが広まり、実用性が広く認知される
2018年〜：GraphQLの普及とともに「BFF＝GraphQL層」という組み合わせが一般的な実装パターンになり、フロントエンドチームが自律的にAPIを設計できるようになる
2020年代〜：モバイル・Web・IoT・音声デバイスなどクライアントの多様化がさらに進み、BFFパターンはスタンダードな設計指針として定着

比較対象	目的	BFFとの違い
APIゲートウェイ	認証・ルーティング・レート制限などの共通処理	全クライアント共通。BFFはクライアント個別
GraphQL	クライアントが必要なフィールドを自由に指定	BFFの実装手段の1つとして組み合わせることが多い
BFF（本パターン）	クライアント種別ごとに最適化したAPI提供	専用の集約・整形レイヤーを設ける
モノリシックAPI	1つのAPIで全機能を提供	BFFはその逆。クライアント別に分割する考え方

メリット・デメリット

発注者・意思決定者の立場から、採用時に押さえておきたいポイントを整理します。

メリット

メリット	説明
フロントエンドの自律性向上	各チームが自分たちのBFFを管理できるため、他チームへの依存が減る
クライアント最適化	モバイルには軽量なレスポンス、Webには豊富なデータなど、適切な量のデータを返せる
バックエンドの安定性	フロントエンドの変更がバックエンドに波及しにくくなる
セキュリティ境界の明確化	各クライアントが触れるAPIの範囲をBFFで制御できる

デメリット・注意点

デメリット	説明
管理するサービスが増える	BFFが増えるほど運用コスト・監視対象が増加する
ロジックの重複	複数のBFFで似たような処理を書きがちになる
チーム体制との整合が必要	BFFの分け方はチーム構造（コンウェイの法則）と合わせるべき