--- title: "保険基幹システムとは？生保・損保の業務領域とデータモデル・刷新順序を解説" url: "https://www.issoh.co.jp/column/details/17153/" published: 2026-08-30 updated: 2026-08-30 categories: ["業務システム"] publisher: "株式会社一創" --- # 保険基幹システムとは？生保・損保の業務領域とデータモデル・刷新順序を解説 保険基幹システムは、契約の引受から保険料の収納、契約保全、保険金の支払までを一本の台帳でつなぐシステムです。ところが製品カタログを眺めても、契約管理・収納・支払という機能名が並ぶだけで、自社の何をどの順序で切り出せばよいのかは分かりません。この記事で扱うのは、保険会社側の基幹に入っている業務領域を生保と損保で分けた整理、銀行の勘定系との構造的な違い、商品定義と契約・当事者・イベントを分けるデータモデル、パッケージ導入と受託開発を分ける条件、そしてレガシー刷新で先に切り出す領域の順序です。基幹システムそのものの定義は[基幹システムとは？業務システム・ERPとの違いと構成領域](https://www.issoh.co.jp/column/details/12885/)で扱っているため、本記事は保険業に固有の部分に絞ります。 ## まとめ：保険基幹システムの構成整理と刷新順序を決めるまでの判断軸 先に結論を書きます。保険基幹システムは「契約管理」を核として、収納・支払・再保険・代理店手数料が周辺で連動する構造です。刷新の単位は機能名ではなく、この業務領域の切れ目に置いてください。契約管理の本体だけは、最後まで残す前提で計画を組むのが安全です。 生保と損保では設計の前提が違います。生保は1件の契約が数十年にわたって状態を変え続けるため、契約保全の処理系が業務量の中心になる。損保は1年更改の大量計上と代理店経由の情報連携が中心で、手数料計算と再保険の連動が改修頻度を押し上げます。同じ保険基幹でも、どちらの前提で作られたパッケージかで適合度が変わります。 着手を見送る条件も明確です。商品改定と制度対応が同じ年度に重なる時期に、契約管理本体の一括移行を選ぶべきではありません。まず収納と照会の周辺領域を外に出し、支払査定を次に置く。この順序であれば、契約管理本体の判断を先送りしたまま効果を出せます。 ## 保険基幹システムが担う業務領域と、銀行の勘定系との構造的な違い 保険基幹システムを機能一覧で理解しようとすると、どこが本体でどこが周辺かが見えなくなります。処理系の責務から入ります。 ### 契約・収納・支払という3つの処理系が持つデータと責務の分かれ目 中核にあるのは契約ファイルです。誰が、どの商品を、いつから、いくらの保障で契約しているか。この状態の正本を1か所に持ち、他の処理系はそこを参照します。収納は保険料の請求と入金消込を扱い、口座振替・クレジットカード・団体扱いといった経路ごとに未収と過払いの突合を回します。支払は保険金・給付金・満期返戻金の請求受付から査定、送金までを扱う処理系です。 責務の分かれ目は「契約の状態を変える権限を誰が持つか」に現れます。収納の不入金は失効という契約状態の変更につながり、支払の確定は保険金額の減額や契約消滅につながる。つまり周辺の処理系は、契約ファイルに対して状態遷移を要求する側に立ちます。この一方向の関係を崩し、収納側や支払側にも契約状態のコピーを持たせると、突合作業が恒久的に残ります。 責任準備金の計算も契約ファイルを源泉にします。保険業法上、将来の保険金支払に備えて積み立てる金額は契約単位の情報から算出されるため、契約データの粒度が決算処理の精度をそのまま左右する構造です。 ### 勘定系システムとの比較で見える、残高概念と計上タイミングの違い 銀行の勘定系は、口座残高という単一の真値をリアルタイムに更新し続けます。取引が起きた瞬間に残高が確定し、その日のうちに閉じる。対して保険の契約は、締結から数十年にわたって状態を変え続け、しかも決算日時点の債務を計算で求めます。残高が「ある」のではなく「見積もる」対象という点が、根本的な設計差です。 この差は要求される非機能にも出ます。勘定系が即時性と無停止性を最優先するのに対し、保険基幹は遡及訂正の正確さを優先します。3年前の告知内容の誤りが判明したとき、その時点まで遡って契約状態と責任準備金を計算し直せるか。オンライン応答が数百ミリ秒遅いことより、この再計算ができないことのほうが実務では痛い。銀行側の構造は[勘定系システムとは？三層構造と情報系との違い](https://www.issoh.co.jp/column/details/16010/)で整理しています。 ### 基幹システム一般の定義に対して、保険業で追加される制度要件の範囲 製造業や流通業の基幹システムが会計・販売・在庫・生産を束ねるのに対し、保険業では監督法規に基づく計算と報告が処理系の一部として組み込まれます。責任準備金と支払備金の積立、区分経理、ソルベンシー・マージン比率の算出根拠となるデータの保持。これらは「あとから帳票で作る」ものではなく、契約データの持ち方そのものに制約をかけます。 会計基準の側からも要求が来ます。IFRS第17号「保険契約」は2023年1月1日以後に開始する事業年度から適用され、3月決算会社では2024年3月期からの適用となりました。生命保険・損害保険・再保険を含むすべての保険契約が対象で、契約を個別ではなく発行年度・収益性・ポートフォリオの区分によるグループ単位で測定します。既存の契約ファイルが契約単位の情報しか持たず、区分を会計側の集計で作っている場合、刷新時に発行年度と商品区分を契約データの属性として持たせるかどうかが、国際会計基準の任意適用を視野に入れる会社での分岐になります。 ## 生保と損保で分かれる基幹領域の中身と、業務量を押し上げる処理の所在 保険基幹システムという一語でまとめられがちですが、生保と損保では負荷のかかる場所が違います。パッケージ選定を誤る原因の多くがここにあります。 ### 生保の引受プロセス：告知・査定の自動判定を適用できる範囲の線引き 生保の新契約は、申込の受付、告知内容の確認、査定、成立、証券発行という順に進みます。自動判定を入れる余地が最も大きいのは、告知内容が基準の範囲に収まり、保険金額が一定額以下の申込です。年齢と保険金額の組み合わせで診査の要否を決めるルールは、そもそも規程として明文化されているため、システム化しやすい。 逆に、既往症の申告があるケースや高額契約は自動判定から外します。医的な判断が入る領域を無理にルール化すると、例外条件が増え続けて保守できなくなるためです。自動成立の比率を最初から高く狙わず、査定担当者の判断が分かれない範囲だけを機械に任せる順序で線を引いてください。 ### 契約保全（異動・貸付・失効復活）が業務量を押し上げる構造と滞留点 生保の基幹で最も件数が出るのは、新契約ではなく契約保全です。住所変更、受取人変更、保険金額の減額、契約者貸付、払済・延長への変更、失効と復活。これらはすべて契約状態の遷移であり、遷移のたびに責任準備金と保険料が再計算されます。 滞留が起きるのは、遷移の組み合わせを事前に定義しきれない箇所です。貸付残高がある契約の失効、復活時の未払保険料の充当、減額と受取人変更が同日に届いたときの適用順序。こうした複合ケースを画面で処理できず紙の申請書に戻すと、そこだけ手作業が残ります。刷新時は、件数の多い単純な遷移よりも、この複合ケースの網羅性を評価軸にしてください。 ### 損保の契約計上と代理店経由の情報連携で生じる二重入力の解消方法 損害保険業界のシステムは、代理店側のシステム、損保VANを介した業界共通の通信基盤、保険会社の個社システムという3層で成り立っています。代理店が計上した契約情報が業界共通の経路を通って保険会社へ流れ、自動車保険の等級情報などについては損害保険料率算出機構との接続も加わる構造です。 二重入力が発生するのは、代理店側の入力項目と個社の計上項目がずれている場合です。解消の方向は2つしかありません。個社側の項目を業界標準の範囲に寄せるか、代理店側で入力した内容を計上データへ機械的に変換する層を挟むか。前者は商品の独自性を削るため、実務では後者を選ぶことが多い。代理店側で使う業務システムの機能差は[保険代理店システムの比較｜満期・手数料計算で選ぶ判断軸](https://www.issoh.co.jp/column/details/16713/)で整理しています。 ### 再保険の出再と回収が保険金支払と会計処理へ波及する経路の設計 再保険は、引き受けたリスクの一部を他社へ移す仕組みです。契約単位で出再割合が決まる比例再保険と、一定額を超える損害を対象とする非比例再保険では、システム側の持ち方が変わります。前者は契約ごとに出再先と割合を保持できますが、後者は個別契約ではなく損害の集積単位で判定するため、支払データを別の切り口で集計する処理が必要になる。 ここを軽く見ると、保険金支払の実装が終わってから会計連携で作り直しになります。支払が確定した時点で出再先への回収債権が立ち、決算では回収可能性の評価まで入る。要件定義の段階で、支払処理と再保険処理と会計処理の3者が同じ識別子でつながる設計にしておく必要があります。再保険のスキームを理解しないまま要件を切ると、この連鎖が見えません。 ## 保険基幹システムのデータモデル：商品・当事者・契約・イベントの分け方 刷新後に改修費が下がるかどうかは、機能ではなくデータモデルで決まります。分けるべき軸は4つです。 ### 商品定義をコードに埋め込まない商品ファクトリ方式と改修コストの差 旧来の保険基幹では、商品ごとにプログラムが枝分かれしています。定期保険の計算ロジック、医療保険の給付判定、特約の付加ルール。これらが個別のモジュールとして実装されていると、新商品の追加が毎回開発案件になります。生命保険会社の基幹システムが新商品開発や新チャネル追加のたびに大きなコストを要すると指摘されてきたのは、この構造が理由です。 対する商品ファクトリ方式は、保険料率表・給付条件・特約の組み合わせ規則をデータとして外に出し、共通のエンジンが解釈します。新商品はパラメータの登録で組み立てる。実装の手間は初期に寄りますが、改定が年に何度も走る会社ほど回収が早い。判断の目安は、直近3年間で商品改定にかかった開発費が、基幹の年間保守費と同じ桁に達しているかどうかです。 ### 契約・当事者・イベントを分離して持つ設計が遡及訂正に効く理由 契約者、被保険者、受取人、代理店、支払先。保険では1つの契約に複数の人が別々の役割で結び付きます。これを契約レコードの項目として持つと、同一人物が複数契約に登場したときに名寄せができず、受取人変更のたびに全契約を横断する更新が走ります。当事者を独立した実体として持ち、契約との関係を役割付きで結ぶ形にすれば、変更は関係側の1行で済む。 もう1つがイベントの持ち方です。異動・支払・入金といった出来事を履歴として残し、契約の現在状態はその積み上げとして導出できる形にしておくと、遡及訂正が「過去のイベントを訂正して再計算」で表現できます。現在値だけを上書きする設計では、3年前に遡った訂正が事実上できなくなり、手計算とデータ修正で埋める運用が残ります。 ## パッケージ導入と受託開発を分ける4つの条件と、費用構造の見え方の差 保険基幹のパッケージは、生保向け・損保向け・少額短期保険向けで作りが分かれています。どちらを選ぶかは規模ではなく、次の条件で決まります。 ### 商品数・改定頻度・チャネル構成から見るパッケージ適合の境界線 パッケージが適合しやすいのは、商品数が絞られ、販売チャネルが代理店または直販のどちらかに寄っている会社です。標準機能に業務を寄せる余地があるため、カスタマイズ比率を抑えられます。少額短期保険業者のように商品構成が単純で件数が多い領域は、パッケージの適合度が高い。 境界を越えるのは、独自の特約体系を持ち、改定が年に複数回走り、代理店・直販・銀行窓販・Webが並走している場合です。この構成ではパッケージの標準機能から外れる要件が積み上がり、カスタマイズが半分を超えたあたりで、パッケージを土台にする利点が消えます。判断の分かれ目は、要件のうち標準機能で満たせる比率が7割を切るかどうかに置くと現実的です。 ### 費用構造の違い：ライセンス費と追加開発費で総額の見え方が変わる仕組み 見積書の総額だけを比べると、判断を誤ります。費用の出方が構造的に違うためです。 | 比較の観点 | パッケージ導入 | 個別の受託開発 | | --------- | ------------- | ----------- | | 初期費用の内訳 | ライセンス＋設定＋追加開発 | 要件定義から一括 | | 商品改定時の改修 | 定義変更で吸収できる範囲 | 都度の開発案件になる | | 制度改正への追随 | ベンダー側の標準対応 | 自社で個別に対応 | | 5年間の総額の傾向 | 保守料が毎年積み上がる | 初期が重く保守は圧縮可 | | 業務要件の自由度 | 標準機能に業務を寄せる | 既存業務をそのまま実装 | 比較するなら、5年間の総支出で並べてください。パッケージは初期が軽く見えても、ライセンスと保守が毎年発生し、標準対応の範囲外の改定は別途見積になります。改定が年3回以上ある会社ではパッケージ側が有利に振れ、商品構成が10年単位で変わらない領域では、初期が重くても保守の積み上がらない受託側が下回ります。 ### 外部へ切り出す範囲を決めるときに確認しておく体制と業務知識の所在 保険基幹の要件は、業務規程と監督法規の知識がないと書けません。責任準備金の計算方法、失効復活の取扱い、再保険のスキーム。この理解が欠けたまま要件定義に入ると、外部接続先の洗い出し漏れと計算仕様の誤りが後工程で顕在化します。発注側で押さえるべきは、業務規程を説明できる担当者を各領域に1人ずつ確保することです。 委託先に求める条件は、保険業務の経験より「既存システムの解析ができるか」を先に見てください。刷新案件の初期作業は、動いている旧システムから仕様を読み取る作業が大半を占めます。金融領域の要件と外注先の選び方は[金融・公共・流通系のシステム開発とは？業界特化の要件と外注先の選び方](https://www.issoh.co.jp/column/details/12888/)にまとめており、保険基幹の周辺システムや参照系の開発をどこまで外に出すかを検討する段階であれば、[金融システム開発](https://www.issoh.co.jp/service/business%5Fsystem/financial/)のような業種特化の受託開発で範囲を区切って相談する進め方もあります。 ## レガシー刷新で先に切り出す領域の順序と、一括移行を選ばない条件 刷新の失敗は、技術選定ではなく順序の設計で起きます。ここは判断を言い切ります。 ### 収納と照会から切り出し、支払査定を次に置く順序が成り立つ根拠 着手順は、契約状態を書き換える度合いが低い領域から並べます。実務で成立する順序は次の通りです。 1. 参照系と契約者向け照会：契約データの複製を受けるだけで、本体を変更しない 2. 保険料収納：入金消込の結果を契約側へ返すが、状態遷移は失効判定に限られる 3. 保険金・給付金の支払査定：請求受付と査定の判断支援から着手し、送金は後回しにできる 4. 契約保全：状態遷移の中核で、複合ケースの網羅が前提になる 5. 契約管理本体と責任準備金計算：最後に置く この順序が成り立つ根拠は、前段ほど旧システムとの併存期間に耐えられる点にあります。参照系は日次連携で成立し、収納は締め日単位で突合できる。逆に契約保全から着手すると、新旧どちらが契約状態の正本かという問題が初日から発生します。 ### 契約管理本体の一括移行を選ばない条件と、並行稼働の期間の置き方 契約管理本体を一度に入れ替える方式は、既存契約の件数が数十万件を超え、かつ商品体系が10年以上にわたって積み上がっている会社では選びません。移行対象に、すでに販売を終了した商品の契約が大量に残っているからです。販売停止済みの商品は新システムで再現する価値が薄いのに、契約が生きている限り計算ロジックを移植せざるを得ない。 現実的な解は、販売中の商品を新基幹へ寄せ、販売停止済みの契約は旧システムに残して自然減を待つ並行稼働です。期間は、残存契約の満了状況から逆算します。定期保険中心なら5年程度で大半が消えますが、終身の契約が残る会社では10年を超える前提で保守体制を組む必要がある。並行期間中は、契約者からの照会に両系統を横断して答えられる参照系を先に用意しておくことが条件になります。 ### 刷新の着手を見送る場面：商品改定と制度対応が重なる時期の判断 着手すべきでない時期があります。期日が決まった制度対応と、商品改定の山が同じ年度に重なる場合です。2026年6月1日施行の改正保険業法のように施行日が定まっている対応は、遅らせるという選択肢がありません。ここに刷新の移行判定を重ねると、限られた業務部門の人員を奪い合い、両方が遅れます。 もう1つの見送り条件は、現行システムの仕様書が失われ、稼働中のコードしか手掛かりがない状態で、解析期間を確保せずに開発を始めようとする場合です。この状態で一括移行を選ぶと、テスト工程に入ってから未知の業務ルールが次々に見つかります。解析だけで半年を計画に積めないなら、その年度は参照系の切り出しにとどめ、本体には手を付けないほうが結果的に早い。大手損害保険会社でも、自動車保険の基幹システム刷新の完了を公表するまでに長い期間を要しており、2024年11月27日付の公表資料がその一例です。 ## 刷新の要件定義前に確認する制度対応と外部接続先の洗い出し範囲 要件定義の初期に洗い出しを終えていない項目は、後工程でそのまま遅延になります。優先して確認する2点を挙げます。 ### 2026年6月1日施行の改正保険業法で、基幹側に及ぶ体制整備の範囲 2025年6月6日に公布された改正保険業法は、2026年6月1日から施行されます。特定大規模乗合損害保険代理店に対する体制整備義務の強化、兼業代理店の業務管理体制の整備義務の強化、保険契約の締結等に関する禁止行為の範囲拡大、保険仲立人の変更届出義務の対象追加が主な内容です。 義務の名宛人は代理店側ですが、保険会社の基幹にも影響が及びます。代理店の管理体制を確認する立場として、募集人の登録状況や乗合状況、苦情の受付記録を保険会社側で把握する必要が出るためです。刷新の要件に、代理店・募集人の管理情報と苦情記録の保持を含めるかどうかは、施行日前に決めておく項目になります。 ### 要件定義の初期に外部接続先を洗い出す作業の進め方と抜けやすい経路 抜けやすいのは、業務部門が日常的に意識していない経路です。 - 損保VANを介した業界共通システムとの接続と、損害保険料率算出機構への情報提供 - 金融機関との口座振替・団体扱いの授受データと、保険料控除証明の出力経路 - 再保険会社との出再・回収の精算データ - 銀行窓販・提携チャネル向けの契約情報の連携 - コールセンターや契約者向けWebが参照している既存インタフェース 進め方としては、機能一覧からではなく、稼働中システムのジョブ定義とファイル授受の一覧から洗い出してください。業務部門への聞き取りだけでは、年に1回しか動かない経路が漏れます。基幹システム全体の刷新の進め方は[基幹システムとは？構成領域と刷新の進め方](https://www.issoh.co.jp/column/details/12885/)で扱っており、保険業ではそこに監督法規と業界共通インフラへの接続が加わる、という位置付けで読むと整理しやすくなります。 ## よくある質問 保険基幹システムの検討でよく挙がる質問に答えます。 ### 保険基幹システムとは具体的に何を指しますか？ 保険会社が契約の引受から保険料の収納、契約保全、保険金・給付金の支払までを処理する中核システムを指します。生命保険では新契約・契約保全・収納・支払・顧客情報管理が、損害保険では代理店連携・契約計上・収納・支払・再保険が主な構成領域です。責任準備金の計算など監督法規に基づく処理も含まれます。契約情報の正本を保持する点が、周辺の情報系やチャネル系システムとの違いです。 ### 保険基幹システムの刷新にはどのくらいの期間がかかりますか？ 領域と方式で大きく変わります。参照系や契約者向け照会の切り出しであれば半年から1年程度で成立しますが、契約管理本体を含む刷新では、現行システムの解析だけで半年前後を見込む必要が出てきます。既存契約を旧システムに残す並行稼働を選ぶ場合、保守が必要な期間は残存契約の満了状況で決まり、終身保険が残る会社なら10年を超える前提で見てください。 ### クラウド型の保険基幹サービスは選択肢になりますか？ 商品構成が単純で件数の伸びが読みにくい領域、とくに少額短期保険では選択肢になります。初期の設備投資を抑えられ、契約件数の変動にも合わせやすいためです。確認すべきは、商品定義をどこまで自社で変更できるか、契約データを他システムへ渡す経路と形式が用意されているか、監督当局への報告データを自社で組み立てられるかの3点です。この3つが制約される契約条件なら、刷新後の身動きが取れなくなります。 ### 少額短期保険業者でも同じ構成の基幹システムが必要ですか？ 同じ構成は必要ありません。商品構成が単純で契約期間も短いため、契約保全の複合ケースや再保険の連動が発生しにくく、パッケージの標準機能で収まる比率が高くなります。優先すべきは、契約件数の多さに耐える収納処理と、Web経由の申込から計上までを止めずに流す経路の設計です。 ### 保険会社の基幹システムと保険代理店のシステムは何が違いますか？ 扱う情報の正本が違います。保険会社の基幹は契約の正本と責任準備金を保持し、監督法規に基づく計算と報告を担います。代理店側のシステムは、自社が扱う顧客と契約の管理、満期対応、募集人とコンプライアンスの管理、手数料の照合が中心です。両者は業界共通の通信基盤を介してつながり、代理店で計上された情報が保険会社側へ流れる関係にあります。 ## 関連記事 - [基幹システムとは？業務システム・ERPとの違いと構成領域・刷新の進め方を解説](https://www.issoh.co.jp/column/details/12885/)：業種横断で基幹システムの構成と刷新手順を扱っています - [勘定系システムとは？三層構造と情報系との違い・オープン化の判断を解説](https://www.issoh.co.jp/column/details/16010/)：銀行側の基幹構造との比較材料になります - [保険代理店システムの比較｜満期・手数料計算と2026年改正保険業法対応で選ぶ判断軸](https://www.issoh.co.jp/column/details/16713/)：代理店側の業務システムを製品単位で比較しています - [金融・公共・流通系のシステム開発とは？業界特化の要件と外注先の選び方](https://www.issoh.co.jp/column/details/12888/)：業界特化の要件と委託先選定の観点を整理しています - [業務システムとは？種類・基幹システムとの違いと開発・導入形態の選び方](https://www.issoh.co.jp/column/details/12886/)：基幹と周辺の業務システムの線引きを扱っています --- 出典: [保険基幹システムとは？生保・損保の業務領域とデータモデル・刷新順序を解説]()（株式会社一創）