【セッションレポート】責任ある AI に向けて: 生成 AI アプリケーション評価のアプローチ（AWS-52） #AWSSummit

AWS Summit Japan 2025 の Day2 で発表された以下のセッションのレポート記事です。
責任ある AI に向けて: 生成 AI アプリケーション評価のアプローチ（AWS-52）

セッションの概要

基盤モデルの技術進歩に伴い、RAG や AI エージェントに代表されるような生成 AI をアプリケーションに組み込んで活用するユースケースが広がりを見せています。基盤モデルの力で強力な機能をアプリケーションに簡単に実現できる反面、本番化に際してアプリケーション全体としての精度やリスクをどのように評価するか、悩みを持つ方は多いのではないでしょうか？本セッションでは、生成 AI アプリケーションの評価について、生成 AI ならではの要素を踏まえたベストプラクティスや AWS 上での実現方法について解説します。

※セッションページより引用

セッションレポート

アジェンダ

• 生成AIアプリケーション評価の基本
• 生成AIアプリケーション構成要素の評価方法
• 生成AIアプリケーションのリスク評価
• 機能リリースの信頼性を高めるには

はじめに

• 生成AIにより、これまで不可能だったことが可能になっている。
• しかしそれと同時に、生成AIによる新たなリスクと課題が出現している。
• 従来のAIモデルと現在の基盤モデルの違い
  • 従来：特定のユースケースに特化（例：ローンを承認する？）
  • 現在の基盤モデル：複数のユースケースに対応（例：議事録を作成して）
• さらに、検索エンジンやMCPのような外部との連携により、複雑性は増している。
• 複雑化する中で、品質とアジリティのバランスをどう取っていくか
  • 挙動を過度に分析する→生成AIの良さが失われる
  • チューニング不足でリリース→本番環境でのインシデントリスク
• 責任あるAIを実現するためには
  • 生成AIの品質とリスクに自信を持つために「テストと評価を一貫した方法で行う」ことが重要

生成AIアプリケーションの評価の基本

• 自信を持ってデプロイするために評価戦略を決める
• 決め方の流れ
  • アプリケーションの目的を定義する
  • 求められる精度とリスクを洗い出す
  • これを評価手法に落とし込む
• 責任あるAIを実現するためのフレームワーク
  • 8項目の柱
  • 公平さ、説明可能性、プライバシーとセキュリティ、安全性、制御性、正確性と堅牢性、ガバナンス、透明性
• 評価観点
  • 品質（アプリケーションが期待している以上のパフォーマンスを出しているか）
  • レイテンシ
  • コスト
  • 信頼性（リスクが許容範囲内に収まっているか）

生成AIのこの4つの評価項目のうち、品質と信頼性の2つはLLMの場合だと定性的な評価になってしまう。

パフォーマンス（品質）の評価方法

• 精度とは異なる評価

  • パフォーマンス評価
    • スピードとコスト

• 精度に関する評価

  • 人間による評価は最も身近（手動）
    • →最も品質が高い評価を行えるが、スケールにはエキスパートが必要でスケールしにくい
  • 経験則に基づくメトリクス（自動）
    • コストが低い
    • 人間の評価と一致するか、チューニングが必要
  • AIによる評価（LLM-as-a-judge）
    • 評価観点を伝えてLLMに評価させる方法
    • チェック項目を柔軟にカスタムできる

• スケーラブルな評価を行うには、経験則に基づくメトリクス（自動）とAIによる評価（LLM-as-a-judge）の活用が重要

  • 評価したいメトリクスに応じて、このどちらかを使い分ける判断が重要
  • ただし、どちらにせよ人間による評価と一致しているかという部分は考慮が必要

• 乖離がないかの確認と調整：キャリブレーション

  • 小規模なデータセットを用いて、LLMに評価を行い、乖離がないかを人間が調査する。
  • 人間の評価によって信頼性を確保する。

• 様々な評価メトリクスがあるが、ユースケースに応じて使い分ける必要がある。

構成要素の評価方法

• LLMそのものについて
  • リーダーボードでモデル候補は探せるが、ユースケースと同じ傾向を示すとは限らない
  • 各モデルを評価して、どれが適しているかを判断する必要がある
  • 自分たちでフィットするモデルを評価する必要がある
• その評価方法の1つにBedrock モデル評価がある
  • カスタマイズしたモデルやインポートしたモデルに対しても評価が可能
  • 様々な評価メトリクスがある
