自動車保険設計システム開発の見積相場や費用/コスト/値段について

自動車保険設計システムの開発費用は、対象範囲、連携数、料率管理、可用性要件によって、1,000万〜10億円超まで変わります。

費用相場の目安、費用の内訳と変動要因、進め方と見積の確認点を順に取り上げます。全体像は自動車保険設計システム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・自動車保険設計システム開発の完全ガイド

自動車保険設計システムの全体像と費用の考え方

自動車保険設計システムを代理店向け比較見積、保険会社向け基盤、顧客向けWeb申込に分けた図。
扱う業務の広さが、開発範囲を分ける出発点です。

自動車保険設計システムは、車両や運転者の情報をもとに保険料を算出する業務システムです。補償内容を設計し、見積書や申込書を作成するところまで担います。

入力画面だけを作る場合と、商品・料率管理から契約までつなぐ場合とでは、費用が大きく異なります。そこで、まず対象業務を分類して開発範囲を決めておくと、予算の精度を高められます。

代理店向け比較見積システム

代理店向けシステムは、契約者や車両の情報を一度入力すれば、複数の保険会社の見積を比べられる仕組みです。ただし、保険会社ごとの差を共通項目へ変換する設計が必要になり、この設計が費用を左右します。

  • 見積比較:複数の保険会社へ見積を依頼し、結果を並べて比べます。
  • 補償の共通化:補償名、特約条件、入力項目、料率をそろえます。
  • 業務連携:比較推奨、意向確認、証券取込、顧客管理を相互につなぎます。

比較推奨の理由や意向確認の履歴も、システムに残す対象になります。また、見積画面に加えて連携範囲を広げるほど、開発費用は上がります。

保険会社向け基盤と顧客向けWeb申込

保険会社向けの基盤は、商品や補償、料率を起点に、契約から保険金の支払までを管理します。

  • 商品管理:料率テーブル、適用期間、承認フローを管理します。
  • 契約業務:契約、更新、変更、解約、保険金支払を扱います。
  • Web申込:本人確認、決済、申込成立までの導線を整えます。

顧客向けWeb申込では、アクセスが集中しても止まらないための非機能要件も欠かせません。保険会社型は業務範囲と責任が広くなり、顧客向け型は認証や決済への投資が増えます。

自動車保険設計システムの費用相場の目安

自動車保険設計システムの4つの開発範囲と初期費用幅を対応させたパネル図。
対象業務の広がりに応じて、費用の目安も段階的に変わります。

自動車保険設計システムの初期開発費は、1,000万円台から数億円まで幅があります。比べる目安として、一般的な業務系Webシステムは、小規模で100万〜300万円、中規模で300万〜800万円、大規模で800万円〜数千万円とされています。

この目安は、2026年6月公開の資料によるものです。出典は、イー・ジーシステム株式会社「システム開発の費用相場と見積書の読み方(2026年版)」です。

自動車保険向けでは、この目安に加えて、正確性、外部連携、監査、可用性の費用が上乗せされます。

見積MVPは1,000万〜3,000万円

見積MVPは、対象を絞り込んだ場合に初期費用の目安として置く範囲です。

  • 対象範囲:1チャネル、1〜2社、限定商品に絞ります。
  • 主な機能:見積計算、PDF出力、簡易な商品管理を扱います。
  • 収まりやすい条件:既存CRMや保険会社側のAPIを利用します。

申込や契約管理を対象外にできれば、この範囲に収まりやすくなります。一方で、RPAや証券OCR、複雑な特約、権限分離を加えると、上限を超える可能性があります。また、厳格な監査ログまで同時に求める場合も、MVPの費用は上がります。

代理店向け比較見積は3,000万〜8,000万円

代理店向け比較見積は、複数社の条件をそろえたうえで比べ、判断を支えるシステムです。

  • 比較対象:3〜6社程度の見積を比較します。
  • 業務機能:補償共通化、比較推奨、意向把握を扱います。
  • 連携機能:証券取込、CRM連携、代理店権限を含めます。

