BFF（Backend for Frontend）パターン入門｜フロントエンド最適化APIをクラウドで設計するマイクロサービス実装ガイド

モバイルアプリとWebブラウザで同じAPIを叩いているのに、レスポンスが重すぎてモバイルが遅い。画面に必要な項目を揃えるために、フロントエンドが複数のエンドポイントを何度も呼び出している。APIのバージョンアップがすべてのクライアントに影響して身動きがとれない——こういった悩みを抱えたことはないだろうか。

オンプレのモノリシックなWebシステムでは、サーバーサイドがHTMLレンダリングも担うため、こうした問題はあまり顕在化しなかった。しかしクラウドに移行し、APIを分割・スケールするマイクロサービス設計に転換すると、「誰がフロントエンドの都合に合わせた集約をするのか」という問題が浮き彫りになる。

この記事では、その問題を解決するアーキテクチャパターン「BFF（Backend for Frontend）」について、設計上の判断基準・AWS上での実装方針・料金感覚まで、現場のインフラエンジニア視点で解説する。

BFFとは何か——「フロントエンド専用のAPI集約レイヤー」

BFF（Backend for Frontend）は、2015年にSam Newmanが提唱したアーキテクチャパターンだ。名前の通り「フロントエンドのためのバックエンド」、つまりWebブラウザ・モバイルアプリ・IoTデバイスといったクライアントの種類ごとに、それぞれ専用のAPI集約レイヤーを設ける設計を指す。

典型的な構成は次のようなイメージになる。

BFFがない場合、フロントエンドは必要なデータを自分でかき集める（複数のAPIを順次・並列で呼ぶ）か、バックエンドが「全クライアント向けの汎用API」を提供することになる。どちらも構造的に問題が起きやすい。

なぜ「汎用API」だけでは破綻するのか

オンプレ時代の典型的な構成を思い出してほしい。Webサーバーがバックエンドの業務ロジックを呼び出してHTMLを返す——この場合、サーバーサイドが「画面の都合」を知っているので自然と集約されていた。

しかしAPIサーバーになった途端、バックエンドは「データを返す」だけになり、「どう組み合わせるか」はクライアントに委ねられる。複数チャネルが同居し始めると、次の3つの問題が重なって起きる。

①レスポンスの粒度問題
Webブラウザは高解像度の画像URLや詳細スペックが欲しい。スマートフォンは通信量削減のため最小フィールドだけで十分。同じAPIでこれに応えようとすると、余計なフィールドを返し続けるか、クエリパラメータで個別対応するかの泥沼になる。

②チャタリング（Over-fetching / Under-fetching）問題
商品詳細ページを表示するために「商品API」「在庫API」「レビューAPI」「関連商品API」を別々に叩くパターン。通信回数が増え、特に3G環境のモバイルでは体験が著しく劣化する。GraphQLが解決策として話題になる背景の一つでもある（REST API vs GraphQL vs gRPCの違いはこちらを参照）。

③バックエンドのAPIバージョン爆発問題
Webとモバイルの要求の違いをバックエンド側で吸収しようとすると、`/v1/products`、`/v2/products`、`/v2/products?view=mobile`……と際限なくエンドポイントが増殖する。バックエンドチームがフロントエンドの細かい要求変更に追い立てられる状況が生まれる。

BFFはこれらをフロントエンドに近い層で吸収することで、バックエンドのマイクロサービスをフロントエンドの都合から切り離す。マイクロサービスとモノリシックアーキテクチャの比較でも触れているように、マイクロサービスの分割効果を実際に活かすには、こうした「集約責務」の置き場所の設計が欠かせない。

BFF設計の基本判断——「いくつBFFを作るか」

BFFの数については、現場でよく議論になる。主な判断軸を整理しよう。

1. 1つのBFF（シンプル構成）

WebとモバイルのUI差がそれほど大きくなく、チームが小さい段階では、BFFを1つにまとめることもある。差異をBFF内のロジック分岐（User-AgentやリクエストパラメータでWebとモバイルを判定）で吸収する。

メリット: デプロイ・監視・コードの管理先が一か所で済む。
デメリット: BFFが肥大化すると、「どのクライアントの変更か」が混在して可読性が落ちる。

