InsureMO | インタビュー掲載

インタビュイー：
InsureMO株式会社 代表取締役 河上 氏

InsureMOとはどのようなサービスですか？開発の背景もあわせて教えてください

InsureMOは、クラウドネイティブのマイクロサービスで保険業務を支える、保険ミドルオフィス・プラットフォームです。私たちが把握している限り、マイクロサービスで保険の仕組みをここまで体系的に実現しているのは、世界的に見ても当社だけだと考えています。コンテナで構築し、ドメイン駆動設計に基づいて最適化されたマイクロサービスがきちんと連携して動いている、そういう設計になっています。

背景には、当社のCEOの大きな決断があります。私たちはもともと、保険会社向けにパッケージ製品を提供していました。当時としては評価いただいていた製品なのですが、モノリシックの仕組みである以上、改修するとあちこちに影響が出ますし、カスタマイズも基本的にしたくないしすべきではない。そうすると、お客様としては「やりたいことができない」「カスタマイズで費用がかかる」「保守が難しい」となってしまうわけです。これは結局、お客様を幸せにしないとCEOが判断しまして、思い切ってそのパッケージは販売停止にしました。そのうえで、マイクロサービスを組み合わせて構築する全く新しいプラットフォームとしてInsureMOを作り直したという経緯です。

経済産業省が「2025年の崖」として、モノリシックなレガシーシステムからの脱却とマイクロサービス化を打ち出していますが、保険業界に対してその課題にきちんと正面から応えられているのが、当社の立ち位置だと考えています。コアシステムと販売チャネルの双方を、Middleレイヤーとしてつなぐ。コアの刷新も、既存コアを活かしたままチャネル接続のハブとして使うことも、どちらも一つのプラットフォームで対応できる点が特徴です。

どのようなお客様から、どのようなご相談が寄せられていますか？

大きく二つに分かれます。一つは、保険会社のコアシステムをモダナイズしたいというご相談です。これは既存の仕組みを刷新したいというお話なので、要件としては比較的わかりやすいです。もう一つは、新しいビジネスを立ち上げたい、新規のチャネルにAPI経由で保険商品を提供したいというご相談で、こちらが非常に増えています。

後者については、私たちも最初は予想していなかった引き合いが多く来ていまして、銀行様、カード会社様はもちろん、聞き馴染みのある様々な事業会社様からもご相談をいただいています。海外ではスタートアップの会社様がOEMで当社の仕組みを自社サービスとして販売するケースもあって、本当にいろいろな形でお使いいただいています。パッケージではないので「これしかできない」という制約がなく、お客様が「あったらこんなことができる」と自由に発想できるのが、お声をいただきやすい理由なのかなと思います。

「組込型保険」の代表的な導入事例についてご紹介いただけますか？

まずわかりやすい事例として、大手ECサイトでのペット保険があります。これは、あいおいニッセイ同和損保様の子会社であるリトルファミリー少額短期保険様がご導入されているものです。サイトに入ると、お客様は最後まで保険会社の名前を一切意識せず、サイト中で完結して保険にお申し込みいただけます。背後で大手ECサイトのAPIとリトルファミリー様、そしてInsureMOがつながっています。お客様は住所や年齢、決済情報を再入力する必要がありません。これが、私たちが考える「正しい組込型保険」だと思っています。

海外ではさらにダイナミックな事例があります。インドのタクシー配車アプリOla様では、当社のAPI経由で1日100万件の保険契約を処理しています。連携を実現するまでにかかった期間は10日間。配車アプリで車を呼ぶと、GPSの行き先情報をもとに「空港に向かうなら旅行保険」というように動的に商品をリコメンドして、その場でお申し込みまで完結する仕組みです。あとはインドの鉄道予約サービスで、チケット購入時に保険を組み合わせて朝夕の4時間で70万件売れている事例もあります。

MACHアーキテクチャを保険業界で採用する意義について教えてください

MACHはMicroservices、API-first、Cloud-native、Headlessの頭文字で、グローバルでクラウドネイティブの標準的なアーキテクチャとして規定されています。当社はこのMACHを保険業界向けに本格的に実装している、おそらく唯一のプラットフォームだと認識しています。

