オムニチャネルシステム開発の見積相場や費用/コスト/値段について

オムニチャネルシステム開発の費用は、店舗数やSKU数によって大きく変わります。既存システムとの連携や、データ移行・業務テストの範囲でも変わり、全体では数千円から数億円まで幅があります。

全体像は、オムニチャネルシステム開発の完全ガイドでも確認できます。

▼全体ガイドの記事
・オムニチャネルシステム開発の完全ガイド

オムニチャネルシステム開発の費用を左右する全体像

オムニチャネルシステムは、店舗やECサイト、自社アプリなど、複数の接点をつなぐ仕組みです。SNSや電話窓口、外部モールも連携の対象に含まれます。商品と顧客の情報を共通データとして扱い、在庫や注文、ポイントも同じ基盤で連携させます。

マルチチャネルとは違い、オムニチャネルでは購買履歴や会員情報を接点の間で引き継げます。さらに、店舗受取や店舗からの発送まで一貫して扱えるのが特徴です。

ECサイトのリニューアルだけではない理由

EC単体とオムニチャネルでは、連携する業務と例外処理の範囲が異なります。そのため、ECのリニューアルと同じ感覚で見積もると、費用の前提がずれてしまいます。

  • EC単体:商品表示、注文受付、受注管理を中心に連携します。
  • オムニチャネル:店舗や倉庫、会員、返品まで連携の対象です。

ECサイト単体では、商品を表示する画面と受注管理が中心になります。一方、オムニチャネルでは、店舗POSや倉庫の出荷可能数、店舗の取り置きを扱う点が大きな違いです。

モール注文や会員・ポイントの情報に加えて、返品や交換の状態も連携が必要です。たとえば、ECに表示した店舗在庫が店頭で売れた場合は、販売可能在庫を減らす処理が必要になります。

表示の更新に加えて、注文後に在庫の引き当てが失敗した場合の案内も必要です。こうした例外処理と連携テストが、EC単体との費用差を生みやすい部分です。

見積もり前の「データの正」の決定

見積もりの前に、商品と顧客、在庫、注文それぞれについて、正となるシステムを決めておきます。

  • 更新元:各データの正となるシステムの決定
  • 失敗時の扱い:再送、手動修正、監査ログのルールの取り決め

商品情報はPIM、顧客情報はCRMが正になることがあり、在庫はOMSや基幹が正になる場合もあります。注文はECまたはOMSを正とするなど、役割を先に決めておきます。

正を決めないまま連携すると、複数のシステムが同じデータを書き換えてしまい、不整合が起きます。更新頻度や再送の扱い、手動修正の権限、監査ログも要件に含めておきます。

この整理は要件定義や業務設計に含まれ、後工程の手戻りを抑えるための費用です。

オムニチャネルシステムの費用相場の目安

EC中心から中規模のオムニチャネル統合まで、4つの構成別に初期費用レンジを並べた図解。
連携範囲が広がる構成ほど、検討する初期費用の幅も大きくなります。

初期費用は、クラウド型で小さく始める場合に100万〜800万円程度です。複数店舗、POS、OMS、WMS、会員基盤を統合する場合は、500万〜3,000万円程度になります。

複数ブランドや基幹刷新を含む大規模案件は、3,000万円から数億円になります。ここに挙げた金額は、公開相場と、案件ごとの連携・移行・テストを踏まえた予算検討用のレンジです。そのため、個別案件の確定見積もりではなく、前提条件をそろえて見比べる必要があります。

ASP・SaaSでEC中心に始める場合は数千円〜100万円程度

EC中心で始める場合は、初期費用と月額費用を分けて確認します。

  • 初期費用:数千円から100万円程度に収まることもあります。
  • 月額費用:数千円から数十万円程度が目安です。

店舗側の在庫表示や簡易的な受注連携に絞れば、初期費用は抑えやすくなります。自社で制作するか、デザイン、商品登録、決済設定を外注するかによっても変わります。

Shopifyの日本向け料金は、Basicが年払い月額3,650円です。Growは10,100円、Advancedは44,000円、Plusは月額368,000円からです。

