保険業界のシステム開発外注｜規制対応とレガシー刷新の進め方

保険業界の基幹システムは、数十年にわたり稼働してきたメインフレーム上の契約管理・保険金支払・引受査定などを中核に構成されています。老朽化とCOBOL技術者の減少により刷新を急ぎたい一方、社内に十分な開発リソースを抱えている保険会社は多くありません。外部委託は避けて通れない選択肢になりつつあります。

しかし、保険業界のシステム開発外注は、一般業界の外注と同じ感覚では進められません。保険業法と金融庁「保険会社向けの総合的な監督指針」により、システムを外部に委託しても「委託先管理の責任は保険会社に残る」と明確に位置付けられているためです。委託先で情報漏えい・システム障害・工程遅延が起きたときに責任を問われるのは、他ならぬ保険会社自身になります。

さらに保険業界特有の事情として、被保険者の傷病歴・保険金請求履歴といった機微情報を扱うこと、そしてメインフレーム基幹系というレガシー環境をどう段階的に置き換えていくかという難題があります。「規制対応」「レガシー刷新」「委託先管理」の3つを同時に成立させないと、外注プロジェクトは経営層・コンプライアンス部門の承認を得られません。

本記事では、保険業界のシステム開発を外部委託する際に押さえるべき規制の要点、レガシー基幹系を刷新スコープにどう組み込むか、委託先ベンダーの選定チェック項目、契約に盛り込むべき条項、そして委託後に自社へ残す監督・モニタリング体制を、発注担当者がそのまま社内説明に使える形で解説します。

保険業界のシステム開発外注が難しい3つの理由

保険業界のシステム開発外注は、一般企業の外注や、同じ金融業でも銀行・証券とも異なる固有の難しさがあります。まず、その難しさの正体を3つの軸に整理しておくと、この後の判断が格段にしやすくなります。

保険業法・監督指針が求める「委託しても残る保険会社の責任」

保険業法は、保険会社が業務を外部に委託する場合であっても、契約者保護と業務の適切性を確保する責任は保険会社自身に残ると位置付けています。金融庁「保険会社向けの総合的な監督指針」でも、外部委託先の選定・契約・モニタリング態勢を保険会社が構築しているかが検査の主要な着眼点になっています（金融庁「保険会社向けの総合的な監督指針」）。

つまり、システム開発を外注しても、次のような事象については保険会社が説明責任を負います。

• 委託先で発生した情報漏えい・不正アクセス
• 委託先の品質不良・工程遅延に起因する保険金支払遅延やサービス停止
• 委託先が再委託した第三者による事故

「委託した相手が悪かった」では通用しないのが保険業界の外注です。この前提が、他業界の外注と一線を画す最大のポイントになります。

メインフレーム基幹系がもたらすレガシー刷新の難易度

保険会社の契約管理・保険金支払・引受査定は、長年メインフレーム上で作り込まれてきたシステムに集約されています。長い運用の中で仕様書と実装が乖離し、COBOL資産のブラックボックス化とCOBOL技術者の減少という「保守困難」問題が顕在化しています（参考: 情報処理学会「保険業界における真の崖～みんなを救う翼」）。

刷新を急ぎたい一方で、以下のような固有の難しさがあります。

• 契約は数十年単位で継続するため、旧システムと新システムを長期間並行稼働させる必要がある
• 保険料計算・責任準備金計算といった業務ロジックは金融庁への商品届出内容と一致していなければならず、仕様の再現に高い精度が求められる
• 一括入れ替えは業務停止リスクが極めて高く、段階移行が事実上の必須条件になる

これらの制約は、外注のスコープ設計・スケジュール・移行方式に直接影響します。

機微情報（被保険者情報）を扱うことによる情報管理の重さ

保険会社が扱うのは、氏名・住所・連絡先だけではありません。健康診断結果・傷病歴・入通院履歴・保険金請求内容といった、いわゆる「機微情報」に該当する項目が大量に含まれます。金融分野の個人情報保護ガイドラインでは、機微情報の取扱いは通常の個人情報より厳格な運用が求められ、委託先での取扱いにも同等の水準が要求されます（金融分野における個人情報保護に関するガイドラインの安全管理措置等についての実務指針）。