• SageMaker AI の基盤モデル評価
  • fmeval でカスタム評価スクリプトが実装可能
• これらのモデル評価の方法
  • まずは用意されたメトリクスやデータセットを活用して評価
  • 独自のデータセットは必須ではないが使用推奨
    • 公開されたデータセットをモデルが学習しており「答えをすでに知ってしまっている」という可能性がある
    • タスクに特化したデータセットが最も有用なメトリクスとなる。
• LLM-as-a-judgeのメトリクス
  • 12個のメトリクスがある
  • LLMプロンプトがすでに用意されているため、チューニングしなくても使い始めることができる

RAGの評価方法

• 評価の前段に検索が加わっていることが特徴
• Bedrock にも、Knowledge Base 全体を評価する方法がある
  • 検索 or 検索+生成を、LLM-as-a-judge で評価できる。
• 組み込みメトリクスでは評価できない場合
  • Ragas のようなRAGを評価するOSSのツールがある。
  • 組み込みメトリクスなどで評価した上で、カスタマイズしたい場合にこういったOSS評価ツールを使うのも良い

エージェントの評価

• 各コンポーネントの評価が重要（コンポーネントが多いため）
• 複数ターンからなる会話を評価する必要がある
  • さらにこれを定量的に評価する必要がある
• AWS Labs による agent-evaluation フレームワークによる方法
  • テストケースをyamlで記述し、CI/CDでテスト実行
  • 会話が成立しているか、という部分を評価
  • 中身は LLM-as-a-judge

リスク評価と、リリースの信頼性を高めるには

• ユースケースの特定
  • 例えば、楽曲レコメンドと、X線の腫瘍検出を比較した場合
  • どちらもエラーレート1%でも、レコメンドはOK、腫瘍検知ではNG
  • ユースケースによって、リスクの前提基準は大きく異なる
• リスクを洗い出すことが重要
  • 8つの柱によって洗い出す
• リスク評価とは
  • リスクが発生する確率 × リスクイベントが発生した場合の影響
  • →これがリスク評価
  • リスク評価マトリクスを使用
    • 発生可能性と影響度それぞれ5段階で評価し、マトリクスで確認
    • 発生確率が高くても、影響が低ければ Low のような評価
    • 一方確率が低くても影響が甚大であれば High のような評価
  • 「影響」のウェイトが大きい
• メトリクスを選定する
  • 安全性(有害コンテンツの生成割合)の場合。
    • 安全なコンテンツと生成コンテンツの差分を評価する（曖昧）
    • 許容される最大値を下回っているかどうか（下回っていればOKと判断）
• リリース基準を、コンテンツの生成割合がマトリクスのどこにあるのか、というのを意識する。
  • Midium までは許容できるのか、 Very low じゃないと許容できないのか
• 評価方法は、パフォーマンスと同様にノーコードで実現可能

結果解釈

• 結果評価を解釈する
  • 評価結果だけ見たら超えていなくても、実際は超える可能性がある。
  • 実際の生成は、点ではなく分布になっていることを意識する必要がある。
  • 片側信頼区間を推定し、評価結果の不確実性を考慮する。
  • ライブラリを用いたりすることで信頼区間を推定できる。

緩和戦略

• Bedrock Guardrails
  • 入力/出力をフィルタすることで、インシデントなどの問題が起きるリスクを抑制できる
  • 拒否トピックの設定や、PIIをマスキングしたりといったフィルタもある。
  • つい先日のアップデートで、フィルタが日本語対応。

最後に

さらに詳しく知りたい場合は、AWSの「責任あるAI」のページを参照ください。
責任ある AI - AWS で責任を持って AI を構築する - AWS

感想

LLMの急激な発達により、企業でも競争力の確保のためにプロダクトに組み込むような動きが出てきています。しかし、その中でリスクは常に付きまといます。
どのようなアプローチでリスクを抑制しつつ、スケーラブル評価を行ってアジリティも確保していくかという考え方・対応方法は、すべてのAI活用企業で活用できる知見と感じました。
また、AIによるリスクの整理や捉え方についてはセキュリティリスクと同様の考え方が活用できることも1つの気づきでした。AI自体は新たな技術ですが、それに対して既存の知識やノウハウも活かしながら取り組んでいくことも重要であるということを強く認識できました。