re:Invent 2024: Amazon Bedrockのセキュリティ - RemitlyのAI活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Understanding security & privacy on Amazon Bedrock, featuring Remitly (AIM360)
この動画では、Amazon Bedrockのセキュリティとプライバシーについて、AWSのMachine Learning SpecialistのQingwei Liと、Remitlyの事例を交えて解説しています。Bedrockの基本的なセキュリティ機能として、推論とトレーニングのデータを一切保存しないポリシーや、GDPRやHIPAAへの準拠について説明しています。また、Deterministic ControlsとProbabilistic Controlsという2種類の制御方法を組み合わせた多層防御の実現方法や、Automated Reasoning、Knowledge Bases、Guardrailsなどの具体的な機能の活用方法を詳しく解説しています。Remitlyの事例では、730万人のアクティブユーザーを持つ送金サービスにおいて、Bedrockを活用してカスタマーサポート体験を変革し、チャットボットによる問い合わせ対応率25%を達成した実績が紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Bedrockのセキュリティとプライバシーに関する概要
それでは始めましょう。皆様、おはようございます。AWSのMachine Learning Specialistの李慶緯（Qingwei Li）と申します。本日は、私と登壇者の方々で、RemitlyのケースをもとにAmazon Bedrockのセキュリティとプライバシーについてご説明させていただきます。
業界調査によりますと、セキュリティは依然として、規模を問わず多くの組織にとって主要な懸念事項となっています。データのプライバシーとデータ保護は、毎年の調査で主要な懸念事項の一つとして挙げられています。 本日のトークでは、Generative AIのセキュリティに焦点を当てます。まず、Amazon Bedrockのセキュリティについて説明し、Bedrockのセキュリティに焦点を当てたコンポーネントについてご紹介します。その後、Remitlyの同僚が、セキュアなGenerative AIアプリケーションを構築するためのBedrockの活用経験についてお話しします。最後に、同僚のRajが、私たちの観察と経験に基づいて、セキュアなGenerative AIアプリケーションを構築するためのパターンについてご紹介します。
Amazon Bedrockのデータ保護とプライバシー機能
Generative AIのセキュリティについて考える際、3つのステージに分けることができます。第一のステージはモデル自体で、モデルプロバイダーがデータの管理、クリーニング、フィルタリングを行い、トレーニングされたモデルの安全性を確保する必要があります。第二のステージはモデルへのアクセスで、データアクセスの認証と認可が含まれます。最後に、Generative AIアプリケーション全体のセキュリティを考える必要があります。これは、AIモデルに到達する前のデータのセキュリティと、モデルが出力を生成した後に、組織のResponsible AIポリシーに準拠していることを確認することを意味します。
Amazon Bedrockについて簡単にご紹介させていただきます。Bedrockは、お客様がGenerative AIアプリケーションを簡単に構築・スケーリングできるように設計された、フルマネージド型のGenerative AIサービスです。お客様は、独自のモデルをトレーニングしたり、インフラストラクチャの展開を心配したりすることなく、Generative AI Foundation Modelにアクセスすることができます。私たちの取り組みの一つは、 お客様に最高かつ最新のFoundation Modelを提供することです。私たちはお客様に選択肢を提供したいと考えています。画面には、Anthropic、Meta、Amazon、その他の主要プロバイダーからの強力なモデルを含む、さまざまなモデルプロバイダーのFoundation Modelのリストが表示されています。多くの方々が、Bedrock内のFoundation Modelを試されたことと思います。
Bedrockについて理解したところで、Bedrockがセキュリティをどのように確保しているのかを見ていきましょう。まずは、Bedrockのデータプライバシーと保護の部分からお話ししたいと思います。 これは非常に基本的なことで、本日のセッションで何度か繰り返すかもしれませんが：私たちは推論とトレーニングのデータを一切保存しません。保存しないということは、モデルプロバイダーによってデータが漏洩、共有、閲覧される可能性がないということです。Amazonがいかなる目的でもそのデータを使用することはできません。私たちが保存するのは、請求目的の使用データなどの運用メトリクスと、Bedrockコンソールにログインした際にカスタマイズジョブのリストを確認できるようにするためのメタデータのみです。さらに、すべてのプロンプトとデータはお客様ごとに分離され、APIリクエストを送信したのと同じリージョンに留まります。例えば、Frankfurtリージョンにモデル呼び出しリクエストを送信した場合、そのリクエストは同じリージョン内に留まります。先ほど述べたように、私たちはお客様にFoundation Modelの選択肢を提供したいと考えていますが、アカウントでモデルを有効にするかどうかはお客様次第です。アカウント内のユーザーに対してどのモデルを有効にするかは、お客様が決定します。また、Amazon Bedrockサービスとの間のすべての通信が暗号化されていることも確認しています。
データは常に転送中に暗号化されています。モデルのFine-tuningを行う際、Bedrockでそのモデルを提供するためにコピーを保持する必要がありますが、お客様独自のAWS KMSキーでモデルを暗号化することができます。これにより、お客様のみがモデルにアクセスできる状態となります。また、Amazon BedrockはGDPR、HIPAAをはじめとする多くのコンプライアンスプログラムを取得していることもお伝えしておきたいと思います。
Amazon Bedrockの接続性とアクセス制御
データ保護とプライバシーについて説明したところで、接続性についてお話ししましょう。画面右側のセットアップを見ると、サービスコンポーネントとAPIエンドポイントが同じリージョンに存在するAmazon Bedrockのサービスアカウントがあります。左側には、お客様のVPCを持つクライアントアカウントがあります。お客様がBedrockサービスにAPIコールを行う際、パブリックアドレス空間経由とプライベートアドレス空間経由の2つの方法があります。黄色の線はパブリックアドレス空間を表しています。VPC内からAmazon Bedrockにリクエストを行う場合、トラフィックはまずインターネットゲートウェイを通り、パブリックアドレス空間を経由してAPIエンドポイントに到達します。パブリックアドレス空間を経由すると言っても、トラフィックがAmazonリージョナルネットワークを離れることはなく、つまりパブリックインターネットに晒されることはありません。
BedrockサービスへのAPIコールを社内ネットワークから行う場合は、パブリックインターネットを経由してBedrockサービスにアクセスする必要があります。プライベートVPC内にリソースを持つお客様や、アカウント内でパブリックインターネット空間を制限するポリシーを持つお客様にとって、このアプローチは適していません。そのため、Amazon Bedrockはプライベート接続オプションも提供しています。まず、VPCエンドポイントを作成して、お客様のVPCとAmazon Bedrockサービスの間にプライベート接続を確立する必要があります。BedrockサービスへのAPIコールやリクエストを行う際、トラフィックはパブリックアドレス空間を経由せずにAPIエンドポイントにプライベートに接続され、プライベートな接続性が確保されます。
次にアクセス制御についてお話ししましょう。IAM管理者は、誰がBedrockリソースへのアクセスを認証・承認されるかを制御します。画面には2つのポリシー例が表示されています。1つはモデルの権限を具体的に指定するもの、もう1つはモデルの権限を許可するものです。これらのポリシーを通じてモデルへのアクセスを細かく制御できるため、非常に便利です。最近、Application Inference Profileという機能をリリースしました。これは、モデル呼び出しリクエストを送信できるリソースだと考えてください。Application Inference Profileにタグを付けることができ、これは非常に便利です。なぜなら、IAMポリシーに条件要素を追加することで、誰が各モデルにアクセスできるかをさらに細かく制御できるからです。私の経験では、お客様は複数のApplication Inference Profileを作成します。同じModel IDに対して異なるアプリケーション用に作成することもあり、これによってモデルへのアクセスを非常に細かいレベルで制御することができます。
Amazon Bedrockの可観測性とResponsible AI
では、可観測性と監査可能性について説明しましょう。まず、Amazon CloudWatchを使用してBedrockを監視できることをお伝えしたいと思います。
Amazon CloudWatchを使用してBedrockをモニタリングすることができます。Amazon CloudWatchは生データを収集し、処理して、非常に読みやすいリアルタイムのメトリクスとして表示します。画面で見ていただけるように、呼び出し回数、レイテンシー、エラーなどのメトリクスがすべてCloudWatchに表示されます。さらに、デフォルトではオフになっているModel Invocation Loggingと呼ばれる機能をオンにすることもできます。これにより、リクエストの入力、出力、およびリクエストに関連するメタデータがすべてお客様のアカウントに保存されます。ここで強調しておきたいのは、データは確かに保存されますが、それはお客様のアカウント内であり、アクセスできるのはお客様だけだということです。
Amazon BedrockはCloudTrailとも統合されています。CloudTrailはアクションの記録を提供するので、Amazon Bedrockアカウント内で誰がどのような操作を行っているかを、ユーザーロール別に確認することができます。ここで注目していただきたいのは、CloudWatchとCloudTrailを使用することで、アカウント内で完全な監査性と可観測性を確保できるということです。
最後に、Amazon Bedrock Guardrailsに関連して、私たちがResponsible AIについてよく話題にすることをお伝えしたいと思います。Guardrailsの各コンポーネントの詳細については、同僚のRajが説明する予定なので、ここでは深く触れません。しかし、大まかに言えば、Guardrailsは責任あるAIポリシーを確実に守るための保護機能だと考えることができます。ユーザーがリクエストを送信すると、まずGuardrailsに送られます。違反が検出されなければ、モデルがリクエストを受け取って推論を行います。Guardrailsによって違反が検出された場合は、デフォルトのメッセージがユーザーに返されます。もちろん、どのようなメッセージを返すかはカスタマイズして制御することができます。これは、推論モデルが生成する出力についても同様で、AIポリシーが確実に守られるよう、Guardrails内の保護機能によってチェックされます。
Remitlyの事例：クロスボーダー送金におけるGenerative AIの活用
ここまでで、Bedrockのセキュリティ機能についてよく理解していただけたのではないかと思います。それでは、Remitlyの皆様にバトンタッチしたいと思います。ありがとうございました。ありがとう、Kim。皆さん、こんにちは。私はRemitlyのVP Product ManagementのAnkurです。Bedrockの実装と、それを使って私たちがどのようにお客様の体験を変革したかについてお話しできることを大変嬉しく思います。Remitlyは、お客様が毎年数十億ドルを世界中に迅速かつ確実に送金できるようにサポートするデジタルネイティブなアプリです。私たちのビジョンは、国境を越えた金融サービスを提供することで、人々の生活を変革することです。私たちのお客様の大半は、様々なユースケースで国境を越えた送金に私たちのサービスを利用しています。クロスボーダー送金は、多くの人々やお客様にとって非常に重要なライフラインとなっています。
2つの視点から詳しく見てみましょう。戦略的な視点から見ると、世界銀行によれば、低・中所得国向けの送金額は6,560億ドルを超え、海外直接投資や開発援助金をはるかに上回っています。次に顧客の視点から見ると、2022年に約2,500人のお客様を対象に、送金された資金がどのように使用されているかを調査しました。その結果、52%のお客様が送金額の50%が家計費に使用されていると回答しました。このことからも、透明性を保ち、タイムリーで信頼性の高いサービスを提供することが、お客様のニーズにとっていかに重要であるかがわかります。
13年にわたって築き上げてきた優れた製品は、お客様からの信頼につながっています。これは、前四半期における730万人の四半期アクティブユーザー数、145億ドルの四半期取引量、そして約170カ国にわたるグローバルな事業展開に反映されています。そして私たちがよく言うように、これはまだ始まりに過ぎないのです。 ここからは、Generative AIを活用してサポート体験をどのように変革しているかについてお話しします。私たちはデジタルファーストの企業であり、テクノロジーを活用してお客様の課題を解決することを重視しています。Fintechの分野では、イノベーションが爆発的に起きているため、私たちは常に新しいテクノロジーとそれによるお客様の課題解決方法を探っています。これから、この技術の実装方法と、私たちがどのように適用したかについてお話しします。
まず、一般的な状況についてお話ししましょう。先ほど触れたように、遅延は私たちのビジネスにおけるお客様の信頼を損なう要因となります。実際、お客様の約95%は、カスタマーサポートに連絡することなく取引を完了しており、その多くは期待以上のスピードで完了しています。 しかし、約5%の取引では、取引を完了できない場合や追加情報が必要な場合、あるいはお客様が配送状況について問い合わせてくる場合があります。このような状況では、サポート体験がお客様の安心感と私たちのサービスへの信頼にとって極めて重要となります。
遅延が発生すると、 お客様の信頼は低下します - これは私たちにとって直接的な相関関係があります。事業の成長に伴い、優れたカスタマーサポート体験を確保することが重要です。私たちは長年にわたって約30%の成長率を維持してきました。前四半期だけでも、総アクティブユーザー数は前年比35%増、送金量は42%増を記録しました。サポート量も同様のペースで増加しています。18の言語でサービスを提供しているため、効果的なサポートの提供が非常に重要になります。人的対応だけでは規模の拡大が難しくなるため、テクノロジーが不可欠となっています。
私たちは、一定期間でサポート量を4分の1に削減するという意欲的な目標を掲げており、テクノロジーを活用してこれを実現しようとしています。 サポートにおける重要な考慮事項には、顧客満足度と直接的な相関関係がある迅速な解決時間があります。また、多様なユースケースに対応する必要があります。構造化された取引データや、非構造化のテキストやチャットなど、さまざまな形式のデータを扱います。リアルタイムのオンラインチャット体験では、時には100ミリ秒以下で意図を理解する必要があります。さらに、アカウントの変更から送金状況の確認まで、お客様からの問い合わせは多岐にわたります。サポートには複数のコミュニケーションチャネルが必要です - メール、電話、チャットなど、お客様がいる場所で対応できなければなりません。金融サービス企業として、個人情報や金融データのコンプライアンスとセキュリティは不可欠です。
Generative AIを活用したサポート体験の変革
Generative AIにより、いくつかの分野で新たな可能性が見えてきました。意図の分類において優れたパフォーマンスを発揮し、生成された応答によってより良い顧客体験を創出できます。従来のエンコーダーとデコーダーモデルという大がかりな作業に比べ、Prompt Engineeringを使用した新しいユースケースの迅速な展開が容易になります。Generative AIにおいて、RAGやガードレールなどの機能により、ハルシネーションが減少し、Large Language Modelを活用できるようになっています。また、問題の規模に合わせて効率的にワークロードをスケールすることができます。
課題を2つの形に分けて説明させていただきます。1つ目は運用上の課題です。お客様への応答を可能にするために、適切な参照文書を見つけ出す必要があります。応答は非常に迅速で、時には6秒以内に行う必要があり、お客様が私たちのテクノロジーとサービスを信頼できるよう、応答の正確性が極めて重要です。私たちは規制対象の金融サービス企業であるため、セキュリティ面での課題が特に重要です。データプライバシー、アクセス制御、ネットワークセキュリティは非常に重要な要素です。サポートの記録には個人情報が含まれているため、安全に取り扱う必要があります。データは体験をパーソナライズするために不可欠ですが、安全に保存・管理しなければなりません。
それでは、ソリューション設計についての全体的な考え方をお話ししましょう。お客様が従来型のBotに検索クエリを入力し、私たちはお客様の取引データを持っています。この2つを組み合わせて、従来型とNeural Networkの検索を組み合わせたハイブリッド検索を行います。その後、コンテンツ取得セクションに進み、検索を使用してセルフヘルプガイドのコンテンツスニペットに保存されている関連コンテキストからデータを取得します。
検索では、使用できる正確な参照文書を探そうとしています。次に、レスポンス生成と呼ばれる段階に進みます。ここでは検証の正確性を重視しており、正しい参照を見つけるためにサブシステムを検索し、コンテンツの取得と生成の正確性を確認します。その後、レスポンス検証という次の段階に移ります。これには3つのステップがあります。まず、レスポンスが参照文書を引用しているかどうか。次に、引用された文書が最初に与えられた参照資料に含まれていたかどうか。そして3つ目は一貫性で、レスポンス、質問、参照文書が、私たちが答えようとしている内容のコンテキストと一貫しているかどうかを判断します。
では、アーキテクチャを見ていきましょう。お客様がチャットインターフェース内でリクエストを入力する従来型のChatbotがあります。また、Intent分類システムである修正システムと、Q&Aワークフローもあります。このフレームワーク内の既存システムには、すべてのコンテンツとお客様情報も含まれています。フローの仕組みはこうです：お客様がテキストで質問をし、私たちは保有しているデータを使用してIntent分類を行い、FAQ形式のIntentに該当するかどうかを判断します。FAQ形式のIntentである場合、Q&Aワークフローが実行されます。
Q&Aワークフローが呼び出されると、Amazon OpenSearch Serviceでオープン検索を行います。ここでは、Amazon Bedrock Embedding APIを使用して検索エンベディングを行い、お客様の設定、お客様情報、お客様の質問をエンベッドします。その後、ハイブリッド検索を使用して参照資料を取得します。お客様の質問はAmazon Bedrock Converse APIに渡され、Claudeモデルを使用してレスポンスが生成されます。そのレスポンスをガードレールシステムに渡し、ガードレールを満たしていれば問題ありません。満たしていない場合は、より堅牢なモデルを使用して2回目の処理を行います。
なぜAmazon Bedrockを選んだのでしょうか？Bedrockは、先ほど同僚が説明した2つの異なる責任を明確に分離しています。1つは、キュレーションされたデータを提供し、Foundation Modelをトレーニングし、顧客が広く使用できる製品としてリリースするModel Providerです。もう1つは、それらのモデルへの信頼性の高い、コスト効率の良いアクセスを大規模に提供するModel Hostです。この分離は、モデルのトレーニングプロセスと推論データに使用されるモデルの間に意図的なエアギャップを維持することでデータプライバシーを促進するCo-designの原則に従っています。また、モデルの明確な市場リーダーが存在しない場合でも、ベンダーロックインを防ぐのに役立ちます。既存のアクセス制御に対するネイティブなAWSサポートは、常に非常に有用でした。
最後に、AWSチームとのパートナーシップにおいて、Guardrailシステムが存在しなかったため、GenAI技術全体が時間とともに成熟していく中で進歩を続けられるよう、Remitly内部で独自のGuardrailシステムを構築しました。 ここで、全体的なデモを簡単にご紹介します。これは、お客様が利用する従来のチャットインターフェースです。チャットをクリックすると、チャットボットが顧客をどのように支援できるかを示します。これは生成された応答です。顧客は、特定の支払い方法について質問を入力しようとしています - ベルギーで非常に有名で広く使用されているBancontactでの支払い方法について尋ねています。
この時点で起こっているのは、すべての情報が取り込まれ、チャットボットが応答しようとしているところです。右側の図では、Intent Classifierが働いており、これがQ&Aのインテントであると判断しています。ここで、モデルからの応答が生成されます。生成された応答では、その支払い方法の使用方法について説明し、さらに顧客が詳細を確認できる参考文書も引用しています。この過程で、情報の検索と生成のプロセスを経て、Guardシステムを通過し、顧客への応答が生成されました。
結果についてお話ししましょう。私たちは非常に良い結果を得ています。このシステム全体の構築には約2ヶ月かかりました - とても効率的な取り組みでした。現在、採用率は25%に達しており、4件のチャットのうち1件がチャットボットによって処理されています。顧客満足度も高く、多くの問題が解決されています。しかし、最も素晴らしいのは、顧客はいつでも人間のオペレーターに切り替えることができるにもかかわらず、チャットボットとやり取りしている際に実際に切り替えるのはわずか3%だということです。これは、この技術にとって大きな成功と言えます。重要な教訓として、まず第一に、セキュリティは実装の出発点であり、後付けではなく当然の要件として考える必要があります。
セキュアなGenerative AIアプリケーション構築のためのベストプラクティス
Proof of Conceptの観点から最先端のモデルから始めたくなる誘惑はありますが、コストとレイテンシーの問題がすぐに制限要因となる可能性があります。 参考データと顧客からの問い合わせに真摯に向き合うことが重要です。言語固有のニュアンスについては非常に慎重になる必要があります。なぜなら、モデルによってパフォーマンスが異なる可能性があるからです。
私たちは、をどのように活用し、Generative AIをスケールさせていくかについて、より広いビジョンを持っています。最優先事項は、チャット体験の中で、より多くのお客様の問題に直接対応する新しいインテントベースの解決ワークフローで、実装のカバレッジを拡大することです。また、お客様との会話の中で、インテント分類が軌道を外れた時により適切に検知し、軌道修正できるよう、言語理解能力を活用したいと考えています。さらに、Generative AIをサポート業務以外にも拡大しています。その一例として、マーケティングコンテンツの生成について議論を重ねており、これはサポート以外での実装を示すものです。その後、データソースを拡大し、自社でホスティングするのではなく、Amazon Bedrockのガードレールを活用して構築していく予定です。
私たちのCISO（最高情報セキュリティ責任者）であるDarren Challeyの言葉を共有させていただきたいと思います。彼は、AWSとのパートナーシップ、そして顧客データを安全に保つために必要な制御を構築できる製品に対して感謝の意を表明しています。私たちにとって、お客様のために革新を続けることは非常に重要です。お客様が迅速に送金できるようにするために、私たちができることは何でも追求していきます。
それでは、Rajに引き継ぎたいと思います。ご参加いただき、ありがとうございます。これから、Generative AIの全サイクルについて説明していきます。まず、最初のステップに戻りましょう。セキュアなFoundation Modelの構築について考える時、Large Language ModelやGenerative AIモデルの構築には2つのステップがあります。適切なデータをキュレーションし、Pre-trainingのプロセスを経る必要があります。次に、おそらく最も重要なステップとして、Post-training alignmentがあります。これは、モデルプロバイダーが安全性のためにモデルをチューニングし、より安全で、セキュアで、整合性のある応答を提供するようLLMの動作を調整することを意味します。
ここで、Amazon Bedrockは、プロバイダー、その利用規約、パフォーマンスに基づいて選択肢を提供したいと考えています。AWSサービスとして、IAMで認証を行い、慣れ親しんだネットワーク制御やデータ制御を利用できます。プロバイダーからのモデルアーティファクトを私たちのサービスアカウントでホストしているため、アクセスがよりシンプルになり、データの漏洩を確実に防ぐことができます。
最後のステップは、おそらく多くのお客様がセキュリティに関して質問されることの中で最も多い、モデルの実際の使用方法についてです。アプリケーションに実装する際、ハルシネーションを防ぎ、送信するデータが安全であることをどのように確保するのでしょうか。Generative AIを使用したシステムの構築を考え始めると、いくつかの重要な考慮事項が出てきます。最もよく耳にする懸念事項は、ハルシネーションの防止方法、各ステップでの可視性の確保、従来のAuthNやAuthZ制御の統合方法、アプリケーションを特定のデータに基づいて関連性を保つ方法、そしてPrompt injectionやPrompt leakなどの有害な攻撃からの保護方法です。
これらは、Generative AIアプリケーションを構築する際に、私たちの開発者コミュニティの大半が考慮しなければならない制御です。ほとんどの開発者は、Foundation Modelをゼロから構築したりホストしたりするのではなく、アプリケーションにセキュリティを組み込むことに重点を置いているユーザーです。そこで、Generative AIアプリケーションを構築する際に特に重要な2種類の制御について説明したいと思います。1つ目は、決定論的制御（Deterministic Controls）と呼ばれるものです。決定論的制御とは、同じ方法で実行すれば再現可能で、説明可能な制御のことを指します。これは、Foundation Modelに入力されるデータ、あるいはユーザーの認証や承認を行う前の段階で、適切なデータや機能へのアクセス権を持つ信頼できるユーザーであることを確認するように設計されています。つまり、データがモデルに到達して推論を行う前に、セキュリティを確保するということです。これには、IAM、KMS、AuthN、AuthZなどの制御が含まれ、LLMに到達する前のアクセス制御を行います。
これには、Amazonのガードレールにおけるレディネスチェックなども含まれます。2つ目は、確率論的制御（Probabilistic Controls）と呼ばれるもので、初心者の方には少し分かりにくいかもしれません。確率論的制御は、有害なシステム入出力を防ぐような言語タスクにより適しており、システムのユースケースが適切であることを確認し、より広範な問題の解決を支援するように設計されています。英語のあらゆる要素に対してif文や論理文を書くことはできませんが、テーマや機械学習的なチェックを設定することで、保護の範囲を広く設定することができます。ただし、これらは確率論的なものであり、一定のリスクを受け入れる必要があることを理解しておくことが重要です。
このセッションを通じて、Generative AIのアーキテクチャにおける大きなパターンと、これら2つの制御を組み合わせて完全なソリューションを実現する方法について説明します。私たちが確認した、お客様が最も多く実装している3つの一般的なパターンは、これらの制御の組み合わせ方に帰着します。1つ目はPrompt Engineeringで、モデルに送信する内容と、タスクを解決するために適切な情報を確実に持たせる方法に関するものです。プロンプトは、デフォルトでLLMがどのように応答するかを決定します。LLMは、データと機能の分離がほとんどないという新しい概念を導入しました。事前学習済みの情報コーパスが組み込まれているため、応答生成の方向性を適切に導く必要があります。
2つ目はRetrieval Augmented Generationで、詳細なデータソースを取り込んでベクトル埋め込みを作成します。ユーザーの質問に基づいて、それをコンテキストに注入することで、適切な回答を生成できます。LLMは確率論的なモデルであるため、LLMに到達する前に、できるだけ決定論的にし、入力データが適切で検証済みであることを確認する必要があります。最後に、多くのお客様の利用で見られる新しいパターンは、Tool Useと呼ばれる概念で、静的なシステムやリポジトリだけでなく、リアルタイムの情報とやり取りするエージェント的な振る舞いと組み合わせています。
これにより、新しい攻撃ベクトルが導入されます。APIを使用する認証は適切か、アクションは有効か、不適切な動作を防ぐにはどうすればよいかといった問題です。自律的に行動するエージェントを考える場合、セキュリティの確保が必要です。私たちは、確率論的制御と決定論的制御を組み合わせた多層防御として、4段階のプロセスでこれを実現します。実際のアプリケーションシナリオで考えてみましょう。最初に取り組むのは、適切なプロンプトの構築です。Amazon Bedrockのモデルに対して、正しいIAMロールとアクセス権限を持ってモデルを呼び出せる状態から始めましょう。
プロンプトを作成する際には、2つの要素について考える必要があります。1つ目はSystem Promptで、おそらく最も調整が必要な部分です。これはLLMに送信する永続的な指示であり、モデルの動作と機能を定義します。LLMには真の意味でのデータと機能の分離がないため、与えられたものの範囲内で制限を設ける必要があります。2つ目のUser Promptは、LLMに回答してもらいたい質問、つまりエンドユーザーが尋ねる可能性のある内容です。User PromptがSystem Promptに影響を与えるようにして、エッジケースに対応し、問題の範囲を満たすように設計することが重要です。
プロンプトを作成する際には、多くのベストプラクティスがありますが、セキュリティの観点から見るとどのような意味を持つのでしょうか。私たちは簡単なテストを実施し、敵対的な攻撃を想定して、モデルに分類タスクを実行させる約50のユースケースを生成しました。その結果、最適化されていない一般的な質問を与えた場合、50回の攻撃のうち24回を通過してしまいました。これは非常に高性能なモデルで、本来与えるべきでない結果を出してしまう、かなり低い防御率でした。しかし、これらの改善を組み込むと、その数値は100%になりました。Prompt攻撃やPrompt注入について考える際、これらの対策は非常に重要になります。なぜなら、プロバイダーはモデルの事前学習とアライメントを行っていますが、私たちの使用方法もそれらのモデルに指示を与える方法と整合している必要があるからです。
これが最適化されていないプロンプトの例です。「あなたの仕事はこの3つの項目に従って相互作用を分類することです。それ以外のことはせず、これら3点以外では応答しないでください」という非常にシンプルなプロンプトを与えています。
私たちは、Claude 3.5モデルに特化したベストプラクティスを適用してプロンプトを生成しました。これを読むと、モデルに問題空間をどのように考えてほしいかを段階的に示したガイドのようになっています。ご覧の通り、AnthropicのXMLタグを使用しています。モデルに問題へのアプローチ方法を段階的に記述しているのです。Chain of Thoughtという概念を導入し、モデルに実際の問題空間、入力、そして望む応答方法について考えさせています。セキュリティの観点から見ると、これは精度を大きく向上させます。なぜなら、モデルが応答や生成を行う前に、自身の思考プロセスを通じてそれが実際に安全かどうかを確認するからです。この演習で気付いたのは、モデルがこのプロセスを経ることで、攻撃を試みていることを判断し、応答しないことを選択したということです。これは広範な取り組みですが、最近私たちはAmazon Bedrock Prompt Managementというサービスをリリースし、これらのモデル固有の活動の調整を支援しています。
プロンプトを作成し、良いプロンプトが準備できましたが、これは確率的な制御です。先ほど述べたように、これらはモデルプロバイダー固有の対応であり、すべてのモデルプロバイダーに対してこれを行うのは非常に困難です。では、一貫した制御が必要な場合はどうすればよいでしょうか。ここで昨年私たちがリリースしたAmazon Bedrock Guardrailsの出番です。Guardrailsはモデルに依存しないセーフガードです。ここでのアイデアは、入力とモデルが生成した出力の両方を6つの異なるフィルターでチェックすることです。これらのフィルターには確率的なもの、決定論的なもの、そしてその両方を組み合わせたものがあります。社内テストでは、Guardrailsをワークフローに追加することで、Foundation Modelだけを使用する場合と比べて、有害なコンテンツのブロック率が約85%向上することがわかりました。また、RAGにおける幻覚的な出力も約75%削減されました。Foundation Modelを使用して構築を始める際には、これらを組み合わせることで非常に効果的に機能し、まさに多層防御として考えることができます。
Guardrailsの各コンポーネントについて手短にご説明します。最初のコンポーネントはContent Filtersです。私たちAWSではResponsible AIの柱を定義し、入力や生成された出力に、ヘイトやプロンプト攻撃、プロンプトの漏洩といった有害なものが含まれていないかを判断するための機械学習モデルを作成しました。2番目は、機密情報に対する決定論的フィルターと確率論的フィルターの組み合わせです。正規表現チェックやパターン定義などを使用する場合、それは決定論的で毎回確実に機能します。一方、確率論的な制御は、社会保障番号や名前、住所などのPIIを検出するために私たちが構築した機械学習モデルです。これらすべてに正規表現パターンを定義することはできないため、これらのモデルがその役割を担っています。
次はDenied Topics（禁止トピック）です。これはモデルに話してほしくないトピックを制御するものです。例えば、受託者としてのアドバイスを提供すべきではないアプリケーションを構築している場合、受託者としてのアドバイスに関する意図を検出してブロックします。これは入力と応答の両方に適用されます。次のWord Filtersは、競合他社の名前など、単純に言及してほしくない単語やフレーズのセットです。次の2つは比較的新しい機能です。Contextual Groundingは、Foundation Modelによって生成された応答がソースに関連しているかどうかを確認する複合フィルターです。これはRAGのユースケースで特に人気があり、Embeddingsから取得したソースドキュメントとの関連性や、それらのソースドキュメントに基づいて回答がどれだけ根拠づけられているかをチェックします。そして、昨日発表したAutomated Reasoningについては、多くの方がすでにご覧になったかもしれません。これは大規模言語モデルの世界に決定論的なアクションをもたらすため、個人的に最も期待している機能です。
それでは、もう少し詳しく説明していきましょう。 コンピュータサイエンスやエンジニアリングのバックグラウンドをお持ちの方々にとって、Automated Reasoningは決定論的または離散的な数学的チェックとして考えるとわかりやすいでしょう。ソースドキュメントがある場合、特定の意図（例えば、このドキュメントを使用して休暇手続きを生成するなど）とともにAutomated Reasoningサービスに送信します。
Automated Reasoningは自動推論ポリシーを作成します。変数のセットとそれらの変数に基づくルールのセットを定義します。これらは論理文として考えてください。「以上」「以下」といった、純粋に論理的な表現です。これがポリシーとして保存され、このコンポーネントは確率論的です。重要なのは、要件に完全に合致しない場合は編集できるということです。
Q&Aが実際のモデルに送信されて検証される際には、毎回その変換が行われます。ユーザーの質問と回答を論理文の表現に変換し、作成したルールと変数に対して新しいQ&Aチェックの表現で決定論的なチェックを行います。パスした場合は、パスしたことを通知し、そのチェックをパスするために使用された変数と、有効とされるために行われたすべての仮定を示します。ルールを満たさないシナリオでは、具体的なルールと、なぜ機能しなかったのかの値を示し、応答を有効にするための修正案を提供します。
これは、Generative AIにおける説明可能な意思決定が可能になったことで、セキュリティとハルシネーション制御について考える際の新しいパラダイムを導入するものです。より手続き的なドキュメントについて考え始めると、この説明可能なコンポーネントが本当に役立ちます。注目すべき点として、これは確率的制御と決定論的制御の両方を組み合わせたものです - チェックは決定論的であり、実際の生成部分は確率的です。
適切なプロンプトと適切なガードレールを追加する方法について説明しましたが、ここからは、これらのよく使われるパターンを通じて実際にデータを活用する方法を見ていきましょう。最初に取り上げたいのは、おそらく現在誰もが使用しているRAGについてです。そして、Amazon Bedrock Knowledge Basesを使ってどのように実現するのかについてお話ししたいと思います。最初のステップは、実際にデータを取り込み、ベクトル表現を作成することです。
RAGとAgentsを活用したセキュアなGenerative AIアプリケーションの構築
まずは、Amazon Bedrockのコントロールプレーンに対する実際のリクエストから始めましょう。APIを呼び出すための適切なロールと権限があることを確認し、正しいリージョンで適切なサービスロールを持っていることを確認する必要があります。ここから、Amazon Bedrock Knowledge Bases APIにアクセスします。これはランタイムであり、直接LLMを使用しているわけではないことを理解することが重要です。サービス自体のランタイムにアクセスしているのです。
サービスがアクションを呼び出すための適切なロールを持っていることを確認します。これは、保存したいドキュメントリポジトリにアクセスします。Amazon S3を使用している場合は、適切なS3権限が必要です。外部ソースにアクセスする場合も、Knowledge Basesに情報を読み込むための適切な認証と権限があることを確認してください。それが完了したら、その情報をAmazon Bedrockのモデルに送信します。Knowledge Basesが、Amazon Bedrockの埋め込みモデルを実際に呼び出すためのルールと権限を持っていることが重要です。その後、ドキュメントのベクトル表現を取得し、サポートされているベクターデータベースに書き込みます。Amazon Bedrock上のベクターデータベースの場合は、IAMで完全に定義できます。外部の場合は、適切な認証メカニズムが必要です。
このようなシステムの実際の使用に関して、RAGの呼び出しのような処理が送信される前に、認証と承認をどこで行うかを考える必要があります。アプリケーションを使用しているユーザーがいるとします。アプリケーションはKnowledge Bases APIを呼び出すための適切なルールと権限を持っていますが、ユーザーが閲覧を許可されたデータのみを見ることができ、他人の情報を見ることができないようにするにはどうすればよいでしょうか。
ステップ1として、データがKnowledge Base APIに送信される前に、まずユーザーの認証と認可を行います。これは従来型のAuthNコントロールで実施できます。ユーザーの身元が確認できたら、confused deputy問題を回避するため、情報が届く前にフィルタリングを行うことができます。ここからRAGでは、非常にユニークな様々な処理が可能になります。
1つ目は、メタデータと呼ばれる概念です。 Knowledge Base内では、RAG用に取り込むドキュメントに特定のメタデータを関連付けることができます。これは閲覧を許可するグループや年度など、実質的にどんな情報でも構いません。これが重要な理由は、RAGの呼び出しが行われる前に事前フィルタリングができるからです。この点については後ほど詳しく説明します。ここからデータはKnowledge Base APIに送信されます。そして、すべてのドキュメントの作成に使用した埋め込みモデルを呼び出して、クエリを埋め込みます。
次に、メタデータフィルタリングと呼ばれる処理を行います。送信されたクエリに基づいてフィルタリングを行うのです。これにより、認証・認可済みのユーザーに対して、ベクトルデータベースからのドキュメントが、エンドユーザーやLLMでの生成に到達する前にフィルタリングされることを確実にします。これは通常の認証・認可メカニズムからさらに範囲を絞り込むものですが、ユーザーが閲覧を許可されたデータのみにアクセスできるようにする方法です。マルチテナント型のソリューションでは、これは非常に強力な機能となります。
ベクトルデータベースからデータを取得したら、それをLarge Language Modelに送信します。この時もKnowledge Baseには適切な権限が必要です。処理が完了したら、レスポンスをエンドユーザーに返します。このフローを見ていくと、各ステップで認証と権限チェックを行っていることがわかります。Prompt Engineeringのようなコントロールを導入して、生成に使用するプロンプトを具体的にしたり、コンテキストに基づいた制約を含めたりすることもできます。ただし、決定論的なコントロールは省略せず、適切なIAMポリシーやルールを確実に適用します。
これがRAGシナリオにおける2つの要素の連携方法です。次に、おそらく皆さんがre:Inventで最も期待している話題について説明したいと思います - それは、エージェントの振る舞いについての考え方です。Agentsは独自のアクションを実行でき、より動的なワークフローに組み込むことができるという、非常にユニークな視点をもたらします。では、このプロセスのセキュリティをどのように確保すればよいのでしょうか？ここでも、これらのコントロールを組み合わせて使用します。
アプリケーションのシナリオについて考えてみましょう。適切なロールを設定し、適切なポリシーを取得し、ユーザーを認可し、ユーザーに関する情報を取得します。ここで注目したいのは、Amazon Bedrock Agentsにはセッション属性というコンポーネントがあることです。このセッション属性はLLMの外部に存在しますが、ランタイム自体がAPIにそれを渡すのを助けます。これはセッショントークンのようなものかもしれませんし、認証メカニズムのようなものかもしれません。要するに、決定論的な制御として、ユーザーの認証を支援するものなのです。
ここから、適切なロールを確認し、Agents APIを呼び出します。 これは、ユーザーの意図や目的に応じて、Large Language Modelとの間で行き来が行われる部分です。LLMは思考の連鎖のプロセスを経ていきます。これは完全にAgentに与えたプロンプトの指示によって導かれます。そして次のアクションステップを生成します。それを送り返し、静的な情報を取得するためにKnowledge Baseへの呼び出しが必要か、あるいは Action Groupやツールセットへの呼び出しが必要かを判断します。ここで、先ほどのセッション特性と認証制御が実際のAPI自体に渡されることになります。
このフローにおけるセキュリティについて考えると、実際の呼び出しを行うのはLLMではありません。LLMは単に「このユーザーはこれをしようとしている - このツールを使う必要がある、このKnowledge Baseを呼び出す必要がある」と判断するだけです。私たちが使用しているのは、Agentsのランタイムのような非常に決定論的な制御です。Amazon Bedrock Agentsには、アクションが実行される前にユーザーにアクションの確認を求めたい場合に使える素晴らしい機能もあります。APIの仕様を渡す際にこれを追加すると、ユーザーにアクションの確認を求めることができます。つまり、自律的なアクションを取らせることなく、人間を介在させるフローを実現できるのです。
最終的に、ユーザーに応答を返して処理が完了します。これら2つの大きなパターンについて考え始めると、より確率論的なアプローチと組み合わされた決定論的な制御の下で、この2つがどのように連携するかが分かります。エンドツーエンドのアーキテクチャとして考えると、 アプリケーションを望ましい成果に合わせるにはどうすればよいでしょうか？これまで話してきたことを、本当にすべてまとめてみましょう。
IAMを有効にすることができます。 AWS CloudTrailを有効にして、それらのAPIアクションを確実にログに記録することができます。最後に、すべてのやり取り、すべてのプロンプト、すべてのレスポンスを記録したい場合は、Amazon CloudWatchにログを記録できます。このように認証と認可を行い、セッション属性とともにメタデータを含むクエリを送信します。そこから最初のAmazon Bedrock Guardrailsの呼び出しを行います。これは最初からAgentsやKnowledge Basesと統合されています。
まず、ユーザーのクエリが意図した内容と合致しているかを認証します。合致していれば、そのクエリをAgentに送信します。その際、Agentの指示内容がPrompt engineeringのベストプラクティスに沿っていることを確認します。ここで、Agentに適切なロールと必要なアクションを実行するための適切な権限を付与します。そして、Knowledge baseへの呼び出しが必要かどうかを判断します。これらの情報はすべて保持されます。メタデータの事前フィルタリングや、対応するセッション属性も得られます。しかし、これは基本的にゼロトラストのプロセスです。AgentはKnowledge baseを実際に呼び出す権限を持っているのか？適切な権限を持っているのか？といった確認が行われます。
次に、より動的なアクションを呼び出す必要がある場合、同様のチェックが行われます。適切なロールと権限を持っているかどうかの確認です。この情報を処理するために必要なプロセスは何か？このチェックは各ステップで実施されます。そして、望ましい応答が得られた場合、そのプロセスをダブルチェックするためにGuardrailによって再度検証されます。最後に、これらが完了してはじめて、ユーザーに実際の応答が返されます。
このようなパターンやアーキテクチャの構築を始める際に重要なのは、これらの2つのコントロールを組み合わせることです。Generative AIには確率的な要素がありますが、アプリケーションの構築とデータアクセスの制御を考える際には、可能な限り決定論的であるべきです。確率的なコントロールが導入され、より広範な問題として捉える必要があります。では、これらすべてをまとめてみましょう。元のリストに戻ると、機密データやPIIの保護を実装する場合、決定論的なコントロールを使用してLLMに到達する前にデータを検証・フィルタリングし、さらにGuardrailsの機密情報フィルターなどと組み合わせてPIIをブロックする必要があります。
次に、これらすべてのインタラクションを確実にログに記録するにはどうすればよいでしょうか？これは最初から実施すべきことで、Model invocation loggingを確実にセットアップしておく必要があります。さらに、一貫したネットワークとセキュリティコントロールをどのように維持するか？これらは決定論的なチェックとして考えるべきです。IAM、KMS、ネットワークコントロールなどがこれにあたります。そして、Agent型アプリケーションにおけるAuthNとAuthZコントロールを考える際には、Bedrockのセッション属性が非常に強力なツールとなります。
関連性を確保し、有害な攻撃からどのように身を守るか？ここで確率的なコントロールが重要になってきます。アプリケーションに対して適切なPrompt engineeringによる指示を行い、System promptが適切であることを確認し、さらにSafeguardsやGuardrailsなどを用いた多層防御を検討する必要があります。最後に、リクエストの認証と認可を確実に行うにはどうすればよいでしょうか？これはLLMに任せるのではなく、既に構築済みの従来の仕組みを使用して実施すべきです。
難しく感じるかもしれませんが、考慮すべき2種類のControlsがあり、それぞれが独自の興味深い役割を果たしているということを覚えておいてください。次のステップとして、始めるのに役立つ素晴らしいリソースをご用意しています。ぜひチェックしていただくことを強くお勧めします。これらのリソースは、この内容をより実践的に理解する手助けとなるはずです。以上で終わりですが、本日のセッションにご参加いただき、ありがとうございました。セッションのアンケートにぜひご協力いただければ幸いです。皆様、誠にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion