モデル更新時のエージェント評価——アップグレード前後を安全に比較する

モデルプロバイダーが新バージョンをリリースするたびに「いつ切り替えるべきか」という判断を迫られる。汎用ベンチマークスコアは参考になるが、自社エージェントの実務タスクで品質が上がるかどうかは別の問題だ。評価設計なしにアップグレードすると、品質劣化を最初に発見するのはユーザーになる。

モデルバージョンアップはなぜエージェント品質を変えるのか

モデル更新はツール選択挙動とプロンプト感度を変化させる。公式ベンチマーク改善が自社業務タスクの品質向上を保証しない。

LLMプロバイダーが公表する「XXXXベンチマークが改善」という数値は、自社エージェントの業務品質と直結しない。評価データセットが異なるためだ。特に次の3点がリスクになる。

ツール呼び出し挙動の変化: JSONスキーマの解釈が変わり、既存のツール定義との整合が崩れる
プロンプト感度の変動: 以前は正確に従っていた指示が過剰解釈されたり、逆に軽視されたりする
コンテキスト処理の差異: 長いセッションでの指示遵守率や優先順位付けが変わる

Anthropicは移行ガイドで「同一プロンプトでも出力特性が変わる可能性があり、タスク固有の評価を推奨する」と述べている。Claudeシリーズの場合、Opus・Sonnet・Haikuのそれぞれでツール使用の挙動差が公式に文書化されており（Claude model tool use performance comparison）、バージョン間の差異は機能追加だけでなく挙動特性そのものに及ぶことがある。

シャドーモードによる並列評価とは何か

シャドーモードは同一入力を現行・候補の両モデルに送り候補応答を記録するが実行しない。ユーザーに影響はゼロだ。

シャドーモードの仕組みはシンプルだ。LLMゲートウェイがリクエストを受け取ると、現行エージェントに加えて候補エージェントにも同じ入力を送信する。候補の応答はログに記録されるが、ユーザーには返らない。

``本番リクエスト ↓ [LLMゲートウェイ] ├─→ 現行エージェント（Sonnet 4）→ ユーザーへ返却 └─→ 候補エージェント（Sonnet 5）→ ログのみ記録``

全トラフィックをシャドーに流すと推論コストが倍になる。10〜25%のサンプリングで統計的に有意な比較データは確保できるため、コストを抑えながら評価を継続できる。Future AGIの評価ガイドは「10〜25%の並列採点で24時間以内にルーブリックが収束する」と述べており、中小規模の運用でも現実的な構成だ。

LangSmith・Braintrust・Arize Phoenixはシャドートレースの受け入れをサポートしており、既存のトレース収集パイプラインへの追加設定だけで対応できる。Kuuの運用管理サービス（AI-Ops）では、こうした評価基盤の設計・構築を支援している。

なお、シャドーモードはオンライン評価の一形態であり、継続的な品質監視の全体像についてはAIエージェントのオンライン評価——本番サンプリング設計の実践も参照されたい。

比較する3指標と合否ゲートの設計

移行判断の最小指標はタスク完了率・根拠整合性・エラー率の3つ。3指標が現行と同等以上を3日間維持したら昇格を検討できる。

タスク完了率（Task Completion）

エージェントが依頼されたタスクを意図通りに完了したかを評価する。LLM-as-judgeで採点する場合、「ユーザーの依頼が解決されているか（1/0）」のバイナリ評価が採点ノイズを抑えやすい。中間スコア（0〜5点）は評価者間のばらつきが大きくなる。

根拠整合性（Groundedness）

ツール実行結果やコンテキスト文書に基づいた回答かを確認する。ハルシネーションの検知に有効で、「回答の主張がコンテキストで裏付けられているか」を評価する。

エラー率

ツール呼び出し失敗・スキーマ不整合・タイムアウトの増減をヒューリスティックで全量チェックする。評価コストがかからず、モデル更新後に最初に異常を示すことが多い指標だ。

合否ゲートの設計

候補モデルが以下の条件を3日間連続で満たした場合に本番昇格を検討する。

指標	合格条件
タスク完了率	現行 ±1% 以内（悪化しない）
根拠整合性	現行 ±2% 以内
エラー率	現行と同等以下

「5%以上改善なら移行を優先する」というポジティブな基準も追加すると、「壊れていない」だけでなく「良くなっている」を確認できる。

最小実装の3ステップ

既存の可観測性ツールにシャドー設定を追加するだけで並列評価環境を1週間以内に構築できる。新規インフラは不要だ。

Step 1: シャドートレースの有効化

LangSmith・BraintrustはクライアントライブラリにShadow設定を追加するだけで、現行と候補の両レスポンスを並列記録できる。AIゲートウェイを経由する場合はx-routing-strategy: shadowヘッダーを付与する。評価対象はランダムサンプリングで全リクエストの10〜25%を選択する。

Step 2: 評価テンプレートの設定

3指標の評価テンプレートを両モデルのトレースに同一ルーブリックで適用する。LangSmithのEvaluatorsまたはDeepEvalのメトリクスを使うと最小設定で開始できる。現行モデルのベースラインスコアを事前に7日分以上取得しておくことで、比較基準を安定させられる。

Step 3: アラートと昇格フローの設定

候補モデルのスコアが現行を下回ったタイミングでSlackアラートを発火させる。最終的な移行判断は人間が行うが、アラートベースにすることで毎日ダッシュボードを確認するコストを省ける。昇格決定は合否ゲート基準の達成をトリガーとする文書化されたフローにしておくと、判断の属人化を防げる。

よくある移行判断の3つの誤り

最多の誤りは「ベンチマーク改善＝自社品質向上」の短絡とサンプル数不足。最低100サンプルペアで統計的有意性を確認してから判断する。

誤り1: 汎用ベンチマークへの過信

プロバイダーのベンチマーク改善は参考値に過ぎない。自社の業務タスク固有のプロンプトで評価しなければ、改善効果が自社に適用されるかどうかは分からない。

誤り2: サンプル数不足

10件のサンプルでスコアを比較しても統計的ノイズで誤判断しやすい。最低100件、理想的には300件以上のペアを収集してから判断する。LLMの出力は非決定論的なため、少ないサンプルでは偶然の品質差を「改善」と誤認する。

誤り3: テストデータの陳腐化

Golden Datasetが古く、実際の本番入力分布と乖離している場合がある。シャドーモードで本番の実リクエストを評価に使うことでこのズレを防げる（エージェント回帰テストとゴールデンデータセットも参照）。

参考

まとめ

モデルアップグレードの判断を汎用ベンチマークだけで行うのは危険だ。シャドーモードで本番トラフィックの10〜25%を候補モデルに流し、タスク完了率・根拠整合性・エラー率の3指標を3日間以上比較することで、自社ユースケース固有の品質変化を定量的に把握できる。

既存の可観測性ツールへの設定追加から始められる最小構成で評価基盤を作り、合否ゲートで移行判断を標準化することで、プロバイダーのリリースサイクルに振り回されない運用体制を築ける。

AIエージェントの評価基盤の設計・構築については、Kuu株式会社のAIエージェント運用管理サービス（AI-Ops）にご相談ください。