API設計

BFF（Backend For Frontend）びーえふえふ

API設計マイクロサービスフロントエンドAPIゲートウェイGraphQLアーキテクチャパターン

BFFについて教えて

簡単に言うとこんな感じ！

BFFは「フロントエンド専用の取次役サーバー」だよ！スマホアプリとWebブラウザって、欲しいデータの量や形が違うよね。BFFはそれぞれの画面に合わせてデータを整えてくれる専属シェフみたいな存在なんだ！

BFF（Backend For Frontend）とは

BFF（Backend For Frontend）とは、フロントエンド（画面・UI）の種類ごとに専用のバックエンド層を用意するアーキテクチャパターンです。「フロントエンドのためのバックエンド」という名前のとおり、特定のクライアント（Webブラウザ、スマホアプリ、スマートTVなど）に最適化されたAPIを提供する中間サーバーを指します。

従来の設計では、1つの汎用APIをすべてのクライアントで共有していました。しかし、スマホ画面とPC画面では必要なデータ量も形式も異なるため、「スマホには不要な情報まで大量に返ってくる」「画面に合わせた加工をフロントエンド側でやらなければならない」という問題が起きがちでした。BFFはこの問題を解消するために生まれた考え方です。

マイクロサービス（機能を小さなサービスに分割して構成するシステム設計）が普及した2010年代以降、複数のバックエンドサービスをまとめてフロントエンドに渡す「集約層」としてBFFの重要性が急速に高まりました。

BFFの構造と役割

BFFが担う主な処理

処理	内容	具体例
データ集約	複数のマイクロサービスからデータをまとめる	「商品情報API」「在庫API」「レビューAPI」を1回のリクエストで返す
データ変換	クライアントに合った形式に整形する	PCには全フィールド、スマホには最小限のフィールドだけ返す
認証・認可の中継	トークン検証などをまとめて処理する	フロントエンドが個別にサービス認証しなくてよくなる
エラーハンドリング	複数サービスのエラーを吸収・統一する	どのサービスが落ちても同じ形式でエラーを返す
キャッシュ	頻繁に使うデータを一時保存して高速化する	商品カテゴリ一覧を毎回取得せずキャッシュで返す

クライアント別BFFの分け方

ユーザー操作
    │
    ├─ Webブラウザ ──→ [Web BFF]     ─┐
    ├─ iOSアプリ  ──→ [モバイル BFF] ─┼─→ [バックエンドサービス群]
    └─ Androidアプリ→ [モバイル BFF] ─┘      商品API / 在庫API
                                              ユーザーAPI / 決済API

モバイル向けとWeb向けで別々のBFFを用意するケースが多いですが、規模によってはiOSとAndroidで分けることもあります。

覚え方

BFF ＝「Best Friend Forever（親友）」ではなく「Backend For Frontend（フロント専用バックエンド）」。フロントエンドの”専属アシスタント”と覚えましょう。飲食店で言えば、ホールスタッフ（フロントエンド）の代わりにキッチン（バックエンドサービス）へ注文を取りに行って、お皿に盛り付けて持ってくる「中間厨房」です。

歴史と背景

2000年代後半〜: Amazonや Netflix がマイクロサービスアーキテクチャを採用し始める。複数の小さなサービスに分割したことで「誰がデータをまとめるか」問題が浮上
2015年: SoundCloudのエンジニア Sam Newman が「Pattern: Backends For Frontends」として概念を明文化・命名。ブログ記事が業界に広まる
2016〜: スマートフォンの普及でモバイルアプリとWebで異なるUXが求められるようになり、BFFパターンの採用が加速
2018〜: GraphQL（クライアントが必要なデータを自分で指定できるAPI技術）の普及で「GraphQL自体がBFFの役割を果たす」という考え方も登場
2020〜: Next.js などのフルスタックフレームワークが普及し、フロントエンドのコードの中にBFF相当の処理を書くスタイル（API Routes / Server Components）も一般的に

BFF・APIゲートウェイ・モノリスの比較

よく混同されがちな「APIゲートウェイ」との違いを整理しましょう。

BFFとAPIゲートウェイは併用できる

実務ではBFFとAPIゲートウェイを組み合わせて使うことが多いです。

クライアント
    │
    ▼
[APIゲートウェイ]  ← 認証・SSL終端・流量制限（全クライアント共通）
    │
    ├→ [Web BFF]     ← Web画面向けのデータ整形
    └→ [モバイル BFF] ← アプリ向けのデータ整形
         │
         ▼
    [マイクロサービス群]

「門番（APIゲートウェイ）」が入口で共通処理をして、「専属シェフ（BFF）」がクライアント別に料理を仕上げるイメージです。

導入時に検討すべきポイント

BFFは便利なパターンですが、チーム構成・システム規模に合わないと逆効果になることもあります。

観点	BFF導入が向いているケース	BFF不要なケース
クライアント種別	Web・モバイル・TV など複数ある	Webのみなど1種類
バックエンド構成	マイクロサービスで分散している	1つのAPIサーバーで完結
チーム体制	フロントエンドチームが自律的に動く	少人数でフルスタック開発
データ要件	クライアントごとに必要なデータが大きく異なる	どのクライアントも同じデータで十分
開発速度	フロントとバックで独立してデプロイしたい	合わせて一括リリースで問題ない

実務Tips: システム発注時にベンダーから「BFF層を設けます」と提案された場合は、「どのクライアント向けのBFFですか？」「BFFの開発・運用は誰が担当しますか？」を確認しましょう。BFFはサーバーの追加を意味するため、インフラコストと運用コストが増える点も念頭に置いてください。