保険金査定システムの発注は、業務範囲の整理、発注形態の選定、RFPでの条件統一の順に進めると、委託先との認識差を抑えられます。
発注形態、契約、費用、委託先の選び方も、この流れに沿って順に押さえると整理しやすくなります。
▼全体ガイドの記事
・保険金査定システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
保険金査定システムの発注・外注前の全体像
保険金査定システムは、契約後に発生した事故や疾病、損害の請求情報を契約内容と照合する業務システムです。支払可否と金額を決め、請求者や代理店との連絡から証拠書類の扱い、支払処理、監査証跡までを扱います。
同じ「査定」でも、契約を引き受けるか決める「引受査定」とは目的が異なります。
保険金査定システムが管理する業務
まず受付方法、請求書類、案件状態、担当者権限、監査記録を整理すると、必要な機能が見えてきます。請求を受けたあとは、契約管理システムと照合する流れになります。
- 請求受付：Web・スマートフォン・代理店ポータルから受け付ける
- 書類登録：受付番号を発行し、写真・動画・診断書・修理見積書を受け取る
- 案件管理：受付済みから書類不足、追加資料待ち、査定中、上長承認待ち、支払決定、不支払を経て完了まで追跡する
- 権限管理：担当者、損害調査担当、上長、支払担当ごとに権限を分けて持たせる
- 監査証跡：契約条項、変更履歴、操作ログ、AI出力、人の修正内容を、後から追えるように残す
損害保険と生命保険で異なる必要データ
査定で扱うデータは保険種別によって異なり、そのぶん必要な機能も変わります。
- 損害保険：自動車の損傷画像、火災・水災の写真、修理見積もり、事故位置、代理店の受付情報を使う
- 生命保険：診断書、入院・手術情報、医療コードを扱い、商品・特約ごとの支払条件を照合する
画像による査定を重視するのか、帳票をコード化して扱うのかによって、AI、データモデル、テスト方法の組み方が変わります。
発注前の業務範囲の4段階
発注範囲は、システム化する業務の深さで4段階に分けて考えると、会社ごとの提案を同じ基準で比べられます。
- 受付・保管：請求受付と書類保管
- 査定支援：OCR・入力支援と担当者向け支援
- 自動判定：商品・特約ルールによる支払可否の判定
- 基幹連携：契約管理・支払基盤・代理店システムとの連携
最初は全商品を自動化せず、請求件数が多く判断が比較的単純な商品を1つ選ぶのが現実的です。そのうえで、過去案件で精度を確かめてから対象を広げます。
保険金査定システムの発注形態の選び方
発注形態は、請求件数や商品・特約数、既存システムの複雑さで考えます。独自ルールの有無も、選択の大きな材料になります。
標準業務が多い場合はSaaS・パッケージ、独自性と拡張性を重視する場合はハイブリッドが、まず候補に挙がります。
基幹の更改や高度な統制が必要な場合は、個別開発やスクラッチも検討の対象になります。
SaaS・パッケージ導入が向く場合
SaaSやパッケージは、標準機能から始めやすい点が強みです。個別の調整事項も、契約前に確認できます。
- 標準機能：請求受付、契約管理、書類保管、ワークフローを短期間で導入できる
- iChainBase：少額短期保険向け製品として案内されている
- 導入工数：標準機能を使えれば、要件定義と設定の工数を抑えられる
- 契約確認：商品改定、独自ルール、保管場所、API制限、障害運用、データ返却、再委託先を確認する
iChainBaseでは、書類アップロード、オンライン請求受付、支払査定が案内されています。加えて、自動査定オプションと契約照会APIも用意されています（出典：iChain株式会社「iChainBase」、2026年確認）。ただし、例外処理を無理に削ると、導入後に手作業が増える可能性があります。
クラウド上の個別開発が向く場合
クラウド上の個別開発は、既存システムを活かしながら、業務に合わせて拡張できるのが特徴です。
- 構成：画面、API、案件管理、ルール、文書保管、ワークフロー、支払連携、監査ログを組み合わせて作る
- 段階導入：既存の契約管理・顧客マスタを残し、受付・査定支援から始めて、商品やチャネルを増やしていく
- API要件：エラー処理、再送、タイムアウト、重複データの扱いを事前に決める
- 継続要件：バックアップと復旧目標を決める
- 安全管理：暗号化、権限、鍵、ログ、保存先、リージョン、委託先・再委託先の条件をRFPに書く
標準機能と独自査定を分けたい場合のハイブリッド型
標準機能と独自領域を分けておくと、初期のリスクを抑えながら、固有のルールも扱えます。
- 標準部分：受付、文書保管、基本ワークフローをパッケージで整える
- 独自部分：支払判定、画像査定、代理店連携、分析を、APIや個別開発で加える
- 適用範囲：既製品では扱いにくい商品・特約や損害調査ルールも維持できる
- 責任分界：障害窓口、API変更通知、データモデルの所有権、リリース順序、テスト環境を文書に残す
- 統括責任：発注先を一社にまとめられない場合は、元請け責任者を明確にする
独自商品と大規模統制がある場合のスクラッチ開発
標準製品では業務を吸収しきれない場合に検討します。自由度が高い一方で、改定費用や保守の負担が増えます。
- 検討条件：独自商品、複数基幹との連携、全国拠点や代理店での24時間運用
- ルール管理：判定ロジックをコードから切り離し、登録、承認、テスト、適用日、旧ルールへの復帰を管理する
- AIの役割：単純案件の自動処理や入力支援から始め、判断不能案件は人へ戻す
- 判断記録：人が最終判断した根拠を残す
商品改定のたびにルール変更の費用がかかります。さらに、判定の知識がコードに埋まると、保守も難しくなります。
保険金査定システムの発注・外注の進め方
提案依頼を急いで始めると、会社ごとに想定する範囲が変わってしまい、提案を比べられなくなります。まず業務の流れを一覧にして範囲を決め、RFPを配布して提案と見積を比べます。そのうえで契約後に要件を確定すると、発注者と受託者の認識差を小さくできます。
請求受付から支払完了までの現行業務の洗い出し
請求から支払完了までの流れと、各工程の実際の進め方を記録しておきます。
- 業務フロー：受付チャネル、取得項目、必要書類、照合、追加資料、損害調査の分岐、承認、支払、通知、再査定、苦情対応を時系列に並べる
- 工程情報：担当部署、利用システム、手作業、判断基準、例外、処理時間、月間件数を記録する
- 判断条件：経験に頼っている判断を、契約条項、証拠、支払不可条件、上長へのエスカレーション条件に分けて書き出す
- 評価データ：過去案件の正しい結果、誤判定、追加資料、人の修正を抽出し、ルールやAIの評価に使う
最初のMVPの範囲：1商品・1チャネル
対象を絞ってMVPを組み、業務とAIの品質を検証します。
- 対象選定：請求件数が多く条件を整理しやすい1商品、または限定した代理店チャネルを選ぶ
- MVP機能：受付、書類アップロード、契約照合、ルール判定、手動承認を含める
- 支払連携：本番振込まで行うか、テスト用データ出力に留めるかをリスクと体制で決める
- 評価指標：処理時間、支払漏れ・過払い、誤った追加資料要求、差し戻し、代理店問合せを測る
- 品質確認：自動化率だけでなく正確性と説明可能性も評価する
全商品を一度に対象にすると、例外処理とデータ移行が膨らみます。
提案依頼と選定の比較条件
提案書の章立てを指定し、実案件に近い操作で比べます。
- 共通条件：同じRFP、同じ匿名化サンプルデータ、前提条件を全社に渡し、提案書の章立てもそろえる
- 提案範囲：対象外、利用者数、請求件数、連携・移行件数、テスト、納品物、保守、追加費用を、提案書に記載してもらう
- 実演内容：書類不足の判定、契約照合、例外の引き継ぎ、上長承認、判定理由を、実演で確かめる
- 現場適合：誤りを修正できるか、ルール改定を安全に反映できるか、障害時も業務を続けられるかを見る
テスト・リリース・運用引き継ぎの範囲
開発から運用までを発注範囲に含めたうえで、例外も含めた受入条件を決めます。
- 開発工程：要件定義、画面・API・ルール・移行の設計、開発
- テストと移行：単体・結合・総合・受入テスト、教育、本番移行、安定稼働確認を含める
- 例外テスト：書類不足、重複契約、免責、保険期間外事故、支払済み、異議申立て、停止中受付を試す
- 運用：商品改定、権限追加、AI評価、ログ監査、復元、障害訓練を続ける
- 納品物：マニュアル、ルール一覧、API・データ定義、テスト結果、制約、復旧手順、窓口を受け取る
RFP・要件整理で書く項目
RFPには、業務課題と対象範囲、制約をそろえて書きます。加えて、成果物と提案条件も同じ資料に記載します。
件数や商品数が曖昧なまま自動査定を依頼すると、見積条件が各社で異なり、後から追加費用が発生しやすくなります。
業務量とデータ前提の示し方
件数、利用するシステム、データの利用条件を、数値と具体名で示します。
- 業務量：月間・繁忙期件数、同時利用者、商品・特約、代理店、受付チャネルを記載する
- 書類・保管：1件あたりの書類点数、画像・動画容量、保管期間、過去データ件数を示す
- 連携先：契約管理、顧客、代理店、支払、会計、通知、認証の各システムについて、連携方式、更新頻度、API、CSVの制約を整理する
- AI前提：帳票の種類、画像品質、正解データ、許容誤り、人が確認する項目を明らかにする
- データ利用：匿名化、利用目的、保存期間、再学習、国外移転、委託先について、法務と個人情報の担当者と確かめる
機能要件の書き方：判定・例外・権限
機能や権限は、判定ルールや例外対応とあわせて、一連の業務として定義します。
- 業務機能：受付、本人確認、照合、書類案内、OCR、判定、調査、追加資料、承認、支払、不支払通知、再査定、問合せを含める
- 権限：各状態での閲覧・変更・承認者を定め、代理店は自社案件だけを見られるようにする
- 査定ルール：商品・特約、保険期間、免責、事故日、損害区分、支払限度額を整理する
- 例外管理：重複契約、追加資料、エスカレーション条件を定める
- 変更管理：ルール変更者と承認者を分け、適用開始日を指定できるようにする
価格比較の前に決める非機能・監査要件
セキュリティと監査の条件は、企画の段階から決めてRFPに含めます。
- 可用性：稼働・応答時間、同時利用者、復旧時間、バックアップ頻度、災害対策を定める
- 安全管理：監視、脆弱性、権限、ログ保存、暗号化、データ削除を決める
- 第三者管理：金融庁のガイドラインは、リスクと第三者管理を重視しています（出典：金融庁、2025年7月改正）
- 追跡記録：参照者、日時、使用ルールと書類、AI出力、人による修正と承認を記録する
- ログ運用：改ざん防止、検索、出力権限、保存期間、監査画面を決める
ログを事後に確かめられる仕組みがあると、障害調査や苦情対応で事実を追いやすくなります。
保険金査定システムの契約形態の選び方
契約形態は、要件の確定度と成果物で分けて考えます。要件が固まった開発には請負、調査や要件定義には準委任を当てはめると、扱いやすくなります。そのうえで、契約の名称だけでなく、完了条件や変更方法、責任分界を明確にしておく必要があります。
請負契約の完成条件と検収基準
成果物と検収条件が明確な開発工程であれば、請負契約を検討できます。
- 対象成果物：画面、API、ルール管理、移行、テスト、マニュアルなどを定める
- 検収基準：正常系に加え、書類不足、重複請求、権限違反、連携エラー、ルール改定、障害復旧を確認する
- 変更管理：データ提供の遅れ、ルール追加、API変更に備えて、変更手順、追加見積、納期への影響、責任分担を契約に書く
準委任契約の活用場面：要件定義と専門支援
完成条件を固定しにくい工程では、専門業務の遂行を委ねる準委任が適しています。
- 対象業務：現行分析、RFP作成、方式比較、ルール整理、進行管理、セキュリティ設計
- 役割分担：発注者が保険業務を判断し、受託者は整理と技術を支援する
- 業務報告：稼働時間・体制、月次報告、課題、決定事項、次月計画、知識移管を定める
- 最終判断：査定ルールの承認者は発注者に置き、契約解釈や支払判断を外部任せにしない
要件定義・開発・保守の契約の分け方
工程ごとの確定度に合わせて契約を分けたうえで、知的財産や終了条件も見ておきます。
- 契約の分担：要件整理は準委任、確定MVPの開発は請負、保守は準委任または保守契約にする
- AI検証：データ品質で精度が変わるため、検証と本番導入を分ける
- 権利と情報：著作権、利用権、OSS、第三者サービス、学習データ、秘密保持、個人情報を確認する
- 継続・終了：再委託、脆弱性、障害連絡、終了時のデータ返却・ログ保管を定め、運用自由度と撤退可能性を比べる
保険金査定システムの費用相場とコスト内訳
査定システム単体の公開価格表や、業界全体を代表する統計は確認しにくい状況です。費用は、機能や件数、商品・特約によって変わります。さらに、既存連携や移行、セキュリティ、AI評価データも費用を左右します。
ここに挙げる金額は、2025年時点の一般的な開発人月単価と保険要件から推定した、検討用の目安です。査定専用の公定価格ではありません。
発注範囲別の初期費用：800万円〜3億円超
初期費用は発注範囲によって変わります。次に挙げるのは、2025年時点の発注検討用の推定目安です。
- 設定中心：SaaS・パッケージ導入は800万円〜2,500万円程度、3〜8か月
- 限定MVP：1商品・限定代理店の請求査定は1,500万〜3,000万円程度
- 部分連携：契約管理・支払基盤との連携を含めると2,000万〜6,000万円程度
- AI追加：OCR・画像査定・不正検知を加える場合、データ整備、評価、API、人の確認を含め、1,000万〜5,000万円程度の追加費用が生じることがある
- 大規模開発：多数の商品・拠点・代理店や複数基幹を含めると8,000万〜3億円超。24時間運用などでは12〜24か月以上の可能性がある
査定専用の公定価格ではないため、実際の金額はRFPをもとに個別見積を取って決めます。
見積書の要件定義・連携・テスト費用の分解
作業ごとに費用を分けておくと、発注者側の準備の負担も含めて、総額を比べられます。
- 開発費：要件定義、業務整理、UI・UX、アプリ、ルールエンジン、OCR・AIごとに分ける
- 基盤費：API、移行、インフラ、認証・権限、セキュリティ診断ごとに分ける
- 導入費：テスト、教育、進行管理、保守の費用も提示してもらう
- 連携条件：API本数、認証、変換、再送、テスト環境で費用が変わる
- 社内工数：ルール確認、匿名化、受入テスト、教育などを含め、受託費や月額費と合算して見る
発注者側の準備が不足すると、開発停止やリリース後の手戻りにつながります。
月額費用の内訳：利用量・保守・AI従量課金
月額費は利用量に加えて、AI処理、保守、安全管理、停止時の対応まで確認します。
- 基盤・利用料：SaaS、クラウド計算・保存・通信、ユーザー数・請求件数の料金
- 運用費：OCR・生成AI処理、監視、保守、脆弱性対応、バックアップ、サポート
- 月額目安：利用量連動で30万〜200万円程度からの場合もあるが、個別見積で確認する
- AI課金：ページ・画像・トークン単価、再処理、モデル変更の検証、学習データ保管を確認する
- 費用管理：料金上限、予算アラート、利用停止時の手動切替を運用・契約に含める
この月額目安は、査定専用サービスの標準価格ではありません。
保険金査定システムの委託先選定と見積比較の観点
委託先は、知名度や価格だけでなく、保険業務やルール変更、移行、連携への対応で比べます。また、セキュリティと運用の引き継ぎも確認します。
プライムベンダー、パッケージ会社、AI・OCR会社では、任せられる範囲が異なります。そのため、各社の評価は役割に応じて行い、同じ尺度に無理に当てはめないようにします。
保険業務と対象領域の実績
実績の件数だけでなく、対象領域や役割が自社に近いかを確かめます。
- 対象業務：支払査定、受付、契約照合、代理店連携、損害調査、診断書処理、画像査定
- 実績内容：商品数、月間件数、利用者数、既存連携、保守体制、元請け・再委託の別を聞く
- 役割分担：保険知識が薄いAI・画面開発会社の場合は、ドメイン担当会社との責任の分け方を決める
- 類似性：損保と生保の違いを踏まえ、自社の損害種別・商品・代理店に近い事例を確認する
見積比較の条件：範囲・前提・成果物
価格差の理由が分かるよう、範囲と前提、費用項目を照らし合わせます。
- 機能範囲：受付のみか支払判定までか、AI検証や人の確認を含むかをそろえる
- 作業範囲：API本数、移行件数、テスト、教育を確認する
- 費用項目：初期・月額費、オプション、従量課金、保守、追加開発単価を並べる
- 契約条件：納期、発注者作業、保証、解約費用を比較する
- 差額理由：要件定義、レビュー、テスト、セキュリティ、移行、運用設計の省略有無を調べる
見積から除外された項目は、後から追加費用になる可能性があります。
AIの精度とセキュリティの確認方法：実演・証跡・契約
AIは受付から人の査定までを支える設計として、性能と管理条件を確かめます。
- 導入動向：生命保険の支払査定を支援するAIが提供されています
- 実証動向：受付や書類確認を支援する請求AIの実証が進んでいます
- 精度評価：匿名化案件で読み取り・分類・判定、判断不能時、人の確認率、誤判定是正、更新後の再テストを確認する
- 契約管理：再学習利用、保存場所・削除、権限、事故通知、再委託先を定める
- 継続管理：金融庁も、重要業務の継続と第三者リスク管理を論点にしています（出典：金融庁「金融分野におけるITレジリエンスに関する分析レポート」、2025年6月）
PKSHA Technologyは2025年10月30日、書類データ化、査定ルート最適化、担当者支援を行う生命保険査定向けAIを発表しました（出典：PKSHA Technology、2025年10月30日）。また、リードインクスとMysuranceは2026年3月、受付とAI-OCR・LLMの書類確認を組み合わせた保険金請求AIを実証しました（出典：Mysurance、2026年3月27日）。
運用開始後の体制と提案内容
日々の変更と障害対応の分担は、提案の段階で体制を確かめておきます。
- 運用作業：商品改定、帳票変更、代理店権限、手動受付、ログ監査、AI確認、問合せの担当を決める
- 変更分担：業務担当者が行う変更と、開発会社へ依頼する作業を分ける
- 支援期間：3か月・6か月の安定稼働支援、教育、定例会を提案書に記載してもらう
- 対応基準：障害優先度、応答時間、改善提案の方法を確認する
- 発注者体制：業務、IT、セキュリティ、個人情報、査定の担当者を置き、決定を進める
分担が明確であれば、保守費用と対応時間を見通しやすくなります。
2026年時点の最新動向と注意点
2026年時点では、AI-OCRや生成AI、画像認識を段階的に導入する動きがあります。主な用途は、請求者への案内や事故の受付、書類確認、担当者の査定支援です。
導入にあたっては、AIの対象工程と根拠の示し方を決めるほか、人の承認点や誤りの監視方法も定めます。
判断を支援するAIと人の役割分担
支払判断には説明責任が伴うため、AIの役割と人の承認を、RFPで定めておきます。
- AIの支援：帳票の抽出、書類不足の確認、類似案件の検索、単純なルールの適用、根拠候補の提示を担う
- 人への引継ぎ：複雑な例外や判断不能案件を担当者へ戻す
- 最終承認：AIだけに支払を任せず、担当者が契約条項と原資料を確認する
- 効果測定：査定・追加資料依頼の時間、手動処理率、再査定、支払漏れ・過払い、問合せを測る
- 品質評価：自動化率・誤判定率を確認し、苦情や顧客体験も合わせて評価する
第三者サービスを含む業務継続と安全管理
第三者サービスが止まる場合も想定し、代替手段と委託管理を発注条件に含めます。
- 対象サービス：クラウド、OCR、AI、SMS、メール、金融機関、外部DBを計画に含める
- 障害対応：代替受付、後入力、手動査定、復旧後の二重処理防止、顧客通知を決める
- 委託管理：金融庁資料を参考に、委託先評価、再委託把握、事故報告を契約・運用に反映する
- 復旧確認：脆弱性対応、バックアップ復元、復旧訓練
- 予算：監視やテストを、重要業務の継続費用として見積もる
よくある質問
費用や納期は業務範囲によって変わるため、請求件数、商品数、既存システム、セキュリティ要件に照らして確かめます。
保険金査定システムの開発費用は最低いくらですか？
費用は範囲によって変わります。次に挙げる金額は、査定専用の公開統計ではなく、機能範囲と一般的な開発工数から推定したものです。
- 標準設定：800万円〜2,500万円程度、3〜8か月が目安
- 限定MVP：商品・チャネルを絞った場合は1,500万〜3,000万円程度
- 見積条件：件数や商品・特約、基幹連携、移行、AI、セキュリティを、RFPに記載する
パッケージとスクラッチ開発はどちらがおすすめですか？
標準的な受付や書類保管を早く導入したいならパッケージ、独自商品や複雑な基幹連携が中心ならスクラッチを検討します。
多くの企業では、標準機能と独自の判定や画像査定を組み合わせるハイブリッドが、費用、拡張性、導入リスクのバランスを取りやすい方法です。
保険金査定システムは請負と準委任のどちらで発注しますか？
要件の確定度や作業の性質に応じて、工程ごとに契約を分けるのが一般的です。
- 要件整理：準委任契約で進める
- 開発：条件が固まった範囲を請負契約にする
- 運用・保守：準委任または保守契約を使う
- AI検証：前提が変わりやすいため工程を分け、成果物・評価指標・追加作業条件を定める
RFPには何を最低限入れるべきですか？
業務量、システム条件、AI・安全要件、契約境界を、一つの資料にまとめます。
- 業務条件：月間・繁忙期の請求件数、商品・特約、代理店、受付方法、必要書類
- システム条件：既存連携、権限、保管期間、稼働時間、復旧目標
- AI・移行：AI範囲、正解データ、テスト、移行条件
- 契約範囲：対象外、発注者作業、納品物、保守、再委託、データ返却、事故対応
条件を明記しておくと、各社の見積を同じ前提で比べられます。
まとめ
発注では、受付から再査定までの業務を、書類確認や契約照合、査定、承認、支払ごとに分けて考えます。
システム化する範囲や件数、独自ルールをもとに、SaaS・パッケージ、クラウド個別開発、ハイブリッド、スクラッチを比べ、合う発注形態を決めます。
発注成功の要点：範囲・契約・見積の前提のそろえ方
発注条件と責任の範囲をそろえておくと、候補会社の提案を同じ土台で比べられます。
- RFP：件数、商品・特約、代理店、既存システム、データ、AI、権限、監査、安全、継続条件を示す
- 契約：要件定義は準委任、明確な開発は請負、運用保守は別契約を検討する
- 費用比較：初期費に加え、連携、移行、テスト、教育、AI従量課金、保守を確認する
最初の一歩：過去案件と現行フローの整理とRFP化
まずは小さく検証し、効果と委託先の運用力を見ながら、段階的に広げていきます。
- 検証範囲：1商品・1チャネルのMVPで人とAIの役割を確かめる
- 改善判断：査定時間、正確性、再査定率、問合せ件数などのKPIを見る
- 委託先評価：保険業務、ルール変更、監査、セキュリティ、引き継ぎを確認する
▼全体ガイドの記事
・保険金査定システム開発の完全ガイド
▼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を創業。