Embedded Insurance（エンベディッド・インシュアランス、組み込み型保険）がグローバルなinsurtechのトレンドの一つとなり、随分時間が経ちました。今更ではありますが、本記事ではできる限り具体的かつ日本の状況を考慮した上での論点整理を試みます。
Embedded Insuranceとは
Embedded Insurance（組み込み型保険）とは、なんでしょうか。一般的には「保険以外の他のサービスや製品に組み込まれる保険」などと言われるようです。おそらく、2019年頃に米国のインフルエンサーが「全ての企業はフィンテック企業になるんだ！」と、曖昧かつショッキングなことを言ったことからEmbedded Financeという文脈が始まっていると理解しています。UberでもStripeが使われてるよね※、決済は全てのサービスに関わるよね、決済に限らずサービスには金融コンポーネントが常にあるよね、的な文脈だと思います。
本記事では法的な役割分担の詳細は割愛しますが、じゃあその金融コンポーネントがどのようにサービスに組み込まれていくかというところで、ライセンス（e.g. 少額短期保険業ラインセンス）を持つか、それとも代理業として行うか、はたまたエネーブラー的な立ち位置の企業に手伝ってもらうかなどの選択肢がサービス提供者に与えられるわけです。
※正確にはUberでStripeが使われるようになったのは2023年になってからのようです。
そして、組み込み型保険の文脈では、様々なサービスがうまれたり、デジタル化されたりする過程で、そこに（意識され、もしくは意識すらされず）自然に保険が組み込まれるということなのです。
保険以外の金融と比べて、組み込み型のニーズは非常に高いと理解しています。これは、a)保険が生活（他のサービス）に密着した金融商品であることと、b)保険はネガティブをゼロにする商品であることゆえのCVRの難しさの両面からのものです。
以下、組み込み型保険について、具体的なFAQに答える形で論点について述べたいと思います。
エンベディッド・インシュアランスにデジタルは必要条件なの？
自然に保険が組み込まれるという意味では、サービス自体がデジタルであればデジタルであることは必要条件だと思います。ただ、例えば住宅ローンに団体信用保険が組み込まれていて、不自然さを感じるUXになっていないことでわかるように、デジタルでないものも、広い意味での（伝統的な）エンベディッド・インシュアランスと言えるかと思います。とはいえ、別に無理矢理言う必要もなく、この記事ではこれまで存在したような伝統的なものはエンベディッド・インシュアランスとは呼ばないこととします。
エンベディッド・インシュアランスの弊害はないの？
デジタルであればより自然に、もしくは少ない負荷で保険を組み込むことができる可能性が高い一方で、いわゆる意向確認が不十分になる可能性は高くなります。つまり、サービスの購入と保険の購入をサクサク行うことができる一方、保険の内容をきちんと確認せずに購買してしまう危険性です。
保険商品や配当率の考え方において「契約者の合理的な期待」という考え方があります。日本において、1996年の規制緩和までは保険商品はどこで買っても同じ内容でした。そこから既に30年あまりの時間が経ち、保険商品は多様化しています。デジタル非対面だろうがアナログ対面だろうが、普通はこういうことを期待するよね、というレベルをスタート地点とし、さらに保険会社としては契約者の効用関数が線形ではないことを理解して、win-winになる地点を模索することが意向確認を含むUXに関する重要な論点となります。
エンベディッド・インシュアランスは損害保険のみじゃないの？
損害保険はモノとサービスに関する保険ですから、モノとサービスがデジタル化すれば保険もデジタル化されることが期待されるため、事例としては圧倒的に多くなると思われます。実際に国内外の成功事例も損保系の方が多いです。
生命保険にはエンべディッド・インシュアランスはないの？
無くはないです。
後述しますが、エンベディッド・インシュアランスといっても様々な類型と手法があり、それらの組み合わせでCVR（成約率）を上げることは、生保分野においても間違いなく可能です。ただし、「組み込む先のサービス」が現段階においてあまり多くないというのが実態です。ただし、例えばこちらのレポートでは、損保の60%がエンベディッドでとしているのに対して、生保の30%がエンベディッドで、と予測しており、今後さらに拡大するとの見方もあります。
エンベディッド・インシュアランスと粘着性の関係は？
世の中には様々なサービスがありますが、最近のサービスは、「無料で始めることができて、使いながらサービスの価値を体験して継続するかどうかを検討する」というものが非常に多いのではないでしょうか？デジタルサービスはスケーラブルであるため、それが可能であるということかもしれません。また、デジタルサービスではな無くとも、近頃の製品には「リッチな説明書がない」ものが多いと思いませんか？これも使いながら慣れてもらうということです。
残念なことに、多くの保険ではこのような側面があることは稀です。
保険商品の構造上の特徴として、生損保いずれの分野でも、保険には「とりあえずやってみる」「使いながら慣れてみる」という、入口のハードルを下げつつもサービスを使い始めた後の粘着性を上げるような工夫があることが少ないのです。そのため、このある種の欠点を補完するようなサービスと保険を組み合わせることは、サービス全体のユーザーへの粘度を上げることに寄与し、これにより保険契約の入り口で必要となる意向確認などの負荷を減らすことができるのではないかという仮説を持っています。またすでに存在する方法でもありますし直近は様々な方法が出てきていますが、無料保険を活用した粘着性向上も有効な手段です。
エンベディッド・インシュアランスの類型
エンベディッド・インシュアランスにはどのような類型があるかについて、以下の図の通りまとめました。
類型については、商流に乗っていればいるほど自然な組み込みとなるため、CVRが高くなる傾向が明らかです。さらに、総付は全てのユーザーに保険を付保するため、任意付保に比べると必ず売上が高くなるわけですが、団体（や企業）が保険料を負担するので、その予算制約から、そもそもの団体成約のCVRが低くなる可能性があります。よって、まず商流の中で総付で少額の保険を付保し、その後に任意保険を募集するという類型を横断してユーザージャーニーを組み立てる形も１つのパターンとしてあり得ます。
エンベディッド・インシュアランス実現の方法論
このようなエンベディッド・インシュアランスを達成する方法論については、UXの観点と保険商品自体のカスタマイズの観点の２軸があります。
エンベディッド・インシュアランスの方法論において、UXの向上にはエンジニアリング技術的な困難性が伴いますが、非商流型であってもここを努力することでCVRを向上させることができます。保険商品自体を組み込み先のサービスに沿ってカスタマイズすることは、工夫をすればするほど、データや規制のハードルが高くなることになる一方、CVRを向上させるというよりは粘着性を高くするものであり、より良く保険商品を理解してもらったり、ロイヤリティを向上させることに寄与するものと思われます。テレマティクシスや健康増進保険の文脈で保険会社の収益率を向上させることも可能でしょう。
制約条件と様々な障害
上述したようなエンベディッド・インシュアランスの方法論（UXおよび保険商品特性）は、基本的にはやればやるほど効果が出るものですが、現実的にはリソース制約があるためそうはいきません。ここでは一般的にどういう制約が生じがちなのか、特に失敗例にフォーカスしてケーススタディします。
保険会社システムが、ID・Paymentとの情報連携できない
サービス提供者側にIDやPaymentの情報が存在しているケースがほとんどで、これを組み込まれる保険側に連携することはUX利便性の大きな向上となるため、どのような保険でも例外なくCVRが向上します。しかし、現実的に連携ができる保険会社システムは稀であり、非常に高価なシステム開発費が必要となります。
#システムに拡張性がない
オープンAPIを提供したが、使ってくれない・使いづらい
一般的に、サービス提供者がIT事業者である場合には、できる限り自然な保険導線の組み込みを希望します。その場合、保険会社がAPIをオープンに提供し、うまく保険を組み込むのがベストです。しかし、現実は、サービス提供者側のアプリではエンジニアの工数が足りず、APIだけを提供されても保険を組み込むことが困難という状況が散見されます。サービス提供者がIT企業でない場合は、エンジニアの工数というより既存システムがクローズドで構成されており、APIは無用であることも多く存在します。例えば、生保APIの会社であるBESTOW社でも、2020年にBESTOW Protect APIをリリースしましたが（それはLemonade社でも採用されています）、2022年にProtect Webというより短時間でリリースできるフロントエンドも含めたパッケージをリリースしているように見えます。
更に、多くのケースではサービス提供者は保険募集人で、”募集文章”たる保険募集導線は自由にUX設計ができず、保険会社の監修を受ける必要があります。このプロセスは想像以上にストレスがたまり、ボトルネックになることが多くあります。
#エンジニア工数不足 #募集文章
そこにその保険は要らないんだよ
ユーザーは組み込み先のサービスを利用・購入する際、明確な意思や目的を持って動いています。特にオンライン導線の場合にはより明確かつ能動的な目的意識を持っていることが多いため、かなりサービスにフィットした自然な保険商品でないと、CVRは低くなる傾向が顕著です。サービスへのフィット感が低くてもCVRが高くなるためには、ユーザーが納得できる低価格、法律などが要請する必要性、当該保険がカバーする保険事故がその時点で想起できるものであることなどの要素が必要となります。
なお、自然な保険商品にするために、必ずしもサービスに応じた保険商品設計、例えば保険給付構造の変更が必要ではないかもしれません。例えば、単純な定期保険を葬儀保険や飛行機墜落保険として売るなど。
#保険商品性がマッチしていない
サービス提供者のデータを保険商品に落とし込めない
保険組み込み先のサービス提供者は、非常に多くのユーザーデータを保有しており、それを活用した保険商品の組成を望んでいることが多くあります。データを用いることで他団体よりも安い保険料を実現できる可能性があったり、ユーザーの行動変容を促せると本業サービスに良い影響や社会的意義があったりするケースです。しかしながら、このようなケースにおける保険会社側のコスト増は、一般にデータ活用することによるCVR増よりも桁違いに大きくなってしまうことが多いです。これは保険商品の許認可のコストや、システム対応コストによります。ここは直近の潮流になりつつもありますが、少額短期保険を活用することはよい対応方法と考えられます。
#データを活用できない
ではどうしたら良いのか
ではどうすれば良いのか。エンベディッド・インシュアランスの原点に立ち戻って目的や意義について考えるとヒントが得られそうです。例えば、商流型のエンベディッド・インシュアランスがそもそもなぜ存在するのかというと、その商流のメインプロダクトのリスクヘッジです。そう考えると、保険だけでなく、保証やサポートサービスなどを組み合わせたユーザー体験設計全体で、そのプロダクトを安心して買うこと、使うことを後押しするのが本質であるとわかります。
そこで、リターンとして上がるであろうメインのプロダクトの売上向上やリピート率向上、保険販売による上乗せ収入などを加味して、エンベディッド・インシュアランス提供による効果の仮説を立てることが出来るでしょう。
一方で、非商流型の保険の場合は効果が見えづらいです。その場合、まずは開発工数をミニマムにし、一般的によく売れている商品をライトに試す導線で、LP来訪者などから分母となる数を見極めるのもありです。その上で、〇〇ペイや〇〇ポイントで支払いなど、ユーザーにとってその保険をこのチャネルで買うべき理由が明確になるような、コンバージョン率を上げる施策の実施に移っていくのも一案です。
そんなエクササイズを通して、ちょうど良いシステム投資のタイミングやレベル感が見えてくると思います。
少短設立Naviはこちら
