クレジットカード・決済開発の見積相場や費用/コスト/値段について

クレジットカード・決済システムの開発費は、連携方式、課金モデル、セキュリティ要件によって、100万〜400万円から数億円以上まで変わります。

費用の幅が大きいのは、決済画面を追加するだけか、業務システムや基盤まで含めるかで、作業の範囲が大きく違うためです。

▼全体ガイドの記事
・クレジットカード・決済開発の完全ガイド

クレジットカード・決済システムの全体像

購入者を中心にPSP、カード会社、加盟店の注文・会計システムを結んだ図です。
決済画面の外側にも、連携する相手がいます。

クレジットカード・決済システムとは、決済画面に限らず、購入者の支払い要求を受けて複数のシステムをつなぐ仕組み全体を指します。

決済システムでは、PSP、カード会社、加盟店の注文・会計システムを連携させ、認証から入金消込まで、各段階の内容をそろえる必要があります。

事業タイプを分けて考えると、必要な機能が見え、見積もりの内容が妥当かどうかも見分けられます。

EC・店舗への決済導入

EC・店舗への導入では、決済画面の部分と業務連携の部分を分けて見積もります。

  • 対象:ECや店舗POSへの決済追加
  • 標準連携:開発費は100万〜400万円
  • 期間:企画初期の目安は1〜3か月

カードや電子マネー、QRコードなどを追加する作業は、比較的始めやすい領域です。

ホスト型CheckoutやPayment Linkを使うと、カード番号を自社サーバーに保存しない構成を組みやすくなります。

導入範囲が決済画面に限られる場合は、注文登録と売上確定、取消・返金を中心に実装できます。

Webhookによるステータス更新も、中心となる機能に含まれます。一方で、店舗とECの統合、店舗別の精算、複数ブランドまで含めると、単純な画面導入では済まなくなります。

在庫や会計との連携まで含める場合は、業務システム連携として見積もります。店舗とECの統合も、この扱いに含まれます。

SaaS・マーケットプレイスの課金基盤

SaaS・マーケットプレイスでは、継続課金や売上分配まで含めて、課金基盤全体を考えることになります。

  • 課金:継続・日割り・従量課金
  • 失敗対応:再試行やカード更新
  • 分配:出店者への売上分配

1回払いと比べると、解約と再開の処理が加わり、請求の流れも複雑になります。

StripeのPayments、Billing、Connectなどを組み合わせられるプラットフォームもあります。ただし、サービス固有の契約や請求、台帳、手数料の計算は、自社側で設計することが多くなります。

複数のPSPを切り替えるオーケストレーターでは、トークンの統合や二重計上の防止が必要になります。

障害時のルーティングも増えるため、カスタム連携は400万〜800万円程度になります。

独自基盤では、費用が500万〜2,000万円程度まで広がります。

カード・金融基幹システム

カード・金融基幹では、API追加にとどまらず、運用モデル全体を設計します。

  • 対象:会員・与信・精算基盤
  • 運用:24時間365日の監視と障害対策
  • 費用:500万円〜数億円以上

カード会員向けアプリや、イシュア・アクワイアラの会員・与信・精算基盤は、オンライン決済APIの追加とは規模が異なります。

会員情報、利用可能額、請求を扱い、ポイントや加盟店精算まで含みます。さらに、ネットワーク接続、監査ログ、フェイルオーバーも必要になります。

災害対策まで一つの運用モデルに含めるため、この分野の作業範囲は広がります。

費用の目安は、カード会員向けアプリで500万〜5,000万円、基幹刷新で5,000万円〜数億円以上です。

期間は12〜18か月以上が目安です。

投資判断では、障害時の損失や制度対応も含めて考えます。

クレジットカード・決済開発の費用相場

費用相場は、連携方式と基盤の規模によって大きく分かれます。

目安は、標準連携が100万〜400万円、カスタム連携が400万〜800万円です。

独自決済基盤やオーケストレーターは、500万〜2,000万円が目安になります。金融機関の基幹刷新は、5,000万円〜数億円以上になることもあります。