接続方式がAPI、ファイル、RPAに分かれると、接続先ごとに例外処理が必要になります。さらに、障害時の再実行も設計に含め、拠点数や利用者数が多ければ教育費も見積に加えます。権限設計や問い合わせ対応の費用も、利用規模に応じて加わります。

保険会社向け基盤は8,000万〜3億円

保険会社向けの基盤は、商品管理から契約、支払までを一貫して扱います。

  • 業務範囲:商品・料率管理、見積、申込審査、契約を扱います。
  • 契約後業務:更新、変更・解約、帳票、決済を含めます。
  • 周辺連携:代理店・顧客チャネル、保険金支払とつなぎます。

新旧基盤の並行稼働や、複数チャネルの性能試験も費用に影響します。さらに、災害時の復旧設計と監査証跡まで含めると、移行と品質保証の比率が高まります。初期費用だけで判断せず、料率改定や障害対応の運用コストも見ておく必要があります。

基幹刷新や契約・支払まで含めると3億円超

基幹刷新まで含める案件は、単一機能の開発と比べて大きな予算が必要になります。

  • 刷新範囲:レガシー基幹、契約、保険金支払を対象にします。
  • 基盤範囲:データ基盤、24時間運用、代理店網を含めます。
  • 移行範囲:段階的なデータ移行と新旧切替を扱います。

費用は3億〜10億円超となることもあります。期間も24〜60か月程度に及びやすいため、業務改革と移行を含むプログラムで管理します。ただし、会社数や契約件数、既存資産、接続先、目標復旧時間によって、個別に変わります。

ポイント

同じ自動車保険設計システムでも、対象を見積MVPに絞るか基幹刷新まで含めるかで費用は大きく変わります。まず対象範囲を決めてから相場を見ると、比べやすくなります。

自動車保険設計システムの費用内訳

見積書は「システム開発一式」とまとめず、工程と機能のまとまりごとに確認します。費用は一般に、人月単価、必要工数、付帯費用を掛け合わせて決まります。特に、要件定義の精度によって、金額が倍以上動くこともあります(出典:イー・ジーシステム株式会社の2026年資料)。

保険システムでは、さらに正解データ、回帰テスト、外部接続、監査対応も必要になります。

企画・要件定義・設計の費用

企画では、発注側が何を改善するシステムかを先に定義しておきます。

  • 業務目的:代理店の入力負荷、商品改定、申込完了率を見ます。
  • 入力情報:車両、用途、走行距離、運転者、年齢を整理します。
  • 保険条件:免許証、等級、事故歴、補償、特約を洗い出します。

割引や割増まで含めて業務ルールを確かめ、画面の見た目だけで要件を決めないことが大切です。計算条件や帳票の確認が不足していると、開発後の修正で追加費用が発生しやすくなります。

外部連携・データ移行・帳票の費用

費用が膨らみやすいのは、外部システムとの接続と既存データの移行です。

  • 接続先:保険会社、代理店、顧客管理、会計と連携します。
  • 周辺機能:本人確認、決済、電子契約、帳票をつなぎます。
  • 移行作業:名寄せ、欠損補正、商品対応、リハーサルを行います。

API連携でも、認証、タイムアウト、再送を設計する必要があり、重複登録や代替運用の決め方も欠かせません。APIがない場合にRPAを使うと、画面変更の検知と手動切替も見積に含める必要があります。また、既存契約データの移行項目を分けて示すと、見積を比べやすくなります。

テスト・セキュリティ診断・リリースの費用

保険料の計算は、代表的な1ケースが動くだけでは確認が終わりません。

  • 計算確認:車種、料率クラス、年齢、等級を照合します。
  • 条件確認:事故有無、用途、特約の組み合わせを検証します。
  • 品質確認:機能、連携、性能、脆弱性、権限を試験します。

商品改定のたびに、正解データを使った回帰テストを実行します。障害復旧訓練や受入テストは、教育やリリース支援とあわせて費用に含めます。これらを除いた見積は安く見えますが、運用後の手戻りが大きくなりがちです。

クラウド・保守・改定対応のランニングコスト

