マルチモーダルな初回損失通知（FNOL）エビデンスをタグ付けされた、意思決定対応の入力情報に変換し、アジャスターが生のアーティファクトではなくコンテキストから始められるようにします。
手動のFNOL処理は、非構造化されたマルチモーダルなエビデンスを人間の対話用に設計されたポータルを通じて解釈する必要があるため、専門家の時間を反復的なタスクに費やします。現場で撮影された写真、ウォークアラウンド動画、スキャン文書、口述または録音されたメモは、入力時にシステムに入り、そこで下された決定がクレームサイクルタイム、下流の精度、顧客体験に直接影響します。
保険の全ラインにわたり、この瞬間は複雑です。FNOL受付は「単にクレームを開くだけ」とよく説明されますが、実際には、大量の非構造化データを解釈、検証、関連付ける必要があり、その後で意味のある決定を開始できます。
課題は重大です：クレーム専門家は反復的な入力検証に過度の時間を費やします。ポータルをナビゲートし、エビデンスの完全性を検証し、アーティファクトを解釈してから、専門知識をより価値の高い決定に適用するまでにかなりの時間がかかります。業界の観察によると、初期クレーム処理中に入力検証がアジャスターの時間のかなりの部分を消費する可能性があり、典型的な提出では評価を開始する前に意味のある画面作業が必要です。大災害や季節的な急増によるボリュームスパイク時には、これらの遅延が蓄積し、バックログを生み出し、クレーム解決を遅らせ、顧客体験に影響を与えます。
この投稿では、ハンズフリーFNOL受付システムが、ドメイン推論のためのStrands Agents SDKで構築されたエージェントと、ライブポータルインタラクションのためのAmazon Bedrock AgentCore Browser Toolをどのように組み合わせるかを示します。このアプローチは、反復的な画面作業を排除しながら人間の専門知識を維持します。
このソリューションは、2つの補完的な機能を組み合わせています：
Strands Agentsは、生成AIエージェントを構築するためのモデル駆動アプローチを採用したオープンソースSDKです。このアーキテクチャでは、エージェント（Strands Agentsで構築）がAmazon Bedrockを通じて提供される基盤モデル（FM）を使用して、保険固有のビジネスルール（エビデンス解釈、モーダル間の関連付け、クレーム複雑性評価など）を適用します。
ブラウザ推論は、自然言語の指示（例：「次の未処理クレームを開く」または「画像分析をトリガーする」）を解釈し、具体的なUIアクションに変換するクライアントSDKであるAmazon Nova Actによって実行されます。Amazon Bedrock AgentCore Browser Toolは、Nova Actがそれらのアクションを実行するために接続する管理された分離されたChromeセッションを提供します。AgentCore Browser Toolは、観測可能性のためにセッション記録とライブビュー機能も提供します。
このワークフローでは、Nova ActがAgentCore Browserセッションを通じて画面上に表示される内容を推論することで受付プロセスを駆動し、Strandsベースのエージェントがバックグラウンドでドメイン推論を実行します。Nova Actはエビデンスを分析する必要があるタイミングを判断し、ポータルインタラクションを調整し、ドメインエージェントは人間のレビュアーが使用するのと同じドメインロジックを適用してエビデンスの意味を判断します。
結果として、手動の画面作業が自動化され、人間の監視と監査可能性が維持されます。クレーム専門家は、判断のためのコンテキスト豊かで事前分析された提出物を受け取り、検証ではなくなります。タグ付けされたエビデンスは、ルーティング、パターン分析、およびクレームライフサイクル全体の継続的なワークフロー改善をサポートする耐久性のある運用資産となります。
ワークフローは、システムの実際の動作からキャプチャされたリアルなブラウザ自動化録画を用いて説明されます。
機会：人間の専門知識を増幅するためのクレーム受付の最適化
保険の全ライン（自動車、損害、生命、健康、特約）において、クレーム受付は非構造化情報が初めてシステムに入る瞬間です。写真、動画、スキャン文書、録音メモが一緒に到着し、多くの場合不完全で、ラベルが一貫せず、標準化されることはほとんどありません。
クレーム専門家はこの瞬間に深いドメイン知識をもたらします。彼らは使用可能なエビデンスがどのように見えるべきか、何が欠けていることが多いか、アーティファクトが相互にどのように関連するか、そしてカバレッジ、重大度、次のステップにとってどのシグナルが重要かを知っています。しかし今日、その専門知識の多くは、ゆっくりとした手動のポータル作業（画面をクリックし、アーティファクトを一つずつ目視検査する）を通じて適用されています。意味のある評価を開始する前に、レビュアーは経験に大きく依存する基本的な質問に答えなければなりません。これには、必要なアーティファクトが存在するか、写真と動画が使用可能で関連性があるか、音声メモに重要な観察が含まれているか、提出物が遅延なく進めるのに十分であるかが含まれます。
これらの質問に答えるには、骨の折れる画面作業が必要です。典型的なFNOL提出物には、複数のビューに分散した多数のアーティファクトが含まれる可能性があり、レビュアーはエビデンスを見つけ、各アイテムを開いて解釈し、モーダル間でシグナルを相関させ、結果をポリシーしきい値と比較し、監査の継続性のためにサマリーをキャプチャする必要があります。
これらのステップは不可欠ですが、反復的で機械的でもあります。判断ではなく注意が必要です。その結果、熟練したアジャスターと審査員は、専門知識をより価値の高い決定に適用する前に、入力の完全性を検証するために不釣り合いな時間を費やします。
この課題は日常のクレーム処理に存在し、大災害イベント、季節的な自動車クレーム、健康および生命クレーム活動の急増によるボリュームスパイク時にさらに顕著になります。ワークロードが増加すると、バックログが拡大し、エビデンスレビューが急いで行われたり一貫性がなくなったり、人間の判断が本来よりも遅れて適用されます。
問題は専門知識や技術の不足ではありません。問題は、ドメイン知識がプロセスの中で遅すぎるタイミングで行使され、反復的な入力検証にすでに時間が費やされた後であることです。
ドメイン知識をコード化することが状況を変える理由
クレーム受付は、重要な決定ロジックが構造化ルールにキャプチャされ、個人の経験や直感だけに頼るのではなく、取り込み時に一貫して適用されるときに加速します。
経験豊富なレビュアーは、異なるクレームタイプに必要な写真の角度、動画が欠落した画像を代替できるタイミング、より高い複雑性を示すアーティファクトの組み合わせ、下流の処理を停滞させる可能性のあるギャップを直感的に知っています。
エージェンティック生成AIにより、この実用的知識をビジネスルールと推論ツールにコード化し、エビデンスがシステムに入る際に一貫して適用できるようになります。
Strands AgentsをNova ActおよびAgentCore Browser Toolと組み合わせることで、ポータルのナビゲーション、クレームのオープン、分析のトリガーといった機械的な受付作業がドメイン推論から分離されます。Nova ActはBrowser Toolセッションを通じてワークフローを進め、Strands Agentsはエキスパートロジックを適用してエビデンスを解釈、タグ付け、相関付けます。
エビデンスが取り込み時にタグ付けされると、不足または不十分なアーティファクトが早期に検出され、関連性が暗黙的ではなく明示的になり、クレームを現在の内容に基づいてトリアージできます。人間のレビュアーは最初からコンテキストを持ち、ゼロから始める必要がありません。
自動化されたエビデンスタグ付けが今と将来に重要な理由
自動化タグ付けは、下流のステップが始まる前に入力の完全性と明確性を確保することで、現在のクレームを加速します。レビュアーは基本事項の確認に費やす時間を減らし、重要な判断により多くの時間を費やします。
時間が経つにつれて、一貫してタグ付けされたエビデンスは耐久性のあるデータ資産になります。タグはコード化されたドメイン推論によって生成され、一回限りの解釈ではないため、保険会社は次のことが可能になります：
- ルーティングと優先順位付けの改善
- 不完全な提出による再作業の削減
- 遅延やエスカレーションにつながるパターンの特定
- 新しいシナリオが出現したときの受付ルールの改良（コンプライアンス境界や意思決定権限を変更せずに）
タグ付けされたエビデンスが蓄積されるにつれて、非構造化アーティファクトは孤立したファイルではなくなります。画像、動画、音声は検索可能で分析可能なシグナルとなり、一般的なギャップが検出されたときのプロアクティブな連絡、専門チームへのクレームの事前準備、類似の将来クレームのサイクルタイム短縮など、新しいワークフローをサポートします。
最も重要なことは、タグ付けにより、ドメイン専門知識が取り込み時に一度適用され、ライフサイクル全体で再利用され、異なる段階で繰り返し再発見される必要がなくなることです。
これがエージェンティック自動化が可能にするシフトです：専門知識を上流に移動させ、下流システムを構造化シグナルで強化し、人間をループから外さずに、より迅速で一貫性のある解決を可能にします。
このシフトを既存のポータルを変更せずに実装する方法を示すために、次のセクションでは、ブラウザレベルの自動化と推論駆動エージェントを組み合わせたエージェンティックFNOL受付アーキテクチャを紹介します。
ソリューション概要：ポータル変更不要のエージェンティック受付
このプロトタイプは、エージェンティック推論とブラウザレベルの相互作用を使用してFNOL受付をエンドツーエンドで自動化する方法を示しています。本番環境では、Nova ActクライアントSDKが人間と同様にUIと対話するため、同じブラウザ自動化アプローチが既存のポータルに対して変更なしで機能します。
プロトタイプは現実的な本番環境を模倣するように構築されています。FNOLポータルとバックエンドサービスはAWS上のコンテナ化アプリケーションとして実行され、エージェント駆動のブラウザ自動化は人間のレビュアーとまったく同じようにライブポータルと対話します。この分離により、ドメイン推論とUI制御が独立して進化し、監査可能性と運用の安全性が維持されます。
高レベルでは、このソリューションは、AWS上で最新のエージェンティックシステムをどのようにデプロイするかについての実用的な知識を前提としています。これには、推論のためのFM、アプリケーションランタイムのためのコンテナ化サービス、状態とエビデンスのためのイベント駆動型ストレージの使用が含まれます。従来のロボティックプロセスオートメーション（RPA）ツールの経験は不要です。ここで説明する自動化は、事前録音されたスクリプトやハードコードされたフローを再生するのではなく、UI状態の推論に依存しています。
AWSアカウントと権限
ソリューションで使用されるリソース（AWS Cloud Development Kit (AWS CDK)、Amazon Elastic Container Service (Amazon ECS) on AWS Fargate、Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB、Elastic Load Balancing (Application Load Balancer)、Amazon CloudFront、AWS Identity and Access Management (IAM)のロールとポリシーを含む）をデプロイおよび管理するための権限を持つAWSアカウントへのアクセスが必要です。
デプロイメントは、AWSコマンドラインインターフェイス（AWS CLI）を使用した標準的な開発セットアップを使用して、AWS認証情報がローカルに設定されていることを前提としています。
ランタイム環境とデプロイメントモデル
FNOL受付ユーザーインターフェイスとバックエンドサービス（Strands Agentsを使用して実装されたエビデンス分析とクレーム複雑性評価を含む）はDockerコンテナとしてパッケージ化され、AWS Fargate上のAmazon ECSにデプロイされます。インフラストラクチャはAWS CDKを使用してプロビジョニングされ、コンテナイメージを構築し、単一のデプロイメントワークフローの一部として必要なコンピューティング、ストレージ、ネットワーキングリソースを作成します。
画像、動画、トランスクリプトなどの非構造化エビデンスアーティファクトはAmazon S3に保存されます。クレームメタデータ、エビデンス参照、エージェント生成の分析出力はAmazon DynamoDBに永続化されます。これにより、エージェントは受付全体でエビデンスを取得、関連付け、推論できます。
ブラウザ自動化の実践
エージェント駆動のブラウザ自動化は、ワークステーションや自動化ホストなどの別の制御環境から実行され、AgentCore Browserセッションを通じてデプロイされたFNOLアプリケーションに接続します。これは、ブラウザ自動化が実際の環境で一般的に運用される方法を反映しています。ブラウザ推論を担当するクライアントSDKであるNova Actは、Chrome DevTools Protocol（CDP）を介してWebSocket経由でAgentCore Browser Toolによって提供される管理されたChromeセッションに接続します。自動化レイヤーは、ライブポータルを観察し、それと対話します。