店舗POS連携システムの費用は、連携範囲、店舗数、POSや決済との接続方法によって、約50万〜2,000万円以上まで変わります。
金額の差は、連携範囲と店舗数、接続方式の組み合わせで生まれます。構成別の価格帯や費用の内訳を知っておくと、見積もりを比べる目安になります。
▼全体ガイドの記事
・店舗POS連携システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
店舗POS連携システムの費用相場
初期費用の目安は、CSVで取り込む小規模な構成から、POS・EC・基幹システムを統合する構成まで、約50万〜1,200万円です。この額は税別の概算で、連携項目と運用の責任範囲によって変わります。
構成別の価格帯
構成別の価格帯は、売上集計、在庫管理、本部管理のどこまでを連携するかで決まります。連携する範囲が広がるほど、見積もりの価格帯も上がります。
- 売上集計：売上を本部で集める範囲
- 在庫管理：売上に在庫の動きを加えた範囲
- 本部管理：本部側の機能まで広がる構成
最小構成は、既存POSの売上データをCSVで受け取り、本部で店舗別・商品別に集計する仕組みです。公開されている多店舗管理システムの機能別相場では、売上集計は約50万〜200万円、期間は1〜3か月が目安とされています。
CSVの定型取込だけなら下限に近づきやすい一方、POS APIから自動取得してレポートまで作る場合は、100万〜200万円程度へ上がりやすくなります（出典：GXO「多店舗・多拠点管理システム開発の費用相場」、2026年確認）。
在庫をまとめて管理する構成では、POSの売上だけでなく、入荷や返品、店舗間移動、棚卸、EC在庫との同期まで扱います。扱う範囲が広がるぶん、目安は約150万〜600万円です。対象店舗や商品マスタの複雑さ、同期のリアルタイム性によって変わります。
本部ダッシュボードや権限管理、エラー再処理まで含めた場合は、約300万〜1,200万円の統合管理案件として見積もられるケースもあります。
スクラッチ開発と既製POSの価格差
スクラッチ方式では、POSレジの画面や商品登録、会計、在庫、決済、周辺機器の制御まで、一から開発します。費用は、規模の違いと、既製POSを使う方式の違いで分けて見ます。
- 小規模：単店舗で、機能を絞った構成
- 中規模：機能が増え、複数店舗に対応する構成
- 既製POS：連携基盤と本部画面に開発範囲を絞る方式
目安は、単店舗・シンプル機能の場合で約100万〜500万円です。中規模の多機能・複数店舗対応では約500万〜2,000万円、大規模チェーンや基幹連携を含むと2,000万円以上になります。
上記の数字の出典は、株式会社ripla「POSシステムの見積相場や費用／コスト／値段について」（2026年確認）です。これはPOS連携だけの価格ではなく、POS本体の開発を含む価格帯です。
既製のクラウドPOSやパッケージを使えば、連携基盤と本部画面に開発を絞れるぶん、初期費用を抑えられます。一方で、月額ライセンスや店舗・端末課金は継続して発生します。API利用条件やオプション、保守費も、続けて見込む必要があります。
参考として、BCPOSはソフト月額5,000円から、機器セットは税抜22万4,000円からです。これは製品の価格であり、市場相場ではありません。出典はビジコム「クラウド連動POSレジ BCPOS」（2026年確認）です。
公開事例に見る連携の範囲
費用を考える際は、レジ端末だけでなく、どこまでデータ活用基盤を作るのかを思い描くと役立ちます。公開事例は、そのイメージをつかむ手がかりになります。
- POSとEC：異なる系統のデータを一つにまとめる連携
- 店舗とオンライン：融合した顧客体験の設計
- 費用の見方：端末以外の設計範囲まで含めて見ること
2025年2月、NECとダイアナは、POSレジやECサイトなどの各種データを統合・活用するデータ活用基盤を構築しました。あわせて、店舗とオンラインが融合するOMO施策を進めると発表しました。
出典はNEC「ダイアナとNEC、店舗とオンラインが融合した次世代の顧客体験を提供する施策を加速」（2025年）です。
この事例からは、POS連携の費用がレジ端末の購入費だけで決まるわけではないことが分かります。POSとECのデータモデル、顧客体験、店舗業務、本部での分析を横断して設計するほど、要件定義やデータ統合、権限、運用支援の範囲が広がります。
自社で「売上を集計したい」のか、「店舗とECの在庫・顧客体験をつなぎたい」のかを先に決めると、必要な価格帯を絞り込めます。
店舗POS連携システムの費用内訳
見積書が「開発一式」だけだと、導入後や店舗展開時にかかる費用を見落としやすくなります。そのため、費用はソフトウェア、連携設定、移行に分け、さらに端末・通信、教育・導入、保守・運用も別々に見ます。そのうえで、3〜5年のTCO（総保有コスト）で比べます。
要件定義・開発・テスト・導入支援の費用比率
公開されているPOS開発費の内訳目安は、工程ごとに次のとおりです（出典：株式会社ripla「POSシステムの見積相場や費用／コスト／値段について」、2026年確認）。
- 要件定義・設計：開発費の10〜20％が目安
- 開発：開発費の50〜60％が目安
- テスト・導入：テスト15〜20％、導入10〜15％
たとえば、開発費が500万円なら、要件定義・設計は約50万〜100万円、開発は約250万〜300万円です。テストは約75万〜100万円、導入支援は約50万〜75万円になります。実機テストや業務例外によって、この割合は変わります。
通常のWebシステムより業務例外が多いことも、要件定義とテストの工数を押し上げる要因です。例外には、返品や取消、値引のような取引処理と、税率や締め処理があります。
ハードウェア・移行・運用費の見込み
ハードウェア費用に含まれるのは、タブレットまたはPOS端末、バーコードスキャナー、レシートプリンターです。ほかに、キャッシュドロアやカードリーダー、自動釣銭機なども含まれます。
- 機器費：端末や周辺機器の台数で変わる初期費用
- 移行・導入：データ移行と設定、設置、研修の費用
- 運用費：保守と回線、API利用料や決済手数料にかかる費用
POS機器は1台数万〜数十万円で、BCPOSのセットは税抜22万4,000円からです。ほかに、旧POSの商品と店舗のデータ、会員と在庫のデータを移す費用がかかります。コード変換や設定、設置、研修も費用に含まれ、台数が決まっていないと総額を低く見積もることになります。
保守費用は、開発費の年10〜20％が目安として紹介されることがあります。ただし、24時間監視や休日対応、法改正対応を含むかで金額は変わります。POSメーカーの追加や現地駆け付けを含むかどうかでも、差が出ます。
クラウド費、店舗回線、API利用料、決済手数料も、月額または取引量に応じて発生します。
店舗POS連携システムの見積額が変わる要因
店舗POS連携の価格差は、画面の数よりも、データの種類と連携方式で生まれます。障害時の運用や店舗展開の規模も、金額の差に関わります。次の3点を押さえると、各社の金額を比べる際に役立ちます。
- 店舗規模：店舗数やPOS台数、メーカー数によって展開費が変わる
- 連携方式：API、CSV、Webhookによる実装と運用の負担の差
- 業務ルール：返品、取消、通信断への対応範囲が費用を左右
店舗数・POS台数・POSメーカー数が費用に与える影響
1店舗1台の検証と、100店舗500台の展開では、同じ連携機能でも必要な設計と運用が変わります。
- 店舗数：展開のたびに手間と作業量が増える
- POS台数：端末設定や現地作業の範囲が広がる
- メーカー数：仕様を吸収するアダプターが必要になる
店舗数が増えると、店舗コードの管理、端末設定、回線確認の作業が加わります。さらに、現地作業と教育の費用に加えて、問い合わせ対応や段階リリースの費用も必要になります。
複数のPOSメーカーが混在する場合は、メーカーごとのAPI仕様やCSV形式を吸収するアダプターが必要になり、初期開発だけでなく将来の保守費も増えやすいです。
ただし、すべての店舗に同じ機能を一度に入れる必要はありません。1店舗のPoC、数店舗のパイロット、全店展開の順に分ければ、初期の検証費を限定できます。
見積書でも「共通基盤の費用」と「店舗または端末を増やすごとの展開費」を分けてもらうと、将来の予算を立てやすくなります。
API・CSV・Webhookと連携先の違い
連携方式は、費用と運用のしやすさを左右します。たとえば、定型CSVを一日一回取り込む方式は、リアルタイム性を求めない売上集計に向いていて、比較的安く始めやすいです。
- CSV：定型データの取り込み
- API：自動取得や更新
- Webhook：受信側の設計まで含める方式
API連携は自動取得や更新がしやすい一方で、認証、レート制限、エラー処理への対応が必要です。仕様変更への追随も欠かせません。Webhookを使う場合は、受信失敗時の再送、重複防止、イベント順序の扱いを設計します。
たとえばスマレジのプラットフォームAPIは、HTTPS上でGETやPOSTを使います。PUTやPATCH、DELETEも使われます。POSを含む各プロダクトのデータへ、外部システムからアクセスできます。
公開仕様には、本番環境の参照系APIが最大50回／秒、更新系APIが最大20回／秒と記載されています。一方で、利用条件や仕様が変更される可能性も示されています（出典：スマレジ・プラットフォームAPI共通仕様、2026年確認）。
APIが公開されているかどうかに加えて、必要なデータ項目と契約プランまで確認しておくと、費用の判断材料になります。
返品・取消・通信断などの業務ルール
売上の連携だけなら簡単に見えても、返品や取消、値引、税率変更が加わると難易度は上がります。さらに、現金とキャッシュレスの締め、ポイント利用、店舗間移動が重なると、扱いはいっそう複雑になります。
- 取引処理：返品、取消、値引、税率変更の扱い
- 再処理：二重計上の防止と、失敗データの再送
- 通信断：止まっている間の取り扱い
冪等性、再送、日次突合を省くと、運用と障害対応の費用が増えます。通信断時の会計継続や、復旧後の正データの扱いを決めておくと、単なる転送より費用は高くても、業務停止を防げます。監査ログやアラート、承認も決めておく必要があります。
見積もりの金額が安いときは、重要な異常系が除外されていないかを確認します。
店舗POS連携システムの開発期間
開発期間の目安は、売上集計が1〜3か月、在庫をまとめて管理する構成が2〜5か月、統合と段階導入が4〜12か月です。期間を見る際は、要件定義やAPI調査、実機の確認を含めます。
移行やパイロット、全店展開の時間も含めて確認すると、期間の見通しが立ちやすくなります。
最短で進めるための最小構成
最短で進めるには、対象を1店舗、1種類のPOS、売上・商品・在庫の最小項目に絞り、PoCを行うことが鍵になります。
- 対象店舗：まずは1店舗に絞る
- 連携項目：売上・商品・在庫を優先する
- 検証内容：実際のデータでの動きを確かめる
画面を新しく作る前に、既存POSのサンプルデータを取り出せるかを確かめます。店舗コードと商品コードをそろえ、日次の突合までできるかも見ておくと、後の手戻りを減らせます。
通信断や返品の検証も最初に行えば、全店展開の後に高額な作り直しが発生するリスクを下げられます。
PoCでは、画面だけでなく連携項目と再処理、正データまで形に残し、照合作業と切戻し条件も書き留めます。PoCの内容を本番開発の一部として使うと、要件の不確実性が減り、見積もりの精度が上がります。
店舗展開を段階化する方法
全店を一斉に導入すると、短期間で切り替えられる反面、障害が全店舗へ波及します。
- 1店舗：現場条件を検証する段階
- 数店舗：業態、回線、端末の違いを確かめる段階
- 全店：基準を満たしたうえで拡大する段階
まず現場条件の異なる1店舗で検証し、次に数店舗で業態・回線・端末の差を確かめます。そのうえで、本部と全店へ拡大していく方法が現実的です。
各段階では、売上と在庫の突合率や処理時間を確認します。問い合わせ件数や未処理エラーも見て、次の段階へ進む基準を決めておきます。
大規模案件では、POSメーカーや決済会社との調整が必要になります。店舗や経理、情シスも関わるため、調整の範囲は広がります。
機器の納品やアカウント発行、審査、教育を全体日程に含めます。繁忙期を避けた切替日も、同じ日程表に入れます。
店舗POS連携システムの費用を無駄なく抑えるポイント
コストを抑えるとは、必要な連携を残して手戻りを減らすことです。使わない機能や重複する画面は省けますが、初期費用だけを下げて障害対応や手入力を増やすと、現場の人件費を含むTCOが高くなります。
既存POSと標準APIの活用
POS本体を交換する前に、現在のPOSがどの連携手段を備えているかを確かめます。
- 公式連携：API、Webhook、認定CSVの有無
- 開発範囲：連携基盤と本部側に絞る範囲
- 責任範囲：保守と終了条件の明記
既存POSを残し、連携基盤と本部側のデータマートだけを開発するハイブリッド方式なら、レジ画面や決済端末を一から作る費用を避けられます。
連携方式を決める前に、APIを使える契約プランや取得できる項目を確かめておく必要があります。レート制限や仕様変更時の通知方法も、あわせて確認しておきましょう。
ただし、POSのデータベースへ直接つなぐ方式は、製品更新時の互換性や保守の責任があいまいになりやすいです。短期的には安く見えても、将来のアップデートで連携が止まり、再開発費が発生するおそれがあります。
原則として標準の連携方式を優先し、例外的な方式を選ぶ場合は、保守の範囲と終了条件を契約書に書き込みます。
連携項目とリアルタイム性の優先順位
同期の速さは、データごとに分けて考えられます。月次の分析用データは夜間バッチで足りる場合がある一方、遅れが許されないデータは別に扱う必要があります。
- 即時性が必要なデータ：店舗受取の在庫を優先
- 遅延を許容できるデータ：分析は夜間バッチで足りる
- 段階導入：売上と在庫から広げていく進め方
売上から会計まで、各データについて更新頻度や許容遅延を決めておきます。送信方向と障害時の代替運用も、あわせて決めます。こうすると、過剰なAPI処理やインフラ費を避けられます。
第一段階では、売上と在庫の正確な連携、本部集計、エラー再処理に絞ります。高度なCRMやAI分析は、最初の段階では実装しません。
第二段階で顧客・ポイント・EC施策を加えるように分ければ、投資判断をしながら拡張できます。
要件を削るときでも、正確性と業務継続に関わる機能は優先して残します。返品や取消、締め処理、監査ログがその例です。
TCOと保守範囲による比較
見積もりを比べるときは、各社の金額を同じ形式にそろえることが欠かせません。初期開発費と端末費、月額ライセンスとクラウド費は、項目ごとに金額を並べて比べます。回線費やAPI利用料、決済手数料も、同じ並びで確認します。初期と継続の費用、保守の範囲も、同じ書き方で確認します。
- 初期費用：開発、端末、移行、教育を分けた内訳
- 継続費用：月額、通信、API、決済、保守の各費用
- 保守範囲：障害や制度変更への対応の差
月額が安くても、APIの追加利用や店舗の追加によって従量課金が増えることがあります。反対に、初期費用が高くても、標準機能や運用監視が含まれていれば、5年間のTCOが低くなる場合があります。
保守契約では、障害の受付時間や一次回答の期限、復旧目標を確認します。仕様変更への対応も見ておくと、契約後の認識違いを減らせます。
保守費や店舗展開費は、同じ形式で確認します。教育費やデータ移行費も、あわせて見ておきます。
セキュリティパッチや税率、インボイス制度への対応も、対象に入っているかを見ます。POSメーカー側の変更が起きたときに、どちらがどこまで対応するかも確認します。
国税庁は、適格請求書等保存方式について、一定事項を記載した帳簿と適格請求書などの保存を仕入税額控除の要件として示しています。そのため、レシートや帳票の仕様は、自社の取引形態に合わせて確認しておく必要があります（出典：国税庁「No.6498 適格請求書等保存方式」、令和7年4月1日現在法令等）。
店舗POS連携システムの見積もりを取る際のポイント
見積もりを依頼する際は、現状と目標、データの流れを明記します。店舗数やPOS台数、連携先も書き添えると、会社ごとの前提がそろいます。更新頻度や異常時の運用、希望時期も記載すると、前提をさらにそろえられます。
見積もり前に整理する項目
見積もりの前に情報を整理しておくと、各社が同じ前提で金額を出せます。最低限、店舗数と今後の増加予定、POSメーカー・機種・台数を整理し、商品点数と1日の取引件数も書き添えます。整理する項目は、店舗、連携、運用の面に分けると分かりやすくなります。
- 店舗情報：店舗数や増加予定、POSの機種と台数
- 連携条件：取り込む項目と、APIやCSVの有無
- 運用条件：更新頻度、通信環境、決済方式
連携では、取り込みたい項目と連携先システムを挙げるところから始めます。リアルタイム性が必要かどうかは業務によって違うので、データごとに分けて書いておくと、見積もりの前提が伝わりやすくなります。
追加費用になりやすいのは、業務ルールの扱いです。返品や取消、値引、締め処理の扱いを記載します。さらに、棚卸と店舗間移動、EC注文も書いておきます。
予算は、初期開発や端末設置、移行教育、月額保守に分けます。そのうえで、必須・できれば・将来拡張の層で整理し、各層の費用、期間、前提条件、除外項目を提示してもらいます。
2〜3社以上で比較する方法
候補会社には同じ前提を渡し、総額だけでなく、見積もりの粒度と質問の内容を比べます。
- 同じ条件：要件書とサンプルデータを統一
- 実装経験：POS業務と既存POS連携の実績を見る
- 運用設計：実機テストとエラー再処理の考え方を比べる
各社の経験は、POSや店舗業務の実績、既存POSを残した連携の実績で確認できます。そのうえで、実機テストの範囲や日次突合の設計まで聞いておくと、比べる材料がそろいます。
大規模チェーンでは、店舗展開と24時間の障害連絡体制も選定条件になります。
価格差が大きいときは、前提と除外項目を見比べます。見積もりによっては、片方がAPI調査や移行、教育、現地設置を含み、もう片方は開発だけということがあります。
提案書には、要件定義で作るもの、テストの項目、データ移行の責任を書いてもらいます。受入基準や切戻しの手順、保守の範囲も明記してもらうと、発注後の追加請求や認識違いを抑えられます。
決済・個人情報・法対応の確認
決済まわりは、セキュリティ設計と保守範囲を大きく左右します。
- 決済方式：保存方法と端末連携で、誰がどこまで担うか
- 個人情報：権限や暗号化、ログ、保存期間の取り決め
- 法対応：PCI DSSと個人情報保護の措置を具体化
カード情報を自社データベースに保存する場合と、決済事業者のトークン化を使う場合とでは、取り扱いが大きく異なります。カード番号を自社で持たない構成でも、PCI DSSの対象がどこまで及ぶかは、決済方式とシステム構成によって変わります。
PCI Security Standards Councilは、2025年3月31日からPCI DSS v4.0.1の一部要件が有効になると案内しています。契約前に、決済事業者と開発会社との対応範囲を早めに確かめておく必要があります（出典：PCI Security Standards Council、2025年1月・3月の案内）。
会員情報や購買履歴を連携する場合は、まず利用目的を決めておく必要があります。委託先の管理と削除方法も、あわせて決めておきます。
個人情報保護委員会は、個人情報保護法の法令やガイドラインを公開しています。「セキュリティ対応済み」という表記だけでは内容を判断しにくいため、自社のデータ利用と委託関係に照らして確かめておきます。
セキュリティと法対応を後付けにすると、追加開発とリリース延期の原因になります。
店舗POS連携システムについてよくある質問
費用を検討すると、既存POSを残せるか、CSVで足りるか、月額費用をどう見るかといった疑問が出てきます。見積もりの前に質問されやすい内容を、順に取り上げます。
既存のPOSを使ったまま連携できますか？
はい、公式API、Webhook、認定CSVなどの連携手段があれば、既存POSを使ったままEC、在庫、会計、CRMなどへデータを連携できます。
POS本体を交換する必要がないため、端末購入や店舗教育の費用を抑えられる可能性があります。ただし、APIで取得できるデータ項目と更新頻度を確認し、契約プランや返品・締め処理の扱いも見てから判断します。
CSV連携とAPI連携はどちらが安いですか？
一般には、定型CSVを決まった時間に取り込む方式のほうが、リアルタイムAPI連携より初期費用を抑えやすいです。ただし、CSVの作成やアップロードを人が行う場合は、運用の人件費と入力ミスが発生します。
店舗受取や在庫表示のように即時性が必要な業務はAPI、日次集計で足りる業務はCSVにすると、用途ごとに費用と効果のバランスを取りやすくなります。
店舗POS連携は100万円以内でできますか？
既存POSのCSV集計だけなら、約50万〜100万円の可能性があります。API連携や在庫、複数店舗への対応を含むと、100万円超が一般的です。
エラー再処理や実機テスト、現地導入まで含めて見積もる場合は、店舗数やデータ量、運用条件を確認します。
POS連携の費用は初期費用だけ比較すればよいですか？
初期費用だけでなく、3〜5年のTCO（総保有コスト）で比べます。TCOには、月額や通信、API、決済のような継続費用に加えて、端末交換や保守が含まれます。
法改正や店舗追加、障害対応も、比べる対象になります。決済手数料は取引量に応じて発生するため、売上規模が大きいほど継続費用への影響が大きくなります。
まとめ
店舗POS連携の目安は、売上集計だけなら約50万〜200万円（CSV取込のみなら下限寄り）です。在庫管理まで含めると約150万〜600万円、本部管理やEC等まで統合すると約300万〜1,200万円になります。
POS本体をスクラッチ開発する場合は、規模に応じて約100万〜500万円、約500万〜2,000万円、2,000万円以上になります。いずれも税別の概算で、店舗数や連携先、APIの有無によって変わります。決済や実機、データ移行、保守範囲でも差が出ます。
最適な進め方は、まずPOSを作り直すのか既存POSを連携するのかを切り分けることです。売上・商品・在庫の最小構成で、1店舗のPoCから始めます。
返品や取消、締め処理、通信断を検証し、再送や日次突合、権限・監査ログも確かめます。そのうえで、数店舗から全店へ段階的に広げます。
見積もりは初期費用だけでなく、3〜5年のTCOで比べてください。月額や決済の費用は、継続して発生するぶん総額に響きます。導入後や店舗展開時にかかる費用は見落としやすいため、次の項目が総額に入っているかを確かめます。
- 端末：POS端末や周辺機器の初期費用
- 通信：店舗回線にかかる費用
- 保守：障害対応や法改正対応を含むかで変わる費用
- 教育：研修や導入時の教育にかかる費用
- 法対応：税率やインボイス制度、PCI DSSへの対応
要件書には、店舗数やPOS台数、メーカー、連携データを書きます。更新頻度や障害時の業務、移行範囲、受入基準も記載し、2〜3社以上へ同じ条件で相談します。
開発会社は、店舗業務やPOS・決済の担当範囲、実機テスト、導入後の監視と再処理まで提案できるかで選びます。費用の安さだけで決めず、こうした提案力を見極めることが、長期的なコストの抑制につながります。
▼全体ガイドの記事
・店舗POS連携システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。