2024-12-07 AWS re:Invent 2024: ジェネレーティブAIで実現する保険業界の変革 - DXCとAWSのソリューション

※本記事は、AWS re:Invent 2024のセッション「Accelerate insurance transformation using gen AI and data analytics (ANT201)」の内容を基に作成されています。このプレゼンテーションはAWSパートナーであるDXC Technologyによって提供されました。セッションの詳細情報はYouTube（https://www.youtube.com/watch?v=z4fDDu8Yvzg ）でご覧いただけます。

本記事では、DXC Technologyの代表者によるライトニングトークの内容を要約しております。この発表では、保険業界が直面している規制要件の変化、顧客期待の変化、保険金請求の深刻度と頻度の増加に対応するため、クラウドを活用したデジタル主導の変革についての知見が共有されました。

なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご覧いただくことをお勧めいたします。

AWS re:Inventについての詳細情報は https://go.aws/reinvent 、その他のAWSイベントについては https://go.aws/3kss9CP をご参照ください。

1. 保険業界におけるAI導入の課題

1.1 プロジェクトの本番環境移行と資金調達の難しさ

保険業界では、AIに関して非常に有望なパイロットプロジェクトが数多く立ち上がっていますが、これらの取り組みを本番環境に移行することが大きな課題となっています。私たちが観察している状況では、CEOや取締役会からの好奇心や推進力は強く、IT部門の上級幹部（CIO、CTO、CDO）からも「AIが会社にどのような価値をもたらすか」という問いかけが絶えません。

しかし、特に初期段階において、AIの取り組みを開始するための資金調達は困難なことが多いです。これはいくつかの要因が組み合わさった結果です。技術的な側面だけでなく、経営層からの期待と実際の導入ハードルの間には大きなギャップが存在しています。私が日々接している保険会社では、AIの可能性への期待は高いものの、実際の投資判断に至るまでには多くの障壁があることが現実です。

プロジェクトの本番環境への移行の難しさは、単に技術的な課題だけではなく、組織全体のコミットメントや資源配分の問題とも密接に関連しています。先進的なAIパイロットが有望な結果を示しても、それを大規模な本番環境に展開するには、継続的な投資とリソースの確保が必要です。そして実際のところ、多くの保険会社では初期投資の大きさと不確実性が、本格的な取り組みへの移行を躊躇させる要因となっているのです。

1.2 内部スキル不足とデータ準備の問題

最も一般的な課題として、まず内部スキルの不足が挙げられます。AIやジェネレーティブAIの活用には専門的なスキルが必要ですが、それだけではありません。AIや機械学習の価値を本当に引き出すためには、データを適切に準備する必要があります。

データの準備状況は別の大きな課題です。多くの組織では、異なるプラットフォームに対してリバースエンジニアリングを行う必要がありますが、これは保険業界においては特に問題が深刻です。なぜなら、保険会社は通常、合併や買収によって成長してきた歴史があるからです。その結果、複数のレガシーシステムが複数の組織体に存在し、それらを統合する必要があります。

データの洗浄や準備も不可欠です。AIや機械学習の出力は、入力されるデータの質に大きく依存するのです。データが適切に整理され、品質が高くなければ、どれほど優れたAIモデルを構築しても、その価値を十分に引き出すことはできません。保険業界の複雑なデータ環境においては、データの準備と標準化が特に重要な要素となります。

1.3 M&Aによるレガシーシステムの複雑化

保険業界では、合併や買収による成長が一般的であり、これが複雑なシステム環境を生み出す主な要因となっています。私が説明したように、「保険会社はしばしば合併・買収によって成長するため、この問題は特に深刻です」。成長するたびに新たなレガシーシステムが加わり、それぞれが独自のデータ構造やビジネスロジックを持っています。

これらの複数のレガシーシステムは、複数の事業体にまたがって存在し、それぞれが独自の方法でデータを管理しています。これらシステムからデータを統合しようとすると、多くの場合リバースエンジニアリングが必要となります。システムごとに異なるデータ形式、異なるコード体系、異なる業務プロセスが存在するため、単純なデータ抽出だけでは不十分なのです。

このような環境では、データの整合性を保ちながら統合することが極めて困難です。各システムはそれぞれの時代に、それぞれの目的で設計されているため、現代のAIや分析ニーズに対応できるようなデータ設計になっていないことがほとんどです。M&Aの歴史が長い保険会社ほど、この複雑性は増大し、AI導入の障壁となっています。

1.4 エンジニアリングソリューションの高コストと日常業務優先の現実

AIソリューションを実装するにあたって、もう一つの問題はエンジニアリングソリューションの高額な初期コストです。これはインフラの観点からというよりも、開発とエンジニアリングの側面からの課題です。もちろん、クラウドはインフラ面でのコスト削減に役立ちますが、それでもAIの価値を活用するためには多くの開発とエンジニアリング作業が必要となります。

そして現実的な問題として、通常は「ライトを付けておく」こと、つまり日常業務の維持が最優先事項となります。このため、多くの実験的なAI導入は、より緊急性の高いニーズのために後回しにされてしまいます。保険会社の多くは、既存システムの運用と保守に多くのリソースを割かなければならず、革新的なAI取り組みに十分な資源を振り向けられないのが現状です。

これらの日常業務と革新的なプロジェクトのバランスは常に難しい課題です。経営陣は革新を求める一方で、業務の連続性と安定性も確保しなければなりません。その結果、多くの有望なAIプロジェクトは、「もっと緊急なニーズ」が解決されるまで棚上げされることになるのです。この優先順位の問題がAIの本格導入を遅らせる大きな要因となっています。

2. DXCとAWSによるソリューションアプローチ

2.1 AWS Insurance Lakeを基盤としたプラットフォーム

DXCはこのような課題を解決するためにAWSとパートナーシップを組み、保険業界における独自のポジションを活かしたソリューションを開発しました。私たちの強みを考えてみると、AIや機械学習ソリューションの構築に必要なデータの多くは、実はコアシステムから来ています。そしてDXCは、この分野における最大手ベンダーなのです。

これは重要なポイントで、私たちは多くの保険会社のデータを管理しており、そのプロセスと活用方法を理解するスキルを持っています。そこで私たちが開発したのは、AWS Insurance Lakeを基盤としたプレビルドソリューションです。AWS Insurance Lakeは素晴らしい出発点であり、保険向けのデータプラットフォームを構築するためのキャンバスを提供しています。

DXCの役割は、このAWS Insurance Lakeを完成させることでした。私たちは様々なシステムからデータを統合するコネクタの作成、データのクレンジング、保険会社が理解し組織化できるデータモデルの構築などに多くの労力を投じました。さらに、このデータをビジネスプロセスに接続して実際の価値を提供できる機械学習モデルとジェネレーティブAIのユースケースも開発しています。

基本的に私たちは、保険業界の典型的な状況に合わせられるプラットフォームとユースケースのセットを提供しています。必要なカスタマイズは最小限で済み、わずか2〜3ヶ月でパイロットケースを開始できるのが特徴です。こうした迅速な導入サイクルにより、保険会社はAIの価値を短期間で実感することができます。

2.2 データ連携コネクタとデータモデルの構築

私たちのプラットフォームの主要機能をもう少し詳しくご説明しましょう。AWSの上に私たちが構築した機能的なコンポーネントには、保険業界に必要な典型的な要素がすべて含まれています。まず、左側にはソースシステムの一覧があります。私たちはDXCのプラットフォームへの事前作成済みコネクタだけでなく、CRMやその他の外部システムなど、保険会社がデータを取得する一般的なソースへのコネクタも用意しています。

これらのコネクタは、異なるシステムからデータを抽出し、統合するための重要な役割を果たします。保険業界の複雑なシステム環境を考えると、こうした事前構築されたコネクタの価値は非常に大きいものです。各システムの独自性を理解し、データを正しく抽出するための専門知識が込められています。

さらに、私たちはデータレイクと保険データモデルを構築しました。これにより、企業がすでに持っている企業データハブやデータウェアハウスと統合することも、新しいデータ基盤の土台として利用することもできます。データが完璧に整理された状態になるのです。

このデータモデルの上には、データカタログを配置しています。これによってデータを利用可能かつ説明可能にします。これは企業が独自のモデルやアプリケーションを構築するための基盤として活用できます。データ連携とモデル構築の両方において、豊富な経験に基づいた最適化された設計を提供しているのが私たちのソリューションの強みです。

2.3 多様なソースシステムとの統合機能

私たちのソリューションの左側には様々なソースシステムがあります。私たちはDXCのプラットフォームへの接続コネクタを事前に作成していますが、それだけではありません。CRMや保険会社がデータを取得する可能性のある外部システムなど、一般的なソースへのコネクタも用意しています。

これらのコネクタは、多様なシステムからのデータ統合を容易にするために設計されています。保険業界の複雑なシステム環境では、データソースが多岐にわたるため、これらの事前構築されたコネクタが大きな価値を持ちます。私たちはDXCのコアシステムに精通しているため、データの抽出と変換に関する深い知見を持っています。

また、コネクタは単にデータを抽出するだけでなく、データの品質と整合性を確保するための処理も行います。異なるシステムから抽出されたデータは、フォーマットや構造が異なることが多いため、統合前に標準化する必要があります。私たちのコネクタは、このプロセスを自動化し、データの整合性を維持しながら効率的に統合できるよう設計されています。

保険会社がM&Aによって成長してきた場合、複数のレガシーシステムが存在することが一般的です。私たちのソリューションは、これらの異なるシステムからデータを統合し、単一の一貫したビューを提供することで、分析とAIの活用を可能にします。データソースの多様性を管理することは、AI導入の成功において不可欠な要素であり、私たちのソリューションはこの課題に直接対応しています。

2.4 BI報告機能とアプリケーション統合用API

私たちはこのデータモデルの上に、基本的な機能も含めた完全なセットのBIレポートを構築しました。これらはHR、運用、財務、保険数理など多くの分野をカバーしています。これらのレポートは、多くの場合、AWSにデータを取り込む投資の正当化として役立ちます。データがAWS環境に取り込まれれば、このデータを活用して最も革新的なユースケースをサポートすることができるのです。

データを最大限に活用するために、私たちは完全なAPIセットも作成しました。これらのAPIはアプリケーション統合を可能にし、さらにイベントカタログも用意しています。このイベントカタログはKinesisとEventBridgeを活用しており、アプリケーションにデータを公開するためのものです。

具体的には、KinesisとEventBridgeを使用してデータをアプリケーションに公開し、もちろん特定の分野をサポートするためのいくつかの機械学習モデルとジェネレーティブAIモデルも構築しています。これらのモデルはデータを活用して、ビジネスプロセスと接続し、実際の価値を提供します。

このようなAPIとイベント駆動型のアーキテクチャにより、保険会社は既存のアプリケーションや新規開発するアプリケーションとシームレスに統合できます。データが単に保存されるだけでなく、リアルタイムで活用可能な状態になることで、ビジネスの俊敏性と効率性が大幅に向上します。私たちのソリューションは、データの保存から活用までの全サイクルをカバーしているのです。

2.5 2-3ヶ月での導入パイロット開始の実現

基本的に私たちが提供しているのは、典型的な保険業界の状況に合わせられるプラットフォームとユースケースのセットです。必要なカスタマイズは最小限に抑えられており、パイロットケースはわずか2〜3ヶ月で開始できるようになっています。これは保険業界においてAIプロジェクトを導入する際の一般的なタイムラインと比較して非常に短期間です。

この短期導入を可能にしている要因は、事前構築されたコネクタ、データモデル、そして業界固有のユースケースをパッケージ化した私たちのアプローチにあります。保険会社は一からデータパイプラインを構築したり、AIモデルを開発したりする必要がなく、すでに検証済みの構成要素を利用して迅速に価値を創出できます。

通常、保険会社では社内リソース不足や複雑なデータ環境により、AIプロジェクトの立ち上げには6ヶ月から1年以上かかることも珍しくありません。しかし私たちのソリューションを活用することで、この時間を大幅に短縮し、早期に成果を出すことができます。

パイロットからスタートすることで、リスクを低減しながら段階的に導入を進めることができます。最初の成功体験が次のステップへの投資を正当化する材料となり、AIの導入と活用の好循環を生み出します。2〜3ヶ月という短期間でのパイロット開始は、保険会社が「できるかどうか」という疑問から「どれだけの価値があるか」という議論へと焦点をシフトさせる重要な転換点となるのです。

3. 保険業界向けユースケースとデータ活用

3.1 販売・流通分野への焦点（クロスセル、解約防止など）

ここで、私たちがサポートしている典型的なユースケースの例をいくつか紹介します。まず、私たちは出発点として「流通（ディストリビューション）」に焦点を当てています。クロスセル、アップセル、解約防止、代理店トレーニング、顧客の獲得（ウィンバック）、新規ビジネスなどの機能を提供しています。

これらは特に流通部門の責任者や販売チャネルの責任者にとって、最も関心の高い分野です。なぜなら、追加の収益という形で即座に価値を提供できるからです。顧客の解約を減らし、既存顧客へのセールスを増やすことは、投資回収が早く、データをプラットフォームに取り込むための投資を正当化するのに役立ちます。そして一度データがプラットフォームに入れば、他のユースケースも探索できるようになります。

例えば、クロスセルとアップセルのモデルは、既存顧客に対して追加商品や上位商品を提案することで収益を増やします。また、解約防止機能は、離脱リスクの高い顧客を特定し、事前に対策を講じることができます。代理店トレーニングでは、成功している代理店の手法を分析し、他の代理店にそのベストプラクティスを教えることができます。

これらの流通分野のユースケースは、短期間で具体的な成果が見えやすく、数字で効果を測定しやすいという利点があります。追加収益の獲得や顧客維持率の向上という形で、投資に対する明確なリターンを示すことができるため、多くの保険会社にとって、AI導入の最初のステップとして最適なのです。

3.2 多様なデータソースの統合と活用

このようなモデルが良好に機能するために必要なデータの種類について説明します。一般的に保険会社は、すでに持っているデータを分析し、データリポジトリを構築しようとしています。そしてデータを整理しようとしているのです。

まず、顧客がポータルやコールセンターを通じて行うインタラクションなど、従来はサイロ化されていたデータがあります。次に、第三者から取得するデータもあります。例えば、保証人（エンドーサー）からのデータや、政府から提供されるオープンデータなども含まれます。これらは顧客へのより良いターゲティングとアプローチを提供するためのシグナルとして活用できます。

さらに、顧客自身の行動データも重要です。あらゆるチャネルを通じたすべての顧客接点が対象となります。過去の保険金請求、過去に所有していた商品、あるいは顧客の家族に関するデータ、または保険会社が提供するサービスとエンドーサーが提供するサービスとの間の接続も考えられます。例えば、バンカシュアランス（銀行と保険の連携）や他のどんな関係性も、このデータモデルに保存して活用できます。

これらは推奨エンジン、特に解約予測の品質を向上させるためのシグナルとして使用されます。レコメンデーションの品質は、提供されるデータの質に大きく依存します。だからこそ、完全なデータセットを持つことは、適切な結果を提供するための良いモデルを持つことと同じくらい重要なのです。

3.3 顧客行動データと外部データの連携

顧客自身の行動データは非常に重要な要素です。私たちが収集するのは、あらゆるチャネルを通じたすべての顧客タッチポイントに関するデータです。これには顧客がポータルサイトで行った操作から、コールセンターとのやり取りまで含まれます。

さらに重要なのは、過去の保険金請求履歴や、顧客が過去に所有していた商品に関する情報です。こうした履歴データは、将来の顧客行動を予測する上で非常に価値があります。また、顧客の家族に関するデータも重要です。保険は世帯単位で検討されることが多いため、家族構成や家族のライフイベントに関する情報は、適切な商品提案のための重要な手がかりとなります。

外部データとの連携も見逃せません。保険会社が提供するサービスと、エンドーサー（保証人）が提供するサービスとの間の接続関係も活用できます。例えば、バンカシュアランス（銀行と保険の連携）のケースでは、銀行口座や金融商品の情報と保険商品を連携させることで、より的確な提案が可能になります。

これらのさまざまなデータソースからの情報は、すべてデータモデルに保存され、顧客理解を深めるためのシグナルとして使用されます。モデルの推奨や解約予測の精度は、これらのデータがどれだけ充実しているかに大きく依存します。多様なデータ間の関連性を見出し、意味のあるパターンを特定することで、顧客へのアプローチをパーソナライズし、適切なタイミングで適切な提案を行うことができるのです。

3.4 データの質とAIモデル精度の関係性

推奨エンジン、特に解約予測の品質は、提供されるデータの質に大きく依存しています。だからこそ、完全なデータセットを持つことは、良いモデルを持つことと同じくらい重要なのです。実際、AIの世界ではよく「ガベージイン・ガベージアウト（粗悪な入力からは粗悪な出力しか得られない）」という言葉が使われますが、これは特に保険業界に当てはまります。

データの質が高く、包括的であればあるほど、AIモデルの予測精度は向上します。例えば、顧客の過去の行動パターン、商品利用履歴、問い合わせ記録、支払い状況などの情報が充実していれば、その顧客が将来解約する可能性や追加商品に興味を持つ可能性をより正確に予測できます。

また、データの鮮度も重要な要素です。古いデータだけに基づいた予測は現在の顧客行動を反映していない可能性があります。保険会社は継続的にデータを更新し、最新の顧客インタラクションをモデルに反映させる必要があります。

さらに、データセットの多様性もモデル精度に大きく影響します。単一のソースからのデータだけでなく、社内データと外部データを組み合わせることで、顧客の全体像をより正確に把握できます。例えば、内部の商品保有データに加えて、オープンデータや市場トレンド情報を統合することで、モデルの文脈理解が深まります。

結局のところ、AIモデルから得られる洞察や推奨の価値は、入力されるデータの質と完全性に直接比例するのです。どれだけ高度なアルゴリズムを使用しても、不完全または低品質のデータでは、最適な結果を得ることはできません。

4. 代理店支援AIシステムの実例

4.1 機械学習とジェネレーティブAIの組み合わせ

今から顧客データがどのように活用できるかの例を示したいと思います。特に代理店と顧客のインタラクションに焦点を当てます。デジタル化が進む中でも、代理店は依然としてほとんどの保険会社にとって主要な販売チャネルです。特に生命保険のような複雑な商品の販売においては代理店の役割が重要です。しかし、損害保険や医療保険においても、複雑な議論や複雑な販売はほとんどが代理店を通じて行われています。

そのため、代理店の価値を示す良い例だと考えました。この事例では、顧客ではなく代理店をターゲットにしており、機械学習とジェネレーティブAIを組み合わせて販売サイクルをサポートしています。

基本的に3つのステップがあります。最初のステップでは、システムが代理店に連絡すべき適切な顧客を選定するのを支援します。例えば、解約する可能性が高い顧客や、過去の履歴や他の顧客との類似性に基づいて追加の特約や追加商品を購入する可能性が高い顧客などが対象となります。

2番目のステップでは、代理店が会話の準備ができるように、提案する商品の正確な組み合わせを定義します。3番目のステップでは、アポイントを取り、顧客との会話を管理するために代理店が必要とするすべてのコンテンツを生成します。ここでジェネレーティブAIが活躍します。推奨モデルからの入力を取り込み、代理店が議論するためのコンテンツを生成するのです。

