BFFのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

BFF（Backend for Frontend）は、Webやスマートフォンなどフロントエンドごとに、必要なデータを集約・変換して返す専用バックエンドです。開発では、画面要件から逆算して小さく始め、業務ロジックをBFFへ移しすぎないことが成功の要点です。

「BFFのシステムを導入したいものの、どこから要件を整理し、何を開発会社へ伝えればよいか分からない」と悩む担当者は少なくありません。BFFはAPIを一つ追加すれば終わる仕組みではなく、認証、複数APIの集約、障害時の応答、監視、運用体制まで含めて設計する必要があります。本記事では、業務システムにBFFを導入する進め方を、要件整理から定着まで6つのフェーズに分けて解説します。費用相場や見積もりの見方、発注前のチェックリストも紹介しますので、自社にBFFが必要か判断する材料として活用してください。

▼全体ガイドの記事
・BFFのシステム開発の完全ガイド

BFFのシステム開発とは？まず全体像を理解します

BFFは、フロントエンドと業務サービスの間に置く、画面に近いバックエンドです。たとえば商品、在庫、会員、注文の各APIを呼び出し、商品詳細画面が必要とする形にまとめて返します。フロントエンドが個別の業務APIを何本も直接呼び出さずに済むため、画面側の実装をシンプルにしやすい点が特徴です。

BFFが担う代表的な処理は、複数APIの集約、レスポンスの変換、ページング、画面単位の認証・認可、キャッシュ、タイムアウト、リトライ、レート制限、監査ログです。一方、注文確定、与信判定、在庫引き当て、請求金額の計算といった業務ルールは、ドメインサービスや基幹側に置くのが基本です。BFFに業務ルールを集約すると、Web用BFFとアプリ用BFFで異なる判定が生まれ、後から修正箇所を特定しにくくなるためです。

役割分担を図にすると、クライアントからAPI Gatewayへ入り、認証や共通の流量制御を行った後、Web BFFまたはモバイルBFFへルーティングし、その先で業務サービスへ接続する流れになります。Microsoft Learnの公式パターンでも、API Managementを共通の認証・監視・キャッシュ・ルーティングの層とし、クライアント別のBFFが画面固有の集約を担う例が示されています（出典: Microsoft Learn「フロントエンド専用バックエンドパターン」、2025年5月更新）。

BFFを検討しやすいのは、Web、スマートフォンアプリ、店舗端末、管理画面など複数の利用者向け画面があり、それぞれで必要なデータ形式や通信条件が異なるケースです。既存の基幹システムやCRMを残したまま新しい画面を追加したい場合にも、既存APIを直接改修せずに画面向けの接続層を用意できる可能性があります。個人情報や社内APIをブラウザへ直接公開したくない場合も、認証と公開範囲を整理する候補になります。

反対に、利用するフロントエンドが一つだけで、既存APIがその画面の要求をすでに満たしている場合は、BFFを増やさない方が合理的です。小規模なシステムならAPI Gatewayのルーティングとバックエンドのレスポンス設計で足りることもあります。GraphQLのフロントエンド固有リゾルバーで同じ目的を達成できる場合もあります。Microsoft Learnも、単一インターフェースや要求がほぼ同じインターフェースではBFFが適さない可能性を示しているため、導入効果とサービス数の増加を比較してください。

BFFのシステム開発の進め方を6フェーズで解説します

BFF開発は、いきなりエンドポイントを実装するのではなく、画面の目的と業務APIの状態を把握してから、代表画面で検証し、本番へ段階的に広げます。ここでは、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで進めます。各フェーズの成果物を先に決めておくと、発注先との認識違いを減らせます。

最初に、対象となる画面を一覧化します。画面名だけでなく、利用者の種類、主な操作、表示するデータ、更新処理、許容できる待ち時間、オフラインや通信不安定時の扱いまで記載します。商品詳細、注文履歴、在庫確認など代表的な1〜2画面を選び、画面が必要とするデータをどの業務サービスが持っているかを対応づけます。

この段階のチェックリストは、フロントエンドの種類と数、既存APIの所有部署、API仕様書の有無、認証方式、個人情報や決済情報の有無、ピーク時の同時アクセス、レスポンスタイムの目標、障害時に許容する部分表示の範囲です。画面別API一覧、データ項目一覧、認証・権限一覧、非機能要件一覧を成果物にすると、後工程の追加請求を抑えやすくなります。

