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

O2Oシステムの費用は、導入方式、店舗や会員の規模、POS・ECなどとの連携範囲によって決まります。初期費用は30万円程度から1億円超まで幅があります。

方式別の相場、見積もりの内訳、費用が変わる要因を順に説明します。全体像はO2Oシステム開発の完全ガイドもご覧ください。

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

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

O2Oシステムの概要と費用の考え方

O2OはOnline to Offlineの略で、Webサイト、EC、SNS、スマートフォンアプリなどをオンラインの接点として使います。そこから実店舗への来店、予約、購買、再来店へつなげる考え方です。そのため費用も、アプリ単体ではなく、オンラインの行動を店舗の成果として測る仕組み全体で見ます。

O2OとOMOの違いと費用への影響

O2Oはオンラインから店舗への送客を重視します。一方、OMOはオンラインとオフラインを分けず、一貫した顧客体験を設計します。

• O2Oの施策：EC商品の店舗在庫表示、アプリクーポンのPOS利用、店舗検索から来店までの計測。
• OMOの施策：会員、商品、在庫、購買履歴を横断した顧客体験。

送客が目的であれば、会員証、店舗検索、クーポンなどに機能を絞れます。ただし、ECと店舗の在庫共通化や店頭受け取り、パーソナライズまで行うと、OMO基盤に近づきます。そのぶん、連携・データ整備・テストには追加費用がかかります。

O2Oの主な機能（顧客接点・店舗連携・データ活用）

O2Oの機能は、顧客が使う接点、販促・接客、裏側のシステム連携に分けて整理できます。

• 顧客接点：アプリ、Web、LINEミニアプリ、SNS、QRコード。
• 販促・接客：通知、クーポン、ポイント、会員証、店舗検索。予約、順番待ち、事前注文、決済も含みます。
• データ連携：POS、EC、在庫、商品マスタ、CRM、予約システムをつなぎ、会員IDや購買イベントを共通化。

NSWのモバイルO2Oサービスでは、サーバ構築不要のO2O BaaSを紹介しています。ほかに、プッシュ通知、位置連動クーポン、店舗検索があります。さらに、行動分析、Beacon連携、POSとのクーポン連携もあります（出典: NSW「モバイルO2Oサービス」）。

標準機能を使えるかどうかで、ゼロから作る場合と比べた初期費用や開発期間が変わります。

O2Oシステムの費用相場の目安

費用相場は幅が広く、初期30万〜150万円程度のSaaS・既製店舗アプリから、2,000万円〜1億円超のオムニチャネル基盤までに及びます。中心になりやすいのは、標準モジュールに個別連携を加える300万〜800万円程度の導入です。

複数の店舗・EC・POS・CRMをつなぐ本格開発は、800万〜2,000万円程度です。ただし、これらは公開相場と機能構成から整理した推定レンジで、すべてのO2O案件に当てはまる固定価格ではありません。

SaaS・既製店舗アプリ・LINEミニアプリの費用

標準機能を中心に始める場合、初期費用は30万〜150万円程度、月額は5万〜30万円程度が見積もりの目安です。見積もりの前に、標準機能で解決する課題と個別開発が必要な課題を切り分けます。

対象となる機能は、店舗情報、クーポン、プッシュ通知、簡易会員証、店舗検索などです。ここでの月額は、複数の類似サービスの機能構成から整理した推定値で、公開価格の統計ではありません。

利用条件や追加開発の有無で費用は変わるため、見積もりの際は次の項目を確認します。

• 料金の変動要因：店舗数、会員数、配信数、サポート範囲。
• 追加費用：ストア登録代行、個別デザインの有無。
• 個別開発：POSクーポン連携、会員ランク、在庫同期、来店判定。
• 契約条件：月額に含む機能、利用上限、データ持ち出し可否。

標準モジュール＋個別開発の費用（300万〜800万円程度）

