※本記事は、AWS re:Invent 2024のセッション「Understanding security & privacy on Amazon Bedrock, featuring Remitly (AIM360)」の内容を基に作成されています。セッションの詳細情報は https://www.youtube.com/watch?v=3Sxw6IIYhdE でご覧いただけます。本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご覧いただくことをお勧めいたします。

登壇者紹介：

• Qingwei：AWSのマシンラーニングスペシャリスト。Amazon Bedrockのセキュリティ機能と実装パターンについて解説。
• Ankur：Remitlyのプロダクトマネジメント VP。クロスボーダー送金サービスにおける生成AI活用事例を紹介。
• Raj：AWS。生成AIアプリケーションの構築パターンとベストプラクティスについて解説。

本セッションは、AWS主催のAWS re:Invent 2024の一環として開催されました。AWSは世界最大規模のクラウドプラットフォームを提供しており、200以上のサービスをグローバルに展開しています。スタートアップから大企業、政府機関まで、多くの組織がAWSを活用してコスト削減、アジリティの向上、イノベーションの加速を実現しています。

1. Amazon Bedrockのセキュリティと概要

1.1 生成AIセキュリティの3段階

Qingwei: 業界調査によると、セキュリティは依然として様々な規模の組織の主要な懸念事項となっています。幻覚、データプライバシー、データ保護といった問題は、年々の調査で主要な懸念として挙げられ続けています。そのため、本日の講演では生成AIのセキュリティに焦点を当てていきます。

生成AIのセキュリティは3つの段階に分けて考えることができます。第一段階はモデル自体のセキュリティです。これはモデルプロバイダーとして、データの管理、クリーニング、フィルタリングを行い、トレーニングされたモデルがセキュアであることを確保する必要があります。

第二段階はモデルアクセスのセキュリティです。これは誰がデータにアクセスする認証を受け、承認されているかという点に関わります。

そして最後の段階は、生成AIアプリケーション全体のセキュリティです。データが生成AIモデルに到達する前のデータのセキュリティを確保し、モデルが出力を生成した後、その出力が組織の責任あるAIポリシーに準拠していることを確認する必要があります。

これら3つの要素を組み合わせることで、生成AIのセキュリティの全体像が形成されます。このフレームワークに基づいて、Amazon Bedrockのセキュリティについて説明していきます。Bedrockは、顧客が生成AIアプリケーションを構築・スケーリングすることを容易にする完全マネージド型の生成AIサービスです。

この3段階のアプローチは、私たちがBedrockのセキュリティを設計・実装する際の基本的な考え方となっており、各段階でのセキュリティ確保が総合的なセキュリティを実現する上で不可欠だと考えています。

1.2 Amazon Bedrockの基本機能と提供モデル

Qingwei: Amazon Bedrockは、顧客が生成AIアプリケーションを構築しスケーリングすることを容易にする、完全マネージド型の生成AIサービスとして設計されています。顧客はサーバーレスで生成AI基盤モデルにアクセスできるため、独自のモデルをトレーニングしたり、インフラストラクチャの展開を心配したりする必要がありません。

私たちの重要なコミットメントの一つは、顧客に最高かつ最新の基盤モデルを提供することです。画面に表示されているリストは、様々なモデルプロバイダーから提供されている基盤モデルを示しています。これには、Anthropic、Meta、Amazonなどの主要プロバイダーからの強力なモデルが含まれています。

私たちは顧客に選択肢を提供することを重視しています。ただし、これらのモデルへのアクセスは顧客のアカウント内で有効化する必要があります。つまり、顧客が自身のアカウント内のどのユーザーがどのモデルを使用できるようにするかを決定することができます。

このように、Bedrockはサーバーレスという利点と、複数のモデルプロバイダーの選択肢を組み合わせることで、顧客が柔軟に生成AIアプリケーションを構築できる基盤を提供しています。多くの皆様が、すでにBedrock内の基盤モデルを試験的に使用したり、実験を行ったりしていることと思います。

1.3 データプライバシーと保護機能

Qingwei: Bedrockのデータプライバシーと保護に関して、最も基本的かつ重要な点から説明させていただきます。この点は本日のセッションで何度か繰り返すかもしれませんが、それだけ重要な原則です：私たちは推論データおよびトレーニングデータを一切保存しません。データを保存しないことで、データが漏洩する可能性を根本的に排除しています。これにより、データがモデルプロバイダーと共有されたり、Amazonが何らかの目的で使用したりする心配はありません。

私たちが保存する唯一のデータは、課金目的の使用データなどの運用メトリクスと、Bedrockコンソールにログインした際に表示されるカスタマイズジョブのリストなどのメタデータに限定されています。