2. チャネルごとにBFFを分ける（推奨パターン）

Web向けとモバイル向けで別BFFを持つ。さらに社内向け管理ツールや外部パートナー向けAPIがあれば、それぞれ独立させる。

これがSam Newman自身が推奨するパターンでもある。チームの所有権がクライアント単位で分かれていると、BFFもその区切りと一致させると摩擦が減る（いわゆる「コンウェイの法則」の応用）。

3. 外部向けAPIは「BFF」でなく「API Gateway」で分離

外部パートナーや第三者が使うAPIは、BFFとは目的が異なる。SLAの安定性・バージョニング・認証方式（OAuth 2.0など）が主な関心事になるため、Amazon API Gatewayをそのまま外向けゲートウェイとして使い、BFFとは別系統にするのが現場では一般的だ（Amazon API Gateway入門も参照）。

AWSでのBFF実装パターン

AWSでBFFを実装する代表的な構成は、次の2パターンだ。

パターンA: API Gateway + AWS Lambda（サーバーレス型）

最も軽量に始められるパターン。Lambda関数一つがBFFの集約ロジックを担い、下流の各マイクロサービスのAPIを呼び出してレスポンスを組み立てる。

# 構成イメージ（AWS CLI / 疑似コード）
# Amazon API Gateway（HTTP API）でルート定義
# GET /web/products/{id} → Lambda: web-bff-product-detail
# GET /mobile/products/{id} → Lambda: mobile-bff-product-detail

# Lambda（web-bff-product-detail）内の処理イメージ
# 1. 商品APIを呼ぶ（Product Serviceへ）
# 2. 在庫APIを呼ぶ（Inventory Serviceへ）
# 3. レビュー集計APIを呼ぶ（Review Serviceへ）
# 4. 3つの結果をマージして一つのJSONで返す

メリットは、トラフィックが少ない段階ではコストがほぼゼロに近いこと（Lambda無料枠は月100万リクエスト）。スケールも自動で行われるため、インフラ管理の手間がかからない。

注意点は、下流のマイクロサービス呼び出しが直列になるとLambdaの実行時間が長くなりやすいことだ。Promise.allなどで並列呼び出しにするか、タイムアウト設計を丁寧に行う必要がある。

パターンB: Amazon ECS / EKS上のコンテナBFF

BFFのロジックが複雑になり、Node.js/Go/Pythonなどで実装したサービスをDockerコンテナとして動かすパターン。Amazon ECSやAmazon EKSと組み合わせる。

# ECS（Fargate）構成例
# ALBでWebとMobileのBFFを振り分ける
# リスナールール: /web/* → web-bff ECSサービス
# リスナールール: /mobile/* → mobile-bff ECSサービス

# ECSサービスはFargateで管理することでEC2の
# インスタンス管理を省略できる

コンテナ型はWebSocket接続やストリーミングレスポンスなど、Lambdaでは扱いにくいユースケースに対応しやすい。チームのNode.js/Goスキルをそのまま活かせるのも利点だ。

サービスメッシュ（Istio、AWS App Meshなど）と組み合わせることで、BFFから下流マイクロサービスへの通信を可観測性高く管理できるようになる。

料金の目安（2026年8月時点）

BFF自体の料金は、実装方式と通信量で大きく変わる。

注意が必要なのは、BFFが下流のマイクロサービスAPIを呼び出す際のVPC間・リージョン間のデータ転送料金だ。同一VPC・同一AZ内の通信は無料だが、AZ間は0.01 USD/GBかかる。BFFと下流サービスが同じAZに乗るよう設計するか、コスト試算時に通信量を見積もっておきたい。

実務Tips：BFFを導入するときの判断基準

【重要】BFFが「効く」条件と「過剰設計」になる条件

BFFは万能ではなく、むしろシンプルな構成で十分な場合も多い。導入を検討する前に、以下の条件を確認するとよい。

