保険金支払システムは、請求の受付から書類の確認、査定、承認、送金、監査までをつなぐ業務基盤です。支払の正確さと処理速度を両立させることを目指します。
導入方式や開発手順、費用、発注の詳細は、下の関連記事もご覧ください。
▼関連記事一覧
・保険金支払システム開発の進め方
・保険金支払システム開発でおすすめの開発会社6選と選び方
・保険金支払システム開発の見積相場・費用
・保険金支払システム開発の発注・外注・委託方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
保険金支払システムの全体像
保険金支払システムは、単独の申請画面ではなく、複数の業務とデータを結ぶ基幹業務の仕組みです。具体的には、契約者が入力した請求情報や診断書・領収書などの書類に加えて、契約内容、査定ルール、送金先情報も、一つの案件として追跡できる状態をつくります。
管理する情報の範囲
案件情報、処理履歴、契約条件を、一つの案件にまとめて管理します。
- 案件情報：受付日時、契約者・受取人、契約番号、請求内容、提出書類、担当者の記録。
- 処理履歴：査定結果、支払額、支払日、通知履歴、監査ログを、案件に紐付けて残します。
- 契約条件：死亡保険金、入院・手術・通院給付金、障害・介護給付金、満期保険金の条件を、商品・特約ごとに照合する仕組みです。
主要な機能の分類
機能は、請求受付から書類管理、契約照合、査定、承認、送金、監査までの流れに沿って分けて考えます。
- 受付・書類：Web、スマートフォン、代理店、電話、紙の各経路での請求受付。
- 照合・査定：本人確認、AI-OCR、医療用語のコード化、契約照合、支払判定の各工程。
- 承認・送金：担当者割当、簡易事案の処理、上長承認、差戻し、追加書類の依頼、送金指示。
- 通知・監査：顧客への進捗通知と、判断者・参照情報・適用ルールの監査ログへの記録。
書類は画像やPDFで管理し、不足があれば追加提出を依頼します。また、機能一覧は画面単位で作るより業務の流れに沿って整理したほうが、抜けに気づきやすくなります。
保険金支払システムの種類と構成
方式は、既存資産を残す範囲、独自商品を再現する範囲、変更を続ける期間を基準に選びます。初期費用だけで決めると、約款改定や商品追加のたびにかかる改修の負担を見落としやすくなります。
保険業務パッケージの利用
パッケージでは、標準機能をそのまま使う部分と、個別開発を加える部分で、影響の出方が変わります。
- 標準機能：契約・請求・査定・支払の共通機能を設定して使うため、ゼロから作るより品質管理や保守体制を整えやすい傾向があります。
- 個別開発：日本固有の約款や複雑な特約を再現し続けるとアドオンが増え、バージョンアップや障害調査が難しくなる場合があります。
採用前に、標準機能と設定変更、追加開発、外部サービスの境界を確かめます。デモでは、発注側が代表的な請求事案と例外事案を持ち込み、支払計算、差戻し、ルール改定、監査ログを実演してもらいます。
クラウド・SaaSの組み合わせ
クラウド・SaaSを組み合わせる場合は、導入のしやすさに加えて、利用条件と情報管理の条件を確認します。
- 段階導入：請求受付、文書管理、AI-OCR、ワークフロー、分析基盤を導入できます。
- 運用と費用：繁忙期の拡張、監視、バックアップ、機能更新を利用しやすい一方、利用料は請求件数や保存容量で変わる場合があります。
- 情報管理：保管場所、暗号化、暗号鍵、再委託先を決めます。障害復旧、ログ保持期間、終了時のデータ返却も、契約と設計の両面で定めます。
事業者の説明に加えて、自社の委託先管理や監査手続きに合うかも確かめます。
スクラッチとハイブリッドの使い分け
独自性をどこまで残すかを決め、方式を選ぶ前に整理しておく条件も確認します。
- 個別開発：独自商品や特殊な査定ロジックが競争力に直結する領域に適します。
- ハイブリッド：支払判断は個別開発し、標準化できる周辺機能はパッケージやクラウドを使う方法があります。
- 事前整理：商品数、特約数、月間請求件数、連携先を一覧にします。過去データ量、求める稼働率、約款改定頻度も、あわせて整理します。
認証や文書保管、通知、監視まで自作すると、初期費用と運用負担が膨らみます。加えて、条件が曖昧なままだと費用や納期も見えにくくなります。
保険金支払システム開発の進め方
開発は、現行業務の洗い出しと対象範囲の決定から始まり、要件定義、設計・開発、テストを経て、移行と運用改善に進みます。
書類不足や契約失効、複数特約、支払対象外などの例外も、正常系と並べて扱います。特に、重複請求や本人確認の不一致は、早い段階で扱うかどうかが成否を分けます。
現行業務の洗い出しとKPIの設定
業務の現状と判断ルールを整理し、改善目標を決めます。
- 業務とKPI：受付から監査までの担当部署・システムを洗い出し、月間請求件数、平均処理日数、書類不備率、差戻し率、作業時間、支払漏れ・訂正件数を計測します。
- 改善目標：平均処理日数の短縮や、受付から支払完了までの進捗照会率などを数値目標にします。
- 判断ルール：商品・特約・請求パターンと規程・約款・社内マニュアルの根拠を紐付け、熟練者の例外処理もルール台帳に記録します。
現行業務の洗い出しと判断ルールの整理を省くと、画面は完成しても、実際の査定で案件が止まるおそれがあります。
要件定義での自動化の境界
自動化と人による確認の境界を決め、要件書と受入条件に落とし込みます。
- 処理の分担：自動処理、担当者確認、上長承認、専門部署へのエスカレーションの区分。
- AI-OCRと査定：AIを使う業務と、人が確認する業務の境界。
- 要件と受入条件：必要な機能、運用条件、例外対応を要件書に記載します。
たとえば、AI-OCRは書類分類や項目抽出に使います。ただし、信頼度が低い場合は、原画像と抽出値を並べ、人が確認できる画面にします。
支払可否や支払額をAIだけで確定させる場合は、説明可能性、再現性、誤判定時の責任を定義します。加えて、手動停止の手順も別途定めます。
要件書には、入力項目、判定ルール、権限、承認経路を盛り込みます。通知、帳票、外部連携、ログも、同じ要件書で定めます。障害に備えて、バックアップや手動切替、RTO・RPO、監査条件も明記します。
発注側は、書類未着や同一人物の複数請求、支払済み案件の訂正のような場面も、受入条件まで具体化しておきます。
設計・開発・テストの段階的な進め方
設計とテストでは、変更に対応できるかどうかと、支払判断が一致しているかを確かめます。
- 設計：保険金支払業務のデータ構造とシステム連携を決めます。
- 並行テスト：単体テストに加えて、匿名化した過去案件で、旧新の支払対象、金額、不支払理由、通知を照合します。
- 受入確認：AIの要確認率や抽出誤りを確認します。あわせて、性能、障害復旧、権限逸脱、ログ改ざん耐性、災害時の切替も確かめます。
基本設計では、案件データ、API、認証、権限を決めます。さらに、文書保管やルールエンジン、ワークフロー、会計・決済連携の扱いも定めます。
約款改定や商品追加を、プログラムの改修だけに頼らず進められる構造かを確認します。そのうえで、担当者が変更履歴を残してルールを更新できれば、稼働後の改修負担を抑えられます。
移行と稼働後の運用設計
移行範囲と照合方法を決めたうえで、稼働後の確認項目も運用に組み込みます。
- 移行対象と検査：契約番号、請求・支払履歴、書類、監査ログの範囲を決めます。欠損、重複、文字コード、旧商品コード、画像紐付けを検査します。
- 切替計画：件数と金額の照合結果を記録し、新旧システムを一定期間並行稼働させ、支払業務を止めずに切り替えます。
- 稼働後の運用：処理時間、不備・差戻し率、支払漏れ、AI要確認率、障害件数の定期確認。
- 運用の見直し：約款・法令変更時のルール更新、モデル精度、委託先、権限を見直します。
稼働後は、業務部門と情報システム部門で改善のバックログ（課題一覧）を共有します。
▶ 詳細はこちら：保険金支払システム開発の進め方
保険金支払システムの費用相場とコストの内訳
価格は、請求件数や商品・特約数、既存システムとの連携によって変わります。データ移行量も影響し、AI-OCRの利用量や可用性、監査要件も費用に関わります。
ここで示すのは、企画段階で使う推定レンジです。公開価格ではないため、見積時には対象業務と品質要件を明示し、金額を再計算してください。
規模別の初期費用と期間の目安
規模ごとに、対象範囲と初期費用、期間を照らし合わせて見ます。
- 限定PoC：帳票1種類のAI-OCR、受付画面、少数商品の検証、小規模API連携を想定します。目安は500万〜2,000万円、2〜6か月です。
- 部分刷新：Web請求、文書管理、OCR、査定ワークフロー、契約・会計連携を含みます。目安は2,000万〜8,000万円、9〜18か月程度です。
- 本格刷新：8,000万〜3億円、18〜36か月程度になる可能性があります。
- 全面再構築：契約管理や会計・決済まで横断し、レガシーを廃止する場合です。3億円を超え、30〜60か月に及ぶ場合があります。
本格刷新には、複数商品や複雑な特約、ルールエンジンを含む場合があります。そのほか、不正・異常検知、複数チャネル、データ移行、冗長化が入ることもあります。
金額は機能数に加えて、テスト件数と移行責任によっても変わります。
費用を左右する項目と工数の考え方
概算は「工数×人月単価」に、利用料や追加作業を加えて考えます。
- 利用料：パッケージ・クラウド利用料、AI-OCRや文書保管の従量料金です。
- 構築作業：外部連携、データ移行、セキュリティ評価、教育を含みます。
- 運用費：保守、監視、クラウド、ライセンスなどが発生します。
専門人材の単価を1人月60万〜120万円と仮置きすると、30人月は1,800万〜3,600万円になります。80人月なら、4,800万〜9,600万円です。
この単価は、2025〜2026年の企画・提案段階で使う編集用の推定であり、市場統計ではありません。実際の単価を保証するものでもありません。
費用配分は、要件定義・基本設計が25〜35％、開発が30〜40％、テストが15〜25％です。データ移行・外部連携は、5〜15％と置くこともできます。
保守改修や監視、クラウド、ライセンスは、初期費用の年15〜25％程度と仮置きします。また、SaaSやOCRの費用は処理件数によって変わります。
発注側は、見積書で初期費用と月額費用、追加利用料、約款改定時の改修費を分けて確認します。
5年TCOによる比較
初期費用に加えて、5年間の支出と業務改善の効果を並べて比べます。
- 総費用：初期費用に60か月分の利用料・保守費、移行費、追加開発、セキュリティ評価、データ返却費を加えます。
- 運用費の変動：請求増加後の従量課金や保管料、連携改修、教育、監査、障害対応を含めると、安価なSaaSの総額が逆転することもあります。
- 改善効果：処理時間や紙書類、担当者工数、支払漏れ、訂正の削減と、商品の追加スピードも評価します。
現行の処理件数や単価に、作業時間と訂正件数を加えて、複数のシナリオで効果を試算します。
▶ 詳細はこちら：保険金支払システム開発の見積相場・費用
保険金支払システムの開発会社・サービスの選び方
選ぶときは、知名度や機能数に加えて、自社の業務と制約に合うかを基準にします。
保険業務パッケージ、総合開発会社、AI-OCR・医療データの専門会社では、得意な領域が異なります。そのため、クラウド基盤や運用を担う会社も含めて、必要な役割ごとに分けて評価します。
生命保険の支払査定実績の確認
実績は、「保険会社向け」という表記よりも、支払業務のどの工程を担当したかで確かめます。
- 請求・査定：受付、書類管理、契約照合、支払額計算、支払対象外の判断を確認します。
- 承認・送金：承認、送金、監査のうち、提案範囲に含まれる工程。
- 導入・保守：規模、商品・特約の類似度、連携先、稼働後の保守責任を確かめます。
実績の詳細は、匿名化された範囲で確認します。デモでは、正常な入院給付金に加えて、複数特約、追加書類、契約失効を提示してもらいます。
そのうえで、短期間の重複請求や支払済み後の訂正も確認の対象です。画面の処理に加えて、データの根拠、ログ、差戻し、手動介入を説明できるかを評価します。
既存システムとの連携と技術適合性
既存連携の安定性と、AIを含む提案の検証・運用方法を確かめます。
- 既存連携：既存システムとの接続方式と運用条件を確認します。
- ファイル連携：古い方式を残す場合、仕様変更の管理と監視方法を要件に含めます。
- AIの検証：平均値だけでなく帳票別精度や誤読検知、信頼度表示、原文照合を確かめます。
AIの検証では、学習データへの再利用、モデル更新時の再テスト、推論ログ、有人確認への切替も見ます。
連携先は、契約管理や顧客管理、会計、決済です。ほかに、本人確認や文書管理も含まれます。APIの有無やリアルタイム・バッチの別を確認し、障害時の再送や二重送金防止も見ます。加えて、不整合検知と接続先変更の責任も確かめます。
AIの結果を支払判断に使う場合でも、責任者が説明できる流れを設計できるかどうかを見ます。
開発体制・品質保証・5年TCOの比較
提案の機能数に加えて、実行体制と長期運用の条件を比べます。
- 担当体制：業務責任者、PM、アーキテクト、セキュリティ、移行、テストの担当を確認します。再委託や担当交代、障害時の連絡、問い合わせ時間も見ます。
- 運用対応：約款改定への対応と、提案時の説明者が実作業を担うかを確かめます。
- 評価項目：業務知識と類似実績、標準・個別開発の区分、連携と移行・テスト、セキュリティと運用、契約、5年TCOを比べます。
発注側は、例外事案への対応、変更費用の透明性、データ返却の条件も見ます。
▶ 詳細はこちら：保険金支払システム開発でおすすめの開発会社6選と選び方
保険金支払システムの発注・外注・委託方法
発注側が業務の判断を整理したうえで、委託先に任せる範囲と自社で決める範囲を分けます。
RFPには、対象業務や請求件数、商品・特約を記載します。現行システムや連携先も示します。そのうえで、必要な性能やセキュリティ、移行、運用の条件、予算と納期を伝えます。
RFPに盛り込む業務と品質の条件
業務と品質の条件を具体化し、役割に応じて提案候補を比べます。
- 業務・品質条件：状態遷移、査定ルール、承認権限、書類保存期間を記載します。通知や外部連携、ログ、バックアップ、障害復旧も入れます。
- 事案と成果：匿名化した代表・例外事案を添え、支払額、不支払理由、承認者、出力帳票を提案に含めてもらいます。
- 候補選定：必要な役割に応じて複数候補を比べます。
候補が多い場合は、実績、体制、概算費用、対応不可範囲を書面で確認してから、詳細提案へ進みます。この手順を踏むと、発注側と候補側の双方の負担を抑えられます。
契約形態と責任分界の明確化
工程ごとに契約形態を選んで、何を納めるのか、誰が責任を持つのか、変更時にどう扱うのかを決めておきます。
- 契約形態：企画・調査は準委任、仕様と納める範囲を合意できる開発は請負、標準機能の継続利用はSaaS契約にします。
- 範囲と責任：一契約ですべてを固定すると変更や検収が曖昧になりやすいため、納める範囲、作業範囲、責任、支払条件を分けます。
- 契約前の確認：変更承認、遅延、障害重大度、復旧目標、損害対応を確かめます。再委託、秘密保持、個人データ、監査協力、終了時のデータ返却も見ます。
支払額や不支払理由の誤りは影響が大きいため、検収後の対応と緊急連絡体制を具体化します。
発注後の業務部門の主導権
判断基準は業務部門が管理し、受入条件も実際の案件をもとに決めます。
- 責任者とルール：業務、情報システム、法務・コンプライアンス、セキュリティ、経理・決済の責任者を参加させます。そのうえで、承認者と変更管理者を決めます。
- 定例管理：未決定ルール、テスト不合格、移行エラー、セキュリティ課題、追加費用、変更要求を確認します。
- 受入テスト：匿名化した実案件を業務担当者がテストし、支払額と判断根拠を説明できる状態を合格条件にします。
判断基準を開発会社だけに任せると、現場の暗黙知や例外が仕様から抜けてしまいます。
▶ 詳細はこちら：保険金支払システム開発の発注・外注・委託方法
セキュリティと2026年時点の最新動向
保険金支払システムは、病歴や診断書、口座情報などの要配慮個人情報を扱います。そのため、安全対策も機能要件と同じ重さで設計します。
FISC第13版は、2025年3月に公表されました（出典: 金融情報システムセンター「安全対策基準・解説書（第13版）」、2025年）。同版には、サイバーセキュリティ、オペレーショナル・レジリエンス、AI・生成AIの安全対策が反映されています。保険会社のRFPでは、こうした基準を自社の管理策に落とし込んで示します。
個人情報と委託先の管理
個人情報保護法のガイドラインを踏まえて、情報の扱いと委託先の管理を定めます。
- 利用・保存管理：利用目的、アクセス権限、閲覧・ダウンロード・印刷の制御、通信・保存の暗号化を決めます。操作ログ、保存期間、削除、バックアップ、再委託も定めます。
- 外部処理：AI・OCRの入力データが学習利用されるか、国外移転されるか、障害時にどの環境へ復旧するかを確認します。
- 権限と監査：部署・案件状態・商品・地域ごとに権限を分けます。
退職・異動時にはアカウントを停止し、特権IDの利用を記録します。定期的な権限の見直しを自動化することも検討します。
監査ログは、改ざんを防ぎながら、判断根拠と関連書類を追跡できる期間にわたって残します。
AI・即日支払・クラウド化の段階的な導入
公表事例を参考に、効果とリスクを測りながら適用範囲を広げます。
- 生成AIと査定：生成AIとルールエンジンを組み合わせた給付金査定の共同事例が公表されました。
- AI-OCRと即日着金：AI-OCRの利用開始と、即日着金を支援する連携事例。
- 導入手順：検証を経て、自動処理へ段階的に広げる進め方。
ある事例では、年間約50万件の査定で、担当者の業務時間を従来比4割程度削減する計画です（出典: 生命保険会社・IT企業の共同発表、2026年5月）。この数値は個別事例の目標であり、各社に同じ効果が出るとは限りません。
2026年には、診療明細書を分類・抽出し、医療コード化するAI-OCRの利用が始まりました。生命保険の給付金支払業務での事例です（出典: 保険給付金支払業務プラットフォームの導入発表、2026年2月）。
また、2025年12月には、保険基幹のクラウド化と決済連携で即日着金を支援する事例が公表されました。受付から査定、送金、運用をつなぐ事例です（出典: 保険基幹システム・決済連携に関する発表、2025年12月）。
導入は書類分類や項目抽出など、効果とリスクを測りやすい領域から始めます。次に類似事案検索、根拠提示、ルール判定支援へ広げ、十分に検証してから自動処理を拡大します。受入条件には、説明可能性、誤りの検知、有人対応、モデル更新時の再テストを含めます。
自社の帳票品質、ルールの標準化、要確認率を先に測る必要があります。これらの事例は、受付だけでなく査定、送金、運用までをつなぐ方向性を示しています。
保険金支払システムのよくある質問（FAQ）
企画やベンダー選定でよく出る疑問に回答します。
費用や自動化の可否は、会社ごとの条件によって変わります。そのため、ここでの回答をそのまま使わず、自社の請求件数や商品、既存システム、求める品質に置き換えて検討してください。
保険金支払システムの開発費用はいくらですか？
企画段階の推定レンジは、刷新する範囲によって異なります。
- 限定PoC：500万〜2,000万円です。
- 部分刷新：2,000万〜8,000万円です。
- 本格刷新：8,000万〜3億円です。
- 全面再構築：契約管理や会計・決済まで含める場合、3億円を超える可能性があります。
請求件数や商品・特約、連携本数、移行量、テスト範囲を提示したうえで、初期費用に加えて5年TCOで比べます。
AIで保険金の支払査定を完全自動化できますか？
完全自動化を目指すより、まずは書類分類や項目抽出、医療用語の標準化から段階的に導入します。類似事案検索や担当者への根拠提示も、導入候補になります。
信頼度が低い事案や例外事案は人が確認し、判断根拠、入力データ、モデル版、承認履歴を記録します。
既存の契約管理システムを残して開発できますか？
既存システムを残し、一部機能から追加する構成が可能です。
- 追加機能：請求受付、書類管理、AI-OCR、査定ワークフローを追加できます。
- 既存資産：契約照合や支払履歴を既存システムに残すハイブリッド構成も考えられます。
- 移行計画：二重管理、API・ファイル連携の障害、再送、データ不整合、旧システムの保守期限を要件に含め、段階移行のロードマップを作ります。
開発会社を選ぶときに最も重視すべき点は何ですか？
生命保険の支払査定への理解と、連携・移行・テストを一体で担えるかを重視します。加えて、例外事案や標準・設定・個別開発の区分、AIの有人確認、5年TCOも比較します。
稼働後は、約款改定への対応とデータ返却の条件も確認します。
セキュリティ要件はどこまで必要ですか？
要配慮個人情報を扱うため、認証や権限、暗号化、操作ログ、保存期間を定めます。加えて、バックアップや監視、脆弱性対策、障害復旧、委託先管理も、同時に定義します。
FISC第13版や個人情報保護委員会のガイドラインを参照し、自社のリスク評価、監査、契約、業務継続計画に合わせます。
まとめ
保険金支払システムは、請求の受付から監査までを、書類や契約、約款と結ぶ業務基盤です。
成否は、AIやクラウドを採用するかどうかよりも、現行業務と例外を洗い出し、判断根拠と責任を設計できるかで決まります。
自社に合う規模の判断
対象範囲に応じて刷新の規模を選び、推定費用と変動要因を照らし合わせます。
- PoC：書類分類や請求受付だけを検証し、初期費用は500万〜2,000万円が目安です。
- 部分刷新：請求・文書・査定・連携を刷新し、2,000万〜8,000万円が目安です。
- 本格刷新：複数商品と基幹・決済まで変え、8,000万〜3億円が推定の目安です。
金額は、請求件数や商品数、テスト、移行、セキュリティによって変動します。
最初に作る資料
RFPの前に、業務・システム・費用の判断材料を揃えます。
- 業務資料：受付から送金までの業務フロー、商品・特約と査定ルールの台帳を作ります。
- 現状と試算：現行システム・連携先、請求件数とKPI、匿名化した代表・例外事案、5年TCOの試算表を用意します。
- 提案評価：RFPで実績、体制、AI、セキュリティ、契約条件を評価します。
候補は機能数より、支払判断の正確性、処理時間、監査可能性、変更への強さ、運用継続性で評価します。
段階導入と有人確認を前提にすると、既存資産を活かしながら業務を改善しやすくなります。
▼関連記事一覧
・保険金支払システム開発の進め方
・保険金支払システム開発でおすすめの開発会社6選と選び方
・保険金支払システム開発の見積相場・費用
・保険金支払システム開発の発注・外注・委託方法
▼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を創業。