Akira

Posted on Jul 2 • Originally published at apidog.com

BFF 対 API Gateway: 違いと使い分けを徹底解説

「BFFとAPIゲートウェイ」は、マイクロサービスアーキテクチャで混同されやすい組み合わせです。どちらもクライアントの前段にあり、リクエストを受け取り、バックエンドへ渡します。しかし、両者は競合する選択肢ではありません。APIゲートウェイは共通ポリシーを一元化し、BFF（Backend for Frontend）は特定のフロントエンド向けにレスポンスを最適化します。

今すぐApidogを試す

この記事では、BFFとAPIゲートウェイの境界を実装目線で整理します。どちらをどこに置くべきか、両方を使う場合のリクエストフロー、避けるべき設計ミス、そしてAPIコントラクトをどう管理するかを確認します。

APIゲートウェイとは何か？

APIゲートウェイは、クライアントとバックエンドサービスの間にある集中型の入り口です。すべてのリクエストを受け取り、共通の処理を適用してから、適切なサービスへルーティングします。

APIゲートウェイに置くべき責務は、すべてのクライアントに共通するものです。

ルーティング: パスやホストに基づいて、適切なアップストリームサービスへ転送する
認証と認可: トークンを検証し、未認可のリクエストを拒否する
レート制限とスロットリング: バックエンドを過負荷や不正利用から保護する
可観測性: ログ、メトリクス、トレースを一元的に収集する
TLS終端、キャッシング、リクエスト変換: インフラ寄りの処理を共通化する

実装上の判断基準はシンプルです。

すべてのクライアントに同じルールを適用したいなら、APIゲートウェイに置く。

たとえば、モバイルアプリ、Web SPA、パートナーAPIのすべてで同じ認証方式を使うなら、各サービスや各BFFに認証処理を実装するのではなく、ゲートウェイで強制します。

APIゲートウェイとより広いプラットフォーム機能の違いについては、API管理 vs APIゲートウェイも参考になります。

Backend for Frontend（BFF）とは何か？

Backend for Frontend（BFF）は、特定のフロントエンド体験に合わせて作るバックエンドです。

1つの汎用APIですべてのクライアントを支えるのではなく、WebアプリにはWeb BFF、モバイルアプリにはモバイルBFFを用意します。Sam Newmanの考え方では、基本は「1つのユーザーエクスペリエンスに1つのBFF」です。

このパターンは、複数のクライアントに対応し続ける単一の共有バックエンドが、やがてモノリスのようなボトルネックになる問題から生まれました。

BFFの特徴は、所有権とレスポンス形状です。

フロントエンドチームが所有する
特定のUIや画面要件に密接に結合する
フロントエンドの変更に合わせて素早く進化する
複数のバックエンドサービスを呼び出し、クライアント向けに整形する

BFFが担当する典型的な処理は次のとおりです。

集約: モバイル画面に必要なデータを、商品サービス、在庫サービス、価格サービスなど複数サービスから取得して1つのレスポンスにまとめる
トリミング: 40個のフィールドを返すバックエンドレスポンスから、モバイルに必要な3個だけを返す
クライアント固有の整形: Webはリッチな表示用に詳細データを返し、モバイルは軽量な一覧用データだけを返す

BFFは、特定のフロントエンドに特化したAPIアグリゲーターと考えると理解しやすいです。

BFFとAPIゲートウェイの重複する点

BFFとAPIゲートウェイは、見た目の構成が似ています。

どちらもクライアントリクエストを受け取る
どちらもバックエンドへルーティングできる
どちらも複数サービスの結果をまとめられる
どちらもクライアントとサービスの間に置かれる

ただし、目的と所有者が異なります。

観点	APIゲートウェイ	BFF
目的	共通ポリシーの一元化	特定フロントエンドの体験最適化
所有者	プラットフォーム / インフラチーム	フロントエンドチーム
対象	すべてのクライアント	1つのフロントエンド体験
ロジック	認証、認可、レート制限、ルーティング、監視	集約、整形、トリミング、画面向けレスポンス

実装時の判断ルールは次のとおりです。

すべてのクライアントで同じならゲートウェイ。フロントエンドごとに違うならBFF。

たとえば、認証やスロットリングをBFFに実装すると、BFFごとに同じロジックを複製することになります。その結果、モバイルBFFとWeb BFFでポリシーがずれ、セキュリティや運用が不安定になります。

BFFとAPIゲートウェイの連携

実際のマイクロサービス構成では、APIゲートウェイとBFFのどちらか一方だけを選ぶのではなく、両方をレイヤーとして使うことが一般的です。

典型的な構成は次のようになります。

Client
  ↓
API Gateway
  ↓
Mobile BFF / Web BFF
  ↓
Microservices

リクエストフローは次のようになります。

モバイルクライアントが認証トークン付きでリクエストを送る
APIゲートウェイがトークンを検証し、レート制限を適用し、ログとメトリクスを記録する
ゲートウェイがリクエストをモバイルBFFへルーティングする
モバイルBFFが商品サービス、在庫サービス、価格サービスを呼び出す
BFFが結果を集約し、モバイル画面に必要な形へ整形する
レスポンスがゲートウェイ経由でクライアントへ返る

この分離により、チームごとの変更範囲を明確にできます。

プラットフォームチームは、BFFを変更せずにレート制限や認証ポリシーを更新できる
フロントエンドチームは、ゲートウェイ設定を触らずにBFFのレスポンス形状を変更できる
各マイクロサービスは、特定UI向けの整形ロジックを持たずに済む

APIゲートウェイはロードバランサーでも、サービスメッシュでもありません。役割は異なります。詳しくは、APIゲートウェイ vs ロードバランサー、サービスメッシュ vs APIゲートウェイを参照してください。

このように、各レイヤーに明確な責務を持たせる考え方は、API主導型接続の原則とも一致します。

決定表: BFF vs APIゲートウェイ

質問	APIゲートウェイ	BFF
誰が所有するか？	プラットフォーム / インフラストラクチャチーム	それを利用するフロントエンドチーム
誰にサービスを提供するか？	すべてのクライアントに一律に提供する	1つの特定のフロントエンドに提供する
主な役割	認証、認可、レート制限、ルーティング、可観測性	クライアント固有の集約とデータ整形
いくつ実行するか？	通常はエッジごとに1つ	異なるユーザーエクスペリエンスごとに1つ
結合度	疎結合、クライアント非依存	密結合、クライアント固有
変更頻度	比較的安定、プラットフォーム主導	高頻度、フロントエンドのロードマップに追従
含めるもの	すべてのクライアントで同一の処理	1つのクライアントに固有の処理

この表は、責務をどちらに置くかを判断するために使えます。

全員に共通する処理 → APIゲートウェイ
フロントエンドごとに違う処理 → BFF
両方が必要な処理に見える場合 → レイヤーを分けて両方使う

どちらを使用すべきか

APIゲートウェイを使うべきケース

次の条件に当てはまる場合は、APIゲートウェイを導入します。

複数のサービスを外部またはクライアントに公開している
認証や認可を一箇所で強制したい
レート制限を統一したい
リクエストログやトレースを一元化したい
クライアントに直接マイクロサービスを見せたくない

ほとんどのマイクロサービスシステムでは、BFFより先にAPIゲートウェイが必要になります。

BFFを使うべきケース

BFFは、クライアントごとの要件差が大きいときに有効です。

Webとモバイルで必要なデータ量が大きく異なる
モバイルでは通信回数を減らす必要がある
共有APIが複数フロントエンドの要求で肥大化している
フロントエンドチームがUI変更に合わせてAPI形状も素早く変更したい
1つの画面を表示するために複数サービスの呼び出しが必要になる

BFFをスキップすべきケース

次のような場合、BFFは不要なオーバーヘッドになる可能性があります。

クライアントが1つしかない
すべてのクライアントがほぼ同じリクエストを行う
共有APIで十分に対応できている
BFFを増やすことでネットワークホップや運用負荷の方が大きくなる
GraphQLなどで、クライアントが必要なフィールドを適切に選択できている

BFFは「将来必要になるかもしれない」だけで作るものではありません。実際にクライアントごとの違いがボトルネックになったときに導入します。

両方を使うべきケース

大規模なマイクロサービスでは、次の構成が一般的です。

エッジにAPIゲートウェイを置く
その背後にWeb BFF、Mobile BFFなどを置く
BFFの背後に各マイクロサービスを置く

この構成により、共通ポリシーとクライアント固有ロジックを分離できます。

よくある間違い

1. 認証とレート制限をBFFに置く

認証、認可、レート制限は横断的関心事です。BFFではなくAPIゲートウェイに置くべきです。

BFFごとにこれらを実装すると、次の問題が起きます。

BFF間でポリシーがずれる
同じロジックを複数箇所に実装する
セキュリティ修正の反映漏れが起きる
運用チームが全BFFを把握する必要が出る

2. BFFを第二のモノリスにする

BFFは小さく、1つの体験に集中させます。

共有ビジネスロジック、複雑なドメイン処理、複数クライアント向けの汎用機能をBFFに詰め込むと、BFFは新しいモノリスになります。

BFFに置くべきなのは、あくまで次のような処理です。

画面向けのデータ集約
レスポンスの整形
不要フィールドの削除
クライアント固有の表示都合への変換

3. ゲートウェイをBFFとして使う

ゲートウェイ設定にクライアント固有の変換ルールを大量に入れると、ゲートウェイがBFFの代用品になります。

小規模では動きますが、次の問題が出ます。

フロントエンドチームが変更のたびにプラットフォームチームへ依頼する
ゲートウェイ設定が複雑になる
中央管理すべきポリシーとUI固有ロジックが混ざる
デプロイ責任が不明確になる

クライアント固有のロジックはBFFに置きます。

4. クライアントが1つしかないのにBFFを作る

単一のWebアプリしかなく、他のクライアントが存在しないなら、まずは共有APIで十分です。

BFFは次のコストを追加します。

追加のネットワークホップ
追加のデプロイ単位
追加の監視対象
BFFとバックエンド間のコントラクト管理

2つ目以降のクライアントが登場し、要件差が明確になってから導入しても遅くありません。

5. APIコントラクトを忘れる

BFFもAPIゲートウェイルートも、外部から見るとAPIです。

そのため、それぞれに以下が必要です。

エンドポイント定義
リクエスト / レスポンススキーマ
認証方式
ステータスコード
エラー形式
テスト
ドキュメント

これを怠ると、BFFは「フロントエンドチームしか理解していない未文書のブラックボックス」になります。APIコントラクトの重要性については、APIコントラクトとは何かを参照してください。

Apidogが適合する場所

リクエストがAPIゲートウェイ、BFF、またはその両方を通過する場合でも、各レイヤーはAPIコントラクトを公開します。

Apidogは、それらのコントラクトを設計、テスト、モック、ドキュメント化するためのワークスペースです。ApidogはAPIゲートウェイやBFFを構築、ホスト、置き換えるものではありません。各レイヤーが公開するAPIサーフェスを管理するために使います。

具体的には、次のように使えます。

設計: BFFの集約レスポンスやゲートウェイ経由で公開するエンドポイントをスキーマファーストで定義し、OpenAPIとして共有する
モック: ダウンストリームサービスが未完成でも、BFFのモックを用意してフロントエンド開発を進める
テスト: ゲートウェイ経由のエンドポイントを実際のクライアントと同じように呼び出し、認証、ステータスコード、レスポンス形状を検証する
ドキュメント: BFFやゲートウェイルートのインタラクティブなAPIドキュメントを公開し、チーム間の認識を揃える

これは、フロントエンドとバックエンドを並行して進めるAPIファーストの進め方にも合っています。

設計パターンとしてBFFを選ぶか、APIゲートウェイを使うか、あるいは両方を使うかはアーキテクチャ上の判断です。しかし、各レイヤーがAPIコントラクトを持つ点は変わりません。

Apidogを無料で試して、バックエンドコードを書く前にBFFとゲートウェイのコントラクトを設計・モックしてください。

よくある質問

BFFはAPIゲートウェイの一種ですか？

いいえ。BFFとAPIゲートウェイはどちらもルーティングや集約を行うことがありますが、目的と所有者が異なります。BFFはフロントエンドチームが所有し、1つのクライアント体験に最適化されます。APIゲートウェイは中央集権的に所有され、すべてのクライアントに共通ポリシーを適用します。

APIゲートウェイなしでBFFを使えますか？

使えます。ただし、大規模なシステムでは通常おすすめしません。ゲートウェイがないと、各BFFが認証、認可、レート制限などを再実装することになり、ポリシーの一貫性が失われます。

いくつのBFFを持つべきですか？

Sam Newmanの「1つのエクスペリエンスに1つのBFF」という考え方に従います。大きく異なるフロントエンドごとにBFFを分けます。一方で、同じチームが保守するiOSアプリとAndroidアプリのように要件が近い場合は、1つのBFFを共有できます。

BFFはAPIゲートウェイを置き換えますか？

いいえ。BFFとAPIゲートウェイは補完関係です。ゲートウェイはエッジで共通ポリシーを強制し、BFFはその背後で特定クライアント向けにデータを整形します。

BFFを構築すべきではないのはいつですか？

すべてのクライアントが似たリクエストを行う場合、クライアントが1つしかない場合、またはGraphQLなどで必要なデータ選択が十分にできる場合は、BFFをスキップできます。

認証とレート制限はBFFとゲートウェイのどちらに置くべきですか？

APIゲートウェイです。認証、認可、レート制限はすべてのクライアントで統一されるべき横断的関心事です。BFFに置くと、ロジックの重複とポリシーの乖離を招きます。

DEV Community