この料金はプラットフォームの料金で、POS、基幹連携、アプリ、移行、制作は別途かかります。運用の人件費も別に必要になるため、予算は総額で組みます。

出典はShopify Japan「Shopifyの料金プラン」です(2026年8月確認)。

クラウド型に店舗・POS・在庫連携を加える場合は100万〜800万円程度

標準APIを使えるクラウド型に連携を少数追加すると、初期費用は100万〜800万円程度です。

  • 連携対象:店舗在庫、POS、決済、配送などが対象です。
  • 月額対象:サービス、クラウド、外部アプリ、監視、保守の費用が該当します。

月額は、利用料やクラウドなどを合わせて数万円〜40万円程度になることがあります。ただし、この数字は公的な相場表ではなく、公開相場に案件固有の連携を加えて推定したレンジです。

店舗数が少なく、在庫の更新元が明確であれば、下限に近い額になります。また、既存システムに安定したAPIがあれば、連携費用も抑えられます。

ECパッケージは300万〜1,500万円程度が目安

ECパッケージの標準機能を使い、業務に合わせて拡張する場合の初期費用は300万〜1,500万円程度です。

  • 月額:公開相場では10万〜30万円以上とされています。
  • 期間:導入期間の目安は4〜8か月程度です。

この構成では、商品や受注、顧客、在庫、販促を、自社業務に合わせて拡張します。この公開相場は2025年の情報で、出典はSalesforce Japan「ECサイトの構築費用はいくら?相場の比較や見積もりポイントを解説」です。

POS、WMS、モール、会員・ポイントを加えると、連携アダプターの費用が増えます。さらに、データ移行と店舗ごとの導入テストは、パッケージ本体とは別に上乗せされます。

中規模のオムニチャネル統合は500万〜3,000万円程度

中規模構成では、EC、複数店舗、POS、OMSまたは在庫管理、WMSを連携させます。

  • 初期費用:500万〜3,000万円程度
  • 月額費用:20万〜100万円程度をベースに、各種費用が加わります。

会員・ポイント、店舗受取、店舗発送、返品まで運用する構成です。月額には、プラットフォームやクラウド、保守、監視、外部サービスの費用が加わります。

期間は、6〜12か月程度で段階導入する計画を一般的な検討軸にします。ただし、店舗展開数や既存基幹の改修範囲によって、期間と費用は前後します。

2025年のSCSKとアークランズの事例では、店舗、EC、モールの在庫をまとめて管理しました。出典は、SCSK「アークランズとSCSKが協働し、ECシステム基盤を再構築」です。

商品・在庫の管理と業務基盤を組み直す案件では、費用が画面制作費より広い範囲に及びます。

大規模な基幹刷新は3,000万円〜数億円に広がる可能性

複数ブランド、多店舗、多SKU、海外拠点を含むと、費用は3,000万円から数億円に広がります。

  • 対象範囲:ERPや会計の刷新まで含む構成です。
  • 追加設計:可用性、セキュリティ、移行、並行稼働に関わる作業

アクセスが集中する場面への対応や、ERP・会計の刷新も、対象範囲を広げる要因になります。また、フルスクラッチや複数製品を組み合わせる構成では、機能開発以外の設計も必要です。

教育と運用の引き継ぎも必要になるため、予算は開発費に加えてそれらも含めて組みます。

Salesforce Japanは、フルスクラッチのEC構築費用を500万円〜数千万円と整理しています。出典はSalesforce Japanの2025年情報です。

オムニチャネル連携を含める場合は、対象範囲に応じて、さらに増えると考えます。

ポイント

費用は構成の範囲で大きく変わるため、まず店舗数や連携先、対象業務を整理し、近い構成の相場と見比べて考えるとよいでしょう。

オムニチャネルシステム開発の費用内訳

費目ごとの作業範囲を中心に、要件定義、連携、データ移行、テストと店舗展開を結んだ図解。
費用を工程や作業領域ごとに分けると、見積もりの対象を照合できます。

見積書は、合計金額だけでなく費目ごとの作業範囲を比べて読むことが大切です。たとえば、業務整理や外部接続、マスタ整備、異常系テスト、店舗展開が、全体の大きな割合を占める場合もあります。

初期費用、月額費用、社内負担に分けて、最低限必要な費用を把握します。

要件定義・業務設計の費用

要件定義では、店舗、EC、倉庫、コールセンター、物流、マーケティングの各領域の業務を確認します。

  • 業務フロー:商品登録から返品・返金までの流れ
  • 要件の分離:システム要件と運用要件の切り分け

価格変更や在庫引当、店舗受取、キャンセルは、業務シナリオとして書き出しておきます。これを省くと、店舗ごとの在庫引当ルールの違いが開発の途中で判明してしまいます。さらに、返品時にポイントを戻す条件が未定のままだと、追加開発や納期の延長につながります。

POS・ERP・WMS・モールとの連携費用

連携費用は、接続数だけでなく、データやエラー処理の条件によっても変わります。

  • 接続条件:APIの有無、データ項目、リアルタイム性
  • 障害条件:再送、部分成功、通信断の扱い

セキュリティ要件の確認も必要です。POSから売上を受け取るだけであれば比較的単純ですが、在庫同期になると設計が増えます。EC注文を店舗へ引き当て、欠品時に別の店舗や倉庫へ切り替える場合も、設計の範囲が広がります。

楽天やAmazonなどの外部モールでは、各社の注文や返品のルールに合わせる必要があります。連携ごとに、タイムアウトや重複送信への備えも見積もりに含めます。

会員・商品・在庫・注文データの移行費用

データ移行は、件数よりも品質と変換ルールが費用を左右します。

  • 会員データ:重複、表記揺れ、退会、同意状況の確認
  • 商品・注文:SKU、画像、税区分、返品状態の検証

会員IDの重複や、氏名・住所の表記揺れがあると、抽出と名寄せの作業が増えます。商品コードや在庫区分、過去注文の欠損も確認が必要です。

会員を統合する場合は、個人情報の利用目的と同意状況をもとに、移行の対象を決めます。商品は、価格や販売期間まで含めて確認します。注文は、番号の重複や返品・返金の状態を、新システムで再現できるかを検証します。

テスト・店舗展開・教育の費用

オムニチャネルのテストでは、画面表示に加えて、業務のつながりを確認します。

  • 業務テスト:在庫、受取、出荷、返品の整合性の確認
  • 店舗展開:研修、問い合わせ対応、切り戻しの準備

店舗で売った直後にEC在庫が減るか、店舗受取の引き当てが正しく行われるかを確認します。加えて、受取期限を過ぎた注文や出荷後のキャンセル、返品もテストの対象です。

在庫、売上、ポイントが整合するかを確かめる際には、実店舗の営業時間も考慮します。また、在庫の数え直しや通信断、レジ交換、繁忙期のアクセス集中も確認の対象になります。

店舗スタッフが迷わないよう、マニュアルと問い合わせ窓口も用意します。旧システムとの並行稼働も含めて、準備を進めます。

導入店舗数が多いほど、研修と展開の費用を別枠で見ると、実態に近い見積もりになります。

ポイント

見積書は合計金額だけでなく、費目ごとの作業範囲を比べて読みます。要件定義から店舗展開までのどこが含まれ、どこが対象外かを見ておくと、比較の前提がそろいます。

初期費用以外にかかるランニングコスト

導入後の費用は、固定費と、取引量に応じた変動費に分けて考えます。月額だけで比べると、アプリやAPI利用量、決済、クラウド、保守の費用が抜け落ちてしまいます。

監視や商品登録、社内運用の人件費も含めて、3年程度の総保有コストを作ります。初期費用や月額費用、繁忙期の追加費用、契約更新費を並べて比べます。

ライセンス・クラウド・外部サービス費

コマース基盤やOMS、CRMには、それぞれ費用がかかります。CDPやPOSも、利用するなら別途費用がかかります。WMSやBIも、利用する場合は費用の対象になります。

  • 契約条件:契約期間と標準機能の範囲
  • 利用量:ユーザー、店舗、注文、API、データ量の見込み

