BFFのシステム開発の発注/外注/依頼/委託方法について

BFFのシステム開発を発注・外注するなら、画面専用のAPI集約層だけを作るのではなく、既存システムとの責任分界、認証・監視、保守範囲まで決めてから委託することが重要です。適切な要件整理と契約を先に行えば、Webやスマートフォンアプリを追加しながら、基幹システムへの影響を抑えやすくなります。

本記事では、BFFのシステムを発注・外注する際の進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積比較のポイントに分けて解説します。BFFを導入しないほうがよいケースや、発注後に費用が膨らみやすい落とし穴も扱うため、自社でどこまで準備してから相談すべきか判断できます。

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

BFFのシステムを発注する前に知っておきたい全体像

BFFはBackend for Frontendの略で、Web、スマートフォンアプリ、管理画面などのフロントエンドごとに用意する専用バックエンドです。商品、在庫、会員、注文など複数の業務APIを呼び出し、画面が必要とするデータにまとめて返す役割を担います。Microsoft Learnも、複数の画面に一つの汎用バックエンドを使い続ける代わりに、画面ごとの要件に合わせたバックエンドを配置するパターンとして説明しています（出典: Microsoft Learn「Backends for Frontends pattern」、2026年8月確認）とされています。

既存バックエンドやドメインサービスは、注文確定、与信、在庫引当など業務上の中核ルールを管理します。一方、BFFは画面に近い場所で複数APIの呼び出し、データ形式の変換、画面固有の認証処理を担います。API Gatewayは認証、ルーティング、レート制限、共通ログなどを受け持つことが多く、BFFの画面用集約とは役割が異なります。発注時にこの分担を書面化しないと、BFFに業務ロジックが入り込み、画面ごとに異なる注文ルールが生まれるため注意が必要です。

Webとアプリで必要なデータ形式が違う場合、複数の業務APIを一画面で組み合わせる場合、既存APIを変えずに新しいフロントエンドを追加したい場合は、BFFの価値が高くなります。画面から社内APIを直接呼び出しており、認証情報の露出や不要なデータ返却が心配な場合も候補になります。反対に、利用する画面が一つだけで、既存APIと同じ要求しか送らない小規模システムでは、API Gatewayや単純なバックエンドだけで十分なことがあります。Microsoft Learnも、単一インターフェースの場合やGraphQLのフロントエンド専用リゾルバーで足りる場合は、BFFを追加しない選択肢を示しています。

BFFのシステム開発はどの発注形態で外注すべきですか？

BFFの外注では、丸投げできる会社を探すより、発注者が業務の目的と受け入れ条件を持ち、開発会社が設計・実装・運用を支援する形が安定します。要件の確定度、社内に技術責任者がいるか、既存APIの複雑さ、リリース後の保守を誰が担うかによって、適した発注形態は変わります。

初めてBFFを導入する企業や、既存APIの品質が分からない企業は、代表的な1〜2画面に絞ったPoC・MVP発注が向いています。例えば、商品一覧と注文履歴だけを対象に、API集約による通信回数、画面表示までの時間、認証エラー、下流サービス停止時の表示を検証します。PoCの成果物にはソースコードだけでなく、API契約、性能測定結果、未解決課題、本番化の追加見積もりを含めてもらいます。検証結果を次の本開発の判断材料にできるため、最初から全社横断の大規模契約を結ぶよりリスクを抑えやすくなります。

完成する機能と受け入れ条件を先に確定できる場合は、成果物、納期、検収基準を合意しやすい一括請負が候補になります。ただし、既存APIの仕様が不明、段階的に画面要件を固める、技術検証で方針が変わる場合は、作業時間と役割を合意する準委任のほうが実態に合います。社内にプロダクト責任者がいて、開発会社のエンジニアをチームへ迎えるなら、準委任や内製化支援も選択肢です。実務では、要件整理とPoCを準委任、本番リリース対象の機能を請負、運用改善を月次準委任と分ける方式もあります。

契約書だけでなく、RFP、要件定義書、基本設計書、運用設計書に責任分界を落とします。発注者は業務ルール、優先順位、既存APIの所有者との調整、受け入れ判断を担い、受託会社はBFFの設計、実装、テスト、デプロイ手順、障害時の一次切り分けを担う、といった書き方です。API Gateway、認証基盤、WAF、監視、下流サービスの障害は誰が対応するかも分けます。責任分界が曖昧なままでは、障害発生時に「BFFの不具合か、基幹APIの遅延か」を調査するだけで時間がかかり、保守費用も予測できなくなります。

BFFの外注で使えるRFPと要件整理の進め方

BFFのRFPでは、単に「APIを作る」と書くと各社が異なる範囲を見積もるため、比較できる提案になりません。どのフロントエンドの、どの画面が、どの業務データを、どの条件で必要とするのかを示し、BFFの内側に置かない処理も明記します。AWS Prescriptive Guidanceでも、BFFはドメインモデルを持つ業務サービスではなく、フロントエンドに属するAPI層として、認証、集約、データ変換を担う考え方が示されています（出典: AWS Prescriptive Guidance「API integration – Backend for frontend」、2026年8月確認）とされています。

RFPには、背景と目的、対象ユーザー、対象フロントエンド、対象画面、現行システム構成、既存API一覧、認証方式、個人情報・決済情報の有無、ピーク時のアクセス想定、希望納期を入れます。API一覧はエンドポイント名だけでなく、入力項目、返却項目、エラーコード、レート制限、所有部署、SLA、変更予定まで分かる範囲で添付します。特に「既存APIを変更できるか」「BFFから新規APIを追加してよいか」「下流APIの障害時に画面へ何を返すか」は見積差が出やすい項目です。

非機能要件も最低限そろえます。例えば、通常時とピーク時のレスポンスタイム目標、同時接続数、稼働時間、障害検知時間、ログ保存期間、監査ログの改ざん防止、バックアップ、脆弱性診断、デプロイ頻度を記載します。数値を決められない場合は、候補値を提案会社から出してもらう項目として明示し、各社が同じ前提で見積もれるようにします。

画面表示用の項目変換、複数APIの集約、ページング、表示用の並べ替え、フロントエンド固有のセッション管理はBFFの候補です。注文確定、与信判定、在庫引当、価格計算、権限の最終判断など、複数画面から利用される業務ルールはドメインサービス側に残します。BFFに業務ルールを入れると、その画面では正しくても別のチャネルで再利用できず、後から同じルールを複製することになります。

RFPでは「BFFの責務」と「業務サービスの責務」を文章で示し、提案会社には境界を図で返してもらいます。例えば、BFFが注文APIを呼び出す前に金額を再計算しない、在庫数を独自に保持しない、認可の最終判定は下流サービスでも行う、というルールです。担当チームも、BFFはフロントエンドチーム、業務ルールはドメインサービスチームが所有するなど、リリース判断の窓口まで決めると運用が安定します。

ブラウザやアプリから社内APIを直接呼ばず、BFFで認証情報を扱う構成を採る場合でも、BFFが安全になるとは限りません。Cookieセッションを使うならCSRF、SameSite、セッション固定化、期限、ログアウトを定義し、トークンを使うなら保管場所、更新、失効、スコープを決めます。オブジェクト単位の認可、レート制限、入力値検証、SSRF対策、ログへの個人情報マスキングもRFPの確認項目です。OWASP API Security Top 10 2023では、認可に関係するリスクが上位に複数含まれ、SSRFもリスクとして追加されています（出典: OWASP API Security Top 10 2023、2026年8月確認）と報告されています。

会員情報や購入履歴を扱う場合は、開発会社の選定だけでなく委託契約と監査方法まで決めます。個人情報保護委員会のガイドラインでは、委託先の安全管理措置が委託元に求められる水準と同等かをあらかじめ確認し、再委託先も含めて取扱状況を把握する考え方が示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）とされています。アクセス権、保存場所、削除期限、事故時の報告時間、再委託の事前承認を契約と運用手順に落とします。

BFFのシステム開発で選ぶ契約形態と契約書のポイント

BFF開発の契約では、開発費の安さだけでなく、仕様変更、成果物の権利、保守移行、障害対応の範囲を確認します。BFFはアプリやWebのリリースと密接に関係するため、納品日にコードが渡されるだけでは不十分です。リポジトリ、CI/CD、IaC、API仕様、テストコード、監視設定、運用手順まで、何を成果物とするかを明確にします。

請負契約では、機能一覧だけでなく、受け入れ可能な状態を検収基準にします。画面ごとの正常系・異常系、返却データの項目、エラーコード、認証失敗時の応答、タイムアウト時の動作、対応ブラウザやOS、負荷試験の条件、重大な脆弱性が残っていないことなどです。例えば「性能を改善する」ではなく、「指定した負荷条件で95パーセンタイルの応答時間を目標値以内にする」と定義し、計測方法と測定環境も合意します。

仕様変更の扱いも必須です。既存APIの仕様変更、対象画面の追加、認証方式の変更、ピークアクセス数の増加など、見積前提が崩れた場合の協議手順を決めます。変更をすべて無償対応にすると受託会社がリスクを価格へ上乗せし、すべて有償にすると発注者が改善しにくくなります。変更管理票、影響範囲、追加工数、納期変更、承認者をそろえる運用が現実的です。

準委任契約では、完成機能の保証ではなく、合意した業務を適切に遂行することが中心になります。そのため、月間の稼働時間だけでなく、担当者、会議体、設計レビュー、コードレビュー、テスト実施、課題管理、リスク報告、意思決定の期限を定義します。要件が変わるプロジェクトでも、何をいつまでに検討し、どの判断を発注者が行うかが見えるため、作業のブラックボックス化を防げます。

準委任で注意したいのは、発注者が受託会社の個人へ直接指揮命令する状態です。チームの役割、窓口、承認経路を整理し、法務・購買部門にも確認します。契約期間の更新条件、担当者変更、再委託、機密情報、情報セキュリティ、成果物の利用権、契約終了時の引き継ぎを事前に決めておくと、担当者の交代や内製化へ移るときも継続しやすくなります。

発注前に、ソースコード、テストコード、API定義、設計書、コンテナ定義、TerraformなどのIaC、パイプライン設定、監視ダッシュボード、ログ設定を成果物として列挙します。納品先を発注者のリポジトリにするか、受託会社のリポジトリから移管するかも決めます。第三者ライブラリやクラウド設定の利用条件、著作権・著作者人格権の扱い、再利用可能な共通部品の範囲については、契約締結前に法務と確認します。

引き継ぎでは、担当者による説明会を一度行うだけにせず、発注者の環境でデプロイとロールバックを実行できる状態を受け入れ条件にします。障害時の連絡先、一次対応時間、重大度別の復旧目標、脆弱性が発見された場合の修正期限、クラウドアカウントの管理者、秘密情報の保管場所を台帳化します。これらは初期費用と保守費用を分けて見積もるためにも必要です。

BFFのシステム開発を外注する費用相場とコストの内訳

BFF単体には公的な統一価格表がないため、以下は業務システム開発の相場情報を基礎に、既存APIが整備され、BFFが画面用の集約に限定される前提で置いた2026年時点の発注検討用の推定レンジです。データ移行、基幹刷新、外部SaaSの大規模連携、24時間運用まで含める場合は、BFFの開発費だけで判断せず、別途見積もりに分けます。

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数、データ変換の複雑さ、認証・認可の種類、エラー時の分岐、テストパターン、運用環境の数で決まります。リサーチノートの業務システム相場では、PMが月90万〜150万円、SEが月65万〜110万円程度の人月単価が目安として挙げられています。ただし、この単価は会社、技術、契約、地域、担当者の経験で変わるため、単価だけで安さを比較しないことが大切です。

