チャットメモリの操作がAIシステムを台無しにする仕組み
0 分で読めます
LLMに会話の記憶はあるのか？
ChatGPT、Claude、Copilotの登場により、私たちは日常的にチャット型AIアシスタントを利用するようになりました。チャットボットが私たちのことや、以前の会話を「覚えている」ことにも慣れてきました。
好みを思い出すバーチャルアシスタントから、過去の問い合わせを追跡するサポートボットまで、チャットメモリはデジタルエージェントとのやり取りに自然に備わっているように感じられます。そのため、ChatGPTなどの最新のAIモデルやLLMを活用したボットにも、同様の記憶機能が組み込まれていると思いがちです。
しかし、それは錯覚です。実際には、大規模言語モデル（LLM）はステートレスで、現在の会話や過去の会話で交わされた質問や回答を知りません。LLMは応答を生成するたびに、その時点で与えられた入力だけをもとに回答します。過去の会話の履歴がプロンプトに明示的に含まれていない限り、それを記憶しているわけではありません。記憶しているように見えるのは、AIアプリケーションの開発者が過去の会話メッセージを入力に埋め込むという巧妙な設計パターンによるものです。
AIアプリでチャットメモリを実装する
LLMを活用したアプリケーションでチャットメモリを実装する場合、開発者は通常、自分たちで会話履歴を管理します。ユーザーの入力とLLMの応答は、永続化のためにデータベースなどに保存します。多くの最新LLM APIは、過去のメッセージをリクエストの一部として渡せる構造化入力に対応しています。これは一般に「コンテキスト」と呼ばれます。メッセージは通常、ロールを付与したエントリーの連なりとして整理され、各メッセージにsystem、user、assistantのいずれかのタグが付けられます。この構造により、モデルは会話の構成や流れを理解できます。
たとえば、LLMにリクエストを送信する際、ペイロードには次の内容が含まれる場合があります。
system：ボットの役割を定義する指示（例：「あなたは親切なアシスタントです。」）
user：ユーザーのメッセージ。
assistant：チャットボットの応答。
新しいリクエストのたびに、この一連のメッセージをモデルに再度渡すことで、チャットボットは会話を「覚えている」ように見えます。実際には、与えられた対話履歴にもとづいて、次の応答を予測しているにすぎません。
多くのAPIには専用のmessagesフィールドがあり、このようにロールを付与したメッセージの連なりを渡せます。以下のコード例と同様です。
会話の進行に合わせてメッセージリストを維持・更新し、トークン制限に収まるよう必要に応じて内容を削除したり要約したりするのは、開発者の責任です。この方法では、柔軟で透明性の高いモジュール型のメモリを実現できますが、誤解を招く内容や改ざんされた内容が挿入されないよう、慎重に管理する必要があります。
アプリケーション内でLLMコンポーネントをオーケストレーションするための現在のフレームワークを使えば、チャットメモリの実装は簡単です。メモリコンポーネントに過去の会話をあらかじめ読み込むだけで、以前の会話を簡単かつ効果的に続けられます。
JavaのLangchain4Jでチャットメッセージを扱う
以下は、Langchain4jを使ってチャットメモリ付きのAiServiceを作成するJavaの例です。データベースに保存されたメッセージをチャットメモリにあらかじめ読み込み、UserMessageまたはAiMessageとして挿入します。
LLMのチャットメモリへのインジェクション
開発の観点から見ると、チャットボットに以前の会話を覚えているように見せるために、過去の会話を保存して再挿入することはそれほど難しくありません。しかし、メッセージと応答はステートレスなLLMに送られるコンテキストの一部であるため、潜在的な攻撃経路にもなり得ます。偽のチャット履歴を巧妙に作成すれば、LLMをだまして望ましくない応答をさせる、汚染されたコンテキストを挿入できます。さらに、LLMが関数を呼び出せる、またはMCPサーバーにアクセスできる場合、望ましくないアクションやポリシーに反するアクションを実行する可能性もあります。
したがって、保存してLLMに再挿入する会話の完全性を確保し、誰にも改ざんされないようにする必要があります。データベース認証情報の漏えいや、コードや依存関係に含まれるSQLインジェクションのような単純な脆弱性が悪用され、会話を操作してLLMの挙動を改ざんされるおそれがあります。
チャットメモリへのインジェクション：概念実証
以下の例では、レンタカー会社のチャットサービスを使って予約をキャンセルしようとします。利用規約上、キャンセルはできないはずです。LLMを利用したチャットボットにキャンセルを依頼すると、規約に従って拒否します。
アプリケーションの別の箇所には、SQLインジェクションが可能な検索機能があります。このSQLインジェクションを悪用し、次のクエリでデータベースにあらかじめ作成した会話を挿入できます。
つまり、チャットボットをだまして予約をキャンセルさせようと、ユーザーのプロンプトとアシスタントの応答を含む会話を捏造しています。
先のSQLインジェクション攻撃で挿入された偽の会話は、チャットボットが予約を削除したという確認で終わっています。もちろん、実際にはまだ削除されていません。しかし、次のプロンプトで確認を求めると、LLMはポリシーに反していても予約を削除する関数を実行します。
重要なのは、チャット履歴を編集・改変すると、LLMに文脈から外れた応答をさせられるということです。LLMが関数ツールを使える場合、説得力のある会話を作り込むことで、その関数を実行するよう仕向けることもできます。
チャットメモリの改ざんを防ぐことが重要
LLMはステートレスであり、プロンプトはAIサービスの応答を左右する重要な要素です。チャットメモリとは、コンテキストでプロンプトを補完することにほかなりません。モデルは、プロンプトと与えられたコンテキストにもとづいて動作します。アプリケーション開発者は、自ら会話履歴を管理する必要があります。そのため、LLMに渡す会話の完全性を確保することが不可欠です。
上記の例では、チャット履歴を改ざんすることで、LLMにポリシー違反となる応答をさせ、関数を実行させることができました。簡略化した例ではありますが、SQLインジェクションのような基本的なコードの脆弱性が悪用され、AIの問題に発展することも示しています。したがって、コードや依存関係をスキャンして問題を検出し、こうした一般的な脆弱性を防ぐことが重要です。Snyk CodeとSnyk Open Sourceを使えば、簡単に実施できます。さらに、会話のハッシュフィンガープリントを保存するなど、完全性を保証する仕組みの導入も検討しましょう。
チャットメモリは攻撃経路となり、AIシステムやAIエージェントに本来実行すべきでない関数を実行させるために悪用される可能性があります。AIエージェントを開発する際は、チャットメモリへの攻撃に備えて保護策を講じましょう。
AIを組み込むことで生じるセキュリティリスクについて詳しく知りたい方は、以下をご覧ください。
AIへの信頼を築きませんか？実践的なガイドを今すぐ入手。
AI対応準備チェックリスト
AIへの信頼を築く
対処されないリスクを招くことなく、チームがAIを活用できるよう支援する、実践的で体系的なガイドをご覧ください。