これらは公開された定価ではなく、企画初期の推定レンジです。NotebookLMの調査結果、公開料金、類似する業務システムの工数をもとに作成しています。

正式な見積もりでは、決済手段、取扱高、対象ブランドを費用に反映させます。

既存システム、可用性、審査とセキュリティ要件も、前提として必ず確認します。

初期開発費に含まれる項目

初期開発費を見るときは、画面数だけでなく、決済状態ごとの処理まで確認します。

  • 設計:企画・要件定義・基本設計
  • 実装:決済画面・API・PSP接続
  • 運用準備:テスト・審査・リリース

注文・課金APIも実装の対象です。さらに、Webhook処理や管理画面、会計・在庫とのデータ連携も、対象に含まれるかを確認します。

テストや審査対応、リリース作業まで含まれているかも、あわせて確認します。

決済は、未処理や認証済み、売上確定といった状態をたどります。失敗、取消、返金も、それぞれ状態として定義します。

一部返金やチャージバックも含めて、注文・請求・在庫・会計の変化を設計します。

状態設計が抜けた見積もりは、後から追加費用が発生しがちです。

機能追加の目安は、コンビニ決済で30万〜80万円、QRコード決済で30万〜60万円です。

銀行振込の自動消込は50万〜100万円、サブスクリプションは50万〜150万円です。従量課金は80万〜200万円程度が参考になります。

日割りや上限通知を含むか、カード更新や失敗時のリトライを含むかで、工数は変わります。これらも標準価格ではなく、個別案件の条件をもとにした推定です。

PSPの初期費用・月額費用・決済手数料

PSP費用は、開発会社への支払いとは分けて考え、固定費と従量費を合算します。

  • 固定費:初期費用・月額費用
  • 従量費:決済手数料・サービス利用料
  • 周辺費:振込・取消・返金手数料

SBペイメントサービスが2026年に公開している相場では、無料〜数十万円が目安です。

月々は数千円〜数万円で、カード決済の手数料は決済金額の2〜10%です。

利用料は0.3〜1%で、1件あたりの処理費は数円〜数十円です。同じ相場では、取消処理は5円程度です。

出典は「決済代行の手数料とは?」(2026年閲覧)です。

提示される条件は、業種や取扱高、審査結果によって変わります。契約期間によっても変わります。

Stripeの日本向け標準料金は、国内カードの成功取引1件あたり3.6%です。

この標準料金では、初期費用も月額料金もかかりません。3Dセキュア認証にも、追加の手数料はかかりません。

出典はStripe「料金体系 & 手数料」(2026年8月確認)です。

たとえば、月商1,000万円なら、3.6%で月36万円、年間では432万円になります。取扱高によっては、手数料率を0.5ポイント下げる効果が大きくなります。

開発費を100万円下げるより、手数料率を下げるほうが有効な場合があります。

3年TCOでの比較

3年TCOでは、初期開発費と3年分の運用費を合算して比べます。

  • 固定費:初期費用と月額費用
  • 従量費:取扱高・件数に応じた費用
  • 運用費:保守・監視・セキュリティ

計算式は「初期開発費+PSP初期費用+月額費用×36か月」で、これに「取扱高×決済手数料率×36か月」を加えます。

件数×トランザクション費用×36か月の分も計算に入れます。月商1,000万円の場合、決済手数料は3年間で1,296万円になります。

売上が伸びる事業では従量費の差が大きくなるため、保守的・標準・成長の3パターンで試算します。

各パターンに、取扱高の変化を反映させます。

取扱高が小さい段階では、初期費用と月額費用が無料の従量課金型が有利なこともあります。

ボリュームディスカウント、プラン変更、最低利用料は、見積書と契約書で見ておきます。返金時の手数料やチャージバック発生時の請求も、確認が必要です。

トークンを別のPSPへ移せるか、データを書き出せるかも確かめます。

ポイント

費用は連携方式と基盤の規模で大きく変わるため、まず自社の取引に必要な連携の範囲を決めてから、同じ条件で複数社の見積もりを比べます。

クレジットカード・決済のコストが変動する要因

課金モデル、セキュリティ、既存システムと可用性の3項目をカードで示した図です。
機能の幅と運用条件の両方が、見積もりに関わります。

同じカード決済でも、価格は業務と運用の複雑さによって変わります。そのため、取引の種類やデータ連携を確認し、あわせてセキュリティと障害時の対応も分けて見ます。

課金モデルと決済件数

課金モデルの種類が増えるほど、決済状態と請求処理の設計範囲も広がります。

  • 1回払い:決済・返金・注文更新
  • 継続・従量:請求と利用量の管理
  • マーケットプレイス:売上分配と精算

1回払いは設計の範囲が比較的狭く、始めやすい形です。

サブスクリプションでは、請求日の変更、日割り、無料期間への対応が必要です。

加えて、失敗時の再試行やカードの有効期限更新、解約と再開も対象になります。未収金の管理も含まれます。

従量課金では、利用量を正確に計測し、締め処理まで整合させる必要があります。上限超過、請求の確定、明細の表示も含めて設計します。

マーケットプレイスでは、複数の出店者へ売上を配分します。そのうえで、手数料や返金、チャージバック、振込を、それぞれ個別に管理することになります。

注文画面が同じでも、基盤の工数は増えます。

3Dセキュア・PCI DSS・不正対策

非保持化を選んでも、対策がなくなるわけではありません。

  • 非保持化:PCI DSSの対象範囲を縮小
  • 残る対策:改ざん・アクセス・ログ監視
  • 追加要件:3Dセキュアと不正対策

脆弱性診断と連絡体制も必要になります。

自社でカード情報を扱う場合は、PCI DSSの評価、監査、運用まで必要になります。その費用は、年間500万〜2,000万円程度という推定もあります。

環境による差が大きいので、個別に算定する必要があります。

経済産業省は、2025年3月の改訂で、EC加盟店向けの実務上の指針を示しました。そこでは、脆弱性対策、EMV 3-Dセキュア、不正ログイン対策が求められています。

出典は経済産業省「『クレジットカード・セキュリティガイドライン』が改訂されました」(2025年)です。

PCI SSCは、PCI DSS v4.0の51個の将来日付要件について、2025年3月31日が適用期限だと案内しています。v4.0.1は、要件の追加や削除ではなく、訂正と明確化を目的とした改訂です。

出典はPCI Security Standards Council(2024年10月発表)です。

法令、業界ガイドライン、PCI DSSの認証要件は、別々のものとして区別して考えます。

どの対策を誰が担当するかは、RFPに記載します。

既存システム・可用性・接続先の数

接続先と可用性の要件が増えるほど、連携と運用の工数も増えます。

  • 連携先:会計・ERP・在庫・CRM・POS
  • 例外処理:Webhook・再送・入金消込
  • 可用性:冗長構成と24時間365日運用

会員やポイント、物流、データ分析なども接続します。接続先が増えるたびに、項目変換やエラー処理、締め処理の工数も増えます。

Webhookの順序が入れ替わる場合や、タイムアウト後の再送にも対応します。返金が売上確定より先に実行される例外も、対象に含めます。

決済IDや注文ID、冪等キーを決め、台帳の正本も定めておくと、修正費用を抑えやすくなります。

取扱高やピーク時の同時実行数も、価格に影響します。

冗長構成や複数リージョン、バックアップ、障害時の切り替えが必要になることがあります。24時間365日の監視と一次対応には、運用設計や当番体制の費用もかかります。

NTTデータは、CAFISを1984年から24時間365日運用しています。加盟店向けのADAPTISでは、サーバー機能をサービスセンター側で提供します。

出典はNTTデータ「顧客接点・決済」(2026年8月確認)です。

外部の基盤を使うか、自社で同等の体制を組むかで、費用は変わります。

ポイント

価格の差は、課金モデルや接続先の数、セキュリティ要件の違いから生じやすいものです。金額が想定と違うときは、どの要因が見積もりに入っているかを先に確かめます。

見積もりを取る際の進め方

見積もりは、販売チャネルと業務範囲を整理してから依頼します。要件が曖昧なまま安い提案を選ぶと、あとから追加費用が発生しがちです。

  1. 販売チャネルと業務の範囲を整理する
  2. 決済状態と例外処理を定義する
  3. PSPや開発会社へ同じ条件で依頼する