要件を整理したら、BFFの実装方式を選びます。AWS API GatewayとLambda、Azure API ManagementとAzure Functionsのようなマネージドサービスを使う方式は、インフラの初期構築を抑えやすく、アクセス量が変動するサービスに向きます。ECS、EKS、AKS、Cloud Runなどのコンテナ方式は、既存のコンテナ標準や長時間処理、細かなスケール制御がある企業に向きます。Node.js・TypeScript、Java・Spring Boot、Goなどの言語は、既存チームの保守能力と業務サービスとの整合性で決めます。

開発会社の比較では、BFFという名称を使った実績数だけで判断しないことが重要です。画面別の集約ロジックを実装できるか、基幹APIの所有者と調整できるか、セキュリティレビューや負荷試験を誰が担当するか、ソースコードとIaCを引き渡すか、稼働後の障害対応時間はどれくらいかを確認します。提案依頼書には、BFF本体、API Gateway、認証基盤、監視、CI/CD、負荷試験、保守を分けて見積もるよう指定してください。

設計では、画面単位のエンドポイント、リクエストとレスポンス、エラーコード、タイムアウト、リトライ、キャッシュの有効期間、ログ項目、権限の判定場所を決めます。複数APIを並列に呼び出す場合は、一部のサービスが遅いときに全画面を待たせるのか、取得できたデータだけを返すのかを仕様化します。書き込み処理では、リトライによる二重登録を避けるため、冪等性キーや重複チェックも設計に含めます。

認証では、ブラウザに業務APIのアクセストークンを長期間保持させる構成を安易に採用せず、Cookieセッション、HttpOnly、Secure、SameSite、CSRF対策、トークン更新、ログアウト時の失効を確認します。BFFは業務ルールの置き場ではないため、注文確定や権限変更の最終判定は業務サービス側で行い、BFFでは画面に必要な認証情報と公開範囲を整えます。個人データを扱う場合は、漏えい、滅失、毀損を防ぐために必要かつ適切な安全管理措置が求められるため、ログのマスキング、保存期間、委託先の責任分界も設計書と契約書に記載します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。

開発は、代表画面の薄い縦切りから始めると効果を判断しやすくなります。BFFのコード、API契約、単体テスト、CI/CD、監視ダッシュボードまでを一つの小さな流れとして作り、遅延、データ欠落、障害時の表示を確認します。LINE ENGINEERINGが公開した出前館Webリプレイスでは、WebとBFFを別サーバーに分けたことで、負荷に応じた台数調整やデプロイ・ロールバックの分離がしやすくなったと報告されています。BFFは分ければよいのではなく、分ける目的と運用単位を先に定義することが大切です。

テストは、単体テストだけで終わらせません。BFF固有のロジックには単体テスト、業務サービスとの入出力には契約テスト、実際の接続には結合テスト、画面操作には受け入れテストを用意します。さらに、ピーク時の同時アクセスを想定した負荷試験、依存サービスの遅延や停止を再現する障害試験、認証・認可と脆弱性の検査を実施します。

特に確認したいのは、タイムアウトが連鎖しないか、リトライがリクエストを増幅しないか、部分レスポンスのときに画面が誤った情報を表示しないか、個人情報がアプリケーションログやトレースへ残らないかです。OWASP API Security Top 10 2023では、上位のリスクに認可不備、機微な業務フローへの無制限アクセス、SSRFなどが挙げられています（出典: OWASP API Security Top 10 2023、2023年）。BFFのテスト計画にも、オブジェクト単位の認可、レート制限、外部URLへの接続制御を含めてください。

本番稼働では、全画面を一度に切り替えず、社内利用者や限定ユーザーから段階的に開放します。フィーチャーフラグ、カナリアリリース、旧APIへのフォールバックなど、問題発生時に戻せる仕組みを用意します。切り替え前には、DNSやルーティング、シークレット、環境変数、監視通知、バックアップ、問い合わせ窓口を確認し、誰がどの条件で切り戻すかを決めておきます。

