結論：EC・通販業向け返品交換管理システムの費用は、SaaSなら初期設定を含めて10万〜100万円程度、
既存ECへの追加開発なら300万〜1,000万円程度、OMS・WMS・決済・会計まで統合する業務システムなら1,000万〜3,000万円程度が推定レンジです。
ただし、返品申請フォームだけを作るのか、返品可否の判定、返送、検品、再入庫、交換品の在庫引当、
返金、会計、分析までを一貫して管理するのかで、必要な費用は大きく変わります。本記事では、
2026年時点で確認できる公開料金と、類似するEC・受注・倉庫連携システムから整理した推定レンジを分け、
費用の内訳、変動要因、開発期間、コストを抑える進め方、見積もりの確認ポイントまで解説します。
▼全体ガイドの記事
・EC・通販業向け返品交換管理システム開発の完全ガイド
EC・通販業向け返品交換管理システムの費用相場はいくらですか？
結論から言うと、費用相場は導入方式と連携範囲で判断する必要があります。返品の受付とメール通知を早く整えたい企業はSaaS、
既存ECを活かしながら返品ポータルや返金連携を追加したい企業は追加開発、独自の返品規約や複数倉庫・会計まで統合したい企業は業務システム開発が候補です。
導入方式別に見る3つの価格帯
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
第一の価格帯は、返品特化SaaSや物流会社のサービスを利用するケースです。初期設定や業務整理まで含めた導入費は10万〜100万円程度、導入期間は2〜8週間が推定の目安です。
既存のEC、受注管理、倉庫システムに標準連携があり、返品ポリシーとメールを設定できる場合は、開発費を抑えやすいです。
ただし、月額料金、返品申請ごとの従量費、配送運賃、個別連携費は別に確認する必要があります。
第二の価格帯は、既存ECに返品・交換ポータルと管理画面を追加するケースです。
申請画面、注文照合、返品可否判定、限定的な在庫・配送・決済連携を含めて、300万〜1,000万円程度、期間は3〜6か月が推定レンジです。
ECチャネルが1つ、倉庫が1拠点、返品理由と返金方法が比較的単純なら下側に寄りやすいです。複数モールや交換商品の在庫引当まで含める場合は上側に寄りやすいです。
第三の価格帯は、OMS、WMS、決済、会計、CRMをまたぐ返品業務システムを構築するケースです。1,000万〜3,000万円程度、期間は6〜12か月が推定レンジです。
大規模な多ブランド・多拠点運用、海外配送、複雑な承認や厳格な監査、データ基盤まで含める場合は、3,000万〜8,000万円以上。9〜18か月になる可能性があります。
これらは返品管理専用の公表統一相場ではなく、要件に基づく推定です。
公開料金から分かる導入コストの下限
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
公開料金の例として、Recustomerとecforceの連携開始時に公表された情報では。
Recustomer返品・交換のBasicプランが月額16,500円（税込）から、基本料金内15件、超過分が返品申請1件あたり1,000円とされていました。
返品交換とキャンセルの両方を利用する場合は月額33,000円（税込）からという料金例も公表されています。
出典は株式会社SUPER STUDIO「ecforceとRecustomerのAPI連携」およびRecustomer公式料金ページです。
ただし、現在のRecustomer料金ページは利用サービスや課題に応じた提案方式です。したがって、この記事では永続的な現行価格と断定せず、SaaSを比較する際の公開料金例として扱います。
ヤマト運輸の返品・交換サポートサービスは、公式FAQで初期費用55,000円（税込）から、月額固定費11,000円（税込）。利用料がデータ1件あたり55円（税込）と案内されています。
受付フォームの構築費用と宅急便運賃は別途見積もりです。出典はヤマト運輸「返品・交換サポートサービスの利用料金を教えてください」です。
配送網や代替品発送まで任せたい企業にとっては、システムを全面開発する前に比較できる現実的な基準です。
EC-CUBEは本体を無料で利用できますが、カスタマイズや保守の費用は要件により異なり、開発会社からの提案になります。
公式ページに掲載されたクラウドECのStandardプランには、初期費用70,000円、月額49,800円から84,800円。
決済手数料別途という参考料金がありますが、新規登録受付停止中と記載されています。
出典はEC-CUBE公式「料金に関するFAQ」およびクラウドEC料金ページです。料金だけでなく、受付状況、返品機能の追加開発、データ移行、保守費用まで確認する必要があります。
EC・通販業向け返品交換管理システムの費用内訳は何ですか？
見積書では、画面の数だけでなく、返品の状態遷移と外部サービスとのデータ整合性を費用項目として分けることが重要です。
特に返品では、返金と在庫戻しが別々に完了するため、受付画面だけを安く作っても、後工程がExcelやメールのままだと期待したコスト削減につながりません。
要件定義・業務設計にかかる費用
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初に必要なのは、申請、本人確認、承認、返送、入荷、検品、再販・B品・廃棄・修理、交換出荷、返金、会計という状態遷移の整理です。
アパレルならサイズやカラー交換、食品や化粧品なら衛生上の開封条件、家電なら故障確認や修理判定、定期購入なら次回配送との関係を定義します。
この作業を省くと、後から例外ルールが増え、画面とAPIの作り直しが発生しやすいです。
要件定義では、月間注文数、返品率、月間返品件数、繁忙期のピーク、SKU数、販売チャネル数、倉庫数、決済方式、返品理由の分類を整理します。
さらに、1件あたりのCS対応時間、返金完了までの日数、在庫復帰までの日数を現状値として記録します。これらが分かると、SaaSの月額・従量料金と、開発して内製化する場合の工数を同じ土俵で比較できます。
画面・ワークフロー・外部連携の開発費
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
開発費の中心になるのは、顧客向けの返品交換ポータル、担当者向けの管理画面、ルール判定、交換品の在庫引当、返金額の計算、メール通知、監査ログです。
写真や動画を受け付ける場合は、ファイル保管、容量制限、個人情報の取り扱い、悪意のあるファイルへの対策も必要になります。
高額商品の返品や規約外の返金は、人が承認してから実行できるHuman in the Loopを残す設計が安全です。連携先は、ECカート、楽天市場やYahoo!
ショッピングなどのモール、Amazon、自社EC、OMS、WMS、3PL、配送会社、決済代行会社、会計、CRMに分かれます。
単に注文を取り込むだけでなく、返品受付番号、返品ステータス、入荷実績、検品結果、在庫の扱い、返金完了を双方向に書き戻す必要があります。
API、Webhook、CSV、手動登録の境界を先に決めると、連携開発費と運用費を見積もりやすいです。
データ移行・テスト・教育にかかる費用
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
過去の返品履歴を分析したい場合は、注文、顧客、商品、SKU、在庫、返品理由、返金のデータを移行します。項目名やコード体系がEC、WMS、会計で異なると、変換ルールの設計と検証が必要です。
特に同じ商品でも色やサイズのSKU表記が違うと、交換在庫の引当を誤るため、マスタの統合は画面開発と別の作業として見積もる必要があります。
テストでは、通常返品だけでなく、期限切れ、開封済み、セール品、欠品、交換品の在庫不足、部分返金、送料負担の違い、倉庫での検品不良、決済APIの失敗。Webhookの重複通知まで確認します。
返金と在庫戻しが片方だけ成功した場合の復旧手順も必要です。現場向けの操作教育、マニュアル作成、リリース後の問い合わせ窓口、障害時の手動運用も初期費用または保守費用に含めて比較します。
返品交換管理システムの費用が変動する要因は何ですか？
同じ返品管理システムでも、月間返品件数だけで価格は決まりません。実務上は、連携するデータの種類、
例外ルールの多さ、倉庫の運用、セキュリティと可用性の水準、海外や複数ブランドへの拡張性が見積もりを左右します。
次の項目をRFPに明記すると、会社ごとの金額差を説明しやすくなります。
チャネル数・返品件数・倉庫数
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
自社ECだけなら注文照合の経路を絞れますが、モールや店舗をまたぐと注文番号、顧客情報、決済、配送伝票、返品可否の扱いが異なります。
月間返品件数が少なくても、ピーク時に短時間で集中するなら、キュー処理や在庫の仮引当が必要になる場合があります。
倉庫が複数あると、返送先の出し分け、入荷予定、検品結果、再入庫先を管理するための連携が増えます。
返品ポリシーと例外ルールの複雑さ
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
「購入から何日以内か」「未使用か」「タグがあるか」「衛生商品か」「セール品か」「初期不良か」「顧客都合か」を条件にして自動判定するほど。ルールエンジンの設計が必要です。
送料を誰が負担するか、返金ではなく交換やストアクレジットを提案するか、差額決済を行うかも価格に影響します。
自由記述だけで処理すると自動化しにくいため、選択式の理由、商品状態、写真の有無をデータ項目として設計することが重要です。
返品特約は、広告と注文確定直前の最終確認画面で、返品や解除の条件を顧客が認識できるように表示する必要があります。
消費者庁「通信販売広告Q&A」および「通信販売における最終確認画面について」でも。
通信販売の最終確認画面で申込内容を容易に確認・訂正できない表示が問題になることや、返品特約を明瞭に表示する必要があることが案内されています。
システムの自動判定と画面表示が規約と一致するようにすることは、法務対応だけでなく、後からの個別判断を減らすコスト最適化にもつながります。
セキュリティ・可用性・監査の水準
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
返品管理では、氏名、住所、購入履歴、配送先、返金先、問い合わせ内容、商品画像を扱う可能性があります。
担当者ごとの権限、管理画面の多要素認証、通信時と保存時の暗号化、APIトークンの保管、操作ログ、バックアップ、復旧手順。脆弱性診断をどこまで求めるかで費用が変わります。
SaaSなら事業者の認証方式、データ保管場所、ログの取得範囲、障害時の手動運用を確認します。
IPAの「ECサイト構築・運用セキュリティガイドライン」は、個人情報への安全管理、二要素認証、ログやバックアップの保管・保護などを確認項目として示しています。
また、経済産業省が2025年3月に公表したクレジットカード・セキュリティガイドラインの改訂は、カード情報の漏えい・不正利用防止を扱う事業者に関係します。
出典はIPA「ECサイト構築・運用セキュリティガイドライン」および経済産業省「クレジットカード・セキュリティガイドライン改訂」です。
返品システム側ではカード情報を保持せず、PSPの返金APIを利用する設計を優先すると、リスクと保守対象を抑えやすいです。
費用を抑えながら開発する進め方はどうなりますか？
最初からすべてのチャネルや例外を作り込むと、初期費用と納期が膨らみます。返品の件数を減らすことだけを目的にせず、
適切に受け付け、処理を速め、返品理由を商品改善や再購入につなげる循環を作ることが重要です。
小さな範囲で効果を測り、成果が確認できた機能だけを広げる進め方が適しています。
現状の工数を測り、1チャネルで実証する
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
まず、メール、電話、Excelで対応している返品の流れを、担当者と倉庫担当者に聞き取ります。
返品1件あたりの確認時間、差し戻し回数、返金までの日数、在庫が戻るまでの日数、問い合わせの再発回数を記録します。
費用対効果は、システム料金だけでなく、削減できるCS工数、返金の遅れによる問い合わせ、在庫復帰の遅れ、交換に転換できる件数を含めて判断します。
そのうえで、1ブランド、1チャネル、1倉庫を対象に、返品申請、注文照合、返品可否判定、返送案内、検品結果、返金または交換までを90日程度実証します。
評価指標は、返品受付から承認までの時間、返金完了日数、在庫復帰日数、問い合わせ削減率、交換転換率、1件あたり処理コスト、誤判定率です。
数字を取らないまま全社導入すると、便利になった印象だけで追加投資を判断することになります。
標準機能を先に使い、競争上必要な部分だけ作る
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
SaaSやパッケージの標準機能で、注文番号による本人確認、申請受付、メール通知、返品理由の収集、返金ステータスの管理ができるなら、そこを活用します。
独自開発の対象は、自社の競争力に直結する返品ポリシー、複雑な交換・差額処理、特有の倉庫判定、複数ブランドのルーティングなどに絞ります。
標準画面を無理に全面改修するより、APIやWebhookで必要なデータだけを連携する方が、初期費用とアップデート対応を抑えられる場合があります。
一方で、標準SaaSの月額が安く見えても、個別API、追加ユーザー、返品件数の従量費、データ保管、配送、決済、サポートが積み上がることがあります。
3年程度の利用期間を仮定し、初期費用、月額、従量費、開発費、保守費、移行費を合算した総保有コストで比較します。短期間で始める価値と、将来の制約を合わせて判断することが大切です。
データ定義と人の承認範囲を先に決める
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
商品、注文、顧客、在庫、返品理由の定義がシステムごとに違うと、連携のたびに変換処理が必要になります。
最初に商品コード、注文番号、返品受付番号、返品理由、商品状態、送料負担、返金方法、交換先SKU、会計処理の項目を共通化すると。将来のチャネル追加にかかる費用を抑えやすいです。
自由記述を残す場合も、分析に必要な選択項目と分けて保存します。AIによる返品理由の分類や不正返品のスコアリングを検討する場合も、高額返金、規約外対応、品質に関わる判定は担当者の承認を残します。
自動化の範囲を明確にしておけば、全件を人が確認するコストと、誤判定による返金・在庫損失のリスクを比較できます。
人が確認するケースだけを管理画面に集約することが、現場の負担と開発範囲の両方を抑えるポイントです。
見積もりを取る際に確認すべきポイントは何ですか？
複数社に同じ条件で相談するには、機能一覧だけでなく、返品業務の状態遷移、連携先、
件数、例外、非機能要件を一枚に整理します。見積金額の安さだけで決めると、データ移行やテスト、
保守、配送・決済の従量費が後から追加されるため、初期費用と運用費を分けて確認します。
見積書で分けてもらうべき項目
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
要件定義、業務設計、画面設計、フロントエンド、管理画面、ルール判定、EC・OMS・WMS・決済・会計とのAPI連携、データ移行、インフラ。
セキュリティ診断、テスト、教育、リリース支援を分けて記載してもらいます。
各項目には、対象画面数や連携本数ではなく、処理する状態とエラー時の動きを含めます。曖昧な「返品対応一式」だけの見積もりは、比較しにくく追加費用の原因になります。
運用費は、月額利用料、保守、監視、バックアップ、問い合わせ対応、追加ユーザー、API利用、返品申請の従量費、配送運賃、決済手数料、ストレージ。外部サービスの契約費に分けます。
さらに、仕様変更、チャネル追加、OSやAPI仕様変更、障害対応、データ修正の単価や契約範囲も確認します。
料金表に載っていない個別連携やフォーム構築が別見積もりになるサービスもあるため、公開料金を総額と誤認しないことが大切です。
開発会社・サービスの選び方
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
候補を比較するときは、返品特化SaaS、ECパッケージ、物流会社や3PL、スクラッチ開発会社を同じ「安さ」だけで並べないようにします。
返品申請から返金までをSaaSで早く始めたいのか、倉庫の検品・再入庫まで物流会社に任せたいのか、既存基幹と独自ルールを深く統合したいのかで。評価軸が違うためです。
連携実績、API仕様、Webhookの再送、在庫引当の整合性、障害時の手動運用を確認します。提案時には、自社の返品業務を実際のテストデータで再現してもらいます。
たとえば、アパレルのサイズ交換、購入者都合の返金、初期不良、交換品の欠品、返品期限超過、部分返金を一連のシナリオにします。
デモで入力できても、倉庫入荷後の検品結果が在庫と会計に正しく反映されなければ本番運用には使えません。現場担当者、CS、物流、経理、情報システムの全員で確認することが重要です。
費用を増やす失敗を避ける確認事項
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
典型的な失敗は、受付フォームだけを自動化し、返品予定と倉庫の入荷、返金、会計を手作業に残すことです。
次に、返品理由を自由記述だけで集めて分析できないこと、返品規約とシステム判定が一致しないこと、AIに高額返金を無承認で実行させることもあります。
これらは導入後に再開発や運用見直しが発生し、初期費用より高い追加コストになる場合があります。
見積もり段階で、返金の最終承認者、返品品の状態区分、在庫を戻すタイミング、返送中の仮在庫、例外時の担当者、API停止時の手動手順を決めます。
要件をすべて固定する必要はありませんが、未確定の項目は「別途見積もり」ではなく、想定する幅と決定時期を明示します。これにより、安い初期見積もりと高い追加請求の差を小さくできます。
よくある質問（FAQ）
ここでは、EC・通販業向け返品交換管理システムの費用を検討する企業から寄せられやすい質問に回答します。
金額だけでなく、どの範囲を自動化するか、将来の連携や運用をどう見込むかを確認することが判断のポイントです。
返品件数が少なくてもシステムを導入する価値はありますか？
あります。返品件数が少なくても、1件あたりの確認や返金に時間がかかる、問い合わせが多い、
返金や在庫戻しのミスが起きる場合は、SaaSの小規模プランや標準機能から始める価値があります。
月額と従量費だけでなく、削減できる対応時間、返金の早期化、交換への転換、顧客の再購入まで含めて判断します。
SaaSとスクラッチ開発はどちらが安いですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
初期費用だけなら、標準機能を使えるSaaSが安く始めやすいです。
一方で、複数のEC・モール、独自の返品規約、OMS・WMS・会計との深い連携、特殊な承認フローがある場合は。個別開発やスクラッチの方が業務に合う可能性があります。
月額、従量、連携費、保守、移行費を含む数年分の総額と、業務を変更する負担を合わせて比較します。
返品管理システムで見落としやすい費用は何ですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
見落としやすいのは、APIやWebhookの個別連携、データ移行、返品フォーム構築、配送運賃、返品申請の従量費、決済の返金手数料、ストレージ。セキュリティ診断、テスト、現場教育、リリース後の保守です。
ヤマト運輸の公開料金でも、受付フォーム構築費と宅急便運賃は別途見積もりとされています。公開されている基本料金を総額とせず、導入から運用までの費用を一枚にまとめて確認します。
見積もり依頼前に何を準備すればよいですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
月間注文数と返品件数、返品率、ピーク時の件数、販売チャネル、倉庫、利用中のEC・OMS・WMS・決済・会計、返品規約、返品理由、返金方法。交換の有無を整理します。
現場のメールやExcelのサンプル、返品1件の処理手順、例外ケースも共有できると、開発会社は画面数ではなく業務の複雑さを見積もれます。
さらに、90日実証で測るKPIと、初回リリースに含めない機能を決めておくと、提案の比較がしやすいです。
まとめ
EC・通販業向け返品交換管理システムの費用は、SaaSの導入設定で10万〜100万円程度、
既存ECへの追加開発で300万〜1,000万円程度、OMS・WMS・決済・会計まで含む業務システムで1,000万〜3,000万円程度が推定の目安です。
多ブランド・多拠点、海外配送、厳格な監査やデータ基盤まで含める場合は、3,000万〜8,000万円以上になる可能性があります。
金額は連携範囲と運用まで含めて比較します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
公開料金には、SaaSの基本料金、返品申請ごとの従量費、物流サービスのデータ利用料などがありますが、フォーム構築、個別API、配送運賃、決済。保守は別になる場合があります。
見積もりでは、受付だけでなく、返品可否、返送、検品、再入庫、交換出荷、返金、会計、分析、監査までの状態遷移を対象にし。初期費用とランニングコストを分けて確認します。
まずは小さく測定し、返品体験と利益の両方を改善します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初に現状の返品工数と返金・在庫復帰の遅れを測り、1チャネル・1倉庫で実証し、交換転換率や1件あたり処理コストを確認します。
標準SaaSで足りる部分は活用し、独自ルールや競争力に直結する連携だけを開発することで、導入スピードと将来の拡張性を両立しやすくなります。
返品を単なるコストではなく、再購入につながる購入後体験として設計することが、投資効果を高めるポイントです。▼全体ガイドの記事
・EC・通販業向け返品交換管理システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。