# AI評価

> YogoQ Core AI-readable term handoff. Preview, read-only, Reviewed/Verified only.

- Canonical URL: https://core.yogoq.com/ja-JP/core/ai-evaluation
- Locale: ja-JP
- Content tier: db_backed
- Quality: reviewed
- Publication status: published_reviewed
- Schema version: core-reviewed-term-ai-handoff-v2
- Compatible with: core-reviewed-term-ai-handoff-v1
- Content hash: 00173467f511b5c234492e63bb9e3fd48a49cda99fdbbb1ac32ddf9aca6f99e4
- Trust policy: core-trust-policy-v1-2026-06-22

## Short Definition

AI評価は、AIの出力や行動が目的、品質、安全性、コスト、業務基準を満たすかをテストする仕組みである。生成AIやエージェントを本番化する前提になる。

## 一言でいうと

AI評価は、AIの出力や行動が目的、品質、安全性、コスト、業務基準を満たすかをテストする仕組みである。生成AIやエージェントを本番化する前提になる。

## 計算の考え方

AI評価は用途ごとの採点指標と失敗率で見る。 合格率 | 合格ケース数 / 評価ケース数 | 本番投入の最低品質を見る 重大失敗率 | 高影響エラー / 評価ケース数 | 事故につながる失敗を見る 回帰率 | 以前合格していたが失敗したケース / 以前の合格ケース | 変更影響を見る

- 合格率 | 合格ケース数 / 評価ケース数 | 本番投入の最低品質を見る
- 重大失敗率 | 高影響エラー / 評価ケース数 | 事故につながる失敗を見る
- 回帰率 | 以前合格していたが失敗したケース / 以前の合格ケース | 変更影響を見る

## 含めるもの / 含めないもの

AI評価は、モデル性能だけでなく、プロンプト、データ、ツール、UI、運用ルールを含む。 含める | 正確性、根拠、形式、安全性、バイアス、ツール操作、レビュー負荷 | 実務品質の要素 含めない | 一回限りの感想、デモの印象、モデル名だけの比較 | 再現性がない 明示する | 評価ケース、採点基準、合格ライン、レビュー担当、更新頻度 | 継続改善に必要

- 含める | 正確性、根拠、形式、安全性、バイアス、ツール操作、レビュー負荷 | 実務品質の要素
- 含めない | 一回限りの感想、デモの印象、モデル名だけの比較 | 再現性がない
- 明示する | 評価ケース、採点基準、合格ライン、レビュー担当、更新頻度 | 継続改善に必要

## 意味

AI評価は、AIシステムの出力、判断、ツール利用、長いタスクの進行が、期待する基準を満たすかを継続的に測る活動である。正解がある分類タスクだけでなく、要約、検索回答、下書き、コード生成、エージェント実行なども、基準、テストケース、採点方法、レビュー担当を決めて評価する。実務では、モデル変更、プロンプト変更、データ更新、ツール追加のたびに回帰が起きるため、AI評価は一回の検収ではなく運用品質の仕組みとして扱う。 正解率だけでなく、根拠、形式、安全性、禁止行動、ツール実行、レビュー負荷を評価対象に含めることで、AI機能を継続的に改善できる。

## 役立つ場面

モデル、プロンプト、RAG、ファインチューニングのどれを採用すべきか比較できる。 本番化前に、許容できない失敗をブロックする基準を設定できる。 判断時は、平均点だけでなく重大失敗率、回帰率、レビュー負荷を分けて見る。 AI機能の改善を、個人の印象ではなくKPIとして運用できる。 判断時は、平均点だけでなく重大失敗率、回帰率、レビュー負荷を分けて見る。

- モデル、プロンプト、RAG、ファインチューニングのどれを採用すべきか比較できる。
- 本番化前に、許容できない失敗をブロックする基準を設定できる。 判断時は、平均点だけでなく重大失敗率、回帰率、レビュー負荷を分けて見る。
- AI機能の改善を、個人の印象ではなくKPIとして運用できる。 判断時は、平均点だけでなく重大失敗率、回帰率、レビュー負荷を分けて見る。

## 使い方のポイント

- AI評価は、AI出力と行動を再現可能に測る仕組みである。 AI評価はリリース前の検収ではなく、変更ごとに回す品質運用である。
- 評価対象はモデルだけでなく、プロンプト、データ、ツール、UI、運用を含む。
- 代表ケース、失敗例、境界例を持たない評価は本番品質を保証しにくい。
- モデルやプロンプトを変えたら回帰テストが必要である。 AI評価はリリース前の検収ではなく、変更ごとに回す品質運用である。
- 重大失敗率を合格率と同じくらい重視する。 AI評価はリリース前の検収ではなく、変更ごとに回す品質運用である。

## 何が数字を動かすか

評価品質は、代表的なケース、失敗例、採点基準、変更時の回帰テストで決まる。 ケース設計 | 実際のユーザー質問や業務失敗を含める 採点基準 | 何を合格とするかを人間が説明できるようにする 失敗例 | 危険な例や境界例を入れると本番事故を防ぎやすい 回帰 | 変更時に過去の合格ケースが壊れていないかを見る

- ケース設計 | 実際のユーザー質問や業務失敗を含める
- 採点基準 | 何を合格とするかを人間が説明できるようにする
- 失敗例 | 危険な例や境界例を入れると本番事故を防ぎやすい
- 回帰 | 変更時に過去の合格ケースが壊れていないかを見る

## 判断するときの注意点

高い平均点だけで本番可否を決めない。 少数の重大失敗が事業リスクになる用途では、平均スコアより危険ケースを見る。 評価ケースが簡単すぎると、実運用で品質が崩れる。 人間評価を使う場合は、採点者間の基準ずれを確認する。

