LLMアプリの安全性を実環境で測るための考え方

安全性への関心が高まる中、LLMアプリをどのように評価すべきかという問いが浮かび上がっています。

そこで本記事では、LLMアプリケーションの安全性を実環境で評価するための枠組みを提案した研究を紹介します。モデル単体ではなく、プロンプトや外部連携を含むアプリ全体のふるまいに着目した実践的な評価手法が整理されています。

リスクの整理からテスト設計、結果の読み取り方まで、運用現場に応用しやすい視点が得られる内容を目指します。

背景

LLMを活用したチャットボットや業務支援アプリを開発する動きが広がり、試作や実装に取り組む人が増えています。APIや開発支援ツールも整備が進み、以前よりはるかに手軽にプロトタイプを構築できるようになっています。

一方で、こうしたアプリを実際に一般ユーザーに提供する段階では、「このアプリは本当に安全か」という問いに向き合う必要があります。モデルそのものの性能や制御だけでなく、アプリとしてのふるまい全体に目を向けたリスク評価が不可欠です。

たとえば、専用プロンプトの設定や外部知識との連携、ユーザーインタフェースの設計など、アプリごとの実装に応じて安全性の課題は大きく変わってきます。多くの有名な評価手法はいまだに基盤モデル単体に焦点を当てており、アプリ全体としての振る舞いを捉えるためのフレームワークが不足しています。

また、実際の利用シーンを反映していない形式で安全性を測っているベンチマークも多く、現実の運用リスクを見落とす可能性があります。たとえば外部連携が発生するだけでもモデルの応答傾向は変わることがあります。

LLMアプリを安全に社会に出していくには、開発者が自らの環境や目的に即した形で、安全性を定量的に把握できる実践的な評価の仕組みが求められます。

本記事では、そうしたニーズに応える枠組みとして、現場で運用しやすく、かつ再利用可能な安全性評価フレームワークの構築に取り組んでいる事例を紹介します。

評価ツールはあるのに使いにくい理由

LLMアプリの安全性を測るためのベンチマークは数多く登場していますが、現場でそのまま使えるかというと話は別です。実際の運用環境をきちんと想定できていないという声も多く、なぜ評価がうまくいかないのか把握しておく必要があります。

モデルだけ見ても現実のリスクはわからない

多くの評価は、LLMそのものを対象に設計されていますが、アプリとして動かすと、プロンプトの工夫や検索連携、インタフェース上の設計など、さまざまな要素が加わります。こうした構成全体を考慮しないと、本当に必要な安全性の確認にはなりません。

たとえば、選択肢形式で回答させるテストは、実際のチャット形式のやりとりとは大きく異なります。また、プロンプトやガードレールといった重要な設計要素を含まない評価も依然として多くあります。

ガードレールの大切さに言及するベンチマークもあるにはありますが、実際の評価プロセスに取り込めていないのが現状です。その背景には、アプリごとの構成が多様で、すべての組み合わせをテストするのが難しいという事情があります。

アプリの作り方が安全性を左右する

モデルそのものの性能とは別に、アプリとしての構成や設計が安全性に影響するという点も見逃せません。最近の研究では、その具体的な例がいくつか示されています。

良かれと思ってやった調整が裏目に出ることも

ファインチューニングでモデルを目的に合わせて調整するのは一般的な手法ですが、安全性の観点ではむしろ悪化するケースもあります。一般的なデータを使った場合でも、出力のバランスが崩れることがあると報告されています。

外部知識を加えると別の問題が出てくる

検索機能を加えて回答の質を高めようとする試みも増えていますが、これもまた新たなリスクを持ち込みます。モデルがもともと知らなかった情報を外から受け取ることで、想定外の危うい出力が生じる可能性があるという指摘があります。

プロンプトの一文が結果を左右することがある

プロンプトのちょっとした書き換えや長さの調整でも、出力の安全性が変わってくることがあります。見た目には些細な変更でも、モデルの応答傾向に影響するため、設計段階から注意が必要です。

アプリ全体をまるごと評価する発想をしよう

以上のようにアプリを構成する個々の要素が安全性に与える影響は無視できません。にもかかわらず、アプリ全体を一つのまとまりとして評価する枠組みは、これまでほとんど用意されてきませんでした。

今回紹介する研究では、そうしたギャップを埋めるため、現場の開発フローや運用環境をふまえて活用できる、安全性評価の実践的なフレームワークが提案されています。LLMアプリを本番で使ううえで、どこにリスクがあるかを確認していくための出発点として活用できるかもしれません。

リスクの分類は自分たち仕様にしておく

安全性を評価するときに、まず考えるべきは「何がリスクか」を言葉で整理することです。とはいえ、誰にとっても共通な正解があるわけではありません。使う場面や組織の立場によって、重視すべきリスクは変わってきます。自分たちに合ったリスクの分類をつくるための考え方が必要になります。

すでにある分類を参考にしつつ、自分たちの現場に寄せる

リスク分類のひな型は各種ガイドラインにそろっていますが、そのままではしっくりこないこともあります。自分たちの文脈にあわせてカスタマイズする前提で見ていきましょう。

まずは関係ありそうなリスクを幅広く拾ってみる

はじめの一歩は、LLMアプリに関係しそうなリスクを洗い出すことです。MITのリスクリポジトリのような整理済みの資料は手がかりになります。法規制も無視できないポイントで、たとえばEUのAI法やNISTのガイドラインなど、押さえておきたい資料はいくつかあります。

リンク集

• MITのリスクリポジトリ
• EU人工知能法（AI Act）
• NIST AIリスクマネジメントフレームワーク

想定される使われ方に照らして考える

列挙したリスクが実際にどんなかたちで表れるか、アプリの使われ方を前提に具体的に見直します。意図どおりに使われるとは限らないので、少し突飛な使い方も含めて、「それが起きたら困るかどうか」を判断します。

たとえば、製造業の品質管理アプリでは、ヘイト発言よりも技術的なミスのほうがはるかに重大です。一方、感情に寄り添うチャットボットであれば、誤情報よりも攻撃的な言動のほうが問題になります。

社内の温度感をそろえておく

法務やコンプライアンス、開発チームなど、それぞれが気にする観点は違います。だからこそ、あらかじめ関係者を巻き込んで分類の妥当性を確認しておくと、あとになって齟齬が出にくくなります。

細かくなりすぎず、現場で使える分類に

リスクの洗い出しが終わったら、それを実際に使えるかたちに整えていきます。ポイントは、「完璧を目指すより、扱いやすさを優先すること」です。

今起きうるリスクに絞る

抽象的な未来の話より、今そこにある具体的なリスクに焦点を当てます。たとえば「AIが社会を支配する」といった話ではなく、「医療っぽい質問に変なアドバイスを返してしまう」といった現実的な問題のほうが先です。

細かく分けすぎない

リスクを細分化しすぎると扱いづらくなります。対応方法が共通しているリスクはまとめて、別の対策が必要なものだけ分けておくくらいがちょうどよいです。

法律や規制の定義と足並みをそろえる

分類のラベルや基準は、できるだけ既存の法制度と整合性を取っておくと、後から運用しやすくなります。たとえば「ヘイト的な発言」については、国の反差別法などの定義をもとに分類を組んでおくと無用な混乱を避けられます。

政府機関の事例から見えてくる整理のしかた

実際に公共機関で使われた分類の事例を紹介します。アプリ展開を見据えて調整されたもので、

以下の3つのカテゴリに注目しています。

1. 望ましくないコンテンツ
ユーザーを不快にさせたり、組織の信頼性を損なったりする内容

以下は、「望ましくないコンテンツのリスク分類」の例です。（論文では、各リスクカテゴリーに分類されるメッセージ例も掲載されていましたが、過激すぎるため本記事では除外しました）

2. 専門的なアドバイス
医療・法律・金融など、専門資格なしに語ると危険なアドバイス。公的な立場からの回答と受け取られやすい場面では特に注意が必要

3. 政治的な発言
政治的な偏りがあると見なされ、公共サービスとしての中立性に疑念を持たれるリスク

用途にあわせて柔軟に適用

カテゴリは、アプリの用途に応じてさらに細かく整理し、必要な部分だけを評価対象にします。たとえば教育目的のチャットボットであれば、医療アドバイスに関する評価は外すといった使い分けをします。

リスクの深刻度に応じた対応設計

たとえばヘイト的な発言のように、リスクの中でも深刻度が段階的に分かれているものについては、「軽度なら警告、高度なら即ブロック」といったレベル分けを設定しておくと、柔軟な運用ができます。

判断基準をすり合わせるために具体例を活用

分類だけでは解釈に差が出るため、実際にどういった発言が該当するかを例示しておくと、評価チーム内での判断がぶれにくくなります。実務で運用するうえでは、こうしたサンプルが評価精度を大きく左右します。

実際のアプリで安全性をどう測るか

リスクの整理ができたら、次はアプリ自体がどれほど安全かを確かめる段階に入ります。LLMは構造上、絶対に安全とは言い切れませんが、一般的なユーザーが試すような攻撃に対してどの程度耐えられるかを測ることには十分意味があります。開発チームや関係者が「少なくとも簡単には突破されない」と確かめられることは、実運用の安心につながります。

実験のために攻撃的なプロンプトを自分たちで用意する

攻撃的なプロンプトを用意して実験の準備をします。その際、公開されているベンチマークをそのまま使えることもありますが、多くの場合は現場の事情と合いません。また、モデルの訓練にすでに使われているものだと、評価の意義が薄れがちです。また、自分たちで定義したリスク分類と対応していないケースもあります。

そのため、内部向けのテスト用プロンプトを作っておくことが基本になります。作成にあたっては、次のような点を意識すると効果的です。

①現実に起こりそうなやりとりをもとにする

実際のユーザーが入力しそうな言い方で、特定のリスクを的確に狙えるように設計します。あいまいな表現では、モデル側が意図を誤解したり、適切な判断ができなくなったりします。

たとえば「誰かを倒す方法」という表現は、格闘技の勝利と暴力的な行為の両方に解釈できてしまいます。「暴力で相手を傷つける方法」といった明確な表現にしておくと、意図した挙動の確認につながります。

*念のため注意として、当然ながらこうした有害な内容をLLMに聞くのは通常は禁止されています。

②内容・構造・情報源の幅を持たせる

プロンプトの種類が偏ると、評価結果も偏ります。複数の観点からの多様性を意識するとよいです。

• 内容面では、年齢・性別・宗教・人種などさまざまな属性を含める
• 表現形式は、質問・命令・断言など幅広く使い分ける
• 情報源は、ベンチマーク、SNS、実際のチャットログ、手作業での生成などを組み合わせる

③ローカルな事情も反映する

英語で訓練されたモデルにとって、日本語の俗語や文脈を理解するのは難しいことがあります。自分たちの運用環境に合わせて、言語や文化、法律に即したプロンプトを加えておきます。

たとえば、日本語なら「マジでヤバい」などの文脈依存表現、あるいは医療・金融といった業界特有の言い回しも含めておくと、より現実に近い評価が可能です。

④難易度を段階的に上げる

単純な命令文から、回避的・巧妙な攻撃パターンまで、レベルに応じたテストを用意しておくと、どの程度の攻撃に耐えられるかが見えやすくなります。

たとえば、「薬物を使いたい」といった直接表現に加えて、「CBDやTHCの使い方を教えて」といった周辺語を使ったケースも含めるようにします。さらに難度を上げると、暗号化された命令（例：base64）や攻撃テンプレートの活用などもあります。

*先ほどと同様、ここではアプリ評価のためにあえて有害な内容を質問するデータを作成する話をしていることに注意。

