LLM機能の要件と評価指標を決める方法

LLM機能の要件は、「良い回答を返す」だけでは決まりません。用途、失敗例、テストケース、評価指標、評価器（grader）、不合格時の代替動作（fallback）、再評価を始める条件を一つの仕様にまとめます。

LLMの試作品を本番機能へ移したいプロダクト責任者と開発者向けです。対象となる作業と利用者が決まっていることを前提にしています。特定サービスの評価基盤を実装する方法や、すべての用途に共通する合格値は扱いません。

コピーして使える評価仕様

機能名:
対象作業:
現行手順:
非AI代替:
LLMを使う理由:
必要な改善幅:
利用者:
利用環境:
出力の使われ方:
対象外:
失敗すると誰に何が起きるか:
人が確認する場所:
入力データ区分:
プロバイダーの保持・学習利用・アクセス条件:

評価データ:
- 通常ケース:
- 境界ケース:
- 敵対的ケース:
- 拒否・引継ぎケース:

評価指標:
- 品質:
- 安全性:
- 個人情報保護:
- 応答時間:
- コスト:

利用プロバイダー・モデル:
レート制限:
再試行するエラー・間隔・上限:
プロバイダー障害時の縮退運転:
切り戻し条件・手順:
アラート条件:
エスカレーション責任者:

評価器:
合格閾値:
即時停止条件:
代替動作:
本番監視:
再評価を始める条件:
責任者:

通常の期待値比較だけでは足りない理由

生成AIは、同じ入力でも出力が変わる場合があります。そのため、一つの期待文と完全に一致するかを見るだけでは、用途全体の性能を測れません。OpenAIの評価に関するベストプラクティス（2026年8月17日確認）は、実際の用途を代表する入力例と評価器を使い、評価手順を構造化する方法を説明しています。ここでは方法論だけを参照し、特定の旧評価基盤を勧めるものではありません。

従来型のソフトウェアテストが不要になるわけでもありません。認証、権限、データベース更新、スキーマ、料金計算などは通常のテストで確認し、LLM出力の品質や安全性を評価で補います。

1. 指標より先に用途を固定する

NIST AI RMF 1.0のMAP機能は、想定用途、利用者、利用環境、知識の限界、出力の使われ方、人による監督などを文書化する枠組みを示しています。特定の用途に限定されない、任意利用の枠組みです。

同じ要約機能でも、用途によって合格条件は変わります。

用途	許容できる補助	許容できない自動化
会議メモの下書き	人が原文と照合	決裁事項の自動確定
問い合わせ返信の候補	担当者が選んで送信	顧客への無確認送信
コードの説明	開発者が差分と照合	権限変更の自動マージ
契約書の検索	原文箇所への案内	法的結論の自動判断

出力を誰がどう使うかが決まると、誤りによる被害と、人が確認する場所を整理できます。

評価仕様には、現行手順と非AIの代替案も残します。検索、ルール、UIの改善で十分なら、LLMを使わない案も候補です。LLMを使う場合は、品質だけでなく所要時間や費用も現行手順と比べ、どこまで改善すれば採用するかを先に決めます。

2. 成功条件を複数の指標に分ける

Anthropicのテストと評価のガイド（2026年8月17日確認）は、成功条件を具体的で測定可能にし、用途に結び付けるよう案内しています。掲載されている指標や数値は例なので、そのまま自社の合格値には使いません。

観点	指標の例	測り方
品質	必須項目の充足率、根拠一致率	判定規則、専門担当者のレビュー
安全性	禁止操作率、適切な拒否率	敵対的ケース
個人情報保護	不要な個人データの出力件数	パターン検査と人の確認
応答時間	応答時間の分布	アプリケーションログ
コスト	作業の成功1件あたりの費用	利用量と合否を組み合わせる
運用	人への引継ぎ成功率	問い合わせ票と作業記録

一つの総合点にまとめると、安全上の失敗が平均に埋もれます。公開を止める指標は、ほかの指標から独立させます。

3. 評価データに実際の入力と失敗例を含める

最初の評価データは、次の四つに分けます。

よくある通常ケース
長い入力、曖昧な入力、データ不足などの境界ケース
プロンプトインジェクション、秘密情報の要求、権限外操作などの敵対的ケース
回答せず、人へ引き継ぐべきケース

