BFF（Backend for Frontend）を挟むべきケース｜SPA・モバイル・外部公開API別

モダンなシステム開発において、フロントエンドとバックエンドの間に「BFF（Backend for Frontend）」という層を設けるアーキテクチャが一般的になりました。しかし、すべてのプロジェクトでBFFが必要なわけではありません。むしろ、不必要な導入はシステムを複雑化させ、開発スピードを低下させる要因にもなり得ます。

本記事では、IT実務者の視点から、SPA・モバイルアプリ・外部公開APIという3つの主要なユースケースにおいて、どのような状況でBFFを採用すべきか、その具体的な判断基準と設計手法を詳述します。

1. BFF（Backend for Frontend）とは何か？その本質的な役割

BFFとは、特定のユーザーインターフェース（UI）やフロントエンドの種類（Web、iOS、Android等）ごとに最適化された専用のバックエンドを指します。Sam Newman氏によって提唱されたこのパターンは、フロントエンド開発者が自分たちの使いやすい形でデータを取得・加工できるようにすることを目的としています。

1.1 汎用APIと特化型インターフェースの乖離を埋める

バックエンドのマイクロサービス群が提供する「汎用的なAPI」は、特定の画面構成に依存しないように設計されます。一方で、フロントエンドの「1つの画面」を表示するには、複数のマイクロサービスから情報を集めなければならないケースが多々あります。BFFは、フロント側の要求に応じてこれらを束ね、必要な項目だけをフィルタリングして返す役割を担います。

1.2 マイクロサービスアーキテクチャにおけるオーケストレーション

バックエンドが細分化されている場合、クライアントから何度もAPIリクエストを投げる「チャッティ（おしゃべりな）API」問題が発生します。BFFでこれらをオーケストレーション（調整・統合）することで、クライアント側の通信回数を1回に抑えることが可能になります。

2. 【ケース別】BFFを導入すべき判断基準

BFFを採用すべきかどうかは、エンドユーザーが利用するデバイスの特性や、背後にあるバックエンドの複雑性に依存します。

2.1 SPA（シングルページアプリケーション）の場合

ReactやVue.jsを用いたSPAにおいて、BFF導入を検討すべき最大の理由は「セキュリティ」と「データ集約」です。

• セキュリティの強化: ブラウザのJavaScriptでアクセストークン（JWT等）を保持するのは、XSS攻撃のリスクを伴います。BFFを介することで、トークンをBFF側のセッションやHttpOnlyなCookieで管理し、クライアントにはセキュアなセッションIDのみを渡す構成が可能になります。
• CORSの回避: 複数のドメインにまたがるAPIを呼び出す際、BFFが同一ドメインのプロキシとして機能することで、CORS設定の煩雑さを解消できます。

なお、データ連携の全体像を俯瞰する際は、単なるAPI連携だけでなく、ビジネスプロセス全体でのデータ配置を考慮することが重要です。
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』にもある通り、フロントエンドの要件に引きずられすぎず、データの出所（System of Record）を明確にする必要があります。

2.2 モバイルアプリ（iOS/Android）の場合

モバイル環境では、Webブラウザ以上に「通信量」と「バッテリー消費」がシビアに評価されます。

• オーバーフェッチの解消: モバイル画面はデスクトップに比べて表示項目が少ないことが多いため、汎用APIが返す巨大なJSONから必要な3項目だけを抽出してレスポンスするBFFが有効です。
• OS固有の要件への対応: iOSのみにプッシュ通知用の追加データが必要な場合や、特定の古いアプリバージョンに対して下位互換性を持たせたレスポンスを返す必要がある場合、バックエンド本体を汚さずにBFF層で吸収できます。

2.3 外部公開API・サードパーティ連携の場合

自社サービスを外部パートナーにAPIとして開放する場合、BFF（またはAPI Gateway）は強力なゲートキーパーとなります。

• プロトコル変換: 内部ではgRPCやメッセージキューを使用しているが、外部向けには標準的なREST/JSONやWebhooksを提供したい場合に変換層として機能します。
• レートリミットとクォータ管理: パートナーごとに呼び出し回数を制限し、背後のマイクロサービスが過負荷でダウンするのを防ぎます。

