開発者と読み解くAIの世界

ガードレールによるLLMの安全性担保

安全なLLMプロダクトを構築するための技術

坂本一樹

2024年12月12日 09:00

　本コーナー「開発者と読み解くAIの世界」では、AIアプリ開発に携わるエンジニアより寄稿いただき、開発者目線でみる生成AIの面白さや活用法、開発現場のリアルをお伝えします。

　ソフトウェアプロダクトにLLM（大規模言語モデル）を組み込む動きは世界的に加速し続けています。しかし、一方でLLMの出力自体は誤った情報やプライバシーの侵害にあたる情報、差別を助長する情報などが含まれてしまう場合があります。

　そのような状況を防ぐためにLLMに対して、ガードレールの構築が求められるケースが増えてきています。

　この記事では、LLMのガードレールの重要性と実際にプロダクトに組み込む実装について、お話させていただければと思います。

ガードレールを用いたLLMの出力制御

LLMにおけるガードレールとは

　LLMにおけるガードレールとは、“LLMの回答をユーザーにとって安心できるものとするため、LLMとシステム間でリスクある回答を検知する機能および、検知したときの振る舞いを決める技術的戦略”といえます。

　現段階で、いくつか論文も出ていますし、OSS（オープンソースソフトウェア）やSaaSとしての提供も増えており、LLMプロダクトの拡大とともに正しい情報を安定して提供するための考え方として急速に広まっています。

ガードレールの目的

　ではなぜ、ガードレールは必要なのでしょうか。

　ガードレールの大きな目的としては、LLMの回答を特定の形式やコンテキストに強制し、各レスポンスを検証することで、不審な回答をユーザーの目に触れさせないことにあります。

　例えば、生成した回答が個人情報を含んでいる場合にはそれを検知し、個人情報をマスキングした文章に書き換えることで情報流失を避ける、といった使い方ができます。

　「何故そのようなガードレールが必要か」というと、LLM自体にもまだまだ問題があり、ハルシネーションと呼ばれるAIの誤回答であったり、バイアスのかかった回答や差別的な回答、意図していない個人情報を出してしまうという問題があります。

LLMの問題	内容
ハルシネーション	参照元や事実とは異なる情報、また事実性が確認できない情報を生成してしまう
偏見や差別	社会的偏見や差別を含んだ内容を出力してしまう
情報漏えい	個人情報や社内の機密情報を意図しない形で出力してしまう
非道徳的・法的な問題	“爆弾の作り方”など道徳的・法的に問題のある内容を出力してしまう
セキュリティ（Jailbreak）	悪意あるユーザーによって上記ケースの出力を意図的にさせられてしまう

　現状では、LLMに対してこういった回答を完全に防ぐ手段はありません。

　そのため、ユーザーがLLMから回答を直接受け取ってしまうと、誤解を与えてしまうケースや、最悪の場合ユーザーに損害を与えるケースが発生する可能性があります。

　こういったことを防ぐためには、ガードレールとして、誤回答を検知してユーザーの目に触れさせない仕組みが必要となります。

ガードレールの適用範囲

　LLMのガードレール自体は、基本的にLLMのインプット／アウトプットに関して適用されます。

インプット

　生成AIに対して入力する文章をチェックするガードレールとなります。例えば、個人情報が含まれている場合にマスクしたり、言い換えを行ったりといった操作を実行します。

　また、特定の話題（暴力的なコンテンツなど）を実行しないようにしたり、jailbreakなどの悪意を持った実行を検知します。

アウトプット

　生成AIに対して出力時に回答をチェックするガードレールです。出力に対しても入力と同じように個人情報のマスクや削除の実行をします。

　また、生成されたものが文法として正しいか判断したり、そもそも問い合わせを行っている内容と関係ないことを出力していないかをチェックします。

　最終的には出力が完全に間違って出力されていれば、エラーなどの定型文を返す等の処置も行います。

　ほかにも特定のJSON型で返すなど、出力の形式を固定する役割をもつ機能もあります。

ガードレールの実装

　インプット／アウトプットに対するガードレールの実装では、大きく分類すると2タイプに分かれています。それぞれメリット、デメリットがあり、組み合わせて実装するケースがほとんどになります。

静的ガードレール

