写真：窓の杜

　本コーナー「開発者と読み解くAIの世界」では、AIアプリ開発に携わるエンジニアより寄稿いただき、開発者目線でみる生成AIの面白さや活用法、開発現場のリアルをお伝えします。 【この記事に関する別の画像を見る】 　ソフトウェアプロダクトにLLM（大規模言語モデル）を組み込む動きは世界的に加速し続けています。しかし、一方でLLMの出力自体は誤った情報やプライバシーの侵害にあたる情報、差別を助長する情報などが含まれてしまう場合があります。 　そのような状況を防ぐためにLLMに対して、ガードレールの構築が求められるケースが増えてきています。 　この記事では、LLMのガードレールの重要性と実際にプロダクトに組み込む実装について、お話させていただければと思います。 ◆ ガードレールを用いたLLMの出力制御 ■ LLMにおけるガードレールとは 　LLMにおけるガードレールとは、“LLMの回答をユーザーにとって安心できるものとするため、LLMとシステム間でリスクある回答を検知する機能および、検知したときの振る舞いを決める技術的戦略”といえます。 　現段階で、いくつか論文も出ていますし、OSS（オープンソースソフトウェア）やSaaSとしての提供も増えており、LLMプロダクトの拡大とともに正しい情報を安定して提供するための考え方として急速に広まっています。 ■ ガードレールの目的 　ではなぜ、ガードレールは必要なのでしょうか。 　ガードレールの大きな目的としては、LLMの回答を特定の形式やコンテキストに強制し、各レスポンスを検証することで、不審な回答をユーザーの目に触れさせないことにあります。 　例えば、生成した回答が個人情報を含んでいる場合にはそれを検知し、個人情報をマスキングした文章に書き換えることで情報流失を避ける、といった使い方ができます。 　「何故そのようなガードレールが必要か」というと、LLM自体にもまだまだ問題があり、ハルシネーションと呼ばれるAIの誤回答であったり、バイアスのかかった回答や差別的な回答、意図していない個人情報を出してしまうという問題があります。 　現状では、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のガードレールのユースケース 　ここまでLLMのガードレールについて解説してきましたが、実際のプロダクトへの適用イメージを得るために、いくつかのユースケースを説明いたします。 ■ １.メール自動生成における文法チェック 　LLMのユースケースとしてメールの自動化をアシストして欲しいと思う方は多いかと思います。一方で失礼に当たるメールが自動生成されては困ります。 　こういった場合には、動的ガードレールを使用して“敬称に様をつけているか”、“敬語の使用は適切か”、“論理的な内容になっているか”をチェックすることが必要です。 ■ ２.コールセンターにおける通話内容要約 　コールセンターでもLLMの使用は加速しています。しかし、コールセンターでは電話番号などの個人情報のやり取りをするケースも多々あります。その際の要約では個人情報をマスクしたいので、静的ガードレールにより個人情報をマスクして出力しないようにすることができます。 ■ ３.デパートのフロア案内における話題固定 　LLMは音声での対話ができるので、デパートや飲食店などでも使用されるケースが増えるかと予想されます。その際、ユーザーのインプットに対して案内とは関係ない回答（例えば政治の話題など）をされると、レピュテーションリスクに繋がります。その場合は動的ガードレールを使用して特定の話題以外は回答しないようにするのが無難です。さらに静的ガードレールを使用して暴力的表現などは使えなくしておくとリスクをより減らせるでしょう。 ◆ 安全なLLMプロダクトを目指して 　本記事では、LLMガードレールについてと実際のユースケースについて説明させていただきました。 　LLMのガードレールを簡単に構築できるOSSやLLMの基盤側でもガードレールのサービスは開始していますので、必要に応じて設定するか、自分たちでガードレールの構築することを検討いただければと思います。 　LLM自体は非常に素晴らしい技術であり、今後の社会発展に大きく寄与する可能性を秘めています。しかし、急速に発展したが故にLLM自体いろいろな問題をはらんでいるのもまた事実です。 　その中で、どれだけ安全にLLMのプロダクトを構築していくかで、今後の社会発展のスピードすら変わっていくかもしれません。 ■ 著者プロフィール：坂本 一樹 　ソフトバンクに新卒入社し、交換機の運用に従事。その後、エンジニアとして新規システム部門の立ち上げを経て、ベンチャー企業を複数社経験。2024年10月にAlgomaticへ参画。現在はHR領域で生成AIを用いたプロダクト開発をテックリードとして推進中。 ・株式会社Algomatic：https://algomatic.jp/