3. BFFに持たせるべき「正しい責務」と設計のポイント

BFFのアンチパターンは、そこに「ビジネスロジック」を書いてしまうことです。BFFはあくまで「プレゼンテーション層の延長」であるべきです。

3.1 データの集約と整形（Aggregator）

例えば、ECサイトの商品詳細画面を表示するために「商品情報」「在庫情報」「配送スケジュール」「口コミ」の4つのAPIを叩く必要がある場合、BFFでこれらを並行実行し、1つのレスポンスにまとめます。

3.2 ユーザー認証・認可の代行（Auth Proxy）

フロントエンドに代わって認可サーバー（Auth0, Microsoft Entra ID等）と通信し、トークンの更新（リフレッシュトークン）を安全に行います。企業内システムでSaaSを多用している場合、ID基盤との連携は必須です。
SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャに見られるような、セキュアなアイデンティティ管理とBFFを組み合わせることで、堅牢な認証フローを構築できます。

3.3 エラーハンドリングとリトライ戦略

依存している1つのマイクロサービスが一時的にダウンしていても、画面全体をエラーにするのではなく、一部の情報を「情報なし」として返すようなフォールバック処理をBFFで記述します。

4. BFFの実装パターンと技術スタック比較

BFFの実装には、非同期処理に強い技術選定が不可欠です。以下に代表的なスタックの比較を示します。

特に最近では、Next.jsの「API Routes」や「Server Actions」を利用して、BFFを明示的な別サーバーとして構築せずに、Next.jsアプリケーション内に内包するパターンが増えています。これにより、型の整合性を維持しながら高速な開発が可能です。

5. BFF導入時の懸念点と解決策

BFFは魔法の杖ではありません。導入に伴うデメリットも正しく理解する必要があります。

5.1 ネットワークホップによる遅延への対策

クライアント → BFF → バックエンド と通信が1つ増えるため、単純なリクエストでは数ミリ秒から数十ミリ秒の遅延が加算されます。この対策として、BFFとバックエンド間は高速なプロトコルである gRPC を使用したり、同一ネットワーク（VPC内）に配置して内部通信のオーバーヘッドを最小化したりするのが一般的です。

5.2 BFFの「二重開発」を避けるためのスキーマ駆動開発

フロントエンドの要求に合わせてBFFを書き直す際、バックエンドの変更も伴うと開発スピードが落ちます。これを防ぐには、OpenAPI（Swagger）やPrisma、GraphQLなどのスキーマから型定義を自動生成する「スキーマ駆動開発」の導入が必須です。
【完全版・第5回】freee会計の「経営可視化・高度連携」フェーズで解説されているようなAPI活用術と同様、BFF層においても「APIは契約（Contract）」であるという意識を持つことが、保守性を高める鍵となります。

5.3 運用監視（オブザーバビリティ）の重要性

エラーが発生した際、それがBFFのロジックによるものか、背後のマイクロサービスによるものかを即座に切り分ける必要があります。OpenTelemetryなどを用いた分散トレーシングを導入し、リクエストのライフサイクルを可視化しておくべきです。

6. まとめ：自社のプロジェクトにBFFは必要か？

BFFを導入すべきかどうかの最終的なチェックリストは以下の通りです。

• バックエンドのAPIが、フロントエンドの1画面を表示するのに3回以上リクエストを必要とするか？
• モバイル、Web、外部連携など、用途ごとにレスポンス構造を最適化したいか？
• JavaScript側に認証トークンを露出させたくないという、明確なセキュリティ要件があるか？
• チームがバックエンドとフロントエンドで分かれており、疎結合に開発を進めたいか？

これらに対して「Yes」が多いのであれば、BFFの導入はコストに見合う価値を提供します。逆に、シンプルなCRUD操作が中心のアプリケーションや、小規模なチームで開発している場合は、BFFを置かずにバックエンドAPIを直接叩くシンプルな構成の方が、デリバリー速度を維持できるでしょう。システムの成長段階に合わせて、適切なタイミングでアーキテクチャをアップデートしていく柔軟性が、現場の実務担当者には求められます。