iOS・Androidに、会員登録、ポイントや会員証、通知などの標準モジュールを組み合わせます。店舗検索、クーポン、管理画面も含みます。POSまたはECの一部と連携する構成では、初期300万〜800万円程度が目安です。

開発期間は3〜6か月程度です。単機能のアプリより費用が上がるのは、連携や運用に必要な設計が加わるためです。

• 会員連携：会員IDの照合。
• クーポン連携：利用済みフラグの返却。
• 運用設計：障害時の再送、管理者権限、操作ログの扱い。

2026年版の公開相場では、小規模システム開発が100万〜300万円、中規模が500万〜1,000万円、人月単価が60万〜200万円程度です（出典: SIA株式会社「システム開発の費用・相場 2026年版」）。

O2Oでは、通常の会員制Webシステムに店舗データとアプリの連携が加わります。そのため、連携数やテスト量によって相場の上側へ寄りやすくなります。

本格的なO2O・オムニチャネル基盤の費用

複数ブランド・多数店舗で、在庫、商品マスタ、受注、会員を連携する構成があります。さらに、ポイント、予約、決済、CRM、分析基盤まで連携範囲を広げるケースもあります。その場合の目安は、初期800万〜2,000万円程度、開発期間6〜12か月程度です。

基幹刷新、大規模なデータ移行、複数ブランドの権限管理まで含めると、2,000万円〜1億円超、12〜18か月以上になる可能性があります。

費用を左右する条件と導入の進め方は、分けて見ます。

• 費用の要因：API仕様、データの名寄せ、在庫更新の即時性、ピーク性能、障害時の業務継続。
• 段階導入：数店舗で在庫・クーポン・会員連携を検証し、効果を見てBOPIS（店頭受け取り）や高度なCRMへ拡張。

O2Oシステム開発費用の内訳

見積書に「開発一式」とだけ書かれていると、後から要件定義やデータ連携、テスト、保守が追加されることがあります。そのため、費用は三つの工程に分けて比べます。一つ目は企画、要件定義、UX設計の工程です。二つ目はアプリ、管理画面、外部連携の工程で、三つ目はデータ移行、テスト、リリースの工程です。

企画・要件定義・UX設計の費用

企画では、どの顧客をどの店舗へ送客するか、主なKPIを何にするかを決めます。ここが曖昧なままだと、後の要件定義で機能の優先順位を付けにくくなります。

企画・要件定義・UX設計では、顧客や店舗の行動に関わる次の項目を決めます。

• 要件定義：店舗検索、会員登録、クーポン、ポイントを優先度付けします。通知、在庫表示、予約、決済も対象です。
• 店舗業務：要件定義の段階で、スタッフの業務も整理します。
• UX設計：店舗情報やクーポンまでのタップ数、店頭で提示する画面の見せ方。

工程を省くと、機能が多くてもダウンロードされない、通知が多くてアンインストールされる、スタッフがクーポンの確認方法を理解できないといった問題が起きます。

要件定義には、来店率、クーポン利用率、会員化率、再来店率のうち何を検証するかを明確にしたうえで、必要な範囲で費用をかけます。

アプリ・管理画面・外部システム連携の費用

開発費には、画面やシステムの実装に加えて、既存データやサービスをつなぐ設計も含まれます。

店舗とECの会員を共通化するには、顧客IDの対応表、退会・同意撤回の扱い、重複会員の統合ルールが必要です。POSとクーポンの連携では、発行、利用、取消の扱いに加えて、期限切れや通信障害時の再処理も決めます。

• 実装範囲：アプリ、Web・管理画面、API、バッチ。認証、通知、ログ、権限管理も含みます。
• アプリ開発相場：iOS・Android単体は各100万〜200万円。
• 複数OS相場：マルチプラットフォームは80万〜150万円。
• 機能別相場：会員登録20万〜50万円、通知15万〜30万円。
• 機能別相場：決済40万〜100万円、位置情報・地図20万〜50万円。