稼働判定は「デプロイできたか」ではなく、業務結果で行います。代表画面の成功率、P95の応答時間、依存サービス別のエラー率、タイムアウト数、認証失敗数、BFFのCPU・メモリ・同時実行数を監視し、事前に定めた基準を満たすかを確認します。モバイル向けではペイロードサイズと通信回数、管理画面では大量データ取得時の負荷も測定してください。

BFFは稼働後も画面要件と一緒に変わります。WebチームやアプリチームがBFFを所有し、ドメインサービスとはAPI契約で連携するのか、共通のプラットフォームチームが運用するのかを決めます。エンドポイントごとの所有者、変更申請、互換性を壊す変更の承認者、脆弱性対応の期限、夜間障害の連絡先を一覧化しておくと、障害時の責任の押し付け合いを防げます。

月次では、利用されていないエンドポイント、エラー率の高い依存先、キャッシュヒット率、平均・P95応答時間、クラウド費用、ログ量を見直します。APIのバージョンを増やし続けるとBFFが古い仕様を抱えるため、廃止予定日と移行方法を公開し、利用者を新しい契約へ誘導します。開発会社へ委託する場合も、ソースコードだけでなく、テスト、IaC、監視設定、運用手順、障害報告書のテンプレートまで引き渡してもらうと、内製化や相見積もりへ移行しやすくなります。

BFFのシステム開発費用相場とコストの内訳

BFF単体の公的な価格表はほとんどないため、費用は画面数、接続するAPI数、既存APIの品質、認証・認可、可用性、監査、テスト、運用体制で大きく変わります。以下は、既存APIが利用可能で、データ移行や基幹刷新を含めず、BFFと周辺のクラウド・運用を整備する前提の推定レンジです。市場統計としての確定価格ではなく、業務システム開発の一般的な工数相場をBFFの範囲へ置き換えた目安です。

PoC・MVPは300万〜600万円程度、期間は2〜3か月が一つの目安です。1フロント、5〜10エンドポイント、既存API接続、基本認証、最低限のテストに絞ります。小規模本番は600万〜1,200万円程度、3〜5か月が目安で、CI/CD、監視・ログ、負荷試験まで含めます。いずれも既存APIの仕様が安定し、代表画面から段階的に広げる前提です。

Webとアプリの複数フロント、複数ドメインサービス、APIバージョン管理、可用性設計、移行支援まで含める中規模では、1,200万〜2,500万円程度、5〜8か月が目安です。複数BFF、基幹・外部SaaS連携、冗長化、監査、災害復旧、24時間運用を含むエンタープライズでは、2,500万〜6,000万円以上、8〜12か月以上になる可能性があります。これらは推定レンジであり、決済、個人情報、厳格なSLA、既存APIの改修がある場合は別途増額されます。

見積もりの中心は要件整理、基本設計・詳細設計、BFF実装、API接続、認証・認可、テスト、プロジェクト管理です。BFFはコード量だけでなく、API契約の調整や障害時の仕様決定に工数がかかるため、既存APIの所有部署との調整費を忘れないでください。一般的な業務システムの目安では、人件費が総額の60〜80％程度を占めることがあり、PMは月90万〜150万円、SEは月65万〜110万円程度の単価で積算されるケースがあります。ただし、これは市場全体の統一価格ではなく、スキル、契約形態、地域、期間によって変わります。

別途になりやすいのは、API Gateway、WAF、認証基盤、シークレット管理、ログ・トレース、CI/CD、負荷試験環境、監視設計、移行支援、運用手順書、セキュリティ診断です。AWS公式では、API GatewayはAPI呼び出し数とデータ転送を中心に従量課金され、HTTP API・REST APIは利用時に課金される仕組みです（出典: AWS「Amazon API Gateway pricing」、2026年8月確認）。Lambdaもリクエスト数と実行時間で課金されるため、初期費用とクラウドの月額費用を分けて見積もる必要があります。

低トラフィックのサーバーレス構成なら、BFF周辺のクラウド費用は月1万〜10万円程度から始められる可能性があります。監視、WAF、ログ保管、データベース、複数環境を含む中規模では月10万〜50万円程度、高負荷、常時稼働、多リージョン、長期ログ保存、厳格な監視を含むと月50万〜200万円以上になることもあります。これは為替、リージョン、通信量、ログ量、可用性で変動する概算であり、請求額を保証するものではありません。