また、すべてのプロンプトやデータは顧客ベースで分離されており、APIリクエストを送信したのと同じリージョン内に留まります。例えば、フランクフルトリージョンにBedrockのモデル呼び出しリクエストを送信した場合、そのリクエストは同じリージョン内に留まります。

さらに、モデルのファインチューニングを行う場合、Bedrock内でお客様にサービスを提供するためにモデルのコピーを保持する必要がありますが、お客様独自のKMSキーでモデルを暗号化することができます。これにより、モデルへのアクセスは顧客のみに制限されます。

また、Amazon Bedrockは画面下部に記載されている多数のコンプライアンスプログラムを達成していることも付け加えておきたいと思います。これらのセキュリティ機能とコンプライアンス認証により、Bedrockは企業の厳格なデータプライバシーとセキュリティ要件を満たすことができます。

1.4 接続性とネットワークアーキテクチャ

Qingwei: まず、接続のセットアップについて説明させていただきます。画面の右側にAmazon Bedrockのサービスアカウントがあり、ここにBedrockサービスコンポーネントとAPIエンドポイントが配置されています。同じリージョン内の左側には、クライアントアカウントと、その中のお客様のVPCがあります。

顧客がBedrockサービスにAPIコールを行う場合、2つの接続方法があります。1つはパブリックアドレス空間を通じた方法、もう1つはプライベートアドレス空間を通じた方法です。

画面の黄色い線で示されているのがパブリックアドレス空間経由の接続です。VPC内からBedrockへのリクエストは、まずインターネットゲートウェイを通過し、そこからパブリックアドレス空間を経由してAPIエンドポイントに到達します。パブリックアドレス空間を通ると言っても、トラフィックはAmazonのリージョナルネットワーク内に留まり、パブリックインターネットには露出されません。ただし、企業ネットワークからBedrockサービスにAPIコールを行う場合は、パブリックインターネットを経由してBedrockサービスにルーティングする必要があります。

プライベートVPC内のリソースを持つお客様や、アカウント内でパブリックインターネット空間の使用を禁止するポリシーを持つお客様のために、Amazon Bedrockはプライベート接続オプションも提供しています。この場合、まずVPCエンドポイントを作成する必要があります。これにより、VPCとAmazon Bedrockサービスの間にプライベート接続が確立されます。APIコールやリクエストを行う際、トラフィックはプライベートにAPIエンドポイントに接続され、パブリックアドレス空間は一切使用されません。これによりプライベート接続が保証されます。

このように、お客様のセキュリティ要件に応じて、パブリックまたはプライベートの接続オプションを選択することができます。

1.5 アクセスコントロールとIAM統合

Qingwei: IAM管理者がBedrockリソースへのアクセスを制御する方法について説明させていただきます。画面に表示されている2つのポリシー例をご覧ください。1つは特定のモデルへのアクセス権限を制限するもの、もう1つはモデルへのアクセスを許可するものです。このようなポリシーを使用することで、モデルへのアクセスを細かく制御することができます。

最近、私たちはアプリケーション推論プロファイルという機能をリリースしました。アプリケーション推論プロファイルは、モデル呼び出しリクエストを送信できるリソースとして考えることができます。この機能は非常に便利です。なぜなら、モデルIDそのものにはタグを付けることができませんが、アプリケーション推論プロファイルにはタグを付けることができるためです。

これは、IAMポリシーに条件要素を追加することで、誰がどのモデルにアクセスできるかをより細かく制御できるようになるため、非常に有用です。私の経験では、多くのお客様が同じモデルIDに対して複数のアプリケーション推論プロファイルを作成し、異なるアプリケーションごとに使い分けています。これにより、モデルへのアクセスを非常に細かいレベルで制御することができます。

このように、IAMとアプリケーション推論プロファイルを組み合わせることで、Bedrockのリソースアクセスを柔軟かつ安全に管理することができます。

1.6 監視と監査機能

Qingwei: まず、Amazon CloudWatchを使用してBedrockを監視できることを説明させていただきます。CloudWatchは生データを収集し、処理して、読みやすいリアルタイムメトリクスとして提示します。画面でご覧いただけるように、呼び出し回数、レイテンシー、エラーなどのメトリクスがすべてCloudWatchに表示されます。

さらに、モデル呼び出しログを有効にするオプションも提供しています。これはデフォルトでは無効になっていますが、有効にすると、入力リクエスト、出力、リクエストに関連するメタデータがすべてお客様のアカウントに保存されます。ただし、これらのログはお客様のアカウントに保存され、お客様のみがアクセスできることを強調しておきたいと思います。

Amazon BedrockはCloudTrailとも統合されています。CloudTrailはアクションの記録を提供するため、ユーザーやロールごとに、Amazon Bedrockアカウント内で誰が何をしているのかを確認することができます。

つまり、CloudWatchとCloudTrail、そしてモデル呼び出しログを組み合わせることで、アカウント内での完全な可観測性と監査能力を持つことができます。これらの機能により、Bedrockの使用状況を包括的に監視し、必要に応じて詳細な分析や監査を行うことが可能です。

1.7 責任あるAIとGuardrailsの実装

Qingwei: 私たちは責任あるAIについて多く議論していますが、その具体的な実装としてAmazon Bedrock Guardrailsを提供しています。私の同僚のRajが後ほど詳細を説明しますが、高レベルではGuardrailsを責任あるAIポリシーを保証するための保護機能として考えることができます。

システムの動作を具体的に説明すると、ユーザーがリクエストを送信すると、まずそのリクエストはGuardrailsの保護機能によってチェックされます。違反が検出されなければ、モデルはリクエストを受け取り、推論を実行します。

一方、Guardrailsによって違反が検出された場合、承認されたデフォルトメッセージがユーザーに返送されます。もちろん、ユーザーに返すメッセージをカスタマイズして制御することも可能です。

同様のプロセスは、推論モデルが生成した出力にも適用されます。出力もGuardrails内の保護機能を通過し、AIポリシーへの準拠が確認されます。このように、入力と出力の両方でポリシー準拠を確保する二重のチェック体制を構築しています。

この時点で、皆様はBedrockのセキュリティ機能について良い理解を得られたのではないかと思います。この後は、RemitlyのチームがBedrockを使用して実際にどのようにセキュアなシステムを構築したのかについてお話しいただきます。

2. Remitlyのユースケース

2.1 Remitlyの事業概要と規模

Ankur: Remitlyは、デジタルネイティブなアプリケーションとして、毎年数十億ドルの国際送金を迅速かつ確実に実行するサービスを提供しています。私たちのビジョンは、国境を越えた金融サービスを提供することで、人々の生活を変革することです。私たちの顧客の多くは、様々なユースケースに応じて国際送金を利用しています。

クロスボーダー送金の重要性について、2つの観点から説明させていただきます。まず戦略的な視点では、世界銀行によると、低・中所得国向けの送金額は6,560億ドルを超えており、これは海外直接投資や開発援助金をはるかに上回る規模となっています。

次に顧客の視点から見ると、2022年に実施した2,500人の顧客調査では、52%の顧客が送金額の50%を家計費に充てていると回答しています。このことから、送金の透明性、適時性、信頼性が顧客のニーズにとって非常に重要であることがわかります。

13年をかけて構築された私たちの優れた製品は、顧客からの信頼を獲得しており、それは以下の数字に反映されています：

• 前四半期のアクティブユーザー数は730万人
• 四半期の送金取扱高は145億ドル
• 約170カ国にわたるグローバルな展開

そして私たちは、これはまだ始まりに過ぎないと考えています。このような大規模な事業基盤をベースに、生成AI技術を活用してさらなるサービス向上を目指しています。

2.2 カスタマーサポートの課題

Ankur: 私たちはデジタルファーストの企業として、テクノロジーを活用してお客様の問題を解決することに注力しています。フィンテック分野ではイノベーションが急速に進んでおり、私たちは常に新しいテクノロジーを活用して顧客の課題解決に取り組んでいます。

最も重要な課題の一つは、送金の遅延が顧客の信頼を損なうことです。私たちの取引の95%は顧客サポートへの問い合わせなしで完了しており、多くの場合、お客様の期待以上のスピードで送金が完了しています。しかし、残りの5%の取引では、追加情報が必要であったり、配送状況の確認が必要であったりして、完了することができません。このような場合、サポート体験は顧客の安心感と私たちのサービスへの信頼にとって極めて重要です。遅延が発生すると、時間の経過とともに顧客の信頼は低下していきます。これは私たちにとって非常に直接的な相関関係があります。

また、成長に伴うサポート体制の拡充も大きな課題です。私たちは過去数年間、年間30%のペースで成長を続けています。直近の四半期だけを見ても、アクティブ顧客数は前年同期比35%増、送金額は42%増となっています。これに伴い、サポート量も同様のペースで増加しています。

さらに、18の言語でのサポート提供が必要であり、手動での対応では規模の拡大が困難になってきています。そのため、テクノロジーの活用が私たちのサポート体制において非常に重要な要素となっています。

