BFFのシステム開発の見積相場や費用/コスト/値段について

BFFのシステム開発費は、開発範囲、接続先APIの品質、運用要件によって大きく変わります。推定額は300万円から6,000万円以上までの幅があり、規模が大きくなるほど高くなります。

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

BFFの役割と費用が発生する理由

共通の境界機能と画面固有の処理を分けて捉えられます。

BFFはBackend for Frontendの略で、画面ごとに用意する専用のバックエンドです。

Webやアプリと業務サービスの間に置かれ、API呼び出しとデータ整形を担います。加えて、認証・認可やキャッシュも受け持ちます。

Microsoft Learn「フロントエンド向けバックエンドパターン」（2025年更新）は、複数画面の要求を共通のバックエンドに集めない方式を説明しています。そこでは、画面別に調整した専用のBFFを配置します。

BFF開発で費用がかかる作業

BFFの費用には、画面データの集約・変換の設計も関わります。

API接続：商品、在庫、会員、注文の4サービスを呼ぶ場合は、各APIの仕様確認が必要
エラー対応：タイムアウト、リトライ、ログの扱いの設計
セキュリティ：OAuthトークンをブラウザに直接持たせない方式、Cookieセッション、CSRF対策、個人情報のマスキング

特に、セキュリティ対策を採用すると、検証の工数も増えます。

API Gatewayとの役割の違い

API GatewayとBFFは、担当する範囲が違います。

API Gateway：認証、ルーティング、レート制限など共通の境界機能
BFF：画面向けデータの集約・変換、認可を担い、ドメインサービスとは共有しない

役割を混同すると、画面の処理をGatewayに詰め込んだり、BFFに業務ルールを集めたりしてしまい、将来の改修費が膨らみます。

AWS Prescriptive Guidanceの資料「API integration – Backend for frontend」（2026年8月参照）も参照しています。

BFFを導入しないほうがよい条件

BFFを追加する前に、画面とAPIの構成を見て、既存の仕組みで必要な処理が実現できるかを確かめておきます。

効果が限られる条件：単一画面・単一APIで、Webとアプリの要求や認証もほぼ同じ
代替手段：GraphQLのフロントエンド向けリゾルバーや既存API Gatewayで実現できる場合がある
適用判断：Microsoft Learnは、接続画面が1つ、または各画面の要求が似る場合に不適な可能性を挙げる

導入費と、サービスが増えることによるデプロイ、監視、脆弱性・障害対応の負担を比べて判断します。

BFFのシステム開発の進め方と各工程の費用

BFFの見積もりは、エンドポイント数だけでなく、画面、接続先、認証方式を基準に工程ごとに組み立てます。

障害要件、環境数、テスト範囲も、工程ごとに分けて見積もります。

PoCでも、代表画面やAPI契約が曖昧なまま実装を始めると、仕様変更が起きやすくなります。そのため、初期の定義に費用をかけておくと、手戻りを抑えられます。

要件定義・企画フェーズで決める事項

要件定義では、対象画面とAPIの情報を整理して、見積もりの条件を揃えておきます。

画面要件：データ、更新操作、権限、ピーク時アクセス数、目標レスポンスタイム
既存API：仕様書、所有部署、SLA、レート制限、エラーコード、個人情報の有無
処理の分担：注文確定や与信はドメインサービスに残し、BFFの処理と分ける
RFP：画面別API一覧、認証方式、非機能要件、ログ保存期間、障害通知先、コード・IaCの帰属、保守範囲

対象画面には、Web、スマートフォンアプリ、管理画面などがあります。

RFPの前提が決まらないまま一式見積もりを頼むと、各社の条件がずれ、金額を比べられなくなります。

小規模な案件でも、代表的な1〜2画面を選んでPoCの対象を固定しておきます。

設計・実装フェーズで発生する工数

設計と実装では、画面の表示や更新時の動作、既存APIとの接続条件を決めていきます。

