10月19日、Kanika Vatsyayanが「Why AI Models Pass Benchmarks but Fail in Production」と題した記事を公開した。この記事では、ベンチマークで高スコアを叩き出したAIモデルが本番環境で静かに壊れていく根本原因と、それを防ぐためのテスト戦略について詳しく紹介されている。
ベンチマーク合格≠本番動作、その根本的なズレ
MMLUで88%、GSM8Kでトップクラスの推論精度、HumanEvalでほぼ完璧なPythonコード生成——これらの指標をクリアしたモデルがリリースされ、数週間以内に本番障害を起こす。サポート用チャットボットが存在しない返品ポリシーを自信満々に語り、AIコパイロットが不正なJSONペイロードを出力して下流のサービスをフリーズさせる。
Vatsyayanはその原因を一言で切る。「モデルは劣化していない。設計通りに動いている」。
問題の本質は構造的なミスマッチだ。静的なベンチマークは「隔離された単一能力」を測るが、本番環境のAIアプリケーションは分散・ステートフルなソフトウェアスタックの中で動作する。この差を埋めないまま出荷するから壊れる。
本番で起きる4種類の障害パターン
従来のソフトウェアは構文エラーや例外で明示的に死ぬ。だがMLシステムはHTTP 200を返しながら静かに間違え続ける。Vatsyayanは本番障害の発生面を4つに分類する。
- Fabricated Business Logic（架空ビジネスロジック）： LLMが存在しない割引や取引記録を数学的確信をもって生成する
- Orchestration and Tool Errors（ツール呼び出し失敗）： 正しいアクションを選んでも、JSONスキーマの引数転記ミスやネットワークタイムアウト後の重複API呼び出しが起きる
- Covariate and Input Drift（分布ドリフト）： ユーザーの言い回しや質問の複雑さが学習時のデータ分布からズレ、サーバーエラーなしに精度が落ちる
- Adversarial Vulnerabilities（プロンプトインジェクション等）： 入力サニタイズが不十分なエージェントは、従来のSAST（静的解析セキュリティテスト）では検出できない攻撃に脆弱だ
なぜ公開ベンチマークはこれを検出できないのか
特にRAG（Retrieval-Augmented Generation）アーキテクチャが典型例だ。ベンチマークは「クリーンな単一ターンのプロンプト」を評価するが、本番のRAGシステムはベクトルDBや会話履歴からプロンプトを動的に組み立てる。
矛盾する2つのポリシー文書と古いガイダンスが検索結果に混在したとき、モデルはそれらを「権威ある回答」として合成してしまう。ベンチマークが測るのは「孤立した事実を知っているか」であり、「ノイズだらけの企業コンテキストでハルシネーションを起こさないか」ではない。
ツール実行における問題も深刻だ。JSONペイロードにエスケープされていないダブルクォートが混入しただけで下流マイクロサービスはクラッシュする。またネットワークレイテンシでAPIタイムアウトが発生すると、エージェントがリクエストをリトライして重複したデータベース書き込みや金融トランザクションが発生するケースも報告されている。
本番投入前にやるべきこと
「厳格なスキーマ検証」と「確率的な意味評価」を分けて行う
assert response.code == 200 のような完全一致テストをLLM出力に適用すると、無害な言い回しの違いでテストが壊れる。逆に緩すぎる検証はハルシネーションを素通りさせる。
Vatsyayanは検証パイプラインを2レイヤーに分割することを推奨する。
- Deterministic Contract Testing： 構造化出力（JSON、APIパラメータ、型、必須フィールド）に対して厳格なアサーション
- Probabilistic Semantic Evaluation： 自然言語出力に対してはRAGASのような参照ガイド型のAI評価メトリクスをゴールデンデータセットで評価
エッジケースからバージョン管理されたゴールデンデータセットを作る
公開ベンチマークに依存するのをやめ、自社のドメインシナリオで構成したデータセットをCI/CDパイプラインに組み込む。構成は以下の3種類だ。
- ハッピーパス： 通常の業務トランザクションと頻出クエリ
- 境界・エッジケース： パラメータ欠落、矛盾する指示、空のコンテキスト
- 本番で発生したハルシネーションや失敗： サニタイズして永続的なリグレッションテストに変換する
カオスエンジニアリングとアドバーサリアルファジングでガードレールを検証する
ステージング環境でAPIからHTTP 500/502/504を意図的に返し、オーケストレーションエンジンが無限リトライループに入らずエラーをエスカレーションできるか確認する。また 「以前の指示を無視して」 のようなプロンプトインジェクション文字列を自動でスローし、ガードレールが推論前にブロックするかを検証する。
デプロイ後も終わらない——本番モニタリングの設計
テストはリリース時に終わらない。Vatsyayanが挙げる本番フェーズの対策は以下の3点だ。
- シャドウデプロイ： システムプロンプトやモデルバージョンを変更する際、書き込み操作を無効化した状態で本番トラフィックを並行処理し、現行ベースラインと比較する
- 統計的ドリフト監視： Population Stability Index（PSI、入力データの分布変化を定量化する統計指標）やセマンティックベクトルの距離を追跡し、精度劣化をエラーログより早く検知する
- 自動フォールバック： リアルタイムモニターが非準拠な生成を検出したら即座にペイロードをリダクトし、所定のフォールバック応答を返す。問題のある実行トレースは自動でリグレッションスイートに投入する
まとめ——ベンチマークスコアが保証しないもの
ベンチマークスコアはモデルの汎用能力を示すものであり、特定の企業ソフトウェアスタック上での信頼性を保証しない。確率的なAIコンポーネントを決定論的なコードのように扱えば、アーキテクチャは脆くなる。CI/CDパイプラインへのAI評価ゲートの組み込みと本番での継続的モニタリングが、その差を埋める現実的な手段だ。
詳細はWhy AI Models Pass Benchmarks but Fail in Productionを参照していただきたい。