これらは2026年版の公開目安です（出典: モカモコ株式会社「アプリ開発の費用相場と外注先の選び方 2026」）。ただし、O2Oの個別見積もりでは、連携・テスト・保守の費用が別途加わります。

データ移行・テスト・リリース準備の費用

移行では、会員情報、商品・店舗マスタ、在庫を新しいシステムへ移します。さらに、ポイント残高と購買履歴も移し、各システムの更新順序と整合性を確かめます。

店舗数が増えるほど、端末や通信環境、POS機種などの組み合わせが増え、スタッフの操作パターンも広がります。そのぶん、テスト工数も増えます。

リリース前には、店舗ごとの端末・通信環境やPOS操作を踏まえて、次の動作を確かめます。

• アプリ環境：OS差異、通知・位置情報の許諾。
• 店舗機能：QRコード読取、クーポン利用済み処理。
• 連携処理：在庫更新遅延、決済失敗時の表示。

ストア申請、プライバシーポリシー、利用規約を見積もりに含むか確認します。店舗向けマニュアルと問い合わせ対応についても、同じように確かめます。

O2Oシステムのランニングコスト

リリース後も、クラウドや外部API、監視の費用が続きます。さらに、保守やコンテンツ配信、店舗教育もかかります。そのため、月額費用や従量課金も含めて、3年程度の総保有コストで比べます。

クラウド・通知・地図・決済などの従量課金

運用費は、インフラ費と外部サービス費に分かれます。固定料と利用量に応じた課金を分けて確認します。

• クラウド：計算資源、データベース、ストレージ、バックアップ。CDN、監視、ログ保管も含みます。
• 外部サービス：通知、地図・経路検索、SMS、メール、本人確認、決済。
• 従量課金の基準：利用者数、通知数、地図表示回数、決済件数、保存期間。
• 固定料金：最低利用料と月額固定料。

決済を組み込む場合は、開発費のほかに、事業者の手数料、返金・チャージバック対応、売上照合の運用も考慮します。

アプリストアの課金制度は、地域や取引形式、プログラムによって変わります。そこで、オンライン決済をアプリ内で扱うか、店頭決済や外部ECへ誘導するかを、要件定義の段階で整理します。

保守・OS対応・コンテンツ運用の費用

保守の対象と運用担当を明確にし、契約範囲と日常業務を分けて確認します。

• 保守作業：障害・脆弱性対応、バックアップ確認、OS・ブラウザ更新、ストア審査、外部API変更対応。
• 販促担当：マーケティング担当者が通知・クーポンを配信。
• 店舗担当：スタッフが会員証・クーポンを確認。
• システム担当：情報システム担当者がデータ品質を管理。

契約によって、問い合わせ時間や緊急時の復旧目標が変わります。改修単価や月の作業時間も異なります。SLA、対象外作業、データ復旧の責任範囲は、見積書と契約書で確認します。

コンテンツ制作や問い合わせを外注するなら、運用費に含めます。スタッフ教育やKPIレポートを外注する場合も、運用費に入ります。開発後に誰が何を担うかを決めておくと、想定外のコストを防げます。

O2Oシステムの費用が変動する7つの要因

同じ店舗アプリでも、店舗数やデータ連携の条件によって見積もりは変わります。費用を左右する要因は7つで、規模・連携・機能の3つに分かれます。

規模に関わるのは、店舗数・会員数と、アクセスや業務量です。連携に関わるのは、接続方式とデータ品質、在庫更新の扱いです。機能に関わるのは、機能数、対象OSやチャネル、セキュリティ要件です。

下の3つの節で、この順に見ます。金額差を説明できるよう、RFPや見積もり依頼書にこれらの条件を記載します。

店舗数・会員数・アクセス規模の影響

数店舗の実証実験と全国数百店舗の本番運用では、インフラや権限が異なります。サポートやテストの範囲も変わります。見積もりには次の規模を記載します。