Shopify Plusは、標準設定と統合なら3年契約で月額368,000円からです。1年契約では月額398,000円からと公式に案内されています。出典はShopify Japan「Shopify Plusの価格」です(2026年8月確認)。

複雑な事業構造では料金が個別に変わります。また、カスタム開発やテーマの費用は別途かかります。外部アプリと移行作業も、別途の評価が必要になります。

料金は、ユーザー数や店舗数、注文数で変わるうえに、APIコール数やデータ保持量でも変わります。そのため、追加ストア数も確認し、繁忙期の利用量まで見積もりに入れます。

保守・監視・セキュリティ費

保守費には、障害対応、問い合わせ、軽微な改修、更新、バックアップが含まれます。

  • 対応条件:受付時間、回答、復旧、休日対応の範囲
  • 安全対策:権限、監査ログ、暗号化、脆弱性対応の内容

障害時に備えて、受付時間と一次回答・復旧の目標を決めておきます。重大障害の連絡方法や再発防止の報告範囲も、あらかじめ明確にします。

顧客データや決済を扱うため、安全対策は見積もりの中でも外せない項目です。脆弱性診断と委託先の管理も、セキュリティ要件に含めます。決済情報を自社で保持するか、決済サービスに委ねるかによって、PCI DSS対応の内容も変わります。

「保守費に含む」とひとまとめにせず、実施内容に分けて見積もってもらいます。

社内運用・商品データ整備の費用

導入後も、商品情報や在庫差異、注文エラー、返品、教育を担当する人が必要です。

  • 日常運用:商品登録、在庫確認、注文の再処理
  • データ整備:商品マスタの責任者と更新ルールの決定

キャンペーン設定や店舗スタッフの教育も、社内で担う運用作業です。開発会社の見積書には社内人件費が含まれないことが多いため、自社の工数として別に見込みます。

複数チャネルで、商品名や価格、画像、在庫区分をそろえる責任者が必要です。初期データの整備を外注する場合は、商品点数、画像加工、属性項目、登録期限を分けて依頼します。

ポイント

導入後の費用は、月額だけでなく3年程度の総保有コストで見るのが目安です。ライセンスや保守、社内運用の人件費まで含めると、予算の全体像がつかめます。

費用が変動する要因と見積もりの取り方

相見積もりの前に確認する店舗数や業務シナリオ、比較範囲、対象外作業を4枚のカードに整理した図解。
同じ前提にそろえると、提案ごとの費用差を読み取りやすくなります。

同じ名称のシステムでも、店舗数や業務範囲が違えば、見積もりの中身は別物になります。相見積もりでは、初期費用や月額、期間、対象外、追加費用の条件をそろえることが大切です。

安い提案を選ぶ前に、何を削った金額なのかを確認することが重要です。

店舗数・SKU数・注文量の条件

店舗数、SKU数、注文量は、連携と運用の規模を決める基本条件です。

  • 店舗・商品:店舗数、ブランド数、SKU数の提示
  • 注文・物流:注文数、モール数、倉庫数の提示

店舗が増えると、店舗コードや営業時間、受取可能時間、在庫の更新頻度が増えていきます。端末設定や教育の対象も広がるため、店舗数は見積もりに必ず含めます。

SKUが多い場合は、属性やバリエーション、画像、在庫ロケーションの数も増えます。価格ルールの整備も工数を押し上げるため、商品条件を提示しておきます。

注文量は、通常日の平均だけでなく、セールや年末のピーク値も示すとよいです。そのうえで、同時アクセスやAPI呼び出し、バッチ処理、出荷の締め時間も確認します。見積依頼書には、月間注文数とピーク時の数字を必ず書きます。

店舗受取・店舗発送・返品までの業務シナリオの定義

機能一覧には業務の複雑さが表れにくいため、シナリオで示します。

  • 店舗受取:引当、期限、本人確認、返金までを含む流れ
  • 店舗発送・返品:作業指示、欠品、返金、検品の内容