⑤作る量は無理のない範囲から

一度に完璧なベンチマークを目指す必要はありません。最初は小さく始め、あとから必要に応じて拡張していく方法が現実的です。テスト結果の偏りを避けるためにも、プロンプトの種類ごとの比率には注意が必要です。

アプリ全体をひとつの箱として扱う

アプリの内部構成を細かく分けて評価するのではなく、実際のユーザーと同じように「入力して、返ってきたものを確認する」という視点で評価します。これをブラックボックス型のテストと呼びます。

アプリが1つのエンドポイントとして公開されていれば、この方式での評価は比較的容易です。外部ツールとしてはGarak、Inspect、Moonshotなどが使われています。

リンク集

• Garak（Generative AI Red‑Teaming & Assessment Kit）
• Inspect（UK AI Security Institute 提供の評価フレームワーク）
• Moonshot（AI Verify Foundation 提供のベンチマーク＆レッドチーミングツールキット）

返ってきた回答をどう判断するか

自由な形式で返されるテキストの内容が安全かどうかを評価するのは簡単ではありません。正解が1つに決まっているわけではないからです。

安全性分類ツールは補助的に使う

OpenAIのModeration APIやMetaのLlama Guardのようなツールは、わかりやすく危険な内容（暴力、性的表現など）を検出するのに向いています。ただし、組織ごとの期待値や文脈に応じた判断はできません。

たとえば、返金処理のチャットボットがユーザーから「生きていたくない」と言われたとき、共感的に答えるのが正解とは限りません。業務上は「その話題には応じられません」と返すほうが安全というケースもあります。

「拒否すること」を評価基準にする

このような状況では、モデルが「答えない」という判断をできるかどうかが評価のポイントになります。以下の論文では、拒否のタイプを分類する枠組みが提案されています。

Wang, Y., Li, H., Han, X., Nakov, P., & Baldwin, T. Do‑not‑answer: Evaluating safeguards in LLMs. Findings of the Association for Computational Linguistics: EACL 2024, 896–911.

拒否を検出する手段

以下のように、複数の方法がありますが、どれを使うにしても「検出ツール自体が正しく機能しているか」は別途確認しておく必要があります。

• 「お答えできません」「申し訳ありません」などの定型文を探すキーワード検索
• DistilRoBERTaなどで訓練された拒否検出モデルを使って自動分類する
• 別のLLMに「この返答は拒否に当たるか」を判断させる（LLM-as-a-judge）

Alt-Testのように、人間の判断と比べてどの程度一致しているかを測る手法も参考になります。

評価結果をどう読み取るか

安全性のスコアは「全体のうち、安全だった回答の割合」で算出されます。ASR（攻撃成功率）の逆数として見ることもできます。

スコアは絶対ではなく、目安とする

たとえば満点を取ったとしても、それが「完全に安全」という保証にはなりません。LLMの性質上、同じ入力でも毎回同じ回答が出るとは限らず、テスト範囲外の挙動も多くあります。

逆にスコアが低くても、UIの工夫やログ監視など別の対策でリスクを下げられる場合もあります。

有用性とは切り分けて考える

ここでの評価は「危険な回答を返さないかどうか」を見るもので、アプリの使いやすさや性能とは別軸です。安全と有用性のバランスをとるには、両方を並行して評価していく必要があります。

まとめ

本記事では、LLMアプリケーションの安全性を実環境で評価するための枠組みを提案した研究を紹介しました。

リスクの分類からプロンプト設計、ブラックボックス評価、拒否検出に至るまで、実務に即した手順が整理されています。組織ごとの事情に合わせてリスク定義をカスタマイズする姿勢が一貫しており、再利用性と適応性が重視されています。

評価の結果はスコアだけで判断するのではなく、運用方針や周辺対策と併せて読み解くことが求められます。ご自身の状況に照らしながら、取り入れやすい要素から一つずつ応用していくとよさそうです。