返金や入金消込は、別見積もりになります。障害対応も追加され、結果として費用が高くなることがあります。

要件定義で決める項目

見積もり依頼書では、事業条件と運用条件を同じ細かさで示します。

  • 事業条件:チャネル・国・取扱高・単価
  • 決済条件:ブランド・手段・課金方式
  • 運用条件:SLA・監視・保存期間

ピーク時の件数も書きます。

カードブランドや決済手段、課金方式も、あわせて示す必要があります。1回払い・分割・継続・従量の別も、そこに含めます。

返金と一部返金、チャージバック、入金サイクルを明示します。会計・在庫・CRMとの連携も記載します。

利用者権限と必要な管理画面も記載します。

カード情報の保持者、PSPを変更する可能性、トークン移行の要否を明示します。求めるSLAと障害時の連絡時間も示します。

監視の範囲とデータの保存期間も、対象に含めます。決済状態は、画面の遷移ではなく、台帳上の状態として記載します。

認証は成功したのに注文登録に失敗する場合を、RFPの例に含めます。通信がタイムアウトした後に成功通知が届く場合も、確認の対象にします。

Webhookが重複して届いたり、順不同で届いたりする場合も、見積もりの対象にします。

売上確定後の一部返金や、PSPの入金額と会計売上の不一致も含めます。これらの例外が含まれているかを確認します。

条件をそろえておくと、提案会社ごとの品質差が見えます。

複数社の提案の比較

提案は、導入規模と運用の重さをそろえて比較します。

  • 短期導入:PSPの標準機能
  • クラウド基盤:複数決済の統合
  • 大規模基盤:カード・金融基幹

三つの型を混ぜずに見ると、各社の提案を比べやすくなります。

GMOペイメントゲートウェイやSBペイメントサービスは、標準機能を使う案件と相性のよい候補です。Stripeは、API中心のSaaSやマーケットプレイス、越境決済の比較対象になります。

NTTデータのCAFIS・ADAPTISやTISのPAYCIERGEは、基盤・SIの候補です。店舗や金融、複数チャネルにまたがる案件のほか、接続先の多さや可用性を重視する案件で検討します。

会社名の知名度だけで順位をつけず、自社の要件への適合性で評価します。

評価表には、初期開発費とPSP費用、月額と従量費を並べます。加えて、3年TCOも比較の列に入れます。

対応決済手段や継続課金・分割、3Dセキュア、トークン移行も比べます。

複数PSPへの対応と会計・POS連携を確認します。監視やSLA、PCI DSS支援も見ます。加盟店審査の支援と、障害時の責任分界も並べます。

テストや運用設計、脆弱性診断、リリース後の保守が含まれない提案は、条件が異なります。そのため、各社に同じ質問をします。

各社の回答は、含む・含まない・追加費用・前提条件に分けて記録します。

契約・検収・責任分界

契約では、画面の完成だけでなく、例外処理と責任分界も定めます。

  • 検収:正常系と例外系を含める
  • 責任分界:開発会社・PSP・加盟店
  • 保守:監視・更新・復旧試験

取消と返金、部分返金も、受け入れ条件に入れます。再送や重複通知も含めます。通信断やPSP障害、会計差異、カード更新や不正利用も対象です。

どの証跡を残すかは契約で定めておき、障害時の一次受付を誰が担当するかも確認します。PSPへの連絡や復旧の判断、返金の判断、利用者への告知も、誰が担うかをあらかじめ決めておきます。

開発会社、PSP、加盟店の三者で、障害時の役割を確かめます。

準委任契約は要件変更に柔軟に対応できる一方、最終的な費用は増えやすい契約です。そのため、月次の成果物と上限工数を合意しておきます。請負契約では、範囲外を明確にしておきます。

PSPの仕様変更、法令やガイドラインへの対応、追加する決済手段の扱いも、契約に記載します。保守契約については、対応の範囲も確認します。

保守契約に、監視時間や対応時間、脆弱性修正が含まれるかも確認します。