保険業界の特性として、生命保険であれば10数年単位の長期データを保有・保管する必要があり、商品種別ごとの仕様差や規制要件も非常に複雑です。だからこそ、モノリシックな仕組みでは限界がきます。マイクロサービスで部品化し、APIで疎結合に組み合わせていけば、新しい商品や新しいチャネルが出てきたときに、必要な部品だけを増やしたり差し替えたりして対応できます。クラウドにただ載せるのではなく、AWSやAzureの仕組みの力を100%引き出すレイヤードアーキテクチャになっているのが、私たちのクラウドネイティブの考え方です。

細かな話ですが、データベースに対しても、当社はAPI経由できちんと完結させる設計にしています。他社様の中には直接SQLを発行できるようにしているケースもあるのですが、それをやってしまうと整合性が取れなくなったり、ロールバックできなくなったりするので、私たちはAPIで一貫させています。こうしたところまでこだわって作っているのが、MACHを「掛け声」で終わらせないために大事な部分だと考えています。

2,000以上のアトミックAPIと17,500以上の商品テンプレートは、どのように組み合わせて使えるのですか？

当社が提供しているAPIは、特定の顧客要件に依存しない粒度まで分解された「アトミックAPI」です。たとえば保険金請求まわりだけでも189個のAPIがあって、引受、受付、計算、支払判定といった一連の業務プロセスを部品単位で組み合わせていけるようになっています。お客様は、自社が必要な部品を組み合わせて、自分たちの業務に合わせた仕組みを構築できます。

業界の中には「APIを標準化していこう」という議論もありますが、私たちとしては、ECサイトとクレジットカード、スマホ決済サービスが全く同じAPIで動けるはずがないと考えています。それぞれが提供している情報も求めているものも違うので、相手側のAPIに合わせ込んでいく柔軟性こそがプラットフォームの仕事だと思っています。だから当社は、既存のアトミックAPIを揃えるだけでなく、新しいAPIを高速で作れるDevOps基盤と、後ほどご紹介するAIコーディング環境も合わせて提供しているわけです。

商品テンプレートについては、世界中の生命保険、損害保険、投資商品、団体保険、変額保険、収入保障保険など、難易度の高い商品を含めて17,500以上をテンプレート化しています。日本市場固有の商品にも対応していて、設定するだけでデータベースの論理設計・物理設計が自動的に生成される仕組みになっています。商品ごとの引受ルール、年齢制限、査定ルール、リスクルールまでテンプレートに含まれているので、漏れや重複が出にくい。当社では「カスタマイズ」という言葉は使わず、「部品を組み合わせて作る」というアプローチで対応しています。

保険会社のコアシステムや販売チャネルへの接続はどのように対応されるのですか？

共同ゲートウェイのような業界共通基盤への対応も含めて、基本的にはすべて対応可能です。当社の大きなパートナーであるNTTデータ様が手掛けられている領域は当然カバーできますし、現在では15社以上のパートナー企業様と連携しています。デロイト様、EY様、IBM様、NTTソリューションズ様、フューチャーアーキテクト様といった大手の企業様が、当社のプラットフォームをご販売・インテグレーションいただける体制になっています。

接続そのものは、APIでつなげるのが理想ですが、現実にはコアシステム側がCOBOLで動いていたり、Javaで作られていたり、Apache Sparkを使っていたりと、いわゆる「個社要件」になります。そこは私たちのほうで対応することもありますし、パートナー様が手掛けるケースも多くあります。「コネクターを用意していますからすぐつながります」という売り文句を耳にすることがありますが、現実にはほぼ当てはまらないというのが、私たちの率直な見方です。要件ごとに丁寧に作り込んでいくのが結局は最短だと考えています。

2026年3月から提供開始された「AIコーディング」と、AIエージェント機能について教えてください

当社のAI活用は、大きく二つの方向で進めています。一つが「AIコーディング」、もう一つが業務自動化のための「AIエージェント」です。

AIコーディングは、保険専用のAI開発環境です。ご存じの通り、Claude CodeのようなLLMベースの開発ツールでアプリケーションを作ろうとすると、大規模なシステムや業務知識が必要な領域では限界があります。保険の業務知識をプロンプトに入れようとしても、そもそも言語化できる人がいなければ要件定義に8ヶ月、10ヶ月とかかってしまう。そこで当社は、AIが読めるように設計した「AIフレンドリーAPI」を提供しています。このAPIを介してLLMに保険の業務知識を渡せるようにしたうえで、UIの振る舞いや配色をプロンプトで指示すると、5分程度で画面が出来上がります。社内では、海外旅行保険の申込画面を80分のうちに20回ほどイテレーションをかけて作り上げたケースもあります。要件定義から実装まで数ヶ月かかっていた工程が、ここまで圧縮されてきています。

もう一つのAIエージェントは、保険会社や代理店の業務を無人化する方向の機能です。たとえば、海外旅行中のお客様が空港で「飛行機が遅れていますが、保険は出ますか」とチャットで聞いてきたとします。当社のAIエージェントは、その場でお客様の契約状況をAPIで確認し、外部のフライト遅延情報(FlightAware等)も確認したうえで「現在2時間半の遅延ですが、当該保険は12時間以上の遅延で支払対象になるため、現時点では支払対象外です」と回答できます。重要なのは、計算をLLMに任せていない点です。AIにブラックボックスで計算させると金融庁のガイドラインに抵触しますし、ハルシネーションのリスクもあります。当社はAPIを介してデータベースから根拠を引き出す設計なので、エビデンスをきちんと残せるようになっています。

代理店様向けには、商品知識の照会をAIエージェントが代行するソリューションも、PoCを中心に複数社で進めていただいています。「この商品はこの保証がつくのか」「この条件で売れるのか」といった照会を、AIが保険会社側のナレッジに基づいて即座に返す仕組みです。

データ基盤、規制対応、セキュリティについて教えてください

データ基盤としては、データレイクとデータマートを当社のプラットフォーム向けに最適化しています。エンドユーザー様でも分かりやすいデータ構造になっており、申込・支払・問い合わせなど各業務プロセスで再利用しやすい設計です。サイロ化された保険会社のデータをマッシュアップして、レポートや問い合わせ業務にそのまま使える形にしています。すべての制限事項や監査項目は金融庁様に届け出て承認を取得しており、信頼性は十分に担保しています。

セキュリティ面では、AWSとのパートナーシップが大きいです。AWS Service Ready Certificationsを直近1年で7件取得しており、海外からのアクセス制限やデータベースへのアクセス権限を限られた人にしか付与しないといった統制を、AWSの仕組みを最大限活用して実装しています。なお、InsureMOはシンガポール発の製品ですが、金融庁様からはシンガポール製品として既にご認知いただいており、地政学的リスクへの対応として、その点も明確にしています。

規制対応については、改正保険業法や経済安全保障の文脈で、今年から会計監査法人による内部監査のプロジェクトも予定しており、第三者の観点での信頼性確保もさらに進めていきます。

日本市場での導入実績と、定量的な成果について教えてください

日本国内での導入実績は、今月のご導入分も含めて32社（2026年5月時点）となります。生命保険会社様、損害保険会社様、大手SI様の案件が豊富です。具体例としては、大手カード会社が提供するブランドの証券の仕組みを当社で全面的に構築させていただいています。JCB様にもご導入いただいております。

定量的な成果として本件は、要件変更があった中でも約4ヶ月で立ち上げ、エラーなく稼働しています。証券料率改定への対応では、コストとスピードが従来のおよそ2分の1まで圧縮できた事例も出ています。

他の事例では、エコシステム全体で9ヶ月の構築、その後の各チャネル展開は2ヶ月程度。大手ECサイトでのペット保険でも数ヶ月レベルで同社との連携と複数商品のリプレース・並行リリースを実現できています。AIコーディングを併用すれば、従来「何ヶ月」だった工程が「何日」「何時間」レベルまで短縮できる見込みです。

どのような企業に向いていますか？逆に不向きなケースがあれば教えてください