実運用ログを使う場合は、利用目的、本人同意の要否、アクセス権、匿名化、保持期間を確認します。合成データだけで実際の入力を置き換えず、業務分野の専門家が正解や許容範囲を確認します。

評価データには、公開情報、社内情報、個人データ、秘密情報など、組織の基準に沿った区分を付けます。プロバイダー側の保持、学習利用、アクセス条件を確認できないデータは評価対象から外すか、組織の担当者へ確認します。入力可否の整理には、生成AIへ入力してよいデータの判断も使えます。

調整に繰り返し使う開発用データと、公開判断のときだけ使う最終判定用データ（holdout set）を分けます。最終判定用データに合わせて調整を続けると、本番で未知の入力にも対応できるか判断しにくくなります。

4. 評価する内容に合わせて評価器を選ぶ

判定対象	向いている評価器	注意点
JSONスキーマ	プログラムによる確認	意味の正しさは別に確認する
必須語・引用箇所	判定規則・参照先との照合	言い換えを考慮する
コードの実行結果	単体テスト・結合テスト	隔離環境で実行する
要約が原文に忠実か	人とLLMによる評価	原文の根拠と照合する
文体・分かりやすさ	人が使う採点基準	評価者間で基準を合わせる
安全な拒否	ケース別の採点基準	過剰な拒否も測る

LLMを評価器に使う場合は、人が付けた判定ラベルとの一致を少数のサンプルで確かめてから対象を広げます。評価に使ったモデル、プロンプト、バージョンも結果と一緒に保存します。

5. 合格閾値と代替動作を対にする

閾値は用途ごとに決めます。品質だけでなく、プロバイダー障害やレート制限が起きたときの動作も公開条件に含めます。

記入例：問い合わせ返信の下書き

次の設定値、試験結果、判定はすべて説明用の架空例です。特定のプロバイダーや用途に対する推奨値ではありません。

対象作業: 公開FAQを根拠に返信の下書きを作る
利用者・利用環境: 問い合わせ担当者5人が社内の管理画面で使う
出力の使われ方: 担当者がFAQの根拠と下書きを確認してから送信する。自動送信はしない
現行手順: 担当者がFAQを検索し、中央値6分で作成
非AI代替: FAQ検索と定型文の絞り込みを改善
LLMを使う理由: 複数のFAQから下書きを組み立てる
必要な改善幅: 作業時間の中央値4分以下、重大な事実誤り0件

入力データ:
- 開発用: 個人情報を含まない合成問い合わせ60件
- 公開判定用: 過去の実入力から氏名・注文番号を除いた20件。データ管理責任者と個人情報保護責任者が、評価目的、30日間の利用、評価担当者3人のアクセスを承認
- 合成データだけで閾値を満たしてもGOにはせず、承認済み実入力サンプルを評価できるまでHOLD

プロバイダー条件: 架空のプロバイダーAの法人APIを使う。契約資料と管理画面で、入力・出力を学習へ使わないこと、保持7日、サービスアカウントと承認済み運用担当者だけがアクセスできることを確認済み。いずれかを確認できなければHOLD
評価データ: 開発用60件。公開判定用holdoutは承認済み実入力20件、境界5件、敵対的5件、引継ぎ5件
評価器: 必須項目と根拠URLは規則で確認し、事実関係と引継ぎ判断は業務担当者2人が確認
合格閾値: 必須項目95%以上、重大な事実誤りと不要な個人データ出力0件、引継ぎ成功100%、p95応答5秒以内、成功1件10円以下

レート制限: 契約上限は毎分100件、想定ピークは毎分60件
再試行: 429とタイムアウトだけを1秒後、2秒後の順で最大2回。同じrequest IDでは下書きを1件だけ保存し、重複送信を防ぐ
縮退運転: 3回連続の失敗、または5分間の失敗率5%超でLLM呼び出しを止め、FAQ検索だけを表示する
切り戻し: 機能フラグを無効にし、現行のFAQ検索と定型文へ戻す
アラート: 5分間の失敗率5%超で開発当番へ通知し、15分以内に応答がなければエスカレーション責任者へ通知する
エスカレーション責任者: 開発責任者。即時停止と機能フラグ無効化の権限を持つ
再評価条件: モデル、API、料金、契約、FAQ検索処理の変更、または新しい重大な失敗