保守運用費は、初期開発費の年間15〜25％程度を目安に置くケースがあります。定常監視だけか、平日日中の問い合わせ対応か、24時間365日の障害対応かで大きく異なります。見積書では、クラウド実費、監視・保守費、脆弱性対応、API仕様変更への対応、追加開発を分け、月額の上限や超過時の計算方法まで確認してください。

BFFの見積もりを取る際のポイントとチェックリスト

BFFの見積もりは、エンドポイント数だけで比べると判断を誤ります。接続先の数が少なくても、認証、厳格な認可、複雑な集約、障害時の部分表示、監査ログ、負荷試験が必要なら工数は増えます。反対に、既存APIの仕様が安定し、代表画面に絞り、マネージドサービスを活用できれば小さく始められます。見積もり依頼書では、作る範囲と作らない範囲を同じページに書くことが有効です。

発注前に、画面一覧、利用者権限、画面ごとのデータ項目、更新操作、接続先API、想定するエラー、ピークアクセス、目標応答時間をまとめます。既存APIがある場合は、OpenAPI定義、サンプルリクエスト、レスポンス例、レート制限、SLA、変更履歴、所有者を添付します。資料が不足している場合は、要件定義・API棚卸しの見積もりを本開発と分け、最初の調査フェーズで不確実性を減らしてください。

RFPには、BFFが担当する画面固有の変換と集約、業務サービス側に残すルール、API Gatewayに寄せる共通機能を明記します。たとえば「商品詳細画面では商品、在庫、会員ランクを一つのレスポンスに集約するが、価格計算は商品サービスが行う」と書けば、BFFへ実装する範囲が明確になります。レスポンスの項目名、nullの扱い、ページング、タイムアウト、部分成功の表現も決めておくと比較しやすくなります。

性能では、平均値だけでなくP95やP99の応答時間、同時アクセス数、ピークの継続時間、許容するエラー率を指定します。可用性では、月間稼働率、復旧目標時間、復旧時点目標、バックアップ、マルチゾーンや多リージョンの要否を指定します。セキュリティでは、OAuthやOIDC、Cookie、WAF、秘密情報管理、脆弱性診断、個人情報のマスキング、監査ログの保存期間を確認します。

運用範囲には、監視項目、アラートの通知先、一次切り分け、二次対応、依存サービスの障害時連絡、月次レポート、OSやランタイムの更新、脆弱性の修正期限を含めます。開発費だけ安く見えても、監視設定や手順書がなく、稼働後の保守が別会社になると総額は上がります。初期開発費、クラウド利用料、保守費、追加改修費を5年間の総保有コストで比較してください。

納品物は、ソースコードだけでなく、API仕様書、データマッピング、テストコード、負荷試験結果、脅威モデル、IaC、CI/CD設定、監視ダッシュボード、運用手順、障害時の切り戻し手順まで明示します。ソースコードの著作権や利用権、第三者ライブラリのライセンス、作成したIaCの帰属、クラウドアカウントの所有者も確認してください。委託先のリポジトリで開発する場合は、発注者が閲覧・取得できる方法を契約に含めます。

責任分界では、BFFの障害と業務サービスの障害をどう切り分けるか、API仕様変更を誰が通知するか、互換性を壊す変更の承認者は誰かを決めます。SLAに応答時間だけでなく、障害受付時間、一次回答、復旧目標、計画メンテナンス、セキュリティインシデントの報告期限を含めると、実運用での期待値を合わせやすくなります。

相見積もりでは、同じ画面一覧、API一覧、環境数、非機能要件、テスト範囲、保守期間を渡します。各社の見積書を、要件定義、設計、実装、テスト、インフラ、移行、保守に分解し、含む・含まない・前提条件を並べます。提案の技術名よりも、障害時の挙動、API契約の管理、運用引き継ぎ、追加費用の発生条件を質問すると、実務上の差が見えます。

