LASSIC Media らしくメディア
BFF(Backend for Frontend)導入を外注する
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- BFF(Backend for Frontend)は、クライアントごとに専用のバックエンドを置き、複数サービスへの直接アクセスによる通信過多や過剰・過少取得を防ぐ設計パターンです
- API Gatewayやマイクロサービス分割とは役割が異なり、フロント別にAPIを集約・整形する「アプリ層」を担う点が特徴です
- 導入にはBFFの肥大化やロジック重複、所有権をどのチームが持つかという論点があり、外注時は委託範囲の切り分けが判断のポイントになります
目次
BFF(Backend for Frontend)とは何か
BFF(Backend for Frontend)とは、Web・モバイルなどクライアントの種類ごとに専用のバックエンドを設け、そのクライアント向けにAPIの集約・整形・認証処理をまとめて担わせる設計パターンです*1。この考え方は、ソフトウェアアーキテクトのSam Newman氏が2015年に提唱したもので、単一の汎用APIに代えて「1つのユーザー体験に特化したサーバー側コンポーネント」を置く点が特徴です*1。
マイクロサービスアーキテクチャでは、1つの画面を表示するために複数のサービスからデータを取得する場面が増えます。BFFはこの集約処理をクライアント直近のレイヤーに寄せ、フロントエンド側の都合に合わせてAPIを設計できるようにする点に意味があります。
API Gateway・マイクロサービス分割との位置づけの違い
BFFは、インフラの入り口を一元化するAPI Gatewayや、機能単位でサービスを分割するマイクロサービス化そのものとは役割が異なります。API Gatewayは認証・スロットリング・ルーティングなど横断的なゲートウェイ機能を担うのに対し*2、BFFはクライアント種別ごとにAPIレスポンスを集約・整形する「アプリケーション層」の役割を担います。両者は排他的な選択肢ではなく、API Gatewayの背後に複数のBFFを配置する構成も採用されます*2。
複数マイクロサービスの直接呼び出しで生じる通信過多
フロントエンドが複数のマイクロサービスへ直接アクセスする構成では、画面を描画するために何度もAPI呼び出しが発生しやすくなります。Microsoft Azure Architecture Centerでは、単一の共有バックエンドサービスが複数のフロントエンドから競合する要求を受け続けると、更新が頻発し開発のボトルネックが生じると指摘されています*2。
デスクトップとモバイルでは、画面サイズ・パフォーマンス・表示上の制約が大きく異なります*1。同一のAPIレスポンスを両方に返す設計では、モバイル向けには情報が過剰になり、デスクトップ向けには不足するという不一致が生まれやすくなります。
フロントチームとバックエンドチームの調整コスト
共通バックエンドを別チームが管理している場合、あるフロントチームからの変更要望を、他のフロントチームへの影響を確認したうえで反映する必要があります。Azure Architecture Centerは、この確認プロセスが合意形成の遅れや要件バランス調整の負荷につながると説明しています*2。画面ごとに必要なデータ構造が異なるほど、共通APIの改修は複数チームの合意を要する作業になります。
クライアント種別ごとに専用BFFを置く考え方
BFFパターンの解決策は、クライアントインターフェースに特化した要件のみを扱う新しいレイヤーを、フロントエンドと既存バックエンドの間に導入することです*2。Webアプリ・モバイルアプリなど複数のインターフェースを持つ場合は、インターフェースの数だけBFFサービスを用意します*2。
各BFFは、担当するクライアントに最適化されたレスポンス形式を返すことに専念します。共有バックエンドより小規模で複雑度が低いため、アプリケーション全体の管理がしやすくなるとされています*2。
所有権をフロントエンドチームに置く設計
Sam Newman氏は、BFFをUI開発チームと同じチームが保守することを推奨しています*1。フロントチームがBFFの所有権を持つことで、クライアント側とサーバー側の両方を同じチームが素早く反復でき、言語選定・リリース頻度・優先順位づけを自分たちで決められるようになります*2。中央集権的なバックエンド開発チームへの依存を減らせる点が、この設計の利点です*2。
API Gateway・GraphQLとの違いと併用パターン
BFFは従来REST APIで実装されることが多かった一方、近年はGraphQLを採用する事例も増えています*2。GraphQLはクライアントが必要なデータを自らのクエリで指定できるため、フロント別に専用エンドポイントを持つBFFレイヤーを設けなくても、同様の集約効果を得られる場合があります*2。実際、Azure Architecture Centerは「組織がフロントエンド特化のリゾルバーを備えたGraphQLを採用している場合、BFFサービスが価値を追加しない可能性がある」と述べています*2。
API Gatewayとの組み合わせ例としては、認証・監視・キャッシュ・ルーティングといった横断的関心事をAPI Gateway側で一元処理し、クライアント別の集約・整形ロジックをBFF側に置く構成が紹介されています*2。この構成では、API Gatewayがゲートキーピング(アクセス制御)・レート制限・ゲートウェイルーティングの各パターンを担い、BFFはクライアント固有のロジックのみに専念する役割分担になります*2。
マイクロサービス分割とBFFは別レイヤーの取り組み
マイクロサービスへの分割は、バックエンド側の機能をどう区切るかという設計判断です。BFFは、分割された複数のマイクロサービスを画面単位でどう束ねてフロントに返すかという、集約側の設計判断にあたります。マイクロサービス分割を進めるほど、画面表示に必要なサービス呼び出し数が増える傾向があるため、BFFの導入価値は分割の進み具合と合わせて検討する対象になります。
BFFの肥大化・ロジック重複という導入の論点
BFFは万能な解決策ではなく、導入時に検討すべき論点があります。第一に、1つのBFFで複数のクライアント種別を処理しようとすると、責務が増え続けて肥大化する傾向があると指摘されています*1。クライアントごとの違いを吸収する目的で作ったはずのBFFが、結局は共通バックエンドと同じ問題を抱えることになります。
第二に、Web用・モバイル用など複数のBFFを並行運用すると、同じような集約ロジックが重複しやすくなります。Azure Architecture Centerは、複数のインターフェースが類似のリクエストを行う場合、1つのBFFサービスに統合できないかを検討すべきだとしています*2。一方でSam Newman氏は、サービス間の重複自体には比較的寛容な立場を取りつつ、同じロジックが3回目に必要になった段階で共通化を検討する目安を示しています*1。コード重複と、クライアントごとに最適化された体験のどちらを優先するかは、トレードオフとして評価する必要があります*2。
横断的関心事をBFFに寄せすぎない
Azure Architecture Centerは、BFFサービスが扱うべきなのは特定のユーザー体験に関わるクライアント固有のロジックに限るべきだとしています*2。監視や認可のような横断的な機能をBFFに実装すると効率が落ちるため、こうした機能はゲートキーピング・レート制限・ゲートウェイルーティングといった別のパターンで切り出して扱うことが推奨されています*2。
また、サービス数が増えるほど運用負荷は増加します。それぞれのサービスが独自のライフサイクル・デプロイ・保守・セキュリティ要件を持つため、追加するBFFの数は関連コストとのバランスで判断する必要があります*2。クライアント間で同一・類似のリクエストしか発生しない場合や、単一のインターフェースしかバックエンドと連携しない場合は、BFFパターンが適さない場面として挙げられています*2。
BFF導入を外注する際の委託範囲と発注準備
BFF導入を内製で進める場合、フロントエンド・バックエンド双方の設計知識に加え、クライアント種別ごとの要件整理、既存マイクロサービスとの接続設計、認証処理の集約方法など複数領域の知識が必要になります。フロントチームが所有権を持つ設計を採る場合は、フロントエンドエンジニアがサーバーサイドの実装・運用にも一定の工数を割く体制を組む必要があります。
設計を誤ると、BFF自体が新たな共有ボトルネックになったり、既存の共通バックエンドとロジックが二重化したまま運用コストだけが増える結果にもなりかねません。導入前にクライアント種別ごとの要件差分を洗い出さないまま実装に着手すると、後から全体構成を見直す手戻りが発生します。
外注を検討する場合は、委託範囲を次のように切り分けて整理しておくことが発注準備の起点になります。
| 委託範囲 | 主な内容 | 発注前に準備する情報 |
|---|---|---|
| 要件整理・設計 | クライアント種別ごとのAPI要件の洗い出し、BFFと既存バックエンドの責務分担の設計 | 対象クライアント一覧、既存マイクロサービスの構成、画面ごとの必要データ |
| 実装 | BFFサービスの新規構築、認証集約処理の実装、既存APIとの接続 | 使用予定言語・フレームワーク、既存の認証基盤の仕様 |
| API Gatewayとの統合 | 横断的関心事(認証・監視・ルーティング)をゲートウェイ側に集約する設計 | 既存のAPI Gateway構成、監視基盤の有無 |
| 運用・保守 | BFF稼働後のモニタリング、クライアント要件変化に応じた改修 | 想定されるクライアント追加・変更の頻度 |
特に「実装だけを外注し、要件整理は自社で完結させる」という切り分けは、クライアントごとの要件差分が曖昧なまま実装が始まるリスクを伴います。要件整理の段階から一貫して伴走できるか、既存のマイクロサービス構成やAPI Gatewayとの接続実績があるかは、委託先選定時に確認したいポイントです。
まとめ：BFF導入を外注する3つの判断軸
本稿では、BFF(Backend for Frontend)パターンの考え方をSam Newman氏の提唱内容とMicrosoft Azure Architecture Centerの整理をもとに解説しました。要点を3つに集約します。
第一に、BFFはクライアント種別ごとに専用バックエンドを置き、API Gatewayやマイクロサービス分割とは異なる「フロント別のAPI集約・整形」を担うアプリ層のパターンです。第二に、導入時にはBFFの肥大化やロジック重複という論点があり、横断的関心事をBFFに寄せすぎないことが重要です。第三に、外注する場合は要件整理から運用まで一貫して対応できるか、既存構成との接続実績があるかを基準に委託範囲を切り分けることが判断の軸になります。
よくある質問
BFFとAPI Gatewayは同時に導入するものですか？
どちらか一方を選ぶものではなく、役割が異なるため併用されることがあります。API Gatewayは認証・監視・ルーティングなど横断的な機能を担い、BFFはクライアント種別ごとのAPI集約・整形を担います*2。Azure Architecture Centerでも、API Managementのようなゲートウェイの背後に複数のBFFサービスを配置する構成例が紹介されています*2。
BFFを導入するとGraphQLは不要になりますか？
一律に不要になるとは言えません。GraphQLはクライアントが必要なデータをクエリで指定できるため、フロント別のBFFレイヤーと同様の集約効果を得られる場合があります*2。フロントエンド特化のリゾルバーを備えたGraphQLをすでに採用している組織では、BFFサービスを追加しても価値が乏しい可能性があるとされています*2。
BFFはどのチームが保守するべきですか？
提唱者のSam Newman氏は、BFFをUI開発チームと同じチームが保守することを推奨しています*1。フロントチームが所有権を持つことで、クライアント側とサーバー側を同じチームが一体で反復でき、言語選定やリリース頻度を自分たちで決められる利点があります*2。
BFFを増やしすぎるとどのような問題が起きますか？
サービスの数が増えるほど、それぞれに独自のライフサイクル・デプロイ・保守・セキュリティ要件が発生し、運用負荷が増加します*2。また複数のBFF間で似た集約ロジックが重複しやすくなるため、類似のリクエストが多い場合は1つのBFFへ統合できないかを検討する必要があります*2。
BFF導入の外注はどこまでの範囲を依頼できますか？
クライアント種別ごとの要件整理・設計から、BFFサービスの実装、既存API Gatewayとの統合、稼働後の運用・保守まで、段階ごとに委託範囲を切り分けて依頼できます。要件整理を自社だけで済ませて実装のみを外注すると要件差分が曖昧なまま進みやすいため、要件整理から一貫して対応できる委託先を選ぶことが判断のポイントです。LASSIC IT事業部では、元請(元請（プライムベンダー）)としてシステム開発・運用の受託実績を持ちます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Sam Newman「Pattern: Backends For Frontends」（2015年公開）
- *2 出典：Microsoft「Backends for Frontends pattern」Azure Architecture Center（2025年3月更新）
