BFFの発注は、まず対象画面と既存APIを整理し、次にPoCで検証します。そのうえで、責任分界と契約を決めて進めます。
この流れで進めると、基幹システムへの影響を抑えやすくなります。全体像は、BFFのシステム開発の完全ガイドにまとめています。
▼全体ガイドの記事
・BFFのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
BFFのシステムを発注する前の全体像
BFFはBackend for Frontendの略で、画面ごとに用意する専用のバックエンドです。Web、スマートフォンアプリ、管理画面などが対象になります。
BFFは、商品・在庫・会員・注文などの複数の業務APIを呼び出します。そのうえで、画面が必要とするデータにまとめて返す役割を担います。
BFFは、汎用バックエンドを画面間で共有する代わりに、画面ごとの要件に応じてバックエンドを置くパターンです。Microsoft Learnも、このパターンとして説明しています（出典: Microsoft Learn「Backends for Frontends pattern」、2026年8月確認）。
BFFと既存バックエンド・API Gatewayの役割の違い
既存バックエンドやドメインサービスは、注文確定、与信、在庫引当などの中核ルールを管理します。一方、BFFは画面に近い場所で、複数のAPIを呼び出します。
BFFは、データ形式の変換や画面固有の認証処理も担います。API Gatewayは、認証・ルーティング・レート制限・共通ログなどを受け持つことが多く、画面用の集約とは役割が異なります。
発注時に分担を書面にしておかないと、業務ロジックがBFFに入り込むおそれがあります。その結果、画面ごとに異なる注文ルールが生まれかねないため、注意が必要です。
BFFの導入価値が高いケース
BFFの導入価値は、画面と業務APIの関係で見ます。次のような場合は、BFFが候補になります。
- 画面ごとの違い：Webとアプリで必要なデータ形式が異なる
- API集約：複数の業務APIを一画面で組み合わせる
- 画面追加：既存APIを変えずに新しいフロントエンドを追加する
- 直接接続の懸念：認証情報の露出や不要なデータ返却が心配
ただし、画面が1つで既存APIと同じ要求しか送らない小規模なシステムでは、API Gatewayや単純なバックエンドで足りる場合があります。Microsoft Learnも、単一インターフェースの場合や、GraphQLの専用リゾルバーで足りる場合には、BFFを追加しない選択肢を示しています。
BFFのシステム開発の発注形態
BFFの外注では、丸投げできる相手を探すより、発注者が業務目的と受け入れ条件を持つ形のほうが安定します。また、開発会社は設計・実装・運用を支援します。
適した発注形態は、要件の確定度と社内の技術責任者の有無で変わります。既存APIの複雑さや、リリース後の保守担当も関係します。
PoC・MVPから始める発注が向いている企業
初めての導入でAPIの品質が不明な場合は、代表的な1〜2画面に絞ってPoCで検証します。PoCでは、通信と表示、認証と障害の2点を確かめ、その結果を本開発の判断に使える成果物として受け取ります。
- 通信と表示：商品一覧と注文履歴での通信回数と表示時間
- 認証と障害：認証エラーや下流サービス停止時の表示
- 成果物：API契約、性能測定結果、未解決課題、本番化の追加見積もりを受け取る
検証結果は、次の本開発を判断する材料になります。そのため、最初から全社横断の大規模契約を結ぶより、リスクを抑えやすくなります。
一括請負・準委任・内製支援の使い分け
発注形態は、要件の確定度と社内体制に合わせて使い分けます。
- 一括請負：機能と受け入れ条件を先に確定できる場合に候補となる
- 準委任：API仕様が不明、要件を段階的に固める、技術検証で方針が変わる場合に合う
- 内製化支援：社内にプロダクト責任者がいて、外部エンジニアをチームに迎える場合に選べる
発注を分ける方式もあります。たとえば、要件整理とPoCは準委任、本番機能は請負、運用改善は月次の準委任とする形です。
発注者と開発会社の責任分界
責任分界は、契約書のほか、RFPや要件定義書・基本設計書・運用設計書にも記載します。発注者は業務ルールと優先順位を決め、既存APIの所有者と調整したうえで、受け入れを判断します。
受託会社は、BFFの設計と実装、テスト、デプロイ手順、障害時の一次切り分けを担う形が一例です。API Gateway・認証基盤・WAF・監視と、下流サービスの障害対応も、担当を分けます。
分界が曖昧だと、障害時にBFFと基幹APIのどちらに原因があるかを調べるだけで時間がかかります。加えて、保守費用も予測しにくくなります。
BFFの外注で使えるRFPと要件整理の進め方
RFPに「APIを作る」とだけ書くと、各社の見積範囲が食い違い、提案を比べられません。画面と業務データ、必要な条件を示したうえで、BFFに含めない処理も明記します。
AWS Prescriptive Guidanceは、BFFを業務ドメインモデルではなく、フロントエンド側のAPI層として説明しています。その層は、認証、集約、データ変換を担います（出典: AWS Prescriptive Guidance「API integration – Backend for frontend」、2026年8月確認）。
RFPに入れる情報
RFPでは、提案の前提をそろえるため、対象とシステムの情報を整理します。
- 対象：背景、目的、ユーザー、フロントエンド、画面
- 現行環境：システム構成、既存API、認証方式、個人情報・決済情報の有無
- 前提：ピーク時のアクセス想定と希望納期
API一覧には、エンドポイントに加えて、入力・返却項目、エラーコード、レート制限を記載します。所有部署やSLA、変更予定も、分かる範囲で添付します。
既存APIを変更できるか、新規APIを追加できるかといった点や、下流APIの障害時に画面へ何を返すかは、見積もりに差が出やすい項目です。
非機能要件には、通常時・ピーク時の応答目標、同時接続数、稼働時間を記載します。障害検知時間とログ保存期間も盛り込みます。また、監査ログの改ざん防止・バックアップ・脆弱性診断・デプロイ頻度も含めます。
数値を決められない項目は、提案会社に候補値を出してもらうと明記します。そうすると、各社が同じ前提で見積もれます。
BFFに入れる処理と業務サービスに残す処理の分け方
BFFと業務サービスの責務は、画面専用の処理か、複数画面で共有する業務ルールかで分けます。
- BFF：表示項目の変換、API集約、ページング、表示順の調整、画面固有のセッション管理
- ドメインサービス：注文確定、与信、在庫引当、価格計算、権限の最終判断
業務ルールをBFFに入れると、別のチャネルで再利用できなくなります。そうなると、同じルールを後から複製することになります。
RFPには両者の責務を文章で示し、提案会社には境界図を求めます。そのうえで、注文APIの前に金額を再計算しない、在庫数を独自に保持しない、認可の最終判定は下流でも行うといったルールも記載します。
BFFはフロントエンドチーム、業務ルールはドメインサービスチームが所有するなど、リリース判断の窓口も決めておくと、運用が安定します。
認証・個人情報・障害時の要件の指定範囲
BFFで認証情報を扱う場合は、安全性を一つずつ確かめる必要があります。そのため、RFPでは認証方式ごとの要件と、API保護策を具体化します。
- Cookieセッション：CSRF、SameSite、セッション固定化、期限、ログアウト
- トークン：保管場所、更新、失効、スコープ
- API保護：オブジェクト単位の認可、レート制限、入力検証、SSRF対策
- 個人情報：ログへのマスキング処理
OWASP API Security Top 10 2023では、認可関連のリスクが上位に複数含まれています。また、SSRFもリスクとして追加されています（出典: OWASP API Security Top 10 2023、2026年8月確認）。
会員情報や購入履歴を扱う場合は、委託契約と監査の方法も決めておきます。
個人情報保護委員会のガイドラインは、委託先の安全管理措置が委託元に求められる水準と同等かを事前に確かめるよう示しています。さらに、再委託先を含む取扱状況も把握するとしています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。
契約と運用手順では、アクセス権や保存場所、削除期限を定めます。事故時の報告時間や再委託の事前承認も、そこに含めます。
BFFのシステム開発で選ぶ契約形態と契約書のポイント
契約では、開発費のほかに、仕様変更・成果物の権利・保守への移行・障害対応の範囲を確認します。納品時にコードを受け取る形だけで済ませると、引き継ぎは不十分になります。リポジトリやCI/CD、IaCを成果物として納めるかを決めます。次に、API仕様・テストコード・監視設定・運用手順の扱いも決めます。
請負契約の検収基準
請負契約では、機能一覧だけでなく、受け入れできる状態を検収基準にします。画面ごとに、求める動作を明確にします。
- 画面の応答：正常系・異常系、返却項目、エラーコード、認証失敗時の応答
- 実行条件：タイムアウト時の動作、対応ブラウザ・OS、負荷試験の条件
- 品質基準：重大な脆弱性が残っていないこと
性能は「改善する」と書くのではなく、指定負荷における95パーセンタイルの応答時間を目標値以内に収めると定義します。
計測方法と測定環境も合意しておきます。既存APIの仕様や対象画面、認証方式、ピークアクセス数が変わる場合の協議手順も必要です。
変更をすべて無償にすると、受託会社はリスクを価格に上乗せします。一方で、すべて有償にすると、発注者が改善しにくくなります。そこで、変更管理票で、影響範囲や追加工数、納期変更、承認者をそろえます。
準委任契約で管理する成果
準委任契約では、完成機能を保証するよりも、合意した業務を適切に進めることが中心になります。管理する項目は、契約時にそろえておきます。
- 体制：月間稼働時間、担当者、会議体、窓口、承認経路
- 作業管理：設計・コードレビュー、テスト、課題管理
- 進行管理：リスク報告、検討事項、発注者の意思決定期限
要件が変わる案件でも、検討事項と発注者の判断時期を見える化しておけば、作業のブラックボックス化を防げます。
発注者が受託会社の個人に直接指揮命令する状態には、注意が必要です。そのため、チームの役割や窓口、承認経路を整理し、法務・購買部門にも確認します。
契約更新や担当者変更、再委託のほか、機密情報や情報セキュリティも事前に決めます。成果物の利用権と終了時の引き継ぎも、同じ時点で決めておきます。そのため、担当者の交代や内製化の際にも、業務を続けやすくなります。
ソースコード・IaC・API仕様の帰属
発注前に、成果物と引き継ぎの条件を契約で定めます。
- 開発成果物：ソース・テストコード、API定義、設計書、コンテナ定義、TerraformなどのIaC
- 運用成果物：パイプライン、監視ダッシュボード、ログ設定
納品先は、発注者のリポジトリにするか、受託会社から移管するかを決めます。また、第三者ライブラリやクラウド設定の利用条件、著作権・著作者人格権、共通部品の再利用範囲は、契約前に法務と確認します。
引き継ぎは説明会だけで終えず、発注者の環境でデプロイとロールバックができる状態を受け入れ条件にします。障害連絡先や一次対応時間、重大度別の復旧目標も、台帳にまとめます。
脆弱性の修正期限やクラウドアカウントの管理者、秘密情報の保管場所も記録します。これらは、初期費用と保守費用を分けて見積もるときにも必要になります。
BFFのシステム開発を外注する費用相場とコストの内訳
BFF単体には、公的な統一価格表がありません。そこで、業務システムの相場情報を基にした、2026年時点の発注検討用の推定レンジを示します。
この推定は、既存APIが整備され、BFFが画面用の集約に限られる前提です。データ移行・基幹刷新・大規模な外部SaaS連携・24時間運用を含む場合は、BFFの開発費だけで判断せず、別途見積もります。
規模別の初期開発費の目安
BFFの規模は、画面の数に加えて、連携する業務サービスの数と運用の要件で段階が分かれます。4つの段階ごとに、含まれる作業と推定費用の幅を示します。
- PoC・MVP：1フロント、5〜10エンドポイント、既存API接続、基本認証、最低限のテストで300万〜600万円
- 小規模本番：Webまたはアプリ向けBFF、API集約、認証認可、CI/CD、監視・ログ、負荷試験で600万〜1,200万円程度
- 中規模：Webとアプリ、複数ドメインサービス、APIバージョン管理、可用性設計、移行支援で1,200万〜2,500万円程度
- エンタープライズ：複数BFF、基幹・外部SaaS連携、冗長化、監査、DR、24時間運用で2,500万〜6,000万円以上
この数値は、確定した市場統計ではありません。業務システムの相場（小規模300万〜700万円、中規模700万〜1,500万円）に、BFF固有の認証・集約・監視の範囲を合わせた推定です。
既存APIが仕様書どおりに動かない場合や、下流の改修が必要な場合は、費用が上振れします。また、厳しい性能目標や個人情報の監査も、増額の要因になります。
提案書では、費用を分けて示してもらいます。対象は、BFFの実装と周辺基盤、テスト・移行・保守です。
人件費と工数の見積もり方
BFFの見積もりは、画面数だけでなく、API接続数や認証・試験範囲にも左右されます。
- 実装範囲：画面ごとの下流API数、データ変換、認証・認可、エラー分岐
- 検証・運用：テストパターン、運用環境数
リサーチノートの業務システム相場では、PMは月90万〜150万円、SEは月65万〜110万円程度が目安です。この相場は、会社・技術・契約・地域・経験で変わるため、単価だけで比べないことが大切です。
費用は、企画・要件定義・基本設計・API実装、既存APIとの結合に分けます。認証・セキュリティやテストも分けます。加えて、CI/CD・インフラ、リリース支援、文書作成を分けると、比べやすくなります。
人件費が総額の60〜80％程度になるという業務システムの目安もありますが、これはBFF案件の統計ではありません。工数と担当ロールに加えて、成果物とレビュー回数も確認します。
クラウド費用と保守運用費の分け方
運用費は、クラウド利用料と保守運用費に分けて考えます。利用規模ごとの推定額も確認します。
AWS公式料金では、API Gatewayは呼び出し数やデータ転送、Lambdaはリクエスト数と実行時間を中心に課金されます（出典: AWS「Amazon API Gateway Pricing」「AWS Lambda Pricing」、2026年8月確認）。
- 低トラフィック：従量課金を活かしやすく、サーバーレス構成で月1万〜10万円程度
- 中規模：監視・WAF・データベースを含め月10万〜50万円程度
- 高負荷など：集約処理・ログ量が多い、多リージョン・常時稼働で月50万〜200万円以上。コンテナ等も比較
- 保守運用：初期開発費の年間15〜25％程度が業務システムの目安
- 対象費用：API Gateway、実行環境、WAF、ログ、トレース、監視、アラート、バックアップ、脆弱性対応
これらはリサーチノートの概算で、利用量や構成によって変わります。見積もりの条件には、リクエスト数や転送量、ログ保存期間を記載し、環境数と為替も添えます。24時間監視やSLAを含む場合は、保守運用費も別の金額になります。
BFFの委託先選定と見積比較で確認すべきポイント
開発会社は、規模や知名度だけでなく、既存APIを理解して画面単位の要件に変換できるかで選びます。次に、同じRFPを候補の会社に渡します。
各社には、提案範囲や前提、除外事項をそろえて回答してもらいます。担当者・開発方法・テスト・保守体制・見積もりの不確実性も、同じ項目で示してもらいます。ただし、APIやマイクロサービスの実績があっても、同じBFFの経験があるとは限りません。
委託先のBFF実績の確認項目
実績を確かめる際は、「BFFの実績がありますか」に続けて、対象範囲と運用条件まで尋ねます。
- 構成：Web・アプリの別、BFF数、接続したAPIの種類
- 運用：認証方式、ピーク負荷、障害対応、保守担当
- 匿名事例：業種、規模、対象画面、技術、期間、成果物、課題
守秘義務で社名を出せない場合でも、匿名で説明できるかを確認します。提案の段階では担当予定者と面談し、業務ロジックをBFFに入れない判断についても尋ねます。
下流APIが遅い場合のタイムアウトや部分レスポンス、リトライ、重複実行についても質問します。障害時の利用者への影響と復旧手順まで説明できる会社は、発注後の連携も期待できます。
画面一覧だけを示して大きな固定費を提示し、前提や除外事項を説明しない提案では、比較の基礎が不足しています。
見積書を横並びに比べる項目
合計額を見る前に、各社の見積もりに同じ作業が含まれているかを比べます。確かめる範囲は、次の3つです。
- 設計と実装：要件定義、APIの洗い出し、設計、実装
- 検証：単体・契約・結合・負荷テスト、セキュリティ診断
- 運用準備：CI/CD、監視、リリース、操作説明、引き継ぎ
BFFのコードが安くても、API Gatewayや認証基盤、ログ・トレース、環境構築が別料金であれば、本番までの総額は高くなります。
比較表には、初期費用と月額費用、想定人月、単価、期間を並べます。さらに、アクセス数やクラウド費、ライセンス費、保守時間、SLA、追加変更単価も入れます。
各社の金額差が大きい場合は、対象外の範囲を調べます。たとえば、既存API改修を含む会社と、BFFから下流APIを呼ぶだけの会社とでは、同じ開発費でも比べられません。
提案会社への質問によるリスクの見抜き方
提案会社には、設計方針と納品・運用の条件を質問します。
- 設計と障害：BFFを増やし過ぎない方針、API契約、下流障害時の設計
- 情報管理：個人情報のマスキング、脆弱性対応、再委託先
- 引き継ぎ：担当交代、ソースコード、IaCの引き渡し
回答は、回答書・前提一覧・WBS・体制図・リスク一覧として記録してもらいます。口頭の約束は、成果物や作業範囲に反映されなければ、後から確認できません。
既存APIの文書が古い、テスト環境がない、承認に時間がかかる、マスキングが未整備といった問題も、開発会社に正直に伝えます。
問題を隠すと、提案会社は安全を見て大きな予備工数を積むか、受注後に追加費用として提示します。なお、有償の要件定義で事前調査を行うと、本番開発の見積もりの精度が上がる場合があります。
よくある質問
BFFの発注では、技術の選択よりも、適用範囲と費用の前提、委託先との分担をそろえることが重要です。相談の前によく寄せられる質問に、順に答えます。
BFFのシステム開発は何社に見積もりを依頼すべきですか？
まずは同じRFPを3社前後に依頼すると、提案の方向性と費用幅を把握しやすくなります。一方で、候補を増やし過ぎると、質疑応答と評価に時間がかかります。
既存API・クラウド・業界要件・保守体制が合う会社を、事前に絞ります。特にPoCでは、価格だけでなく、検証設計と本番化の見通しを重視します。
BFFを外注すると既存システムを大きく改修する必要がありますか？
既存APIがそのまま使え、BFFを画面用の集約と変換に限る場合は、大規模な改修を伴わずに済むことがあります。基幹システムを残したまま、WebやアプリとBFFを追加できます。
認証・権限・エラー応答・性能・API不足の問題が分かれば、下流APIの改修が必要になります。最初にAPIを洗い出し、代表的な画面でPoCを行います。
BFFの開発後の保守運用も同じ会社へ委託すべきですか？
同じ会社に委託し続ける方法にも、内製へ引き継ぐ方法にも利点があります。BFFと下流APIの構成を深く理解した会社に保守を任せると初動を速めやすい一方、発注者が運用を理解せず依存するリスクがあります。
初期契約の段階から、監視設定・障害対応手順・ソースコード・IaC・テスト環境を発注者が確認できるようにします。そのうえで、月次保守の範囲と内製化・移管の条件も決めておけば、選択肢を残せます。
まとめ
発注前に、Web、アプリ、管理画面ごとの差分と既存APIの課題を整理します。一方で、単一画面・単一APIで足りるなら、BFFを増やさない判断も必要です。
複数APIの集約・画面固有の変換・認証の分離・基幹システムを残した段階導入が必要なら、BFFを候補にします。
RFPには、画面別のAPI一覧や認証、非機能要件を記載します。障害時の挙動、ログ保存、個人情報、コード・IaCの帰属、保守範囲も、あわせて書きます。
費用は、PoC・MVPが300万〜600万円、小規模本番が600万〜1,200万円です。中規模は1,200万〜2,500万円、エンタープライズは2,500万〜6,000万円以上です。
既存APIの品質と下流改修、セキュリティ・可用性・運用体制によって、費用は増減します。見積もりには、その前提を必ず併記します。
請負では検収基準と変更管理、準委任では作業範囲と責任者を明確にします。どちらの契約でも、成果物・引き継ぎ・脆弱性対応・SLA・再委託・個人情報の監督を確認します。
見積比較では、合計金額ではなく、設計・実装・テスト・基盤・保守が同じ範囲で含まれているかを見比べます。
▼全体ガイドの記事
・BFFのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。