開発ベンダーがテスト用に本番データを扱うケース、運用保守中に本番環境へアクセスするケース、再委託先が実装作業を行うケースなど、機微情報が委託先の管理下に入る場面は多く発生します。委託しても情報管理の責任は保険会社に残るため、外注前提の設計段階からデータ取扱い・アクセス制御を組み込む必要があります。

保険会社のシステム開発外注に関わる規制・ガイドライン

外注を安全に進めるには、まず「何を満たせば監督責任を果たしたことになるか」の土台を押さえる必要があります。保険業界のシステム開発外注に関わる規制・ガイドラインは、大きく4つの軸で整理できます。

保険業法・監督指針が求める外部委託先管理の要点

保険業法および同施行規則は、保険会社に業務運営の適正確保・体制整備義務を課しています。金融庁「保険会社向けの総合的な監督指針」II-4「業務の適切性」では、外部委託先管理に関する典型的な着眼点として、以下の観点が挙げられています（監督指針 II-4）。

• 委託先を選定する際の評価基準・審査プロセスが整備されているか
• 委託契約に責任分界・報告義務・監査権・再委託の管理などが盛り込まれているか
• 委託期間中の定期モニタリング・監査・是正指示の枠組みが機能しているか
• 委託業務の重要性に応じたリスク評価と、経営レベルでの承認プロセスがあるか

システム開発の外注はこれらの「業務の一部の委託」に該当し、監督指針で求められる管理態勢を保険会社側で構築しなければなりません。

FISC安全対策基準と保険会社が押さえるべき対応範囲

金融機関のシステムに関する事実上のデファクトスタンダードが、公益財団法人金融情報システムセンター（FISC）が発行する「金融機関等コンピュータシステムの安全対策基準・解説書」です。2026年3月には第14版が公表され、AI利活用時の安全対策・サイバーセキュリティ・耐量子計算機暗号（PQC）や近年のシステム障害から得られた知見などが反映されました。保険会社も対象金融機関に含まれ、業界横断で参照される基準になっています（FISC「金融機関等コンピュータシステムの安全対策基準・解説書」（第14版））。

FISC安全対策基準は、システムの設置・運用・保守に加えて、外部委託先の管理・クラウド利用時の対応・サイバーセキュリティ対策など幅広い項目を網羅しています。加えて金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」も、サードパーティ管理・多段階委託のリスク管理を強く求めています（金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」）。

発注担当者としては、委託先ベンダーがこれらの基準・ガイドラインに準拠した開発・運用体制を持っているか、あるいは準拠可能な体制で受託できるかを、選定段階で確認する必要があります。

金融分野個人情報保護ガイドラインと機微情報の委託

被保険者の機微情報は、金融分野個人情報保護ガイドラインとその実務指針により、通常の個人情報より厳格な取扱いが求められます。委託関連で特に押さえておきたいのは次の点です。

• 委託先に対する必要かつ適切な監督義務（安全管理措置・従業員教育・アクセス制御）
• 再委託を行う場合の事前承認と再委託先への監督義務の伝達
• 委託契約における目的外利用禁止・第三者提供禁止・データ返却／消去条項の整備
• 委託先での取扱状況に関する定期的な監査・報告徴収

システム開発の要件定義段階から「本番データを開発・テストに使うのか」「マスキングをどこで行うのか」「保守フェーズで委託先が本番環境にアクセスするのか」を決めておかないと、後工程で監督義務を果たせない設計になりがちです。

レガシー基幹系の刷新をどう外注に組み込むか

規制対応の土台を押さえたうえで、次に難関になるのがレガシー基幹系の刷新をどう外注スコープに落とし込むかです。ここで判断を誤ると、規制対応どころか刷新プロジェクトそのものが座礁します。

なお、リホスト／リライト／リビルドといった刷新手法の一般的な比較や、発注者側が事前に押さえておきたい費用・進め方の基礎はレガシーシステム刷新とは？発注者が知る手法・進め方・費用の基礎でも解説しています。本記事では業界横断の一般論はそちらに譲り、保険業界固有の規制要求・段階移行・委託先管理の観点から、外注スコープをどう設計するかに絞って掘り下げます。

リホスト／リライト／リビルドの選択と外注設計への影響

メインフレーム基幹系のモダナイゼーション手法は、大まかに以下の3つに分けて考えられます。

外注の観点で見ると、リホストは短期・低リスクだが将来の負債を先送りしやすく、リビルドは長期・高リスクだが最大の効果を狙えます。実際の刷新プロジェクトでは、契約管理はリホストで先に近代化基盤へ載せ替え、保険金支払や引受査定は段階的にリライト／リビルドしていく、といったハイブリッド設計が現実解になることが多いです。

外注先ベンダーに手法選択そのものを丸投げすると、ベンダーが得意な手法に引き寄せられ、保険会社側の中長期戦略とずれます。手法選択はコンプラ部門・経営層と合意した中期方針として保険会社側で意思決定し、外注は「決めた手法をどう安全に実行するか」に限定するのが安全です。

段階移行・並行稼働を前提とした発注スコープの切り分け

保険業界の基幹系刷新は「一括カットオーバー」が現実的でないケースがほとんどです。契約は数十年単位で継続し、旧契約と新契約が同一システム内で長期間共存するためです。したがって発注スコープは、次のような単位に切り分けて設計します。

• 業務ドメイン単位（例: 契約管理／保険金支払／引受査定／再保険）
• 商品単位（新商品は新システム、既契約は旧システムで維持）
• 機能単位（帳票出力・外部連携APIから先に切り出す）
• 期間単位（並行稼働の許容期間を最初に決めておく）

並行稼働期間中は、旧システムと新システムの両方のデータ整合性・帳票整合性を維持する必要があり、その保守運用も外注スコープに含めるべき論点になります。「新システムの構築」だけを発注し、旧システムの並行稼働支援を別ベンダーに任せる設計は、責任分界の穴を生みやすいので注意が必要です。

ドキュメント不備・COBOL資産・データ移行への備え

保険会社のレガシー基幹系では、次のような「刷新前提でつまずきやすい要素」が高確率で存在します。

• 仕様書と実装の乖離（ドキュメント未更新・改修履歴の散逸）
• COBOL資産のブラックボックス化（担当者退職による属人化）
• 帳票・外部システムとの数十年分の連携仕様
• 商品ごとに異なる保険料計算・責任準備金計算のロジック
• 過去契約のマイグレーション設計（データ精度と金融庁届出内容との整合）

これらは発注スコープの初期に「アセスメントフェーズ」を独立させて委託し、費用固定の小さな契約で棚卸しした上で、本格開発のスコープと契約金額を確定していく段階契約が安全です。要件定義前に本格開発を発注してしまうと、ドキュメント不備が判明した段階で追加費用が青天井になります。

保険業界の委託先（ベンダー）選定チェックポイント

規制要求とレガシー刷新の要件を、実際の委託先評価に変換する段階です。「実績豊富」「セキュリティ万全」といった抽象アピールを鵜呑みにせず、確認項目に落とし込みましょう。

保険業界の開発実績・レガシー刷新実績をどう見極めるか

保険業界の開発実績を評価する際は、次のような具体項目で確認するのが有効です。

「保険会社向けの実績があります」という一言では、パンフレット制作を1件手掛けた程度でも実績になってしまいます。金融庁の届出・監督対象になる領域を担当した経験があるかまで踏み込んで確認しましょう。

セキュリティ体制・認証の確認項目（チェックリスト）

セキュリティ体制は、ベンダーの取得認証と、実運用の体制の両面で見ます。以下は発注時のチェックリスト例です。

• ISMS認証（ISO/IEC 27001）またはプライバシーマークの取得
• 金融分野で活用される場合のISMAP登録（クラウドサービスの場合）
• FISC安全対策基準への準拠状況（自己評価または第三者評価）
• 開発・運用の物理拠点（国内／海外・オフショア構成）
• 開発環境のアクセス制御・ログ管理・退職者の権限剥奪プロセス
• 機微情報を扱う場合のマスキング・匿名化の技術的対応
• 従業員に対する個人情報・金融規制の教育カリキュラム
• 過去のインシデント発生履歴と再発防止策の説明

認証は「取得しているか／していないか」だけでなく、認証の適用範囲（全社／一部部門）と、開発対象システムがその範囲に含まれるかまで確認します。適用範囲外の部門が受託する場合、認証は名目上のものになります。

再委託・多段階委託のリスクをどう抑えるか

システム開発では、元請けベンダーが下請け・孫請けに実装を委託する多段階委託が一般的に発生します。金融庁のサイバーセキュリティに関するガイドラインでも、多段階委託のリスク管理は重要論点として繰り返し取り上げられています。