画面応答：レスポンス形式、ページング、キャッシュ期間、部分レスポンス
障害制御：タイムアウト、リトライ、サーキットブレーカー、遅延時の全体制御
処理配置：画面向け変換はBFF、価格計算や与信判定はドメインサービス
実装条件：APIの認証・形式、外部SaaSの安定性、維持するバージョン数
技術選択：Node.js、TypeScript、Java、Goをチームや環境、監査要件に合わせる

複数APIを並列に呼び出すと表示を速めやすい一方で、1つが遅れたときに備えて全体のタイムアウトも考えます。さらに、更新系の処理では、同じ処理が重複して実行されないようにします。

テスト・リリースフェーズの作業範囲

BFFは複数サービスの失敗を受けるため、単体テストだけでは足りません。

契約・結合：BFFと呼び出し先APIの契約、結合の確認
認証・負荷：権限、負荷、タイムアウト、障害注入の検証
情報保護：個人情報を含むログや内部URL、スタックトレースの漏えい有無

LINE ENGINEERINGの2023年の記事では、WebとBFFのサーバーを分離しています（「出前館Webリプレイスで直面した技術的課題と解決」）。

出前館の事例では、負荷調整、デプロイ、ロールバックも分けて扱っています。

分離で柔軟性が増す一方、環境や監視、障害対応の対象も増えます。そのため、分離に伴う設計とテストは見積もりに入れます。

BFFのシステム開発費用・コストの内訳

実装以外にも設計や運用引き継ぎが費用を形づくります。

初期費用には、コードだけでなく要件定義と設計も含まれます。

初期費用では、クラウド基盤と認証、監視の費用も必要です。

テストとプロジェクト管理も含めます。

業務システムの一般的な目安では、人件費が総額の60〜80％程度です。

人件費の割合は、BFF単体の公的な価格表ではなく、既存APIを使う業務システム開発から置き換えた推定です。

要件定義・アーキテクチャ設計の費用

設計費を見積もるには、まず設計の対象を確かめます。

設計対象：画面、API、データフロー、認証、権限、非機能要件、障害時動作、運用分界
既存API：仕様書が古い場合は、実際のレスポンスやエラーを調べる
構成方式：Webのみ、Webとアプリ別、共通BFFのいずれかで設計量が変わる
PoC範囲：1〜2画面で集約効果、応答時間、認証、障害時表示を確かめる

設計は省かず、PoCの範囲を絞って先に確認し、そのあとで本番の範囲を決めます。そうすれば、不要なエンドポイントや過剰なインフラを先に作らずに済みます。

BFF本体の実装・API接続費用

BFF本体の実装では、画面向けの処理と接続方式を決めておきます。

基本機能：API集約、データ変換、ページング、キャッシュ、入力検証、エラー変換、認証・認可
接続範囲：複数ドメインの更新、外部決済、ファイル連携、旧アプリ対応
アプリ互換：旧版と新版の差の吸収、バージョン維持期間の見積条件への記載

実装工数は、エンドポイント数だけでは判断できません。ただし、既存APIを呼ぶ5〜10エンドポイント程度なら、小さく始められます。

複数ドメインの更新や外部連携が加わると、実装とテストの工数が増えます。

スマートフォンの利用者が全員同じアプリ版へ移るとは限りません。そのため、LINEヤフー Tech Blog（2025年）のYahoo!フリマ記事は、BFFが旧版と新版の差を吸収すると説明しています。

Yahoo!フリマの記事は、使われなくなった分岐が技術的負債になりやすい点も説明しています。

インフラ・セキュリティ・テストの費用

本番運用には、開発・検証・本番環境、ネットワーク、シークレット管理を用意します。加えて、WAFとAPI Gatewayを置き、ログとメトリクスの収集も整えます。

運用基盤：分散トレース、CI/CD、バックアップ、アラートの整備
情報保護：個人・決済情報に応じた、アクセス制御、ログマスキング、診断、監査証跡、委託先管理
可用性：24時間SLA、冗長化、災害復旧、複数リージョンまで求めると基盤・検証費が増える
見積項目：「開発費一式」ではなく、アプリ実装、クラウド初期構築、セキュリティレビューに分けて示す
試験・支援：負荷試験、監視設計、リリース支援を、見積書で別項目にする

要件によっては、BFFのコード量以上に基盤・検証費用が増えます。そのため、内訳を分けておくと、初期に必要な項目と後から追加できる項目を見分けられます。

プロジェクト管理・移行・保守引き継ぎの費用

複数部署が所有するAPIを接続すると、調整や保守引き継ぎの費用も発生します。

調整管理：API仕様確認、レビュー、リリース調整、障害時の連絡体制
移行作業：API改修、データ移行、段階リリース、旧システムとの並行稼働
納品後の保守：ライブラリ更新、脆弱性・API変更対応、ログ監視、障害一次対応、月次報告の定義

既存の業務サービスを残したまま画面を刷新する場合は、連携先との調整費を別に計上します。

保守運用費は初期開発費の年間15〜25％程度が目安で、24時間監視、SLA、オンコール、クラウド費をどこまで含むかで変わります。

保守費が含まれない見積もりでは、運用の負担が発注者側に移る場合があります。

ポイント

費用を比べるときは、初期費用と保守運用費を内訳に分けて見ます。内訳があれば、初期に必要な項目と後から追加できる項目を見分けられます。

BFFのシステム開発費用の規模別相場

対象規模が上がるにつれて費用と期間のレンジも広がります。

下の金額は、リサーチノートにある2026年時点の業務システム相場をもとにした推定です。BFF単体の公的統計ではなく、既存APIを利用し、画面用の集約・変換に限った前提で見積もっています。

データ移行や基幹刷新、フロントエンドの全面改修を含む場合は、この範囲を超える可能性があります。24時間運用を求められる場合も、範囲の見直しが必要になります。

金額と期間は、要件の確定度や体制によっても変わります。

PoC・MVPの目安は300万〜600万円、2〜3か月

PoC・MVPでは、既存APIを使う小さな範囲で導入の価値を検証します。

対象：Webまたはアプリの1フロント、5〜10エンドポイント程度
実装：基本認証、画面向け変換、最低限の単体・結合テスト
推定規模：初期費用300万〜600万円、期間2〜3か月
検証項目：通信回数、表示時間、部分表示、チームの所有・運用可否

この目安は、API仕様が確認できて、業務ロジックを新規開発せず、監査や高可用性の要件を限定する前提で出しています。

PoCは安価な本番システムではありません。PoCの目的は検証にあるため、本番要件をすべて実装すると検証の焦点がぼやけ、費用も膨らみます。

小規模本番の目安は600万〜1,200万円、3〜5か月

小規模本番では、WebまたはアプリのBFFを本番環境へ展開します。

本番機能：複数API集約、認証・認可、CI/CD、監視・ログ、基本的な負荷試験
推定規模：初期費用600万〜1,200万円、期間3〜5か月
個人情報：ログのマスキングや権限設計が加わり、同じ画面数でも上限側になりやすい
運用分担：フロントエンドチームが所有し、ドメインサービスとはAPI契約で連携する

API仕様変更の担当を決めておくと、画面を変えるたびに基幹側の調整を待つ状況を減らせます。さらに、運用経験がなければ、初期設計の支援や引き継ぎの費用も見込んでおきます。

中規模の目安は1,200万〜2,500万円、5〜8か月

中規模では、複数のフロントエンドやドメインサービスを対象にして、移行と運用品質も設計に含めます。

対象：複数フロント・ドメイン、API版管理、可用性、段階移行、負荷試験、セキュリティレビュー
推定規模：初期費用1,200万〜2,500万円、期間5〜8か月
複数BFF：共通ライブラリ、認証、ログ・エラー形式、デプロイの標準化

BFFを統合するか分けるかで、共通化と独立デプロイのバランスが変わります。共通化を急ぐと、画面の要件に合わない汎用的な層ができてしまいます。そのため、共通項目と個別項目を分けて考えます。

エンタープライズの目安は2,500万〜6,000万円以上、8〜12か月以上

エンタープライズでは、複数BFFや基幹・外部SaaS連携などを含む可能性があります。

想定要件：冗長化、監査ログ、災害復旧、ゼロトラスト、24時間運用、段階移行
推定規模：初期費用2,500万〜6,000万円以上、期間8〜12か月以上
基盤・運用：API管理・認証基盤、ネットワーク、監視、SRE、障害訓練、運用設計
総保有コスト：実装費だけでなく、教育や契約上の責任分界も含めて全体で評価する

金融、公共、医療などで要求が厳しい場合は、セキュリティ審査や第三者試験の期間も加わります。

基幹刷新やデータ移行は別プロジェクトに分け、依存関係と責任範囲をはっきりさせます。

ポイント

規模ごとの目安は、PoC・MVPの300万〜600万円から、エンタープライズの2,500万〜6,000万円以上まで幅があります。いずれも既存APIを使い、画面用の集約・変換に限った前提の推定です。

BFFの費用が変動する要因とランニングコスト

初期費のほかに、運用後もクラウドや監視、保守の費用が続きます。API変更への対応も、継続してかかる費用です。そのため、初期費用と月額費用を分けて、1年目と2年目以降の合計で見ます。

概算では、低トラフィックのサーバーレス構成が月1万〜10万円程度、中規模が月10万〜50万円程度です。高負荷・多リージョン・常時稼働では、月50万〜200万円以上です。利用量と構成によって変わる推定値です。

既存APIの品質と接続先の数

APIの仕様や接続先が揃っているほど、BFFの見積もりを立てやすくなります。

API形式：RESTで認証、エラー、ページング、データ型が揃うと見積もりやすい
接続方式：古いSOAP、CSV、独自プロトコル、外部SaaS、DB直接参照には変換アダプターや接続試験が必要
画面単位：接続先が3サービスか10サービスかで集約設計が変わる
見積資料：API数、読み取り・更新の別、個人情報の有無を画面一覧に記す

複数サービスを呼ぶ画面では、並列化とタイムアウトを設計します。部分表示とデータ整合性も考える必要があります。また、所有部署が異なり承認に時間がかかる場合は、期間と管理費も増えます。

認証・セキュリティ・可用性の要求

扱う情報と可用性の要求に応じて、セキュリティ設計や基盤費用が変わります。

情報の種類：会員情報と決済・健康情報では認証、ログ、分離、診断要件が異なる
ブラウザ認証：OAuthトークンを露出させないCookieセッション、CSRF、SameSite属性
追加対策：オブジェクト単位の認可、レート制限、SSRF、ログの個人情報マスキング
性能・復旧：ピーク同時実行数、応答時間、復旧目標が費用に影響する
可用性：単一リージョン冗長化と多リージョン切替では、ネットワーク、データ同期、障害訓練が異なる

これらを含めると、設計・実装・テストの工数が増えます。月間アクセス数だけでなく、ピーク時の同時実行数も費用に影響します。許容応答時間や復旧時間目標も、費用を左右する要素です。

SLAには、可用性、復旧・通知の時間、対象外の障害を具体的に書いておきます。

クラウド料金を左右するリクエスト数と実行時間

サーバーレスは、低トラフィックや不規則なアクセスで始めやすい構成です。月額には、実行環境以外の費用も含めて考えます。

月額の内訳：API呼び出し、転送、実行時間、メモリ、ログ、キャッシュ、WAF、DB、監視
AWS API Gateway：呼び出しと転送データが中心で、キャッシュは容量に応じて時間課金
HTTP APIの公開例：月4億3,200万リクエストを段階単価で計算
REST APIの公開例：月500万回、3KB応答の呼び出しと転送を合算

AWS「Amazon API Gateway Pricing」（2026年8月参照）に示された課金例です。実額は、リージョンや無料枠、為替によって変わります。さらに、転送先や採用サービスでも変わります。

見積もりには、想定するリクエスト数と応答サイズを明記しておきます。

保守運用費とBFF特有の負債

BFFは画面の要件に合わせて育っていくため、保守の範囲と運用費も見積もりに含めます。

保守対象：応答形式、API版、旧アプリ対応の分岐が増えると、テストや脆弱性対応も広がる
保守契約：不要コード整理、API契約・依存ライブラリ更新、監視ルール見直しを含める
運用費：監視担当、障害対応、脆弱性診断、負荷試験、リリースレビューも費用に含める
契約範囲：自社と委託先の役割を分け、月額保守費とスポット費を別に提示してもらう

ポイント

費用を左右するのは、既存APIの品質、認証や可用性の要求、クラウドの利用量です。初期費用と月額費用を分けて1年目と2年目以降の合計で比べると、判断の目安をつかみやすくなります。

BFFのシステム開発費を抑える方法

費用を抑えるには、導入効果を検証できる範囲から始めるのが近道です。認証と認可、ログは後付けしにくいため、初期に設計します。安全なエラー応答も、後から直すと手間がかかります。

高可用性や多リージョンは、後から追加できる構成にしておき、コストとリスクを見ながら段階的に投資します。

代表画面に絞ったPoCの開始

全画面を一度にBFF化すると、要件の揺れがそのまま費用に反映されます。そのため、PoCでは代表画面に対象を絞ります。

代表画面：通信回数、API集約効果、既存API変更の影響を基準に選ぶ
検証：1〜2画面で応答時間、通信量、開発サイクル、障害時動作を測る
本番への引き継ぎ：テスト、IaC、ログ、シークレット管理、文書の整備
開始前の合意：引き継ぐコードと破棄するコードの決定

使い捨てのコードとして安く作ると、本番化の際に作り直しが発生し、結果的に二重の費用がかかります。また、対象外の全画面や全APIを一括で開発することは避けます。

クラウド構成とデータ量の計測

費用を抑えやすい構成は、アクセスの特性によって変わります。そのため、初期から利用状況を計測して選びます。

計測項目：1日あたりのリクエスト数、ピーク同時数、平均応答サイズ、実行時間、ログ量
サーバーレス：少量で不規則なアクセスなら始めやすい
コンテナ・インスタンス：常時高負荷で実行時間が長い場合、費用を予測しやすいことがある
AWS Lambda：リクエスト数、実行時間、無料枠、メモリ量が料金に影響する

AWS「AWS Lambda Pricing」（2026年8月参照）に基づく料金条件です。必要な応答項目に絞り、不要なログや重複呼び出しを減らすと、転送量と実行時間も削減できます。

キャッシュは古い情報を返すおそれがあるので、機能ごとに更新の頻度と許容できる鮮度を決めておきます。

複数社の見積もりの比較条件

相見積もりでは会社の数よりも、各社に渡す前提条件を揃えることが大切です。その条件を同じ資料に書いて比べます。

開発範囲：画面一覧、API一覧、認証方式、環境数、テスト範囲
費用内訳：初期費用、クラウド初期構築、月額クラウド費、月額保守費、追加改修単価
提案・運用体制：実装範囲、対象外作業、保守期間、障害対応範囲

金額だけでなく、各社のBFF実装範囲と、含まれない作業も横並びで見ます。

各社の実績や担当者の経験、既存APIや基幹への理解も確認します。加えて、クラウドの選択とセキュリティレビュー、SRE対応を見ておきます。ソースコードとIaCの引き渡し、脆弱性対応の責任分界も、あわせて確かめます。

公開情報だけで得意分野を断定せず、似た構成の開発例や運用中の障害対応を、提案の時点で尋ねておきます。

費用と一緒に決める契約と責任分界

BFFは各チームの境界に置かれるため、契約上の役割と納品の範囲をはっきりさせます。

運用責任：API契約管理、障害の一次切り分け、認証基盤の担当の決定
納品物：ソース、OpenAPI、テスト、IaC、監視画面、運用手順、脆弱性対応期限
個人情報：安全管理措置や委託先管理をRFP・契約・運用に反映する
契約条件：ログ、保存期間、権限、削除依頼、再委託の条件

複数の組織が関わるため、責任が曖昧だと復旧が遅れ、追加費用やセキュリティリスクも大きくなります。

ポイント

費用を抑えるには、代表画面に絞ったPoCから始めるのが目安です。認証、認可、ログは初期に設計し、契約では責任分界を費用と一緒に決めておきます。

BFFのシステム費用に関するよくある質問

見積もりでは、開発費、既存APIによる費用差、運用費などの疑問が出てきます。そこで、発注前の質問には、前提条件を添えて答えます。

BFFのシステム開発は最低いくらから依頼できますか？

既存APIが整備され、1フロント、5〜10エンドポイント、基本認証に限定したPoC・MVPが対象です。代表画面を検証する条件では、推定300万〜600万円、期間2〜3か月が目安です。

ただし、本番運用に必要な監視や冗長化は含まれません。セキュリティ審査と保守も、この金額には入りません。PoC後の本番化費用と引き継ぎ範囲は、あらかじめ確認しておきます。

既存APIがあるならBFFの費用は安くなりますか？

既存APIを使えれば、業務ロジックやDBを新規開発する費用を抑えやすくなります。

ただし、認証やエラー形式がそろっていなかったり、必要な項目が不足していたりすると、変換や接続調整が増えます。レート制限が厳しい場合や、仕様書が古い場合も、手間が増えます。見るべきはAPI数より、必要なデータを安定して取得できる品質です。

BFFのランニングコストは毎月どれくらいかかりますか？

推定概算は、低トラフィックのサーバーレス構成で月1万〜10万円程度、中規模で月10万〜50万円程度です。

高負荷・多リージョン・常時稼働では、月50万〜200万円以上の場合があります。金額は、クラウドや監視、WAFの範囲で変わります。DBやログ、保守体制をどこまで含むかも影響します。

月間リクエスト数、ピーク同時数、転送量を前提として示します。ログ保存期間や監視・障害対応時間も含め、1年分の総額で比べます。

WebとアプリでBFFを分けると費用は増えますか？

サービスの数が増えると、初期実装、デプロイ、監視の対象が増えやすくなります。脆弱性対応やテストの対象も増えます。

Web用とアプリ用のBFFを分けると、リリースや性能を独立して調整でき、長期の変更費を抑えられる場合があります。

Microsoft Learnの指摘も踏まえ、サービスが増えることによる運用負担と、最適化の効果を比べます。その際の観点は、画面数、変更頻度、チーム体制です。

BFFのシステム開発費用相場のまとめ

BFFの開発費は、既存APIの品質と開発範囲で変わります。推定では、PoC・MVPが300万〜600万円、小規模本番が600万〜1,200万円です。

中規模は1,200万〜2,500万円、エンタープライズは2,500万〜6,000万円以上です。どちらも一律の市場価格ではなく、API集約に限った前提での目安です。

見積もり比較の要点

見積もりを比べるときは、費用の内訳と開発の前提条件を揃えます。

費用内訳：初期開発、クラウド初期構築、月額クラウド、保守運用、追加改修
開発条件：画面・エンドポイント数、接続API、認証・認可、個人情報、ピーク負荷
運用品質：SLA、監視、ログ保存期間、テスト範囲の記載
対象範囲：業務ロジックや基幹刷新を含むかどうかと、対象外作業の明確化

代表画面とAPI一覧から始める相談

導入に迷う場合は、全体の開発を発注する前に、代表画面の要件を整理し、既存APIを洗い出すところから始めます。通信回数や画面性能への効果を確かめます。あわせて、認証の安全性やリリース速度も見ます。

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を創業。