BFFとは？API Gatewayとの違い・採用判断とアンチパターンを実装視点で解説

BFF（Backends For Frontends）は、Webやモバイルなど画面ごとに専用のバックエンドを置く設計パターンです。読み方は「ビーエフエフ」。フロントエンドが必要とする形にデータを整えてから返す中間層で、複数のマイクロサービスを画面側で束ねる手間を肩代わりします。この記事では、BFFが解決するover-fetching／under-fetchingの課題、API Gatewayやマイクロサービスとの役割分担、どの条件なら採用に見合いどの規模では過剰投資になるのか、そして運用で崩れやすいアンチパターンまで、実装者と技術選定者の視点で整理します。

まとめ：BFFの本質と採用可否の結論

BFFは「1つの画面種別につき1つのバックエンド」を用意し、そのフロントエンド専用にAPIを設計する層です。複数サービスの呼び出し集約、画面に合わせたレスポンス整形、認証情報の秘匿を担い、フロントエンドの通信を1本にまとめます。SoundCloudのPhil Calçado氏らが提唱し、Sam Newman氏が『Building Microservices』で整理、Microsoftのアーキテクチャ文書でもパターンとして扱われています（2026年時点）。

採用の分岐点ははっきりしています。フロントが2種類以上（Web・iOS・Androidなど）あり、背後がマイクロサービスに分かれ、画面ごとにレスポンス要件が食い違うなら、BFFは費用対効果に見合います。逆に、フロントが1つでバックエンドが単一なら、BFFは運用対象を1つ増やすだけの過剰投資です。判断を誤らないための条件と、パススルー化・共有BFFの肥大化といった失敗パターンは本文で具体的に示します。

BFFとは何か、フロントエンド専用バックエンド層が担う集約と整形の役割

BFFの位置づけは単純です。フロントエンドとマイクロサービス群の間に立ち、画面が使いやすい形に整えたAPIだけを公開します。フロント側は個々のサービスを直接知らずに済み、通信の複雑さをBFFに閉じ込められます。

BFFの読み方とBackend for Frontendという名称が指すもの

BFFはBackend for Frontendの略で、読み方は「ビーエフエフ」です。パターン名としては複数形の「Backends For Frontends」で語られることが多く、これは「フロントエンドの種類ごとにバックエンドを分ける」という設計思想を表しています。Web用とモバイル用で必要なデータの粒度や項目は異なるため、1つの汎用APIで両方をまかなうより、画面種別ごとに専用の口を用意するという発想です。汎用の共有APIを1本置く方式とは、ここで明確に分かれます。

BFFがover-fetchingとunder-fetchingを解消する仕組み

画面が汎用APIを直接叩くと、2つの無駄が生まれます。1つはover-fetching。一覧画面に名前しか要らないのに、住所や購入履歴まで含む重いレスポンスを受け取ってしまう状態です。もう1つはunder-fetching。1画面を描くのに商品・在庫・レビューと複数のAPIへ何度も往復し、通信回数が膨らむ状態を指します。

BFFはこの往復とデータ選別をサーバー側に移します。画面が必要とする項目だけを、必要な数のサービスから集めて1回のレスポンスにまとめる。結果としてモバイル回線での表示速度と実装の見通しが良くなります。GraphQLを用いて画面ごとにクエリを設計する構成も、目的は同じ「画面に合わせた過不足のないデータ供給」です。

BFFの典型的な構成とNode.jsを中心とした技術スタック

実装ではNode.jsとTypeScriptの組み合わせが主流です。理由は明快で、フロントエンドと同じ言語・型定義を共有でき、画面を作るチームがそのままBFFを保守できるからです。データ集約にGraphQL（ApolloやNestJS）を据える構成、あるいはREST集約に留める構成のどちらも取られます。

近い機能をフレームワークが内蔵する例も増えました。Next.jsのRoute HandlersやServer Componentsは、画面を描く直前にサーバー側で複数APIを束ねる点でBFFと重なります。小さく始めるならフレームワーク内蔵の層で足り、独立運用が必要になった段階で専用サービスへ切り出す、という段階設計が現実的です。

