生成AIの評価をリリースゲートにする — 測る/止める/信じる/回すのeval設計

生成AIのアプリを更新したとき、「なんとなく良くなった気がする」で本番に出荷していないでしょうか。プロンプトを直した、安いモデルに替えた、別のLLMから移行した——どの変更も、出力品質が前より落ちていないことを定量で確かめないまま出荷すると、気づかないうちに劣化を本番へ流すことになります。これを防ぐ仕組みが評価（eval）です。本記事は、生成AIの評価を「機能の使い方」で終わらせず、変更を出荷してよいかを判定するリリースゲートとして設計する手引きです。測る・止める・信じる・回すの4つの設計に分け、特にモデル/RAGとエージェントで評価の射程が異なる点を正確に書き分けます。対象は生成AI・RAG・エージェントを本番運用する実務者で、コンソール操作の手順は扱いません。指標の定義や料金は版で変動するため、いずれも2026年6月時点として扱い、適用前に公式の最新情報をご確認ください。

なぜ本番の評価が論点なのか

評価が上級テーマになるのは、それが単独の機能ではなく、いくつもの変更を受け止める共通の土台だからです。他社LLMからの移行も、エージェントの挙動変更も、コスト削減のためのモデル置換も、共通して「壊れていないこと」を定量で保証する必要があります。その保証を担うのが評価です。

Amazon Bedrock Evaluations は2025年3月20日にGA（一般提供開始）し、モデル評価・RAG評価・LLM-as-a-judge の3系統を備えます。これにより、感覚ではなく指標で「良くなった」「壊れていない」を判定できます。ただし、機能があることと、それをリリースの可否判断に組み込めることは別です。以降では、何を測るか、どの閾値で出荷を止めるか、judgeを信じてよいか、評価コストをどう設計するか、そしてオフラインとオンラインの二段をどう組むかを順に見ていきます。

何を測るか — 3系統と指標選択

評価の出発点は、対象に合った系統と指標を選ぶことです。Bedrock Evaluations の3系統は、それぞれ向く用途が異なります。

系統	主な方式	代表的な指標	向く用途
モデル評価	プログラム評価／人手評価／LLM-as-a-judge	accuracy・robustness・toxicity、BERTScore・F1、correctness・completeness 等	モデルの精度・安全性・頑健性の比較
RAG評価（retrieve only）	取得品質の評価	context relevance・context coverage	検索（retrieval）の質を確かめたい
RAG評価（retrieve and generate）	取得＋生成を端から端で評価	correctness・faithfulness・completeness・helpfulness、citation precision・citation coverage	応答全体の正答性・根拠忠実性

プログラム評価は、キュレート済みまたは自前のデータセットに対して、従来のNLPアルゴリズム指標やaccuracy・robustness・toxicityを自動算出します。人手評価は、自社チームやマネージドのワーカーが評価軸で採点・選好します。LLM-as-a-judge は、第2のLLMが応答を採点し、その理由も返します。RAG評価は、取得だけを見るか、取得から生成まで端から端で見るかを選びます。いずれの場合も、期待される取得テキストや応答を含む「正解（ground truth）」のデータセット、いわゆるゴールデンデータの整備が前提になります。なお、各指標の正確な定義や最新の一覧は版で増減するため、掲載時点の内容を公式ドキュメントで確認してください。タスクに必要十分な指標だけを選び、faithfulness のようにハルシネーション検出に効く指標は、RAGなら優先度を上げる、といった選択を行います。

リリースゲートにする — 回帰スイートで出荷を止める/通す

指標を選んだら、それを「測りっぱなし」にせず、出荷の可否判断に変換します。ここが本記事の核です。指標に閾値を設定し、変更のたびに評価を回して前回比の劣化を検知する回帰スイートを組めば、評価はリリースゲートになります。閾値を割ったら出荷を止め、満たせば通す、という運用です。

この考え方は、インフラ運用のSLO（サービスレベル目標）と対をなします。インフラのSLOがレイテンシや可用性で「サービスが壊れていないか」を測るのに対し、評価は出力品質のSLOとして「応答が壊れていないか」を測ります。両者は別物ですが、リリースを止める/通すという判断の型は共通です。

ここで決定的に重要なのが、評価の射程が二製品で異なることです。モデルやRAGの出力は、Bedrock Evaluations のオフライン（データセット単位のバッチjob）で評価します。出荷後の本番トラフィックを継続的に監視するオンライン評価は、Bedrock Evaluations の機能としては提供されず、ログ収集・サンプリング・judge呼び出し・可視化を自前で組む運用になります。一方、エージェントについては、Amazon Bedrock AgentCore Evaluations という別製品が、2026年3月31日に東京を含む9リージョンでGAし、オンライン評価をマネージドで提供します。「オンライン評価は全部自前で作るもの」という理解は、2026年6月時点では古くなっています。次節以降で、この二射程を前提に設計を詰めます。

LLM-as-a-judge を信じてよいか

リリースゲートの判定をLLM-as-a-judge に任せるなら、judge自身の信頼性を吟味する必要があります。judgeも一つのLLMであり、いくつかのバイアスを持つことが知られています。代表的なものに、評価対象の提示順で評価が変わる位置バイアス、長い応答を高く評価しがちな冗長性バイアス、自分（と同系統のモデル）の出力を好む自己選好バイアスがあります。

これらの定量的な影響度について、公式に固定の数値があるわけではありません。したがって、影響を数値で断定するのではなく、運用で抑える前提に立ちます。具体的には、judgeの判定を全面的に信用せず、人手評価を一定割合で併用し、judgeのスコアをサンプル監査して人手の判断とずれていないかを定期的に確かめます。

judgeモデルの選択自体も設計事項です。built-in 指標の評価には、Amazon Nova、Anthropic Claude（Haiku 4.5・Opus 4.5・Sonnet など）、Meta Llama、Mistral といったモデルが選べ、クロスリージョン推論プロファイルにも対応します。高性能なjudgeは人手との一致が高い反面コストが上がり、軽量なjudgeは安価ですが一致が下がりえます。judgeの選択は、評価品質とコストのトレードオフそのものです。

評価コストを設計する — 規模×judge単価×頻度

評価は無料ではありません。コストの構造を押さえると、どこにいくら掛けるかを設計できます。Bedrock Evaluations では、評価そのものに別料金はかかりません。アルゴリズムによる自動スコアは追加費用なしで提供されます。一方で、LLM-as-a-judge やRAG評価で消費するjudgeモデルのトークンは、オンデマンドの標準価格で課金されます。RAG評価では Bedrock Knowledge Bases の通常利用料も別途発生します。人手評価のみ、モデル推論に加えて完了タスクあたりの課金（参考値で $0.21 / human task）があります。料金は2026年6月時点の参考値で、公式の料金ページで確認してください。

つまり評価コストは、おおよそ「評価データの規模 × judgeモデル単価 × 評価頻度」で決まります。回帰スイートを毎コミット全件で高性能judgeに回すと、judge推論費が積み上がります。そこで、評価の粒度と頻度を使い分けます。

課金要素	設計レバー
judgeモデル単価	一次判定は軽量judge、最終ゲートは高性能judge
評価データの規模	高頻度のCIはサンプリング、リリースゲートは全件
評価頻度	毎コミット／日次／リリース時で段階を分ける
RAG評価のKB利用料	構成全体の費用は別途試算（構成TCOの専門記事へ）

毎コミットのCIでは軽量judgeとサンプリングで速く安く回数を稼ぎ、リリースゲートでは高性能judgeと全件で厳密に出荷可否を決める、という二段構えが基本形です。

オフライン×オンラインの二段

評価はリリース前の一回で終わりではありません。リリース前の回帰評価（オフライン）で出荷可否を決め、出荷後は本番の継続監視（オンライン）で品質の劣化を早期に検知します。この二段を、前述の二射程に合わせて組みます。

モデルやRAGでは、オフラインの回帰評価は Bedrock Evaluations の機能で組めますが、オンライン監視は自前です。本番のリクエストとレスポンスをログに残し、一定割合をサンプリングしてjudgeに採点させ、結果を CloudWatch などで可視化する、という運用を設計します。エージェントでは、AgentCore Evaluations が On-demand（特定インタラクションを span/trace ID指定で評価）、Batch（CloudWatch Logs のセッション群を非同期で評価）、Online（本番ライブトラフィックをサンプリング採点）の3モードを提供し、二段をマネージドで組めます。エージェントのオンライン評価の運用詳細は、エージェント本番運用の専門記事の領域です。本記事は評価設計の総論と、モデル/RAGの設計に軸を置きます。

落とし穴とまとめ

最後に、評価運用で踏みやすい点を整理し、全体をまとめます。

• ゴールデンデータは陳腐化する: 正解データセットは作って終わりではなく、仕様やドメインの変化に合わせて保守しないと、評価そのものが現実とずれます。
• 指標の定義・一覧は版で変わる: 指標の正確な定義や対応範囲は版変動があるため、2026年6月時点として扱い、公式ドキュメントで最新を確認します。
• judgeバイアスの影響は定量化されていない: 公式に固定値はありません。数値で断定せず、人手併用とサンプル監査で担保します。
• 二製品を混同しない: モデル/RAGの Bedrock Evaluations とエージェントの AgentCore Evaluations は別製品で射程が違います。「オンラインは全部自前」と一括りにしないことが正確な設計の前提です。

評価をリリースゲートにする設計は、4つに集約できます。何を測るか（測る）、どの閾値で出荷を止めるか（止める）、judgeをどう信頼するか（信じる）、どの粒度と頻度で回すか（回す）です。他社LLMからの移行後、エージェントの変更後、安いモデルへの置換後——いずれの「壊れていないことの確認」も、このeval設計に集約されます。具体的な移行手順や推論コストの単価設計、エージェント本番運用は、それぞれの専門記事に接続して進めると、変更を安全に出荷し続ける仕組みが組み立てられます。

出典

• Amazon Bedrock Evaluations（ユーザーガイド） — https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html
• RAG評価・指標（evaluation-kb・公式ドキュメント） — https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation-kb.html
• RAG評価・LLM-as-a-judge 機能のGA（AWS News Blog） — https://aws.amazon.com/blogs/aws/new-rag-evaluation-and-llm-as-a-judge-capabilities-in-amazon-bedrock/
• Amazon Bedrock Evaluations 製品ページ — https://aws.amazon.com/bedrock/evaluations/
• Amazon Bedrock AgentCore Evaluations GA（What’s New・2026年3月・東京含む9リージョン） — https://aws.amazon.com/about-aws/whats-new/2026/03/agentcore-evaluations-generally-available
• AgentCore Evaluations 評価タイプ（開発者ガイド） — https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations-types.html
• Amazon Bedrock 料金 — https://aws.amazon.com/bedrock/pricing/