BFFが効くケース
・Webとモバイルで表示要件が大きく異なる（フィールド数・フォーマット・集約範囲）
・フロントエンドのチームとバックエンドのチームが別れており、それぞれのリリースサイクルを独立させたい
・下流のマイクロサービスが5つ以上あり、フロントエンドが都度すべて呼んでいる
・モバイルの通信量削減が業績に直結している（EC、ゲーム等）

BFFが過剰設計になるケース
・フロントエンドが1種類しかない（WebのみのBtoBサービス等）
・チームが3名以下で、BFF追加によるデプロイ管理コストが開発速度を下げる
・バックエンドのAPIがすでにGraphQLで実装されており、クライアントが任意のフィールドを選択できる

GraphQLとBFFの使い分け

BFFとGraphQLはしばしば比較される。GraphQLはクライアント側が必要なフィールドをクエリで指定できるため、Over-fetchingを解消する力がある。しかし、認証・認可の細かいアクセス制御やキャッシュ設計、チーム境界の整理という観点では、BFFのほうがシンプルに見えるケースも多い。

「GraphQLを導入するほどの規模か」「フロントエンド開発者がGraphQLのスキーマ設計を担えるか」を判断軸にするとよいだろう。

BFF内でやってはいけないこと

BFFはあくまで「集約・変換・フィルタリング」を担うレイヤーであり、ビジネスロジックを持つ場所ではない。注文確定・在庫引き当て・決済処理などのロジックをBFFに書き始めると、「BFFが重くなる」だけでなく、バックエンドのマイクロサービスに分散させた責務がBFFに回帰してしまう。BFFが行う処理は「下流のAPIを呼ぶ → 結果を整形して返す」の2段階に収める意識を持つとよい。

よくあるトラブルと対処法

トラブル①：BFFのレイテンシが想定より高い

原因のほとんどは、下流マイクロサービスへの呼び出しが直列になっていること。相互依存のない呼び出しはPromise.all（Node.js）やasyncio.gather（Python）など言語の並列呼び出し機構を使って並列化する。また、BFFから下流APIへの接続でTCPコネクションの確立コストが積み重なっている場合は、HTTP/2やコネクションプールの活用が有効だ。

トラブル②：下流サービスの障害がBFF経由でフロントエンドに伝播する

BFFがすべての下流サービスの応答を待つ設計では、一つが遅延するだけでBFF全体がタイムアウトする。サーキットブレーカーパターンを組み込み、障害が起きた下流サービスへの呼び出しを一定時間停止する設計を入れるとよい。Lambdaであれば外部ライブラリ（opossum等）、Fargateであればサービスメッシュの機能として組み込める。

トラブル③：WebとMobileのBFFでコードが重複する

集約ロジックの一部が両方のBFFで同じになるケースは多い。この共通部分をLambdaレイヤーやnpmパッケージ（内部）として切り出すと、重複を減らせる。ただし、共通化しすぎると「BFFが1つでよかった」状態に戻るため、チームの境界が自然に共通部分の切り出し先を決めることが多い。

トラブル④：BFFの認証・認可をどこで行うか

JWTトークンの検証をBFF側で行うのか、API Gatewayのオーソライザーで行うのかで迷うケースがある。推奨は「API GatewayのLambdaオーソライザーでトークンを検証し、BFFには検証済みのユーザー情報をヘッダーで渡す」パターン。BFF内での認証ロジックの重複を防ぎ、共通の認証基盤を一か所に集約できる。

本記事のまとめ

BFF（Backend for Frontend）パターンのポイントを整理する。

・BFFとは: フロントエンドの種類（Web/モバイル等）ごとに専用のAPI集約レイヤーを設けるパターン
・解決する問題: レスポンスの粒度差・チャタリング・バックエンドのAPIバージョン爆発
・AWS実装: API Gateway + Lambda（小規模・サーバーレス）か ECS/EKS上のコンテナ（中大規模）
・向いている場面: フロントエンドが複数種類あり、チームやリリースサイクルが分かれている場合
・注意点: BFFにビジネスロジックを持ち込まない。並列呼び出し・サーキットブレーカーを設計に含める

マイクロサービスを採用したものの「結局フロントエンドが大変になった」というのはよくある現場の声だ。BFFを適切に設計することで、バックエンドの分割効果をフロントエンドの体験改善にもつなげることができる。