店舗受取では、取り置き期限や本人確認が絡むため、在庫引当から受取完了までを一本ずつ確かめておきます。未受取の場合も返金まで、一連のシナリオとして示します。

店舗発送では、作業指示や梱包資材、配送会社、出荷確定を確認します。欠品時の切り替え方法も、店舗発送の条件に含めておきます。

返品では、EC購入品を店舗で受け付けるかどうかと、返金方法を決めます。在庫へ戻す条件やポイントの扱い、検品結果の連携は、返品の流れの中で決めておきます。

正常系と例外系を分けて示すと、各社の提案範囲とテスト計画を比べやすくなります。

3社以上での費用・期間・対象範囲の比較

開発会社、パッケージベンダー、クラウド製品の導入パートナーとでは、前提が異なります。

  • 同じ条件:3社以上へ同じRFPを渡すこと
  • 比較項目:費用、期間、標準機能、追加開発の比較

見積もりは、要件定義、設計、開発の工程ごとに分けて出してもらいます。連携、移行、テストについても、別々の金額で示してもらいます。教育と保守の費用も、同じように分けてもらいます。標準機能と追加開発の範囲、将来拡張の方法も、比較表に入れておきます。

データ移行の責任者と、障害時の一次窓口、SLAを確認します。契約が終わるときのデータ返却条件も、提案比較の対象になります。

金額が低い提案では、対象外の作業や社内負担が別に置かれていないかを確かめます。

ポイント

同じ名称のシステムでも、店舗数や業務範囲、対象外の作業によって見積もりは大きく変わります。提案の金額は、何を含み何を削った数字なのかを並べて比べることが大切です。

オムニチャネル開発のコスト最適化のポイント

コスト最適化では、機能を一律に減らす代わりに、検証したいユースケースへ投資を集中させます。成果を測りやすい範囲から始めて運用を確認し、そのあとで広げれば、リスクを管理できます。

優先KPIを一つか二つに絞った段階導入

最初は、店舗在庫の表示精度、店舗受取の受取率、会員重複をKPI候補にし、効果を測りやすい一つか二つに絞って段階的に導入します。

  • 優先KPI:上の候補から選ぶ一つか二つの指標
  • MVP:1ブランド、数店舗、一部カテゴリでの実施

アプリやレコメンド、AI、全モール、全店舗を同時に対象にすると、要件が一気に膨らみます。そのため、最初の対象は効果を測りやすい範囲に絞ります。

MVPでは、在庫引当やキャンセル、返品、通信断を含めてテストを行います。効果と現場の負荷を確かめてから店舗やチャネルを増やし、不要な機能を先に開発することを避けます。

標準機能・API・既存サービスの優先

独自開発が必要な競争領域と、標準機能で代替できる領域を分けて考えます。

  • 標準化しやすい領域:商品管理、決済、メール、分析、認証
  • 段階移行:既存POSやERPをAPI・iPaaSで接続する方法

実績のあるSaaSやパッケージを組み合わせると、開発と保守の費用を抑えられる場合があります。既存のPOSやERPを残したまま使う道もあるため、入れ替えの範囲は慎重に決めます。

アドオンを増やしすぎると、契約更新やAPI制限への対応が複雑になります。バージョンの互換性や障害の切り分けも難しくなるため、構成は増やしすぎないようにします。

初期費用だけでなく、3年間の保守費と将来の変更費まで比べて判断します。

データと業務ルールの先行標準化

データと業務ルールを先にそろえると、カスタマイズの増加を抑えられます。

  • データ:SKU、店舗コード、顧客ID、注文状態の統一
  • 業務:返品、返金、棚卸しのルールの合意

不整合をカスタマイズで吸収すると、開発費と保守費が増えます。

税や価格のルールもそろえ、システムに残す例外は限定します。店舗や物流、カスタマーサポート、経理、情報システムの担当者が、業務変更を検討します。こうしたルールを先に合意しておくと、後からの手戻りを減らせます。

ポイント

コストを抑えるには、効果を測れる範囲から段階的に始めることが有効です。データと業務ルールをそろえてから広げると、手戻りを減らせます。

よくある質問(FAQ)

ECサイト構築とオムニチャネル開発の価格は、相場情報が混在しています。そのため、発注前によくある質問ごとに、費用の範囲と条件を分けて答えます。

オムニチャネルシステムは最低いくらから開発できますか?

最低費用は、ECだけか、店舗連携まで含むかで大きく変わります。

  • EC中心:SaaSのサービス料金が数千円から
  • 店舗連携:開発は100万〜800万円程度からの検討

商品データの整備や決済、アプリ、連携、保守、社内運用は、別に費用がかかります。最小構成の価格だけでなく、最初のKPIに必要な業務範囲で見積もることが大切です。

ECサイトのリニューアル費用と何が違いますか?

ECリニューアルは、画面、商品表示、カート、決済、受注管理が中心です。

  • EC単体:画面と注文機能の更新が中心
  • オムニチャネル:店舗と複数システムの業務を横断する対応

オムニチャネルでは、店舗在庫やPOS、OMS、WMS、CRM、モールをつなぎます。返品や店舗受取も対象になり、そのぶん連携設計や移行、異常系テスト、教育が加わります。

EC単体の相場は、そのまま全体の予算として見なすことはできません。

SaaSとスクラッチ開発はどちらが安いですか?

短期の初期費用と導入期間では、標準機能を使うSaaSが有利になりやすいです。

  • SaaS:月額、手数料、アプリ、API制限の確認
  • スクラッチ:初期開発、保守、将来改修の確認

独自の在庫引当や複雑な商流、特殊な料金・返品ルールがある場合には、個別開発が適する可能性があります。パッケージの拡張も含めて、契約変更や障害対応まで比べます。

SaaSとスクラッチを、クラウド費用と将来改修を含む3年間の総額で比べます。

開発期間はどのくらいかかりますか?

開発期間は、方式と連携範囲によって変わります。

  1. EC中心のSaaS導入は、即日〜2か月程度です。
  2. クラウド型の店舗・在庫連携は、2〜6か月程度です。
  3. ECパッケージは、4〜8か月程度です。
  4. 中規模のオムニチャネルは、6〜12か月程度です。
  5. 大規模な基幹刷新は、12〜18か月以上になる可能性があります。

中規模では、複数店舗やPOSとの連携に加えて、WMSやERPとの接続も含みます。会員統合や移行、並行稼働も対象に入ります。そのため、要件定義やデータ整備、店舗側の意思決定、受入テストの準備が遅れると、期間を短縮できません。

まとめ

初期費用は、EC中心なら数千円〜100万円程度です。店舗やPOS、在庫のクラウド連携では、100万〜800万円程度になります。

ECパッケージは300万〜1,500万円程度、中規模統合は500万〜3,000万円程度です。複数ブランドや基幹刷新を含む大規模案件は、3,000万円〜数億円になります。

いずれも、公開相場と類似案件から整理したレンジであり、確定価格ではありません。

連携・移行・運用まで含めた予算の作成

見積もりでは、要件定義や画面開発、POS・ERP・WMS・モールとの連携を分けて確認します。

  • 移行・運用:会員・商品・在庫・注文の移行、テスト、店舗教育、保守を分けること
  • 比較条件:クラウドと外部サービスを含めた、同じ条件での3社以上の比較

月額の安さだけでなく、3年間の総保有コストと、障害時の復旧担当も確認します。

KPIを確認しながら広げる段階導入

全チャネルをまとめて刷新する代わりに、データの正と優先KPIを決めて段階導入します。

  1. 店舗在庫表示や店舗受取など、検証しやすいユースケースから始めます。
  2. 自社に合う範囲を見極め、実行可能なRFPと予算に落とし込みます。

2024年の国内BtoC-EC市場規模は26.1兆円で、EC化率は9.8%です。これらは、経済産業省「令和6年度電子商取引に関する市場調査」による数値です(2025年公表)。

市場の伸びに急いで合わせるより、顧客体験と業務改善に結び付く範囲を見極めます。

▼全体ガイドの記事
・オムニチャネルシステム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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