このような状況を踏まえ、私たちは時間をかけてサポート量を4分の1に削減するという野心的な目標を掲げ、テクノロジーを活用してその達成を目指しています。これは単なる効率化ではなく、顧客体験の向上と信頼関係の維持・強化を目的としています。

2.3 生成AIによる解決策

Ankur: 生成AIにより、私たちは新たな機会を見出すことができました。まず、意図分類において優れたパフォーマンスを実現しました。また、生成された応答を通じて、より優れた顧客体験を創出することができています。

従来のエンコーダーとデコーダーモデルを使用する場合、実装は非常に重い作業となっていましたが、プロンプトエンジニアリングを活用することで、新しいユースケースを迅速に展開できるようになりました。このカスタマイズの容易さは、私たちのサービス改善の速度を大きく向上させています。

また、RAG（Retrieval Augmented Generation）やGuardrailsなどの機能により、幻覚（ハルシネーション）の発生を抑制し、大規模言語モデルを効果的に活用することが可能になりました。これは以前には実現できなかったことです。

さらに、ユースケースが非常に多様であることを考えると、ワークロードの効率的なスケーリングが重要です。生成AIを活用することで、この課題に効果的に対応することができています。私たちの場合、構造化されたトランザクションデータとチャットでの非構造化テキストの両方を扱う必要があり、リアルタイムのオンラインチャットでは100ミリ秒未満で意図を推測する必要があります。また、顧客のクエリは「アカウントで何かを変更したい」から「送金状況を知りたい」まで多岐にわたります。このような多様性に対応するため、また、メール、電話、チャットなど複数のコミュニケーションチャネルをサポートするため、生成AIの柔軟性は非常に重要な利点となっています。

2.4 実装における主要な課題

Ankur: 私たちの実装における課題は、大きく運用面とセキュリティ面に分けることができます。

運用面での主要な課題は、まず私たちが適切な参照文書を発見して顧客応答を可能にする必要があるということです。また、顧客の満足度を維持するために、応答は6秒未満という非常に短い時間で提供する必要があります。さらに、応答の正確性は顧客が技術を信頼し、私たちのサービスを信頼するために非常に重要です。

セキュリティ面での課題は、私たちが規制された金融サービス企業であるため、特に重要です。データプライバシー、アクセス制御、ネットワークセキュリティは極めて重要な要素となっています。

特に注意を要するのは、サポートのトランスクリプトに含まれる個人データの扱いです。これらは非常に慎重に、セキュアな方法で処理する必要があります。

また、サービスをパーソナライズするためにデータは非常に重要ですが、同時にそのデータを安全に保存し、取り扱う必要があります。これらのセキュリティ要件を満たしながら、効率的で正確なサービスを提供することが私たちの主要な課題となっています。

2.5 ソリューション設計と実装アーキテクチャ

Ankur: 私たちのソリューション設計について、広く概要を説明させていただきます。顧客は従来型のボットでテキスト検索クエリを入力し、私たちはそのクエリと顧客のトランザクションデータを組み合わせて、従来型とニューラルネットワークを組み合わせたハイブリッド検索を実行します。

次に、コンテンツ検索のフェーズに移ります。ここでは、検索結果を使用してRemitlyのコンテキスト（セルフヘルプガイド、コンテンツスニペットなど）からデータを取得します。検索プロセスでは、正確な参照文書を探すことに注力します。

その後、レスポンス生成のステージに進みます。ここでは、3つの観点から検証と精度を確保します：

1. サブシステムでの正しい参照の検索
2. コンテンツ検索での精度
3. コンテンツ生成での精度

最後に、レスポンス検証の段階があり、これは3つのステップで構成されています：

1. レスポンスが参照文書を引用しているかどうかの確認
2. 引用された文書が当初提供した参照資料に含まれていたかの確認
3. レスポンス、質問、参照文書の一貫性（コヒーレンシー）の確認

このアーキテクチャにより、正確で信頼性の高い応答を生成することができ、同時にセキュリティと品質を確保することができています。

2.6 Amazon Bedrock採用の理由

Ankur: Amazon Bedrockを選択した理由は、私の同僚が先ほど説明した2つの異なる責任の明確な分離にあります。第一に、モデルプロバイダーはQAデータで学習させた基盤モデルを製品として幅広く顧客に提供します。第二に、モデルホストは信頼性が高く、コスト効率の良いモデルへのアクセスを大規模に提供します。

この分離は、データのプライバシーを促進するコード設計の原則に組み込まれており、モデルのトレーニングプロセスとモデルの推論データの使用の間に意図的なエアギャップを維持することを保証します。

また、現在のようにモデル市場に明確なリーダーが存在しない状況では、ベンダーロックインを防ぐことができる点も重要でした。

さらに、既存のIAMアクセス制御に対する自然なAWSサポートも非常に有用でした。最後に、私たちはAWSチームとのパートナーシップの中で、Guardrailシステムがまだ存在しなかった時期に、Remitly内部でGuardrailシステムを構築しました。これにより、生成AI技術全体が成熟するのを待つことなく、進歩を続けることができました。

このように、BedrockのアーキテクチャとAWSのエコシステムは、私たちのセキュリティ要件と開発のニーズに非常によく適合していました。

2.7 実装結果と成果

Ankur: 私たちは非常に強力な結果を得ることができました。システム全体の構築にかかった期間は約2ヶ月でした。これは非常に短期間での実装が可能だったことを示しています。

現在、システムの採用率は25%に達しています。これは、4件のチャットのうち1件が私たちのチャットボットによって処理されていることを意味します。顧客満足度も高く、多くの問題が解決されています。

しかし、私にとって最も印象的な成果は、顧客が常に人間のオペレーターに切り替えるオプションを持っているにもかかわらず、チャットボットとのやり取りの中で実際に人間のオペレーターに切り替えるのはわずか3%に留まっているという点です。これは、この技術自体の大きな成功を示しています。

この結果は、私たちの生成AI実装が顧客のニーズを効果的に満たし、信頼できるサポートを提供できていることを示しています。2ヶ月という短期間で25%の採用率を達成し、97%の顧客がボットとの対話を継続できているという事実は、この技術の有効性と実用性を明確に示していると考えています。

3. セキュアな生成AIアプリケーションの構築パターン

3.1 決定論的制御と確率論的制御の概念

Raj: 生成AIアプリケーションを構築する際、2つのタイプの制御を導入することが非常に重要です。

まず1つ目は決定論的制御です。決定論的制御は再現可能なものとして考えてください。同じ方法で実行すると、説明可能で再現可能な結果が得られます。この制御は、基盤モデルにデータが到達する前、あるいはユーザーがアプリケーションを使用する認証・承認の前の段階で、データが信頼できること、適切なデータにアクセスできることを確認するために設計されています。これはIAM、KMS、認証・承認制御など、LLMにデータが到達する前のアクセス制御に基づいて構築されます。また、Amazon Guardrailsの正規表現チェックなども含まれます。

次に確率論的制御について説明します。これは言語タスクにより特化した制御で、より複雑です。生成AIを初めて使用する方にとっては少し分かりにくい概念かもしれません。この制御は有害なシステム入力や出力の防止、ケースに関連性を持たせることを目的としています。英語のあらゆる表現に対して、if文や論理文を書くことは現実的ではありませんが、機械学習型のチェックを使用することで、保護したい対象を幅広くカバーすることができます。

ただし、確率論的制御は確率的な性質を持つため、一定レベルのリスクを受け入れる必要があることを理解しておくことが重要です。以降のセッションでは、これら2つの制御をどのように組み合わせて包括的なセキュリティを実現するかについて説明していきます。

これらの制御を適切に組み合わせることで、生成AIアプリケーションの防御を層状に構築することができます。単一の制御に依存するのではなく、複数の制御を組み合わせることで、より強固なセキュリティを実現できます。

3.2 プロンプトエンジニアリングのベストプラクティス

Raj: プロンプトの構築について、まずその2つの主要な構成要素について説明させていただきます。1つ目はシステムプロンプトで、これは最も調整が必要な部分です。これはLLMに送信する永続的な指示であり、モデルの動作と機能の範囲を定義するものです。LLMには真の意味でのデータと機能の分離がないことを考えると、この部分は特に重要です。

2つ目はユーザープロンプトで、これはLLMに回答してほしい質問です。ユーザープロンプトはシステムプロンプトに影響を与えるべきで、エッジケースに対応できるよう設計する必要があります。つまり、問題の範囲全体をカバーできるようにする必要があります。

私たちは実際にNIST対応の敵対的攻撃テストを実施し、約50のユースケースを生成して分類タスクを実行させました。最適化されていない一般的な質問を使用した場合、50件中24件の攻撃をパスしただけでした。これは高性能なモデルでさえ、与えるべきではない回答を返してしまう可能性が高かったことを示しています。

しかし、これらの変更を組み込んだ後、パス率は100%に達しました。プロンプト攻撃やプロンプトインジェクションを考える際、これらの最適化は非常に重要です。確かに、プロバイダーは事前にモデルをトレーニングし、整合性を取っていますが、私たちの使用方法もモデルへの指示と整合させる必要があります。

具体例を示しますと、最適化されていないプロンプトは「あなたの仕事は相互作用を次の3つのものとして分類することです。他のことは何もせず、これら3点以外で応答しないでください」という非常にシンプルなものでした。

対照的に、Claude 3.5モデルのベストプラクティスを適用した後のプロンプトは、かなり大きくなりましたが、問題空間へのアプローチ方法をステップバイステップで詳細に説明しています。XMLタグを使用して、モデルに問題へのアプローチ方法を順を追って説明し、思考の連鎖を導入して、モデルが応答や生成を行う前に問題空間を考え抜くようにしています。

セキュリティの観点から見ると、これは精度を大幅に向上させます。モデルは応答や生成を行う前に、自身の思考プロセスを経て、それが実際に安全かどうかを判断できるようになりました。この演習では、モデルはこのプロセスを経て、「この人は私を攻撃しようとしている、応答すべきではない」と判断できるようになりました。

3.3 Guardrailsの機能と効果

Raj: 昨年私たちはAmazon Bedrock Guardrailsをリリースしました。Guardrailsはモデルに依存しない保護機能であり、入力と、モデルが生成した出力の両方をブロックする設計になっています。6つの異なるフィルターでチェックを行い、その中には確率的なものと決定論的なもの、そしてその両方を組み合わせたものが含まれています。

社内テストでは、Guardrailsをワークフローに追加することで、LLMだけを使用する場合と比較して有害なコンテンツのブロック率が85%向上しました。また、RAGでの幻覚出力も75%削減することができました。

具体的なフィルターの種類と機能を説明させていただきます：

1. コンテンツフィルター：AWSの責任あるAIの柱に基づいて定義された機械学習モデルを使用し、入力や生成された出力が有害かどうかを判断します。例えば、嫌悪表現やプロンプト攻撃、プロンプトの漏洩などを検出します。
2. 機密情報フィルター：正規表現チェックによる決定論的な制御と、PIIを検出する機械学習モデルによる確率的な制御を組み合わせています。社会保障番号、名前、住所など、正規表現では定義できない情報も検出可能です。
3. 禁止トピックフィルター：モデルが特定のトピックについて話すことを制限します。例えば、投資アドバイスを提供すべきでないアプリケーションの場合、投資アドバイスに関する意図を検出してブロックします。
4. 単語フィルター：特定の単語やフレーズの使用を制限します。例えば、競合他社の名前など、使用を避けたい表現を設定できます。
5. 文脈的根拠付けフィルター：基盤モデルが生成した応答が、ソースとどの程度関連しているかをチェックします。これはRAGユースケースで特に重要で、ソース文書との関連性や回答の根拠を確認します。
6. 自動推論機能：これは私が最も興味深いと感じている機能です。決定論的なチェックを大規模言語モデルの世界に持ち込むもので、昨日発表したばかりの機能です。

このように、Guardrailsは複数の保護層を提供し、確率的制御と決定論的制御を組み合わせることで、より安全で信頼性の高い生成AIアプリケーションの構築を可能にしています。

3.4 RAGパターンの実装とセキュリティ

Raj: Bedrock Knowledge Basesを使用したRAGの実装プロセスとそのセキュリティ確保について説明させていただきます。まず、データの取り込みとベクトル表現の作成から始めます。

Bedrockのコントロールプレーンへのリクエストでは、適切なロールと権限があることを確認する必要があります。適切なリージョンで、適切なサービスロールを持っているかを確認します。次に、Bedrock Knowledge BaseのAPIにアクセスしますが、これはランタイムであることを理解することが重要です。つまり、直接LLMを使用しているわけではありません。

サービスは、指定されたドキュメントリポジトリにアクセスするための適切な権限を持っている必要があります。例えばAmazon S3を使用する場合、適切なS3アクセス権限が必要です。外部ソースを使用する場合も、情報をKnowledge Baseに読み込むための適切な認証が必要です。

その後、情報をAmazon Bedrock上のモデルに送信しますが、Knowledge Baseはこれらの埋め込みモデルを呼び出すための権限を持っている必要があります。ドキュメントのベクトル表現は、サポートされているベクトルデータベースに書き込まれます。これがBedrockのベクトルデータベースである場合、IAMで完全に定義できますが、外部の場合は適切な認証メカニズムが必要です。