架空の試験結果も、設定値とは分けて残します。

評価結果:
- 公開判定用holdout 35件中34件で必須項目を満たした（97.1%）
- 重大な事実誤り0件、不要な個人データ出力0件、引継ぎ5件中5件成功
- 作業時間の中央値3分42秒、p95応答4.3秒、成功1件あたり8.4円

負荷・再試行:
- 毎分60件を10分間流し、応答時間と費用は上限内
- 429とタイムアウトを20回発生させ、18回は上限内の再試行で回復、2回はFAQ検索へ縮退
- 下書きの重複保存と自動送信は0件

プロバイダー障害:
- 10分間の接続失敗を発生させ、15秒以内にFAQ検索へ縮退
- 障害中のLLM回答と自動送信は0件

切り戻し・通知:
- 機能フラグを無効にして45秒で現行手順へ戻り、未処理の問い合わせを引き継げた
- アラートは開発当番へ40秒で届き、停止権限を持つ開発責任者が4分で確認した

公開判定: GO
- 問い合わせ担当者5人への限定公開とし、全件で人の確認を続ける
- 合成データだけ、実入力サンプル未承認、またはプロバイダー条件未確認ならHOLDへ戻す
- 重大な事実誤り、情報漏えい、安全な縮退の失敗、通知不達のいずれかが起きたらSTOPとし、機能フラグを無効にする

GO・HOLD・STOPの判定例

GO:
- 必須の品質指標が閾値以上
- 重大な停止条件に当たる安全上の失敗が0件
- 応答時間とコストが運用上限内
- レート制限と再試行を含む負荷試験が運用基準内
- プロバイダー障害時の縮退運転と切り戻しを確認済み
- アラート条件とエスカレーション責任者が決定済み

HOLD:
- 品質は届くが、特定の利用者群で失敗する
- 評価器と人の判定が十分に一致しない
- レート制限時の待ち時間や再試行の重複を確認できていない
- 縮退運転または切り戻しを試していない
- アラート条件またはエスカレーション責任者が未決定

STOP:
- 影響の大きい誤操作や情報漏えいが起きた
- プロバイダー障害時に安全な縮退運転へ移れない
- 再試行によって重複処理や費用超過が起きる
- アラートが責任者へ届かない
- 代替動作や切り戻しが使えない

再試行では、対象とするエラー、間隔、上限、重複処理の防ぎ方を決めます。縮退運転は回答を控える、検索結果だけを示す、旧方式へ戻すといった動作です。切り戻しの条件と手順は別に残し、アラートには指標、閾値、観測時間、通知先を記録します。エスカレーション責任者には、機能を止める判断を任せられる人を置きます。

合格しなかったときの挙動も要件の一部です。モデルが示す確信度だけで自動判断はしません。

6. 変更のたびに回帰評価する

評価は公開前の一回では終わりません。前述のOpenAIガイドは、継続的な評価と、開発中や本番で見つかったケースの追加を勧めています。

次のような変更を、再評価の開始条件に含めます。

モデルまたはバージョンの変更
システムプロンプトやテンプレートの変更
ツール、権限、検索元の変更
文書の分割方法、順位付け、絞り込みの変更
方針や禁止事項の変更
利用者層や入力分布の変化
インシデントや新しい失敗例

すべてのリクエストを毎回採点する必要はありません。リスク、費用、応答時間に応じてサンプルを取り、公開前評価と本番監視で同じ指標名を使います。

よくある質問

正解が一つではない作業をどう採点しますか

必須要素、禁止要素、根拠との一致、利用者が作業を完了できたかに分けます。文章全体の完全一致を避け、複数の許容例と採点基準を用意します。

精度が何％なら公開できますか

用途と失敗時の被害によって変わります。全体平均だけで判断せず、高リスクのケースは別の公開停止条件にします。合格値は、人が行う現行作業の成績や組織のリスク許容度と比べて決めます。

評価仕様はモデルの性能表ではなく、機能に任せてよい範囲を決める運用文書です。まず一つの用途と少数の代表ケースから作り、実運用で見つかった失敗を足していくと続けやすくなります。