　LLMが出力した文章を静的判断するガードレールです。ここでいう「静的」とは同じデータを入れたときにガードレールとしての判定が変化しないものを指します。

　例えば、メールアドレスという個人情報を特定してマスクしたいとします。メールアドレスには xxxx@xxxx.xx.xx と定められた形式があるため、文章のどの部分に記載されていようとも判定は変化しません。

メリット

確実に検知対象の文字を除去できる
－例）センシティブワード、暴力表現など
ガードレールが機能するかテストがしやすい
無料で構築できるケースが多い

デメリット

全てのNGとしたい単語を入力するのは現実的でない
文脈情報を考慮した判定をすることは難しい

　単語の特定という意味では、NGワードを集めたライブラリも公開されているため、センシティブワードなどの除外したい単語を断定することも可能です。

　一方で、新しく出てきた単語を常にメンテナンスする必要がありますし、文脈に応じて判断基準を変更したい単語を判定することは難しいでしょう。

動的ガードレール（LLM as a Judgeを用いたガードレール）

　「LLM as a Judge」とは、成果物の品質を評価するためにLLMを審査員として活用する手法となります。

　今回のケースでは、ガードレールとしてインプット／アウトプットの評価にLLMを使うケースを指します。

　LLMは非常に柔軟ですので、同じく自然言語に対応できるLLMをガードレールに使用し、文脈等のニュアンスも捉えられるようになります。

メリット

ルール化しきれない文脈を用いた表現の判定ができる
－例1）“ビジネスにふさわしくない表現がないかチェックして”
－例2）“お客様の名称には必ず様をつけているかチェックして”
文法などの言語としての間違いを指摘できる

デメリット

判定漏れや判定誤りが含まれる可能性がある
LLMを再度呼び出すため、ユーザーへのレスポンスが遅くなる
追加でLLMを呼び出すための費用がかかる場合が多い

　こちらは静的ガードレールの鏡写しになっており、文脈やニュアンスを捉えることはできますが、LLMを使っている以上、ガードレール自体にハルシネーションなどが起こる可能性があります。

　また、LLM自体は、現状では返答にある程度時間がかかります。ユーザーとインタラクティブなやり取りをさせている最中に何度も呼び出していてはユーザー体験を損なう可能性があります。どこまでを静的ガードレールで担保し、どこからを動的ガードレールとするかは、システムとしてユーザーにどんな体験をさせたいかという選択になります。

LLMの問題	主な対処
ハルシネーション	動的ガードレールによって再確認を行う
偏見や差別	静的ガードレールで対象の単語が入出力されていないか確認する
情報漏えい	静的ガードレールで正規表現を使い、個人情報や機密情報が含まれていないか確認する
非道徳的・法的な問題	動的ガードレールによって文脈を確認する
セキュリティ（Jailbreak）	動的ガードレールによって悪意ある入力を制限する
※文脈による動的ガードレールのチェックは全てのパターンで対応可能

LLMのガードレールのユースケース

　ここまでLLMのガードレールについて解説してきましたが、実際のプロダクトへの適用イメージを得るために、いくつかのユースケースを説明いたします。

１.メール自動生成における文法チェック

　LLMのユースケースとしてメールの自動化をアシストして欲しいと思う方は多いかと思います。一方で失礼に当たるメールが自動生成されては困ります。

　こういった場合には、動的ガードレールを使用して“敬称に様をつけているか”、“敬語の使用は適切か”、“論理的な内容になっているか”をチェックすることが必要です。

２.コールセンターにおける通話内容要約

　コールセンターでもLLMの使用は加速しています。しかし、コールセンターでは電話番号などの個人情報のやり取りをするケースも多々あります。その際の要約では個人情報をマスクしたいので、静的ガードレールにより個人情報をマスクして出力しないようにすることができます。

３.デパートのフロア案内における話題固定

　LLMは音声での対話ができるので、デパートや飲食店などでも使用されるケースが増えるかと予想されます。その際、ユーザーのインプットに対して案内とは関係ない回答（例えば政治の話題など）をされると、レピュテーションリスクに繋がります。その場合は動的ガードレールを使用して特定の話題以外は回答しないようにするのが無難です。さらに静的ガードレールを使用して暴力的表現などは使えなくしておくとリスクをより減らせるでしょう。