保険会社や保険代理店で、契約管理や保険金支払いを担う基幹システムの刷新、あるいは新しい保険商品を売るためのシステム開発を検討する場面が増えています。ただ、保険のシステムは業務が複雑で、既存の仕組みも長年使い込まれているため、「そもそも何から手をつければよいのか」「どこに頼めば任せられるのか」が見えにくいのが実情です。
保険システムの開発は、一般的な業務システムの開発と比べて考えることが多くなります。契約・収納・保険金支払いといった保険特有の業務をどう作るか、老朽化した基幹システムをどう移行するか、保険業法や金融庁の監督指針にどう対応するか——こうした論点を押さえないまま発注先を選ぶと、後戻りの大きい判断になりかねません。
この記事では、保険システムが指す範囲と必要な機能を整理したうえで、開発が難しくなる理由、開発方法（パッケージ・フルスクラッチ・マイグレーション）の違いと費用・期間の目安、押さえるべき法規制、そして開発の依頼先を見極める基準まで解説します。自社の進め方を組み立て、相談先の当たりをつけるための材料としてご活用ください。
目次
一括ダウンロードする
保険システム（保険会社システム）とは
保険システムとは、保険会社や保険代理店が保険事業を運営するために使う業務システムの総称です。ひとくちに保険システムと言っても、担う業務によって役割が分かれます。開発や刷新を検討するときは、まず「どの領域のシステムを対象にするのか」を切り分けることが出発点になります。
大きく分けると、保険会社の中核業務を担う基幹系、営業や販売を支える営業支援系、代理店の業務を担う代理店系の3つに整理できます。ここからは、それぞれが扱う範囲を見ていきます。
保険会社の基幹系（契約・収納・保険金支払い・再保険）
基幹系は、保険事業の根幹となる業務を担うシステムです。保険の引受・契約管理、保険料の収納、保険金・給付金の支払い、再保険といった業務を扱い、保険会社の勘定にも直結します。生命保険では第一分野、損害保険では第二分野、医療・傷害などの第三分野で扱う商品が異なり、それぞれで求められる処理も変わります。
基幹系は取り扱うデータ量が多く、長期にわたって契約を管理し続ける必要があります。稼働の停止が保険金支払いの遅延に直結するため、安定稼働への要求水準が高い領域です。それぞれの業務でどのような機能が必要になるかは、次の「保険システムに必要な機能」で具体的に整理します。
営業支援系・代理店系との違い
営業支援系は、保険商品の見積もり・申込・販売といった顧客接点の業務を支えるシステムです。近年はWebやアプリからオンラインでE申込を完結させる仕組みや、事業会社が自社サービスに保険を組み込む「組込型保険（エンベデッド保険）」への対応も広がっています。
代理店系は、保険を販売する代理店の業務を担うシステムです。顧客・契約情報の管理、募集にあたっての意向把握の記録、手数料計算などを扱い、保険会社の基幹系とは対象とする業務も利用者も異なります。
基幹系ではなく代理店の業務効率化を主な目的とする場合は、対象とするシステムそのものが変わります。代理店向けのシステムの選び方や機能は、以下の記事で比較・解説しています。
保険システムに必要な機能
ここからは、保険システムに求められる機能を業務の流れに沿って整理します。募集から保険金の支払いまで、保険事業は一連のプロセスでつながっており、システムはこの流れを支える必要があります。自社の要件に抜け漏れがないかを確認する際のチェックリストとしてご活用ください。
| 機能 | 商品開発・料率設定 | 募集・見積・申込 | 引受査定（アンダーライティング） | 契約管理・保全 | 収納（保険料収納） | 保険金・給付金支払い | 代理店・手数料管理 | 再保険・決算・帳票 |
|---|---|---|---|---|---|---|---|---|
| 主な機能・役割 | 保険商品の設計、補償内容・特約の設定、保険料率の計算ロジックの管理。新商品の追加や改定に対応する | 保険料の見積もり、オンラインでの申込受付、募集時の意向把握の記録。Webやアプリの顧客接点と連携する | 申込内容の審査、引受可否の判定、告知・診査情報の管理 | 契約内容の登録・照会、住所変更や契約者変更などの異動処理、更改・解約の管理 | 保険料の請求・入金消込、口座振替やクレジットカード決済との連携、未収・失効の管理 | 保険金請求の受付、支払査定、支払い処理。約款に基づく支払可否の判断を支える | 代理店の登録・管理、募集実績の集計、手数料の計算・精算 | 再保険の出再・受再管理、責任準備金などの計算、監督当局向けを含む各種帳票の出力 |
※上記は保険システムで扱われる代表的な業務領域の整理です。必要な機能は事業の分野（生保・損保・少額短期）や商品によって異なります。
これらすべてを一度に作り替える必要があるとは限りません。基幹系だけを刷新する、営業・申込のフロントだけをオンライン化する、といった形で対象を絞る進め方もあります。どの範囲を対象にするかは、後述する開発方法の選択にも関わります。
保険システム開発が難しい理由（開発の難所）
保険システムの開発は、一般的な業務システムより難易度が上がりやすい領域です。ここでは、発注前に理解しておきたい難所を4つの観点で整理します。社内での検討や稟議の材料としても役立ちます。
勘定系業務の複雑さと長期のデータ管理
保険は、契約から保険金支払いまでの期間が長く、生命保険では数十年にわたって契約を管理し続けます。料率計算や責任準備金の計算には保険数理が関わり、商品ごとに処理も異なります。こうした複雑な業務ロジックを正確に実装し、長期にわたってデータを保持し続ける設計が求められます。
レガシー化した基幹システムと移行の負担
とくに生命保険会社の基幹系では、長年にわたってCOBOLで開発され、ホストコンピューター（メインフレーム）上で稼働してきたシステムが今も多く使われています。実際に、生命保険の基幹システムの現場では、ホスト基盤からサーバー基盤へのマイグレーション（移行）が進行している例があります。
こうした移行は一度に完了するものではなく、2025年から2028年にかけて段階的に進める例もあります。移行期間中は、現行のホスト上のCOBOL資産（メインフレーム上で動くCOBOL）を保守しながら、並行して新環境（サーバー上のCOBOLやオープン系）へ対応範囲を広げていく形が取られます。稼働中の基幹を止めずに切り替えるための、現実的な進め方です。
出典・参考資料（1件）
- 参考資料：生命保険のCOBOL案件一覧｜biz-itengineer（リンク）
これはある生保基幹の開発案件で示された移行計画で、業界全体が同じ日程で動くわけではありませんが、ホストからサーバーへの大規模な移行が数年がかりで進む一例です。こうした移行では、稼働中のシステムを止めずに段階的に切り替える必要があり、既存の業務ロジックの棚卸しや検証に相応の期間と体制がかかります。レガシー刷新をどう進めるかは、後述する「開発方法の比較」でも扱います。
高い可用性と大量データの処理
保険金の支払いや契約者からの問い合わせ対応が止まると、契約者に直接の不利益が生じます。金融庁の監督指針も、システムの安全かつ安定的な稼働を保険会社への信頼の前提と位置づけています。大量の契約データを扱いながら安定稼働を保つための設計・運用が、非機能面の要求として重くのしかかります。
法規制・監督指針への対応
保険業は免許制の事業であり、システムにも保険業法や金融庁の監督指針に沿った対応が求められます。顧客情報の適切な管理、外部委託先の管理、システムリスク管理といった要件を、開発の要件定義に織り込む必要があります。具体的にどの法令・指針を押さえるべきかは、後述する「押さえる法規制・監督指針」で解説します。
一括ダウンロードする
開発方法の比較（パッケージ／フルスクラッチ／マイグレーション）
保険システムの開発方法は、大きくパッケージ・SaaSの導入、フルスクラッチ開発、既存システムのマイグレーション（移行・刷新）の3つに整理できます。どれが適しているかは、対象とする業務範囲や既存システムの状況、かけられる費用・期間によって変わります。以下に、それぞれの傾向を整理します。
| 開発方法 | パッケージ・SaaS導入 | フルスクラッチ開発 | マイグレーション（レガシー刷新） |
|---|---|---|---|
| 初期費用の傾向 | 抑えやすい | 高くなりやすい | 規模により大きい |
| 導入期間の傾向 | 短め（設定中心） | 長め | 長め（段階移行） |
| 向くケース | 少額短期保険や新規事業の立ち上げ、標準的な業務を早く始めたい場合 | 独自性の高い商品・業務を要件どおりに作り込みたい場合 | 老朽化したホスト・COBOL基幹を刷新したい場合 |
| 主な留意点 | 自社独自の業務は標準機能に合わせる調整が必要になる | 要件定義・開発の負荷が大きく、保守も自社で担う前提になる | 稼働中システムを止めずに移行する計画と検証が要になる |
※上記は各開発方法の一般的な傾向です。実際の費用・期間は対象業務や既存システムの状況によって異なります。
標準的な業務を早く始めたいならパッケージ・SaaS、独自性の高い商品や業務を要件どおりに作り込みたいならフルスクラッチ、老朽化した基幹を刷新するならマイグレーションが基本の選び分けです。既存システムの状況と、かけられる費用・期間によって、適した方法は変わります。
レガシー／COBOL移行の進め方
ホスト・COBOLで稼働してきた基幹システムを刷新する場合、稼働中の業務を止めずに新環境へ切り替える段階的な移行が基本になります。前述のとおり、生命保険の基幹では2025年から2028年にかけてホスト基盤からサーバー基盤への移行を進める例があり、移行そのものが数年がかりのプロジェクトになります。
移行では、長年の改修で複雑化した既存の業務ロジックを棚卸しし、新環境で同じ処理が再現できるかを検証する作業に相応の工数がかかります。一度にすべてを切り替えるのではなく、業務や商品の単位で区切って移行する計画を立てることが、リスクを抑えるうえで重要です。
保険システム開発の費用・期間の目安
保険システム開発の費用は、対象とする業務範囲・既存システムの状況・カスタマイズの度合いによって大きく変わるため、一律の相場を示すことは困難です。ただし、費用がどのように積み上がるかの構造を理解しておくと、見積もりの妥当性を判断しやすくなります。
受託開発の費用は、おおまかには「開発要員の月額単価 × 必要な工数（人月） × 体制の規模」で積み上がります。開発要員の月額単価の目安としては、生命保険のCOBOL開発案件で1人あたり月額550,000円〜650,000円程度の水準が、フリーランス技術者向けの求人（2026年時点）で示されています。
ただし、これはあくまで開発要員個人の月額単価の一例であり、受託開発のプロジェクト総額や一般的な相場を示すものではない点に注意が必要です。
出典・参考資料（1件）
工数・期間の目安としては、公開されている事例が参考になります。ある損害保険会社の基幹システムをホストからオープン環境へ移行した事例では、全体計画・実行計画・ホストのオープン化といったフェーズごとに、6カ月・18カ月・36カ月といった期間が示されています（各フェーズは並行して進む部分もあり、単純な足し算にはなりません）。
これらは特定事例の値で一般的な相場ではありませんが、桁感の手がかりにはなります。たとえば5人程度の体制で1年（約60人月）を要する開発なら、月額単価60万円換算で概算数千万円規模となり、対象業務の広い基幹系のフルスクラッチや大規模移行では数百人月・数年規模に及ぶこともあります。逆に、対象を絞ったパッケージ導入ではこの桁より小さく収まる傾向があります。
出典・参考資料（1件）
一方、少額短期保険や新規事業の立ち上げでパッケージ・SaaSを利用する場合は、初期費用を抑え、導入期間を短くできる傾向があります。公開されている例では、契約申込のフロントを最短3週間、少額短期向けの基幹業務を最短6ヶ月、テンプレート・ローコードでの立ち上げを最短2週間から約8週間で案内するものもあります（対象業務やカスタマイズの範囲によって変わります）。
費用を左右する主な要因は、対象とする業務の範囲（フロントだけか基幹まで含むか）、既存システムからの移行の有無、標準機能に合わせるかカスタマイズするか、の3点です。この3点で見積もりは大きく振れるため、自社が対象とする範囲を絞り込んだうえで、複数の相談先から見積もりを取り、内訳（初期費用・月額・保守費用）まで揃えて比較することが現実的です。
保険システム開発で押さえる法規制・監督指針
保険システムの開発では、機能の作り込みだけでなく、保険業に課される法規制・監督指針への対応を要件定義の段階から織り込む必要があります。ここでは、押さえておきたい主な法令・指針を整理します。
また、金融庁の「保険会社向けの総合的な監督指針」は保険会社（免許業者）に適用される行政の着眼点であり、保険代理店には、保険会社からの委託先管理・情報管理を通じて、または個人情報保護法などを通じて及ぶ関係になります。
保険業法（業務運営に関する措置）
保険業は免許制の事業です。保険業法（平成7年法律第105号）第3条は「保険業は、内閣総理大臣の免許を受けた者でなければ、行うことができない。」と定めており、保険会社は金融庁の監督の対象になります。
システム開発との関係でとくに重要なのが、業務運営に関する措置を定めた保険業法第100条の2です。顧客情報の適正な取扱いと、業務を外部委託する場合の的確な遂行を、法律上の措置として求めています。システム開発は顧客情報を扱い、外部のベンダーへ委託する行為にあたるため、この条文が対応の土台になります。
保険会社は、その業務に関し、この法律又は他の法律に別段の定めがあるものを除くほか、内閣府令で定めるところにより、その業務に係る重要な事項の顧客への説明、その業務に関して取得した顧客に関する情報の適正な取扱い、その業務を第三者に委託する場合（当該業務が第二百七十五条第三項の規定により第三者に再委託される場合を含む。）における当該業務の的確な遂行その他の健全かつ適切な運営を確保するための措置を講じなければならない。
出典：保険業法 第100条の2｜e-Gov 法令検索
システムリスク管理態勢（監督指針）
金融庁の「保険会社向けの総合的な監督指針」は、システムリスク管理態勢を重要な着眼点として挙げています。システムリスクを次のように定義し、態勢の充実強化を求めています。
システムリスクとは、コンピュータシステムのダウン又は誤作動等のシステムの不備等に伴い、顧客や保険会社が損失を被るリスクやコンピュータが不正に使用されることにより顧客や保険会社が損失を被るリスクを言う。（中略）システムが安全かつ安定的に稼動することは保険会社に対する信頼性を確保するための大前提であり、システムリスク管理態勢の充実強化は極めて重要である。
出典：保険会社向けの総合的な監督指針 II-3-13-2｜金融庁
同指針は、システムリスク管理の基本方針に「セキュリティポリシー」と「外部委託先に関する方針」を含めているか、といった点を着眼点として挙げています。開発・運用の設計に、これらの観点を反映することが求められます。
顧客情報の管理と外部委託先の管理
監督指針は、顧客情報の管理についても態勢を求めています。情報へのアクセスは業務上の必要がある役職員に限るという「Need to Know原則」を踏まえ、アクセス管理の徹底や不正アクセスの防御など、情報管理システムの堅牢化を含む対策を挙げています。これらはシステム開発における権限管理・セキュリティ設計に直接関わります。
顧客等に関する情報へのアクセス管理の徹底（略）、内部関係者による顧客等に関する情報の持出しの防止に係る対策、外部からの不正アクセスの防御等情報管理システムの堅牢化などの対策を含め、顧客等に関する情報を適切に管理するための態勢が構築されており（後略）
出典：保険会社向けの総合的な監督指針 II-4-5｜金融庁
開発・保守を外部ベンダーへ委託する場合は、委託先の管理も求められます。監督指針は事務の外部委託について、委託先が十分なサービスを提供できるか、契約に沿ったサービス提供や損害負担が確保できる財務・経営内容か、といった観点での委託先選定を求めています。この着眼点は、後述する依頼先の選び方にも通じます。
出典・参考資料（1件）
個人情報保護法（安全管理措置・委託先の監督）
保険会社・保険代理店はいずれも個人情報取扱事業者にあたり、個人情報の保護に関する法律（個人情報保護法）が適用されます。同法第23条は、取り扱う個人データの漏えい・滅失・毀損の防止その他の安全管理のために必要かつ適切な措置を講じることを求めています。システムのセキュリティ設計は、この安全管理措置を満たす手段の一つになります。
また、同法第25条は、個人データの取扱いを委託する場合に、委託先に対する必要かつ適切な監督を求めています。開発・保守を委託する場面では、発注側にこの委託先監督の義務が生じます。監督指針の外部委託の着眼点と合わせて、委託の管理を要件に織り込む必要があります。
出典：個人情報の保護に関する法律 第23条・第25条｜e-Gov 法令検索
- （第23条）個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。
- （第25条）個人情報取扱事業者は、個人データの取扱いの全部又は一部を委託する場合は、その取扱いを委託された個人データの安全管理が図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならない。
一括ダウンロードする
開発の依頼先（開発会社・ベンダー）の選び方
保険システムの開発は業務が特殊なため、依頼先の見極めが成否を左右します。ここでは、発注先を選ぶ際に確認したい観点を整理します。次の4点を自社の要件と照らし合わせて確認することが、失敗を避けるうえで役立ちます。
- 保険業界での開発実績があるか：保険は業務の独自性が高く、生保・損保・少額短期のいずれを対象にするかで求められる知見も変わります。対象とする分野・業務での開発実績を確認します。
- 対象システムの得意領域が合っているか：基幹系の刷新、営業・申込のオンライン化、代理店業務の効率化など、依頼先によって強い領域は異なります。自社が対象とする範囲と依頼先の得意領域が合っているかを見ます。
- 法規制・セキュリティへの対応と認証：保険業法・監督指針・個人情報保護法への対応をどう担保するかを確認します。情報セキュリティマネジメント（ISO/IEC 27001／ISMS）などの認証取得は、体制を判断する材料の一つになります。
- 導入後の保守・運用体制：保険システムは長期にわたって使い続けるため、開発後の保守・運用を誰がどう担うかが重要です。安定稼働を支える体制と、契約上の責任・報告の取り決めを確認します。
これらの観点は、金融庁の監督指針が外部委託先の選定について挙げる着眼点とも重なります。委託先が十分なサービスを提供できるか、契約に沿った責任・損害負担が確保できるか、といった点を、発注前のベンダー選定に落とし込むと、選定の軸が定まります。
保険システム開発の相談先・解決策
保険システムの相談先は、大きく2つに分かれます。1つは、契約管理や保険金支払いなどの機能をあらかじめ備えたパッケージ・SaaS・基盤製品を導入する方法。もう1つは、開発会社（SIer・受託開発）に要件どおり作ってもらう方法です。ここからは前者にあたる、保険システムの開発・刷新に使える製品・プラットフォームを紹介します。
フルスクラッチでの受託開発や、ホスト・COBOL基幹の大規模移行そのものは、開発会社（SIer）が担う領域です。以下の製品のうち、既存基幹を止めずに上位のAPI層で最新化するもの（モダナイゼーション）や、大手損害保険向けの基幹刷新に対応するものは、移行の相談先にもなります。自社が対象とする範囲（基幹刷新・新規事業の立ち上げ・レガシー移行など）に合わせて検討してください。
以下は、紹介する保険システムの比較表です。
| サービス名 | Graphene・Nano | InsureMO | joinsure | Inspire | Finnova保険・共済トータルサポートシステム | EXEX少額短期保険 | Guidewire InsuranceSuite | INSTANDA |
|---|---|---|---|---|---|---|---|---|
| 提供会社 | リードインクス株式会社 （ソフトバンク100%子会社） | InsureMO株式会社 | 株式会社justInCaseTechnologies | 株式会社Finatext （東証グロース上場グループ傘下） | 株式会社日立システムズ | 株式会社システムエグゼ | Guidewire Software, Inc. （日本法人：ガイドワイア・ソフトウェア・ジャパン） | Instanda Japan株式会社 （英国 F2X GROUP） |
| 提供形態 | PaaS（Graphene） SaaS（Nano） | PaaS／SaaS （クラウドネイティブ、AWS／Azure） | SaaS（クラウド） | SaaS（保険基幹）＋API連携・立ち上げ支援パッケージ | プライベートクラウド（自社データセンター） | クラウドライセンス／サーバライセンス | オンプレミス／クラウド（Guidewire Cloud Platform） | SaaS（クラウド、Azure） |
| 主な対象 | 保険会社（生保・損保・少額短期） | 保険会社（コア最新化）・組込型保険の事業会社 | 保険会社（少額短期・生保・損保） | 保険会社（第一〜第三分野すべて）・組込型保険の事業会社 | 少額短期保険事業者・保険会社（異業種参入含む） | 少額短期保険・共済・中小保険事業者 | 損害保険（P&C）会社の基幹業務 | 保険会社・保険代理店・MGA |
| カバー業務 | 商品開発・契約・保全・保険金支払い | 申込・支払い・契約管理・保険金請求（マイクロサービスAPIで組合せ） | 引受査定・契約管理・保全・収納管理・支払査定 | 見積・申込／査定・契約管理・保全・保険金請求・更改 | 保険基幹（契約・事故・収納）＋代理店システム＋契約者マイページ | Web契約申込＋基幹業務（契約・事故・請求・支払・代理店管理） | 契約管理・引受（PolicyCenter）／保険金支払（ClaimCenter）／収納（BillingCenter） | 商品設計・保険料設定・見積・引受審査・契約／証券発行・保険金請求 |
| 特徴 | 導入形態を3種（インテグレート型／併存型／基幹システム型）から選択。少額短期でNanoを基幹稼働させた実績 | 既存基幹を止めず上位にAPI層を追加する「保険ミドルオフィス」基盤。組込型保険に対応 | 全業務をコアで完結／申込フォームのみ導入し既存連携の2形態。少額短期保険会社などで導入実績 | 提供形態が豊富（包括／Express／Select／少短・共済向け）。API連携で複数社商品を組込み。2025年6月末で13社導入 | 少額短期分野で10年以上の実績（契約数シェア約35%／2020年9月時点・同社調べ）。小規模モデルは初期費用を従来比約1/10 | 少短・共済に特化したパッケージ。専用オーダーシートで申込ページを設定 | 世界40カ国・570社以上が採用する損保（P&C）基幹。国内10社以上の損保が採用し、日本の損保GWPの60%超をClaimCenterで処理（2025年4月公式発表） | ノーコードで保険商品を設定・変更できる。ISO/IEC 27001:2022取得（本体）。米国・英国市場で80社超が利用 |
| 初期費用 | 要問い合わせ | 要問い合わせ | 要問い合わせ | 要問い合わせ | 要問い合わせ | 要問い合わせ | 要問い合わせ | 要問い合わせ |
| 導入期間の目安 | 要問い合わせ | 要問い合わせ | 要問い合わせ | Inspire Express 約8週間 少短・共済向け 最短2週間 | 要問い合わせ | 契約申込 最短3週間 基幹業務 発注から最短6ヶ月 | 要問い合わせ | 要問い合わせ |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
保険会社の基幹システムを製品ごとに絞り込んで比較したい場合は、以下の記事も参考になります。生命保険・損害保険といった業態別の選び方や、導入事例を交えて解説しています。導入を具体的に検討する段階でご覧ください。
1. Graphene・Nano（リードインクス株式会社）
ソフトバンク株式会社の100%子会社であるリードインクス株式会社が提供する、保険会社向けのデジタル保険プラットフォームです。保険商品の開発から契約・保全・保険金支払いまでの保険業務を一つのプラットフォーム上でデジタル化できる構成で、既存システム環境に応じてインテグレート型・併存型・基幹システム型の3つの導入形態から選べます。
製品はPaaS形態のGrapheneとSaaS形態のNanoに区分されており、規模や要件に応じて使い分けます。公式の製品ページでは、新商品の開発期間を「3〜6ヶ月程度」と訴求しています（比較の前提は公表されていないため、実際の期間は要件により異なります）。少額短期保険の会社で、Nanoを基幹システムとして稼働させた実績があります。
2. InsureMO
老朽化した基幹システムを入れ替えずに、その上位にAPI・マイクロサービスの層を追加して新商品や販売チャネルを立ち上げる「保険ミドルオフィス」基盤です。申込・支払い・契約管理・保険金請求などの機能を部品（マイクロサービス）として用意し、API経由で組み合わせて利用します。
基幹システムを止めずに最新化を進めたい保険会社に向くほか、事業会社が自社サービスに保険を組み込む組込型保険にも対応します。グローバルでは50カ国以上・500社超で利用され、年間の処理保険料は250億米ドル超とされています（いずれもグローバル全体の指標）。日本ではNTTデータなどを通じた提供も行われています。
基幹を入れ替えずに上位のAPI層で最新化するという構成に至った背景を、代表取締役の河上氏は次のように語っています。
私たちはもともと、保険会社向けにパッケージ製品を提供していました。当時としては評価いただいていた製品なのですが、モノリシックの仕組みである以上、改修するとあちこちに影響が出ますし、カスタマイズも基本的にしたくないしすべきではない。そうすると、お客様としては「やりたいことができない」「カスタマイズで費用がかかる」「保守が難しい」となってしまうわけです。これは結局、お客様を幸せにしないとCEOが判断しまして、思い切ってそのパッケージは販売停止にしました。そのうえで、マイクロサービスを組み合わせて構築する全く新しいプラットフォームとしてInsureMOを作り直したという経緯です。
3. joinsure（ジョインシュア）
株式会社justInCaseTechnologiesが提供するSaaS型の保険基幹システムです。管理コンソールが引受査定・契約管理・保全・収納管理・支払査定という保険会社の主要業務をカバーし、申込フォームや契約者ポータルなどのフロント機能と組み合わせて利用します。
少額短期保険だけでなく、生命保険・損害保険の業務にも対応する設計です。全業務をコアシステムで完結させるパターンと、申込フォームのみを導入して既存システムと連携するパターンの両方に対応します。少額短期保険会社などでの導入実績があります。
4. Inspire（株式会社Finatext）
株式会社Finatext（東証グロース上場のFinatextホールディングス傘下）が2020年から提供するSaaS型のデジタル保険基幹システムです。第一分野（生命保険）・第二分野（損害保険）・第三分野のすべての保険商品に対応し、見積もり・申込・引受査定・契約管理・保険金請求・更改までを一気通貫でオンライン化します。
導入形態の選択肢が広い点が特徴です。ローコードで立ち上げるInspire Express、機能を単体で導入できるInspire Select、少額短期保険・共済向けの立ち上げ支援パッケージなどを用意しています。API連携により、事業会社が複数の保険会社の商品を自社サービスに組み込む使い方にも対応します。2025年6月末時点で13社に導入されています。
5. Finnova保険・共済トータルサポートシステム（株式会社日立システムズ）
株式会社日立システムズが提供する保険システムパッケージで、保険基幹システム・代理店システム・契約者向けシステムを一つのパッケージで備えます。日立システムズのデータセンター内に構築したプライベートクラウド環境から提供されます。
少額短期保険の分野で10年以上のシステム開発・運用・保守の実績を持ち、少額短期保険の契約数シェアは約35%とされています（2020年9月時点、同社調べ）。機能を絞り、初期導入費用を従来モデルの約10分の1に抑えたという小規模モデルも別途用意しており、少額短期保険会社など小規模な事業者にも対応します。
6. EXEX少額短期保険（株式会社システムエグゼ）
少額短期保険・共済・中小の保険事業者を対象にしたパッケージ型のトータルソリューションです。株式会社システムエグゼが提供し、インターネット経由の契約申込を担う「契約申込onクラウド」と、契約・事故・請求・支払などの基幹業務を担う「基幹業務onクラウド」で構成されます。
導入期間の目安を公表している点が、費用・期間を知りたい発注検討者には参考になります。公式によれば、契約申込は専用オーダーシートの記入で最短3週間、基幹業務は発注から最短6ヶ月での導入が可能とされています。提供形態はクラウドライセンスとサーバライセンスの2種類から選べます。
7. Guidewire InsuranceSuite（ガイドワイア・ソフトウェア・ジャパン株式会社）
損害保険会社の基幹業務（契約管理・引受、保険金支払い、収納）を担うコアアプリケーション群です。米国のGuidewire Softwareが開発し、世界40カ国・570社以上の保険会社が採用しています。日本では2008年から事業を展開し、日本法人のガイドワイア・ソフトウェア・ジャパン株式会社が販売・導入支援を担っています。
国内では大手を含む10社以上の損害保険会社が採用しています。同社の発表によれば、日本の損保の保険料（元受収入保険料、GWP）の60%超が、保険金支払いを担うClaimCenterで処理されています（2025年4月時点、ClaimCenterに関する数値）。
クラウド版への移行や、今後5年間で6,000万米ドルを日本市場に投資する方針も発表しており、大規模な基幹刷新を検討する損害保険会社の相談先になります。
8. INSTANDA（Instanda Japan株式会社）
保険会社・保険代理店・総括代理店（MGA）向けの、クラウドベースのノーコード保険コアプラットフォームです。保険商品の設計・保険料設定・見積・引受審査・契約・証券発行といった業務を、コードを書かずに設定・変更できる点を中核としています。提供形態はSaaSで、Microsoft Azure上でホスティングされます。
2015年に英国で提供が始まり、日本市場へは2022年に参入しています。情報セキュリティマネジメントの国際規格ISO/IEC 27001を取得しており、業務担当者が主体となって保険商品を素早く投入したい事業者に向く選択肢です。
まとめ
保険システムの開発は、基幹・営業支援・代理店系のどの領域を対象にするかを切り分けるところから始まります。契約・収納・保険金支払いといった保険特有の業務、老朽化した基幹の移行、保険業法や金融庁の監督指針への対応が難所になりやすく、これらを要件定義の段階で押さえておくことが、後戻りを防ぐ鍵になります。
検討の進め方としては、まず対象とする範囲（基幹・営業支援・代理店系のどこまで）を切り分けます。次に、その範囲に合う開発方法を選び、保険業法・監督指針・個人情報保護法への対応を要件に落とし込みます。そのうえで複数の相談先から見積もりを取り、内訳まで揃えて比較すると、論点を漏らさず進められます。
開発方法は、パッケージ・SaaSの導入、フルスクラッチ開発、レガシーのマイグレーションで費用・期間・向くケースが異なります。対象範囲を絞り込んだうえで、保険業界での実績・得意領域・法規制対応・保守体制を軸に複数の相談先を比較すると、自社に合った進め方が見えてきます。まずは各サービスの資料を取り寄せ、自社の要件と照らし合わせるところから始めてみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. 保険システム開発とは何ですか？
保険システム開発とは、保険会社や保険代理店が保険事業を運営するために使う業務システムを、新しく構築したり、老朽化した既存システムを刷新したりすることを指します。対象は、契約・収納・保険金支払いなどを担う基幹系、見積・申込などの顧客接点を支える営業支援系、代理店の業務を担う代理店系に大きく分かれます。どの領域を対象にするかを切り分けるところから検討が始まります。
Q. 保険システム開発の費用・期間はどのくらいが目安ですか？
保険システム開発の費用・期間は、対象とする業務範囲・既存システムの状況・カスタマイズの度合いによって大きく変わり、一律の相場を示すことは困難です。受託開発の費用は「開発要員の月額単価 × 工数（人月） × 体制の規模」で積み上がり、基幹系の刷新のように移行を伴う場合は数年単位のプロジェクトになることもあります。
一方、少額短期保険や新規事業の立ち上げでパッケージ・SaaSを利用する場合は、初期費用を抑え導入期間を短くできる傾向があります。まずは対象範囲を絞り込み、複数の相談先から見積もりを取って比較するのが現実的です。
Q. パッケージ・フルスクラッチ・マイグレーションのどれを選べばよいですか？
開発方法は、標準的な業務を早く始めたいならパッケージ・SaaS、独自性の高い商品・業務を要件どおりに作り込みたいならフルスクラッチ、老朽化したホスト・COBOL基幹を刷新するならマイグレーション、が基本的な選び分けです。判断の軸になるのは、対象とする業務範囲、既存システムの状況、かけられる費用と期間の3点です。
すべてを一度に作り替える必要はなく、基幹系だけを刷新する、申込のフロントだけをオンライン化するといった形で対象を絞ると、方法も選びやすくなります。
Q. レガシー化したCOBOL・ホスト基幹はどう刷新すればよいですか？
COBOL・ホスト（メインフレーム）で稼働してきた基幹システムの刷新は、稼働中の業務を止めずに新環境へ切り替える段階的な移行が基本になります。長年の改修で複雑化した既存の業務ロジックを棚卸しし、新環境で同じ処理が再現できるかを検証する作業に相応の工数がかかるためです。
一度にすべてを切り替えるのではなく、業務や商品の単位で区切って移行する計画を立てることが、リスクを抑える鍵になります。生命保険の基幹では数年がかりでホスト基盤からサーバー基盤へ移行を進める例もあり、期間と体制に余裕を持った計画が求められます。
Q. 少額短期保険を新規に立ち上げる場合、システムはどう準備すればよいですか？
少額短期保険の新規立ち上げでは、契約管理・収納・保険金支払いといった基幹業務をあらかじめ備えたパッケージ・SaaS型の保険システムを利用すると、初期費用を抑えつつ短期間で事業を開始しやすくなります。オンラインでの申込受付や契約者向けの機能を短期間で用意できるサービスもあります。
自社独自の業務がある場合は標準機能に合わせる調整が必要になるため、対応業務の範囲と導入期間を各社の資料で確認し、自社の要件と照らし合わせて比較するとよいでしょう。
Q. 保険システム開発で押さえるべき法規制・監督指針は何ですか？
保険システム開発では、機能の作り込みだけでなく、保険業法、金融庁「保険会社向けの総合的な監督指針」、個人情報保護法への対応を、要件定義の段階から織り込む必要があります。保険業法第100条の2は、顧客情報の適正な取扱いと、業務を外部委託する場合の的確な遂行を求めています。
金融庁の監督指針はシステムリスク管理態勢や外部委託先の管理を重要な着眼点として挙げており、開発・保守を委託する場合は発注側にも委託先を監督する義務が生じます。これらは開発の権限管理・セキュリティ設計・ベンダー選定に直接関わります。
Q. 保険システムの開発会社（発注先）はどう選べばよいですか？
保険システムの開発会社は、保険業界での開発実績、自社が対象とする領域（基幹・営業支援・代理店系）と依頼先の得意領域の一致、法規制・セキュリティへの対応、導入後の保守・運用体制の4点で見極めるのが基本です。保険は業務の独自性が高く、生保・損保・少額短期のいずれを対象にするかで必要な知見も変わります。
これらの観点は、金融庁の監督指針が外部委託先の選定について挙げる着眼点（十分なサービスを提供できるか、契約に沿った責任・損害負担が確保できるか）とも重なるため、発注前のベンダー選定の軸に落とし込むと選定がぶれにくくなります。
保険システム・保険会社システムの料金・資料を一括チェック
MCB FinTechカタログでは、保険システムの開発・刷新に対応するサービスの最新資料を無料で一括請求できます。対応業務や導入形態、費用感を比較して、自社に合った相談先を選ぶ判断材料にご活用ください。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