API Gatewayやマイクロサービスとの役割分担で見るBFFの位置づけ

BFFはよくAPI Gatewayと混同されます。両者は隣り合う層ですが、設置の単位と目的が別物です。ここを取り違えると、Gatewayに画面ロジックを詰め込む、あるいはBFFで全社共通の認証をやり直すといった責務のねじれが起きます。

API GatewayとBFFの違いと現場での使い分けの判断軸

API Gatewayはシステム横断で1つ置き、認証・流量制御・ルーティングといった基盤機能をまとめる層です。対してBFFはフロント種別ごとに置き、その画面専用のデータ整形を担います。Gatewayは変更頻度が低い基盤側、BFFは画面に追従して頻繁に変わる層、と考えると役割が分かれます。

両者は排他ではなく、Gatewayの内側に各BFFを並べる構成が一般的です。認証やレート制限はGatewayに集約し、画面固有の整形はBFFに寄せる。この線引きの詳しい根拠は、APIゲートウェイの役割とリバースプロキシ・サービスメッシュとの違いで整理しています。

マイクロサービス構成におけるBFFの配置場所と責務の切り分け

BFFが力を発揮するのは、背後が複数のマイクロサービスに分かれている場合です。サービスが商品・注文・在庫と分割されているほど、画面を1つ描くための呼び出し先が増えます。その集約点をフロント側に置くと通信が煩雑になるため、画面専用のBFFに引き受けさせます。

逆に背後がモノリス1本なら、集約する相手がいないためBFFの旨味は薄いままです。自社がモノリスとマイクロサービスのどちらを採るべきか未整理なら、モノリスとマイクロサービスの違いとモジュラモノリスの整理を先に押さえると、BFF導入の是非も判断しやすくなります。BFFはあくまで分散構成を前提にした緩衝材で、クラウドネイティブなシステム構成の一部品として位置づけると設計が締まります。

SSRやNext.jsが担うBFF的な処理との重なりと切り分け

サーバーサイドレンダリング（SSR）とBFFは、機能が重なる部分があります。SSRは画面のHTMLをサーバー側で組み立てる際、複数APIからデータを集めるため、実質的にBFFの集約処理を内包します。小規模ならSSR層がBFFを兼ねて構いません。

切り分けの目安は「そのデータ整形をWeb以外のクライアントも使うか」です。モバイルアプリも同じ整形結果を必要とするなら、SSR層に閉じ込めず独立したBFFへ出す。Webだけが使う整形なら、Next.jsのRoute Handlersに留めておく方が運用は軽くなります。将来モバイルが増える見込みがあるかどうかで、最初から分けるか後で切り出すかを決めます。

BFFを採用すべき要件と過剰投資になる場面を分ける損益分岐の基準

BFFは万能の構成ではありません。運用するサービスが1つ増える以上、それに見合うだけの複雑さが背後にあって初めて元が取れます。ここでは採用に踏み切る条件と、逆に見送るべき基準を条件付きで言い切ります。

BFFの導入が費用対効果にしっかり見合うと言える3つの必要条件

次の条件が重なるほど、BFFの投資対効果は高くなります。

• フロントが2種類以上ある（Web・iOS・Androidなど）。画面ごとにデータ要件が食い違い、汎用APIでは両立が苦しい。
• 背後がマイクロサービスに分割され、1画面あたりの呼び出し先が3つ以上に及ぶ。
• フロントエンドチームが自分たちでBFFを保守できる体制がある（言語・型を共有し、リリースを独立させたい）。

3つとも当てはまるなら、BFFはフロントの開発速度と通信効率を同時に引き上げます。実務ではまずこの3条件を満たすかどうかだけを確認すれば十分です。設計や実装体制まで含めて外部の技術パートナーと詰めたい場合は、Webシステム開発の相談窓口で構成段階から検討できます。

小規模なシステム構成においてBFFが過剰投資になる見送りの基準