このように、AIが代理店の業務を支援することで、より効率的かつ効果的な顧客対応が可能になります。機械学習による顧客選定と商品推奨、そしてジェネレーティブAIによるコミュニケーション支援の組み合わせは、保険販売プロセスの変革に大きな可能性を秘めています。

4.2 顧客選定と最適商品提案の自動化

ここで、実際のシステムの様子をライブビデオでお見せします。ご覧いただいているのは代理店の視点からのページです。ここには2種類の情報があります。1つは手数料予測で、代理店はシステムからの推奨が自分の手数料にどのような影響を与えるか、そして目標達成にどう貢献するかを確認できます。もう1つの要素は、これからご覧いただく特定の顧客リストと提案する商品のリストで、過去の履歴に基づいて優先順位が付けられています。

リストには「ホットリード」「ウォームリード」「コールドリード」といった形で、推奨の強さに基づいて分類されています。手数料価値の定量化と、代理店が提案できる特定の商品の表示があります。場合によっては、「この顧客は50歳になった」「この顧客の子供が学校に入学した」といった特定の要因の詳細も表示されます。これらは顧客にニーズを生み出すイベントであり、代理店は成約の可能性が高い会話のきっかけとして利用できます。

ここで代理店ができることは、システムからの推奨を確認、延期、または拒否することです。これが重要なポイントの一つです。多くの場合、代理店は保険会社よりも顧客のことをよく知っています。このシステムでは代理店からのフィードバックを収集し、モデル自体が将来より良い推奨を提供するために活用します。

最初の行からの情報を効果的に収集することは、サポートを提供することと同じくらい重要です。ここでは商品の詳細が表示され、代理店は一人の顧客と話し合いたい商品を数点選択しています。次のステージでは、アポイントメントの計画に進みます。

代理店はここで2つの商品について会話をセットアップし、取引完了の目標日を設定し、通信手段（メールまたは電話）および面談方法（バーチャルミーティングまたは実際の対面）を選択します。代理店がこれらの選択をする理由は、システムがコミュニケーションのタイプに応じて、会話のためのコンテンツを生成するからです。

4.3 顧客対応コンテンツの自動生成機能

この例では、代理店がメールを選択したケースをご覧いただいています。代理店が何について話し合うかをシステムが理解しているため、すでに会話のコンテンツを含むメールが自動生成されています。招待状や代理店が話し合う予定の商品に関するすべての添付ファイルも含まれています。

代理店は顧客との関係性のタイプに基づいて、スタイルをより専門的にするか、より温かみのあるものにするか、あるいはよりフレンドリーにするかを選択できます。このように高いレベルのカスタマイズが可能であり、最終的には手動でテキストを変更することもできますが、これは代理店が会話の計画と準備を行うための大きな時間節約になります。

ここでスタイルを変更すると、メールの内容は変わりますが、伝える内容は同等のままです。画面の下部にスクロールすると、会話のスクリプトが表示されます。一部の代理店は箇条書きの非常に短いスクリプトを好みますが、他の代理店は話し合うべきことがすべて含まれた詳細なスクリプトを好みます。

会話がバーチャルチャネルで行われ、顧客が同意すれば、録音自体をコールセンターのように使用して、オペレーターにリアルタイムの推奨を提供することができます。最終的には、システムは自動的に代理店システムやOutlook、または保険会社がすでに持っている予約システムと連携し、希望の形式で会話の入力情報を提供します。

このコンテンツ生成機能により、代理店は顧客とのコミュニケーションをパーソナライズしながらも、時間を大幅に節約できます。自動生成されたメールや会話スクリプトをベースにしつつ、代理店は自分の知識と経験を加えてカスタマイズできるため、効率性と人間らしさの両方を兼ね備えたアプローチが可能になります。システムは顧客データと商品情報を組み合わせて、各顧客に合わせた最適なコミュニケーションコンテンツを提案するのです。