不確実性が高い場合は、全社に同じ1画面のPoCを依頼する方法があります。商品、在庫、会員など複数APIを集約し、認証、キャッシュ、タイムアウト、テスト、監視の最小構成を作ってもらいます。PoCの合否は「画面が表示されたか」だけでなく、P95応答時間、依存先停止時の表示、ログのマスキング、デプロイと切り戻しの手順、開発チームが保守できるかで判定してください。

BFFのシステム開発でよくある質問

BFFは構成要素が多いため、導入の必要性、API Gatewayとの違い、費用、開発会社への依頼範囲について疑問が生まれます。よくある質問への回答を先に確認し、自社の要件整理や提案比較に役立ててください。

いいえ、すべての業務システムに必要ではありません。複数のフロントエンドで要求や通信条件が異なる、既存APIを変えずに新しい画面を増やしたい、画面から社内APIを直接呼び出したくない場合に導入効果が出やすくなります。画面が一つでAPIもそのまま使える場合は、API Gatewayや既存バックエンドの改善で十分な可能性があります。

API Gatewayは、認証、ルーティング、レート制限、TLS終端、共通ログなど、複数サービスに共通する入口の機能を担います。BFFは、Webやモバイルなど特定画面のために複数APIを集約し、データを画面用に変換します。API Gatewayだけで画面要件を満たせる場合はBFFを置かなくても構いませんが、クライアントごとの集約や変換が複雑になるなら役割を分ける方が保守しやすくなります。

既存APIが整備され、1フロントの代表画面に絞ったPoCなら、300万〜600万円程度の推定レンジから検討できます。ただし、これは公定価格ではなく、基本認証、5〜10エンドポイント、最低限のテストを含む前提の目安です。基幹APIの改修、複数画面、決済や個人情報、24時間運用、監査、データ移行まで含めると、1,200万円を超える中規模や2,500万円以上のエンタープライズ規模になる可能性があります。

最初に、誰がどの画面とデータへアクセスできるかを整理し、認証と認可を分けて設計します。Cookieの属性、CSRF、トークンの保管、オブジェクト単位の認可、レート制限、SSRF対策、入力検証、ログの個人情報マスキング、脆弱性対応の期限を確認してください。BFFだけで防御を完結させず、API Gateway、業務サービス、データベースの各層でも権限を検証する多層防御が必要です。

BFFのソースコード、API仕様書、データマッピング、テストコードと結果、負荷試験結果、IaC、CI/CD設定、監視・アラート、セキュリティ設定、運用手順、切り戻し手順を納品物に含めます。加えて、エンドポイントごとの所有者、APIの廃止手順、障害時の連絡網、保守契約の範囲、ソースコードとクラウドアカウントの権利関係を契約で確認します。納品後に自社チームが再現環境を作り、デプロイと切り戻しを実行できるかまで検収条件にすると安心です。

BFFのシステム開発の進め方まとめ

BFFの開発は、要件整理、方式・開発会社の選定、設計・開発、テスト、段階的な稼働、運用定着の順に進めます。最初に画面一覧、データ項目、認証・権限、非機能要件をそろえ、BFFに置く処理と業務サービスに残す処理を分けます。そのうえで代表画面のPoCを行い、API集約の効果だけでなく、遅延、障害時の挙動、運用負荷、チームの責任分界を検証してください。

着手前は、(1)フロントエンドごとに要求や通信条件が異なるか、(2)既存APIを変更せずに新しい画面を追加したいか、(3)認証・認可や個人情報の公開範囲を整理できているか、(4)ピークアクセスと応答時間を測れるか、(5)BFFを誰が保守するか、の5点を確認します。いずれも曖昧なままなら、まず要件整理やAPI棚卸しを発注し、全体開発の見積もりと切り分ける方法が適しています。

開発会社へ相談するときは、画面別API一覧、認証方式、SLA、ログ保存、ソースコードとIaCの帰属、保守範囲をRFPへ盛り込み、BFF本体とクラウド・運用費を分けて提示してもらいます。価格だけでなく、契約テスト、障害試験、段階リリース、切り戻し、稼働後の所有者まで比較すると、導入後に使い続けられるBFFを選びやすくなります。自社に本当に必要かを確かめながら、代表画面の小さなPoCから始めることが、費用とリスクを抑える現実的な進め方です。

▼全体ガイドの記事
・BFFのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。