• 利用規模：店舗数、会員数、同時アクセス数。
• 業務量：セール時のピーク、1日の購買イベント、通知配信数。
• 即時性：利用者数が少なくても、在庫をリアルタイムに返す場合は連携基盤や監視が必要になることがあります。

POS・EC・CRMのAPIとデータ品質の影響

費用を左右するのは、連携先の数に加えて、接続方式やデータの状態です。設計・開発・テストの工数も、これらによって変わります。

• 接続条件：APIの有無、CSVのみか、更新頻度、障害時の再送、会員IDの統一状況。
• 既存データ：古いPOSや独自形式の在庫データでは、APIゲートウェイや変換処理が必要な場合があります。
• 在庫運用：許容する更新遅延、引当時点、棚卸し中の扱い、店舗間移動の反映方法。

在庫の売り越しや来店後の欠品は、顧客体験を損ないます。また、連携仕様が未確定のまま概算を比べると、安い見積もりが後から高くなることがあります。

機能数・対応OS・セキュリティ要件の影響

機能、対象OSやチャネル、セキュリティの要件を分けて整理すると、各社の見積もりの前提をそろえて比べられます。

• 機能：会員登録、ポイント、クーポン、位置情報、予約を含みます。順番待ち、事前注文、決済、店頭受取、チャット、分析も対象です。
• 対象環境：iOS、Android、Web、LINEミニアプリ。両OSの個別開発かクロスプラットフォームかは、端末機能、性能、保守方針を踏まえて決めます。
• 情報管理：利用目的、同意、配信停止、権限設定。暗号化、監査ログ、脆弱性対応も含みます。

位置情報、購買履歴、会員情報を扱う場合は、誰が何の目的でどのデータを利用するかを整理します。そのうえで、個人情報保護委員会のガイドラインを参照します。

セキュリティ要件を後から付けると、構成変更や再テストが起きやすくなります。そのため、初期見積もりに含めます。

O2Oシステムの開発期間と進め方

O2Oは、目的とKPIを絞ったMVP（Minimum Viable Product）を短期間で検証する進め方が適しています。

期間の目安は、標準機能中心の導入が20日〜3か月、標準モジュール＋個別開発が3〜6か月です。本格連携は6〜12か月、基幹を含むスクラッチは12〜18か月以上です。

MVPによる主目的の絞り込み

検証する目的は一つに決め、数店舗で機能を試して、来店率やクーポン利用率を確かめます。

• 送客：EC閲覧者を店舗へ送る。
• 再来店：休眠会員を再来店させる。
• 在庫起点：店舗在庫から来店・購入を増やす。

店舗検索、会員証、クーポンを目的に合わせて試します。通知、QRコード、効果測定も対象になります。

ポイントや予約、決済を一度に搭載すると、要件調整とテストが膨らみます。在庫、BOPIS、レコメンドも同時に入れると、その負担はさらに大きくなります。

MVPで利用者とスタッフの行動を確かめます。そのうえで、使われた機能に投資を足すと、初期費用と失敗リスクを抑えやすくなります。

MVPの段階でも、将来の会員IDやイベントログを拡張できる設計にしておきます。

データの洗い出しから本番後の改善までの流れ

作業は、次の順に進めます。

1. POS、EC、会員、ポイントなどの管理主体と更新頻度を洗い出します。商品、在庫、店舗、予約、決済も同じように洗い出します。
2. 共通顧客IDとAPIまたはCSV連携を設計し、イベントログ、権限、同意、障害時の再処理も含めます。
3. UI設計、実装、データ連携、受入テスト、店舗スタッフ向け研修を行い、限定店舗で公開します。

本番後は、来店率、クーポン利用率、店舗受取率、会員化率を定期的に確認します。さらに、再来店率、オンラインから店舗への送客率、LTVも追います。

通知は、開封率だけでなく、通知後に来店や購買へつながったかまで測ります。また、データ欠損、クーポンの不正利用、アプリ評価は、改善計画に含めます。店舗からの問い合わせも、改善の対象に加えます。