正直に申し上げると、「向いていない」と言い切れる企業様はあまりないかなと思っています。ただ、私たちが最も力を発揮できるのは、「マイグレーション」ではなく「モダナイゼーション」を目指される企業様です。

「コンバージョン」のように、COBOLをJavaに移すだけ、オンプレからクラウドに移すだけ、というプロジェクトに3年・5年と10億円・100億円をかけられているケースをよく耳にしますが、それで業務自体は何も変わらないことが多い。当社のプラットフォームは、そういう用途でも使えなくはないのですが、おそらく面白さは半減してしまいます。

逆に、「新しいシステムでこういう新しいビジネスをやりたい」という具体的な夢を持っていらっしゃる企業様には、当社の仕組みは非常に噛み合うと思っています。たとえとして適切かわかりませんが、大谷翔平選手や本田圭佑選手が「プロになりたい」ではなく「プロになって◯◯したい」という具体的なビジョンを持って結果を出されているのと同じで、「システムを入れること」が目的ではなく、その先にやりたいことが明確に見えているお客様ほど、私たちのプラットフォームの価値を引き出していただけます。

料金体系はどのようになっていますか？

基本構成としては、InsureMOプラットフォーム機能(基本パッケージ)、AWSなどのインフラ費用、24時間のAPI監視やバージョンアップを含む保守費用がベースになります。お客様の規模やニーズに合わせて、柔軟に設定しています。

そのうえで、保険商品の数に応じた課金を組み合わせています。逆に、API使用数、ユーザー数、チャネル数、接続数といった「使い込みの量」はカウントしておりませんので、自由にお使いいただける設計です。マネタイズしていただけないと意味がないので、お客様のビジネスモデルに合わせて柔軟に設計するスタンスです。

今後の展望と、保険業界に伝えたいメッセージを教えてください

当社はこれまで「APIファースト」を掲げてきましたが、今後は「APIとAIファースト」のプラットフォームへと進化させていきます。APIとAIを組み合わせることで、保険業界全体のオートメーション化、STP化、無人化、さらに高度な顧客接点をより速く・安く実現できる世界観を作っていきたいと考えています。日本のエコシステムは、インドや中東、東南アジア、中国などに比べると正直まだ後発の位置にあると感じていますので、当社が橋渡し役となって、新しい体験をどんどん日本市場に持ち込んでいきたいと思っています。

最後に、業界の方々にどうしてもお伝えしたいことがあります。「過去にスクラッチで作ったら要件が膨らんで失敗したから、今度はパッケージを入れる」とおっしゃる企業様が、いまだに多くいらっしゃいます。ただ、冷静に考えてみると、パッケージを入れたからといってお客様の要望が小さくなることはありません。やりたいことの本質は変わらないのに、パッケージという制約に無理やり合わせると、結局「A'をやりたいのにAしかできません」「カスタマイズすると追加費用です、聞いていません」というトラブルが繰り返されます。

本当に必要なのは、パッケージという「完成品」ではなく、テンプレート・サンプル・ベストプラクティスといった「正しい部品と参考形」だと、私たちは考えています。当社はパッケージではなく、お客様がやりたいことを実現するための部品とテンプレートを提供するアプローチを取っています。このメッセージは、これからも業界に対してきちんと発信していきたいと考えています。

まとめ・編集部コメント

InsureMO株式会社が提供する「InsureMO」は、クラウドネイティブ・マイクロサービスで構成された保険ミドルオフィス・プラットフォームです。保険会社のコアシステムと販売チャネルをMiddleレイヤーでつなぎ、コアシステムの刷新からチャネル接続のハブ機能まで、一つのプラットフォームで柔軟に対応できる点が大きな特徴となっています。

「パッケージではなく部品の組み合わせで構築する」という思想は、コアシステム刷新を控える保険会社様にとっても、API連携で新しい保険体験を作りたい銀行・カード会社・事業会社様にとっても、有力な選択肢となるサービスです。組込型保険や保険業務のモダナイゼーションを検討されている企業様は、一度相談してみる価値のあるサービスだといえます。