従来のテストでは通用しない？LLM開発に必要な新しいテスト観点

LLM（大規模言語モデル）を使った開発が広がる中で、テスト工程に悩む現場が増えています。これまでのソフトウェア開発は「入力に対して正しい出力がひとつ決まっている」ことを前提にしてきました。しかし、LLMでは同じ入力でも異なる答えが返ってきたり、必ずしも一つの正解が存在しないケースが多発します。
本記事では、従来のテストが通用しない理由と、LLM開発に必要となる新しいテスト観点を具体的に解説します。

なぜ従来のテストは通用しないのか？

従来のソフトウェア開発では「入力と期待出力が一対一で決まる」ことを前提にしています。しかし、LLM開発ではこの前提が崩れます。

• 出力の確率性：同じ入力でも応答が揺らぐ
• 複数解の存在：必ずしも「正解は一つ」ではない
• バージョン依存性：APIの更新やモデル切り替えで挙動が変化
• プロンプト依存性：入力の文言の違いで結果が激変
• 評価基準の不明確さ：「正しいかどうか」だけでなく「業務に役立つか」も重要

現場では「昨日のテストで通ったのに、今日同じケースで失敗した」といった事象が頻発します。これが従来型の「合否テスト」では対応できない大きな理由です。

LLM開発実務で頻発する落とし穴

筆者が実務で遭遇した失敗例をもとに、注意すべき落とし穴を整理します。

1. 曖昧な期待値
   • 例：FAQ回答で「返品できます」と「返品可能です」の両方が正解なのに、片方しか認めていない。
2. 再現性の低さ
   • APIの更新により同じプロンプトで返答が変化。テスト自動化が破綻する。
3. 非機能要件の盲点
   • 応答時間が1秒から3秒に伸びるだけで業務システムのUXに影響。
4. ユーザ体験依存
   • 正解率が高くても「自然な文章でない」「トーンが不適切」で不満が出る。
5. 評価データ不足
   • 特定ドメイン（例：医療、法律）のテストデータが準備できず、正答率評価が曖昧に。

新しいテスト観点の整理

従来型テストに加えて、LLM開発では以下の観点をチェックリスト化する必要があります。

テスト観点	目的	実施方法の例
出力の多様性	同じ入力に対してどの程度の言い換えやバリエーションが生まれるかを把握し、用途に応じて多様性が過不足ないかを確認する	同じプロンプトを10回以上実行し、出力の違いを収集・分析。言い換え率や情報追加率を算出して適正範囲か判断する
一貫性	同一条件で安定した出力が得られるかを確認し、業務利用に必要な信頼性を担保する	日時や環境を変えて同じ入力を実行しログ比較。API更新ごとにリグレッションテストを実施
応答時間	ユーザーが業務に支障なく使える速度を満たしているかを評価する	大量リクエストで平均応答時間と95パーセンタイルを測定し、SLA基準（例：95%以上が2秒以内）を確認
コスト	API利用料やリソース消費が予算内に収まるかを事前に把握し、運用リスクを防ぐ	入力・出力のトークン数を計測し、想定利用回数で月額試算。1リクエストあたりのコスト上限を設定
セキュリティ	出力や挙動に個人情報漏洩やプロンプトインジェクションなどのリスクが含まれていないかを検証する	テストデータに個人情報を含めず、出力に住所や口座番号形式がないか自動検出。攻撃的プロンプトを試して安全性を確認
ドメイン適合度	回答が業務ドメイン（医療・金融・法務など）の専門知識や要件と整合しているかを評価する	基準回答集を作成し、専門家レビューと突き合わせる。四半期ごとに基準を更新し誤答の有無をチェック

1.出力の多様性

目的の背景
LLMは確率的に出力を生成するため、同じ入力でも異なる文章を返します。この性質は「FAQ回答」では邪魔になりやすい一方、「アイデア発想」では強みになります。つまり、多様性を評価する目的は「用途に応じた出力の幅を確保できているか」を確認することです。

実務上のポイント
多様性が狭すぎると「機械的すぎる回答」、広すぎると「不安定な回答」になります。プロジェクトの利用目的（顧客対応なのか、資料作成支援なのか）を踏まえて、望ましい多様性の範囲を明示的に決めておく必要があります。

2.一貫性

目的の背景
どれだけ優れた出力が得られても、毎回答えが変わってしまうとユーザーは不信感を抱きます。特に契約条件や業務規則のように「毎回同じでなければならない」ケースでは一貫性は必須です。

実務上のポイント
「再現率」を数値化しておき、業務用途なら80%以上を目安に設定すると判断がしやすくなります。API更新やモデル差し替えの影響を受けやすいため、定期的な回帰テストを仕組みに組み込むことが重要です。

