プロローグ — 30年もののCOBOLが朝4時に止まった日

2026年初め、韓国の大手損害保険会社IT室のチャットルームに朝4時17分のメッセージが浮かんだ。

「PG決済バッチがまた止まった。AS-400上のRPGコードが新しい決済コード長を受け付けない。書いた人は2008年に退職している。コメントが日本語だ」

この一行が2026年の保険会社コアシステム市場の一断面を見せている。保険は最も保守的なIT産業であり、保険ポリシーデータは25〜30年生きなければならない(生命保険は生涯)。だから1990年代のメインフレーム上で書かれたコアが2026年まで生き残った。そしてそれを書いた人たちはもう引退した。

この記事は2026年の保険コアシステム市場の全体地図を描く。グローバルP&C(Property & Casualty)コアの代表格Guidewireがどう市場を制したか、Duck Creek TechnologiesがIPO後どうSaaSへ転換したか、Sapiens・Insurity・EIS・Majescoがそれぞれどんな位置を占めるか。クレーム専門のFINEOS、リスク管理のOrigami Risk、MGA・インディ保険会社向けのBritecoreまで。そして韓国Samsung SDSの保険IT、KBライフのCIS事例、日本のNTT DataとNRI ZAITASの30年の軌跡を一緒に見る。

第1章 · 保険会社コアシステムとは何か — 一文の定義

まず定義。**保険会社コアシステム(insurance core system)とは、保険商品のライフサイクル全体(ポリシー発行・アンダーライティング・料率算定・クレーム処理・支払い・請求)を扱う基幹システム群のまとまりである。**

伝統的に保険コアは三つの中核モジュールに分かれる。

- **PAS (Policy Administration System)** — ポリシー発行、更新、裏書き(endorsement)、満期処理。保険の心臓。

- **Claims System** — 事故受付、調査、合意、支払い。損害率を決めるもっとも大きなコストセンター。

- **Billing System** — 保険料請求、収納、分納、返金。キャッシュフローの背骨。

ここにアンダーライティングワークステーション、料率エンジン(rating engine)、再保険(reinsurance)システム、チャネル(エージェント/ブローカー)ポータル、顧客セルフサービスが取り囲む。保険会社が30年のポリシーを発行すれば、そのポリシーデータ・クレーム履歴・支払い記録が30年間コアの中で生きていなければならない。これが保険コアがメインフレームに閉じ込められていた核心的な理由だ。

2026年の市場は二つの流れに分かれる。**グローバルP&Cコア**(Guidewire・Duck Creek・Sapiens・Insurity・EIS)と**Life & Annuityコア**(Sapiens CoreSuite・OIPA・Majesco L&A・Equisoft)。クレーム専門エンジン(FINEOS・Origami Risk)が別の席を占め、MGA/インディ保険会社向けの次世代(Britecore・Socotra)が新しいlayerを作る。

第2章 · P&C vs Life & Annuity — コア構造の本質的差異

保険コアを理解するにはP&CとL&Aの構造差異からつかむ必要がある。二つの領域はビジネスモデルが違い、したがってコアのデータモデルも完全に違う。

**P&C (Property & Casualty)** — 損害保険。自動車、住宅、傷害、賠償責任。ポリシー期間が短く(通常6ヶ月〜1年)、更新サイクルが速く、クレームが頻繁で多様。料率算定が毎年市場変動を反映し、保険金支払額が定められた限度内で事故損害に比例する。

**L&A (Life & Annuity)** — 生命保険・年金。ポリシー期間が生涯(生命保険)または数十年(年金)。保険金が死亡・解約・満期のような特定イベントに応じて支払われ、責任準備金(reserve)計算・予定利率・死亡率表(mortality table)が中心。30年後に支払う保険金を予め積み立てる必要がある。

| 項目 | P&C | L&A |

| --- | --- | --- |

| ポリシー期間 | 6ヶ月〜1年 | 生涯〜数十年 |

| 中核データ | リスク要因・クレーム履歴 | 責任準備金・予定利率 |

| クレーム頻度 | 高い | 低い (死亡・満期) |

| 料率変動 | 毎年 | ほぼ無し |

| 代表コア | Guidewire・Duck Creek | Sapiens CoreSuite・OIPA |

| 中核表 | 事故統計表 | 死亡率表・生命表 |

この構造差異がコアシステム市場の分岐を作る。GuidewireとDuck CreekはP&Cに集中し市場を二分し、Life & Annuityはよりfragmentedされた市場(Oracle OIPA・Sapiens CoreSuite・Majesco L&A・Equisoft)だ。

第3章 · Guidewire InsuranceSuite — P&Cコアの事実上の標準

Guidewire(2001年創業、2012年NYSE IPO、本社San Mateo)は2026年P&Cコア市場の事実上の標準だ。グローバル上位P&C保険会社の50%+がGuidewireをコアに使う。Travelers、Nationwide、Liberty Mutual、Zurich、AXA、Allianzなど。

Guidewire InsuranceSuiteは三つのメイン製品で構成される。

- **PolicyCenter** — ポリシー管理。商品カタログ、料率計算、ポリシー発行・更新・裏書き。

- **ClaimCenter** — クレーム管理。事故受付、FNOL(First Notice of Loss)、調査ワークフロー、支払い。

- **BillingCenter** — 請求・収納。保険料請求、決済、分納、返金。

ここにInsuranceNow(小規模保険会社向け統合SaaS)、DataHub(データウェアハウス)、InfoCenter(分析・BI)、CustomerEngage(顧客ポータル)、ProducerEngage(エージェントポータル)が取り囲む。2020年以降**Guidewire Cloud Platform**として統合SaaS化が進行中で、2026年現在新規顧客の90%+がクラウドオプションを選択する。

// Guidewire Gosu — PolicyCenter料率算定ルール (GosuはGuidewire専用JVM言語)

// 自動車保険 — 運転者年齢と事故歴による保険料調整

package rules.PersonalAuto

uses gw.api.system.PCLoggerCategory

uses entity.PersonalAutoLine

uses entity.PolicyPeriod

class AutoRatingRule {

function calculateBasePremium(period : PolicyPeriod) : java.math.BigDecimal {

var line = period.PersonalAutoLine

var driver = line.PersonalVehicles.first().Drivers.first()

var basePremium = 1200bd // 基本保険料

// 年齢係数

var ageFactor = driver.Age < 25 ? 1.5bd

: driver.Age < 65 ? 1.0bd

: 1.2bd

// 事故歴係数 — 直近3年の事故件数

var claimsCount = driver.PriorClaims.where(

\c -> c.AccidentDate > java.time.LocalDate.now().minusYears(3)

).Count

var claimsFactor = 1.0bd + (claimsCount * 0.3bd)

return basePremium * ageFactor * claimsFactor

}

}

Guidewireの強みは**商品の深さ**だ。30年間保険会社と一緒に進化しP&Cのほぼ全ての変種(自動車・住宅・商業・海上・労災)を全てサポートする。短所は価格が高く(ライセンス + 実装コンサルティング合計で数千万〜数億ドル)、実装期間が長く(通常2〜4年)、Gosuという独自言語の学習曲線があること。

第4章 · Guidewire Cloud Platform — 2030年80%クラウド目標

Guidewireは2020年から**Guidewire Cloud Platform(GWCP)**として全面クラウド転換を宣言した。AWS上に構築されたマルチテナントSaaSで、2026年現在新規売上の90%+がクラウドだ。CEOのMike Rosenbaumが2025年の決算コールで「2030年までに全顧客の80%をクラウドへ移すのが目標」と発表した。

GWCPのアーキテクチャは三つのレイヤーで構成される。

- **InsuranceSuite Cloud Service** — PolicyCenter・ClaimCenter・BillingCenterのSaaS版。AWSマルチAZデプロイ、自動バックアップ・DR。

- **Cloud Console** — 保険会社ITが自分のインスタンスを管理(デプロイ・モニタリング・アクセス制御)。

- **Marketplace** — 700+統合コンポーネント(他社インテリジェンス・税金計算・災害モデリング等)。

マイグレーションパスは通常三段階。(1) On-prem InsuranceSuiteをlift-and-shiftでAWSへ載せる。(2) Guidewire Cloud Platformへ再プラットフォーム化(Cloud API活用、ContentLib・Studioでカスタマイズを分離)。(3) Guidewireが提供するCloud Serviceへ完全転換(コードとデータをGuidewireマルチテナントへ移管)。

2026年時点でグローバルトップ3 P&C(Travelers・Nationwide・Liberty Mutual)が段階3に到達。韓国はまだ段階1〜2の間が多数で、日本はSOMPO・東京海上が段階2マイグレーション中。

第5章 · Duck Creek Technologies — IPO後のSaaS転換の分岐点

Duck Creek(1990年代Accenture内部部門としてスタート、2016年分社、2020年NYSE IPO、2023年Vista Equity Partnersに非公開買収)はGuidewireのもっとも直接的な競合だ。2026年時点でグローバルP&C市場シェア2位。

Duck Creek **OnDemand** がクラウドネイティブSaaSプラットフォームの名前で、三つのメイン製品で構成される。

- **Duck Creek Policy** — Guidewire PolicyCenter対応。

- **Duck Creek Claims** — ClaimCenter対応。

- **Duck Creek Billing** — BillingCenter対応。

ここにDuck Creek Rating、Duck Creek Reinsurance、Duck Creek Producerが取り囲む。

<!-- Duck Creek Policy — Author定義 (XMLベースのビジュアルルール) -->

<!-- 住宅保険 — 補償限度自動調整ルール -->

Duck Creekの差別点は**Authorビジュアル開発ツール**だ。GuidewireがGosuコードでルールを書くなら、Duck CreekはXML/ビジュアルエディタでルールを書く。したがって非開発者(保険商品マネージャー・アンダーライター)がルールを直接修正する自給率が高い。短所は複雑な分岐ロジックでXMLボリュームが爆発すること。

2023年Vista Equity Partners非公開買収以降、Duck CreekはSaaS売上比率を急速に伸ばし、2026年現在80%+がOnDemand SaaSだ。単純な商品・中小保険会社でDuck Creekが強いという評価がある。

第6章 · Sapiens IDIT & CoreSuite — グローバルマルチラインの精髄

Sapiens(イスラエル本社、1982年創業、NASDAQ上場)はP&CとLife & Annuityを両方扱うmulti-line保険コアの代表格だ。グローバル600+保険会社にデプロイされており、特にヨーロッパ・アジア・アフリカ市場で強い。

Sapiensの二つのメイン製品を区別する必要がある。

- **Sapiens IDIT** — P&Cコア。東南アジア・南米新興市場で強いP&Cフルスタックソリューション。

- **Sapiens CoreSuite for L&P** — Life & Pensionsコア。英国・欧州市場で大手保険会社が導入。

