「スマホのアプリとパソコンのWebサービス、同じ会社のものなのに動きが違う…」って思ったことない？実はその裏側には、それぞれに合わせた専用の「つなぎ役」が働いてるんだよ。それが今回のテーマ「BFF」。難しそうな言葉だけど、読み終わったら「あーそういうことか！」ってなるから安心してね。
- BFFとは Backend for Frontend の略で、フロントエンドごとに専用のバックエンドを用意するアーキテクチャのこと
- スマホ・PC・TVなど 画面の種類に応じて最適なデータ を届けられるようになる仕組みだよ
- 大規模なサービス開発では 開発スピードの向上・無駄な通信の削減 につながるメリットがある
もうちょっと詳しく
BFFは2015年ごろにSam Newman（サム・ニューマン）というエンジニアが広めたアーキテクチャパターン、つまり「システムの設計方法のひとつ」だよ。従来は「1つのAPIが全部のクライアントに対応する」という形が多かったんだけど、サービスが大きくなるにつれて「スマホにとっては重すぎる」「PCにとっては情報が足りない」という問題が出てきた。そこでBFFが生まれたんだ。具体的には、スマホアプリ用・Webブラウザ用・スマートTV用それぞれに「専用バックエンド（BFF）」を置いて、各フロントエンドが必要とするデータだけを最適な形で渡すようにする。これによってフロントエンドの開発チームが「自分たちのBFF」を自分たちでコントロールできるようになり、開発スピードが大幅に上がるんだよ。
BFFはチームの「自治権」を守る仕組みでもある！
⚠️ よくある勘違い
→ BFFを使っても既存のバックエンドAPIは残る。BFFはその「手前に置く仲介レイヤー」なので、APIが消えるわけじゃないよ。
→ バックエンドのAPIはそのままに、BFFがフロントエンドごとに「必要な形」に変換して渡す役割を担うんだ。
[toc]
BFFとは？まずは「なんのため」かを理解しよう
「1つのAPIが全員に答える」時代の限界
ちょっと想像してみて。給食の時間、全員に「同じ量・同じメニュー」が配られるとするよ。でも小食な人には多すぎるし、スポーツ部の子には少なすぎる。これと同じことが、アプリ開発の世界でも起きてたんだ。
昔ながらの設計では、1つのAPI（つまりデータを送り出す窓口）がスマホにもPCにもスマートTVにも「同じデータ」を返してた。でもスマホは画面が小さいし、通信速度も場合によっては遅い。必要なのは「軽くて速いデータ」。一方でPCは大きな画面で複雑な情報をどんどん処理できる。「全員同じ給食」じゃ、誰かが損をするんだよ。
BFFはそこに「専任の担当者」を置く
BFFはその問題を解決するために「フロントエンドの種類ごとに専用のバックエンドを作ろう」という発想から生まれた。つまり——
- スマホアプリ → スマホ専用BFF
- Webブラウザ → Web専用BFF
- スマートTV → TV専用BFF
それぞれの「担当者（BFF）」が、裏側にある本体のデータベースやAPIから情報を取ってきて、各フロントエンドに合った形に加工して渡すんだ。給食で言えば「スポーツ部専用の大盛り給食係」「小食な人専用の少なめ給食係」を用意するイメージだよ。
BFFが登場した背景——マイクロサービスと深い関係
マイクロサービスって何？
BFFを理解するには「マイクロサービス」というキーワードも知っておくと便利だよ。マイクロサービスとは、大きなシステムを「小さな機能のかたまり」にバラバラに分割して作る設計手法のこと。つまり「検索機能」「ログイン機能」「決済機能」をそれぞれ独立したサービスとして動かすやり方だよ。
大きなショッピングモールに例えると、昔は「全部入りの巨大デパート1棟」で運営してた。でもマイクロサービスだと「食料品店・洋服屋・家電量販店」が別々に独立して並んでいる商店街みたいな感じ。それぞれが独立してるから、1つのお店が改装中でも他のお店は普通に営業できる。
マイクロサービスとBFFの組み合わせ
マイクロサービスが広まったことで新しい問題が出てきた。フロントエンド（スマホアプリなど）が必要なデータを集めるために「検索サービス」「ユーザー情報サービス」「在庫サービス」…と何度も何度も別々に問い合わせないといけなくなったんだ。
これ、めちゃくちゃ非効率だよね。そこでBFFが「窓口係」として間に入って、複数のマイクロサービスからデータをまとめて取得し、フロントエンドに「必要な情報だけをセットにして」渡すようになった。フロントエンドは1回問い合わせるだけで全部もらえる。すごく合理的だよ。
BFFの具体的な仕組みを図解で理解しよう
データの流れをステップで追う
実際にBFFがどう動くか、Amazonのようなショッピングアプリを例に考えてみよう。あなたがスマホで「商品ページ」を開いたとき、裏側では何が起きてるんだろう？
- スマホアプリが「商品ページのデータをください」とスマホ専用BFFにリクエストを送る
- BFFは「商品情報サービス」「在庫サービス」「レビューサービス」の3か所に問い合わせる
- 3か所からデータが返ってくる
- BFFがデータをスマホ向けに「必要な情報だけ」に絞って整形する
- スマホアプリに返送される
これ、BFFがなければスマホアプリ自体が3か所に問い合わせて、重いデータを全部受け取って、自分で必要な部分だけ取り出す……という大変な作業が必要になる。BFFがあることで、スマホアプリは「軽くて使いやすいデータ」を1回の問い合わせでもらえるんだよ。
PC版との違いも見てみよう
同じ商品ページでも、PCブラウザ版なら画面が大きいから「レビューを全件表示」「関連商品を横並びで大量表示」などができる。PC専用BFFはPC向けに「より詳しい・より多いデータ」を渡すように設定される。スマホ専用BFFとPC専用BFFは同じバックエンドのデータを使いながら、それぞれのフロントエンドに最適化された「別の料理」を出してるんだね。
BFFのメリットとデメリット——いいことばかりじゃない
メリット：開発チームが自由に動ける
BFFの最大のメリットは「フロントエンドチームの自由度」が上がることだよ。BFFがなかった頃は、スマホアプリのチームが「このデータが欲しい」と思っても、バックエンドのチームに「APIを変えてください」とお願いしないといけなかった。バックエンドチームが忙しければ何週間も待つことに。
BFFがあれば、スマホアプリチームが「自分たちのBFF」を自分たちで書き換えられる。バックエンドを触らずに済むから、スピードが全然違う。これを「チームの自律性」と言うよ——つまり「自分たちのことは自分たちで決められる状態」ってこと。
他にもこんなメリットがある：
- 不要なデータを送らないから通信量が減る（特にスマホに優しい）
- フロントエンドごとに認証・セキュリティのルールを変えやすい
- エラーが起きたとき「どのBFFの問題か」が特定しやすい
デメリット：コードが増えて管理が大変
いいことばかりじゃなくて、デメリットもちゃんと知っておこう。BFFを使うと「スマホ用BFF」「PC用BFF」「TV用BFF」…とたくさんのバックエンドを管理しないといけない。フロントエンドが10種類あれば、BFFも10個。それぞれをメンテナンスするのは結構大変だよ。
また、似たような処理が複数のBFFに重複して書かれることもある。「ログイン確認」の処理がスマホ用BFFにもPC用BFFにも書いてあって、片方を直したら片方を直し忘れた……なんて問題も起きやすい。小さなチームや単純なサービスには「オーバーエンジニアリング」、つまり「大げさすぎる設計」になることも多い。
BFFが使われているサービスの実例と、使うべき場面
実際にBFFを使っているサービス
BFFは特に大規模なIT企業でよく使われているよ。例えば——
- Netflix（ネットフリックス）：スマホ・PC・ゲーム機・スマートTVなど100種類以上のデバイスに対応するため、デバイスごとに最適化されたBFFを持っている
- SoundCloud（サウンドクラウド）：マイクロサービスへの移行とともにBFFパターンを採用したことで有名
- 各種ECサイト：スマホアプリ版とブラウザ版で異なるBFFを持ち、表示する商品数や画像の解像度を最適化している
どんなときにBFFを使うべき？
BFFが向いているのはこんな場面だよ：
- スマホ・PC・TVなど、複数の異なるクライアントに対応するサービスを作るとき
- フロントエンドチームとバックエンドチームが別々に存在していて、それぞれ独立して開発したいとき
- マイクロサービスを使っていて、フロントエンドがたくさんのサービスに問い合わせないといけない状況のとき
逆に、小さなチームで「Webブラウザだけに対応するシンプルなサービス」を作る場合はBFFを使う必要はないよ。設計はシンプルであるほどいい。「大きくなったら必要になる」タイミングで導入するのが賢いやり方だよ。
BFFは「銀の弾丸（何でも解決する魔法の答え）」じゃなくて「特定の問題を解決するための道具」。自分たちのサービスの規模や状況に合わせて使うかどうかを判断するのが、本当に技術を理解してる証拠だよ。
