【ばっくえんどふぉーふろんとえんど】

Backend for Frontend（BFF）とは？

最終更新: 2026年10月4日

💡 フロントエンドの用途に合わせた、専用の調整役

特定のフロントエンドの利用体験に合わせて、専用のバックエンド層を設ける設計パターン。必要なデータの集約や加工を行い、Webやモバイルなどの用途に合うAPIを提供する。

📌 このページのポイント

Web用とモバイル用のBFFが、共通サービスの情報を用途に合わせて返す構成例。OSごとに分けることや、APIゲートウェイを前に置くことは必須ではない。

ひよこ

なんでフロントエンドごとにバックエンドを分けるの？1つじゃダメなの？

ペンギン先生

必要な機能やデータが似ていれば、共通のAPIでも対応できるよ。BFFは、たとえばWebには詳しい一覧、スマホには必要な項目を絞った一覧を返すように、異なる利用体験へ合わせるための層なんだ。

ひよこ

BFFではどんな処理をするの？

ペンギン先生

複数のサービスから情報を集め、画面に必要な形へ整えるよ。商品名・価格・在庫を集約する、といった例だね。フロントエンド側の呼び出しをまとめられるけれど、全体の通信量や応答時間が必ず減るとは限らない。追加の通信や障害時の扱いも設計するんだ。

ひよこ

ペンギン先生

APIゲートウェイは共通の入口として、経路の振り分けや認証、呼び出し数の制限などを担うことが多い。BFFの中心は特定の利用体験に合わせた加工・集約だよ。APIゲートウェイを前に置く構成もあるけれど、その配置がBFFの必須条件ではないんだ。

ひよこ

iOS用とAndroid用も必ず別々にするの？

ペンギン先生

必須ではないよ。似た利用体験ならモバイル用BFFを共有する例もある。必要な機能や担当チームに合わせて境界を決めよう。共通の業務処理は下位のサービスへ置く方法もあるけれど、共有のライブラリなどを使うときは、変更がほかのBFFへどう影響するかも考えるんだ。

ひよこ

どんなプロジェクトで採用すべき？

ペンギン先生

利用体験ごとの違いが大きく、専用の加工や集約が必要なら候補になるよ。Webだけでも集約が複雑なら役立つ場合がある。一方、サービスが増える運用負担や遅延も比較しよう。フロントエンドのチームがBFFも管理できるか、既存APIなどで十分対応できるかを含めて判断するんだ。

まとめ：ざっくりこれだけ覚えればOK！

「BFF」って出てきたら「フロントエンドの用途に合わせてデータを整える専用バックエンド」と思えばだいたいOK！

📖 おまけ：英語の意味

「Backend for Frontend」＝フロントエンドのためのバックエンド

💬 Sam Newmanの2015年の記事は、この呼び名をPhil Calçadoによるものとして紹介しているよ

参考資料