結論：保険数理システムの開発費用は、計算エンジンだけなら1,500万円〜5,000万円、
複数商品・既存契約・周辺連携を含む基幹刷新なら1億円〜5億円超が初期予算の目安です。
ただし、保険数理システムは一般的な業務システムのように画面数だけで価格を判断できません。
保険料、解約返戻金、責任準備金、将来キャッシュフローなどの数理ロジックを正確に再現し、
過去契約を含めて新旧計算結果の差分を説明できる状態まで作り込む必要があるためです。
本記事では、保険数理システムの費用相場、内訳、価格が変動する要因、開発の進め方、
見積もりの比較方法、コストを抑えるポイントを、2026年時点の情報をもとに解説します。
▼全体ガイドの記事
・保険数理システム開発の完全ガイド
保険数理システムとは何ですか？
保険数理システムとは、保険商品の基礎率や数理モデルを使い、保険料、給付、解約返戻金、
責任準備金、収益性などを計算するためのシステムです。契約を登録・変更・保全する契約管理システムとは役割が異なり、
契約データを受け取って将来のキャッシュフローやリスクを評価する計算エンジンに近い位置付けです。
契約管理システムとの違いを理解する
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
契約管理システムは、申込受付、契約成立、住所変更、保険料入金、給付金請求、解約など、契約の状態と業務処理を管理します。
一方、保険数理システムは、その契約条件と基礎率をもとに、いくらの保険料が必要か、将来いくらの給付が見込まれるか、責任準備金をいくら積むべきかを計算します。
両者を一つの大きなシステムとして作ることもできますが、計算ロジックを独立したサービスやパッケージとして管理すると。商品改定時に契約管理画面全体を改修せずに済む場合があります。
見積もりの最初の分岐は、計算エンジン単体を導入するのか、契約管理・会計・DWH・販売支援まで含む基幹刷新なのかです。
ここを曖昧にしたまま複数社へ相談すると、一方はモデル移植だけ、もう一方はデータ移行まで含めた金額を提示し、比較できない見積もりになります。
主要機能と費用に影響する範囲
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
主要機能は、基礎率・前提管理、商品・保険料計算、責任準備金や契約者価値の評価、シナリオ分析、帳票出力、データ連携、監査証跡です。
たとえば前提管理では、死亡率、解約率、継続率、経費、運用利回りなどを商品や契約世代ごとに版管理し、適用期間を切り替えます。
商品数が増えるほど数式や例外条件の検証対象が増え、過去契約を再計算する場合は、当時の基礎率や制度を復元する作業も必要になります。
また、決算期だけに計算するのか、商品設計や販売画面から即時に呼び出すのか、大量契約を夜間バッチで処理するのかによって、必要な性能と構成が変わります。
確率論的シナリオを多数回実行する場合は、CPUやGPUの並列処理、ジョブスケジューラー、結果データの保管量まで費用に含める必要があります。
保険数理システム開発の進め方
保険数理システムの開発は、現行ロジックを調査し、要件を定義し、代表商品で検証してから段階的に移行する流れが安全です。
最初から全商品・全契約を一括移行するより、計算結果を比較できる小さな単位で成功条件を確認した方が、
後から発覚する差分や移行リスクを抑えやすくなります。
現行ロジックの棚卸しと要件定義を行う
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初に、現行プログラム、計算式、基礎率、前提表、帳票、入力データ、手作業、障害履歴を一覧化します。
メインフレームやCOBOLに実装された数式が担当者の記憶に依存している場合は、コードを読むだけでは足りません。
アクチュアリー、商品部門、契約管理部門、会計部門、IT部門から、丸め規則、日付の境界、契約状態、例外契約、旧商品の扱いを聞き取り。判断理由とともに仕様書へ残します。
要件定義では、商品数や契約件数だけでなく、計算頻度、1回の処理時間、1日あたりの処理可能件数、RTO・RPO、外部連携数、監査ログの保存期間。前提変更の承認者を決めます。
金融庁の保険会社向け監督指針でも、システムの制限値を把握し。制限値を超えた場合のシステム面・事務面の対応を検討する観点が示されています。
出典: 金融庁「保険会社向けの総合的な監督指針」、2026年。
代表商品でPoCとモデル移植を実施する
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
次に、代表的な商品と契約を選び、現行システムと新システムで同じ入力を計算します。
成功条件は、画面が表示されることではなく、保険料、返戻金、準備金、将来キャッシュフローなどの差分を項目別に説明できることです。
差分が出た場合に、丸め、利率の適用日、月割り・日割り、データ変換、旧商品の制度など、原因を切り分けられる設計にします。
PoCでは、通常ケースだけでなく、契約途中の変更、払済保険、失効からの復活、解約、特約の付加・消滅、過去の料率、欠損データを含むケースを準備します。
計算エンジンと業務アプリケーションを分離し、前提やルールをBRMS、モデルリポジトリ、APIで管理できれば、商品改定時の影響範囲を把握しやすくなります。
PoCの段階で将来の商品追加を想定したデータ項目を確認することが、手戻りを減らすポイントです。
並行計算・移行・本番リリースを進める
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
本開発では、数理モデル、前提管理、ジョブ管理、帳票、API、契約管理や会計との連携を実装します。
その後、単体テスト、結合テスト、総合テスト、総合運転テスト、受入テストを行い、旧システムとの並行計算で結果を照合します。
日立が公開する三井住友海上プライマリー生命の契約管理システム刷新事例では。
既存データを継承しながら約2年で新システムを構築したと説明されています。
出典: 株式会社日立製作所「三井住友海上プライマリー生命保険株式会社事例」。2013年掲載。
数理計算を含む基幹刷新では、移行と検証だけでも長期化しやすいことが分かります。
移行判定基準には、計算結果の一致率だけでなく、差分の説明完了率、処理時間、障害復旧時間、監査ログの取得、切戻し手順の実行結果を含めます。
金融庁の監督指針は、システム統合を基本検討、基本設計、詳細設計、製造、結合テスト、総合テスト、総合運転テスト。
移行という長期プロセスとして整理しています。
出典: 金融庁「保険会社向けの総合的な監督指針」、2026年。
新システムを作ることより、安全に業務を切り替えられることを完了条件に置く必要があります。
保険数理システムの費用相場と内訳
保険数理システム単体の成約価格を示す公開データは少ないため、ここで示す金額は、一般的な保険システムの公開レンジ、
数理モデル特有の検証工数、データ移行、並行稼働を踏まえた初期予算の目安です。契約件数や商品数が同じでも、
過去契約をどこまで再現するか、確率論的計算をどれだけ実行するか、会計・販売・DWHと何本接続するかで大きく変わります。
開発スコープ別の価格帯
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
初期予算は、次のようにスコープを分けて考えると比較しやすくなります。現行ロジックの調査と代表商品の再計算を行うPoCは、300万円〜1,000万円程度です。
1商品群・1部門向けのMVPで、保険料、返戻金、準備金の主要計算、前提管理、限定的なAPIと帳票までを含める場合は、1,500万円〜5,000万円程度です。
既存の数理パッケージを複数商品へ導入し、モデル移植、周辺連携、権限、監査、教育、並行検算まで行う場合は、3,000万円〜1億5,000万円程度が目安です。
全商品、過去契約、契約管理、会計、DWH、可用性、移行、運用設計まで含む大規模な基幹刷新では、1億円〜5億円超になる可能性があります。
一般的なシステム開発の2026年公開情報でも、大企業・金融の案件は監査対応、高可用性、多段階承認。
複雑な既存連携によって標準案件の数倍になり得ると説明されています。
出典: Casually「システム開発の料金相場」、2026年。
なお、保険システム全体の公開レンジとして3,000万円〜3億円程度が紹介されることがありますが、これは数理エンジン単体の価格ではありません。
数理システムにそのまま当てはめるのではなく、対象範囲、契約件数、計算頻度、移行年数、ライセンス、検算期間をそろえたうえで。上記の区分を初期予算の仮説として使うことが大切です。
見積もりに含める費用の内訳
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
費用の中心は、要件定義・現行解析、数理モデルの移植、アプリケーション実装、データ移行、インフラ構築、ライセンス、テスト、教育、保守です。
特に見落とされやすいのが、現行と新システムの計算結果を照合し、差分の原因を調べ、業務部門に説明する工数です。
数式を新しい言語へ書き換える作業だけでなく、曖昧な仕様を確定するアクチュアリーや商品担当者のレビュー時間も予算化します。
人月単価で見積もる場合、2026年2月公開の相場情報では、ジュニアエンジニアが50万〜80万円、ミドルエンジニアが80万〜120万円。
シニアエンジニアが100万〜180万円とされています。
出典: Casually「システム開発費用の相場一覧」、2026年。
保険数理案件では、一般的な実装担当者だけでなく、数理業務を理解する上流担当者、データ移行担当者、性能・セキュリティ担当者。
プロジェクトマネージャーが必要になるため、単価の低さだけで総額を判断できません。
初期費用以外のランニングコスト
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
導入後は、保守費、クラウドやサーバーの利用料、商用パッケージのライセンス、監視・バックアップ、脆弱性対応、制度・会計基準変更への改修費が発生します。
クラウドで大量計算を実行する場合は、契約件数やシナリオ数が増える時期に計算資源とストレージが膨らむため。固定費だけでなく従量課金の上限や予算アラートも確認します。
保守契約では、障害の一次受付、夜間・休日対応、モデル変更、前提値の登録、法令改定、性能チューニング、ユーザー教育のどこまで含まれるかを明確にします。
導入価格が安くても、商品改定のたびに個別見積が発生し、担当者が毎回ベンダーへ依頼しなければならない構成では、長期の総保有コストが高くなります。
費用が変動する要因とコスト最適化のポイント
保険数理システムのコストは、機能数よりも、正確性を証明するための検証範囲、既存資産を移行する難しさ、
計算量、統制要件によって動きます。費用を下げるには品質や安全性を削るのではなく、
対象範囲を分け、再利用できるモデルとデータを増やし、後から高額になりやすい作業を早期に検証することが有効です。
過去契約・商品数・計算量が価格を押し上げる
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最も大きな変動要因の一つは、現在販売している商品だけでなく、過去に販売した商品と契約をどこまで扱うかです。
過去の基礎率、制度、約款、料率改定、契約状態を復元できなければ、新システムで同じ契約を計算できません。
対象期間を直近10年に限定するのか、契約満了まで過去世代を保持するのかで、モデル数、テストケース、データ移行費が変わります。次に、計算量と連携数が影響します。
月次・年次の決算バッチだけなら実行時間を確保しやすい一方、販売画面からリアルタイムに保険料を計算し。さらに大量契約の確率論的シナリオを並行して実行する場合は、別の性能設計が必要です。
契約管理、再保険、資産運用、会計、DWH、BIなどの接続先ごとに、データマッピング、認証、エラー処理、再送、監査ログが必要になるため。APIの本数だけでなく連携の複雑さを見積もります。
段階導入と標準機能の活用で投資を分ける
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
コスト最適化では、最初から全商品を対象にせず、新商品の計算や特定の商品群の準備金計算など、業務上の効果と検証可能性が高い範囲から始めます。
PoCで差分説明と処理性能を確認し、MVPで実運用に必要な監査・権限・帳票を整え、その後に対象商品や会計連携を広げる方式です。
段階ごとに投資対効果と残存リスクを確認できるため、計画変更もしやすくなります。
パッケージやクラウドを選ぶ場合は、標準の数理ライブラリ、モデル管理、ジョブ管理、監査証跡、APIをどこまで使えるかを確認します。
FISのInsurance Risk Suite – Prophetは、生命保険向けに決定論的・確率論的シナリオ、ALM、規制報告、監査証跡。
クラウドまたはオンプレミスの実行環境を提供すると説明しています。
出典: FIS Global「Insurance Risk Suite – Prophet」、2026年閲覧。
標準機能を活用できれば開発工数を減らせますが、日本固有の商品、帳票、社内承認、過去データの変換が別費用になる点は必ず確認します。
セキュリティと統制を後付けしない
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
セキュリティや監査を後から追加すると、データ構造、権限、ログ、運用手順の作り直しが発生します。
特権IDの多要素認証、最小権限、開発・検証・本番の分離、モデルと前提の二者承認、変更履歴、通信・保存データの暗号化、バックアップ、復旧訓練。委託先と再委託先の管理を要件定義に含めます。
FISCが2026年3月に公表した「金融機関等のシステムリスク管理の解説書」は、従来の入門書を刷新し、サイバーセキュリティ、クラウド利用。
リスクベースアプローチを扱っています。
出典: 公益財団法人金融情報システムセンター「金融機関等のシステムリスク管理の解説書」、2026年。
FISCの資料は法律そのものではありませんが、自社のリスク評価、社内規程、監督上の要請、個人情報保護、委託先契約と照合しながら。必要な対策を見積もりへ落とし込むための参考になります。
見積もりを取る際のポイント
相見積もりを成功させるには、金額を聞く前に各社が同じ条件で見積もれる資料を用意します。
特に保険数理システムは、要件の一部が「現行担当者にしか分からない」状態になりやすいため、
対象範囲と不確実な点を分けて提示することが重要です。
RFPに対象範囲と検証条件を書く
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
RFPには、対象商品と商品世代、契約件数と増加見込み、計算頻度、処理時間、確率論的シナリオの有無、過去契約の保存年数、既存プログラムの種類。
データ形式、連携先、帳票、権限、監査ログ、RTO・RPO、クラウド可否を記載します。
さらに、代表商品のテストケース、現行結果のサンプル、許容する差分の考え方、差分が出たときの説明責任を明記します。
見積書の形式は、要件定義、モデル解析、モデル移植、アプリ開発、データ移行、環境構築、ライセンス、テスト、並行計算、教育、保守に分けてもらいます。
各項目に、前提となる人月、期間、対象商品、除外事項、追加費用の条件を付けてもらうと、安い見積もりが単に作業範囲を削っているだけなのかを判断できます。
開発会社・製品・契約方式を同じ軸で比較する
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
開発会社を選ぶときは、生命保険の数理計算、現行ロジックの解析、モデル検証、移行、運用保守の実績を確認します。
国内SIでは、シーエーシーが生命保険・損害保険の業務システムについて要件整理から設計・開発・保守・運用まで支援し。
生命保険分野で数理計算を含む実績を公表しています。
出典: 株式会社シーエーシー「金融業向けサービス：保険」、2026年閲覧。
コンピューターマネージメントも、個人保険の保険料、解約返戻金、責任準備金。
数理統計帳票を扱う開発・保守事例を公開しています。
出典: コンピューターマネージメント株式会社「個人保険システムの開発/保守（数理）」、2026年閲覧。
数理プラットフォームを比較する場合は、国内制度への適合性だけでなく、モデルの透明性、前提の版管理、API、監査証跡、計算性能、クラウドのデータ所在。
料金体系、契約終了時のモデルとデータ返却を確認します。
ソフトウェア提供会社と国内実装SIerを分けて調達する場合は、障害時の一次窓口、バージョンアップの責任、数式の妥当性確認。データ移行の責任分界を契約書へ落とし込みます。
安すぎる見積もりと追加費用のリスクを確認する
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
初期見積もりが極端に安い場合は、過去契約の移行、例外契約の検証、並行計算、性能試験、監査ログ、夜間障害対応が除外されていないかを確認します。
「標準機能で対応可能」という説明でも、日本固有の商品条件や既存帳票を追加すると個別開発へ変わることがあります。
デモでは正常系だけでなく、計算差分の調査画面、前提変更の承認、失敗ジョブの再実行、監査ログの検索を見せてもらうと、実運用とのギャップを把握しやすくなります。
契約方式は、要件が不確かな現行調査やPoCでは準委任、成果物と受入条件を明確にできるモデル移植や機能開発では請負を組み合わせる方法があります。
どちらを採る場合も、仕様変更の扱い、差分原因の調査回数、データ品質が想定を超えたときの追加費用、遅延時の責任、切戻し費用を先に決めます。
保険数理では、業務側の判断が後から変わることもあるため、変更を隠すのではなく、変更管理の手続きを見積もりへ含めることが安全です。
よくある質問
ここでは、保険数理システムの費用や発注について、担当者からよく寄せられる質問に回答します。
自社の条件に当てはめる際は、対象スコープ、過去契約、計算量、検証条件を一つずつ確認してください。
保険数理システムの開発費用はいくらですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
計算エンジンのPoCなら300万円〜1,000万円、1商品群向けのMVPなら1,500万円〜5,000万円。
複数商品へのパッケージ導入なら3,000万円〜1億5,000万円、大規模な基幹刷新なら1億円〜5億円超が初期予算の目安です。
公開された一般的な開発費用や類似案件をもとにした推定であり、成約価格ではありません。商品数、契約件数、過去データ、連携先、検算期間をそろえて見積もる必要があります。
パッケージとスクラッチ開発はどちらが向いていますか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
標準的な数理計算、モデル管理、ジョブ管理、監査機能を早く利用したい場合はパッケージが向いています。
国内固有の商品、社内の計算慣行、複雑な過去契約、独自の連携や帳票を長期的に柔軟に変えたい場合は、スクラッチやハイブリッド構成が候補になります。
初期価格だけでなく、商品改定の速度、モデルの説明可能性、保守人材、ライセンスとクラウドの継続費を含む総保有コストで比較してください。
保険数理システムはクラウド化できますか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
クラウド化は可能ですが、データ所在、委託先管理、接続制御、暗号化、バックアップ、障害時の復旧、従量課金の上限を先に決める必要があります。
決算時だけ計算量が増える場合は、必要なときに計算資源を拡張できる利点があります。
一方、個人情報やモデル資産をどの環境へ置くか、社内規程や監督上の要請に適合するかを確認し、段階的にクラウドへ移行する方法も有効です。
発注前に最初に何を準備すればよいですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
まず、計算エンジン単体の更改か、契約管理・会計・DWHを含む基幹刷新かを決めます。
そのうえで、対象商品・商品世代・契約件数・計算頻度・既存プログラム・連携先・過去契約の保存年数・RTO・RPO・代表的なテストケースを一覧化します。
現行と新システムの結果を比較できるサンプルを用意し、PoCで差分原因と性能を確認してから本開発の見積もりを取ると、金額の精度を上げやすくなります。
まとめ
保険数理システムの費用相場は、PoCで300万円〜1,000万円、1商品群向けMVPで1,500万円〜5,000万円、
複数商品へのパッケージ導入で3,000万円〜1億5,000万円、大規模な基幹刷新で1億円〜5億円超が初期予算の目安です。
ただし、数理システム単体の公開価格は限られるため、相場は対象範囲と前提をそろえて使う必要があります。
予算化で押さえるべきポイント
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
予算化では、計算エンジンと契約管理システムの役割を分け、現行ロジックと過去契約を棚卸しし、代表商品でPoCを実施します。
見積書は、モデル移植、データ移行、並行検算、性能試験、監査・セキュリティ、ライセンス、クラウド従量費、保守費を分けて比較してください。
安い初期費用だけで決めず、商品改定時の変更速度、差分を説明できる透明性、障害時の復旧、契約終了時のデータとモデルの返却まで確認することが重要です。
次に行うべきこと
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初のアクションは、対象範囲を「現行調査」「PoC」「MVP」「本番移行」に分け、商品数、契約件数、計算頻度、連携数、過去契約年数。求める復旧水準を1枚に整理することです。
その資料をもとに、数理業務とシステム開発の両方に実績のある会社へ相談し、同じテストケースで複数社の提案と見積もりを比較します。
保険数理システムは、安く作ることより、将来の計算結果を再現でき、変更を安全に説明できることが事業価値につながります。▼全体ガイドの記事
・保険数理システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。