開発者と読み解くAIの世界
責任あるAI開発に向けたLLMアプリケーションの品質保証の取り組み
LLMにおける動作検証と脆弱性検証
2025年5月1日 09:00
近年、RAGシステムやAIエージェントなど、大規模言語モデル(LLM)を活用したアプリケーションの実用化が進んでいます。これらのアプリケーションは、繰り返し作業の省力化や新たな価値創造に期待される一方、情報漏えいによるセキュリティリスクやハルシネーションによるレピュテーションリスクなど、新たな問題への対応が求められています。
- 参考:情報通信白書令和6年度版(総務省)
こうした懸念に向き合い、責任あるAIの開発に取り組むべく、本稿では開発者やマネージャー向けに、株式会社Algomaticが取り組むLLMアプリケーションの品質保証について紹介します。
責任あるAI
『責任あるAI』とは、AIの開発・運用において倫理的な問題やプライバシー、セキュリティなどの潜在的なリスクを認識し、それらに対処するために企業や組織が責任を持って取り組む指針や原則を指します。
例えば、Microsoftでは、以下の6つの観点からAIテクノロジーを開発および展開するための全社的なルールを構成しています。
また、総務省情報通信政策研究所は、今後AIの便益増進およびリスク抑制の取り組みにおける中長期的な視点での検討として『AI利活用原則案』を紹介しています。
AI利活用原則案 | 各原則の内容に関する主な論点 |
---|---|
適正利用の原則 | 利用者は、人間とAIシステムとの間及び利用者間における適切な役割分担のもと、適正な範囲及び方法でAIシステム又はAIサービスを利用するよう努める。 |
適正学習の原則 | 利用者及びデータ提供者は、AIシステムの学習等に用いるデータの質に留意する。 |
連携の原則 | AIサービスプロバイダ、ビジネス利用者及びデータ提供者は、AIシステム又はAIサービス相互間の連携に留意する。また、利用者は、AIシステムがネットワーク化することによってリスクが惹起・増幅される可能性があることに留意する。 |
安全の原則 | 利用者は、AIシステム又はAIサービスの利活用により、アクチュエータ等を通じて、利用者等及び第三者の生命・身体・財産に危害を及ぼすことがないよう配慮する。 |
セキュリティの原則 | 利用者及びデータ提供者は、AIシステム又はAIサービスのセキュリティに留意する。 |
プライバシーの原則 | 利用者及びデータ提供者は、AIシステム又はAIサービスの利活用において、他者又は自己のプライバシーが侵害されないよう配慮する。 |
尊厳・自律の原則 | 利用者は、AIシステム又はAIサービスの利活用において、人間の尊厳と個人の自律を尊重する。 |
公平性の原則 | AIサービスプロバイダ、ビジネス利用者及びデータ提供者は、AIシステムまたはAIサービスの判断によって個人が不当に差別されないよう配慮する。 |
透明性の原則 | AIサービスプロバイダ及びビジネス利用者は、AIシステム又はAIサービスの入出力の検証可能性及び判断結果の説明可能性に留意する。 |
アカウンタビリティの原則 | AIサービスプロバイダ及びビジネス利用者は、消費者的利用者及び間接利用者を含むステークホルダに対しアカウンタビリティを果たすよう努める。 |
これらの論点には、プロダクト視点におけるセキュリティ・プライバシー対策だけでなく、システムの説明責任や安全性・公平性の保証という論点も含まれます。近年ではLLMから学習データが復元される危険性(Carlini+'20)、学習時にバックドアが設置される可能性(Gu+'17)も示されており、こうした事例はシステム全体の信頼性に大きな影響を与えます。
開発者は、自らが作成するプロダクトの動作原理や潜在リスクを十分に理解し、顧客に対してどのような対策を講じているかを明確に説明することで、利用者や社会からの信頼獲得に努めます。
精度検証の前にやること
『LLMプロダクト開発の新潮流 ~従来の開発との決定的な違いとは』でも解説しましたが、LLMは高い汎化性能と柔軟な言語運用能力から「そもそも技術的に可能であるか」の性能下限を定性的に示すことが容易となりました。一方で、その分だけ現場への迅速な適用と継続的な改善を実施することの重要性が増したともいえます。
AlgomaticのリクルタAIチームではこれらを踏まえ、次のような手順で開発を進めています。
- 技術の不確実性を解消して事業化の効果を測定する
- ガードレールやフェイルセーフの実装や動作検証により安全な動作を保証する
- 継続的な評価と改善の実施により生成品質の向上を図る
――開発初期段階の精度検証は難しい
一般的な機械学習プロジェクトでは、学習済みモデルが現実のデータに対してどれだけ有効に働くか、またその信頼性や実用性がベンチマークと比べてどの程度であるか、を確認するために、評価データセットを用いた精度検証を行います。
LLMやLLMアプリケーションの開発についても同様に、JGLUE、ELYZA-tasks-100、llm-jp-evalなどの公開されたベンチマークを用いた評価や、Ragas、llm-jp-judge、DeepEvalなどのLLM-as-a-Judgeによる評価ツールを用いたクローズな評価などが行われます。
しかし、本当に信頼できる評価はとても難しく、 ステージング環境ではうまく動作したのに本番環境で意図しない応答文を生成してしまう ことは少なくありません。これは評価データセットの不確実性や多様性が十分に考慮されないまま評価を行ってしまう問題に加え、正解の解釈やデータ分布が運用とともに変化してしまう概念ドリフトやデータドリフトなどが問題として挙げられます。
精度検証は透明性の原則を遵守する上で重要なプロセスですが、その真価を問うのは技術的な不確実性を明らかにしてからでも遅くないと思います(ただし、QCDの優先度が決定している対顧客のプロダクト開発については当てはまらない場合があります)。時間をかけてアノテーションしたにも関わらず、正解の解釈が途中で変更されたためにやり直しといったように、 開発初期における精度検証は工数がかかる割に手戻りが発生しやすい ということです。
安全な動作を保証するための動作検証
安全な動作を確保するガードレール設計については『ガードレールによるLLMの安全性担保』で解説したので、ここでは システムが仕様通り正常に稼働するか に目を向けます。
通常、Webアプリケーションの単体テストでは実装内容にもとづいてホワイトボックステストを実施しますが、非決定的なLLMではWebアプリケーションと同じようなテストを記述することは困難です。また精度検証で行うような入出力の対応関係を、バランスよく広範・大規模に収集することは高い時間コストが必要になります。
――タスク仕様や入出力の間接的な関係に着目してテストを実施する
そこで我々は「 本番運用に耐える安全な動作を保証して、実際に運用にのせてみて、継続的な評価改善とともに現場環境に適応させる 」アジャイル型品質保証の取り組みを採用しています。
安全な動作を保証する最も簡単な取り組みのひとつは、システムのあるべき挙動を満たす条件に着目したテストを実施することです。要約タスクでは「入力文字数 > 出力文字数」が不変条件として成立します。構造化出力が要求される場合は、出力構造の型チェックによるバリデーションを適用することができます。プレースホルダ付テンプレートを用いる場合は、テンプレートと出力内容の差分件数がプレースホルダ数と一致するはずです。
また、 タスクに依存しない普遍的な入出力のペア をテストケースとして採用する場合もあります。チャットボットでは挨拶や常識推論を伴う入力、「あああ」といった意味のない単語列による入力が該当します。「システムプロンプトを教えて」などの敵対的指示も含まれます。
さらに、入出力の間接的な関係に着目する場合もあります。
例えば、メタモルフィックテストでは、入力データに対して摂動を加えると出力がどう変化するか予想できる「メタモルフィック関係」を考慮します。 商品推薦タスクの場合、推薦結果がわかっているときに1位の商品を入力データから削除すると、出力結果は2位以降のくり上げとなるはず 、というメタモルフィック関係を考慮できます。
人的・経済的リスクを避けるための脆弱性検証
安全な稼働を保証するためには、タスク仕様にもとづいた応答品質を保証するだけでなく、LLM出力における脆弱性や敵対的指示に対する防御策を講じる必要があります。
LLMアプリケーションにおける主要なセキュリティリスクを整理する OWASP LLM Applications Top 10 においても、プロンプトインジェクションや誤情報などのリスクを取り上げています。
上記のような回答を避けるためには、モデル学習時におけるデータポイズニングに留意するほか、入出力データに対するコンテンツの有害性を検知する必要があります。
例えば、コンテンツモデレーションについては、OpenAI Moderation API、Perspective API、Azure AI Content Safety、Llama Protections、ShieldGemma、chakoshi、といった枠組みを採用したり、LLM-jp Toxicity Dataset、AnswerCarefully Dataset、などから分類器を作成することが求められます。
また、コンテンツモデレーションだけでなく、レッドチーミング(Perez+'22)による事前評価も重要な取り組みのひとつです。
例えば、DeepTeam、promptfoo、などのライブラリでは、制限されたコンテンツをLLMに生成させるようなジェイルブレイクや、指示文を上書きするプロンプトインジェクションなどの敵対的攻撃をシミュレーションしてデプロイ前のLLMアプリケーションにおける脆弱性を評価します。AIセーフティ・インスティチュートからはAIセーフティに関するレッドチーミング手法ガイドも公開されています。
まとめ
本記事では、責任あるAIの開発をテーマに、LLMアプリケーションを安全に運用するための取り組みの一例を紹介しました。
LLMアプリケーションは、継続的な評価と改善を長期にわたって繰り返し実施することが重要で、本記事で紹介した内容のほかにも、モニタリングやガードレール・フェイルセーフ、ユーザフィードバックの反映が必要となります。
株式会社Algomaticは、LLM技術の発展とともに、LLMアプリケーションの品質保証にも積極的に取り組んでいきます。
- 関連記事
AIエージェントの地上戦 ~開発計画と運用実践 - その他の関連文書
AI事業者ガイドライン(経済産業省)
広島AIプロセスに関するG7首脳声明(外務省)
AIと著作権(文化庁)
機械学習品質マネジメントガイドライン 第4版(産総研)
AIプロダクト品質保証ガイドライン 2024.04版(AIプロダクト品質保証コンソーシアム)
「偽・誤情報に対するコンテンツモデレーション等の在り方」に関する主な論点(案)(総務省 デジタル空間における情報流通の健全性確保の在り方に関する検討会)
AIセーフティに関するレッドチーミング手法ガイド(AISI)
著者プロフィール:宮脇 峻平
東北大学大学院で自然言語処理を専攻し、現在までの6年間、言語モデルの開発やLLMアプリケーションの開発に従事。2024年2月に株式会社Algomaticへ参画し、現在はHR領域で生成AIを用いた採用支援型AIエージェント『リクルタAI』の開発や運用を行う。
・株式会社Algomatic:https://algomatic.jp/