re:Invent 2024: Rocket MortgageがAIで顧客体験向上 - セキュアなLLM活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How Rocket Mortgage elevates client experiences with secure AI (SEC214)
この動画では、Rocket MortgageがAIを活用してクライアント体験を向上させた事例が紹介されています。Client-facing Assistant、Rocket Logic Synopsis、Rocket Navigatorという3つの主要なユースケースを通じて、住宅ローン業界でのAI活用方法が解説されています。特に、Client-facing Assistantによるリード転換率33%向上や、Synopsisによる40,000時間の業務時間削減など、具体的な成果が示されています。また、LLMワークロードにおけるセキュリティ上の課題に対し、Context Window制限やPrompt Injection対策、Multi-agent Architectureの採用など、AWSのベストプラクティスに基づいた具体的な解決策が詳しく説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AIによる顧客体験向上：Rocket Mortgageの事例紹介
おはようございます。月曜日の朝、皆様をお迎えできることを嬉しく思います。Rocket MortgageがセキュアなAIによってクライアント体験をどのように向上させたかについて解説する「SEC214」へようこそ。私はAWSのSenior Security Solutions ArchitectのJeremy Wareです。本日は、Rocket MortgageでAI戦略を推進するテクノロジーリーダーの一人であるDan Vasquezと共に登壇させていただきます。残念ながら、プレゼンテーションの準備や関連作業にご協力いただいたRitesh Shahは本日参加できませんでした。それでは早速、本日の本題に入らせていただきたいと思います。
本日のアジェンダとして、RocketのAIミッションの詳細、既に本番環境で稼働している3つのユースケース、プロセスを進める上で考慮したセキュリティ要件、Generative AIワークロードに関連する脅威モデリング、そしてAWSのベストプラクティスについてご説明し、最後に全体のまとめをさせていただきます。最後に5分ほど質疑応答の時間を設けておりますが、Danと私は終了後にホールで追加のご質問にもお答えさせていただきます。
Rocketのミッションと市場機会：AIの重要性
まず、住宅ローン業界とRocketについて概要をお話しし、なぜAI戦略が必要で、私たちにとってなぜ重要なのかについてご説明させていただきます。目の前にある市場機会をご覧ください。現在の住宅ローン市場は推定5兆ドルです。Rocketは大企業で知名度も高いのですが、良い年でもその市場の8-9%しか獲得できていません。効率性を高め、さらに重要なことには、私たちが本当に得意とするクライアントとチームメンバーへのサービスを向上させることで、まだまだ大きな可能性が残されているということです。
私たちのミッションはシンプルです：「すべての人々の住まいをサポートする」。しかし、この3つの言葉には多くの意味が込められています。サポートというのは、単に家を探したり購入したりすることだけではありません。住宅ローンの返済から、家族計画や次の引っ越し、大学進学など、将来のニーズに応じたリファイナンス選択肢まで、住宅所有の全ライフサイクルをカバーしています。「すべての人々」とは、実店舗で住宅ローンを組むことを好む方から、DetroitやClevelandのコールセンターに電話する方、すべてをデジタルで自身で完結させたい方まで、アメリカの住宅購入市場全体を指しています。
では、現在AIを使ってこれをどのように実現しようとしているのかについてお話しましょう。最初のユースケースは、クライアント向けアシスタントです。これは何百万人ものクライアントのためのパーソナライズされた24時間365日利用可能なAIアシスタントです。住宅ローンと言えば、多くの人は地域の支店に行って座り、書類に記入するイメージを持っていますが、Rocket Mortgageはそうではありません。Rocket Mortgageには何千人ものチームメンバーが毎日電話やチャット、メールを通じて何百万人ものクライアントをサポートしています。24時間365日利用可能で、クライアントに代わってアクションを取り、パーソナライズされた体験を提供するクライアント向けアシスタントにより、リード転換率が33%向上すると予測しています。先ほどお示しした数字を思い出してください - 数兆ドル、数十億ドルの収益において、33%という数字は私たちにとって非常に大きな意味を持つのです。
クライアント向けAssistantとRocket Logic Synopsisの実装
クライアント向けAssistantのアーキテクチャについてお話ししましょう。これは単一のAssistantではありません。現段階では多くの人が、AIを効果的に活用するためには、エージェントの完全なネットワークを構築する必要があることに気付いています。すべての呼び出しやGuardrailサービスへの呼び出しを統制し、トップレベルのセキュリティを実装するクライアント向けAssistantという考え方があります。さらにその先には、ワークフローの異なる領域に特化した支援と統合を提供できる、非常にドメイン特化型のエージェントへと深く進んでいます。セキュリティの観点から見ると、これによって既存のドメインごとのセキュリティ制御を組み込み、活用することができます。支払いのためのサービスサイトを構築する際、最初に確認すべきことの1つは、あるクライアントが他のクライアントの情報を見ることができないようにすることです。これはセキュリティの基本中の基本です。しかし、なぜかAIの構築を始めると、人々はこういった質問を始めるのです。
これは新しいことではありません。デジタルプロパティから最初のユーザートークンを取得し、それをエージェントのエコシステムを通して、データを取得するAPIに渡すのです。これは全く同じ制御です。私たちはAIだからといって作り直すことはしませんでしたし、皆さんもそうする必要はないと思います。
Synopsisについて話しましょう。Synopsisはコールセンターのスイートの一部で、人間が最も得意とすることを可能にします。私たちは、スタッフがクライアントに対して可能な限り最高の体験を提供できるようにしたいと考えています。つまり、会話に集中できること、問題に共感できること、常に適切な情報をすぐに利用できること、そして最も重要なのは、クライアントと一緒に問題解決を行い、最善の支援方法を見つけ出すための余裕を持てることです。
私たちが望まないのは、7つの異なる画面で情報を入力することに気を取られたり、タイプミスや数字の転記ミスを心配したり、次のクライアント対応に移る代わりに30分もかけて通話メモを書くことです。これこそがRocket Logic Synopsisが私たちのために行っていることです。今年の半ばまでの実績として、40,000時間のチームメンバーの時間を節約しました。そして、このテクノロジーを活用することで、サービス利用クライアントの70%が、人を介さずにセルフサービスで解決できるか、チームメンバーが初回の通話で解決できています。これにより、クライアントとのやり取り全体を通して効率性が向上します。再度電話をかけたり、こちらからの折り返しを待つ必要がなければ、問題解決のために次のステップに進むことができます。
ここでアーキテクチャについて少し話しましょう。私たちは多くの異なるAmazonサービスを連携させてこれを作り上げています。Amazonが必要なパーツを提供してくれており、Jeremyが安全な組み合わせ方を示してくれたため、独自のものを多く構築する必要はありませんでした。Amazon Transcribeを使用していますが、精度と速度の面で素晴らしい経験をしています。Claude Haikuは通話中の重要な情報を抽出し、チームメンバーに提示する点で素晴らしい性能を発揮しています。QuickSightとAthenaは非常にうまく連携して、会話やその取引で何が起きているかについての迅速なデータインサイトを提供しています。
Rocket Logic Synopsisのデモをクリックしながら見ていきたいと思います。 これは、通話後のレビューの例で、リーダーや銀行員自身が自分の仕事を振り返りたい場合に、素早く会話の正確な文字起こしを確認し、その会話から既に抽出された重要なポイントをすべて確認することができます。最も重要なのは、その文字起こしやトランザクション全体と自然言語でチャットできることです。私たちは、この1回のトランザクションだけでなく、クライアントとのすべてのコミュニケーションやインタラクションからデータを収集し、さらなるインサイトを得たり、次に何をすべきか、次にどのように問題を解決すべきかを把握したりしています。
Rocket Navigator：社内AI実験プラットフォームの構築
Rocket Navigatorについてお話しさせていただきます。私たちのミッションの一つは、15,000人のチームメンバーをAIでスーパーチャージすることです。もし皆さんの中で、自社でAI戦略に責任を持つ立場にある方や、次のステップを考えている方がいらっしゃれば、コールセンターの例のような手の届きやすい良い事例がたくさんあります。しかし、私たちの考え方は常に、AIの最適なユースケースは戦略的な象牙の塔から生まれるのではなく、チームメンバーが日々の業務の中で安全かつ確実にAIを実際に体験することから生まれるというものです。安全性と確実性を強調しておきます。15,000人のチームメンバーに単にAgentへのアクセスを与えて好きなことをさせるというのは、多くのCSOを不安にさせることでしょう。このような規模では、適切なコントロールを組み込む必要があり、コストも重要な要素となります。繰り返しになりますが、RocketはAWS上だけでWikipediaの200倍以上にあたる10ペタバイト以上のデータを持っています。問題は、このユースケースで本当に興味深いことができるように、どうやってそれを安全かつ確実にAIにアクセス可能にするかということです。
私たちは、Navigatorという独自の社内AI実験プラットフォームを構築することを決定し、その開発に携わったチームメンバーも今この部屋にいます。アーキテクチャはとてもシンプルで、少なくともこの例では、認証済みのチームメンバーとしてネットワーク上にいるため、基本的なセキュリティは既に確保されています。
Navigator APIは、Amazon BedrockとさまざまなLLMの間を調整します。実験プラットフォームとして、Bedrock上の複数のモデルだけでなく、AWSエコシステム外のLLMにも接続しています。これは、同じプロンプトを異なる方法で試し、それぞれの状況に最適な方法を見つけ出せるようにするためです。AWS Guardrailサービスを活用していますが、これは非常に重要で、AWSのLLMワークロードに実際にアクセスすることなく独立して使用できます。これにより、AI エコシステム全体での実験を可能にしながら、一貫性とセキュリティを維持できます。
データソースを効果的にコントロールすることができます。RAGは許可していますので、自分のコンピュータでアクセスを許可されているドキュメントであれば、Navigatorで使用できます。内部データソースや内部アプリケーションとの接続については、エンジニアリングチームがデータが適切に使用されていることを確認し、管理できる項目です。これにより、15,000人のチームメンバーに自信を持ってこのツールへのアクセスを提供し、イノベーションにどう役立てられるかを見出してもらうことができます。これがNavigatorの簡単な例です。
それでは、ビデオを再生させていただきます。ユーザーインターフェースは非常にシンプルで、皆さんが普段使用している他のAIエージェントによく似た外観になっています。ChatGPTやClaudeなど、これらのツールには共通したデザイン言語があり、私たちもそれを取り入れることにしました。ここでご覧いただけるのは、チームメンバーがChatRKT機能を使用している例です。ChatRKTは、技術チームのメンバーが各種ガイドブック、Confluenceのドキュメント、GitHubのドキュメント、その他の様々なメモを活用できるように特別に開発したアプリケーションです。
エンジニアリングや大企業に携わる方々の多くが、必要な情報がなかなか見つからない、あるいはドキュメントが様々な場所で更新されているという悩みを抱えています。私たちはこの問題に対処するため、データセットの整理、特定のプロンプティング、そして他のツールとの統合機能を備えたChatRKTを開発しました。これにより、社内での業務の進め方について疑問が生じた際に、シニアエンジニアやアーキテクトが隣で助言してくれるような体験を提供できています。
LLMアプリケーションにおけるセキュリティ考慮事項
安全性に関する考慮事項についてお話しさせていただきます。クライアントからの信頼を維持するために - Fintechについて、特にモーゲージについて考えると、Fintechは決済を扱う様々な分野がありますが、モーゲージに関しては、ほとんどの方にとって人生で最も大きな影響力を持つ取引となります。私たちには1度のチャンスしかありません - もし信頼を失うか、データの取り扱いに不安を感じさせてしまえば、それで終わりです。そのため、この点は非常に真剣に受け止める必要があります。
データセキュリティ管理については、常にクライアントのデータをどのように保護しているかを問う必要があります。情報を取り込んだ瞬間から、それをどう扱い、どうタグ付けし、保持ポリシーはどうなっているのか、どこに保存し、クリーニングは行うのか、分析レイヤーやデータサイエンスチームが機械学習モデルを作成する際にはどうなるのか、誰がアクセスできるのか。これらは常に最優先で考えるべき事項です。
Jeremyが、これらの規制遵守とEnterprise Riskを実際にどのように達成するかについて、詳しく説明する予定です。つまり、業界および社内のガードレールとは何か、ということです。安全に実行できると感じるかもしれませんし、ビジネス的に正しい判断だと思えるかもしれません。しかし、誰もが従うべき法律があり、少なくともこの分野では規制当局が存在し、考慮すべき他の要因もあります。この1年間でRocketが行ってきた取り組みの中で、私が特に誇りに思っているのは、Enterprise RiskチームやInfoSecチームと深いパートナーシップを築き、新しいAIのユースケースやデータのユースケースを評価する際に、常に彼らの意見を取り入れている点です。法的な観点を超えて、もしこれが私たちのデータ、経験、家族、あるいは隣人に関することだったら、何が正しい行動なのかを常に問い続けています。
データが不当な方法で自分たちや他者をターゲットにしたり、差別的な体験を提供したりするために使用されないことを、どのように確認したいのか考える必要があります。私たちは何が正しいことなのかを自問し、それを企業として行うすべてのことに組み込み、技術面でも徹底する必要があります。
Prompt injectionの攻撃は重大な懸念事項です。この点についてはJeremyがすぐに詳しく説明します。一貫したユーザー体験を維持することを考える際、開発段階では望む機能をすべて備えた新しいAgentを構築できるかもしれませんが、Mike Tysonの言葉を借りれば「誰もが計画を持っている、顔面にパンチを食らうまでは」というわけです。そのシステムを本番環境に投入すると、誰でも好きなことができてしまいます。すぐに、Agentが意図しない言語を話し始めたり、1ドルで車を売り出したりする事態になりかねないので、そういった事態から保護する必要があります。
Generative AIワークロードのセキュリティベストプラクティス
この導入を踏まえて、Jeremy、具体的な防御方法について説明をお願いします。ありがとう、Dan。AWSが提供しているリソースについて、手短にレベル設定をしていきましょう。これらは今週の他のプレゼンテーションや、ブログ投稿、ワークショップでも参照される可能性があるものなので、全員が同じベースラインを持てるようにします。 まず、OWASP Top 10ですが、これはWebアプリケーションの脆弱性に関して長年使用されてきた一般的なオープンソースプラットフォームです。現在では、Generative AIやLLMの脆弱性についてもTop 10リストを提供しています。これはAWSがお客様との会話で頻繁に取り上げるものです。Generative AIワークロードに対するすべての脆弱性や脅威ベクトルを網羅したリストではありませんが、脅威モデリングとリスク評価を始めるための優れた出発点となります。
もう1つ目にする機会の多いリソースが、AWSのGenerative AIに関するスコーピングマトリックスです。これは、 Generative AIで利用可能なリソースと機能を採用または活用する方法を定義した分類システムです。OWASP Top 10の脆弱性をこれに重ね合わせており、オレンジ赤で強調表示されているものは、各スコープの採用方法に応じてお客様が責任を負うものです。スコープ1は消費者向けアプリケーションをカバーしており、これにはBedrock PartyRockやChatGPTのようなインターネット上で公開されているものが含まれます。スコープ2には、新しいSalesforceのGenerative AIアプリケーションやAmazon Qのような、内部データを活用する企業向けアプリケーションが含まれます。スコープ3では、モデルを使用するツールではなく、実際にLLMモデルを使用する段階に移行します - これはFine-tuneデータやRAGを使用しないBedrock上の基盤モデルにあたります。
スコープ4は、この分野の核心部分です。これは、Rocketが行っているような、自社の内部利用や潜在的な外部利用のためにGenerative AIで何かを行っているほとんどのお客様が実際に活動している領域です。ここでは、Amazon Bedrockのカスタマイズされたモデルを使用し、DanがNavigatorに関して言及していたRetrieval Augmented Generationを使用してVector Databaseで独自のFine-tuneデータを追加します。ご覧の通り、スコープ4に入ると、お客様の責任範囲が大きく広がります。スコープ5は、Anthropicのように文字通りゼロからモデルを構築し、モデルの所有権を含むすべてを所有している少数のお客様をカバーしています。
最後にご紹介するデフォルトの考え方が、共有責任モデルです。 共有責任モデルは決して新しいものではありません。AWSや他のクラウドサービスプロバイダーで働いた経験のある方なら誰でも目にしたことがあるでしょう。EC2のような従来型のベアボーンサービスから、マネージドサービスへと移行するにつれて、その責任の一部をAWSに移管できることは周知の事実です。これは、お支払いいただく料金の対価の一部とも言えます。EC2では、パッチ管理やOSの選択、VPCの設定などをお客様が管理する必要がありますが、LLM向けのマネージドサービスであるBedrockを使用する場合、モデルへのインプリントに関するネットワークやコンピュートの処理、モデルの分離保護、オペレーティングシステム、そして基盤となるエージェントの物理コンピュートに関連するすべてをAWSが担当します。
Generative AIのワークロードで興味深いのは、共有責任モデルが社内のペルソナにどのように影響を与えるかという点です。従来のアプリケーションでは、開発チームとセキュリティチームが協力してガバナンスと可観測性を設定していました。LLMワークロードに移行すると、開発者やData Scientist、そしてセキュリティのペルソナが関わってきます。それぞれが専門分野を持ち、自分たちがすべきことを理解していますが、全員が協力して取り組む必要があります。
開発者のペルソナを見てみると、サービスロールなどのワークロードのIdentity and Access Managementを担当し、最小権限の原則に従うようにする必要があります。Amazon EC2や独自のコンピュート上で構築する場合は、OSの選択に責任を持ちます。Amazon BedrockとAgentを使用する場合は、バックグラウンドで実行されるAgent Lambdaを含め、それらのコンピュートエージェントで使用する言語の種類を定義する必要があります。また、エスクローや残高などの下流データを使用してワークロードを拡張する際に必要なデータストアへのアクセスも必要です。
Data Scientistは全く異なる視点を持っています。彼らは、Fine-tuningデータセットの管理、そのFine-tuneデータの保存、モデルの再トレーニング時のイテレーション処理に注力します。Vector Databaseに格納されるRAGデータの管理、各トレーニングセッション後の一貫した結果を確保するためのモデル評価の実施、そしてそれらすべての暗号化の管理に責任を持ちます。そしてセキュリティに目を向けると、ガバナンスと可観測性の話になります。セキュリティのペルソナは、AWSプラットフォーム上で誰が何にアクセスできるか、誤った動作を防ぐためのガードレールは何か、そしてワークロードのコンポーネント間のすべてのトラフィックが暗号化されていることを確認します。
これら3つの領域について説明する中で、暗号化、Identity and Access Management、そしてコンピュートとストレージデータが意図的に複数回言及されました。特にLLMを活用したアプリケーションにおいて最も重要な側面の1つは、脅威モデリングの取り組みを非常に早い段階から開始し、適切なステークホルダー全員が最初から関与することを確実にすることです。
AWSはフレームワークが大好きです - スライドや会話、プレゼンテーションでフレームワークについて多く目にすることでしょう。フレームワークは私たちの焦点を絞り、各ステップを適切に進むことを助けてくれます。私はShostackの4つの質問フレームワークを脅威モデリングに活用しています。もしご存知ない方のために、これから4つの質問すべてを見ていきましょう。まず最初に、私たちが持っているもの - 何に取り組んでいるのか？から始めます。これはユースケースから始まり、ステークホルダー、場合によっては開発者やデータサイエンティストが可能なアーキテクチャのアプローチを提案します。
次の質問は「何が間違う可能性があるか？」です。この質問をする時、すぐにセキュリティについて考えるべきです。これはアプリケーションの障害が起こり得る場所や、不正なデータが発生する可能性、レイテンシーが発生する可能性だけでなく、安全でないプラグインの攻撃を受ける可能性や、Prompt Injectionが起こり得る場所、データアクセスを失う可能性のある場所についても考える必要があります。この質問パターンに従うことで、セキュリティの検討をこれらの議論の非常に早い段階から始める必要があることを示しています。3番目の質問は、アプリケーションアーキテクチャ内で特定したこれらの懸念事項や脆弱性に対して、私たちは何をするのかということに取り組みます。
最後に、そして最も重要なのは - 最小権限の原則に向かって進むのと同様に - これは目的地ではなく旅路だということです。私たちは十分な仕事をしたかどうかを問います。これは、たとえアプリケーションにあまり変更を加えていなくても、常に繰り返しと再評価が必要であることを意味します。脅威モデリングについて、AWSと私は特にSTRIDEを好んで使用しています。STRIDEをご存じない方のために説明すると、これは一連の頭字語で、各文字が特定の脆弱性カテゴリーに対応しています。例えば、STRIDEのSはSpoofing（なりすまし）を表し、これは最も一般的にアプリケーション全体での認証や認可の効果を低下させる種類の攻撃です。さらに下を見ると、Information Disclosure（情報漏洩）があり、これはアプリケーションが持っている、またはアクセス可能なデータの機密性を低下させることに関連します。利用可能な脅威モデルは多くあります - STRIDEが絶対的に最高だと言っているわけではなく、単に私が慣れ親しんできたものの一つです。他のモデルにはOCTAVE、MITER ATT&CK、DREADなど、いくつかあります。
あなたの環境で独自の脆弱性分類方法を持っているかもしれません。私が強調したいのは、特に脅威モデリングにおいてフレームワークに従うことが非常に重要だということです。私はラビットホールについて言及しましたが - 誰かが「私は認証と認可のエキスパートだ」と言って、認証と認可に関するすべての脆弱性は見えるけれども、権限昇格やサービス拒否について完全に忘れてしまうことは非常に簡単です。なぜなら、それは脳の別の部分で、どこかに置いてしまって今は失ってしまったからです。そのため、フレームワークは目標に集中し続けるのに非常に役立つ構造なのです。
これから3つのスライドを見ていきます。これが最初のスライドで、基礎について話します。これらはLLMワークロードに関連するAWSのベストプラクティスです。これは完全な網羅的なリストではありませんが、特定のユースケースに適用可能なものよりも包括的です。例えば、これらはすべてRocketのワークロードを評価する際に考慮した事項ですが、すべてのRocketワークロードに当てはまるわけではありません。そのため、十分な精査を行うようにしてください。まず、LLMアプリケーションについて話す際の2種類のセキュリティ問題があります：対処が必要な従来型の脆弱性と、より非決定論的な新しい一連の緩和戦略です。これらが非決定論的なのは、LLMが非決定論的だからです。アプリケーションの中でLLMのような信頼できないエンティティと対話する場合、決定論的なセキュリティを持つことは非常に難しいのです。
では、そこからどうすればよいのでしょうか？特定のタスクに向けてアーキテクトを設計します。Danが先ほど言及したように、私たちはマルチエージェントアーキテクチャを採用しています。各エージェントは、非常に具体的なタスクのために参照できるアクション、プラグイン、データソースの範囲が限定されているためです。特権的なアクションに関しては、必ず人間をループに入れるようにしましょう。LLMは素晴らしいものです - ここ数年で、LLMが得意な分野とそうでない分野がかなり明確になってきました。LLMは技術専門家の代替ではなく、技術専門家のレベルを上げ、作業を加速させるためのものです。そのため、特権的なアクションには必ず人間を介在させてください。
権限を制限する際は、エージェント同士が連鎖しないようにすることが重要です - これを許可すると目的が台無しになってしまいます。AWSに詳しい方なら、ロールチェーニングという用語をご存知かもしれませんが、あるロールが別のロールにアクセスでき、そのロールがさらに別のロールにアクセスできるような状況と同じです。エージェントの場合も、慎重に設計していないと同じことが起こりえます。各エージェントが特定のアーキテクチャ機能を持つことで範囲が制限されると思っていたのに、実際には1つのエージェントが他の7つのエージェントにアクセスでき、本来の目的には不要なデータにアクセスできてしまうのです。
もう1つの推奨事項は、Amazon Bedrockのようなクラウドサービス - マネージドサービスを使用してLLMを構築することです。これにより、セキュリティ上の考慮事項が組み込まれます。Bedrockには自然に備わっている機能がいくつかあります。例えば、Bedrock Agentsには、ある程度のプロンプトインジェクション保護が組み込まれています。また、事前に定義された入出力の期待値に基づいて、モデルを何度も再トレーニングする際の実際の成功度を評価するために、Bedrockのモデル評価機能を使用することもできます。これは自動化することができ、また自動化すべきで、よく知られているサービス拒否攻撃やオーバーフロー攻撃を防ぐことができます。
デリミタを使用し、コンテキストウィンドウを制限することも検討できます。バッファオーバーフロー攻撃をご存知の方もいるかもしれませんが、LLMにおける同等の攻撃がコンテキストウィンドウオーバーフロー攻撃です。これは、敵対的な脅威があなたのアプリケーションに害を与えたり、アプリケーションからデータを露出させたりしようとする最初の方法でしょう。基本的な仕組みを説明すると、LLMに送られるプロンプトの最初に来るアプリケーションの指示が、先入れ先出し方式のため、コンテキストウィンドウに大量のコンテキストを入れることで破棄されてしまうのです。つまり、十分な量の独自の指示を作成することで、アプリケーションで設定した指示をすべてバイパスできてしまいます。そのため、コンテキストウィンドウを設定することが非常に重要です。
より決定論的でない緩和技術の検討に移ると、このスライドに示されているようなものが出てきます。まず、私たちはフレームワークの大きなファンです - これは何度も耳にすることになるでしょう。入出力のサニタイズについてのOWASP ASVS（Application Security Verification Standard）は、絶対に参照すべきものです。これは広く精査された非常に優れたガイドです。
メディアや外部関係者からのこのような批判は、実はオープンソースの素晴らしい点です。なぜなら、入出力のサニタイズに関して実施可能なステップを見落とさないようにする助けとなるからです。もう1つの考慮点は、プロンプトがエンドユーザーによって扱われる場合です。例えば、キーワードを選択したり、事前定義されたプロンプトを実行したりするのではなく、Navigatorのように、ユーザーが自然言語入力で直接モデルとやり取りする場合などです。
入力と出力の両方をサニタイズする必要があります。プロンプトインジェクションに対するユーザー入力は、LLMに到達する前に十分に評価されるべきです。これは、コンテキストウィンドウが制限されていることを確認し、後ほど説明するデリミタに使用するキーワードやその他のメカニズムがトークン化されていないことを確認することを意味します。また、出力を無条件に信頼しないようにすることも重要です。OWASP Top 10でも触れている過剰な権限や過度の依存について、LLMが常に正確な出力を生成すると信じることは正しくありません。
何度も申し上げていますが、LLMの出力は信頼すべきではありません。これは、LLMが非決定論的であり、毎回同じ答えを出すわけではないからです。モデルをトレーニングすると、事前に用意したQA用の質問セットでは把握しきれないような形で、過去の応答の影響が変化する可能性があります。QAチームはすべてのプロンプトのパターンを想定することはできません。もう1つの重要な点は、LLMをワークロード内の信頼できないエンティティとして扱うべきだということです。つまり、LLMに渡すものも、LLMから返ってくるものも信頼できないということです。
すでにコンテキストウィンドウの制限について触れましたが、PII、知的財産、バイアスを除去するためのデータサニタイゼーションは、トレーニングプロセスやファインチューニングプロセスの間に行われるべきです。また、LLMに入力されるデータを評価する際にも必要です。もう1つの重要な点、そして私が最も注目している新しい緩和技術は、デリミタの使用です。LLMに入力を渡す際、使用するLLMやアクセス方法によって、基本的にJSONドキュメントを渡します。このJSONドキュメントは、すべての入力を巨大なドキュメントブロブとしてLLMに渡します。そしてLLMは、その入力をすべて同じカテゴリー、同じ信頼レベル、同じ権限レベルの入力として扱います。
しかし、これは正確ではありません。高度なプロンプト、LLMの動作や対話の種類を制限するために使用するアプリケーションレベルのプロンプト、そしてエンドユーザーからの信頼できないプロンプトがあります。これらは同じではなく、同じように信頼されるべきではありません。JSONドキュメントを渡す際にできることの1つは、キーワード、記号、その他のマーキングを使用して、信頼できる入力と信頼できない入力を分離することです。アプリケーションからの入力を信頼できるものとし、エンドユーザーからの入力を信頼できないものとして分離し、適切にモデルをトレーニングすることで、モデルにデリミタを認識させ、それらのプロンプトを別々に扱わせることができます。
これは、Tokenizerプロセスを制御できる場合に追加できる機能です。単にFoundation Modelを使用するのではなく、マルチモーダル構造でオーケストレーションを行うモデルやサブモデルを構築している場合、Tokenizerを制御できます。その場合、信頼できないデータとの組み合わせではなく、アプリケーションがサポートする入力に基づいて判断を行うために、それぞれの入力を個別にTokenize化することができます。もちろん、これが全てを解決するわけではありません。現在、敵対的なプロンプトを認識し、信頼できないデータと信頼できるデータを分離して判断するようにモデルをトレーニングしています。これらは何度も繰り返して改善していく必要があります。最近、この分野で多くの優れた研究成果が出ており、そのレベルでモデルを活用したり、アプリケーションを活用したりする場合には、ぜひ取り入れることをお勧めします。
最後に、これはよりアーキテクチャに関連する話になりますが、セーフガードを設定してください。トレーニングデータやRetrieval Augmented Generation（RAG）で使用するVector Databaseに入るデータをクリーンにし、サニタイズしてください。Fine-tuningデータやVector Databaseにデータを追加・変更・削除できる権限を持つ人を制限することが重要です。これは強調してもしきれないほど重要です。Model Poisoningについて話すとき、Foundation Modelを使用している場合は自分には関係ないと考える人が多くいます。
しかし、先ほどのスコーピングマトリックスで見たように、それは正しくありません。RAGを使用する場合、私のデータはそこに含まれており、Vector Databaseにアクセスできる人は誰でもモデルが生成する出力を操作できます。住宅ローンやエスクロー残高について話している場合、これは深刻な問題となります。外部データの出所を証明するために、何らかのML-BOMを設定することが非常に重要です。
現在、人々が懸念している大きな脅威の1つは、まだ大規模には行われていませんが、Agent が Fine-tune データやトレーニングデータに埋め込むためにスクレイピングしているウェブサイトが汚染される可能性です。これは問題となるため、ML-BOMを持ち、証明書を確認すること、つまり他のコードリポジトリと同様に、モデルに入るすべてのデータのサプライチェーンや使用しているモデルを理解することが、何か問題が発生した場合に少なくとも追跡して迅速に修正する方法を確保する上で非常に重要です。
Rocketの事例：脅威モデリングと対策の実装
ここで一度振り返ってみましょう。AWSのベストプラクティスについて、そしてRocketが顧客体験を革新し、潜在的にRocketの利益率を最適化する方法について話してきました。33%のコンバージョン率は非常に重要です。では、これらをどのように組み合わせたのでしょうか？まず、私たちが取り組んでいることを見直すことが重要です。SHOSTACK's 4-Question Frameに戻ってみましょう。これがClient-facing Assistantのアーキテクチャです。認証済みおよび未認証のユーザーがWebまたはモバイルのDigital Propertiesを通じてOrchestratorにアクセスします。これはClient-facing AssistantのBackend for Frontend APIであり、下流の処理を実行するための複数のDomain Agentにアクセスできます。下流の処理とは、ユーザーが実行したい操作の種類に応じて、Action Groupsでのアクセスをトリガーしたり、データテーブルからデータを収集してエンドユーザーに返したりすることです。
アーキテクチャはできましたが、どのような問題が起こり得るでしょうか？まず、誰でも入力フィールドに何でも入力できてしまいます。Context Overflow攻撃を試みられたらどうでしょう？適切にContext Windowを制限していますか？Prompt Injection攻撃を防ぐため、LLMに入力されるデータや出力されるデータを適切にエンコードしていますか？手動入力が可能な場合、誤った動作や利用規約に反する動作を引き起こすPromptを防ぐために、どのような対策を講じていますか？
もう一つの懸念は、Model Denial of Serviceです。自動化されたリクエストを繰り返し送信する人がいて、レート制限が設定されていない場合、正常なトラフィックが通れなくなる可能性があります。さらに下流では、Assistantが個人情報を漏洩したり、コンプライアンスに反する用語を使用したりする可能性のある、安全でない出力処理の問題があります。機密情報の漏洩のリスクもあります。例えば、売り手が価格を釣り上げるために買い手の銀行情報やクレジットスコアを確認しようとするケースです。これはRocketのような高度に規制された業界では許容できません。
また、LLM出力への過度な依存や過信という問題もあります。70%のセルフサービス対応において、エンドユーザーに提供する前に、データと照らし合わせて適切で信頼できる出力であることをどのように評価していますか？最後にバックエンドについて、すべてのAPIコールの認証と認可をどのように確実に行っているでしょうか？LLMとワークロードのコンポーネント、そして誰の代理として動作しているかの証明をどのように行っているでしょうか？クライアント1がデータストアのデータを要求する際に、クライアント2のデータを取得するPromptを入力した場合、アプリケーションの入り口ではなくLLMの下流で、適切なデータを取得していることをどのように検証しているでしょうか？
では、何が問題になり得るかは分かりました。これらをどのように修正し、対処すればよいのでしょうか？いくつかのポイントがあります：システムレベルのプロパティと制御機能で許容される使用を定義すること。Agentを呼び出す際のLLMの使用について、例えばGuardrailsのような仕組みが重要な役割を果たします。これは、エンドユーザーからのアクションやリクエストを、住宅ローンなど、扱うべき範囲に限定するための高度なPromptingを行うものです。
私たちが話すべきは住宅ローンの組成、借り換え、サービシングについてであり、Chris Evansが出演している映画や、新しいDeadpoolとWolverineの映画の興行成績についてではありません。これらは許容される用途ではありません。また、必須パラメータの収集と浄化も行っています。例えば、銀行業や住宅ローンのような高度に規制された業界では、クライアントがローン商品について問い合わせたり申し込んだりする場合、その事業を行う州を知る必要があります。なぜなら、銀行員は米国のすべての州で免許を持っているわけではなく、特定の州でのみ免許を持っているからです。これは、アプリケーションが下流で使用する必要のあるパラメータの一例です。
エンドクライアントのPIIを誰にでも見せないよう、また実際にそのクライアントを担当する権限のある銀行員にのみ公開されるよう、パラメータの取り扱いには細心の注意を払う必要があります。ユーザーがエスクロー残高について尋ねてきた場合、その人自身のエスクロー残高だけを表示するようにしなければなりません。LLMが過度な権限を持ってエスクロー残高を勝手に作り出すことは許可していません。代わりに、クライアントIDとローンIDに紐づいたエスクローテーブルに対して、非常に限定的なAPI呼び出しを行う専用のAgentをトリガーするようにしています。エスクロー残高がLLMからエンドユーザーに返される際には、AとBが一致していること、そしてBがアプリケーションスタックの各層で適切に認可されていることを検証しています。
最後に重要なのは、住宅ローンの最終判断をAIに任せてはいけないということです（もし1ドルで住宅ローンを提供してくれるなら別ですが）。必ず人間が介在する必要があります。そのため、Rocketのソリューションによってまとめられたすべてのデータは、最終的に銀行員や認可された住宅ローンブローカー、あるいは最終判断を下す権限を持つ担当者に送られ、人間による確認やレビューを確実に行うようにしています。
脅威モデリングを行い、決定論的なデータセキュリティを導入するにはどうすればよいでしょうか？他にどのような対策を講じているのでしょうか？脅威を特定し、いくつかの解決策を見出しました。これは、スタック全体にわたって認可と認証を実装した例です。例えば、認証済みユーザーがいます。Danが先ほど述べたように、認証済みユーザーにはJWTトーンが発行されます。このJWTトークンには、クライアントIDやローンIDなどの詳細情報が含まれており、これらはスタック全体で認証・認可の参照に使用され、また可観測性の観点から重要なトレーシングにも使用されます。
ユーザーが認証を受けてJWTを取得し、適切なパラメータを持った状態でアプリケーションにアクセスし、自然な会話形式で「私のエスクロー残高はいくら？」と尋ねます。これはDigital Propertiesのウィンドウを通じて - ウェブでの対話かもしれませんし、アプリ内での対話かもしれません - クライアント向けAssistantのオーケストレーション層に送られ、そこでエスクローデータにアクセスできる適切なDomain Agentを決定します。ServicingのDomain Agent配下のエスクローAPIコールは、JWTの情報を携えながら、認証済みユーザーのクライアントIDとローンIDに一致する特定のエスクロー残高を対象とします。
このように、スタック全体を通じてどのように処理されているかがわかります。最後に、データストレージ層に対してAPIコールを実行します。データストレージ層では、適切なIAMを使用して、LLMまたはAgentがユーザーに代わってコールを行うための適切なサービスロールを持っていること、そしてクライアントIDがテーブル上で一致することを検証・認可します。その情報が返されてユーザーに渡される過程で、モデルが誤った情報を生成していないことを確認するための最終的な無害化と評価を行います。評価のポイントは：人間が読める形式になっているか？「あなたのエスクロー残高は3,400ドルです」- はい、これはOKです。さらに重要なのは、その3,400ドルがデータストレージから取得したデータと完全に一致しているか、そしてそれがクライアントIDとローンIDに直接紐づいているかということです。これらすべての条件が満たされれば、エスクロー残高について自然言語で問い合わせを行ったクライアントに対して、セルフサービスでレスポンスを返すことができます。
では、次に何をすべきでしょうか？私たちは繰り返し、評価を続けていきます。まず、実施した対策が期待通りの成果を上げているかを確認する必要があります。私たちは効果的に仕事を行えたでしょうか？これは徹底的なPen Testingを通じて確認します。内部および外部のPen Testingが必要で、これは定期的に行うと同時に、モデルを再トレーニングするリリースごとに実施すべきものです。これはモデルの精度が維持されているか、新しいFine-tuneデータに基づく大きなドリフトが発生していないかを確認するだけではありません。
また、新しいAgentの追加や、コンテキスト要件の変更によって、対策が無効になったり、モデルやアプリケーションの新しい進化の方向性の妨げになったりしていないかを確認する必要があります。そして最後に何をすべきでしょうか？正確性、完全性、明確性について、人間によるレビューが必要です。人間によるレビューを通じて、BedrockやSageMakerを通じて行われたモデル評価の出力を再評価する必要があります。
トレーニングデータとRAGが最新の状態を保っているか、リポジトリ内の何千もの古いドキュメントが全て置き換えられており、更新された情報のみが参照されているかを確認する必要があります。実施した対策が包括的であることを確認し、アーキテクチャを変更する際には毎回Threat Modelに立ち返り、アーキテクチャの変更によって新たな脅威が潜在的な問題として浮上していないか、それに対する新しい対策が必要ではないか、そして最終的に許容可能なリスクは何かを考える必要があります。私はSecurityの立場なのでバイアスがありますが、許容可能なリスクとして分類される問題もあります。些細なGoogle検索やChatGPTの質問に対する不正確なHallucinationは、おそらく全く問題ありません - 許容可能な使用で、ユーザー自己責任です。しかし、住宅ローンや融資情報に関する場合は、そのような情報の誤りを許容することはまずありえないでしょう。
AIセキュリティの重要ポイントとリソース
Dan、私、そして残念ながら今回参加できなかったRiteshが、皆さんに特に覚えておいてほしい4つの重要なポイントがあります。まず第一に、セキュリティはAIのライフサイクル全体、スタック全体を通じて実施される必要があります。これは入口のポイントだけでなく、エンドユーザーにデータが返される時だけでもなく、階層的なアプローチが必要です。Securityの立場の方々にとっては当たり前のことかもしれませんが、それ以外の方々にとっては、アプリケーションを検討する際に必ずしも考慮されていない点です。この場合、アプリケーションの外部に信頼できないエンティティがあり、内部にも信頼できないエンティティがあるため、あらゆる層でセキュリティが重要になります。
セキュリティは全員の責任です。Developer、Data Scientist、Securityの担当者、あるいはアプリケーションやそのデータに関わる全ての人が、自分がアクセスできるものに対するセキュリティに責任を持ちます。そしてstar starの権限を持っている方々には申し訳ありませんが、それは全てに対して責任があるということです。Rocketがこのプロセスを全てのアプリケーションで素早く一貫して実行できた成功の理由の一つは、この点を非常に早い段階で認識していたことです。彼らはPOCや本番環境に入る前の段階で、Developer、Data Scientist、Securityの担当者など、複数のチームを一つの部屋に集め、ユースケースに合わせたアーキテクチャの検討を行いました。
LLMは時として期待を裏切ることがあります - それらは非決定論的だからです。使用するモデルによっては、2+2が「魚」になってしまうこともあり得るのです。そのため、適切な出力のサニタイズが必要であり、決定論的なセキュリティコントロールと顧客・クライアントデータを確実に保護する必要があります。企業全体のガバナンスとユースケースごとの脅威モデリングは、単なる提案ではなく必須要件です。これら2つを同時に実施しなければ、一貫した結果は得られず、いずれ困った事態に直面することになるでしょう。Rocketがこれらを非常にうまく実施できているからこそ、Danと彼のチームは安心して眠ることができるのです。
AWSサイドでも重要な教訓があります。Responsible AIは常に変化し続けています。現時点では、おそらく毎週のように新しい規制や会議、サミットが開催されています。これはAWSにとって進化し続ける分野です。私たちはResponsible AIを6つの柱で定義しています：バイアスと公平性、説明可能性、堅牢性、セキュリティとガバナンス、透明性、そしてプライバシーです。プライバシー、セキュリティ、ガバナンスはここでのいくつかの柱に過ぎないことに注目してください。他にも責任を持つべき要素が多くあります。これは小さな問題ではありません。また、これは現時点での定義であり、この分野が進化し、科学者や規制当局が7番目や8番目の柱を提案するにつれて、AWSもこれを見直し、変更する可能性があることを覚えておいてください。
私のように常に好奇心旺盛な方のために、いくつかのリソースをご用意しています。ブログがいくつかあり、ワークショップもあります。そして、OWASP LLM AI Cybersecurity Governance Checklistへのリンクもあります。これは、デューデリジェンスを行うための出発点となるフレームワークです。ブログは本当に興味深く、Rocket Logicについてより詳しく説明しています。最初の概要では、アーキテクチャについて深く掘り下げています。また、階層化された認可によるデータプライバシーの強化に関する別のブログでは、トレーサビリティ、オブザーバビリティ、そしておそらく最も重要な認証の向上のために、JWTをアプリケーションスタックの全層でどのように扱うかを具体的に説明しています。最後に、非常に似た内容を扱うワークショップがあり、OWASPフレームワークを使用してチャットボットのセキュリティを改善する方法を説明しています。以上で終わりですが、皆様のご来場に心から感謝申し上げます。Danと私には他にもセッションがありますが、皆様にここに来ていただいたことを大変嬉しく思います。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion