BFFアンチパターンとは？API Gatewayとの違いと回避策

BFF（Backend For Frontend）パターンとは、スマホアプリやパソコンの画面（フロントエンド）ごとに、それぞれの画面が必要とするデータだけを渡す専用のサービス（バックエンド）を作る考え方です。

たとえば：

• スマホアプリは画面が小さいので、少ない情報だけを軽く素早く受け取りたい
• パソコンの画面では、もっとたくさんの詳しい情報を一度に表示したい

このように使う場面に合わせて、最適なデータを届ける役割を担うのがBFFです。

適切に活用すればUX向上など多くの利点がありますが、誤用するとアンチパターン（望ましくない設計）に陥る可能性も指摘されています。

本記事ではBFFアンチパターンをテーマに、その概要と背景、API Gatewayとの違い、メリット・デメリット、さらにアンチパターンの具体例や回避策、実装上のポイントについて解説します。

BFFアンチパターンとは何か？その概要と課題

BFFパターンの基礎

BFF（Backends For Frontends）とは、名前が示す通り「フロントエンドのためのバックエンド」です。つまり、各種クライアント（例：Webブラウザ、モバイルアプリなど）のUIごとに専用のバックエンドサービスを設けるアーキテクチャパターンを指します。

もともとはNetflixやSoundCloudの事例で知られ、2015年にマイクロサービスの専門書でサム・ニューマン氏によって紹介されたのが最初とされています。近年では多くのWeb/モバイルサービスで採用され、関連書籍や記事も増えている注目のアーキテクチャです。

BFF: BackendsForFrontends

created by Rinker

• Kindle
• Amazon
• 楽天市場
• Yahooショッピング

従来、単一の汎用バックエンドAPIであらゆるクライアント要求に応えるアプローチでは、モバイル等の特定デバイスには過剰・不適切なデータまで提供してしまい、フロント側の処理負荷やパフォーマンス低下を招く懸念がありました。

BFFパターンではそれを解決するためUIごとに最適化された専用バックエンドを用意します。各BFFサーバはそれぞれのクライアントからのリクエストを受け取り、内部で必要な各種マイクロサービスAPIに問い合わせて結果を集約・加工し、クライアントにとって扱いやすい形式でレスポンスを返します。フロントエンドから見ると、本来ならいくつものサービスにバラバラにアクセスしなければいけないところを、BFFを通せば1回の呼び出しで必要なデータをまとめて受け取れるようになります。そのため、開発の手間が減り、通信の負担も軽くなります。

BFFとAPI Gatewayの違い

BFFと似た役割を担うものにAPI Gatewayパターンがあります。どちらもクライアントとバックエンド群の間に配置される中間層ですが、その設計思想と用途には明確な違いがあります。

API Gatewayはマイクロサービス構成において全クライアントからのリクエストを一手に引き受ける窓口となる統一的なゲートウェイサーバです。各種サービスへのルーティングや認証、簡易なプロトコル変換などを行います。API Gatewayはサービス統合ポイントを一本化できる利点がありますが、全クライアント共通の汎用エンドポイントとなるため、すべてのクライアントに共通のAPIで対応しようとすると、デバイスごとに必要な情報や形式が違うため、ムダが増えたり、処理が複雑になったりしがちです。その結果、アプリの動きが遅くなったり、コードがわかりにくくなることがあります。

一方のBFFはクライアント種類ごとに専用のバックエンドを複数用意します。例えばWebアプリ用BFF、モバイルアプリ用BFFといった具合に、UIごとに別個のエンドポイントとサービスを持つイメージです。各BFFがそれぞれのクライアントに最適なAPIを提供するため、モバイル向けにはデータを絞り込み回数を減らす、一方Web向けには表示に必要な情報をまとめて提供するといったきめ細かな最適化が可能です。

つまりAPI Gatewayが「一本化された玄関」だとすれば、BFFは「クライアント別の玄関を複数構える」形になります。結果として各クライアントは自分専用のバックエンドにアクセスでき、不要な汎用処理を省けます。

以下にクライアントからバックエンドへのAPIコール数の例で、BFFの有無による違いを示します。

上記のように、BFFを導入するとクライアントから見たリクエスト回数を大幅に減らし（例では5回→1回）、通信の往復や処理負荷を削減できます。一方、API Gateway単体では依然としてクライアントごとに不要なデータを取得するケースが残るため、クライアント側での追加処理や通信回数の増加につながることがあります。

BFFパターンのメリット・デメリット

BFFパターンを導入することで得られるメリットと注意すべきデメリットを整理します。

BFFパターンのメリット

UI最適化されたレスポンス

各クライアントにとって必要十分な形でデータを提供できるため、フロントエンド側でのデータ加工や結合処理を簡略化できます。例えばモバイル向けには絞り込んだ小さなJSON、Web向けにはリッチなデータ集合をそれぞれ返せます。

フロントエンドとバックエンドの責務分離

フロントエンド開発者が必要とするUI固有の処理をBFF側で肩代わりすることで、バックエンドのドメインサービスはビジネスロジックに専念し、フロントエンドはUI構築に集中できます。結果としてチーム間の役割分担が明確になり、開発の効率や柔軟性が向上します。

通信回数や待ち時間の削減

前述の通り、BFFが複数のサービス呼び出しをまとめて代理実行するため、クライアントからの通信往復回数が減り、全体のレスポンス時間短縮につながります。ネットワーク帯域が限られるモバイル環境などでは特に効果的です。

バックエンドの変更からフロントエンドを保護

BFFが間に入ることで、バックエンドAPIの変更や統廃合があってもBFF内で吸収できる場合があります。フロントエンドとバックエンドを疎結合に保ち、バックエンドの仕様変更によるフロント側の影響範囲を抑制できます。

開発の独立性向上

バックエンドチームの対応が難しい要求に対して、フロントエンドチームがBFFで補完実装することで迅速に機能追加できる場面もあります。これによりバックエンドの都合による開発ブロックが減り、フロント主導でユーザー体験を改善しやすくなる利点も指摘されています。

BFFパターンのデメリット・留意点

開発・運用コストの増加

BFFという新たな層のサービスを複数管理する必要が生じるため、その開発工数や運用（デプロイ・監視など）コストが増えます。小規模なチームや単純なシステムではBFFを増やすことでかえって負担が大きくなる可能性があります。

一部処理の重複と複雑化

BFF間で類似の処理を行うケースではコードの重複が発生することがあります。しかし各BFFは独立性が重要なため、下手に共通サービス化すると再び一元化した巨大サービスとなり本末転倒です。結果としてある程度の処理重複を許容するか、適切に共通ライブラリ化するかの判断が求められ、設計が難しくなる点があります。

通信遅延の増加の可能性

クライアント->BFF->各サービスという呼び出しの多段化により、場合によってはトータルの通信量・処理時間が増えるリスクもあります。特にBFFが遠隔地にデプロイされている場合や、内部で逐次的に多数のAPIコールを行う実装だとレイテンシが悪化する可能性があります。実装時にはBFF内部での非同期化や並列処理、キャッシュ戦略などで遅延対策を講じる必要があります。

障害時の単一障害点 (SPOF)

特定クライアントのトラフィックがBFFに集中するため、BFFサーバ自体がダウンするとそのクライアント向けサービス全体が影響を受ける重大な障害となります。バックエンドが健全でもBFF層でサービス不能になる恐れがあるため、BFFには高可用性（冗長構成やスケーラビリティ）と監視体制が不可欠です。

バックエンドとの連携・依存

BFFはバックエンドAPI群に依存して動作するため、デプロイ順序の調整やインターフェース変更時の同期が必要です。例えばバックエンドに新フィールドを追加した場合、BFF側でも対応を入れてからリリースするといった連携が発生し、チーム間の調整コストが増えます。

不要な導入による複雑さ

そもそもフロントとバックが1対1関係で要求も単純な場合や、チーム間のコミュニケーションが密接でAPI仕様を柔軟に調整できる環境では、BFFを挟まず直接API連携する方がシンプルなケースもあります。無闇にBFFを導入するとシステムが過剰に階層化されてしまうため、本当に必要な場面か慎重に見極めることも大切です。

以上のようにBFFパターンは強力な一方、使いどころを誤ると追加の複雑さを招きます。次章では「BFFアンチパターン」として、実際に陥りやすい設計ミスの例とその回避策を見ていきます。

BFFアンチパターンの回避策と実装上のポイント

よくあるBFFアンチパターンの例

BFF導入時に陥りがちなアンチパターンの例を紹介します。アンチパターンとは、本来の意図から外れてしまった悪い実践例のことです。BFFについて報告されている代表的なアンチパターンには以下のようなものがあります。

バックエンド・フロントエンド間のコミュニケーション不足