- 少数の重大失敗が事業リスクになる用途では、平均スコアより危険ケースを見る。
- 評価ケースが簡単すぎると、実運用で品質が崩れる。
- 人間評価を使う場合は、採点者間の基準ずれを確認する。

## よくある誤解 / 落とし穴

- 一度評価すれば終わり、という誤解がある。モデルやデータが変われば再評価が必要である。
- 人間が数件見れば十分、という誤解がある。代表ケースと失敗例が必要である。
- 平均スコアが高ければ安全、という誤解がある。重大失敗を別に見る必要がある。

## 最小例

マーケティングチームが、AIにキャンペーン案の下書きを作らせる。最初は担当者の主観で良し悪しを見ていたため、モデル変更後に品質が下がっても気づけなかった。チームは、ペルソナ一致、ブランドトーン、禁止表現、根拠、CTAの明確さを採点基準にし、過去の良い案と悪い案を評価セットにした。プロンプト変更ごとに合格率と重大失敗率を比較し、ブランド違反が出た場合はリリースしないルールにした。結果として改善の議論が感覚ではなく証拠ベースになった。 さらに、評価ケースには良い出力だけでなく、過去に問題になった出力、境界例、禁止表現を入れた。平均点が上がっても重大失敗が残る場合はリリースしない基準を置いたため、モデル名や担当者の印象ではなく、再現可能な証拠で改善判断ができた。

## 似ている言葉との違い

AI評価 | 出力と行動をテストする | 本番品質を判断する A/Bテスト | ユーザー反応を比較する | 実利用後の効果を見る 監視 | 本番の挙動を追う | リリース後の劣化を検知する

- AI評価 | 出力と行動をテストする | 本番品質を判断する
- A/Bテスト | ユーザー反応を比較する | 実利用後の効果を見る
- 監視 | 本番の挙動を追う | リリース後の劣化を検知する

## 一緒に見る指標

AI評価は、生成AI、プロンプト、ファインチューニング、AIエージェントの土台である。 生成AI | 出力品質を測る対象 | 評価なしでは本番化しにくい プロンプトエンジニアリング | 変更効果を測る | 改善の根拠になる AIエージェント | 長いタスクとツール利用を評価する | 成功率だけでは不足する

- 生成AI | 出力品質を測る対象 | 評価なしでは本番化しにくい
- プロンプトエンジニアリング | 変更効果を測る | 改善の根拠になる
- AIエージェント | 長いタスクとツール利用を評価する | 成功率だけでは不足する

## Aliases

- AI評価 (display_name, ja-JP)
- AI Evaluation (english_name, en-US)
- Evals (abbreviation)
- AI評価セット (katakana, ja-JP)
- AI評価 (localized_title, ja-JP)

## Relations

- 生成AI: related (https://core.yogoq.com/ja-JP/core/generative-ai)
- プロンプトエンジニアリング: related (https://core.yogoq.com/ja-JP/core/prompt-engineering)
- ファインチューニング: related (https://core.yogoq.com/ja-JP/core/fine-tuning)
- モデル評価: compare (https://core.yogoq.com/ja-JP/core/model-evaluation)

## RAG Chunks

- core:chunk:ai-evaluation:ja-JP:definition:e678c249b23f1c4d
- core:chunk:ai-evaluation:ja-JP:formula:e49f71edd2136174
- core:chunk:ai-evaluation:ja-JP:boundary:006f25afe8fa457a
- core:chunk:ai-evaluation:ja-JP:meaning:e3e00b3cd8a208b0
- core:chunk:ai-evaluation:ja-JP:usage:b8b6f9eff1f9c4bf
- core:chunk:ai-evaluation:ja-JP:usage:14ff2a4095407f07
- core:chunk:ai-evaluation:ja-JP:drivers:3e420d5864376b99
- core:chunk:ai-evaluation:ja-JP:misunderstandings:a25e568c0222cf1f
- core:chunk:ai-evaluation:ja-JP:misunderstandings:a1a6b10f24b86544
- core:chunk:ai-evaluation:ja-JP:examples:f4b00dad0d717b41
- core:chunk:ai-evaluation:ja-JP:comparisons:678440d3458df5a7
- core:chunk:ai-evaluation:ja-JP:related_metrics:73e92a474c846eeb
- core:chunk:ai-evaluation:ja-JP:faq:fc3f7e72617e6ae4
- core:chunk:ai-evaluation:ja-JP:faq:47b1ad37291463e5
- core:chunk:ai-evaluation:ja-JP:faq:5ebcdd3519ed85df

## FAQ

### AI評価はモデル比較だけですか？

違います。プロンプト、データ、RAG、ツール、UI、運用ルールを含めて評価します。

### 何件くらい評価すべきですか？

用途によります。まず代表ケースと危険ケースを小さく作り、利用ログから継続的に増やします。

### 平均点だけ見ればよいですか？

いいえ。高影響エラーや禁止違反は平均点とは別にブロック条件として見ます。

## Sources

- NIST: AI RMF - https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
- NIST: Generative AI Profile - https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

## Limitations

このページは調査・学習のための参照情報です。会計、法務、金融、医療、セキュリティなどの個別判断では一次情報や専門家の確認を優先してください。

- 公開ページは一般的な理解と実務上の判断材料を提供するもので、個別案件の専門助言ではありません。
- 制度、価格、規制、会計基準、製品仕様など変化が速い情報は、最終判断前に一次情報で確認してください。
- AI支援を含む制作・監査フローを使う場合も、公開可否は品質ゲートと人間が読める証跡に基づいて扱います。