OSやミドルウェアの更新、障害訓練、バックアップからの復旧試験も対象になります。

ポイント

見積もりを比べる前に、販売チャネルと業務範囲、決済状態と例外処理の条件を発注側で整理しておきます。条件がそろっていない提案は、金額だけで判断しないことが大切です。

クレジットカード・決済開発のコスト最適化ポイント

カード決済と返金から始め、実績と要件を確認して追加機能へ進む流れ図です。
先に境界を決めておくと、後から機能を加えやすくなります。

コスト最適化では、信頼性を守りながら、標準機能と差別化部分を分けて考えます。

開発費と手数料、運用費、将来の移行費を、同時に見て判断します。

標準PSPで80%を賄い、差別化部分に集中する構成

一般的な決済処理は標準PSPの外部サービスに任せ、自社開発は絞ります。

  • 外部化:カード処理・標準決済
  • 自社開発:会員・注文・契約
  • 比較:手数料と3年TCO

自社でカード番号を扱うと、認証や監査、脆弱性対応、24時間の運用が必要になります。そのため、ホスト型CheckoutやPayment Linkを活用すると、初期費用を抑えやすく、PCI DSSの対象範囲も狭められます。

PSPのAPIや、標準のBilling、不正検知も活用します。

自社開発は、競争力に直結する部分に限ります。ポイントや売上分配も、この範囲に入ります。

標準PSPを使えば、必ず全体が安くなるとは限りません。手数料率や取引上限、対応ブランド、継続課金の仕様を確認します。

返金期限やトークン移行、データ出力、障害時のサポートも比べます。取扱高が伸びる事業では、3年TCOで別PSPやカスタム契約が有利になる場合があります。

最小構成からの段階的な拡張

初期リリースでは、取引に必要な機能と監視を優先します。

  • 決済:カード・売上確定・返金
  • 管理:検索・入金消込・監視
  • 拡張:実績と要件が固まってから追加

初期構成では、主要なカード決済、注文登録、売上確定、取消・返金を優先します。そのうえで、Webhookや管理者向け検索、入金消込、監視も含めます。

分割やリボ、複数PSP、海外通貨は後回しにします。店舗との統合も、後から追加します。ポイントや複雑な売上分配は、さらに後の段階で広げます。

機能を後から安全に追加するため、決済IDや注文ID、顧客IDの境界は先に設計しておきます。台帳やイベントログの境界も同様です。

段階導入では、PoCの成功条件を決めます。

決済成功率や返金処理時間、Webhookの再送を検証します。入金差異も確かめ、障害時の復旧手順やログからの追跡可能性も確認します。

合格してから本番の取扱高を増やします。タイムアウトや二重送信、遅延通知、PSP停止も、検証の対象に含めます。これにより、緊急対応費を抑えやすくなります。

設計段階での監視・保守の効率化

監視と保守を設計段階から定型化しておくと、運用費や属人的な対応を減らせます。

  • 可視化:失敗・返金・入金差異
  • 追跡:決済IDで記録を連携
  • 定型化:通知・復旧・訓練

決済成功率や失敗理由を、ダッシュボードで見える形にします。Webhookの未処理も対象です。チャージバックやPSPごとのエラー率も含めます。

決済IDをキーに注文、PSP、会計の記録を追跡すると、照合時間を減らせます。再送や再処理を管理画面から安全に実行できるよう、冪等性も実装します。

保守では、PSPの仕様、カードブランドのルール、3Dセキュアへの対応を継続的に更新します。脆弱性への対応や、OSやクラウドサービスの更新も発生し続けます。

対応時間や対象範囲が狭い保守契約では、障害時に別途費用がかかることがあります。

通知先や一次切り分け、エスカレーションは、決まった型にしておきます。月次レビューも、同様に決めておきます。

復旧訓練を重ねて属人的な対応を減らすことが、長期的な最適化につながります。

ポイント

標準PSPで賄える部分と自社で作る部分を分け、手数料と運用費を含めた3年TCOで比べます。開発費だけで判断すると、後から運用費が膨らむことがあります。

よくある質問(FAQ)

費用や発注条件は、事業規模と契約条件を、自社の取扱高に当てはめて確認します。

クレジットカード決済の導入費用は最低いくらですか?

PSPの標準CheckoutやPayment Linkを使う場合は、開発費とPSP料金、総額をそれぞれ分けて見ます。

  • 開発費:企画初期の目安は100万〜400万円
  • PSP料金:初期費用・月額費用が無料の体系もある
  • 総額:手数料・保守・業務範囲で変わる

総額は、画面以外の業務範囲によって変わります。

決済手数料やトランザクション費用、返金や振込の手数料、保守費用は、別に発生します。

注文や返金、入金消込、監視まで含むかを確認します。

カード情報を保存しなければPCI DSS対応は不要ですか?

カード情報を自社環境に保存せず、処理も通過もさせない方式を、非保持化といいます。

  • 対応範囲:非保持化で対象を小さくしやすい
  • 残る対策:改ざん・アクセス・診断・監視
  • 確認事項:責任分界・自己評価・証跡

ただし、PCI DSS対応が不要になるとは限りません。Web改ざん対策とアクセス制御、脆弱性診断とログ監視が必要です。EMV 3-Dセキュアと不正ログイン対策も、引き続き必要です。

自社構成と責任分界を整理し、必要な自己評価や証跡を確認します。

開発会社の見積もりは何社から取るべきですか?

条件をそろえたうえで、少なくとも2〜3社から取ると比較しやすくなります。

  • 候補:PSP・複数システム・クラウドに強い会社
  • 実績:金融・カード基幹の運用実績
  • 確認:テスト・保守・移行・責任分界

金額だけで決めず、例外系テストやセキュリティ、監視、保守も確認します。トークン移行や障害時の責任分界についても、確かめます。

決済手数料を下げるときに最初に見るべき項目は何ですか?

決済手数料を比べる前に、まず月間取扱高と平均単価、決済件数を用意します。返金率と決済手段の比率も、あわせて用意します。

  • 前提:取扱高・単価・件数・返金率を用意
  • 費用:料率・固定費・月額費用を合算
  • 比較:契約条件まで含め3年TCOで判断

少額決済では、固定のトランザクション費用が1件あたりに効きます。高額決済では、料率が効いてきます。

同じ条件で複数社から見積もりを取り、3年TCOで比較します。最低利用料や返金・取消、チャージバックを含めます。振込や契約期間も、比較の対象に入れます。

将来の割引条件まで確認し、手数料だけで判断しないことが大切です。

ポイント

金額は、事業規模と契約条件を自社の取扱高に当てはめて比べます。手数料率だけでなく、固定費と月額費用を合算した額で判断します。

まとめ

クレジットカード・決済開発は、方式と業務範囲で費用が変わります。方式ごとの初期費用に加えて、取扱高に応じたランニング費も比べます。

独自基盤は500万〜2,000万円、カード・金融基幹の刷新は5,000万円〜数億円以上です。金額は、継続課金や売上分配、既存システム連携で変わります。3Dセキュアや、PCI DSSへの対応によっても変わります。可用性や監視・保守の条件も、費用に影響します。

開発費とランニング費を分けた3年TCOでの判断

開発費だけでなく、PSP費用と運用費を3年分で比較します。

  • PSP費用:初期・月額・決済手数料
  • 運用費:監視・保守・セキュリティ
  • 変動費:返金・チャージバック・消込

月商1,000万円で3.6%なら、決済手数料は月36万円です。

初期費用だけでなく、取扱高に応じた料金と切り替え条件を比べます。

要件と責任分界を決めたうえでの見積もり依頼

発注前には、決済状態と例外処理、カード情報の保持範囲を整理しておきます。

  1. 3Dセキュア、PSPの変更可能性、会計・POS連携、SLAを確認する
  2. 障害時の責任分界を決め、標準PSPと自社開発を分ける
  3. タイムアウト、二重送信、遅延Webhook、部分返金、PSP障害を受け入れ条件に含める
  4. 同じRFPで複数社の提案と3年TCOを比較する

▼全体ガイドの記事
・クレジットカード・決済開発の完全ガイド

会社紹介

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

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

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

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

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

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