RAG呼び出しのセキュリティについて、ユーザーに表示を許可するデータのみにアクセスできるようにする方法を考える必要があります。アプリケーションがKnowledge Base APIを呼び出す適切な権限を持っていても、ユーザーが他人の情報を見ることができないようにする必要があります。

そのため、Knowledge Base APIにデータを送信する前に、まず従来の認証・承認制御でユーザーを認証します。これにより、混乱した代理人問題を回避できます。

Knowledge Base内でRAGに独自の機能を追加することもできます。例えば、メタデータは取り込むドキュメントに特定のメタデータを関連付けることができます。これは閲覧を許可されるグループ、年、その他任意の情報にすることができ、RAG呼び出しの前にプレフィルタリングするために非常に重要です。

3.5 エージェントパターンのセキュリティ実装

Raj: エージェントは自律的にアクションを実行し、より動的なワークフローに組み込むことができますが、このプロセスをセキュアにする方法について説明させていただきます。

まず、アプリケーションに適切なロールとポリシーを付与します。次に、ユーザーを認証し、ユーザーに関する情報を取得します。ここで注目していただきたいのは、Bedrockエージェントのセッション属性という機能です。セッション属性はLLMの外部に存在し、ランタイム自体がAPIにこれを渡すのを支援します。これはセッショントークンや認証メカニズムなど、決定論的な制御を実装するために使用できます。

適切なロールを確認した後、エージェントAPIを呼び出します。ここで、ユーザーの意図と実行したいことに応じて、LLMとの間で思考の連鎖が行われます。これは完全にエージェントに与えた指示やプロンプトによって制御されます。

エージェントは次のアクションを生成し、静的情報を取得するためにKnowledge Baseを呼び出すか、アクショングループやツールセットを呼び出すかを判断します。この時点で、先ほど説明したセッション特性や認証制御が実際のAPIに渡されます。

このフローにおけるセキュリティの考え方として重要な点は、LLM自体が呼び出しを行っているわけではないということです。LLMは単に「このユーザーは特定のことを試みている、このツールを使用する必要がある、このKnowledge Baseを呼び出す必要がある」と判断しているだけです。実際の制御はエージェントのランタイムによる決定論的な制御として実装されています。

また、エージェントには、アクションが実行される前にユーザーに確認を求める機能も備わっています。APIスペックを渡す際にこの機能を追加できるため、完全な自律的なアクションを実行する前に、人間によるチェックを組み込むことができます。

3.6 エンドツーエンドのセキュリティアーキテクチャ

Raj: これまで説明してきた内容をエンドツーエンドのアーキテクチャとして組み合わせ、アプリケーションを望ましい結果に合わせる方法について説明します。

まず、基本的な部分から始めましょう。IAMを有効化し、AWS CloudTrailを使用してAPIアクションのログを確保します。さらに、すべての対話、プロンプト、レスポンスをAmazon CloudWatchに記録することができます。

次に、認証と承認のフローについてです。メタデータとセッション属性を含むクエリを送信します。その後、まずAmazon Bedrock Guardrailsへの最初の呼び出しを行います。これはエージェントやKnowledge Baseに最初から組み込まれており、ユーザーのクエリが望ましい内容に合致しているかを認証します。

クエリが承認された場合、エージェントに送信され、エージェントの指示がベストプラクティスを考慮したプロンプトエンジニアリングで設計されていることを確認します。ここで、エージェントに必要なアクションを実行するための適切なロールと権限が付与されていることを確認します。

エージェントがKnowledge Baseを呼び出す必要があると判断した場合、すべての情報が永続化されます。メタデータによる事前フィルタリング、対応するセッション属性を持ちますが、これはゼロトラストプロセスです。エージェントがKnowledge Baseを呼び出す権限を持っているか、適切な権限を持っているかを確認します。

同様に、より動的なアクションを呼び出す必要がある場合も、適切なロールと権限を持っているか、この情報を取り込むために必要なプロセスは何かを確認します。このチェックはすべてのステップで実行されます。

最後に、望ましい応答が得られた場合、再度Guardrailによって検証され、そのプロセスをダブルチェックします。これらすべてが完了した後に初めて、ユーザーは応答を受け取ることができます。

このように、すべての段階で適切なセキュリティチェックを実施し、決定論的な制御と確率論的な制御を組み合わせることで、包括的なセキュリティアーキテクチャを実現しています。

4. ベストプラクティスと推奨事項

4.1 セキュリティ実装の優先順位

Ankur: これまでの私たちの経験から、重要なキーポイントをご共有させていただきます。最も重要な点は、セキュリティは実装の出発点であって、後付けの考慮事項ではないということです。セキュリティは最初から組み込まれていなければならず、これは絶対的な前提条件です。