ここにSapiens DigitalSuite(顧客ポータル・エージェントチャネル)、Sapiens Decision(ルールエンジン)、Sapiens Reinsuranceが取り囲む。

Sapiens IDIT — 商品設定YAML (low-code構成)

自動車保険商品定義 — 新規市場ローンチ

product:

name: AutoComprehensive2026

line_of_business: PersonalAuto

effective_date: 2026-01-01

base_premium:

method: TerritoryBasedRating

factors:

- territory_code # 都道府県別事故率

- vehicle_class # 乗用・SUV・トラック

- driver_age_band # 21-25, 26-65, 65+

coverages:

- code: BI # Bodily Injury

limits: [100000, 300000, 500000]

default_limit: 300000

- code: PD # Property Damage

limits: [50000, 100000, 250000]

default_limit: 100000

- code: COMP # Comprehensive

deductibles: [500, 1000, 2500]

optional: true

underwriting_rules:

- rule_id: AGE_LIMIT

condition: "driver.age < 21 OR driver.age > 75"

action: REFER_TO_UNDERWRITER

- rule_id: PRIOR_LOSSES

condition: "driver.prior_claims_3yr >= 3"

action: DECLINE

Sapiensの強みは**グローバル多国対応**だ。一つのコア上で50+カ国の規制・通貨・言語を扱うように設計されている。Allianz・Generaliのような欧州多国籍保険会社がSapiensでコアを統合した事例が多い。短所はGuidewireほどの米国P&Cの深さがなく、UI/UXが相対的に古いという評価。

第7章 · Insurity — 米国中小保険会社の専門

Insurity(2000年代の合併で形成、GTCRプライベートエクイティ所有)は米国中小P&C保険会社市場の強者だ。売上規模はGuidewire・Duck Creekより小さいが、200+保険会社の顧客基盤を持ち、特にspecialtyライン(商業保険・海上・農作物保険)で強い。

Insurityの主要製品群は三つ。

- **Insurity Policy Decisions Suite** — ポリシー・料率統合プラットフォーム。

- **Insurity Claims Decisions Suite** — クレームワークフロー。

- **Insurity SpatialKey** — 地理空間分析(ハリケーン・洪水リスク評価)。

2022〜2024年の間にInsurityがSpatialKey、Tropics、ISCSのようなspecialty企業を連続買収しspecialty保険コアのほぼ全てのlayerを保有する。米国農作物保険(crop insurance)ではInsurityが事実上の標準に近い。

Insurityのクラウド版は**Insurity Cloud Platform**で、AWSベースのマルチテナントSaaSだ。2026年基準で新規売上の70%+がクラウド。

第8章 · EIS Suite — デジタル保険会社のためのコア

EIS Group(1996年創業、本社サンフランシスコ)は後発だが急速に成長中。中核メッセージは「**デジタルネイティブ保険会社のためのコア**」 — 最初からAPI-first、microservices、event-drivenで設計された。

EIS SuiteはP&CとL&Aを両方扱う統合プラットフォームで、五つの中核コンポーネントで構成される。

- **PolicyCore** — ポリシー管理。

- **ClaimCore** — クレーム管理。

- **BillingCore** — 請求・収納。

- **CustomerCore** — 360度顧客ビュー。

- **EngageCore** — オムニチャネル顧客インタラクション。

EISの差別点は**イベント駆動アーキテクチャ**だ。全てのビジネスイベント(ポリシー発行・クレーム登録・保険料収納)がKafkaトピックへ発行され、他のモジュールが購読して反応する。したがって保険会社が自分の分析・CRM・外部システムとコアを結合しやすい。

{

"event_type": "policy.bound",

"event_id": "evt_2026_05_25_a7f9e",

"occurred_at": "2026-05-25T14:32:18.420Z",

"actor": {"user_id": "agent_445", "role": "agent"},

"tenant_id": "carrier_acme_insurance",

"payload": {

"policy_id": "POL-2026-009834",

"product": "AutoPersonal",

"policyholder_id": "cust_8723",

"effective_date": "2026-06-01",

"expiration_date": "2027-06-01",

"annual_premium": 1487.50,

"currency": "USD",

"coverages": [

{"code": "BI", "limit": 300000},

{"code": "PD", "limit": 100000},

{"code": "COMP", "deductible": 1000}

]

},

"schema_version": "2.3.0"

}

EISはデジタルインディ保険会社(insurtech)とよく合い、伝統的大手保険会社よりも新規参入する保険会社・既存保険会社の新規デジタルブランドでの採用事例が多い。Allstate North Light(デジタルD2Cブランド)がEIS導入事例として有名だ。

第9章 · Majesco — クラウドネイティブマルチライン

Majesco(2014年Mastek Insuranceから分社、2020年Thoma Bravoに非公開買収)はP&CとL&A両方で立場を確保したミドルマーケットコア供給者だ。インド・米国にR&D拠点があり、グローバル200+保険会社の顧客。

Majescoの主要製品群は三つ。

- **Majesco P&C Core Suite** — P&Cポリシー・クレーム・請求計算。

- **Majesco L&A Core Suite** — Life & Annuityポリシー管理。

- **Majesco Distribution Management** — エージェント・ブローカーチャネル。

差別点は**Microsoft Azure深層統合**だ。AWSベースのGuidewire・Duck Creekと違いMajescoはAzure上に深く統合されており、Power BI・Dynamics 365と一緒に使うシナリオが多い。Microsoftベースのインフラを持つ保険会社に適合。

価格帯がGuidewire・Duck Creekより安いのでミドルマーケット保険会社(売上`$1B`〜`$5B`程度)に適合するという評価が多い。