継続費用には、クラウド利用料が含まれます。監視、バックアップ、ログ保管も、継続費用として見ておく必要があります。

  • 運用費:セキュリティ、問い合わせ、障害対応を含めます。
  • 更新費:OSやミドルウェア、料率、商品を更新します。
  • 追加費:新たな連携や利用規模の拡大に対応します。

クラウド型パッケージの場合、初期設定、移行、連携開発で500万〜3,000万円です。月額の利用料と保守は10万〜300万円程度を仮置きしますが、公開されている定価ではありません。

見積を見る際は、利用者数、保険会社数、API数の規模を確認します。データ量やSLA、サポート時間も確かめ、3年または5年の総保有コストで比べます。

ポイント

見積は工程と機能のまとまりごとに確かめ、要件定義の精度や、テスト・診断・運用費まで含めて比べると、金額の違いを読み解きやすくなります。

自動車保険設計システムの価格が変動する要因

自動車保険設計システムの価格要因を、業務範囲、商品・料率、外部連携・移行、可用性・セキュリティ・監査の4カードで整理した図。
見積条件をそろえると、要因ごとの影響を比べやすくなります。

価格は機能数だけで決まらず、正確性、変更のしやすさ、業務継続性によっても変わります。また、監査で説明できる履歴も、工数と品質保証費を左右します。

対象チャネルと業務範囲

対象とするチャネルが変われば、必要な権限やデータ保持期間も変わります。

  • 代理店画面:営業担当が使う業務画面を対象にします。
  • 顧客画面:顧客が使うWeb見積を対象にします。
  • 保険会社業務:契約管理、事故受付、保険金支払を扱います。

見積から申込まで含めると、本人確認と決済が加わるほか、同意取得や電子交付も必要になります。更新や変更・解約まで扱う場合は、状態遷移や帳票の再発行も求められます。また、過去時点の料率を再現する仕組みも、対象範囲に含めます。

商品・補償・料率の複雑さ

自動車保険の料率は、用途や車種、型式を含む多くの条件を使います。年齢や事故歴なども、料率の計算に使われます。

  • 参考純率:契約・支払データから算出される参考値です。
  • 商品管理:適用開始日、終了日、会社独自の付加保険料を扱います。
  • 履歴管理:旧商品の再現、承認者、変更履歴を残します。

損害保険料率算出機構は、会員保険会社の契約・支払データを使って参考純率を算出します。保険会社は、この参考純率を自社の保険料率を算出する基礎として利用できます。

ただし、参考純率は実際の契約保険料そのものではありません。出典は、損害保険料率算出機構「自動車保険参考純率」です。内容は2026年6月届出のものに基づきます。

接続先が増えるほど、データ項目と処理条件を一つずつ確認する手間が増えます。

  • 接続条件:マッピング、認証、エラーコード、処理時間を見ます。
  • 再実行条件:再送ルールと障害時の処理を決めます。
  • データ品質:欠損や重複を移行前後に確認します。

既存データに欠損や重複がある場合は、移行前にクレンジングが必要になります。保険契約では、過去の契約条件や事故歴を後から確認できることが欠かせません。移行対象の件数だけでなく、データ品質と過去時点の再現要件も開発会社に伝えます。

可用性・セキュリティ・監査の水準

保険会社向けの監督指針では、システムリスク管理などが確認事項になります。

  • 管理方針:障害やサイバー事案への対応を定めます。
  • 変更評価:商品変更時にシステムを評価します。
  • 情報資産:機密性、完全性、可用性を確認します。

出典は、金融庁「保険会社向けの総合的な監督指針」です。令和8年7月版の内容に基づいています。

権限分離や操作ログ、暗号化は削れません。診断、バックアップ、復旧目標も、削れない要件です。要求水準を曖昧にすると、終盤に高額な非機能対応が追加されやすくなります。

ポイント

価格は機能数だけで決まらず、対象チャネル、料率の複雑さ、外部連携と移行、可用性の水準で変わります。見積の差を比べる前に、どの要因がどの程度効いているかを確かめます。

費用をぶらさない自動車保険設計システムの進め方

全機能を一括で発注するより、業務の目的と難所を順番に確かめるほうが安全です。そのうえで、誰が、どのデータを、どの条件で変換し、どの証跡を残すかを決めておきます。