3.応答時間

目的の背景
どれほど高精度でも、数秒以上待たされると業務利用の効率が落ちます。顧客チャットでは「2秒以内」、オペレーター支援では「1秒以内」がUXのボーダーラインになるケースもあります。

実務上のポイント
単発テストだけでなく「負荷をかけた状態」で応答時間を計測することが必須です。想定ユーザー数に応じて基準を設定し、システム全体でボトルネックがないかも同時に確認します。

4.コスト

目的の背景
LLMのAPI利用料は従量課金です。出力精度だけに注目していると、気づかないうちに月額コストが数十万〜百万円単位に膨らむリスクがあります。テストの目的は「運用後も持続可能なコスト水準かどうか」を確認することです。

実務上のポイント
1リクエストあたりのコストを計測し、利用頻度をかけ算して月額予測を算出。PoC段階からこの試算を組み込んでおけば、リリース後の「赤字運用」を防げます。

5.セキュリティ

目的の背景
LLMは入力や出力に意図しない情報を含める場合があります。たとえば、テスト中に個人情報が混入したり、プロンプトインジェクション攻撃で内部設定が漏れる可能性があります。目的は「セキュリティリスクを事前に検出すること」です。

実務上のポイント
通常の機能テストとは別に「悪意ある入力」をテストケースに含めることが重要です。情報漏洩防止の自動検出ツールを活用し、セキュリティレビューと併せて検証することで安心して運用できます。

6.ドメイン適合度

目的の背景
一般的な知識としては正しくても、医療や金融、法律などの専門領域では誤答が大きなリスクにつながります。目的は「出力がその業務ドメインに本当に適合しているか」を評価することです。

実務上のポイント
業務専門家によるレビューを必ず組み込み、「基準回答集」を用意して照合するのが基本です。正答率だけでなく「致命的な誤答がゼロ」であることを合格ラインに設定することが望ましいです。

実践的なテスト手順例

実務で導入可能なテストフローを紹介します。

1.期待値を「範囲」で定義する

目的
LLMは表現が揺らぐため、従来の「完全一致」ではテストが破綻する。

実施方法

• 回答候補を「同義表現グループ」としてまとめ、合格範囲を定義する
• 例：「返品できます」「返品可能です」「7日以内なら返品できます」を同一カテゴリに含める
• これをテストデータベースに登録し、自動判定時に参照できるようにする

実務での注意点
あいまいに範囲を広げすぎると「誤答を許容」してしまうため、専門家とQA担当がペアで定義するのが望ましい

2.ログ収集とスコアリング基盤を作る

目的
出力の揺らぎや精度を長期的に数値で監視するため

実施方法

• APIリクエストと出力をすべてログDBに保存（例：BigQuery, Elasticsearch）
• そこにスコアリング関数を走らせる（例：BLEUスコア、ROUGE、正解候補とのマッチ率）
• 結果をダッシュボードで可視化（Grafana, Kibanaなど）

実務での注意点
出力サンプルを残さないと「なぜ精度が下がったのか」が追えない。必ず原文とスコア両方を記録すること

3.人手評価を組み込む

目的
自動スコアだけでは拾えない「文の自然さ」「業務に合っているか」を担保する

実施方法

• 週次でランダムサンプル（例：全出力の5%）を抽出
• 3人以上でクロスレビューし、合議制で合否判定
• 評価基準は「業務要件適合度」「自然さ」「禁止ワード混入」などをスコア表にまとめる

実務での注意点
評価者が疲れると精度が落ちるため、1回のレビューは1時間以内＋インターバルを設けるのがベスト

4.非機能要件を自動監視する

目的
遅延やコストは後から気づくと手遅れになるため、リアルタイム監視が必要

実施方法

• 応答時間（p95・p99）をメトリクス化してCloud MonitoringやDatadogで可視化
• API利用コストを試算し、月次予算と比較
• 異常値検知アラートを設定（例：応答時間が3秒超過、月額予算を80%消費時に通知）

実務での注意点
UXは「平均応答時間」ではなく「最悪値」で評価すること。ユーザーは遅い1回で不満を抱く

5.リリース前のユーザテストを実施する

目的
開発チームが想定していないシナリオで、ユーザー体験を実際に確認するため

実施方法

• 想定業務フローをユーザーに実際に操作してもらう
• ヒートマップや操作ログを収集し、どこで躓いたか分析
• 定性調査（インタビュー）で「納得感」「安心感」も確認

実務での注意点
内部関係者だけでなく、実際の利用者層（現場オペレーター、顧客担当）を必ず含めること