第10章 · FINEOS Claims — クレーム専門エンジンの席

FINEOS(1993年アイルランドダブリン創業、2019年ASX上場)はクレーム管理専門エンジンだ。フルスタックコアではなく**クレーム・労災・障害保険**に特化されている。

FINEOSの主要製品は三つ。

- **FINEOS Claims** — 団体保険・労災クレーム。

- **FINEOS AdminSuite** — ポリシー管理(L&A補助)。

- **FINEOS Engage** — 顧客セルフサービスポータル。

FINEOSの強みは**長期障害・労災(disability and workers' comp)**の深さだ。この領域は一度事故が起きるとクレームが5〜30年続くこともあり、一般P&Cコアでは扱いにくい。FINEOSはこれを最初からデータモデルで扱う。

FINEOS Claimsの典型的なクレームライフサイクルはFNOL(First Notice of Loss) → Intake Validation → Claim Type分岐(Disability・Workers Comp・Group Life)で始まる。Disabilityクレームなら医療証拠収集が続き、Workers Compなら雇用主検証が、Group Lifeなら受益者確認が進む。次にadjudication(判定) → 承認時に支払い開始 + 定期再検討、却下時に異議申立て手続きへつながる。長期クレームは定期再検討を経ながら5〜30年間システムの中で生きている。

FINEOSの2026年時点の主要顧客はグローバル団体保険会社 — Unum、MetLife、Sun Life、Aflac。韓国・日本の市場シェアは低いが、グローバル団体保険市場の事実上の標準の一つとして位置を確立した。

第11章 · Origami Risk — リスク管理と自家保険市場

Origami Risk(2009年シカゴ創業)は伝統的コアシステムと毛色が違う。**リスク管理情報システム(RMIS, Risk Management Information System)**の領域で、主な顧客は自家保険を運営する大企業・政府・病院のような組織だ。

Origamiの差別点は**大規模自家保険(self-insured)**のワークフローを深く扱う点だ。グローバル大企業が自家保険を運営すると — 従業員労災・財物損害・一般賠償責任を外部保険会社の代わりに自家で処理する — そのクレームを追跡・管理・分析するシステムが必要だ。その領域でOrigamiがシェアが高い。

2024〜2025年OrigamiがClearRisk・CatalystのようなGRC企業を買収しクレーム管理からGRC(Governance, Risk, Compliance)へ拡張した。

第12章 · Britecore & Socotra — MGA・インディ保険会社向け次世代コア

Britecore(2008年創業、Intellect Design Arena子会社として合併)とSocotra(2014年Y Combinator出身、2024年EIS Group買収)は次世代P&Cコアの新しいlayerだ。中核メッセージは「**クラウドネイティブ、API-first、30日以内に保険商品ローンチ**」。

Britecoreの強みは**MGA(Managing General Agent)と小規模保険会社**の高速ローンチサイクルだ。伝統コアは新規商品ローンチに6〜12ヶ月かかるが、Britecoreは4〜8週を約束する。

SocotraはWeb2/Web3インディ保険・組込保険(チェックアウト時に自動保険追加)のような新興市場で強い。LemonadeのようなデジタルD2C保険会社が自社コアの代わりにSocotraベースでローンチした事例がある。

| コア | 適合保険会社規模 | 価格帯 | ローンチ速度 | 主な強み |

| --- | --- | --- | --- | --- |

| Guidewire | 売上`$5B+` | 非常に高い | 2〜4年実装 | P&C深さ |

| Duck Creek | 売上`$1B+` | 高い | 1〜3年 | ビジュアルルール |

| Sapiens | グローバル多国籍 | 高い | 1〜3年 | 多国対応 |

| Insurity | 米国specialty | 中程度 | 6ヶ月〜1年 | Specialtyライン |

| EIS | デジタルインディ | 中〜高 | 6ヶ月〜1年 | API-first |

| Majesco | ミドルマーケット | 中程度 | 1〜2年 | Azure統合 |

| Britecore/Socotra | MGA・インディ | 低い | 4〜8週 | 高速ローンチ |

第13章 · API-First設計とGuidewire APIs

2020年代の保険コアの最大の変化は**API-first設計**だ。過去のモノリシックコアが自分のUIを通してのみアクセス可能だったとすれば、2026年のコアはREST/GraphQL APIを通して全機能にアクセス可能でなければならない。これがデジタルチャネル・モバイル・組込保険を可能にする。

Guidewireは2019年から**Cloud APIs**を本格的にリリースし、2026年基準で300+エンドポイントが公開されている。PolicyCenter・ClaimCenter・BillingCenterのほぼ全ての動作がAPIで可能だ。

POST /policy/v1/jobs/submission HTTP/1.1

Host: pc.acme.guidewire.cloud

Authorization: Bearer eyJhbGciOiJSUzI1NiI...

Content-Type: application/json

{

"data": {

"attributes": {

"productCode": "PersonalAuto",

"effectiveDate": "2026-06-01",

"primaryNamedInsured": {

"firstName": "Jane",

"lastName": "Smith",

"dateOfBirth": "1985-04-12",

"primaryAddress": {

"addressLine1": "123 Main St",

"city": "Boston",

"state": "MA",

"postalCode": "02101"

}

},

"personalVehicles": [

{

"vin": "1HGBH41JXMN109186",

"year": 2023,

"make": "Honda",

"model": "Accord"

}

]

}

}

}

このAPI呼出し一回でPolicyCenterに新しい見積もりが生成され、料率エンジンが保険料を計算してレスポンスを返す。以前ならPolicyCenter UIを開いて30回クリックしなければならなかった作業だ。モバイルアプリ、比較サイト、自社D2Cサイトがこのapiを呼び出して即時見積もりを見せられるようになった。

API-first設計のもう一つの利点は**マイクロサービス分解**だ。モノリシックなPolicyCenterを一度に取り替える代わりに、新機能をAPIの上にマイクロサービスとして書いて段階的にコアを空にしていくパターンが可能になる。

第14章 · Salesforce Financial Services Cloud統合

2020年代後半の新しい流れは**Salesforce Financial Services Cloud(FSC)統合**だ。保険会社がコアシステムと別途にSalesforceを営業・顧客管理layerとして導入する事例が急増した。

Salesforce FSCが扱う領域。

- **エージェント・ブローカーCRM** — 営業パイプライン、更新キャンペーン。

- **顧客セルフサービス** — Experience Cloud上のポータル。

- **クレーム協業** — Service Cloud上のクレームアジャスターワークスペース。

- **分析** — Tableau CRM (Einstein Analytics) ベース。

Guidewire・Duck Creek・Sapiensは全てSalesforce FSCとの双方向統合コネクタを公式にサポートする。ポリシー・クレームデータがSalesforceへリアルタイム同期され、エージェントがSalesforceで見積もりを始めるとそれがPolicyCenterへ伝達される。

この構図は保険ITを二つのlayerに分離する — **System of Record**(Guidewire等のコア)と**System of Engagement**(Salesforce)。コアはデータの真実の源で、Salesforceはユーザー経験と外部チャネルを担う。二つのシステムがどうデータを同期するかが2020年代後半の保険ITアーキテクチャの核心的問いになった。

第15章 · メインフレームモダナイゼーション — COBOL/AS-400の影

グローバルP&C市場がクラウドへ移る間、韓国・日本の多くの保険会社は依然としてCOBOL/AS-400上の自社開発コアを回している。30年を耐えたシステムだ。

典型的なメインフレーム保険コアスタック。

- **ハードウェア** — IBM zSeriesメインフレームまたはIBM AS-400(現在はIBM i)。

- **言語** — COBOL、RPG、PL/I。

- **データベース** — DB2、VSAM、IMS DB。

- **トランザクション処理** — CICS、IMS TM。

- **バッチ** — JCL (Job Control Language)。

このスタックの強みは**検証された安定性**だ。30年間24x7無停止で保険ポリシーを処理してきた。短所は**人材不足**だ。COBOL開発者が2020年代に平均年齢55歳を超え、AS-400 RPG開発者はさらに少ない。韓国・日本の保険会社IT部門が最大の危機として認識する問題だ。

IDENTIFICATION DIVISION.

PROGRAM-ID. CALC-PREMIUM.

*> 30年もの自動車保険料計算モジュール — 1995年作成

*> 単純化した例(実際のコードは数千行)

ENVIRONMENT DIVISION.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-DRIVER-AGE PIC 9(03).

01 WS-PRIOR-CLAIMS PIC 9(02).

01 WS-BASE-PREMIUM PIC 9(07)V99 VALUE 120000.00.

01 WS-AGE-FACTOR PIC 9(03)V999.

01 WS-CLAIMS-FACTOR PIC 9(03)V999.

01 WS-FINAL-PREMIUM PIC 9(09)V99.

PROCEDURE DIVISION.

MAIN-LOGIC.

IF WS-DRIVER-AGE < 25

MOVE 1.500 TO WS-AGE-FACTOR

ELSE IF WS-DRIVER-AGE < 65

MOVE 1.000 TO WS-AGE-FACTOR

ELSE

MOVE 1.200 TO WS-AGE-FACTOR

END-IF.

COMPUTE WS-CLAIMS-FACTOR = 1.000 + (WS-PRIOR-CLAIMS * 0.300).

COMPUTE WS-FINAL-PREMIUM = WS-BASE-PREMIUM * WS-AGE-FACTOR

* WS-CLAIMS-FACTOR.

DISPLAY "FINAL PREMIUM: " WS-FINAL-PREMIUM.

STOP RUN.

この30年もののCOBOLをどうモダナイズするかが2026年韓国・日本の保険IT中核議題だ。オプションは三つ。(1) メインフレームをそのまま維持しその上にAPIゲートウェイだけ載せる。(2) Guidewire・Duck Creekのような商用パッケージでコアを丸ごとリプレースする(`$100M`+のプロジェクト、3〜5年)。(3) COBOLを自動でJava/C#へ変換するツール(Heirloom・TmaxSoft・Micro Focus)を使う。

第16章 · 韓国Samsung SDS保険IT — 30年の士官学校

Samsung SDSはサムスン生命・サムスン火災・サムスンカードのITシステムを作ってきた30年の士官学校だ。韓国の保険ITのほぼ全ての中核アーキテクトが一度は通り過ぎた場所。

Samsung SDSの保険IT中核資産。

- **Brity保険コア** — 自社開発P&C・生命統合コア。サムスン火災・サムスン生命に深く統合。

- **SCAS (Samsung Claims Administration System)** — クレーム処理自社システム。

- **Nexledger** — ブロックチェーンベース保険金支払い・再保険精算ソリューション。

- **Brity AI** — チャットボット・文書処理・保険金支払い自動化AIソリューション。

2020年代中盤以降Samsung SDSは自社コアをクラウドネイティブに再設計し始めた。中核は**マイクロサービス分解とイベント駆動統合**で、AWS・Azureマルチクラウドを仮定したアーキテクチャだ。

サムスン生命・サムスン火災がこの自社コアを使い続けるか、それともGuidewire・Sapiensのようなグローバルパッケージでリプレースするかが2020年代後半の韓国保険ITの大きな観戦ポイントだ。自社開発の強みは**サムスングループ統合の深さ**、短所は**グローバル拡張性と人材採用**。

第17章 · KB保険モダナイゼーション — KBライフCISクラウド事例

KB金融グループは2022年KB生命・プルデンシャル生命合併後にKBライフ生命を出帆させ、この合併の最大のIT課題が**二社のコアシステム統合**だった。

KBライフの次世代コアシステム**CIS(Core Insurance System)**は2023〜2025年にかけて構築された。中核特徴。

- **マイクロサービスアーキテクチャ** — ポリシー・クレーム・収納を独立サービスへ分離。

- **Kubernetesベースのコンテナオーケストレーション** — オンプレミス + KBクラウドハイブリッド。

- **イベント駆動統合** — Kafkaでモジュール間の非同期通信。

- **APIゲートウェイ** — 外部チャネル統合のための標準インターフェース。

このプロジェクトは韓国保険ITのモダナイゼーション事例のうち最も野心的なものの一つに挙げられる。既存二社のメインフレームコアをクラウドネイティブで再構築しながら30年のポリシーデータをマイグレーションした事例。

KB以外にも新韓ライフ・教保生命・現代海上が似たモダナイゼーションプロジェクトを進めている。現代海上は自社開発コアを維持しながら段階的にクラウドネイティブモジュールへ分解するパターンで、教保生命はSapiens導入を検討した事例として知られている。

第18章 · 日本NTT Data保険コア — クラウドマイグレーションの巨大な波

日本の保険IT市場はNTT Data、NRI(野村総合研究所)、TIS、NECが事実上四分する。その中でNTT Dataが最大の保険IT SI事業者。

NTT Dataの保険コア資産。

- **NTT Data保険コア (自社パッケージ)** — 日本のP&C・生命保険向けの自社開発コア。

- **OpenCanvas** — NTT Dataが作った保険APIプラットフォーム。

- **TopVision Insurance** — 次世代保険管理パッケージ。

2020年代中盤の日本の保険会社の最大の流れは**クラウドマイグレーション**だ。東京海上日動が2023年からGuidewire Cloudへ一部ラインを移し、SOMPOも似た時期にクラウド転換を発表した。この作業のSIパートナーは主にNTT Data・NRIだ。

日本の保険ITの特徴は**30年以上運用されたメインフレームの比重**が韓国よりはるかに大きい点だ。1980〜1990年代に構築されたメインフレームが2020年代まで生きており、その上のCOBOLコードが数千万行に達する。これをどうモダナイズするかが日本の保険ITの最大の課題。

第19章 · NRI ZAITAS — 30年の保険コアパッケージ

NRI(野村総合研究所)の**ZAITAS**は日本の保険コア市場で最も古いパッケージの一つだ。1990年代初頭にリリースし30年生き残り、日本の中堅・中小保険会社に深く浸透している。

ZAITASの強みは**日本の保険規制・制度との深い整合性**だ。日本の金融庁(FSA)の規制変化、日本の税制、日本の会計基準(IFRS 17導入等)に最も早く対応してきたパッケージ。日本の保険会社がグローバルパッケージ(Guidewire・Sapiens)を導入するときの最大の摩擦点が韓国と同じく**ローカル規制適合性**だが、ZAITASはその部分が基本搭載されている。

2020年代中盤NRIはZAITASのクラウドネイティブ再構築を進めている。既存ZAITASのビジネスロジックを維持しながらインフラlayerをAWS・Azureマルチクラウド + Kubernetesに取り替える作業。2030年完了を目標とする。

NRI以外に日本のもう一つの保険IT強者は**TIS**で、TISの**eX-Tide**パッケージが日本の損害保険市場に深く浸透している。

第20章 · SOMPO・東京海上のコアマイグレーション — 日本ビッグ2の選択

日本の損害保険市場のビッグ2はSOMPOホールディングスと東京海上ホールディングス(Tokio Marine)だ。両社とも2020年代中盤にコアシステムモダナイゼーションを発表し、その選択の差が日本の保険ITの未来を見せる。

**東京海上日動** — 2023年Guidewire Cloud導入発表。自動車保険ラインから段階的マイグレーション。SIパートナーはNTT Data + Accenture。5年スケジュール。

**SOMPO日本興亜損害保険** — 2024年自社開発の次世代コア + マイクロサービス分解発表。外部パッケージの代わりに自社IT子会社であるSOMPO Systemsが構築。クラウドはAWS東京リージョンベース。

この二つの選択の差が意味すること。東京海上は**グローバル標準パッケージで米国・アジア・欧州の一貫性確保**を優先し、SOMPOは**日本特化 + IT自給率**を優先した。どちらが正しいかは2030年頃に評価が出るだろう。

この二つのマイグレーションプロジェクトはそれぞれ`$500M`以上のIT投資だ。韓国のKBライフCISプロジェクトの10倍規模。日本の保険ITの規模と保守性がこの数字に込められている。

第21章 · Low-Code/No-Codeの保険コア適用

2020年代後半の保険コアのもう一つの大きな変化は**low-code/no-code導入**だ。Guidewire Studio、Sapiens DigitalSuite、Duck Creek Authorは全て保険商品マネージャー・アンダーライター・クレームアジャスターがコードなしでルールを修正できるツールを提供する。

この流れの背景。

- **保険商品ローンチ速度の圧力** — デジタルD2C保険会社が新商品を4週でローンチするのに対して、伝統的な保険会社は12ヶ月かかる。差を縮めるためには非開発者が直接ルールを修正できなければならない。

- **IT人材不足** — Gosu・RPG・COBOL人材不足が深刻だ。非開発者が自給できるツールが必要だ。

- **規制対応速度** — 保険規制が頻繁に変わり、IT開発サイクルを待つと遅延ペナルティを受ける。

Guidewire StudioはGosuコードをビジュアルIDEで編集できるようにし、一部ルールはフォームベースのGUIで作成する。Duck Creek Authorはそれ自体がビジュアルルールエディタだ。Sapiens DigitalSuiteはチャネル・UI自体をノーコードで構成する。

短所も明らかだ。**複雑なビジネスロジックはlow-codeで表現が難しい**。依然としてコードとGUIを混ぜて使うハイブリッドモデルが現実だ。

第22章 · マイクロサービス分解パターン — モノリシックコアをどう分割するか

10年もののモノリシックPolicyCenterをマイクロサービスへ分解するにはどこから始めるべきか。2026年時点のベストプラクティスは**Strangler Figパターン**だ。

- **第1段階** — 既存モノリスの上にAPIゲートウェイを載せる。全ての外部呼出しがこのゲートウェイを通過する。

- **第2段階** — 新機能をマイクロサービスとして書く。ゲートウェイが新機能リクエストを新しいサービスへルーティングし、残りは既存モノリスへ送る。

- **第3段階** — 既存機能を段階的に新しいサービスへ移す。モノリスから一つずつモジュールを切り離し、ゲートウェイのルーティングルールを更新する。

- **第4段階** — 全機能が新しいサービスへ移されたらモノリスをシャットダウンする。

このパターンの優雅さは**巨大なビッグバンリプレースを避ける**点だ。10年+の保険コアを一度に取り替えるのはほぼ常に失敗する(IBMが作った「巨大IT プロジェクトの65%が失敗する」という統計がある)。Strangler Figは6〜24ヶ月単位で段階的に移しながらriskを分散する。

マイクロサービス分解の最初の候補は通常**相対的に独立したドメイン** — クレーム受付(FNOL)、決済収納、顧客セルフサービス。コアドメイン(ポリシー発行・料率算定)は最後に移す。

第23章 · データマイグレーション — 30年ポリシーデータの重み

コアシステムを取り替えるときの最も難しい部分が**データマイグレーション**だ。30年分のポリシー・クレーム・決済データを新システムへ移しながら一件も失わないようにしなければならない。

典型的なマイグレーションワークフロー。

1. **データプロファイリング** — 既存システムのデータを分析。正確なスキーマ、データ品質問題、欠損・重複を識別。

2. **データクレンジング** — 汚れたデータを浄化。例:ポリシー番号フォーマット統一、日付フォーマット統一、欠損フィールド補完。

3. **マッピング設計** — 既存スキーマ → 新システムスキーマのマッピング。どのフィールドがどう変換されるか。

4. **変換スクリプト開発** — ETLツール(Informatica・Talend・dbt)または自社スクリプト。

5. **テストマイグレーション** — 一部データ(10〜20%)をテスト環境へマイグレーション。結果検証。

6. **フルマイグレーション** — 全データを移す。通常週末ダウンタイムまたは段階的カットオーバー。

7. **事後検証** — ポリシー件数、保険金支払い累積合計、クレーム件数等の中核指標が一致するか確認。

この作業が難しい理由。**既存システムのデータがきれいでない。** 30年間フォーマットが何度も変わり、一部ポリシーはマイグレーションごとに欠損し、決済履歴はメインフレームの別途システムにある。この全てを整合性を保って移す作業が通常コアマイグレーション全体予算の30〜40%を占める。

-- マイグレーション検証 — 韓国保険会社事例

-- 既存メインフレーム vs 新規Guidewireのポリシー件数・総保険金比較

WITH legacy_summary AS (

SELECT

line_of_business,

COUNT(*) AS policy_count,

SUM(annual_premium) AS total_premium,

COUNT(DISTINCT policyholder_id) AS unique_customers

FROM legacy_policies

WHERE effective_date >= '1995-01-01'

AND status IN ('active', 'lapsed', 'expired')

GROUP BY line_of_business

),

new_summary AS (

SELECT

product_code AS line_of_business,

COUNT(*) AS policy_count,

SUM(annual_premium) AS total_premium,

COUNT(DISTINCT primary_named_insured_id) AS unique_customers

FROM guidewire_pc.policies

WHERE migration_batch_id IS NOT NULL

GROUP BY product_code

)

SELECT

COALESCE(l.line_of_business, n.line_of_business) AS lob,

l.policy_count AS legacy_count,

n.policy_count AS new_count,

(n.policy_count - l.policy_count) AS count_diff,

l.total_premium AS legacy_premium,

n.total_premium AS new_premium,

ROUND((n.total_premium - l.total_premium) / l.total_premium * 100, 4) AS premium_diff_pct

FROM legacy_summary l

FULL OUTER JOIN new_summary n USING (line_of_business)

ORDER BY ABS(count_diff) DESC;

このクエリのような検証をマイグレーション前後に数十回回し、全ての数字が0.01%以内で一致しなければならない、そうしてカットオーバーが終わる。

第24章 · 災害復旧とBCP — 24時間止まれないシステム

保険コアは24x7無停止がほぼ絶対的要件だ。クレーム受付が朝3時にも入り、決済収納が24時間回り、自動車事故は時間を選ばない。

伝統的保険会社のBCP(Business Continuity Plan)設計。

- **二重化データセンター** — メイン + DRサイト。同期・非同期レプリケーション。

- **RPO (Recovery Point Objective)** — データ損失許容時間。通常0〜5分。

- **RTO (Recovery Time Objective)** — 復旧時間。通常1〜4時間。

- **定期DR訓練** — 四半期ごとにメイン → DRフェイルオーバーテスト。

クラウド時代にはこれがより単純になる。AWS・AzureのマルチAZ・マルチリージョンが基本搭載されており、RPO・RTOが分単位に縮む。Guidewire Cloud PlatformはAWSマルチAZデプロイが基本で、自動バックアップ・自動フェイルオーバーが付いてくる。

代わりにクラウドマイグレーションの最大の懸念が**クラウド自体の障害**だ。2024年AWS us-east-1障害で米国東部の複数の保険会社のコアが一度に止まる事件があった。その後保険会社はマルチクラウド(AWS + Azure)やマルチリージョン分散をより真剣に考慮し始めた。

第25章 · 2026〜2030年保険コアの未来 — 5つの予測

最後に2030年に向けた5つの予測。

1. **Guidewire Cloudが80%+を占める** — Guidewireの2030年80%クラウド目標が達成される可能性が高い。新規P&C構築の90%以上がGuidewire Cloud + Duck Creek OnDemandで二分。

2. **AIエージェントがクレーム処理を変える** — Claude・GPTベースのクレームアジャスター自動化が単純クレームの80%を処理。複雑クレームは人が。

3. **組込保険が爆発する** — 自動車購入、フライト予約、家電購入時に自動保険追加。Britecore・SocotraのようなAPI-firstコアがこれを可能にする。

4. **メインフレームの最後の10年** — 韓国・日本のメインフレーム保険コアが2030年頃に大規模に引退。COBOL人材が60代後半に進入しもう維持不可能。

5. **再保険・ブロックチェーン・気候保険** — ブロックチェーンベースの再保険精算(Nexledger・B3i)、気候変動対応の新商品(parametric insurance)、サイバー保険の爆発的成長。

> 「保険コアは30年を生きなければならない。しかし30年もののコアは30年さらに生きられない。その間のモダナイゼーションが2020年代後半の保険ITの全てだ」

第26章 · エピローグ — COBOL開発者が去った後

この記事の最初の場面に戻る。朝4時17分のチャットルーム。2008年に退職したCOBOL開発者。日本語のコメント。

2026年の韓国・日本の全ての大手保険会社IT室にはこういうシステムが一つずつある。30年を耐えたコア。それを書いた人たちは去った。新人はCOBOLを学ぼうとしない。そしてそのシステムは毎日数十億円の保険金を処理する。

これが保険コアモダナイゼーションの本当の重みだ。単純なITプロジェクトではなく**保険会社全体の企業継続性**の問題だ。一度ミスすると会社が崩れる可能性がある。だから保険会社は最も保守的なIT産業であり、同時に最も切迫してモダナイゼーションを必要とする。

GuidewireがP&C市場の80%を取るか、Duck CreekがSaaS転換で追撃するか、Sapiensがグローバル多国籍市場を制するか、韓国のSamsung SDS・日本のNTT Dataが自社コアで耐えるか — この全ての問いが2030年に答えを得るだろう。

最後に一言。**保険は約束だ。30年後の約束をITが守らなければならない。** それが保険コアシステムの存在理由だ。

— 保険会社コアシステム2026、おわり。

参考 / References

- [Guidewire Software — InsuranceSuite](https://www.guidewire.com/products/insurancesuite)

- [Guidewire Cloud Platform](https://www.guidewire.com/products/cloud)

- [Duck Creek Technologies — OnDemand](https://www.duckcreek.com/)

- [Duck Creek Policy](https://www.duckcreek.com/product/policy/)

- [Sapiens — Insurance Software Solutions](https://www.sapiens.com/)

- [Sapiens IDIT P&C Suite](https://www.sapiens.com/products/sapiens-idit/)

- [Sapiens CoreSuite for L&P](https://www.sapiens.com/products/sapiens-coresuite-for-life-pensions/)

- [Insurity — Insurance Software](https://www.insurity.com/)

- [EIS Group — EIS Suite](https://www.eisgroup.com/)

- [Majesco — Insurance Software](https://www.majesco.com/)

- [FINEOS — Claims Software](https://www.fineos.com/)

- [Origami Risk — RMIS Platform](https://www.origamirisk.com/)

- [Britecore — Insurance Core Platform](https://www.britecore.com/)

- [Socotra — Modern Core for Insurance](https://www.socotra.com/)

- [Salesforce Financial Services Cloud](https://www.salesforce.com/products/financial-services-cloud/)

- [IBM zSystems — Mainframe](https://www.ibm.com/products/z)

- [IBM Power Systems / IBM i (AS/400 successor)](https://www.ibm.com/products/power)

- [Samsung SDS — Brity Insurance](https://www.samsungsds.com/)

- [NRI — Nomura Research Institute](https://www.nri.com/)

- [NTT Data — Insurance Solutions](https://www.nttdata.com/global/en/services/industries/insurance)

- [Saga pattern — Hector Garcia-Molina, 1987](https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf)