Amazon Finance が AWS の生成 AI を活用し規制対応を効率化

Amazon の財務技術（FinTech）チームは、異なる管轄区域の規制に準拠して Amazon チームが規制関連の問い合わせを管理するためのシステムを構築・運用しています。これらのチームは、当局からの規制関連問い合わせを処理しており、それぞれが異なる要件、ドキュメント形式、複雑さを有しています。 これらの規制関連問い合わせの処理には、ドキュメントのレビュー、関連情報の抽出、Amazon のインフラストラクチャ内の複数のシステムから支援データを取得し、規制で定められた時間枠内に対応をまとめることが含まれます。問い合わせの頻度とビジネスの複雑さが増大するにつれ、Amazon はよりスケーラブルなアプローチが必要となりました。 本稿では、Amazon FinTech チームが [Amazon Bedrock](https://aws.amazon.com/bedrock/?nc2=type_a) およびその他の AWS サービスを活用して、規制関連問い合わせの処理方法を変革するスケーラブルな AI アプリケーションを構築する方法を実証します。このソリューションを利用する各チームは、自チーム固有のドキュメントや参照資料で構成された独自のナレッジベースを作成・維持しています。 ## 課題 規制関連問い合わせの管理における規模と複雑さは、いくつかの相互に関連した課題をもたらしました： **知識の断片化と検索の複雑さ** 規制当局からの照会には、数千の歴史的ドキュメントから情報を統合する必要があります。これらのドキュメントは PDF、PPT、Word、CSV など様々な形式で存在し、分野固有の専門用語を含んでいます。チームは、膨大な文書群の中で関連する先例や裏付けとなる情報を迅速に見つけ出す方法が必要でしたが、同時に正確性と規制遵守を維持する必要がありました。 **対話コンテキストと状態管理** 規制当局からの照会には、複数回のやり取りを含む対話が求められ、過去のやり取りからの文脈が正確な回答を生成するために不可欠です。セッション間を通じて対話の状態を維持し、チームメンバーが反復的なやり取りを通じて回答を洗練させる過程で回答の進化を追跡することは、大きな複雑さを伴います。 **観測可能性と継続的改善** 生成 AI システムにおいては、特定の回答がなぜ生成されたかを理解することが、その回答自体と同様に重要です。チームは、改善点を特定し、責任ある AI の原則への準拠を維持するために、検索プロセス、モデルの判断、ユーザーとのやり取りについて包括的な可視性を必要としました。例えば、モデルがソースドキュメントに含まれていない情報を捏造（hallucinate）したときや、規制違反につながる可能性のある古いコンプライアンスガイドラインをシステムが取得した場合を検出する必要があります。モデル、プロンプト、およびドキュメントコーパスの変化に伴い、AI システムの精度は時間とともに低下する傾向があるため、継続的な監視が必要です。 ## ソリューションの概要 これらの課題に対処するため、Amazon FinTech チームは [Amazon Bedrock](https://aws.amazon.com/bedrock/)、[AWS Lambda](https://aws.amazon.com/lambda/)、および関連する AWS サービスを活用したインテリジェントな規制対応自動化システムを構築しました。本ソリューションでは、[Retrieval Augmented Generation](https://aws.amazon.com/what-is/retrieval-augmented-generation/)（RAG：検索拡張生成）を実装し、[Amazon Bedrock Knowledge Bases](https://aws.amazon.com/bedrock/knowledge-bases/) とベクトル保存用の [Amazon OpenSearch Serverless](https://aws.amazon.com/opensearch-service/features/serverless/) を組み合わせることで、数千件の歴史的ドキュメントからの情報検索を可能にしています。[Claude Sonnet 4.5](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html) を [Converse Stream API](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ConverseStream.html) を通じて活用したリアルタイムのチャット対話と、会話履歴管理のための [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) を組み合わせることで、文脈を考慮した多段階の対話を実現しています。[OpenTelemetry](https://opentelemetry.io/) とセルフホスト型の Langfuse による包括的な観測機能により、AI システムのパフォーマンスに対する継続的な監視と改善が保証されています。規制に関する問い合わせは非常に文脈依存性が高く、キャッシュヒット率が低くなる傾向があるため、本システムでは大規模言語モデル（LLM）の応答や中間結果をキャッシュしません。 以下の図は、Amazon Bedrock Knowledge Bases を Converse API やその他のツールとともにワークフローで使用し、規制関連の問い合わせに必要な情報を提供する方法を示しています。 ## ナレッジベース取り込みフロー ナレッジベース取り込みフローは、ユーザーがドキュメントをアップロードした後に開始される自動化されたドキュメント処理パイプラインを提供します。その役割は、ドキュメントのデータを [Amazon Bedrock Knowledge Base](https://aws.amazon.com/bedrock/knowledge-bases/) に埋め込むことです。以下にそのフローを示します。 ナレッジベース取り込みワークフローを使用すると、ドキュメントを一括アップロードし、自動化されたパイプラインを通じて検索可能なベクトル埋め込みに変換することができます。以下の詳細なフローは、前述の図で示されています。 - ユーザーによるドキュメントアップロード：ユーザーはクライアントアプリケーションを通じてドキュメントをアップロードします。 - プレサイン URL 生成：クライアントアプリケーションは、Amazon API Gateway にリクエストを送信し、これにより知識ベースの取り込み用 AWS Lambda 関数が呼び出され、プレサイン S3 URL が生成されます。 - ドキュメントアップロード：クライアントアプリケーションは、生成されたプレサイン URL を使用してドキュメントをアップロードします。 - 取り込みトリガーとデータ処理：ドキュメントが Amazon Simple Storage Service (Amazon S3) に正常にアップロードされると、クライアントアプリケーションは Amazon API Gateway をトリガーしてドキュメント処理用 AWS Lambda を起動し、フォーマット変換の処理や複数のドキュメントの並列取り込みを管理します。これらのドキュメントに含まれる画像、チャート、表については事前処理を行う必要はありません。Amazon Bedrock Knowledge Base は、Amazon Bedrock Data Automation (BDA) で構成されており、これにより多様なモダリティを持つコンテンツを効果的に抽出できるためです。その後、AWS Lambda 関数は Amazon Bedrock Knowledge Bases を呼び出します。 - ベクトルストレージ：Amazon Bedrock Knowledge Base は、階層型チャンキング戦略を用いてドキュメント内容をチャンク化し、Amazon Titan Text Embeddings を使用して埋め込みベクトルを生成し、結果として得られるベクトルを OpenSearch Serverless に保存します。階層型チャンキングは、金融文書のセクション構造を反映したネストされた親子関係を作成します。この戦略は構造化され複雑なドキュメントに対して効果的であり、正確な検索のために小さなチャンクをインデックス化しつつ、一貫性のある回答を提供するために十分なコンテキストを含む大きな親チャンクを返すことができます。 自動化された取り込みパイプラインを構築することで、知識の断片化という核心的な課題に対処し、複数のフォーマットにわたる数千件の歴史的ドキュメントを効率的に処理しながら、関連する AI 回答のためのコンテンツインデックス最適化を実現します。この並列化アプローチにより、システムは効果的にスケーリング可能となり、年々の規制関連問い合わせの増加に対応しつつ、大規模なドキュメント量全体で一貫した処理パフォーマンスを維持できます。 ## チャットアプリケーション チャットアプリケーションは、AWS サーバーレスアーキテクチャを基盤としたリアルタイム会話インターフェースを提供し、システムとの自然言語での対話を可能にします。顧客が AI の応答をより早く読み始められるよう、応答ストリーミングを採用しており、この機能は WebSocket 接続を通じて実装されています。これらの WebSocket 接続と Claude Sonnet 4.5 モデルを活用することで、文脈に応じた関連性の高い応答を提供しつつ、DynamoDB 上で会話の状態を維持します。ワークフローは以下の通りです： - チャット会話の開始：ユーザーはクライアントアプリケーションを通じて、新しいチャットセッションを開始するか、既存のセッションを開きます。 - WebSocket 接続：アプリケーションは WebSockets を使用して、Amazon API Gateway と永続的な双方向接続を確立します。 - メッセージ送信：アプリケーションは、WebSocket 接続を介してユーザーの質問を投稿し、これを Chat サービスの AWS Lambda 関数に伝播させます。 - クエリ拡張：Chat Service の AWS Lambda 関数は、Claude 3.5 Haiku モデルとクエリ拡張戦略を使用して、ユーザーの質問の複数のバリエーションを生成します。 - 知識検索：Chat Service Lambda は、拡張された各クエリに対して Amazon Bedrock Knowledge Bases の Retrieve API を呼び出します。この API は、基盤となる OpenSearch Serverless インデックスに対してベクトル類似性検索を実行し、最も関連性の高いドキュメントチャンクと、そのソースメタデータおよび関連度スコアを返します。 - コンテキストの組み立て：Chat Service の AWS Lambda 関数は、Amazon DynamoDB から会話履歴（既存の会話については、特定の会話 ID に基づいて）を取得し、取得したナレッジベースの結果とユーザーの質問を組み合わせてコンテキストを作成します。 - レスポンス生成：Chat Service の AWS Lambda 関数は、Claude Sonnet 4.5 とレスポンスジェネレータープロンプトを使用して、Converse Stream API を通じて、組み立てられたコンテキストに基づいて文脈に即した回答を生成します。 - ユーザーエンゲージメント：Chat Service の AWS Lambda 関数は、生成されたレスポンスを Markdown 形式で WebSocket 接続を介してクライアントアプリケーションへストリーミングし、すべての会話を Amazon DynamoDb の会話履歴テーブルに保存します。 - 観測可能性：プロセス全体を通じて、Chat サービスは OpenTelemetry (OTEL) SDK を使用して、エンドツーエンドのトレースをセルフホスト型の Langfuse インスタンスに公開します。これにより、レイテンシ指標、トークン使用量、プロンプトテンプレート、モデルレスポンスなどの詳細なテレメトリデータが収集されます。 ## マルチターン会話型体験 規制に関する問い合わせの議論は、チームが回答を洗練させ追加データソースを参照する過程で、複数のやり取りを通じて進行することがよくあります。この反復プロセスをサポートするため、Amazon FinTech チームは、低遅延かつ文脈を意識した対話を可能にする Amazon Bedrock ConverseStream API と統合し、Amazon API Gateway (WebSocket APIs)、AWS Lambda、および Amazon DynamoDB を用いたマルチターン会話型ワークフローを実装しました。各チャットセッションは Amazon Cognito によって安全に認証され、一意の会話 ID が割り当てられます。DynamoDB はメッセージを時系列順に保存してセッション間での文脈を維持するため、ユーザーは以前の議論をシームレスに再開し、継続性を保つことができます。 ユーザーが問い合わせを送信すると、システムは入力値をサニタイズしてプロンプトインジェクション攻撃を防ぎます。サニタイズ後、システムは意図を分類し、Amazon Bedrock Knowledge Base からの検索が必要かどうかを判断します。この判断は、LLM を呼び出してユーザーの問い合わせが会話型か知識集約型かを分類することによって行われます。複雑で知識集約的な質問に対しては、ユーザーによる略語や省略された質問の一般的な使用に対応するクエリ拡張戦略が採用されます。この層では Claude 3.5 Haiku を用いて最大 5 つのクエリバリエーションを生成し、Knowledge Base に対して並列で Retrieve API を呼び出して、OpenSearch ベクトル類似度検索を用いて関連結果を取得します。スケールにおけるパフォーマンスを維持するため、このワークフローではマルチスレッディングを使用してこれらの取得呼び出しに並列処理を実装しています。この最適化により、取得レイテンシは 10 秒（逐次処理）から 2 秒未満に短縮され、応答性の高い対話が可能になりました。 取得された情報と直近の会話履歴は、[Amazon Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html) を付加した ConverseStream API を介して Claude Sonnet 4.5 に渡されます。この Guardrails は [sensitive information filters](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-sensitive-filters.html) を実装しており、入力と出力の両方から PII（個人識別情報）や金融データを自動的に検出・除去します。これは規制文書を守る上で極めて重要です。プロンプトインジェクションの試行が検出された場合、システムは「申し訳ありませんが、その質問には回答できません」と応答し、対話の流暢さを維持しながら安全でコンプライアンスに準拠したやり取りを保ちます。 このアーキテクチャは、継続性、透明性、スケーラビリティを実現します。ユーザーは検索および生成フェーズを通じてステータス更新を伴うリアルタイムのストリーミング応答を受け取り、エンゲージメントが向上し、レイテンシが削減されます。DynamoDB における永続的なログは、コンプライアンスレビューのための不変の監査証跡を提供し、サーバーレスかつイベント駆動型の設計は自動的にスケーリングして同時セッションをサポートします。これらの機能により、Amazon FinTech チームは、Amazon Bedrock によって支えられた、文脈に即した、安全で規制遵守の応答を生成する複雑で反復的な対話を行うことが可能になります。 ## 観測可能性 (Observability) 観測可能性は、AI ドライブ型のワークフローを理解し改善する上で重要な役割を果たします。規制問い合わせ応答システムへの完全な可視性を達成するため、Chat Service AWS Lambda は OpenTelemetry (OTEL) を統合し、自己ホスト型の Langfuse インスタンスを構成して、各インタラクションの詳細なエンドツーエンドのトレースをキャプチャしています。この設定により、エンジニアや応用科学者は、プロンプトがどのように処理され、知識がどのように取得され、応答がどのように生成されるかという微細なテレメトリ情報を入手できます。これにより、システムの性能と精度のほぼ継続的な改善が可能になります。ネイティブの Langfuse SDK ではなく OTEL を使用するという決定は、ベンダーに依存しない柔軟性を提供し、テレメトリデータを複数の観測可能性バックエンドへルーティングしたり、進化する監視要件に適応させたりすることを可能にします。 ランタイム時、Chat Service の各 AWS Lambda ステージは手動で [OTEL Java SDK](https://opentelemetry.io/docs/languages/java/) を用いてインストゥルメント化され、[OTEL Generative AI セマンティック標準](https://opentelemetry.io/docs/specs/semconv/gen-ai/) に従ってレイテンシ、トークン使用量、モデルの判断、プロンプトメタデータが記録されます。[スパン](https://langfuse.com/docs/observability/data-model) はほぼリアルタイムで Langfuse へ公開され、チームは Amazon Bedrock ConverseStream API、ナレッジベース検索、Claude Sonnet 4.5 が単一のリクエスト内でどのように相互作用するかを透明性を持って把握できます。詳細なテレメトリデータにより、チームはパフォーマンスのボトルネックを特定し、プロンプト戦略を最適化し、リトリバル精度を向上させる一方で、責任ある AI プラクティスを維持することが可能になります。 この観測可能性フレームワークは、システムの挙動に対する信頼と説明責任を維持します。エンジニアはユーザーのアクションとモデルの結果を相関付け、複数サービスにわたるデータ系譜を追跡し、運用を中断することなく設定を微調整できます。OpenTelemetry の相互運用性と Langfuse の可視化・分析機能を組み合わせることで、Amazon FinTech チームは大規模な生成 AI システムの評価に向けたスケーラブルで拡張性の高い基盤を獲得し、あらゆるインタラクションを継続的な改善のための実行可能なインサイトへと変換します。 以下のスクリーンショットは、Langfuse でキャプチャされたエンドツーエンドのトレースを示しており、観測性ソリューションがクエリ拡張や知識検索からモデルのプロンプト、応答、レイテンシ指標に至るまでの完全なワークフローをどのように捉えているかを解説しています。また、ソースドキュメントの引用も強調されており、応答生成中にコンテキスト情報がシステム内でどのように流れるかという透明性の高い視点を提供します。 参照：Langfuse に投稿されたエンドツーエンドのトレース ## 結論 本記事では、Amazon FinTech チームが Amazon Bedrock を活用してスケーラブルな AI ソリューションを構築し、知識検索の自動化、会話ワークフロー、応答生成を通じて規制関連の問い合わせに対応する方法をご覧いただきました。ドキュメント取り込みパイプライン、多段階の状態保持型会話、OpenTelemetry と Langfuse による詳細な観測性を組み合わせることで、このアーキテクチャはチームが統制され、追跡可能でコンプライアンスに準拠した方法で規制関連の問い合わせに対応することを可能にします。 スタック全体が AWS のサーバーレスサービス上で構築されているため、エンタープライズグレードのデプロイに必要な運用上のスケーラビリティ、セキュリティ、弾力性を提供します。法的コンプライアンス、規制関連の問い合わせ、あるいは高ボリュームの内部知識ワークフローに取り組む場合でも、このパターンはビジネスドメインに合わせて調整・拡張できる実用的な基盤となります。 生成 AI を活用して知識集約型プロセスの近代化を検討されている場合は、[Amazon Bedrock のドキュメント](https://aws.amazon.com/bedrock/)をご参照ください。ここでは、安全でガバナンスが効き、スケーラブルな AI 駆動ワークフローをどのように構築し始めるかについてご紹介します。 ## 著者紹介

Amazon Finance が AWS の生成 AI を活用し規制対応を効率化

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト