「動く」から「使える」へ昇華させる品質評価とテスト
システムの評価やテストは、単に開発初期のバグを防ぐためだけのものではありません。システムが「仕様通りに正しく動くか」という基礎品質の保証や、モデルの性能向上につなげる役割も果たします。またリリース後も社会的なリスクや性能の劣化がないかを継続的に監視するという、運用保守においても必要な観点です。
評価軸の分解：「頭の良さ」と「仕事ができるか」
ソフトウェアの品質特性はISO/IEC 25010で定義されていますが、AIエージェントの能力を評価する際の一つの見方として「頭の良さ（基礎能力）」と「仕事ができるか（実行能力）」の二つに分解して考えるアプローチが有効です。
頭の良さ（基礎能力）
推論や説明の正確さといった「出力品質」や、必要な情報やツールを適切に選択できているかという「知識・ツール活用の適切さ」を指します。これは主にLLMそのものの性能や、プロンプトによる指示の適切さに依存する能力です。
仕事ができるか（実行能力）
タスクを効率的・安定的・安全に遂行できるかという「実用性」の観点です。処理時間やタスク成功率といった「パフォーマンス」、そして出力の安全性や信頼性（ガードレールが機能しているか）などがここに含まれます。
正解が一意に定まるタスクの評価（分類・抽出など）
AIの評価としてまず考えられるのは、入力に対して正解が一意に決定する場合の評価です。例えば分類タスクの場合は、入力文を事前に定義されたカテゴリに分類します。このときの出力は定義されたカテゴリに限定されるため、評価データセットを用いた定量評価を行うことができます。
この場合、評価データセットの構築が重要になります。簡単なタスク設定のみで評価データセットを構築すると性能が過大評価されてしまいます。効果的なテストデータセットを構築するためには、以下のようなサンプリング戦略が有効となります。
- 層化サンプリング：ユーザーの属性や利用シーン、タスクの種類など、重要なカテゴリごとにバランスよくサンプルを抽出します。
- 多様性サンプリング：入力パターンの多様性を最大化するようにサンプルを選択します。幅広いデータを採用することで、システムの汎化性能を測ります。
- 不確実性サンプリング：モデルが判断に迷いやすいケースを優先的に選択します。これにより、システムの弱点を効率的に発見します。
評価手段は多様ですが、OpenAI Evals, Weave, DeepEval, Ragasなどを使うと評価セットの作成や管理ができます。
from deepeval.test_case import LLMTestCase
from deepeval.metrics import AnswerRelevancyMetric
answer_relevancy_metric = AnswerRelevancyMetric()
test_case = LLMTestCase(
input="日本の現在の総理大臣は誰ですか？",
actual_output="高市早苗",
retrieval_context=["第104代内閣総理大臣に高市早苗議員が指名されました"]
)
answer_relevancy_metric.measure(test_case)
print(answer_relevancy_metric.score)
正解が一意でないタスクの評価（生成・対話など）
「こんにちは」という挨拶に対する応答の正解がないように、生成タスクの場合は入力と正解の関係が「1対他」の関係になります。この場合は正解の判定が難しく、またオラクルを用いた評価データセットの構築も困難となります。
下位特性を考慮した評価観点の選定
このようなケースでは、プロパティベースのテスト（要約タスクでは、入力トークン数＞出力トークン数が保証される）や、LLM を用いた判定（LLM-as-a-Judge）が採用されます。
特にLLM-as-a-Judgeを採用する場合、どのような観点で評価を行うかが重要なポイントとなります。評価観点を考慮する場合は、以下のように複数の候補をMECEに列挙した上で、ビジネスインパクトのある観点を優先的に選定します。
評価観点を採用すると、LLMに判断させるための採点基準を定義します。以下の例ではリッカート尺度による5段階評価の例を示しています。
多様な入力に対する汎用性・堅牢性のテスト
開発初期段階の場合、生成タスクでは本番で想定される入力データを十分に確保することが難しいというコールドスタート問題があります。またプロンプトの一部をユーザーに管理させるような運用を行なっているシステムの場合は、プロンプトの記述自体が属人化してしまい、開発者の意図しない応答が生成されてしまう問題もあります。モンキーテストによる堅牢性のテストも有効ですが、ここでは「メタモルフィックテスト」について紹介します。
メタモルフィックテストは、入力データに対して摂動を加えると出力がどう変化するか予想できる「メタモルフィック関係」を考慮します。商品推薦タスクの場合、推薦結果がわかっているときに1位の商品を入力データから削除すると、出力結果は2位以降のくり上げとなるはずというメタモルフィック関係を考慮できます。
以下の例では①完全性 ②魅力性 ③忠実性という三つの大項目について、それぞれ実行可能な摂動を定義しています。実際にテストを行う際は、これらの摂動に基づいてサンプルを作成します。
敵対的な入力に対する脆弱性チェック
安全な稼働を保証するためには、タスク仕様にもとづいた応答品質を保証するだけでなく、LLM出力における脆弱性や敵対的指示に対する防御策を講じる必要があります。チャット形式のようなアプリケーションの場合、ユーザーから自由形式のテキストを入力させる場合があるため、特にプロンプトインジェクションのようなリスクに対応する必要があります。
コンテンツモデレーションについては、OpenAI Moderation API、Perspective API、Azure AI Content Safety、といった枠組みを採用することができます。
from openai import OpenAI client = OpenAI() response = client.moderations.create( model="omni-moderation-latest", input="...確認対象となる文章", )
おわりに
本記事では、不確実性の高いAIエージェント開発において、いかに「当たり前品質」を担保し、ビジネス価値につなげるかを解説しました。
実用化の鍵は、魔法のような技術ではなく、プロンプト調整やロジック分離といった「地道なルール作り」と「泥臭い改善」の積み重ねにあります。これらエンジニアリングの工夫こそが、AIの「賢さ」を「信頼できる仕事能力」へと昇華させることができます。
AIエージェントは作って終わりではなく、現場からのフィードバックを受けて「育てていく」ものです。経営層と現場、開発者が一体となり、小さな改善サイクルを回し続けること。その先にこそ、PoCの壁を超えた真の活用があります。本記事がその挑戦の一助となれば幸いです。