最先端のモデルで開始することは、POCの観点からは非常に魅力的に見えますが、コストと遅延の懸念が迅速に制限要因となる可能性があります。私たちの経験では、常にトップクラスのモデルを使用する必要はありません。代わりに、特定のユースケースに最適なモデルを選択し、必要に応じてより高性能なモデルにフォールバックするアプローチを取ることをお勧めします。

具体的な例として、私たちは最初にClaude Haikuモデルを使用し、Guardrailをパスしない場合にCloud Sennetモデルにフォールバックする戦略を採用しました。これにより、コストと性能の最適なバランスを実現することができました。セキュリティを損なうことなく、効率的なソリューションを構築することが可能です。

このように、セキュリティを最優先としながら、コストと遅延のバランスを適切に取ることが、実用的な生成AIアプリケーションの構築には不可欠です。これは単なる技術的な決定ではなく、ビジネス要件との整合性も考慮した戦略的な判断となります。

4.2 言語特有の注意点への対応

Ankur: 参照データとカスタマークエリの使用について、非常に慎重なアプローチを取る必要があります。私たちの経験では、言語固有のニュアンスを理解することは特に重要です。なぜなら、モデルは言語によって全く異なるパフォーマンスを示すことがあるからです。

私たちは18の言語でサービスを提供していますが、各言語でのモデルの振る舞いは大きく異なることがあります。従って、特定の言語に対するモデルの性能を事前に十分評価し、必要に応じて言語固有の調整や補完的な対策を講じる必要があります。

また、LLMは解決策の検証において、タスクを解決すること自体よりも優れた性能を発揮することがわかりました。これは非常に重要な発見でした。つまり、モデルは特定の言語での解決策を生成するよりも、その解決策が正しいかどうかを判断する方が得意だということです。この特性を活かし、言語ごとに適切な検証メカニズムを組み込むことで、より信頼性の高いシステムを構築することができます。

このように、言語特有の課題に対しては、単一のアプローチではなく、各言語の特性とモデルの性能を考慮した柔軟な対応が必要です。これは特にクロスボーダーサービスを提供する企業にとって重要な考慮事項となります。

4.3 生成AIの制御と監視の方法

Raj: これまでの説明を総括すると、生成AIアプリケーションを構築する際は、決定論的制御と確率論的制御を適切に組み合わせることが重要です。先ほど、元のリストに戻って整理させていただくと、機密データの保護や PIIなどは、RegXパターンなどの決定論的な制御を使用することで実現できます。一方で、有害な攻撃からの保護や、RAGでの幻覚を防ぐといった部分では、確率論的な制御が有効です。

このような制御を効果的に機能させるためには、継続的なモニタリングが不可欠です。CloudWatchやCloudTrailを活用することで、アプリケーションの動作を常に監視し、問題が発生した際に迅速に対応することができます。また、モデル呼び出しログを有効にすることで、生成AIの出力の質を継続的に評価し、必要に応じて調整を行うことができます。

特に、我々の経験から、確率論的な制御には一定のリスクが伴うことを理解しておく必要があります。そのため、複数の層による防御を構築し、1つの制御が失敗した場合でもシステム全体の安全性が保たれるようにすることが重要です。また、定期的にセキュリティ評価を行い、新たな脅威や課題に対応できるよう、システムを進化させ続けることが必要です。

4.4 今後の展開とビジョン

Ankur: 私たちはより広範な生成AIの展開ビジョンを持っています。まず、新しい意図に基づく修復ワークフローを導入することで、実装のカバレッジを拡大し、チャット体験内でより多くの顧客の課題に直接対応することを目指しています。

また、意図分類が正しい軌道から外れた際により適切に検出し、顧客とのコミュニケーションの中で軌道修正できるよう、言語理解能力を活用していきたいと考えています。

さらに、生成AIの活用範囲をサポートの領域を超えて拡大することも計画しています。その一例として、マーケティングコンテンツの生成があります。これは自動サポートの実装例の一つとして、現在検討を進めているところです。

データソースの拡大も重要な課題です。Amazon Bedrock Guardrailsを私たち自身でホストする代わりに使用することで、より多くのデータソースを安全に活用できるようになることを期待しています。

最後に、私たちのCISO、Darren Challeyの言葉を引用させていただきたいと思います。彼は、AWSとのパートナーシップと、顧客データを安全に保つために必要な制御を構築するための製品に深く感謝しています。顧客が迅速に送金できるようにすることは、私たちにとって最も重要な目標であり、そのために革新を続けていきます。