費用の内訳は、企画・要件定義、基本設計、BFFのAPI実装、既存APIとの結合、認証・セキュリティ、テスト、CI/CD・インフラ、リリース支援、ドキュメント作成に分けると比較しやすくなります。人件費は総額の60〜80％程度になるという業務システムの目安もありますが、これはBFF案件の統計ではありません。提示された工数と担当ロールを確認し、各工程の成果物とレビュー回数が含まれているかを確かめます。

初期開発後には、クラウド、API Gateway、コンテナまたはサーバーレス実行環境、WAF、ログ、トレース、監視、アラート、バックアップ、脆弱性対応の費用が発生します。AWS公式料金では、Amazon API GatewayはAPI呼び出し数やデータ転送、AWS Lambdaはリクエスト数と実行時間を中心に課金されます。したがって低トラフィックでは従量課金を活かしやすい一方、集約処理が重い、ログ量が多い、常時高負荷、多リージョン構成という条件では、コンテナや専用インスタンスを含めた月額比較が必要です（出典: AWS「Amazon API Gateway Pricing」「AWS Lambda Pricing」、2026年8月確認）と確認できます。

リサーチノートでは、クラウド運用費を低トラフィックのサーバーレス構成で月1万〜10万円程度、中規模で監視・WAF・データベースなどを含め月10万〜50万円程度、高負荷・多リージョン・常時稼働で月50万〜200万円以上とする概算が示されています。これは利用量や構成で大きく変わる推定であり、見積書ではリクエスト数、データ転送量、ログ保存期間、環境数、為替を前提条件として記載してもらいます。保守運用費は、業務システムの目安として初期開発費の年間15〜25％程度が挙げられますが、24時間監視やSLAを含む場合は別の金額になります。

BFFの委託先選定と見積比較で確認すべきポイント

BFFの開発会社は、会社規模や知名度だけでなく、既存APIを理解して画面単位の要件へ変換できるかで選びます。候補会社には同じRFPを渡し、提案範囲、前提条件、除外事項、担当者、開発方法、テスト方針、保守体制、見積の不確実性をそろえて回答してもらいます。公開されたAPIやマイクロサービスの実績があっても、自社と同じBFF実装を経験したとは限らないため、提案時に実装範囲を具体的に確認します。

「BFFの実績がありますか」という質問だけでは不十分です。Webとアプリのどちらに何個のBFFを作ったか、下流に何種類のAPIを接続したか、認証方式は何か、ピーク時の負荷条件、障害対応、リリース後の保守を誰が行ったかを聞きます。守秘義務で社名を出せない場合でも、業種、規模、対象画面、技術構成、期間、成果物、苦労した点を匿名で説明できるか確認します。

提案段階では、担当予定者と面談し、BFFに業務ロジックを入れない判断、下流APIが遅いときのタイムアウト、部分レスポンス、リトライ、重複実行の扱いを質問します。技術用語を並べるだけでなく、障害時の利用者影響と復旧手順まで説明できる会社は、発注後のコミュニケーションも期待しやすくなります。反対に、画面一覧だけで大きな固定費を提示し、前提条件や除外事項を説明しない提案は比較の基礎が不足しています。

見積比較では、合計額を先に比べず、同じ作業が含まれているかを確認します。要件定義、API棚卸し、設計、実装、単体テスト、契約テスト、結合テスト、負荷試験、セキュリティ診断、CI/CD、監視、リリース、操作説明、引き継ぎを項目化します。BFFのコードだけが安くても、API Gatewayや認証基盤、ログ・トレース、環境構築が別料金なら本番までの総額は高くなります。

比較表には、初期費用と月額費用、想定人月、単価、期間、前提アクセス数、クラウド費、ライセンス費、保守対応時間、SLA、追加変更単価を並べます。各社の金額差が大きい場合は、安い会社へすぐ決めず、対象外になっている範囲を確認します。例えば、ある会社は既存APIの改修を含み、別の会社はBFFから下流APIを呼ぶだけという違いがあれば、同じ「BFF開発費」でも比較できません。

候補会社には、BFFを増やし過ぎない設計方針、API契約の管理方法、下流サービス障害時の設計、ログの個人情報マスキング、脆弱性対応、再委託先、担当者の交代、ソースコードとIaCの引き渡しを質問します。回答を聞くだけでなく、RFPへの回答書、前提一覧、WBS、体制図、リスク一覧として残してもらいます。口頭で「対応します」と言われた内容は、契約の成果物や作業範囲に反映されなければ、後から確認できません。

また、開発会社に現状の問題を正直に伝えることも重要です。既存APIのドキュメントが古い、テスト環境がない、業務部門の承認に時間がかかる、データのマスキングが未整備といった情報を隠すと、提案会社は安全側に大きな予備工数を積むか、受注後に追加費用として提示します。事前調査を有償の要件定義フェーズとして発注するほうが、結果的に本番開発の見積精度を上げられる場合があります。

よくある質問

BFFの発注では、技術の選択よりも、適用範囲、費用の前提、委託先との分担をそろえることが重要です。ここでは、相談前によく寄せられる質問に直接回答します。

まずは同じRFPを3社前後に依頼すると、提案の方向性と費用の幅を把握しやすくなります。会社数を増やし過ぎると、発注者側の質疑応答と評価に時間がかかるため、既存API、クラウド、業界要件、保守体制が合う候補を事前に絞ります。PoCの段階では、価格だけでなく検証設計と本番化の見通しを重視します。

必ずしも大規模改修になるとは限りません。既存APIが利用でき、BFFを画面用の集約と変換に限定できれば、既存の基幹システムを残して新しいWebやアプリを追加できます。ただし、認証、権限、エラー応答、性能、APIの不足が見つかると、下流APIの改修が必要になるため、最初にAPI棚卸しと代表画面のPoCを行います。

同じ会社へ委託する方法にも、内製へ引き継ぐ方法にも利点があります。BFFと下流APIの構成を深く理解した会社に保守を任せると初動を速めやすい一方、発注者が運用を理解しないまま依存するリスクがあります。初期契約の段階から、監視設定、障害対応手順、ソースコード、IaC、テスト環境を発注者が確認できる状態にし、月次保守の範囲と内製化・移管の条件を決めておくと選択肢を残せます。

まとめ

BFFのシステムを発注・外注する際は、まずWeb、アプリ、管理画面などのフロントエンドごとの差分と、既存APIの課題を整理します。単一画面・単一APIで十分な場合はBFFを増やさず、複数APIの集約、画面固有のデータ変換、認証の分離、既存基幹を残した段階導入が必要な場合にBFFを候補にします。

発注前には、画面別API一覧、認証方式、非機能要件、障害時の挙動、ログ保存、個人情報の扱い、ソースコード・IaCの帰属、保守範囲をRFPへ落とします。費用はPoC・MVPで300万〜600万円、小規模本番で600万〜1,200万円、中規模で1,200万〜2,500万円、エンタープライズで2,500万〜6,000万円以上という推定レンジを基準にし、既存APIの品質、下流改修、セキュリティ、可用性、運用体制で増減する前提を必ず併記します。

契約では、請負なら検収基準と変更管理、準委任なら作業範囲と責任者を明確にし、どちらでも成果物、引き継ぎ、脆弱性対応、SLA、再委託、個人情報の監督を確認します。見積比較では合計金額ではなく、設計・実装・テスト・基盤・保守が同じ範囲で含まれているかを見比べることが、発注後の予算超過とベンダーロックインを防ぐポイントです。

▼全体ガイドの記事
・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を創業。