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

BFFのシステム開発は、要件整理から始め、方式と開発会社の選定、設計・開発の順に進みます。その後、テスト、稼働を経て、定着へ移ります。まず画面とAPIの事実をそろえ、代表画面で検証してから段階的に広げるのが基本です。

BFFの役割と導入の判断、各フェーズで決めること、費用と見積もりの確認事項を説明します。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

BFFのシステム開発の全体像

BFF（Backend for Frontend）は、Webやスマートフォンなどのフロントエンドごとに、必要なデータを集めて変換し、返す専用のバックエンドです。たとえば、商品、在庫、会員、注文のAPIを呼び出し、商品詳細画面に必要な形にまとめて返します。そのため、フロントエンドは業務APIを個別に呼び出さずに済み、画面側の実装も単純に保てます。

BFFが担う役割と、業務サービスとの境界

BFFは画面が必要とするデータを扱い、共通機能や業務ルールとは役割を分けて考えます。

• 画面向け処理：API集約、レスポンス変換、ページングを担います。
• 画面単位の制御：認証・認可、キャッシュ、タイムアウト、リトライ、レート制限、監査ログ。
• 業務ルール：注文確定、与信、在庫引き当て、請求計算は、ドメインサービスや基幹側に置きます。

業務ルールをBFFに集めると、Web用とアプリ用で判定が分かれ、修正箇所も特定しにくくなります。

構成は、クライアントからAPI Gatewayに入り、認証や共通の流量制御を行ったあと、Web BFFまたはモバイルBFFへ接続します。そのうえで、各業務サービスにつなぎます。

Microsoft Learnの公式パターンでは、API Managementが共通の認証、監視、キャッシュ、ルーティングを担います。さらに、クライアント別BFFが画面固有の集約を行う例も示しています（出典: Microsoft Learn「フロントエンド専用バックエンドパターン」、2025年5月更新）。

BFFを導入するケースと、増やさないケース

BFFを入れるかは、画面ごとの要件の違いと、サービス数の増加を比べて判断します。

• 複数画面の要件差：Web、アプリ、店舗端末、管理画面でデータ形式や通信条件が異なる場合に検討します。
• 既存システムの活用：基幹システムやCRMを残し、新しい画面向けの接続層を加える場合も候補です。
• 公開範囲の整理：個人情報や社内APIを、ブラウザに直接公開したくない場合が該当します。
• 単一画面：既存APIで要求を満たせるなら、BFFを増やさない方が合理的です。
• 代替手段：API GatewayやGraphQLのフロントエンド固有リゾルバーで、同じ目的を果たせる場合もあります。

小規模なシステムでは、API Gatewayのルーティングとバックエンドのレスポンス設計で足りることもあります。Microsoft Learnも、単一または要求がほぼ同じインターフェースにはBFFが適さない可能性を示しています。

最終的には、導入効果とサービス数の増加を見比べ、自社の画面要件に照らして判断します。

BFFのシステム開発の進め方と6つのフェーズ

BFF開発は6つのフェーズで進み、画面の目的と業務APIの状態を把握する要件整理から始まります。その後、方式と開発会社の選定、設計・開発を経て、テストに進みます。そのうえで、稼働と定着へ移り、代表画面を検証してから本番へ段階的に広げます。

各フェーズの成果物を先に決めておくと、発注先との認識のずれを減らせます。

フェーズ1：画面とAPIの事実をそろえる要件整理

要件整理では、画面の仕様、必要なデータがどの業務サービスにあるか、接続条件をそろえます。

• 画面一覧：利用者、操作、表示データ、更新処理、待ち時間、オフラインや通信不安定時の扱いを記します。
• データ対応：商品詳細など代表的な1〜2画面を選び、必要データを持つ業務サービスと対応づけます。
• 接続条件：フロントエンドの種類と数、API所有部署と仕様書、認証方式。
• 非機能要件：個人情報・決済情報、ピーク時の同時アクセス、応答時間、部分表示の範囲を確認します。

画面別API、データ項目、認証・権限、非機能要件の一覧を成果物にしておくと、後工程での追加請求を抑えやすくなります。また、API仕様書の有無や決済情報の有無も、接続条件とあわせて整理します。

フェーズ2：方式と開発会社の選定

要件を整理したら、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、負荷試験、保守を分けた見積もりを指定してください。

フェーズ3：契約と障害時の動きを決める設計・開発

設計・開発では、画面単位の契約、認証・権限、実装と検証の流れを決めます。

• API契約：エンドポイントと入出力、エラーコードを定義し、タイムアウト、リトライ、キャッシュ期間も決めます。ログ項目と権限の判定場所も含めます。
• 障害時の応答：遅い依存先を待つか、取得済みのデータを返すかを決めます。
• 認証と業務判定：注文確定や権限変更は、業務サービスで最終判定します。
• 代表画面の実装：コード、API契約、テスト、CI/CD、監視を小さく作り、動作を確かめます。

書き込み処理では、冪等性キーや重複チェックを使い、リトライによる二重登録を防ぎます。

認証では、業務APIのアクセストークンをブラウザに長期間保持させる構成を避けます。このとき、Cookieセッションの属性（HttpOnly、Secure、SameSite）、CSRF対策、トークン更新、ログアウト時の失効を確認します。

業務ルールはBFFに集めず、BFFでは画面に必要な認証情報と公開範囲を整えます。

個人データを扱う場合は、漏えい、滅失、毀損を防ぐために、必要かつ適切な安全管理措置が求められます。そのため、ログのマスキング、保存期間、委託先との責任の分け方も設計書と契約書に記載します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。

代表画面の薄い縦切りから始めると、効果を確かめられます。その際は、小さな実装で、遅延、データ欠落、障害時の表示を確認します。

LINE ENGINEERINGの出前館Webリプレイスでは、WebとBFFを別サーバーに分けました。その結果、負荷に応じた台数調整やデプロイ・ロールバックの分離がしやすくなったと報告されています。

BFFを分けること自体より、分ける目的と運用単位を先に定義します。

フェーズ4：API集約と障害連鎖を検証するテスト

テストでは、ロジック、サービス接続、画面操作を、それぞれ検証します。

• 単体・契約・結合テスト：BFFのロジック、業務サービスとの入出力、実際の接続を確認します。
• 受け入れ・負荷試験：画面操作とピーク時の同時アクセスを検証します。
• 障害・セキュリティ試験：依存先の遅延や停止、認証・認可、脆弱性を検査します。

タイムアウトの連鎖や、リトライによるリクエスト増幅がないかも確認します。また、部分レスポンスで画面が誤った情報を表示しないか、個人情報がログやトレースへ残らないかも検査します。

OWASP API Security Top 10 2023では、認可不備、機微な業務フローへの無制限アクセス、SSRFなどが上位リスクに挙げられています（出典: OWASP API Security Top 10 2023、2023年）。そのため、テスト計画にオブジェクト単位の認可、レート制限、外部URLへの接続制御を含めます。

フェーズ5：段階リリースと切り戻しの準備を含む稼働

本番稼働では、段階リリースと切り戻しの準備、業務結果による判定を行います。

• 段階リリース：社内利用者や限定ユーザーから開放し、全画面を一度に切り替えません。
• 切り戻し準備：復帰手段、切替前の確認事項、担当者と実施条件を決めます。
• 稼働判定：成功率や応答時間、依存先のエラーなどを事前基準と照合します。

切り替え前には、DNSやルーティング、シークレットを確認します。さらに、環境変数と監視通知、バックアップ、問い合わせ窓口も確かめます。加えて、フィーチャーフラグ、カナリアリリース、旧APIへのフォールバックなど、問題時に戻せる仕組みを用意します。

稼働判定は、デプロイの成否ではなく業務結果で行います。代表画面の成功率、P95応答時間、依存サービス別エラー率、タイムアウト数、認証失敗数を監視します。

BFFのCPU・メモリ・同時実行数も確認し、事前の基準を満たすか判定します。モバイル向けではペイロードサイズと通信回数、管理画面では大量データ取得時の負荷も測定します。

フェーズ6：運用ルールと所有者を固定する定着

定着させるには、所有者、継続監視、仕様変更、委託時の引き継ぎを決めておきます。

• 所有者と連絡先：担当チーム、互換性を壊す変更の承認者、脆弱性対応期限、夜間連絡先を定めます。
• 定期的な見直し：利用状況、性能、費用を継続的に見直します。
• 引き継ぎ：委託時はコード、テスト、IaC、監視、運用資料を受け取ります。

Webチームやアプリチームが所有するか、共通のプラットフォームチームが運用するかを決めます。

ドメインサービスとはAPI契約で連携し、それぞれの担当を明らかにします。障害時にどこまでを誰が受け持つかも、あらかじめ決めておきます。

月次では、未利用エンドポイント、エラー率の高い依存先、キャッシュヒット率、平均・P95応答時間、クラウド費用、ログ量を見直します。

APIのバージョンを増やし続けると、BFFが古い仕様を抱え込みます。そこで、廃止予定日と移行方法を公開し、利用者を新しい契約へ誘導します。

委託時は、障害報告書のテンプレートも受け取ります。運用資料があれば、内製化や相見積もりへの移行に役立ちます。

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

BFF単体の公的な価格表は、ほとんど見当たりません。費用は、画面数、API数、既存APIの品質で変わります。さらに、認証・認可、可用性、監査、テスト、運用体制も影響します。

ここで示す金額は、既存APIを利用し、データ移行や基幹刷新を含まず、BFFと周辺クラウド・運用を整備する前提の推定レンジです。これは一般的な業務システム開発の工数相場を置き換えた目安で、市場統計の確定価格ではありません。

規模別の初期開発費と期間の目安

規模ごとの推定費用と期間は、対象範囲によって次のように変わります。

• PoC・MVP：300万〜600万円程度、2〜3か月。
• 小規模本番：600万〜1,200万円程度、3〜5か月。
• 中規模：1,200万〜2,500万円程度、5〜8か月。
• エンタープライズ：2,500万〜6,000万円以上、8〜12か月以上。

PoC・MVP（Minimum Viable Product）は、1フロント、5〜10エンドポイント、既存API接続、基本認証、最低限のテストに絞ります。

小規模本番ではCI/CD、監視・ログ、負荷試験まで含めます。いずれも、既存APIの仕様が安定し、代表画面から段階的に広げる前提です。

中規模では複数フロントやドメインサービス、APIバージョン管理、可用性設計、移行支援まで含みます。エンタープライズでは、複数BFFと基幹・外部SaaS連携が対象になります。さらに、冗長化、監査、災害復旧、24時間運用も対象に含まれます。

各金額は推定レンジで、決済、個人情報、厳格なSLA、既存APIの改修がある場合は、別途増額されます。

開発費に含めるべき項目と別途になりやすい項目

見積もりは、開発作業、人件費、周辺環境・運用費に分けて確認します。

• 開発作業：要件整理、設計、BFF実装、API接続が含まれます。認証・認可、テスト、管理も対象です。
• 人件費の目安：総額の60〜80％程度を占めることがあり、職種別単価で積算します。
• 別途費用：API Gatewayなどのクラウド機能、試験環境、監視、移行、診断。

API契約の調整や障害時の仕様決定にも工数がかかるため、既存API所有部署との調整費も確認します。PMは月90万〜150万円、SEは月65万〜110万円程度で積算されるケースがあります。

これらは市場全体で統一された価格ではなく、スキル、契約形態、地域、期間によって変わります。

AWS公式では、API GatewayはAPI呼び出し数とデータ転送を中心に従量課金されます。HTTP API・REST APIも、利用時に課金される仕組みです（出典: AWS「Amazon API Gateway pricing」、2026年8月確認）。

Lambdaも、リクエスト数と実行時間で課金されます。初期費用とクラウドの月額費用は、分けて見積もります。

ランニングコストと費用が増える条件

月額費用は構成規模に加え、監視やログの保存条件によっても変わります。

• 低トラフィック：サーバーレス構成で月1万〜10万円程度からの可能性があります。
• 中規模：監視やWAF、ログ保管、DB、複数環境を含み、月10万〜50万円程度です。
• 高負荷など：月50万〜200万円以上になることもあります。

高負荷、常時稼働、多リージョン、長期ログ保存、厳格な監視は、費用を押し上げます。

これらは、為替、リージョン、通信量、ログ量、可用性で変動する概算で、請求額を保証するものではありません。

保守運用費は、初期開発費の年間15〜25％程度を目安に置くケースがあります。ただし、定常監視、平日日中の問い合わせ、24時間365日の障害対応のどこまで含むかで変わります。