再委託を許容する場合でも、以下の確認・制限を契約前に合意しておきます。

• 再委託を認める範囲（開発工程・作業内容の限定）
• 再委託先の事前承認プロセス（社名・所在地・作業内容の申告）
• 再委託先に対する監督責任を元請けが負うことの明記
• 再委託先の機微情報アクセスの可否と、アクセスする場合の管理措置
• 再委託が変更になった場合の通知義務

「委託先の中で誰が本当に手を動かしているか分からない」状態は、規制対応上の最大リスクになります。契約前に構造を可視化するだけで、事故発生時の対応スピードと責任の所在が大きく変わります。

委託契約で必ず盛り込むべき条項

委託先を選定したら、その要件を契約条項に落とし込む段階です。契約は「事故が起きた後」に効いてくるものです。以下は保険業界のシステム開発外注で最低限盛り込みたい条項です。契約条項の詳細なチェックについては、取適法でIT外注はどう変わる？発注者チェックリストも参考になります。

責任分界・監査権・報告義務を契約で明確にする

保険会社側で必ず契約に盛り込むべき条項は、次のように整理できます。

金融庁の監督指針では、監査権・報告義務・是正指示の枠組みが契約に盛り込まれていることが検査時に確認されます。テンプレート的な条項をコピーするのではなく、保険会社側の実務で実際に発動できる書き方になっているかを社内法務と点検しましょう。

機密保持・被保険者情報の保護・契約終了時のデータ消去

機微情報の取扱いに関わる条項として、以下は必ず含めます。

• 機密保持契約（NDA）による情報管理の一般的義務
• 被保険者情報の目的外利用禁止・第三者提供禁止
• 開発・テスト時に本番データを利用する場合のマスキング・匿名化の義務
• 委託先での従業員教育義務とその実施報告
• インシデント発生時の速やかな通知義務（時間閾値を明記）
• 損害賠償の範囲（上限・除外事由・保険加入義務）
• 契約終了時のデータ返却・消去の方法と証跡取得
• 契約終了後も一定期間存続する条項（残存義務条項）の指定

とくに契約終了時のデータ消去は、消去したことの証跡（消去証明書）を委託先から取得できる形にしておくことが重要です。「消去しました」の口頭連絡では監督対応で説明が付きません。

なお、契約条項全体を体系的にチェックしたい場合は、契約前後で使えるチェックリスト形式の資料を活用すると、社内法務・コンプラ部門との擦り合わせがスムーズになります。

委託形態（請負／準委任）と指揮命令・偽装請負への注意

システム開発の委託形態は、請負と準委任のいずれかを選ぶのが一般的です。請負は成果物完成責任、準委任は業務遂行責任という違いがありますが、実務で注意が必要なのは、発注担当者と委託先エンジニアの日常の関わり方です。

• 委託先エンジニアに対して、保険会社の社員と同じように直接指示・勤怠管理をすると、契約形態が請負／準委任であっても、実態が労働者派遣に該当すると判断されるおそれがある（偽装請負のリスク）
• 委託先の管理責任者を介した指示、成果物ベースの受け入れ、業務範囲の明確化により、指揮命令関係を持たない運用が求められる
• 常駐開発を選ぶ場合でも、席の配置・入退場管理・作業指示ルートを整理し、指揮命令の実態が生じないよう運用を設計する

保険会社が業務委託先エンジニアに現場で細かな指示を出す場面は、開発の性質上どうしても発生しやすくなります。契約を締結する前に、社内の発注担当・法務・人事で「どこまでを委託先の管理責任者経由にするか」の運用ルールを合意しておくことが、契約と実態のズレを防ぐ最短ルートです。

委託後に自社へ残す管理・モニタリング体制

契約を締結して開発が始まれば終わり、ではありません。監督責任が保険会社に残る以上、委託期間中・委託後の継続的な管理体制を自社側に構築しておく必要があります。

定期モニタリング・監査で確認すること

定期モニタリングは、少なくとも次のような項目を定期的なサイクルで確認する形にします。

• 開発進捗・品質状況（マイルストーン達成度・テスト消化状況・欠陥率）
• セキュリティ体制の運用状況（アクセスログ・権限変更履歴）
• 再委託先の変更有無と、変更があった場合の内容
• 委託先の要員体制の変動（主要メンバーの離任・追加）
• 委託先の経営状況・財務健全性（重要委託先の場合）

大手保険会社であれば専任のベンダーマネジメント部門がこれを担いますが、中小規模の保険会社・少額短期保険では専任者を置くのが難しいこともあります。その場合でも、月次の進捗会議に加えて、四半期ごとの体制確認・年次の監査という最低限のリズムを設計しておくことが、当局対応を含めた説明責任のベースになります。

レガシー刷新プロジェクトの進捗・品質を発注側で握るポイント

レガシー刷新プロジェクトは長期化しやすく、発注側の関心が薄くなると、委託先の判断が独走しがちです。発注側で握るべき論点は次のとおりです。

• 段階移行のマイルストーン（並行稼働の終了時期・カットオーバー時期）を発注側の合意事項として明確にする
• 業務ロジックの正しさ（保険料計算・責任準備金計算等）の検証は、必ず発注側の業務部門が主導する
• テストシナリオの主要な範囲は、発注側で承認する（委託先だけでシナリオを閉じない）
• 商品追加・料率改定などの並行案件と刷新プロジェクトの優先順位は、発注側で最終判断する
• スケジュール遅延の兆候（一定閾値を超える遅れ）は、経営層へのエスカレーション基準を事前に定めておく

「委託先が優秀だから任せる」のではなく、「委託先が動きやすいように発注側で意思決定のレールを敷く」姿勢が、レガシー刷新の成否を分けます。

インシデント発生時に発注側が担う初動と当局報告

情報漏えい・システム障害・不正アクセスなどのインシデントが発生した場合、対応の主体は保険会社側です。監督官庁への報告義務や契約者への通知義務は、委託先ではなく保険会社が負います。次のような初動の設計を、契約締結前に整えておきます。

• 委託先からのインシデント通知の受領窓口と、時間閾値（例: 認知後24時間以内）
• 初動の意思決定フロー（システム部門・コンプラ部門・広報・経営層のエスカレーションルート）
• 金融庁への報告可否・タイミングの判断基準
• 契約者・被保険者への通知が必要な場合の準備（通知文案・コールセンター体制）
• インシデント対応後の是正指示・再発防止策の受領と社内展開

インシデント時のスピードは、契約に書かれた「時間閾値」でほぼ決まります。契約時点で、当局報告のリードタイムから逆算した通知タイミングを合意しておくことが、有事の対応可能性を最も左右します。

まとめ｜監督責任を果たせる保険業界の外部委託にするために

保険業界のシステム開発外注が難しいのは、単に規制が多いからではありません。「外注しても、監督責任は保険会社に残る」という核心を、規制対応・レガシー刷新設計・委託先選定・契約条項・体制管理のすべてに一貫して落とし込む必要があるからです。本記事で整理した流れをおさらいすると、次のようになります。

• 保険業法・監督指針・FISC・金融分野個人情報保護ガイドラインが求める外部委託先管理の要点を押さえる
• レガシー基幹系の刷新手法（リホスト／リライト／リビルド）と段階移行を前提に、外注スコープを切り分ける
• 保険業界の実績・セキュリティ体制・再委託管理の観点で委託先を評価する
• 責任分界・監査権・報告義務・機微情報保護・データ消去・偽装請負回避を契約に盛り込む
• 委託期間中の定期モニタリング・レガシー刷新プロジェクトの進捗管理・インシデント初動を自社に残す

これらを整理できていれば、金融庁検査・内部監査・経営層のいずれに対しても、外部委託の意思決定と管理体制を説明できる状態になります。

次のアクションとしては、まず自社の委託先評価チェックリストを本記事の観点で棚卸しし、契約テンプレートに盛り込むべき条項の抜け漏れを確認するところから始めるのが実務的です。実務で使えるチェックリスト・契約条項テンプレートを揃えたお役立ち資料も併せて活用すると、社内法務・コンプラ部門との擦り合わせが進めやすくなります。

保険業界のシステム開発外注は、規制対応・レガシー刷新・委託先管理という難題を同時に成立させる、経営マターのプロジェクトです。外注先に任せきりにするのではなく、監督責任を果たせる形で発注側が意思決定のレールを敷くことが、刷新プロジェクトを座礁させない最大のポイントになります。