保険の満期や更新を迎える契約について、対応の漏れを防ぎながら、更新後まで記録を残していく仕組みが契約更改システムです。
導入方式や必要な機能は、保険種類、更新業務の範囲、既存システムとの連携によって変わります。
▼関連記事一覧
・契約更改システム開発の進め方
・契約更改システム開発でおすすめの開発会社6選と選び方
・契約更改システム開発の見積相場・費用
・契約更改システム開発の発注・外注・委託方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
契約更改システムの概要
契約更改システムは、更新対象の抽出から案内、意向確認、見直し提案、申込、承認、更新後の保全までを管理する業務基盤です。
満期日や更新日の一覧にとどまらず、契約者と被保険者、商品を契約単位で結びつけます。保険期間と保険料、特約も同じ契約に紐づけます。
担当者も同じ契約に結びつけます。さらに、対応履歴や書類、承認状況を同じ契約に集め、更新後の保全情報も残します。そのため、担当者が変わっても業務を続けやすくなります。
更新漏れを防ぐ業務基盤
更新漏れを防ぐには、対象契約を抽出したうえで、期限に応じた顧客案内と案件管理を連動させる必要があります。案件は次のとおり、段階ごとに分けて管理します。
- 抽出対象：契約期間終了、更新型商品、保障見直し、保険料変更など
- 期限タスク：90日前、60日前、30日前などに発行
- 対応中：未接触、案内済み、面談予定、意向確認中、見直し提案中
- 手続き中・完了：申込済み、承認待ち、更新完了
- 終了・保留：保留、解約、失効
時期に応じて顧客へ案内できるので、担当者の記憶や紙のリストに頼らなくても対応を進められます。
画面を増やすためではなく、対応漏れと証跡不足を減らすために、期限超過案件を管理者が把握できるようにします。
生命保険の更新と損害保険の満期更改の違い
生命保険と損害保険では、更改・更新時に確認する内容が異なります。
- 損害保険：満期契約の補償内容や保険料を確認し、継続手続きを進めることが多い
- 生命保険：年齢による保険料、更新型商品の保障、告知、特約継続、販売停止商品の切替を検討
生命保険では、継続するかどうかだけでなく、保障額や許容できる保険料、健康状態の変化を記録する設計が必要です。
顧客の意向と提案内容が合っているかも残せるようにします。
金融庁の監督指針は、顧客の意向を把握し、契約内容との対応や顧客対応の記録を適切に管理する考え方を示しています（出典：金融庁「保険会社向けの総合的な監督指針」、2026年確認）。
契約更改システムの主な機能と導入効果
導入効果は、どの工程の時間とリスクを減らすかで評価します。その際は、現場の入力負担、管理者の確認工数、監査時の証跡確認工数を分けて測ります。
契約・顧客・担当者をまとめて管理する機能
この機能では、契約を単位に顧客と担当者の情報をそろえて扱います。管理する内容は次の5点です。
- 基本情報：契約者と被保険者、商品、保険期間を契約ごとにまとめ、更新日、保険料、特約も同じ契約に紐づける
- 担当・拠点：担当者と所属拠点も合わせて管理する
- 家族・世帯単位：家族や世帯単位で契約を確認できるため、複数の契約をもつ顧客の保障全体を見ながら、更新や見直しを検討できる
- 名寄せ：保険会社や既存システムごとに異なる項目名や日付形式をそろえ、契約状態や顧客名の表記も統一する
- 重複の判定：契約の重複は二重案内や対応漏れにつながるため、契約を識別するキーと判定ルールを要件定義の段階で決めておく
更新対象の抽出・タスク・アラート機能
更新日を基準に対象を抽出し、担当者や拠点、商品ごとに、優先度や残り日数を並べて一覧にします。
- 期限設定：更新日から90日前に初回案内、60日前に再案内、30日前に管理者確認
- 担当変更：休職や異動時に未処理案件を再割り当て
- 優先通知：重要度、期限、意向、契約金額、失効リスクで並べ、未接触や不備など次の行動を示す
アラートは件数を増やすことより、今日対応すべき案件が上に出ることを重視します。未接触や書類不備など、次に取る行動も併せて表示します。
2026年2月の保険代理店向けCRMの業界発表では、損害保険の満期更改を自動化する機能が正式に提供されました。月次リストを起点とした手作業から、優先順位付けと自動通知を組み合わせる流れが示されています（出典：保険代理店向けCRMの満期更改自動化に関する2026年2月の発表、2026年）。
損害保険向けの動向ですが、生命保険でも対象抽出から対応完了までをワークフローとして設計する重要性が高まっています。
意向確認・書類・証跡・分析機能
意向確認や手続きの記録は契約に結びつけて保存し、案件単位で追えるようにします。
- 保存する記録：面談、意向、保障額、保険料、比較商品、推奨理由、申込書、同意、承認履歴、差し戻し理由
- 確認する指標：更新率、対象抽出から初回接触までの時間、未接触・保留・意向未完了件数、書類不備率、担当者別滞留、商品別失効率
案件単位で記録が残っていれば、担当変更後の経緯を確認でき、監査や顧客からの問い合わせにも答えやすくなります。
指標を月次で比べ、アラートや入力項目の効果を検証すると、導入効果を継続して確かめられます。
契約更改システムの種類と方式の選び方
方式は、専用SaaS、パッケージや汎用CRMの拡張、スクラッチ開発の3つに大別できます。
初期費用だけでなく、保険会社との連携、データ移行、法改正や商品改廃への対応まで含めて判断します。
5年間の運用費や契約終了時のデータ返却も見ておきます。
専用SaaSを選ぶ場合
契約管理と満期・更新管理に加え、顧客管理と書類保存も標準機能として備わっている場合、専用SaaSは短期間で導入しやすい方式です。そのため、利用を早く始められ、サーバー運用や定期アップデートの負担も抑えられます。
生命保険の場合、保険料の再計算や告知、特約変更が標準機能に含まれるとは限りません。さらに、販売停止商品への対応、電子署名、保険会社ごとのデータ連携も、標準機能で足りるかを確かめる必要があります。
まず確認するのは、標準機能と追加設定の境界です。そのうえで、月額料金内のユーザー数やデータ量、解約時のデータ形式、障害時の復旧目標も見ておきます。
パッケージや汎用CRMを拡張する場合
既存の業務資産や連携先によって、パッケージと汎用基盤のどちらが適しているかを比べます。
- 業界向けパッケージ：保険業務の項目、帳票、権限、対応履歴を取り込みやすい
- 汎用CRM・ローコード：顧客、案件、タスク、通知を柔軟に設計し、既存管理と統合しやすい
保険特有の意向把握や比較推奨は、追加の設計が必要です。
契約状態や更新時の保険料、健康状態の告知、監査証跡についても、設計の段階で扱いを決めておく必要があります。
画面を作れることと、業務ルールを安全に運用できることは別です。
デモでは通常ケースに加えて、保留や差し戻し、担当者変更を確かめます。さらに、契約重複や商品改廃も同じデモで見ておきます。
スクラッチ開発を選ぶ場合
独自要件や連携規模が競争力に直結する場合は、スクラッチ開発が候補になります。
- 候補となる条件：複数社、独自商品、多拠点、深い基幹連携、大量契約、高可用性が求められる
- 段階導入：契約取込、対象抽出、タスク、履歴、権限、ログから稼働
- 後続機能：保険料計算、高度分析、手数料、他業務連携を第二段階で追加
状態遷移や承認フローは自社に合わせて作れる一方、制度改定や脆弱性対応、運用保守、担当者交代への備えと将来の機能追加を、自社の責任で続けることになります。
すべての機能を一度に作ると、費用と期間が大きく膨らみかねません。そのため、段階ごとに投資効果を検証します。
契約更改システム開発の進め方
開発は、現在の更改業務を一覧にすることから始めます。
そのうえで、対象契約の受領から更新完了までの条件を、業務の流れに沿って明らかにします。さらに、現場の業務と管理者の確認を状態遷移として整理すると、必要な機能と不要な機能を区別できます。
現状把握と要件定義
要件定義の前に、現行業務で使っている情報源、件数、必要なルールを洗い出します。
- 資料：契約台帳、更新リスト、顧客情報、CSV・API、案内、メール、面談・申込・承認記録
- 規模：対象・月間更新件数、保険会社・商品・拠点・ユーザー数、担当変更頻度
- 業務要件：抽出、通知、状態、例外、権限、保存、連携、帳票、監査ログ、KPI
- 生命保険要件：更新前後の保険料、加入年齢、告知、保障額、特約、商品改廃、意向、提案理由
件数が分からないと、移行や性能の前提が各社でばらばらになり、見積を比べにくくなります。
金融庁の監督指針に照らして、意向確認書面や説明記録を誰がいつ保存するかも決めておきます。
MVPの決定と連携設計
初期リリースでは、更新業務に必要な最小限の機能を、MVP（Minimum Viable Product）として決めます。
- 初期機能：契約取込、対象抽出、アラート、対応履歴、状態管理、権限、監査ログ
- 連携方式：API、SFTP・CSV、共同ゲートウェイ、既存基幹DBを比較
- 異常系：重複取込、欠損、文字化け、日付ずれ、状態不一致、再送、遅延、復旧を定義
更新率や未対応件数を一覧にして、現場の入力時間が許容範囲に収まるかを確かめます。
電子署名や保険料再計算、顧客ポータル、手数料計算などは、確認の結果を見て後から追加します。
契約データの取込時と更新結果の返却時にログを残しておくと、トラブルが起きた際に原因を調べる手がかりになります。
テスト・移行・パイロット展開
テスト、移行、段階展開を順に行い、通常時と例外時の業務を確かめます。
- 業務テスト：対象抽出、期限後通知、担当者不在、保留・失効、申込不備、差し戻し、二重送信、権限外閲覧
- データ確認：匿名化データで名寄せ・欠損を調べ、期待状態と表示をテストケース化
- 移行範囲：状態、履歴、保険料、特約、担当者、書類を決め、全件が難しければ現行契約と直近記録を優先
- パイロット：1拠点や1商品群で並行稼働し、抽出精度、入力時間、未対応件数の確認
全件の移行が難しい場合は、過去資料を参照する方法を別に設計しておきます。
パイロットで問題がないことを確かめてから、全社へ展開します。
▶ 詳細はこちら：契約更改システム開発の進め方
契約更改システムの費用相場とコストの内訳
契約更改システム単体の公的な市場統計は確認できていません。そのため、2026年時点で公開されている保険代理店向け管理システムや一般的な業務システムの価格情報をもとにした目安を示します。
金額は、対象契約数やユーザー数、保険会社数、商品数といった規模の条件で変わります。さらに、連携本数やデータ品質、セキュリティ要件も金額を左右します。したがって、この金額を予算の確定値としてそのまま扱わないことが大切です。
方式別の費用相場
公開情報から整理した方式別の参考レンジは、次のとおりです。複数社の受注統計ではありません。
- 専用SaaS標準導入：初期費用は数十万円〜500万円程度、月額は2万円〜10万円程度
- 契約・更新管理のカスタム開発：300万円〜600万円程度
- CRM・意向把握・承認・監査を追加：500万円〜1,200万円程度
- 複数拠点・複数社などを統合：1,000万円〜3,000万円程度となる場合がある
- 基幹連携などを含む大規模開発：3,000万円〜1億円超の可能性がある
大規模開発の金額は、公開目安をもとにした推定です。想定しているのは、保険会社の基幹連携や商品計算を含む場合と、大量データや高可用性、厳格な監査が求められる場合です。
費用に含める項目
見積では、開発時の費用と稼働後の費用を分けて項目を確認します。
- 開発・導入：企画、要件定義、業務設計、画面、ワークフロー、API・ファイル連携、移行・名寄せ
- 品質・展開：通知、帳票、権限、監査ログ、テスト、診断、教育、リリース支援
- 運用：クラウド・ライセンス、保守、問い合わせ、脆弱性対応、バックアップ、監視、改廃、法改正、追加開発、データ返却
SaaSの場合は、初期設定とデータ取込が別料金かどうかを確認します。そのうえで、追加ユーザーや容量、API、個別帳票の費用も見ておきます。さらに、操作研修が別料金かも確かめます。
初期費用が安くても、年ごとの追加改修や利用料が大きくなる場合があります。そこで、5年間の利用料と社内の運用工数を加えたTCO（総所有コスト）で比べます。
見積を比較するための前提
相見積もりでは、各社に同じ前提と、判定できる形の要件を渡します。
- 共通条件：契約・月間更新件数、ユーザー・拠点・保険会社・商品数、データ形式、連携、保存期間、稼働時間、SLA
- 要件例：「更新日の90日前に通知し、未接触のまま14日経過した案件を管理者へ通知する」などと具体化
- 見積範囲：初期導入と保守・追加改修を分け、一式なら工数、単価、前提、除外、追加時単価、納期影響を確認
見積は、安さだけでなく、どの条件で金額が変わるかを説明できるかで比べます。
▶ 詳細はこちら：契約更改システム開発の見積相場・費用
契約更改システムの開発会社・サービスの選び方
開発会社やサービスは、価格や知名度だけでなく、生命保険の更新業務と既存データ・保険会社システムとの連携力で比べます。企業名で選ぶ前に、要件への対応力を同じ質問で確かめると、発注後の認識のずれを抑えられます。
生命保険の更新・保全の実績確認
保険代理店向けか保険会社向けかという区分だけでなく、業務への理解と稼働後の運用力を、質問やデモで確かめます。
- 業務経験：更新型商品、医療保険、特約、再計算、告知、意向確認、申込、承認、保全
- 導入実績：契約・ユーザー数、移行方法、連携本数、障害対応、制度改定への対応期間
- デモ案件：担当異動、複数契約、販売停止商品、意向未完了、申込差し戻し
業務担当者が次の行動を迷わず理解できるかも確認します。
連携・移行・データ品質の評価
連携方式ごとの処理と、移行時のデータ品質を確かめます。
- 共通処理：名寄せ、更新、訂正、削除、再送、エラー通知の確認
- API：取得項目・時期、最新情報との遅延（何分・何時間か）、障害時の再実行の確認
- CSV：到着確認、暗号化、重複取込防止、取込結果照合
- 移行：クレンジング担当、欠損・重複、履歴・書類の範囲を決め、匿名化データでリハーサル
件数や顧客、契約状態の突合結果を受入条件にします。さらに、更新日、担当者、書類も突き合わせて確かめます。
セキュリティと保守体制の評価
選定の段階で、安全対策、役割別の権限、委託先を含む運用管理を確認します。
- 技術対策：認証、MFA、最小権限、職務分掌、暗号化、監査ログ、バックアップ、脆弱性・障害対応、RTO・RPO
- 役割別権限：全件閲覧を避け、募集人・事務・拠点長・コンプライアンス担当で閲覧・編集・承認を分ける
金融庁は2025年7月、「金融分野におけるサイバーセキュリティに関するガイドライン」の一部改正を公表しました。金融分野では委託先も含め、サイバーリスク管理を継続的に見直す必要があります（出典：金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」の一部改正について、2025年）。
開発時だけでなく、稼働後も脆弱性情報やインシデント連絡、再委託を確かめます。さらに、データ返却と契約終了時の削除まで見ておきます。
▶ 詳細はこちら：契約更改システム開発でおすすめの開発会社6選と選び方
契約更改システムの発注・外注・委託方法
基本となるのは、発注側が業務ルールと受入基準を持ち、委託先が設計から移行までを支援する体制です。
商品部門や募集・営業部門に加えて、契約管理やコンプライアンス、情報システムの部門も関係します。技術担当者だけで発注すると、後から業務要件が追加されやすくなります。
発注前のRFPとデータ準備
RFPとデータサンプルをそろえ、候補各社が同じ業務条件で提案できるようにします。
- 業務・規模：対象業務、契約・月間更新件数、ユーザー・拠点・保険会社・商品数
- システム条件：既存システム、連携方式、保存期間、セキュリティ、稼働時間、サポート、予算、希望時期
- 業務資料：現状と理想のフロー、具体的な課題、匿名化した台帳・更新日・状態・担当者・特約・履歴・書類
個人情報や健康情報は、秘密保持契約と安全な受け渡し方法を整えてから開示します。資料が未整備なら、その前提を明記し、調査やクレンジングの工数を見積に含めてもらいます。
請負と準委任の使い分け
要件がどこまで決まっているか、納める内容がどれだけ明確かに応じて、請負と準委任を選びます。
- 請負：要件と受入条件が明確な本開発では、納める内容と完成の条件を定める候補
- 準委任：現状調査、要件定義、PoC、データクレンジングなど、作業量や正解が開始時に定まりにくい業務に適することがある
段階ごとに契約を分ける場合は、次の工程へ進む判断基準を明記します。契約書では、仕様変更や追加改修、遅延、連携先の障害を確認します。
移行の不備や制度改定への対応も、取り決めておきます。さらに、脆弱性、再委託、知的財産の扱いも確かめます。
データ返却と契約終了時の削除についても、契約で決めておきます。受入条件には、画面の確認だけでなく、対象抽出や状態遷移、通知の動きを含めます。
証跡や権限の設定、性能、障害復旧も条件にします。移行後は、件数の突合も含めます。
受入テストと運用引き継ぎ
受入から稼働後の引き継ぎまで、現場で行う作業を確認していきます。
- 一連の受入：対象抽出、案内、面談、意向確認、提案、申込、承認、更新完了、保全を一案件で通す確認
- 例外の確認：担当変更、意向変更、書類不備、期限超過、連携遅延を試し、期待状態との差を記録
- 運用手順：日次取込、エラー、期限通知、権限、マスタ、月次報告、障害連絡、バックアップを定める
稼働後の90日程度は、開発担当者と業務責任者が定例でKPIを確認します。そのうえで、不要な通知や入力項目を見直すと、現場が無理なく使い続けられます。
▶ 詳細はこちら：契約更改システム開発の発注・外注・委託方法
セキュリティ・法令対応・導入後KPI
契約更改システムは、個人情報や契約情報、健康状態に関する情報を扱う可能性があります。加えて、募集人や担当者の情報、顧客とのやり取りが含まれることもあります。そのため、入力、表示、保存のそれぞれで安全対策を検討し、機能要件と非機能要件は分けて管理します。
最低限必要なセキュリティ要件
安全要件は、アクセス管理、システム運用、記録の追跡性に分けて定めます。
- アクセス管理：MFA、最小権限、職務分掌、特権ID、異動・退職当日の権限停止
- システム運用：通信・保存データの暗号化、秘密情報、バックアップ、脆弱性、監視、RTO・RPO、代替運用
- 証跡：監査ログと改ざん検知を設け、記録の登録・変更・承認者と時点を追跡
金融庁の監督指針は、保険募集時の説明や顧客対応などの記録を適切に管理し、保険期間終了まで保存する考え方を示しています（出典：金融庁「保険会社向けの総合的な監督指針」、2026年確認）。
自社に適用される保存期間と委託先の保管責任は、法務・コンプライアンス部門と一緒に確認します。
導入後のKPI
KPIは、更新の成果と対応の状況、業務の品質、作業の負荷に分けて設定します。
- 更新成果：対象抽出精度、更新率、失効率、保留率
- 対応・品質：抽出から初回接触までの時間、期限内対応率、未接触、意向確認完了率、書類不備率、承認滞留時間
- 作業負荷：案件あたり入力時間、再入力件数、期限超過件数、監査資料の作成時間
導入直後は、稼働前の3か月から6か月の実績と比べます。更新率だけで評価すると、案内を急ぐあまり意向確認や説明記録が不足するおそれがあります。
成果だけでなく業務品質も見ながら、複数の指標を組み合わせて改善を進めます。
契約更改システムに関するよくある質問
最適な方式は、自社の保険種類や契約件数、既存システム、顧客対応の体制によって変わります。初期検討で確認される点を取り上げます。
契約更改システムは満期日管理だけでも導入できますか？
導入できます。まずは、契約データの取込や更新対象の抽出、期限アラートや担当者タスク、対応履歴から始めます。
運用が定着したら、意向確認や電子書類を加えられます。さらに、承認や保険料再計算、顧客ポータルへ広げることもできます。
将来の拡張に備えて、契約IDや顧客ID、商品・特約、更新日の項目は初期設計で確保します。状態と担当者の項目も、あわせて持たせます。
生命保険と損害保険の更改を同じシステムで管理できますか？
一元管理は可能です。ただし、同じ画面に並べるだけでは不十分です。
損害保険の満期更改と生命保険の更新・保障見直しでは、保険料や告知、意向確認の扱いが異なります。さらに、商品改廃や特約の扱いにも違いがあります。そのため、共通の顧客・契約・対応履歴に加えて、保険種類ごとの業務ルールと状態遷移を分けて設計します。
契約更改システムの開発期間はどのくらいですか？
標準的なSaaS導入は1か月から3か月程度、契約・更新管理のカスタム開発は3か月から5か月程度が目安です。
CRM、意向把握、複数連携を含む開発は5か月から12か月程度です。
期間は、データ移行や商品ルールの複雑さ、保険会社数によって変わります。さらに、テストの厳格さや社内の意思決定の速さも影響するため、要件定義と移行リハーサルを含めて見積もります。
Excelで管理している契約データを移行できますか？
移行はできますが、事前に項目の意味や表記、日付の形式を整理しておく必要があります。状態や顧客の重複、担当者、履歴・書類についても、事前に確かめます。匿名化した実データでリハーサルし、旧台帳の件数と代表契約の突合を受入条件にすると、不一致を減らせます。
まとめ
契約更改システムは、対象抽出、案内、意向確認、見直し提案、申込、承認、更新後の保全と証跡をつなぐ業務基盤です。
生命保険では、更新時の保険料や年齢、告知を扱います。さらに、商品改廃や特約、保障ニーズも含まれます。そのため、損害保険の年次更改機能をそのまま当てはめないよう注意が必要です。
導入前の確認項目（5項目）
導入方式を比べる前に、判断の条件を確認しておきます。確認するのは次の5項目です。
- 契約管理：更新対象を正確に抽出できるか
- 対応期限：担当者と期限の管理、未対応件数の削減
- 記録：意向・説明・承認・書類を契約単位で保存
- 安全性：権限、監査ログ、委託先管理を要件に含めているか
- 運用費：初期費用ではなく5年TCOで比べる
これらが明確になれば、SaaSやパッケージ、汎用基盤、スクラッチのうち、自社に合う方式を判断しやすくなります。
小さく始めた導入と業務品質の測定
まずは1拠点や1商品群を対象に小さく始め、全社の基幹を一度に刷新しないようにします。そのうえで、契約取込や更新対象の抽出、タスクを検証します。さらに、対応履歴や意向確認、権限・ログも確かめます。
稼働前と稼働後で、初回接触までの時間や未対応件数を比較します。また、期限内対応率、証跡不備率、入力時間も確かめ、現場が使い続けられる設計へ改善します。
▼関連記事一覧
・契約更改システム開発の進め方
・契約更改システム開発でおすすめの開発会社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を創業。