採用しない判断も同じくらい大切です。フロントが1つしかなく、バックエンドも単一のアプリケーションなら、BFFは導入しません。集約する相手がおらず、整形もアプリ内で完結するため、BFFは単に監視・デプロイ・障害対応の対象を1つ増やすだけの負債になります。

スタートアップの立ち上げ期も見送り側です。仕様が固まらないうちに層を分けると、変更のたびにフロント・BFF・サービスの3箇所を直すことになり、開発が遅くなります。この段階ではNext.jsのRoute Handlersなどフレームワーク内蔵の層でBFF的な処理を代用し、フロントが2種類目に増えた時点で独立サービスへ切り出す。過剰な先回りは避けます。

BFFの運用で陥りやすい3つのアンチパターンとその回避の指針

導入後に価値を削るのは、次の3つの崩れ方です。

1. パススルー化。BFFが整形も集約もせず、受けたリクエストをそのまま下流へ流すだけになる。この状態なら層を挟む意味がなく、削除の対象です。
2. 共有BFFの肥大化。全画面向けの処理を1つのBFFに集めた結果、フロント種別ごとの独立性が失われ、変更が全画面に波及する。フロント単位で分ける原則に戻します。
3. ビジネスロジックの流入。値引き計算や在庫引当といった業務ルールをBFFに書き始め、下流サービスと責務が二重化する。BFFは整形と集約に徹し、業務ロジックはサービス側へ返します。

回避の指針は一貫しています。BFFに置くのは「その画面のための整形と集約」だけ。判断に迷う処理が出たら、それを他のクライアントも必要とするか、業務ルールそのものかを問い、どちらかに該当すればBFFの外へ出します。

BFFの導入検討でよく寄せられる質問と実装・判断の観点からの回答

BFFの導入検討で実際に挙がる質問を、実装と判断の観点から5つ整理します。

BFFとAPI Gatewayはどちらを先に導入すべきですか？

基盤としての認証・流量制御が課題なら先にAPI Gatewayを、画面ごとのデータ整形が課題なら先にBFFを検討します。多くの現場ではGatewayを外周に置き、その内側にBFFを並べる順序が収まりやすい構成です。両方を同時に立てる必要はなく、痛みの大きい側から入れて構いません。

BFFはNode.js以外の言語でも実装できますか？

可能です。GoやKotlin、Javaで実装する現場もあります。Node.jsとTypeScriptが好まれるのは、フロントエンドと言語・型を共有でき、画面を作るチームがそのままBFFを保守できるためです。保守の担い手が誰かで言語を選ぶと、運用の負荷が下がります。

BFFとGraphQLは何が違うのですか？

BFFは設計パターン、GraphQLはデータ取得のための技術です。両者は競合せず、BFFの実装手段としてGraphQLを選ぶ関係です。GraphQLを使えば画面ごとに必要な項目だけをクエリで指定でき、over-fetchingを抑えられます。REST集約でBFFを組む選択肢も残ります。

フロントエンドが1つでもBFFは必要ですか？

原則として不要です。フロントが1種類で背後も単一なら、集約も整形もアプリ内で完結し、BFFは運用対象を増やすだけになります。将来モバイルアプリなど2種類目のフロントが加わる見込みが立った時点で、独立したBFFへ切り出す判断が現実的です。

BFFを導入すると開発体制はどう変わりますか？

フロントエンドチームがBFFの保守も担う体制へ寄ります。画面の変更に合わせてBFFのAPIも同じチームが直せるため、バックエンドチームへの依頼待ちが減る点が利点です。一方でデプロイ・監視の対象が増えるため、少人数のチームでは兼務の負荷を見積もったうえで導入します。

関連記事

• APIゲートウェイとは？役割・機能と導入判断：BFFと隣り合う基盤層。認証・流量制御との責務の切り分けを詳説。
• モノリスとは？マイクロサービスとの違い：BFFの前提となる分散構成。導入是非の土台になる整理。
• クラウドネイティブとは？CNCFの定義と構成技術：BFFを位置づけるクラウドネイティブ全体像。
• Webシステム開発：BFFを含む構成設計から実装まで相談できる自社サービス。