見積書では、クラウド実費、監視・保守費、脆弱性対応、API仕様変更への対応、追加開発を分けます。月額の上限や超過時の計算方法も確認してください。

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

見積もりは、エンドポイント数よりも工数を増やす要件で比べます。接続先が少なくても、認証、厳格な認可、複雑な集約、部分表示、監査ログ、負荷試験が必要なら工数は増えます。

既存APIの仕様が安定し、代表画面に絞り、マネージドサービスを活用できれば、小さく始められます。

依頼書には、作る範囲と作らない範囲を同じページに併記します。

画面別の要件とAPI契約の準備

発注資料には、画面別の仕様、API契約、範囲分担、比較条件をまとめます。

• 画面・API資料：権限、データ、更新、接続先を記します。想定エラー、負荷、応答目標も書きます。
• API契約：仕様、例、制限、SLA、変更履歴、所有者を添付します。
• 実装範囲：BFF、業務サービス、API Gatewayの担当を明確にします。

資料が不足する場合は、要件定義とAPIの洗い出しを本開発と分け、最初の調査で不確実性を減らします。

たとえば、商品詳細画面では、商品、在庫、会員ランクを集約し、価格計算は商品サービスに残すと記します。

レスポンスの項目名、nullの扱い、ページング、タイムアウト、部分成功の表現も決めると、各社の提案を比べられます。

非機能要件と運用範囲の金額への反映

非機能要件と運用範囲を明確にして、金額に反映します。性能、可用性、セキュリティ、保守条件を指定します。

• 性能：P95・P99応答時間、同時アクセス、ピーク継続時間、許容エラー率。
• 可用性：月間稼働率、復旧目標時間・時点、バックアップ、冗長化。
• セキュリティと運用：認証、診断、監視、通知を指定します。対応、更新、ログ保存も含めます。

セキュリティではOAuthやOIDC、Cookie、WAF、秘密情報管理、脆弱性診断を確認します。個人情報のマスキングと監査ログの保存期間も定義します。

運用範囲には、監視項目、通知先、一次切り分け、二次対応、依存サービス障害時の連絡を含めます。

月次レポート、OSやランタイムの更新、脆弱性の修正期限も確認します。監視設定や手順書がなく、稼働後の保守を別会社が担うと、開発費が安くても総額は上がります。

初期開発費、クラウド利用料、保守費、追加改修費を5年間の総保有コスト（TCO）で比較してください。

契約で確認する成果物、権利、障害対応の分担

契約では、納品物と権利、障害対応でどこまでを誰が受け持つかを明示します。

• 納品物：コード、API資料、テスト、試験結果を含みます。IaC、CI/CD、監視、運用・切り戻し手順も対象です。
• 権利関係：著作権・利用権、ライセンス、IaC、クラウドアカウントを確認します。
• 責任分界：障害切り分け、API変更通知、変更承認、SLAの対応条件を決めます。

委託先のリポジトリで開発する場合、発注者が閲覧・取得できる方法を契約に含めます。

SLAには応答時間のほか、障害受付時間、一次回答、復旧目標、計画メンテナンス、セキュリティインシデントの報告期限を含めます。そうすると、実運用での期待値をそろえられます。

同じ条件での複数社比較とPoCからの開始

相見積もりでは依頼条件をそろえ、見積もりの内訳とPoCの結果を比べます。

• 共通条件：画面・API一覧、環境数、非機能要件、試験範囲、保守期間を渡します。
• 見積もり比較：工程ごとの費用、含む範囲、前提、追加費用条件を確認します。
• PoC評価：P95応答時間、依存先停止時の表示、ログのマスキング、デプロイと切り戻しの手順、保守可能性を確かめます。

見積もりは、要件定義、設計、実装、テストの工程で分けます。インフラ、移行、保守も別に示してもらいます。技術名よりも、障害時の挙動、API契約の管理、運用引き継ぎを質問すると、各社の差が見えます。

不確実性が高い場合は、全社に同じ1画面のPoCを依頼できます。その画面では、商品、在庫、会員など複数APIを集約します。

認証、キャッシュ、タイムアウト、テスト、監視も試します。合否は、画面表示だけでなく、これらの動きで判断します。

同じ1画面の条件で各社の提案を比べると、実務上の差を判断できます。

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

BFFの導入判断、API Gatewayとの違い、費用、開発会社への依頼範囲について、よくある質問に答えます。

BFFはすべての業務システムに必要ですか？

いいえ、すべての業務システムに必要ではありません。複数のフロントエンドで要求や通信条件が異なる場合は、導入効果が出やすくなります。

また、既存APIを変えずに画面を増やしたい場合や、画面から社内APIを直接呼び出したくない場合も候補になります。一方で、画面が一つでAPIをそのまま使えるなら、API Gatewayや既存バックエンドの改善で十分な可能性があります。

API GatewayとBFFはどのように使い分けますか？

API Gatewayは、認証、ルーティング、レート制限、TLS終端、共通ログなど、複数サービスに共通の入口機能を担います。一方、BFFは特定の画面向けに、複数のAPIを集約してデータを変換します。

API Gatewayだけで画面要件を満たせる場合は、BFFを置かなくても構いません。クライアントごとの集約や変換が複雑なら、役割を分ける方が保守しやすくなります。

BFFの開発費用は最低いくらから考えるべきですか？

BFFの開発費用は、PoCの範囲や含める条件によって異なります。

• PoCの目安：既存APIが整い、1フロントの代表画面に絞る場合、300万〜600万円程度です。
• PoCの前提：基本認証、5〜10エンドポイント、最低限のテストを含む推定レンジで、公定価格ではありません。
• 増額条件：基幹API改修、複数画面、決済・個人情報、24時間運用、監査、データ移行で費用が増える可能性があります。
• 大規模の目安：条件によっては中規模が1,200万円超、エンタープライズが2,500万円以上になる可能性があります。

BFFのセキュリティで最初に確認することは何ですか？

確認項目は、アクセス管理からシステム各層の防御までに分けられます。

• アクセス範囲：画面・データごとの利用者を整理し、認証と認可を分けます。
• セッション管理：Cookie属性、CSRF対策、トークンの保管方法を確認します。
• 攻撃対策：オブジェクト単位の認可、レート制限、SSRF、入力検証、ログの個人情報マスキング、脆弱性対応期限。
• 多層防御：BFFだけで完結させず、API Gateway、業務サービス、データベースでも権限を検証します。

BFF開発を外注するとき、何を納品してもらえばよいですか？

納品物には、BFFのソースコード、API仕様書、データマッピング、テストコードと結果を含めます。負荷試験結果、IaC、CI/CD設定に加えて、監視・アラートとセキュリティ設定も必要です。運用手順と切り戻し手順も欠かせません。

エンドポイントごとの所有者、API廃止手順、障害時の連絡網、保守契約の範囲、ソースコードとクラウドアカウントの権利関係を契約で確認します。

納品後に自社チームが再現環境を作り、デプロイと切り戻しを実行できるかも、検収条件に加えられます。

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

まとめると、BFF開発は、要件整理と方式・開発会社の選定から始め、設計・開発を経て、テストに進みます。そのうえで、段階的な稼働と運用定着へ移ります。進める前に、画面一覧、データ項目、認証・権限、非機能要件をそろえます。

BFFに置く処理と業務サービスに残す処理を分けたうえで、代表画面のPoCを行います。API集約の効果に加え、遅延、障害時の挙動、運用負荷、担当の分け方を検証してください。

着手前に確認する5つの判断基準

着手前に確認する項目を、5つの判断基準にまとめます。

• 画面要件：フロントエンドごとに要求や通信条件が異なるか。
• 既存API：APIを変更せず、新しい画面を追加したいか。
• 情報保護：認証・認可や個人情報の公開範囲を整理できているか。
• 性能要件：ピークアクセスと応答時間を測れるか。
• 運用体制：BFFを誰が保守するか決まっているか。

いずれも曖昧なら、要件整理やAPIの洗い出しを発注し、全体開発の見積もりと切り分ける方法が適しています。

見積もりと開発を成功させる次の一歩

開発会社へ相談するときは、画面別API一覧、認証方式、SLAをRFPに盛り込みます。また、ログ保存、ソースコードとIaCの帰属、保守範囲も含めます。BFF本体とクラウド・運用費は分けて提示してもらいます。

価格だけでなく、契約テスト、障害試験、段階リリース、切り戻し、稼働後の所有者も比べます。代表画面の小さなPoCから始めると、自社の必要性を確かめながら費用とリスクを抑えられます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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