手順をそろえておくと、見積の前提がそろいます。そのため、開発会社ごとの見積を同じ条件で比べられます。

目的・対象利用者・KPIの定義

最初に、システムで改善したい主目的を一つに絞っておきます。

  • 代理店業務:見積作成時間を短くするかを見ます。
  • 保険会社業務:商品改定を速くするかを見ます。
  • 顧客業務:Web申込を増やすかを見ます。

KPIは、回答時間や入力エラー率を中心に設定します。改定リードタイムや申込完了率もKPIにできます。監査資料の作成時間や、障害からの復旧時間も含められます。

たとえば、見積回答を平均30分から10分へ短縮すると定義します。そうすると、必要な自動入力や連携の優先順位を判断しやすくなります。

業務フローと連携先の整理

現行業務は、見積から事故受付までの流れに沿って書き出します。

  • 業務工程:比較推奨、意向確認、申込、契約、更新を並べます。
  • 確認項目:入力元、判断者、帳票、保存期間、例外を記録します。
  • 手作業:現在の手作業とOCRの有無を整理します。

保険会社や業界基盤との接続方式は、CRMや会計、決済、本人確認と合わせて一覧にします。担当部署や仕様書、テスト環境を確認し、レート制限や障害時の連絡先も押さえておきます。連携先を把握しておくと、想定外の外部費用が発生するリスクを下げられます。

商品・料率とプログラムの分離

補償条件や料率をプログラムへ直接埋め込むと、改定のたびに開発が必要になります。

  • 商品管理:商品、料率、適用期間、バージョンを管理します。
  • 承認管理:承認者、変更理由、ロールバックを記録します。
  • 改定運用:業務部門が安全に改定できる仕組みを設けます。

損保ジャパンの「SOMPO-MIRAI」は、商品情報を一元管理しています。さらに、商品改定のシステム対応期間を、従来比で最大50%程度短縮したと公表しています。

出典は、損害保険ジャパン株式会社の2024年11月の公表です。規模が異なっても、改定対応を開発案件から切り離す考え方は参考になります。

難所のPoC検証と段階リリース

本開発の前に、代表的な条件で計算と連携の難所を小さく検証しておきます。

  1. 車種、等級、年齢条件、事故歴、特約の組み合わせで保険料を計算します。
  2. 複数社比較と証券OCR、APIまたはRPA連携を試します。
  3. ピーク時性能と権限分離を確認します。
  4. 見積・設計、申込・決済、更新・事故受付へ段階的に広げます。

新旧システムの並行稼働と切り戻しは、契約前に決めておきます。データ凍結と受入基準も、契約の時点で決めます。検証と切替条件を先に決めておくと、予定外の延長費用を抑えられます。

ポイント

全機能を一括で発注するより、目的と難所を先に確かめ、PoCで検証しながら段階的に進める方が、予算の見通しを立てやすくなります。

自動車保険設計システムのコストを最適化するポイント

コストを抑えるとは、技術を安くすることではなく、総コストを下げることです。将来の改定や障害への備え、データ移行、保守まで含めて判断することが大切です。

正確性や監査性を削ると、事故や訂正対応の費用が初期費用を上回ります。そこで、守る要件と後回しにできる要件を分けておくことが有効です。

MVP対象の見積・設計への絞り込み

契約、更新、事故、保険金支払まで最初から一度に作るのではなく、対象を絞って始める進め方があります。

  • 初期範囲:最も効果を測りやすい見積・設計から始めます。
  • 検証指標:見積回答時間や入力エラー率を確認します。
  • 将来機能:追加機能の優先順位を残しておきます。

1チャネル、主要商品、限られた接続先に絞ってMVPを作ります。そのうえで、再設計が必要な機能と、データモデルだけ先に用意する機能を分けておきます。

パッケージ・クラウド・API・RPAの役割による使い分け

技術名ではなく、導入期間や改定頻度を基準に選びます。接続先と運用体制も、選定の条件に含めます。

  • パッケージ・クラウド:顧客管理や意向把握を短期導入します。
  • RPA:APIがない画面の短期自動化に使います。
  • API・モジュール:長期連携や大規模刷新に使い分けます。

RPAは画面変更に弱いため、長期的にはAPIやファイル連携へ移行します。また、商品差別化や大規模刷新では、モジュール型やスクラッチが適する場合があります。

商品・料率マスタの運用の標準化

保険会社ごとの差は共通項目へ変換し、例外だけを個別に定義します。

  • 標準項目:商品、補償、特約、適用期間をそろえます。
  • 版管理:料率バージョン、承認、公開日時を管理します。
  • 変更記録:申請、レビュー、テスト、ロールバックを残します。

標準化しておけば、追加商品のたびに画面や計算ロジックを大きく改修せずに済みます。また、業務部門とシステム部門の確認時間も短くできます。

テストデータと回帰テストの再利用

代表的な条件の組み合わせを、正解データとして管理します。車種、年齢、等級などの条件が中心です。

  • 再実行:商品改定時に同じケースを再確認します。
  • 自動化:手作業だけでなく自動テストへ組み込みます。
  • データ保護:本番データを匿名化または合成データにします。

同じケースを再実行できれば、確認工数を抑えながら品質を維持できます。自動化には初期費用がかかりますが、改定頻度が高いほど保守費用を下げやすくなります。

見積もりを取る際に確認すべきポイント

見積を比べるときは、総額の大小より先に、同じ前提で比べられるかを確かめます。

  • 規模条件:利用者、保険会社、商品、契約件数をそろえます。
  • 性能条件:ピークアクセス、復旧目標、運用時間を示します。
  • 対象範囲:チャネル、移行、帳票、認証、ログを記載します。

未確定の項目には「要件未確定」と明記したうえで、確定後に費用が増減する条件を開発会社に質問します。

RFPに書く保険固有の要件

RFPには、基本補償や特約の条件を具体的に書きます。年齢条件と運転者限定も、そこに含めます。

  • 補償条件:対人・対物、車両、人身傷害を示します。
  • 料率条件:型式別料率クラス、等級、事故歴を示します。
  • 契約条件:割引・割増、変更、解約、更新案内を示します。

比較推奨の理由、意向確認、重要事項説明、契約概要の出力も明記します。電子交付の要否や、補償差を共通化する範囲も定義しておきます。

例外を個別に表示する条件まで決めておくと、各社の見積条件をそろえやすくなります。

複数社の見積の工程別比較

見積書は「開発一式」でまとめず、工程別に分けて比べます。

  • 開発工程:要件定義、設計、開発、外部連携を分けます。
  • 移行・品質:データ移行、テスト、診断、教育を分けます。
  • 運用工程:リリース、保守、追加対応を分けます。

工程別の内訳がある見積のほうが、前提と差分を比べられます。前述のイー・ジーシステム株式会社の資料でも、その点が説明されています。成果物や担当者、期間は、前提条件と除外事項とあわせて並べて確認します。

契約・受入・保守条件

要件定義と本開発では、それぞれの工程に合う契約形態を検討します。

  • 契約形態:要件定義を準委任、開発を請負または準委任にします。
  • 受入基準:計算、帳票、再処理、権限、ログ、性能を定めます。
  • 保守条件:改定、障害、緊急対応、復旧目標を定めます。

脆弱性の許容条件や、法令・商品変更への対応は、受入基準に含めます。加えて、追加機能の単価や対応時間、再委託、知的財産の扱いまで確認します。

ポイント

見積を比べるときは、総額の大小より先に、規模・性能・対象範囲の前提がそろっているかを確かめます。前提がそろわない見積は、そのまま比べると判断を誤りやすくなります。

最新の事例では、見積画面だけでなく、改定対応や段階移行も重視されています。

  • 商品改定:変更しやすい商品管理を重視します。
  • 連携方式:APIでシステム間の依存関係を抑えます。
  • 移行方式:クラウド基盤へ段階的に移行します。

2026年の予算では、サービスが増えた後も変更しやすい設計に投資するかを判断します。

商品管理とAPI連携で改定対応を速くする事例

損保ジャパンは2024年11月、自動車保険の基幹システム刷新の完了を公表しました。

  • 商品管理:商品、補償、保険料を一元管理します。
  • API連携:機能・サービス単位で依存関係を抑えます。
  • 対応速度:改定対応期間を従来比で最大50%程度短縮しました。

「SOMPO-MIRAI」は、新商品やサービスへの対応を速くすることを目指しています。この事例から、初期費用だけでなく、改定1回あたりの保守工数も見る必要があることが読み取れます。

止められない業務をクラウド基盤で支える事例

野村総合研究所は2025年12月、三井ダイレクト損保の事例を公開しました。

  • 基盤:次世代システムに「NRIクラウド OCI区画」を選びます。
  • 業務継続:24時間365日止められない業務を支えます。
  • 移行:旧システムから数年かけて段階移行します。

2030年を見据え、クラウドの拡張性と金融業務の統制・堅牢性を両立します。出典は、野村総合研究所の2025年12月の公開事例です。

評価するときは、月額費用だけでなく、停止や拡張、移行の仕方まで見ます。復旧や運用体制も含めて確認します。

よくある質問(FAQ)

費用は、対象チャネルや料率の複雑さ、外部連携、移行、可用性によって変わります。予算策定や発注前によく聞かれる質問に、直接答えます。

自動車保険設計システムの開発費用は最低いくらですか?

限定した見積MVPであれば、初期費用は1,000万〜3,000万円程度を仮置きできます。

  • 前提:1チャネル、限定商品、1〜2社接続に絞ります。
  • 機能:見積とPDF出力を中心にします。
  • 変動要因:API、料率、テスト、診断の範囲で変わります。

安い見積では、商品改定と移行の範囲を確かめます。障害復旧や保守が含まれているかも、あわせて見ます。

パッケージとスクラッチ開発はどちらが安いですか?

業務がパッケージに合う場合は、初期開発費を抑えやすくなります。

  • パッケージ:初期設定、移行、追加連携、個別帳票が必要です。
  • スクラッチ:独自商品や深い基幹連携に対応しやすくなります。
  • 比較方法:利用料と改修費を3年または5年で合算します。

スクラッチは独自性を実現しやすい一方で、初期費用が上がります。料率改定や保険会社の追加に対応できるかも、合わせて比べます。

自動車保険設計システムの開発期間はどれくらいですか?

開発期間は、対象範囲によって3〜60か月程度まで変わります。

  • 見積MVP:3〜6か月程度です。
  • 代理店向け比較見積:6〜12か月程度です。
  • 保険会社向け基盤:12〜24か月程度です。
  • 基幹刷新:24〜60か月程度です。

期間を左右するのは、データ移行、外部接続、受入テスト、新旧並行稼働などです。事前にPoCで難所を確認しておくと、延長を防ぎやすくなります。

料率改定に強いシステムにするには何が必要ですか?

商品・補償・料率はプログラムから切り離し、商品マスタで管理します。

  • 版管理:適用期間、バージョン、承認、変更履歴を管理します。
  • 公開管理:テスト結果、公開、ロールバックを残します。
  • 回帰テスト:車種、等級、年齢、事故歴、特約を検証します。

業務部門とシステム部門が、同じ証跡を確認できる状態にしておきます。変更権限と承認フローまで設計し、管理画面の追加だけで対応しないことが大切です。

まとめ

費用は、見積MVPの1,000万〜3,000万円から基幹刷新の3億円超まで幅があります。システムの種類別では、代理店向け比較見積は3,000万〜8,000万円、保険会社向け基盤は8,000万〜3億円です。

金額を左右するのは、保険会社数と料率、連携や移行の範囲です。テストと監査、可用性、保守条件も、金額に影響します。

発注前には、対象チャネルとKPIを定義し、商品・料率をデータとして管理する形を決めておきます。RFPには、正解データを使った回帰テストや段階リリースの条件を書きます。並行稼働と復旧条件も、同じRFPに含めます。

複数社の見積は、工程別と除外事項別に比べ、3年または5年の総保有コストで判断します。

▼全体ガイドの記事
・自動車保険設計システム開発の完全ガイド

会社紹介

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

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

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

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

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

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