結論：デビットカード基幹システムの開発費は、標準サービスへの接続で3,000万円〜8,000万円程度、
複数ブランドに対応する金融機関向け基盤で3億円〜8億円程度が一つの目安です。ただし、
公開定価を集計した相場ではなく、対象範囲や勘定系との接続方式によって大きく変わる編集部推定です。
デビットカードは、カード番号を管理するだけのシステムではありません。利用時の承認、
口座残高の確認、資金の一時確保、売上確定、取消や返金、加盟店との精算までをリアルタイムに整合させる基幹システムです。
この記事では、2026年時点の費用相場、コストの内訳、価格が変動する要因、開発の進め方、
見積書の比較ポイントを、発注前に確認したい順番で解説します。
▼全体ガイドの記事
・デビットカード基幹システム開発の完全ガイド
デビットカード基幹システムの全体像
デビットカード基幹システムは、カード会員、カードネットワーク、加盟店、銀行口座、
社内の勘定・精算業務をつなぐ中核です。クレジットカードのように後日まとめて請求する方式とは異なり、
原則として利用時点で預金口座から資金を引き落とすため、低遅延と取引の整合性を同時に満たす必要があります。
カード管理から精算までが費用の対象です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
主な機能は、申込・本人確認との連携、カード番号や有効期限の管理、発行・再発行・利用停止、オーソリゼーション、口座残高照会、利用限度額管理、売上確定。
取消、返金、利用通知、明細照会、不正検知、管理者向け操作画面です。
これらに加えて、取引ログ、照合、日次締め、監査証跡、障害監視、再送制御、バックアップ、災害対策まで含めて初めて本番運用に耐える基盤になります。
見積書に「カード機能一式」とだけ記載されている場合は注意が必要です。
たとえば、カード発行の画面は含まれていても、勘定系への残高照会、通信タイムアウト時のリトライ、売上確定データとの照合。返金の顧客通知が別費用になっていることがあります。
機能名ではなく、どの業務状態まで責任を持つかで範囲を分解することが大切です。
承認・ホールド・売上確定・返金の状態遷移が重要です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
一般的な取引は、加盟店から利用要求を受ける「承認」、口座残高から利用額を一時的に確保する「ホールド」。
加盟店から売上確定データを受けて正式に引き落とす「売上確定」、必要に応じた「取消・返金」という順で進みます。
承認が成功しても売上確定データが遅れたり、通信が途中で切れたりするため、各状態を別々に管理し、同じ要求を二重処理しない冪等設計が欠かせません。
たとえば、利用時点の引き落とし後に加盟店から売上確定データが届く場合、金額差分の追加引き落としや返金が発生します。
JCBの公式案内でも、売上確定の内容によって返金時期や一時的な二重引き落としが生じる場合が説明されています。
したがって、画面の見た目よりも、例外時に顧客残高とカード元帳を一致させる処理が開発費とテスト工数を左右します。
デビットカード基幹システム開発の進め方
開発は、カードの画面やAPIを先に作るのではなく、発行スキームと資金の流れを確定してから進めます。
特に、J-Debitと国際ブランド付きデビットでは接続先、利用チャネル、ブランド試験、
精算方法が異なります。企画、要件定義、PoC、設計、開発、認定試験、移行、運用設計を一つの工程表で管理すると、
後から追加費用になりやすい作業を見落としにくくなります。
企画・要件定義で決める項目
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初に、発行主体、対象顧客、カードブランド、国内外の利用範囲、ATMやECへの対応、口座の種類、カード枚数、月間取引件数、ピーク時の取引件数を定義します。
続いて、カード管理、オーソリゼーション、残高・元帳、精算、通知、管理画面、不正検知のどこを新設し、どこを既存サービスに任せるかを決めます。
この段階で、ピークTPS、平均応答時間、可用性、障害復旧時間の目標、データ保存期間、監査ログ、RTO、RPOを数値にします。
「大量アクセスに耐える」「すぐに復旧する」だけでは見積比較ができないためです。
要件定義の成果物として、業務フロー、状態遷移図、外部接続一覧、データ項目一覧、非機能要件、責任分界表を残すと、提案会社の見積条件をそろえやすくなります。
PoC・接続設計でリスクを先に確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
実装前には、実際の電文またはサンドボックスを使い、残高照会から資金確保、承認結果の返却までの時間を測定します。
画面モックだけのPoCでは、タイムアウト、重複要求、途中切断、加盟店側の再送、売上確定金額の差異といった本質的なリスクを発見できません。検証項目を絞っても、正常系と異常系の両方を通すことが重要です。
接続設計では、勘定系、カードブランド、CAFISやその他の決済ネットワーク、PSP、KYC・不正検知、銀行アプリ、メールやプッシュ通知を整理します。
NTTデータのCAFISサービスラインナップでは、J-Debit業務の導入とクリアリングセンターによる決済事務処理の省力化が案内されています。
このような標準サービスを利用できるかどうかは、個別開発の範囲と初期費用を左右するポイントです。
テスト・認定・移行・運用を工程に含めます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
金融系の決済基盤では、単体テストが通ればリリースできるわけではありません。
ブランド認定、接続試験、性能試験、セキュリティ診断、総合テスト、障害復旧訓練、利用通知の確認、照合テスト、業務部門の受入テストを計画します。
残高不足、通信タイムアウト、取消後の再送、売上確定の遅延、返金、日付をまたぐ取引、同一要求の二重到着をテストケースに含めます。
既存カードからの移行がある場合は、カード情報、会員情報、利用限度額、停止状態、未確定取引、返金待ち取引を分類します。
データ移行の件数が多いだけでなく、移行中に新しい取引が発生するため、並行稼働、差分連携、切替リハーサル、切戻し条件が必要です。
公開後は常時監視、未完了取引の照合、インシデント対応、ブランド仕様変更への追随までがランニング業務になります。
デビットカード基幹システムの費用相場とコストの内訳
デビットカード基幹システムには、一般的な業務システムのような一律の公開価格がほとんどありません。
カード枚数、取引量、ブランド数、勘定系の種類、リアルタイム性、可用性、PCI DSSの適用範囲、
移行データ、運用体制が案件ごとに異なるためです。以下の金額は2025〜2026年時点で、
カードプロセシング、決済ゲートウェイ、銀行系リアルタイム連携に類似する案件から整理した編集部推定であり、
正式見積ではありません。
対象範囲別の初期費用と期間の目安
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
既存プロセッサやASPに接続し、アプリと管理画面を追加する小規模な構成は、初期費用3,000万円〜8,000万円、期間4〜8か月程度が目安です。
1ブランド、既存勘定系APIあり、標準機能中心という前提です。
カード発行・承認・精算・通知・移行・総合テストを含むパッケージやクラウドの導入では、8,000万円〜3億円、期間8〜15か月程度を見込みます。
複数ブランド、高可用性、外部ネットワーク複数接続、24時間監視、不正検知、災害対策を含む金融機関向けプロセシング基盤では、3億円〜8億円。期間15〜24か月程度が目安です。
発行・カード管理から精算、周辺業務、データ移行、運用設計までをスクラッチで刷新する場合は、8億円〜20億円超、24〜36か月以上になる可能性があります。
接続方式を選ぶための要件定義やPoCだけでも、1,000万円〜3,000万円、2〜4か月程度を見込むと比較しやすくなります。これは公開されたデビットカード単体の価格表ではありません。
取引量や責任範囲を置き換えれば、同じ方式でも金額は変わります。見積書では「本体開発費」「外部接続費」「ブランド認定費」「移行費」「テスト・監査費」「保守・運用費」を分けて記載してもらうことが大切です。
人件費・接続費・テスト費が初期費用を構成します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
初期費用の中心は、要件定義、業務設計、アーキテクチャ設計、アプリケーション開発、API・電文接続、管理画面、データ移行、テスト、プロジェクト管理の人件費です。
金融・決済の知識を持つ設計者やテスト担当者、運用設計者を配置するほど単価は上がりやすくなりますが、例外処理の漏れを減らせます。単純な画面数ではなく、取引状態と外部システムの組み合わせが工数を決めます。
外部費用には、クラウドの本番・検証環境、専用回線、監視、プロセッサやPSPの接続料、ブランドの試験・認定、脆弱性診断、PCI DSS準拠支援。バックアップ、ログ保管が含まれます。
カード番号を自社で保持する範囲が広いほど、暗号鍵管理、アクセス制御、監査、脆弱性対応の負担が増えます。
トークン化や外部プロセッサを利用し、カード情報の取り扱い範囲を縮小する設計は、開発費だけでなく継続的なコンプライアンス費用にも影響します。
ランニングコストと従量課金も分けて確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
標準的な小規模導入のランニング費は、クラウド、プロセッサ、接続回線、監視、保守、監査を含めて年1,000万円〜5,000万円程度。大規模基盤では年5,000万円〜2億円超が一つの推定レンジです。
ここにも公開価格を統計化した根拠はないため、自社の取引量と契約条件に置き換えて確認します。
月額固定費だけでなく、カード発行・郵送、1件ごとの取引従量課金、追加認証、ログ保管、休日対応の費用も確認が必要です。
クラウド型やASPは初期費用を抑えやすい一方、取引件数やカード枚数の増加で利用料が上がることがあります。
契約前に、開発・検証環境の料金、本番以外のバックアップ料金、ピーク時の一時的な増強、障害時の代替環境、データエクスポート、契約終了時の移行支援を確認します。
初期費用が安い提案でも、長期の保守、監査、認定、従量課金を合算すると、スクラッチとの差が縮まる場合があります。
費用を左右する変動要因とコスト最適化のポイント
同じデビットカード基幹システムでも、カード枚数だけで費用は決まりません。ブランド数、
国内外の利用、月間取引件数とピークTPS、勘定系のAPI有無、24時間365日の可用性、
移行の有無、不正検知、複数通貨、カード情報を保持する範囲が複合的に効きます。見積を下げるときは重要な統制を削るのではなく、
標準機能に合わせる範囲と独自開発する差分を整理します。
カード枚数・取引量・可用性が価格を押し上げます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
月間の平均取引件数が少なくても、給料日やキャンペーン時に処理が集中するなら、ピークTPSに対応した構成が必要です。
オートスケールだけでなく、残高照会、ホールド、元帳更新、通知、監視が同じ整合性を保って動くかを検証します。
金融機関向けに、複数リージョンや待機系、RTO・RPOの厳しい水準、24時間の有人監視を求めると、クラウド利用料と設計・試験工数が増えます。
ブランド数が増える場合は、電文仕様、認定試験、例外処理、問い合わせ窓口、精算サイクルが増えます。
海外利用やマルチカレンシーに対応すると、為替、日付・休日、現地規制、返金やチャージバックの扱いも設計対象です。
最初からすべてを搭載するのではなく、国内1ブランド、標準的な利用チャネル、限定されたカード種別で開始し、利用実績を見て拡張する方法がコスト最適化につながります。
標準基盤と段階導入で独自開発を絞ります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
コストを抑えやすいのは、標準パッケージやクラウド型プロセッサを使い、カード情報管理、ネットワーク接続、監視などを専門サービスへ寄せる方法です。
自社の差別化に直結する会員体験、利用制御、銀行アプリ、分析だけをAPIで拡張すると、フルスクラッチより短期間で価値を出しやすくなります。
標準仕様に業務を合わせるFit-to-Standardを検討し、例外業務を増やす前に、その例外が売上や顧客維持に本当に必要かを評価します。
ただし、安易に外部サービスへ寄せると、ベンダーロックインや障害時の責任分界が問題になります。
契約前に、API仕様、データ形式、取引ログの取得、カード情報の返却・削除、価格改定、SLA、障害時の補償、サービス終了時の移行支援を確認します。
標準基盤を使いながら、業務元帳や分析データを自社側にも保持するなど、将来の乗り換えを想定した境界設計が有効です。
セキュリティ対応を後付けにしないことが節約になります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
カード情報を扱う範囲、認証方式、暗号化、鍵管理、特権ID、脆弱性管理、ログ監視、委託先管理を要件定義の時点で決めます。
PCI Security Standards Councilの文書ライブラリでは。PCI DSS v4.0.1と2025年1月版の関連テンプレートが公開されています。
また、PCI DSS v4.0.1は2024年12月31日以降の現行版とされ。
将来日要件の適用期限は2025年3月31日と説明されています（出典：PCI Security Standards Council、2024〜2025年）。
後から準拠範囲を広げると、設計変更、再試験、監査対応が重なって費用が膨らみます。
経済産業省のクレジットカード・セキュリティガイドラインでも、カード情報保護や不正利用対策が関係事業者の実務上の重要事項として示されています。
デビットカード基盤でも、ブランドや業務スキームに応じて、発行会社、PSP、加盟店、外部サービスの責任分界を確認します。
NTTデータが2026年1月27日に発表したMy PalleteとMyJCBの連携は、銀行アプリを起点に口座、カード。決済を横断する顧客接点が広がっている事例です（出典：NTTデータ、2026年）。
接続先が増えるほど、認証と権限管理の設計を初期から含める必要があります。
見積もりを取る際のポイント
見積を依頼するときは、会社名や機能名だけでなく、カード枚数、月間取引件数、ピークTPS、
ブランド数、利用チャネル、勘定系の接続方式、データ移行件数、可用性、RTO・RPO、
カード情報の保持範囲を提示します。条件が揃っていない複数見積は、安いか高いかを比較できません。
最初から詳細な仕様をすべて決める必要はありませんが、金額を左右する前提は同じにすることが大切です。
RFPには取引状態と責任分界を記載します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
RFPでは、承認、ホールド、売上確定、取消、返金、残高不足、タイムアウト、通信再送、日付またぎ、障害復旧の流れを記載します。
さらに、カードブランド・ネットワーク・勘定系・アプリ・不正検知・通知サービスの接続先と、各システムが保持する正とするデータを明らかにします。
たとえば、残高は勘定系が正なのか、カード元帳が一時保留を持つのかが曖昧だと、設計・テスト・障害対応の見積が会社ごとに変わってしまいます。
提案依頼時の質問として、
「同じブランドと勘定系を接続した実績はありますか」「同等のピークTPSと可用性を本番で達成した実績はありますか」「売上確定や返金の不整合をどのように検知・補正し
ますか」「ブランド認定とPCI DSS対応の範囲はどこまでですか」「障害時に顧客・加盟店・金融機関のどこが対応しますか」を用意します。
実績の数だけでなく、障害や切替を含む経験を確認することが重要です。
初期費用だけでなく5年間の総保有コストで比較します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
比較表では、初期開発費、月額固定費、取引従量課金、カード発行費、保守費、監視費、セキュリティ診断費、ブランド認定費、追加開発費、データ移行費を分けます。
開発会社によって「保守に含む」「別途見積」「利用料に含む」の定義が違うため、金額の横に対象範囲と除外項目を記載してもらいます。
特に、テスト環境、バックアップ、ログ保管、休日・夜間対応、障害時の増員は見落とされやすい項目です。契約形態も費用とリスクを左右します。
要件が固まっている機能は請負、PoCや要件整理のように変動する作業は準委任に分ける方法があります。
納品物、検収条件、遅延時の扱い、SLA、損害や返金の責任、データ返却、監査協力、契約終了時の移行を定めます。
価格だけでなく、5年間またはカードサービスの想定運用期間に、どの費用と責任を負うかで発注先を選びます。
安さだけでなく資金整合性と出口条件を評価します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
デビットカードでは、障害時に「承認したが引き落とせていない」「引き落としたが売上確定が届いていない」「返金したが顧客へ通知できていない」という状態が起きます。
提案書に、未完了取引の検知、再送、照合、手動補正、顧客への案内、加盟店への連絡の方法が書かれているかを確認します。障害対応が運用費の対象外なら、必要な体制を別途見積に入れます。
また、将来ベンダーを変更できるかを確認します。
データを標準形式で取り出せるか、カード番号をトークン化した場合に新サービスへ移行できるか、APIや電文仕様が文書化されているか。契約終了時に何日で返却・削除されるかを確認します。
ロックイン対策を契約とアーキテクチャに含めておくことは、将来の追加費用を抑える投資です。
よくある質問
ここでは、デビットカード基幹システムの費用や発注を検討する担当者から寄せられやすい質問に回答します。
金額の目安は前提条件によって変わるため、自社のカード枚数、取引量、ブランド、勘定系、
運用水準を当てはめてご確認ください。
デビットカード基幹システムの開発費はいくらですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
既存プロセッサやASPへの接続を中心とする小規模構成なら3,000万円〜8,000万円程度。パッケージやクラウドを勘定系・アプリと連携する構成なら8,000万円〜3億円程度が目安です。
複数ブランド、高可用性、24時間運用、移行、不正検知まで含む金融機関向け基盤は3億円〜8億円程度、全面スクラッチでは8億円〜20億円超になる場合があります。
いずれも公開価格の統計ではなく、対象範囲を置いた推定です。
ASP・クラウド・スクラッチはどれを選べばよいですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
標準機能で早く提供したい場合はASPやクラウド、既存の勘定系を活かしながら独自部分を追加したい場合はハイブリッド。業務やサービスに大きな差別化がある場合はスクラッチが候補です。
ただし、カード情報管理、ブランド接続、監視、認定試験まで自社で担う必要があるかを確認してから選びます。費用だけでなく、開始時期、自由度、運用負担、契約終了時の移行性を5年間で比較してください。
開発期間はどのくらいかかりますか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
既存APIを利用した小規模な接続なら4〜8か月、カード管理・承認・精算・通知・移行を含む標準導入なら8〜15か月程度が目安です。
複数ブランド、高可用性、認定試験、旧システムとの並行稼働まで含めると15〜24か月以上。スクラッチで周辺業務も刷新すると24〜36か月以上になる可能性があります。
要件定義とPoCを2〜4か月先に実施し、接続リスクを確認してから本開発の見積を固める方法もあります。
PCI DSS対応は見積のどこに含まれますか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
要件定義、設計、実装、脆弱性診断、監査資料の作成、認証・鍵管理、ログ監視、委託先評価などに分散して含まれます。
提案会社によっては準拠支援を別費用にしているため、PCI DSSの対象範囲、準拠支援の成果物、診断の回数、監査人や評価機関との調整を明記してもらいます。
外部プロセッサを使って適用範囲を縮小できる場合でも、自社アプリや運用の責任がなくなるわけではありません。
まとめ
デビットカード基幹システムの費用相場は、標準サービスへの接続で3,000万円〜8,000万円程度、
パッケージやクラウド導入で8,000万円〜3億円程度、複数ブランドの高可用基盤で3億円〜8億円程度、
全面スクラッチで8億円〜20億円超という整理ができます。これは2026年時点の公開定価ではなく、
機能、取引量、ブランド、接続、移行、セキュリティ、運用を前提にした推定です。
見積比較では資金整合性と総保有コストを見ます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
初期費用だけで決めず、プロセッサやクラウドの従量課金、保守・監視、PCI DSS、ブランド認定、データ移行、障害対応、5年間の運用費を合算します。
特に、承認からホールド、売上確定、取消、返金までの状態遷移と責任分界が見積に含まれているかを確認します。安い提案を選ぶことより、後から別費用になる作業を最初に見えるようにすることが重要です。
最初に自社の前提条件を1枚にまとめます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
発注前には、カード枚数、月間取引件数、ピークTPS、ブランド、利用チャネル、勘定系の接続方式、保有するカード情報、移行件数、SLA。RTO・RPOを1枚にまとめます。
そのうえで、標準ASP、クラウドプロセッサ、ハイブリッド、スクラッチを同じ条件で比較し、必要なら小さなPoCで残高照会、ホールド、タイムアウト。返金の整合性を検証します。
riplaでは、業務整理から要件定義、開発、既存システム連携、運用設計まで、プロジェクトの状況に合わせた相談が可能です。
▼全体ガイドの記事
・デビットカード基幹システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。