電子マネーシステムの初期費用は0〜15万円から5,000万円以上までと幅があり、導入方式、対応範囲、取引量によって変わります。
方式別の費用相場、費用を動かす要因、開発の進め方を、この順にたどります。全体像は電子マネーシステム開発の完全ガイドにもまとめています。
▼全体ガイドの記事
・電子マネーシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
電子マネーシステムの費用を考える前の全体像
電子マネーシステムは、一つの製品名ではなく、複数の仕組みをまとめた呼び方です。費用が分かれる最初の分岐は、既存ブランドを受け付けるか、自社残高を発行するかです。この前提を曖昧にしたまま見積もりを取ると、会社ごとに条件が変わり、金額を比べられません。
受け付けるか発行するかの切り分け
まず、既存ブランドの受付と自社残高の発行を分けて考えます。両者では、必要な仕組みの範囲が大きく違います。
- 既存ブランドの受付：外部サービスを使うため、初期費用を抑えやすい方式です。
- 自社残高の発行：残高台帳や加盟店精算まで自社で設計する方式です。
店舗やECで交通系や流通系の電子マネー、iDやQUICPayなどを使えるようにする場合は、PSPやマルチ決済端末を使います。
自社で残高を持たず、認証や売上確定、取消・返金などを外部サービスに接続する形です。そのため、導入期間と開発費を抑えやすくなります。
POS、EC、アプリにAPIを組み込む場合でも、ブランドを1〜2種類に絞れば、連携開発は30万〜150万円程度から検討できます。
自社電子マネーや会員残高、店舗や自治体で使えるデジタル商品券を発行する場合は、必要な機能が増えます。会員登録やチャージ・付与に加えて、残高照会と支払い、返金と失効も扱う必要があります。加盟店精算、利用履歴、問い合わせ対応も、発行する側で設計します。
残高の二重加算や二重利用を防ぐには、取引台帳と制御も欠かせません。
単純な決済ボタンより範囲が広いため、費用は300万〜1,000万円程度から検討するケースが多くなります。
対応ブランドとチャネルによるシステム構成の違い
同じ電子マネーに対応する場合でも、チャネルによって必要な接続は変わります。
- 店舗：端末・通信、POS連動、締め処理の接続
- EC：決済画面、注文状態、取消・返金APIとの連携
- アプリ：認証と端末変更、通知と履歴、問い合わせ導線の設計
FeliCaをかざす店舗決済と、スマートフォンでのオンライン決済では接続が異なります。
アプリ内のバーコード提示や後払い型の決済も、それぞれ別の設計が必要になります。
要件定義では、ブランドに加えて、利用場所と前払いか後払いかを決めておきます。
通信が途切れたときの扱いや、売上を誰がいつ精算するかは、開発の前に固めておく必要があります。
NTTデータのADAPTIS In-Storeには、POSとサービスセンターを接続するASP型があります。その方式では、店舗側でサーバーを運用せずに、複数の決済手段を扱えます。
自社構築と既存サービスの違いは、機能の数だけでなく、責任分界と運用負担の差にも表れます。
電子マネーシステムの費用相場とコストの内訳
見積もりは開発費だけでなく、導入後にかかる費用を合算して比べます。合算の対象は、初期費用と手数料、端末・通信費、PSPの月額です。さらに、クラウド、監視、保守の費用も加えます。
審査や脆弱性診断、返金・チャージバック、入金消込も対象に入れると、3年程度の総保有コストで比べやすくなります。次の数字は、公開料金と類似の業務システムから整理した目安です。ブランド数や取引量、契約条件によって、金額は変わります。
導入方法ごとの4段階の費用相場
導入方法は、初期費用と期間の組み合わせで4段階に分けると、比べやすくなります。
- 設定導入：初期0〜15万円程度、期間は1〜4週間が目安です。
- API連携：初期30万〜150万円程度、期間は1〜3か月が目安です。
- 自社発行：300万〜1,000万円程度から検討する方式です。
- 本格基盤：1,000万〜5,000万円以上になることがあります。
既存のPSPや決済端末の設定だけであれば、初期費用は0〜15万円程度です。
期間は1〜4週間が目安で、端末を無料か低額で提供するサービスもあります。
PayPayの公式料金例では、初期費用と機器費用がいずれも0円です。
ライトプランは月額1,980円で、条件を満たす場合の決済システム利用料は1.60%となっています。
出典はPayPay「費用と振込サイクル」で、2026年8月に確認したものです。これは一つのサービスの公開例であり、電子マネー全般の料金ではありません。ブランドや端末によっては、別途、月額費用や決済手数料が設定される場合もあります。
API連携の初期30万〜150万円は、画面、認証、注文連携、売上確定を含む金額です。期間は1〜3か月程度です。
その範囲には、取消・返金、エラー表示、テストまでを含めます。
画面を作り込んだり、ブランドやチャネルを複数にしたりすると、費用は増えます。
会計やCRMとの連携まで含める追加範囲では、費用が100万〜300万円程度になることがあります。
自社電子マネーやデジタル商品券は、300万〜1,000万円程度が目安です。
会員アプリや残高台帳をはじめ、チャージまたは付与、利用、加盟店管理までを含みます。
既製の発行プラットフォームやクラウドを使えば、売上集計を含めても下限寄りに抑えられます。一方で、独自キャンペーンや複雑な利用制限、複数加盟店の精算があると増額します。
既存の会員基盤との統合も、費用を押し上げる要因です。さらに、全国規模や24時間運用では、5,000万円以上となることもあります。
初期費用の内訳（開発、人件費、機器、審査）
初期費用は、開発と人件費、機器、審査に分けて見ると、見積もりの抜けに気づきやすくなります。
- 開発・人件費：要件定義、設計、開発、テストの作業分です。
- 機器費：端末本体、設置、通信、レシート、POS接続の費用です。
- 審査関連：審査、契約、接続試験、現地立ち会いを分けて計上します。
API接続でも、注文や売上の状態を自社システムと一致させる設計が必要です。タイムアウト時の再送や取消の期限、返金の反映も、設計の対象になります。管理者向けの検索画面も必要になります。
自社残高を扱う場合は、残高台帳や取引履歴、利用制限が追加になります。そのうえで、加盟店ごとの締め処理や精算ファイル、監査ログも必要です。
機器費は、端末の月額も含めて見ます。たとえば10店舗で1台ずつ必要な場合、1台あたりの月額が固定費として積み上がります。
データ移行と利用者向けの画面制作も、見積書で項目ごとに示してもらいます。
「その他一式」にまとめないほうが、後からの追加請求を防ぎやすくなります。
ランニングコストの中心は決済手数料と運用費
ランニングコストは、取引量に連動する費用と、運用を支える費用に分けて考えます。
- 取引関連：決済手数料、返金、チャージバックが対象です。
- 設備関連：端末・通信費、PSP月額、クラウド利用料がかかります。
- 運用関連：監視や保守、問い合わせ、ログ、診断、バックアップの費用です。
PayPayの加盟店向け資料では、電子マネー料金は1台あたり月額1,020円と案内されています。対象は交通系IC、楽天Edy、nanaco、WAON、iDで、決済手数料は2.95%です。また、QUICPayの決済手数料は3.24%と案内されています。
出典は、PayPay「PayPay加盟店総合カタログ」（2026年8月確認）です。
料金は契約時点や端末、業種、売上規模によって変わるため、必ず最新の個別見積もりで確かめておく必要があります。
月商100万円で手数料が2.95%なら、手数料だけで月2万9,500円です。月商1,000万円になると29万5,000円となり、取引量に比例して費用が増えていきます。
端末が10台なら、1台1,020円で月1万200円です。
ブランドごとの料率や振込手数料、最低利用料も、見積もりで確かめる項目です。
返金時の扱いや入金サイクルも異なるため、月商別に3年分を試算することになります。
電子マネーシステムの費用が変動する主な要因
費用は、対応するブランドやチャネルの数で変わります。店舗数、取引件数、同時実行数も影響します。精算の複雑さも影響するため、安い見積もりは前提を先に確かめるのが安全です。
ブランド数、チャネル、取引量が工数と手数料に与える影響
対応ブランドを増やすほど、接続仕様とテストケースが増えます。
- ブランド数：認証、コード、取消、返金の仕様が対象です。
- チャネル：店舗とECで異なる取引状態を、まとめて扱う設計です。
- 取引量：ピーク時の負荷を基準にした容量設計です。
店舗のタッチ決済とECのオンライン決済を同時に扱うと、取引状態の数も増えます。
共通の決済インターフェースを用意するか、ブランドごとに個別実装するかで、初期費用は変わります。
取引量が多い場合は、セールやイベント時のピークを基準に設計します。
サーバー容量やキュー、データベース、監視も、そのピークに合わせて決めることになります。
決済成功率、タイムアウト率、取消率、入金差異を計測できるようにしておくと、障害対応の工数も抑えやすくなります。
2025年の日本のキャッシュレス決済額は162.7兆円で、そのうち電子マネーは6.0兆円、構成比は3.7%でした。
出典は、経済産業省「2025年のキャッシュレス決済比率を算出しました」（2026年の情報）です。
利用規模のある市場であるため、将来の取引増加も含めて設計します。
法務、セキュリティ、障害対応の後回しによる費用増
自社残高を発行する場合は、法務とセキュリティを初期要件に含めておく必要があります。
- 法務：前払式支払手段への該当性と発行形態が対象です。
- カード情報：PCI DSSの対象範囲と責任分界を整理します。
- 障害対応：二重決済、改ざん、復旧への対策を見積もりに含めます。
自家型か第三者型か、利用範囲、払戻し、発行保証金の要否を確かめます。
届出・登録が必要かどうかは、事業モデルによって変わります。
金融庁は2025年にも、関連する内閣府令や事務ガイドラインを改正しています。
判断は最新の資料をもとに、弁護士や所管当局、経験のあるベンダーに確かめます。
PCI Security Standards CouncilはPCI DSS v4.0.1の文書と質問票を公開しています。
PSPのホスト型画面やトークン化を使えば、カード情報を自社で持たずに済む場合があります。ただし、その場合でも、責任分界と運用要件がなくなるわけではありません。
漏えい、残高改ざん、通信断、二重決済、災害時の復旧を想定します。そのうえで、監査ログや権限分離、バックアップ、復旧目標を見積もりに含めます。
電子マネーシステム開発の進め方と費用を膨らませない順序
費用を抑えたいなら、画面制作より先に方式と取引状態を決めておきます。まず発行か受け入れかを決めたうえで、代表ケースの接続試験を行い、そのあとに範囲を広げていきます。異常系を先に設計しておけば、後工程の作り直しも減らせます。
要件定義での決済の責任分界
要件定義では、取引条件と運用の責任を一緒に整理しておきます。
- 事業条件：ブランド、チャネル、端末、店舗数、取引量を確定します。
- 運用条件：入金、加盟店、権限、監査、保守、移行の取り決めです。
- 異常系：取消や返金、通信断、再送、利用停止の扱いです。
対応ブランドや利用チャネルは、増やすほど接続仕様とテストケースが増えるため、早い段階で固めます。
月間の取引件数やピーク時の同時実行数は、容量設計の前提になります。入金サイクルや加盟店数も、同じ前提として扱います。この段階で固めておくと、見積もりの前提がそろいます。
オーソリから売上確定、取消、返金、タイムアウトまでの流れを、状態遷移図にまとめます。締め処理も、同じ図に含めておきます。
取引の確定者、返金の承認者、入金差異の調査者を、はっきり決めておきます。権限や監査ログの扱い、SLA、保守時間、データ移行も、要件定義の段階で決めます。責任分界が決まっていれば、見積もりの抜けにも気づきやすくなります。
方式の選定と、共通部分からの設計・開発
方式は、規模と、競争力になる機能を基準に比べます。
- 小規模・短期：PSPのクラウドやAPIを比べます。
- 店舗中心：マルチ決済端末やASPの比較が中心です。
- 独自要件：発行基盤やスクラッチを検討します。
自社残高や加盟店施策が競争力になるなら、発行プラットフォームを優先します。
スクラッチ開発が向くのは、標準サービスでは解決できない要件がある場合です。たとえば、特殊な精算や独自の利用制限、基幹との深い統合が挙げられます。高い可用性が必要なときも、スクラッチを検討します。
設計では、ブランドごとの差をアダプター層に閉じ込め、注文・会計側は共通の取引インターフェースを呼び出す構成にします。この構成にすると、将来のブランド追加にかかる工数を抑えやすくなります。
残高は、付与、利用、返金、失効を追跡できる台帳で保存します。現在値だけでなく、動きの履歴も残す設計です。冪等性キーを使い、再送されても残高が一度しか動かないようにします。
テストの配分と異常系の比重
テストは少数の代表ケースから始め、異常系を含めて段階的に広げていきます。
- 代表ブランド1〜2種と1店舗、少額取引から始めます。
- 通信断、二重送信、応答遅延、途中失敗を再現します。
- 取消、返金、締め処理、入金差異を確かめます。
- パイロット店舗で指標を測り、安定してから店舗を増やします。
決済の成功だけでなく、全額返金や部分返金、利用停止も再現の対象にします。
管理者の誤操作や設定差、端末交換時の再認証も、テストで確かめます。アプリ更新後の利用履歴も、テスト対象に含めます。
決済成功率や平均処理時間、取消率、入金差異は、測定して数字で見ます。問い合わせ件数も測り、数値が落ち着いているかを見てから次に進みます。
障害時の停止基準や手動受付、再送、残高調査、告知は、手順として決めておきます。
監視と保守を別契約にする場合は、対応時間を事前に決めておく必要があります。
電子マネーシステムのコスト最適化のポイント
コスト最適化は、安い開発会社へ発注することだけではありません。後から膨らむ費用にも目を向ける必要があります。失敗や入金差異が増えると、問い合わせや返金、現地対応、信用低下の費用が積み上がります。
最初は標準サービスを使い、価値のある部分だけを独自開発します。
PSP・クラウド・端末サービスの標準機能の活用
標準機能を使う範囲と独自開発する範囲を分けておくと、初期費用を抑えられます。
- カード決済：ホスト型画面やトークン化を使う形です。
- 店舗運用：端末やASPのサービスセンターを利用します。
- 比較軸：3年総額と移行条件を比べます。
標準機能を使うと、セキュリティ対応と開発範囲を絞りやすくなります。
店舗では、端末処理や通信、ブランド追加、売上集計をASP側で提供してもらえます。そのため、自社で決済サーバーを構築する費用を避けられる場合があります。
NTTデータのサービスにも、POS連動や売上レポートを含む方式があります。
月額や手数料が高いと、取引量が増えたあとに総額が逆転します。
月商100万円、1,000万円、5,000万円の3パターンで、3年分を試算します。試算では、初期費用や月額、料率、端末台数、保守を対象にします。
撤退や移行のときのデータ出力、ブランド変更の条件も、導入前に確かめます。契約が終わったあとに利用履歴がどう扱われるかも、導入前に確かめておきます。
最初のリリースでの絞り込み（ブランド、店舗、機能）
初回リリースの範囲を絞ると、テストと運用の負荷を減らせます。
- ブランド：利用者の多いブランドから始めます。
- 店舗：代表店舗で成功率と負荷を測ります。
- 機能：支払い、取消、返金、履歴を優先します。
全ブランドや全店舗を、店舗・EC・アプリと同時に実装すると、テストが増えます。複雑なキャンペーンも同時に入れると、確認する組み合わせが急増します。
追加するブランドは、共通インターフェースを通して段階的に増やします。
自社電子マネーでは、チャージ、利用、残高照会を初回の中心に据えます。加盟店管理と売上集計も、初回機能に含めます。
複雑なポイント交換や多段階のキャンペーンは、後から追加します。一方で、利用制限と失効条件は後付けが難しいため、規約と台帳を先に固めます。機能を減らす場合でも、法務・セキュリティ・精算は削りません。
精算、監視、問い合わせの標準化
店舗ごとの差を減らしておけば、担当者が確かめる対象を一部の例外に絞れます。
- 精算：売上、手数料、入金、差異を共通化します。
- 監視：ブランド・端末・返金の状態が追える形にします。
- 問い合わせ：取引IDなどによる発生元の追跡です。
加盟店単位の売上集計や手数料計算、入金予定と実入金の照合は、同じ仕組みで行います。差異は一覧にまとめて、担当者が確かめます。
監視では、サービス全体の停止だけでなく、ブランド別の成功率も見ておきます。端末別の通信エラーや返金の滞留も、見えるようにしておきます。
問い合わせでは、利用者や店舗、本部、決済事業者のどこで起きたかを追えるようにします。そのために、取引ID、端末ID、加盟店ID、会員ID、外部決済IDを記録しておきます。そうすると、調査時間や返金判断、ベンダーへの確認回数も減らせます。
個人情報は必要以上に表示しない権限設計にします。
見積もりを取る際のポイントと比較方法
相見積もりでは、合計金額だけでなく、前提条件をそろえて比べることが欠かせません。「電子マネー対応一式」「連携費用一式」「保守一式」と書かれていると、必要な作業が見えにくくなります。
要件は文章と状態遷移で示し、初期費用と月額費用は分けて書いてもらいます。従量課金やオプション、除外項目も、同じように分けて提示してもらいます。
RFPに書く項目（決済状態、精算、運用）
RFPには、機能だけでなく取引条件と運用の責任範囲を書きます。
- 利用条件：発行か受け入れか、ブランド、チャネルを記載します。
- 取引条件：端末、店舗、取引量、ピーク数の内容です。
- 運用条件：精算、障害、法務、移行、テストの扱いです。
会員登録からチャージ、残高照会、支払い、取消、返金までの流れを示します。領収情報や加盟店管理、手数料計算、精算、入金消込も、対象に含めます。
管理者権限や監査ログ、通知、レポートの有無も示しておきます。通信断や二重送信、タイムアウト、部分失敗、返金の遅延も、RFPに書いておきます。
入金差異や利用停止、復旧目標、データ移行も対象として挙げます。
受入テストの責任者は、RFPの段階で決めておきます。
カード情報を扱う場合は、PCI DSSの対象範囲を確かめます。そのうえで、PSPが担う部分と自社が担う部分を分けて記載します。
自社残高を扱う場合は、法令確認の担当者を決めておく必要があります。規約や利用者への表示を誰が作るかも、あわせて決めます。
開発会社の用途別比較と責任分界の確認
候補となる会社は、チャネルや残高管理、精算規模など、用途ごとに比べます。
- EC・アプリ：複数ブランドなら総合PSPを候補に入れます。
- 店舗運用：多店舗なら端末・ASP事業者の検討です。
- 発行・精算：基盤の規模に応じた専門会社やSIの検討です。
自社残高や商品券であれば、発行プラットフォームを候補に入れます。
GMOペイメントゲートウェイやSBペイメントサービスは、比較の対象にできます。DGフィナンシャルテクノロジーやELESTYLE、GMOデジタルPayも候補に入ります。
NTTデータなども含め、各社で得意なチャネルや契約形態は異なります。
選ぶ際は、ブランド、接続方式、精算、保守で比べます。障害時の窓口が自社の体制に合うかも、確かめておきます。
標準機能と追加開発を区別して、仕様変更費用やブランド追加費を確かめます。端末交換や現地対応、監視時間、データ出力の条件も、あわせて示してもらいます。
契約が終わるときの移行条件も、提案の段階で示してもらいます。
決済が成功したのに注文の更新が失敗した場合の責任者を、文書で明確にします。店舗では成功と表示されても本部に売上が届かないことがあるため、その担当者も決めておきます。
見積もりの金額が安くても、例外処理が手作業のままなら、実際のコストは下がりません。
よくある質問
電子マネーシステムの費用について、よく寄せられる質問をまとめました。
方式や法務、運用を判断するための材料として、参考にしてください。
電子マネーシステムの開発費用はいくらですか？
開発費は、既存サービスとの連携か自社発行かで、大きく違います。
- API連携：既存電子マネーのPOS・EC・アプリ連携は30万〜150万円程度です。
- 自社発行：電子マネーやデジタル商品券は300万〜1,000万円程度です。
- 本格基盤：発行・加盟店精算・高可用性を含むと1,000万〜5,000万円以上になることがあります。
ブランドやチャネル、取引量のほか、セキュリティや法務、保守まで含めて見積もります。
既存の決済サービスを使うと開発費を抑えられますか？
既存サービスを使うと、決済基盤をゼロから作るより、初期費用と期間を抑えやすくなります。
- 接続：PSPのAPIやホスト型画面を使う形です。
- 店舗：マルチ決済端末で導入範囲を絞れます。
- 発行：発行プラットフォームの基盤を利用する形です。
月額や決済手数料、端末費、ブランド追加費、データ移行費は発生します。そのため、3年程度の総額で比べます。
独自の残高ルールや加盟店精算が重要な場合は、差分開発が必要になります。
自社電子マネーを発行するときに法律の確認は必要ですか？
はい、必要です。自社残高や商品券などが前払式支払手段に該当するかを、まず確かめます。
- 該当性：自社残高、商品券、ポイント、地域通貨が対象かを確認します。
- 発行形態：自家型か第三者型かを確かめます。
- 手続き：届出・登録と発行保証金の要否です。
機能を実装したあとに法務を確認すると、作り直しが発生しかねません。そのため、要件定義の前に、弁護士や所管当局、経験のある決済事業者へ相談しておくのが安全です。
電子マネーシステムの開発期間はどのくらいですか？
開発期間は方式によって変わり、設定導入から本格基盤まで幅があります。
- 設定導入：既存サービスの設定・審査・端末設置は1〜4週間です。
- API連携：既存POS・EC・アプリへの連携は1〜3か月程度です。
- 自社発行：発行基盤は3〜6か月を見込みます。
- 本格基盤：加盟店精算や高可用性を含むと6〜12か月以上を見込む場合があります。
ブランド審査や法務確認、現地設置、異常系テストも、期間に含めて考えます。
パイロット展開もあるため、開発だけの期間で組むのは避けたいところです。
まとめ
費用は、既存ブランドを受け付けるか、自社残高を発行するかで大きく変わります。PSPや端末の設定は初期0〜15万円程度、API連携は30万〜150万円程度です。
自社電子マネーは300万〜1,000万円程度、本格基盤は1,000万〜5,000万円以上です。判断では、決済手数料や端末、月額などの金額面を含めます。保守や法務、セキュリティ、障害対応も、同じ判断材料に加えます。
見積もり前に決める事項
発注前には、対応ブランドや利用チャネル、店舗数と端末数を整理します。月商や取引件数も、同じ表にまとめておくと比べやすくなります。
- 取引条件：成功、取消、返金、通信断の扱いを決めます。
- 運用条件：精算、入金消込、監視、SLAを決めます。
- 責任分界：法務、セキュリティ、ブランド追加を誰が受け持つかです。
将来のブランド追加も、発注前に整理しておきます。RFPでは、標準機能と追加開発を分けて書き、従量課金や除外項目、移行費用も別に示します。
複数社に依頼すると、価格だけでなく運用負担も比べられます。
費用と安全性を両立する段階的な導入
標準サービスで検証する部分と、自社の競争力になる部分を分けて導入します。
- 方式分け：標準サービスと独自開発の範囲を切り分けます。
- パイロット：代表ブランド・店舗で異常系を検証します。
- 段階拡張：指標を確かめてから、対象を広げます。
拡張の前には、決済成功率や入金差異、問い合わせ件数を確かめます。
費用だけでなく、残高や精算、障害時の説明責任を守れる方式を選びます。それが、長期的なコスト最適化につながります。
▼全体ガイドの記事
・電子マネーシステム開発の完全ガイド
▼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を創業。