4.4 代理店フィードバックによるモデル改善プロセス

会話の後、代理店は結果についてフィードバックを提供することができます。ここで問題となるのは、通常、会話の結果として顧客が保険を購入した場合、保険会社はそれを把握できます。なぜなら、その情報はすべての詳細とともに契約システムに入るからです。

しかし、顧客が購入しない場合、その理由はしばしば代理店のみが知り、共有されないため失われてしまいます。これはモデルにとって非常に貴重な情報です。顧客が価格が高すぎるために購入しないのか、すでに競合他社から購入したのか、商品の品質がより良いものを求めているのか、あるいは単にそのタイミングではないのかという違いは、モデルにとって大きな違いをもたらします。

この情報を記録することは非常に重要であり、代理店がそうすることで次の推奨がより良くなるため、代理店自身の利益にもなります。さらに、この情報は保険会社にとっても、他の理由や他の商品に対するより良いターゲティングをダイレクトチャネルを通じて提供するためにも活用できます。これは双方にとって有益な状況です。

代理店からのフィードバックは、AIモデルの継続的な改善サイクルの核心となります。例えば、特定の年齢層やライフステージにある顧客に対する特定の商品提案が成功しなかった理由についてのパターンが見えてくれば、それに応じて推奨ロジックを調整できます。また、特定の代理店の特性（専門分野、コミュニケーションスタイルなど）と顧客タイプの相性についての洞察も得られます。

このフィードバックループにより、システムは時間の経過とともに「学習」し、より的確な推奨と効果的なコミュニケーション内容を生成できるようになります。代理店の知識とAIの分析力を組み合わせることで、保険販売プロセス全体の最適化が実現するのです。

5. システムデモンストレーションと導入情報

5.1 代理店インターフェースと顧客リスト機能

今からライブビデオをお見せします。ここに表示されているのは代理店視点のページです。このインターフェースには2種類の情報が表示されています。1つは手数料予測で、システムからの推奨が代理店の手数料にどのような影響を与えるか、つまり目標達成にどう貢献するかを確認できます。もう1つの要素は、すぐにご覧いただく特定の顧客リストと提案商品のリストで、これらは過去の履歴に基づいて優先順位付けされています。

画面には「ホットリード」「ウォームリード」「コールドリード」といった形で、推奨の強さに基づいた顧客リストが表示されています。手数料価値の定量化とともに、代理店が提案できる特定の商品の表示があります。一部のケースでは、「再訪問の理由」の詳細も表示されています。例えば「この顧客は50歳になった」「この顧客の子供が学校に入学した」といった情報です。

これらは顧客にニーズを生み出すイベントであり、代理店はこれらの情報を活用して成約の可能性が高い会話のきっかけとすることができます。また、代理店はシステムからの推奨を確認、延期、または拒否することができます。これが重要な点の一つです。多くの場合、代理店は保険会社よりも顧客のことをより深く理解しています。このシステムは、代理店からのフィードバックを収集し、それをモデル自体が将来より良い推奨を提供するために活用します。

第一線からの情報を効果的に収集することは、サポートを提供することと同じくらい重要です。ここでは商品の詳細が表示され、代理店は一人の顧客と話し合いたい商品を選択しています。このインターフェースにより、代理店は顧客データを効率的に閲覧し、最も有望な見込み客に集中することができるため、時間の有効活用と収益の最大化が可能になります。

5.2 コミュニケーション自動化とスタイルカスタマイズ

次のステージでは、アポイントメントの計画に移ります。ここでは2つの商品が表示されています。代理店は取引を完了するための目標日を設定し、通信手段（メールまたは電話）および面談方法（バーチャルミーティングまたは実際の対面）を選択します。そしてアポイントメントをセットアップします。

代理店がこれらの選択をする理由は、システムがコミュニケーションのタイプに応じて、会話のためのコンテンツを生成するからです。この例では、メールを選択しました。ご覧のように、代理店が何について話し合うかをシステムが把握しているため、会話のすべてのコンテンツがすでに含まれたメールが生成されています。招待状や代理店が話し合う予定の製品についてのすべての添付ファイルも含まれています。

代理店は顧客との関係性のタイプに基づいて、スタイルをより専門的にするか、より温かみのあるものにするか、あるいはよりフレンドリーにするかを選択できます。このように高いレベルのカスタマイズが可能であり、最終的には手動でテキストを変更することもできますが、これは代理店が会話の計画と準備を行うための大きな時間節約になります。

スタイルを変更すると、メールの内容は変わりますが、伝える内容は同等のままです。画面の下部にスクロールすると、すぐにスクリプトが表示されます。一部の代理店は箇条書きの非常に短いスクリプトを好みますが、他の代理店は話し合うべきことがすべて含まれた詳細なスクリプトを好みます。

バーチャルチャネルで会話が行われ、顧客が録音に同意すれば、コールセンターのようにその録音をオペレーターへのリアルタイム推奨提供に活用することも可能です。このように、システムは様々なコミュニケーションスタイルと代理店の好みに適応し、各顧客とのやり取りを最適化するための柔軟性を提供しています。

5.3 代理店システムとの連携と商談結果フィードバック

最終的に、システムは自動的に代理店システムやOutlook、あるいは保険会社がすでに持っている予約システムと連携し、希望の形式で会話の入力情報を提供します。これにより、代理店は既存のワークフローとシームレスに統合でき、別のシステムに情報を手動で入力する必要がなくなります。

会話の後、代理店は結果についてフィードバックを提供することができます。ここでの課題の一つは、通常、会話の結果として顧客が保険を購入した場合、その情報はすべての詳細とともに契約システムに入るため、保険会社はそれを把握できます。しかし、顧客が購入しない場合、その理由は代理店だけが知っており、共有されないため失われてしまいがちです。

この顧客が購入しない理由に関する情報は、モデルにとって非常に価値があります。顧客が価格の高さで購入しないのか、すでに競合他社から購入したのか、より良い品質の商品を求めているのか、あるいは単にそのタイミングではないのかという違いは、モデルにとって大きな違いをもたらします。

この情報を記録することは非常に重要であり、次の推奨がより良くなるという点で代理店自身の利益にもなります。また、この情報は保険会社が直接チャネルを通じて他の理由や他の商品に対するより良いターゲティングを提供するためにも活用できます。これは双方にとって有益な状況です。

フィードバック機能により、システムは継続的に学習し、時間の経過とともに推奨の精度が向上します。代理店と保険会社の間の情報の流れが改善され、販売プロセス全体の最適化につながります。特に不成約の理由を系統的に収集することで、商品開発や価格戦略にも貴重な洞察を提供できるのです。

5.4 AWS Marketplaceでの利用可能性

より詳しく知りたい方は、質問にお答えするためにこのセッション後もここに残ります。また、DXCブースの732番にもお越しいただけます。このIDH（Insurance Data Hub）はすでにAWS Marketplaceで利用可能です。

こちらにページとリンクが表示されています。ご興味がある場合や何か会話をご希望の場合は、喜んでご連絡させていただきます。このソリューションは即座に導入でき、AWS環境で直接アクセス可能です。AWS Marketplaceを通じて提供することで、調達プロセスの簡素化と迅速な導入を実現しています。

保険会社はAWS Marketplaceから直接ソリューションを取得し、既存のAWS環境に統合することができます。これにより、複雑な契約プロセスを回避し、より早くビジネス価値を実現することが可能になります。IDHはすでに多くの保険業界固有の機能とユースケースが事前に構築されているため、最小限のカスタマイズで迅速に価値を提供できるよう設計されています。

AWS Marketplaceで提供することで、サブスクリプションベースのモデルを通じてソリューションの継続的な改善と更新も保証されています。保険会社は最新の機能や拡張機能に常にアクセスできるため、市場の進化に合わせてAI機能を拡張し続けることができます。