開発組織の問題で、フロントエンドとバックエンドの担当者がお互いの要件を調整・合意できていない場合、本来バックエンドで改善すべき問題をすべてフロント側（BFF）で抱え込んでしまう事態が起こりえます。

例えば「バックエンドのAPI設計が不十分だが変更が難しいので、フロントがBFFで無理矢理対応する」といったケースです。このようなコミュニケーション不全に起因するBFF利用は、本質的解決になっておらず技術的負債を増やすアンチパターンといえます。

BFFの肥大化（UI以外のロジック過多）

BFFは本来、UIの表示やユーザー体験向上のためのデータ変換・集約に特化すべきです。

しかしアンチパターンでは、業務上のビジネスロジックや複雑なデータ変換処理など本来バックエンドが担うべき責務までBFFに実装してしまいます。

その結果、BFFがミニモノリスのように肥大化・複雑化し、保守困難になるだけでなく、バックエンドのドメイン知識が分散することでバグの温床になります。BFFに過剰な責務を持たせることは避けるべき典型的アンチパターンです。

ビッグバン・ジョイント（一括結合による複雑化）

複数のバックエンドサービスとフロントエンドの結合をBFFで一気に行おうとしてしまうケースです。

例えば、新規プロジェクトで最初からBFFを挟んで多数のサービスを連携させようとすると、設計段階で不確実な要件まで盛り込んでしまい巨大で複雑なBFFが誕生しがちです。または、一つのBFFがすべてのクライアント種別を扱うよう設計してしまい、結果的にAPI Gateway的な一極集中になってしまう場合もあります。それではBFFを分けた意味がなく、開発初期から大きな結合を生んでしまうためアンチパターンとされます。

以上のようなアンチパターンは、しばしば組織上の課題や設計上の怠慢に起因します。「システムアーキテクチャと組織設計は本質的に同じ」とも言われるように、BFF導入時には技術だけでなくチーム体制や開発プロセスにも目を向ける必要があります。次に、これらの失敗を防ぐためのベストプラクティスを解説します。

BFFアンチパターンを避けるためのベストプラクティス

上記のようなアンチパターンに陥らないために、BFF設計・実装時には以下のようなベストプラクティスを心がけます。

チーム間でAPI契約を明確化し緊密に連携する

フロントエンドとバックエンドの担当者が定期的にコミュニケーションを取り、APIの設計（契約）を共同で詰めることが重要です。

フロントの要求事項を早めにバックエンドに共有し、可能なものはバックエンドAPI側でサポートすることで、BFFに不必要な責務が乗らないようにします。OpenAPI (Swagger) ドキュメントを活用してインターフェースを見える化するなど、「仕様のすり合わせ不足」に起因するBFF乱用を防ぎます。

BFFの責務範囲を明確に定義する

BFFに実装するのはあくまでプレゼンテーションロジック（表示形式への変換や複数サービス結果の組み合わせ）やUI向けの最終データ調整に留めます。ドメインルールやデータ検証などは可能な限り下流のマイクロサービスで処理し、BFFは軽量な受け渡し役となるように設計します。

プロジェクト開始時にフロントエンド・BFF・バックエンド各層の「担当すべき責務」を文章化し共有しておくと、本来の役割から外れる実装を抑止できます。

小さく始めて必要に応じて拡張する

初期リリースから無理にBFFを入れ込まず、まずは単一APIやシンプル構成で開始し、サービス拡大に伴い明確な課題が見えてからBFF導入を検討するほうが健全です。

BFFを導入するとしても、クライアントごとに本当に必要な部分だけを切り出し、小規模なBFFから始めて徐々に機能を追加するアプローチが望ましいです。一度に多機能なBFFを作ろうとするとビッグバン統合の失敗につながるため注意が必要です。

BFFはクライアント種別ごとに分離する

複数の異なるUI（例：WebとMobile）を一つのBFFで共通化しようとしないことも原則です。

クライアントごとに要求や最適解が異なる以上、BFFを統合すると内部で条件分岐が増え結局複雑になります。UIごとに別々のBFFサービスを運用し、それぞれを独立デプロイできるようにします。その際、多少のコード重複（共通処理が各BFFに存在する）は許容します。

複数BFF間の共通機能を安易に一つのサービスにまとめてしまうと、また汎用サービスが肥大化してアンチパターンとなるからです。共通部分はライブラリ共有などで解決しつつ、BFF自体は責務ごとに分離しましょう。

エラーハンドリングと部分応答の実装

BFFが複数の下流サービスに依存している以上、その一部が障害を起こした場合の挙動を設計しておく必要があります。

例えば部分的なデータでも返せる工夫を取り入れます。あるサービスからの情報取得に失敗した場合、取得できた他のサービスのデータだけでもレスポンスし、欠落部分はエラーフラグを付けて通知する、といった戦略です。これによりバックエンドの一部障害があってもユーザーに可能な限り機能を提供できます。

また、BFF自身にもタイムアウトやリトライ、サーキットブレーカーなどのフォールトトレランス機構を組み込み、問題発生時にシステム全体への波及を防ぎます。

モニタリングとスケーリングの計画

BFFが新たな中間サーバとなることで監視ポイントも増えます。

各BFFのメトリクス収集と可視化（例えばリクエスト数、レスポンスタイム、エラー率など）を行い、問題の予兆を捉えやすくします。負荷が集中しやすいBFFにはオートスケーリングやロードバランシングを設定し、スパイクトラフィックでも高可用性を維持できるようインフラ設計を行いましょう。

インフラエンジニアとも連携し、BFF層の信頼性をバックエンド同様に確保することが重要です。

AWSでのBFFアーキテクチャ導入例

クラウド環境ではBFFパターンを支えるサービスが豊富に提供されています。特にAWSを例に、BFFをどのように実現できるかを簡単に紹介します。

Amazon API Gateway + AWS Lambda

AWSにおける代表的なBFF構成は、API Gateway を各クライアント向けに設定し、そのバックエンドに Lambda関数 を用意する形です。API Gatewayがエンドポイントの公開と認証を担い、Lambdaが必要な各マイクロサービス（AWSの場合は他のREST APIやDynamoDB等）にアクセスしてデータを加工し返します。

Lambdaはサーバーレスで自動スケーリングするため、モバイルアプリ向けLambda、Web向けLambdaといったBFFが急なアクセス増にも柔軟に対応できます。例えばAWS公式ブログでは、モバイル向けBFFにLambda＋DynamoDB＋Pub/Sub（Amazon SNS/SQS）のイベント駆動構成を組み合わせ、リアルタイムなUI更新を実現するアーキテクチャを紹介しています。

このようにAWSサービスを組み合わせれば、最小のインフラ管理で高度なBFFを構築可能です。

AWS AppSync (GraphQL)

AWSのマネージドGraphQLサービスである AppSync もBFF用途に適しています。

AppSyncではGraphQLのリゾルバーとしてAWS Lambdaや他のAWSデータソースを設定でき、クライアントごとに柔軟なGraphQLスキーマを公開できます。モバイルアプリ向けに特化したGraphQL APIをAppSyncで構築し、各種AWSサービスからデータを集約することでBFF相当の役割を果たせます。

リアルタイム更新（サブスクリプション）機能も備えているため、モバイル通知やライブフィードなどUX向上にも繋がります。

コンテナサービスによるBFF

既存のExpressサーバやNestJSアプリをそのままBFFとして動かす場合、 AWS Fargate (ECS) や Amazon EKS 上にデプロイして運用する手段もあります。

例えばDockerコンテナ化したBFFアプリをサービスごとにスケールさせることで、オンプレと同様の感覚でBFFをクラウド運用できます。AWSにはサービス間通信の認可やサービスディスカバリも整っているため、クラウド上でマイクロサービスの1つとしてBFFを位置付けられます。

BFFアーキテクチャはAWSに限らず、GCPやAzureでも同様の構成が可能です。要はクラウド各社のAPIゲートウェイ＋サーバーレス/マイクロサービス基盤を活用すれば、BFFパターンをスケーラブルかつ効率的に実現できます。

加えてCI/CDパイプラインや監視サービス（例えばCloudWatch）と組み合わせ、BFFのデプロイ自動化やログ集約を行うことで、安全にBFFを運用していくことができます。

BFFアンチパターンの総括

BFF: BackendsForFrontends

created by Rinker

• Kindle
• Amazon
• 楽天市場
• Yahooショッピング

ひまくろ

エンジニア

現役エンジニア。Ruby・PHP・Goを使ったサーバーサイド開発経験が中心でデータベース設計やチューニングが得意分野。 これまでにオンラインでのプログラミング指導や、スクールのメンター、エンジニア採用の面接官も経験。 このブログでは、現場で培ったリアルな知識をもとに、学習のコツや面接対策、働き方のヒントなどを発信しています。エンジニアを目指す方、今の働き方に悩む方へ、少しでも役立つ情報を届けたいと思っています。