Amazon Web Services ブログ
AWS で実現する安全な生成 AI アプリケーション – OWASP Top 10 for LLM Applications 2025 の活用例
近年、企業や組織において、生成 AI を自社のプロダクトに組み込む取り組みが広がっています。生成 AI は、テキスト生成、画像や動画の生成、音声生成など、様々な分野で活用されるようになり、業務の効率化や新しい価値の創出などに期待が高まっています。
一方で、生成 AI を自社のプロダクトに組み込むにあたっては、セキュリティ面での課題にも十分に注意を払う必要があります。生成 AI は、機械学習や自然言語処理などの高度な技術を用いて構築されるため、従来のプロダクトとは異なる脆弱性が存在する可能性があります。例えば、生成 AI が不正に操作されて、偽のコンテンツを生成されたり、機微情報が漏洩したりするなど、深刻な影響が生じる可能性が指摘されています。
これらの脅威への対策は、生成 AI に関わるプロダクトを開発する企業や組織にとって重要な課題となっています。生成 AI のセキュリティ対策については、さまざまな組織や団体からセキュリティフレームワークが提案されてきています。このブログでは、OWASP が生成 AI アプリケーションにおける主要な 10 のセキュリティ脅威をまとめた OWASP Top10 for LLM Applications を参照しながら、AWS 上で生成 AI アプリケーションを設計・開発する方が考慮すべきポイントやリスクシナリオを概説します。
OWASP Top10 for LLM Applications は 2024 年 11 月にVersion 2025 が公開されました。生成 AI の技術や活用が進むにつれて脅威も変化します。このブログでは、以前の Version との差分などに触れながら、具体的な事例や対策方法をご紹介します。生成 AI を安全に活用していくためのヒントが見つかるはずです。ぜひ最後までお読みください。
Amazon Bedrock を用いた基本的な生成 AI アプリケーションのアーキテクチャとコンポーネント
AWS 上で構成される生成 AI アプリケーションをベースに OWASP Top 10 for LLM Applications の考慮事項を考えられるように、まずは基本的な生成 AI アプリケーションのアーキテクチャについて説明します。
図 1: 基本的な生成 AI アプリケーションのアーキテクチャの例
構成要素となるコンポーネントの例
以下で、図 1 の基本的な生成 AI アプリケーションのアーキテクチャで扱われているサービスをご紹介します。
- Amazon Cognito:ユーザーがアプリケーションを利用する前に認証を行います。
- 生成 AI アプリ:ユーザーに対してウェブのインターフェースを提供します。またユーザーのリクエストを処理するために、各コンポーネントとの一連のやり取りをオーケストレーションします。一例として静的コンテンツを Amazon Simple Storage Service (Amazon S3) へホスティングし Amazon CloudFront で配信し、動的コンテンツについては Amazon API Gateway で API としてリクエストを受け付けサーバーレスの AWS Lambda で処理をするように構成する場合があります。または仮想サーバーの Amazon Elastic Compute Cloud (Amazon EC2) やコンテナ実行環境の Amazon Elastic Container Service (Amazon ECS) を利用したウェブサーバやアプリケーションサーバを構成する場合もあります。
- Amazon DynamoDB:ユーザーの会話履歴を NoSQL のデータベースに保存します。
- Amazon Bedrock:
- 大規模言語モデル (Large Language Model:LLM):ユーザーのリクエストを基に回答を生成する大規模言語モデルです。
- ナレッジベース:LLM が事前学習していない (LLM 自体には学習させたくない) ユーザー固有の情報を生成 AI アプリケーションが利用できるようにするために、他のデータソースとの接続をマネージドに提供します。
- 埋め込みモデル:データソースに含まれるテキストなどの情報の埋め込みを行いベクトルデータに変換します。
- ベクトルデータベース:埋め込みモデルで変換されたベクトルデータを保存し、ユーザからのリクエストに基づいてベクトルデータベース内を検索します。例として Amazon OpenSearch Service などがあります。
- Amazon S3:LLM が事前学習していないユーザー固有の情報を生成 AI アプリケーションが利用できるようにするために、ユーザー固有の情報を保管するデータソースです。
生成 AI アプリケーションの動作
事前準備:
a. 事前にアプリケーションで利用するユーザー固有の情報を S3 バケットへ格納しておきます。
b. ナレッジベースを S3 がデータソースとするように構成し、データを同期します。これにより S3 バケットに含まれる情報が埋め込みモデルによって処理されます。
c. 埋め込みモデルによって処理された情報はベクトルデータベースである OpenSearch Service へ保管されます。
アプリケーションのデータフロー:
- ユーザーはアプリケーションにアクセスすると Cognito にリダイレクトされ、認証を行います。
- ユーザーはチャットベースのインターフェース上で、リクエストをプロンプトとして記入し送信します。
- (過去のチャット履歴を参照するような処理をしている場合) アプリケーションは認証情報に含まれるユーザー ID から過去のチャット履歴を照会し、内容を取得します。
- アプリケーションはユーザーのプロンプトに関連する情報を検索するために、プロンプトの文言をナレッジベースで検索します。この動作の過程でユーザーのプロンプトは埋め込みモデルでベクトル化され、ベクトルデータベース上で検索されます。これによりユーザーのプロンプトに関連性の高い情報を効率的に検索することが可能です。結果、アプリケーションはユーザーのプロンプトに関連性の高い情報と、その情報のメタデータ (ファイル名、ファイルのパスなど) を取得します。
- アプリケーションは [2] で取得したユーザーのプロンプト、[3] で取得した会話履歴、[4] で取得した関連性の高い情報とそのメタデータを LLM に入力し、LLM の推論結果を取得します。
- [5] で取得した LLM の推論結果をユーザーに返答します。
OWASP Top 10 for LLM Applications の概要と更新点
OWASP Top10 for LLM Applications では生成 AI アプリケーションの 10 の主要な脆弱性と、それぞれの脅威の概要やリスクシナリオが各項目ごとに示されています。2023 年 10 月に Version 1.1 が公開されていましたが、2024 年 11 月には Version 2025 がリリースされました。
前回の Version と比べてどのような変更がなされたのでしょうか。図 2 に変更点を独自に整理した内容を記載します。
図 2: OWASP Top 10 for LLM Applications の Version 1.1 と Version 2025 の変更点比較
まず、注目すべきは順位の変化です。以前の Version では 6 位だった「機微情報の漏えい」が 2 位にランクアップしています。一方で、1 位の「プロンプトインジェクション」は変わっていません。
新たな項目として、「LLM07:2025 システムプロンプトの流出」、「LLM08:2025 ベクトル化と埋め込みの脆弱性」の 2 つが追加されました。「システムプロンプトの流出」は、ユーザーの入力のようなユーザープロンプトとは別に、本来は生成 AI アプリケーションの内部で制御に使用されるプロンプト (システムプロンプト) が不正に流出し、悪用される可能性のある脆弱性です。システムプロンプトには機微情報が含まれていたり、不適切な出力を生み出さないような出力を制御する内容が記載されている可能性があるため、システムプロンプトの適切な利用や管理が重要になります。
また、「ベクトル化と埋め込みの脆弱性」は、Retrieval Augmented Generation (RAG) を使用する生成 AI アプリケーションにおけるセキュリティリスクです。RAG では、事前学習済みの言語モデルとベクトル化された外部のデータソースを組み合わせることで、応答の性能と文脈の関連性を高めています。しかし、ベクトルや埋め込みの生成、保存、検索の方法に脆弱性があると、悪意のある行為 (意図的または非意図的) によって有害なコンテンツの注入、モデル出力の操作、機微情報へのアクセスなどが可能になる可能性があります。
OWASP Top 10 for LLM Applications の脆弱性と生成 AI アプリケーションとのマッピング
OWASP Top 10 for LLM Applications の各脆弱性を AWS 上で構成する生成 AI アプリケーションで考えられるように、図2 のアーキテクチャ上にマッピングしてみましょう。
図 3: OWASP Top 10 for LLM Applications の各項目のマッピング
今回例示しているような生成 AI を活用したチャットボットのようなシンプルなアプリケーションであっても、各考慮事項がアーキテクチャ上のコンポーネントを幅広くとらえていることが図 3 からも分かります。
本ブログでは、この中から、特に Version 2025 で新たに追加された、LLM07:2025 システムプロンプトの流出と、LLM08:2025 ベクトル化と埋め込みの脆弱性について着目し深堀します。この 2 点以外も重要な観点であり Version 1.1 から内容もアップデートされていますが、引き続き「OWASP Top 10 for LLM を活用した生成 AI アプリケーションの多層防御セキュリティ設計」の内容が参考になります。必要に応じてご活用ください。
Version 2025 で追加された新たな考慮事項
LLM07:2025 システムプロンプトの流出
システムプロンプトの流出のリスクとは、モデルの動作を制御するために使用されるシステムプロンプトに、本来第三者に閲覧されるべきではない機微情報が含まれたり、システムプロンプトに記載されるルールやユーザーの役割や権限、フィルタリングなどのセキュリティ制御を他者に知られてしまうことです。開発者はシステムプロンプトに機微情報を含めるべきではなく、セキュリティ制御として使用すべきではないことを理解することが重要です。
システムプロンプトの例として、GitHub で公開されている generative-ai-usecases-jp (通称: GenU) のサンプル実装で記載されているいくつかのユースケースでのシステムプロンプトを例として確認してみましょう。
文章要約ユースケース
あなたは文章を要約する AI アシスタントです。
最初のチャットで要約の指示を出すので、その後のチャットで要約結果の改善を行なってください。
翻訳ユースケース
以下は文章を翻訳したいユーザーと、ユーザーの意図と文章を理解して適切に翻訳する AI のやりとりです。
ユーザーは <input> タグで翻訳する文章と、<language> タグで翻訳先の言語を与えます。
また、<考慮してほしいこと> タグで翻訳時に考慮してほしいことを与えることもあります。
AI は <考慮してほしいこと> がある場合は考慮しつつ、<input> で与えるテキストを <language> で与える言語に翻訳してください。
出力は <output> {翻訳結果} </output>の形で翻訳した文章だけを出力してください。
それ以外の文章は一切出力してはいけません。
システムプロンプトの流出における、予防と緩和戦略は主に 2 点になります。1 つ目は、API キー、認証キー、データベース情報、アプリケーションの権限構造などの機微情報をシステムプロンプトに含めることを避けてください。権限を分離し、機微情報にモデルが直接アクセスしないよう外部で管理することが望ましいです。Amazon Bedrock Converse API の Tool Use (function calling) では モデルが直接ツールを利用することなく、ユーザー側 (アプリケーション) でツールの実行を行うことが可能です。また Amazon Bedrock Agents では Action Group として Lambda 関数を指定し、モデルには関数の実行権限だけを与え、動的な処理を実装することも可能です。2 つ目は、モデルの厳格な動作の制御にシステムプロンプトを使用することは可能な限り避けることが推奨されます。システムプロンプトを明らかにしないように学習されたモデルもありますが、現時点でモデルが常にこれを遵守する保証はありません。モデルが期待に沿った動作をしているかどうかを判断するための独立した仕組みを用意することが望ましいです。これらは一般にガードレールと呼ばれ、例えば自社で開発する生成 AI アプリケーションが有害なコンテンツを生成していないかの検出と防止はモデルの外部で行うべきです。Amazon Bedrock ガードレールのコンテンツフィルターでは、有害なコンテンツの判定が可能です。マルチモーダルにも対応しており、テキストデータに加えて画像の検出にも活用可能です。
(筆者注) Amazon Bedrock ガードレールは 2025 年 1 月 16 日時点で公式には英語、スペイン語、フランス語のみをサポートしており、他の言語でテキストコンテンツを評価すると、信頼できない結果になる可能性があります。テストデータで検証し、実装方法をご検討ください。
LLM08:2025 ベクトル化と埋め込みの脆弱性
RAG を使用する生成 AI アプリケーションの考慮事項として、不適切なアクセス制御や反転攻撃 (モデルをリバースエンジニアリングする攻撃) によるデータの流出、ナレッジの競合、データの汚染、モデルの振る舞いへの影響などがあります。これらに対する予防・緩和戦略として 3 つの観点を掘り下げてみます。
アクセス制御:
ユーザー固有の情報の保護のために適切なアクセス制御が必要です。ここでは AWS アカウントと RAG の 2 つの観点で考えてみましょう。まずは AWS アカウントについて、関係者を洗い出してみます。生成 AI アプリケーション開発者はもちろん、精度評価や改善を行うデータサイエンティスト、マルチアカウント環境の管理者や監査人などです。次にユーザー固有の情報が含まれるコンポーネントを特定します。S3 や OpenSearch、DynamoDB、またモデル呼び出しのログを記録する場合はログを格納する Amazon CloudWatch Logs や S3 などです。これらを踏まえ、アイデンティティベース、あるいはリソースベースのポリシーを活用し適切にアクセス制御を行います。厳格にアクセス制御を行うことが難しい場合、代わりに Amazon GuardDuty のような脅威検出サービスを使って S3 バケットへの異常な振る舞いや脅威を検知したり、 S3 や DynamoDB のデータに対するアクセスを AWS CloudTrail のデータイベントとして取得し、データに対するアクセスを追跡できるようにしておくことも考えられます。
続いて、ユーザーの所属する部署などに応じて参照可能なデータのみを RAG のコンテキストとして扱うケースを考えてみます。この場合、ユーザーやユーザーが所属する部署などの識別子を Cognito から取得したトークンから確認し、適切に参照する情報を制御できる必要があります。ナレッジベースのマルチテナントに関する考察(英語)やメタデータを用いたフィルタリングをご参考いただいたり、ナレッジベースの代わりにユーザーに応じたアクセス制御をサポートしている Amazon Kendra を利用することも考えられます。
データのバリデーションとデータソースのリスク評価:
RAG で参照するデータのバリデーションを適切に行うことで、ユーザー固有の情報に含まれる個人情報などの流出から保護します。一例として、S3 にデータを格納する際に個人情報をマスクする前処理を行うパイプラインを構成しているケースがあります。データがアップロードされるとパイプラインが自動で起動し、文書の中から個人情報に該当する氏名や電話番号、メールアドレス、社員番号などの情報がマスクされてから、ナレッジベースが参照する S3 バケットにデータが格納されます。これにより、アプリケーションを通して個人情報が公開されるリスクを低減します。
またデータソースのデータが安全に利用できるものであるかリスク評価を行うことが重要です。例としてナレッジベースのデータソースタイプとして Web クローラーを活用する場合、参照先が信頼できる情報ソースなのか十分にリスク評価する必要があります。特に参照する Web サイトが任意の第三者が任意の記載を行うことができる場合、データの汚染を引き起こし、それが悪意あるプロンプトを含んでいる場合に間接的なプロンプトインジェクションが生じる可能性があります。
ログの取得と評価・分析:
悪意あるプロンプトやナレッジの競合などモデルの振る舞いに影響となる要因を特定し対処するために、ログの取得と評価や分析を行います。一例として、ナレッジベースに対して実行された処理にて、どのような情報を取得したかアプリケーションでログとして出力するように構成できます。また、ユーザーの入力と最終的にモデルが生成した出力は、アプリケーション上、あるいはモデル呼び出しのログ記録でログ取得ができます。アプリケーションが意図しない応答をしていることが分かった場合、ログを調査することでどのユーザーが行ったことなのか、意図しない応答を引き起こしたプロンプトがユーザーの入力と RAG で参照した情報のどちらに含まれていたのかを追跡できます。またアプリケーションの開発体制にデータサイエンティストが入ることで、ログの評価・分析を行う場合があります。RAGAS などを用いて RAG の精度評価を行い、検索時と生成時のどちらに課題があるかを切り分け、分析に基づくパラメータのチューニングやアプリケーションの改修など RAG の改善活動を行います。
このような予防緩和戦略を取り入れ、図 1 のアーキテクチャの例をアップデートしたものが図 4 となります。
図 4: ベクトル化と埋め込みの脆弱性に対する予防緩和戦略の実装例
まとめ
本ブログでは生成 AI アプリケーションにおける主要な 10 のセキュリティ脅威をまとめた OWASP Top10 for LLM Applications で挙げられている脅威の概要について触れ、特に Version 2025 で新たに追加されたシステムプロンプトの流出とベクトル化と埋め込みの脆弱性について記載しました。本内容が生成 AI アプリケーションの開発に関わられている皆様の参考になれば幸いです。
著者について
片山 洋平 (Yohei, Katayama) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。
藤浦 雄大 (Yuta Fujiura) は AWS Japan のプロフェッショナルサービス本部所属のセキュリティコンサルタントです。生成 AI セキュリティリードを担当し、生成 AI セキュリティや責任ある AI のトレーニング、アセスメント、ガイドライン策定などでお客様をご支援しています。また生成 AI に関するブログ翻訳も数多く担当しています。余暇はブロックでオリジナル作品を作っています。