O2Oシステムの見積もりを取る際のポイント

会社ごとに開発費・連携費・テスト費・保守費の範囲が違うため、安い見積もりが本当に安いとは限りません。そこで、同じ前提条件で各社に依頼します。

見積もり依頼書に記載する項目

同じ条件で工数を比べられるよう、依頼書に次の情報をそろえます。

• 規模・機能：業態、店舗・ブランド・会員数、同時アクセス、OS、チャネル、必要機能。
• システム・期間：既存システム、連携方式、データ保管場所、希望期間。
• 連携データ：会員ID、商品マスタ、在庫、クーポン、購買イベントの連携方向。
• 店舗運用：端末、オフライン時の扱い、通知配信停止、位置情報同意、管理画面権限。監査ログ、障害時連絡体制、受入テスト担当も記載します。
• 見積条件：未確定要件は「要件定義で確定」と記し、概算と確定見積もりを区別。

開発会社へ確認する質問

連携能力、契約後の運用、解約時のデータ移行は、具体的に確認します。

• 開発・連携：POS・EC・CRM実績、APIがない場合の対応、在庫更新の許容遅延、標準機能と追加開発の境界。
• 契約・保守：データ所有権、OS更新、障害時SLA、店舗研修、ストア申請、脆弱性・問い合わせ対応の見積範囲。
• 既製サービス：解約後のデータ返却、月額算定単位、通知・API上限、カスタマイズ費、移行費。

RECOREは、2025年12月の発表で、Shopify上から店舗在庫を確認するフェーズ1を公開したとしています。同発表では、yuhaku公式ECへの導入例に加えて、今後のBOPIS・CRM連携も示しています（出典: RECORE「RECOREオムニチャネルアプリ」プレスリリース）。

現在利用できる機能と、将来の拡張予定は分けて確認します。

O2Oシステムのコストを最適化する5つの方法

コストの最適化は、成果に関係する機能へ予算を配分し、使われない機能や手戻りを減らすことです。方法は5つあり、主目的に沿った機能の優先順位付け、SaaS・BaaSと個別開発の使い分け、既存システムの活用、データ品質と運用責任の事前確認、数店舗からの段階的な展開です。優先順位付けは1つ目の節、使い分けと既存システムの活用は2つ目の節、データ品質と段階展開は3つ目の節で見ます。

KPIに基づく機能の優先順位付け

KPIから逆算して、機能の優先順位を決めます。目的ごとに優先機能を絞ると、初期工数を抑えられます。

• 来店促進：会員証、店舗検索、クーポン、来店判定、効果測定。
• 店頭受取：在庫引当、受注、店舗通知、受取確認。
• 後回しにできる機能：目的に直接つながらないゲームや複雑なレコメンド。

「EC閲覧者の来店率を高める」「休眠会員の再来店率を上げる」など、主目的に沿って選びます。

SaaS・BaaS・既存基盤の使い分け

標準機能、個別開発、既存基盤は、要件に合わせて組み合わせます。まず、一般機能はSaaS・BaaSに任せ、競争力に直結する連携や業務フローは個別開発にします。整理する観点は次の4つです。

• 機能の分担：一般機能はSaaS・BaaS、競争力に直結する連携や業務フローは個別開発。
• 標準基盤：NSWのO2O BaaSはサーバ構築不要、低価格・短納期を掲げ、共通機能の実装を減らせます。
• 長期費用：月額利用料、データ制約、拡張費、サービス終了時の移行。
• 既存システム活用：EC・POS・CRMを置き換えない場合はAPI等を利用。RECOREの在庫・EC連携基盤やUSENの標準店舗アプリも選べます。

USENは、2025年5月末時点で約14,400店舗以上の導入実績を公表しています（出典: USEN「アプリンク」公式サイト）。実績は参考になりますが、自社の連携要件と同じかどうかを確認します。

データ品質と店舗運用の事前準備

連携の例外処理を減らし、店舗で使われる状態にするために、事前に次の準備を進めます。

• データ品質：店舗住所、EC・POSの商品コード、会員の重複、在庫更新担当を確認。
• データ運用：開発前に責任者、更新ルール、欠損時の扱いを決めて、追加工数を抑えます。
• 店舗定着：スタッフが確認できない機能は、顧客も使えません。操作を簡単にし、研修画面、問い合わせ窓口、障害時の代替手順を用意します。
• 展開判断：数店舗で試してから全店へ展開し、定着しない機能の保守費を避けます。

よくある質問（FAQ）

O2Oシステムの費用や発注で、よくある質問に答えます。導入方式の選択は金額だけでなく、目的、既存システム、運用体制によっても変わります。

O2Oシステムは最低いくらから開発できますか？

標準機能だけのSaaS・既製店舗アプリは、初期30万〜150万円程度、月額5万〜30万円程度からという推定レンジがあります。

独自の会員・在庫・POS連携や個別アプリ開発を含めると、300万〜800万円程度以上になる可能性があります。まずは、標準機能と追加開発の条件を確認して、予算を比べます。

店舗アプリとLINEミニアプリはどちらが安いですか？

既存の顧客接点や標準機能を使えるLINEミニアプリは、インストール促進やOS別開発を抑えやすい場合があります。

位置情報、端末機能、複雑な会員証、独自の購買体験を重視するなら、専用アプリが適することがあります。

初期費用だけでなく、利用料、配信上限、データ取得を含めて比べます。さらに、顧客との継続接点も比較の対象にします。

O2Oシステムの費用を抑えると品質が下がりませんか？

機能を無計画に削ると、使いにくさやセキュリティ上の問題につながります。目的に必要な機能へ絞り、標準モジュールと段階導入を使えば、品質を保ちながら初期費用を抑えられます。

会員IDや権限、同意は、後から直すと費用が大きくなりやすいため、優先して要件に含めます。監査ログ、エラー処理、データバックアップも、同じ理由で優先します。

O2Oシステムの開発会社は何社に見積もりを依頼すべきですか？

まず3社程度へ同じ要件を提示し、標準機能や連携実績、開発体制を比べる方法が現実的です。保守範囲や総額も、同じ条件で比べます。

価格だけでなく、POS・EC・CRM連携と店舗スタッフへの導入支援を確認します。さらに、障害時にどこまでを誰が受け持つか、データ所有権も確かめます。

要件が固まっていない場合は、概算見積もりと要件定義の提案を分けて評価します。

まとめ：O2Oシステムの初期費用と運用費の比較

SaaS・既製店舗アプリは初期30万〜150万円程度、標準モジュール＋個別開発は300万〜800万円程度が目安です。本格的な店舗・EC・POS・CRM連携は、800万〜2,000万円程度が目安になります。

基幹連携や大規模データ移行を含めると、2,000万円〜1億円超になる可能性もあります。いずれも、公開されている類似サービスの価格帯から整理した推定です。

店舗数、会員数、連携先、対応OSによって金額は変動します。データ品質、セキュリティ、運用体制によっても変わります。

開発費・連携費・運用費の総額での判断

見積書では、要件定義やUX設計、アプリと管理画面を分けて確認します。API連携、データ移行、テスト、保守なども、工程ごとに見ます。

初期費用が安くても、月額や従量課金を含めた3年程度の総保有コストで見ると、高くなる場合があります。改修、OS対応、店舗研修も含めて比べると、その差が見えてきます。

KPIと既存データの整理と見積もり依頼

主目的を一つ決め、数店舗のMVPで検証することが、費用最適化の第一歩です。会員・商品・在庫・購買データの管理者と連携方法を整理したうえで、同じ条件で3社程度へ見積もりを依頼します。

O2Oシステムは、稼働後も改善を続けるものとして予算を組みます。来店率、クーポン利用率、再来店率、店舗受取率などのKPIを、継続的に改善する仕組みにします。

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

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