2026年におけるカスタムLLMの自動リグレッションテスト

リリースサイクルからの覚書 — 第7回

金曜日の午後4時47分、あなたはプロンプトをわずか一文字だけ調整してリリースしました。集約評価スコアは0.873から0.871へ動きました――ノイズフロアに十分収まる範囲です。月曜日の朝、サポートキューは、6か月前から安定していたために監視を止めていたクエリのクラスをめぐって炎上しています。

モデルにリグレッションは起きていません。モデルは同じモデルです。評価のほうがあなたの足元からドリフトしていったのです。 ある顧客セグメントで6か月かけて緩やかに成長してきた挙動は、ゴールデンデータセットに一度も組み込まれず、ジャッジプロンプトは10月に人間と最後にキャリブレーションされたきりで、検索インデックスは先週の水曜日、更新された埋め込みモデル上で密かに再構築されていました。

これは第6回で指摘した通りです――モデルが正解であるのは、おおよそ7件のアラートに1件。つまりリグレッションスイートは、モデルだけでなく、スイート自身のドリフトも検出しなければなりません。本稿はそのためのスイートです。

カスタムLLMにとってのリグレッションテストとは何か

ソフトウェアのリグレッションテストは、固定された入力に対して output == expected を表明します。関数が決定論的だからこそ成立します。

言語モデルは同じ意味での関数ではありません。同じプロンプトでも温度 > 0 では妥当な補完の分布を生成し、「妥当」は多次元です――質問に答えたか、検索したコンテキストに基づいているか、安全エンベロープの内側にとどまったか、レイテンシ予算内に応答が戻ってきたか。したがってカスタムLLMのリグレッションテストとは、凍結したベースライン分布に対して挙動の分布を測定することを意味します――重要なスライスごとに、人間に対してキャリブレーション済みのジャッジで、本番トラフィックに似た入力に対して。

これが意味を持つには、まず3つの要素が整っている必要があります。

1. 集約ではなくスライスレベルで本番に似たゴールデンデータセット。
2. キャリブレーション済みのジャッジ――「GPT-5をジャッジに使っている」ではなく、「3名のヒューマンレーターに対してSpearman ρ ≥ 0.7 を測定し、先週リフレッシュした」というレベル。
3. ベースラインマニフェスト――そのスコアを記録したときの正確なモデル重み、プロンプトテンプレート、検索インデックス、ジャッジバージョン。これがなければ、スコアが動いたのはモデルが変わったからなのか、物差しが変わったからなのか判別できません。

Divinciはこの3つすべてをファーストクラスのオブジェクトとして扱い、ハッシュでリンクし、コミットごとにスコアリングします。本稿の残りは、それらの組み立て方です。

なぜほとんどのLLMリグレッションスイートは本物のリグレッションを捕捉できないのか

2026年のカスタムLLMにおける主たる失敗モードは、TianpanのSigma Inferenceチームが2026年4月のポストモーテムで Semver Lie^[1] と名付けたものです。集約メトリクスはフラットまたは改善する一方で、1つか2つの本番スライスが密かにリグレッションするというパターンです。当該スライスはテスト設計時にはトラフィックの5%未満で、ゴールデンデータセットに入っていませんでした。6か月後にはトラフィックの12%に成長し、モデルはそこで劣化していましたが、集約値ではそもそも気づける構造になっていなかったのです。

直近18か月の公開LLMリリースポストモーテムをすべて精査したところ、同じパターンが繰り返されています――スイートがグリーンになったのは、間違ったものをスコアリングしていたからです。 具体的には:

• ゴールデンデータセットはローンチ時にチームが手書きしたきりで、シフトしたトラフィック分布に対して再層化されていなかった。
• LLM-as-judgeのプロンプトは一度設定されたまま、人間ラベルに対して再キャリブレーションされていなかった。ジャッジの一致度は静かに減衰していった^[2]。
• ベースラインスコアは生の数値として保存され、(model_sha, prompt_sha, judge_sha, dataset_sha, score) のタプルとしては保存されていなかった。だからリグレッションが起きても、4つのうちどれが動いたのか誰にも分からなかった。

この3つすべてを解決しないリグレッションスイートは、デプロイ時にグリーンになって誤った安心感を与えるだけのCIステップにすぎません。修正は「ケースを増やすこと」ではありません。修正は、リリースごとにスライス対応・バージョン固定・ジャッジキャリブレーション済みの測定を行うことです。

スライス対応分析に耐えるゴールデンデータセットを構築する

弊社が既定で出荷している4バケット構成――本番サンプル60%、敵対的15%、専門家がキュレートしたエッジケース15%、失敗リプレイ10%――は妥当な出発点です。本当にリグレッションを捕捉できるようにするのは、各ケースに紐づくスライスメタデータです。

データセットの各エントリは以下を持ちます: 入力、期待される挙動(完全一致文字列ではなくルーブリック)、検索コンテキスト(あれば)、slice タグ――ドメイン、ユーザーセグメント、クエリ意図、言語、長さバケット、その他あなたのプロダクトにとって意味のある分解軸。スイートはスライスごとにスコアリングし、しきい値を下回ったスライスがあれば、たとえ集約スコアが上昇していてもリリースをブロックします。

実運用で守るようになった2つのルール:

四半期ごとに再サンプリング。 本番トラフィック分布は、ほとんどのチームが測定するより速くシフトします。本番サンプルバケットは、直近90日のトラフィックに対して四半期ごとに再層化しています。あるスライスがトラフィックの5%超に成長し、ゴールデンデータセットでは2%未満だった場合、次のリリースまでにバックフィルします。

ポストモーテムごとにケースを追加。 本番に到達して捕捉できなかったリグレッションは、データセットに欠けていたケースです。ポストモーテムから48時間以内にリプレイバケットへ追加し、それを浮上させたスライスでタグ付けします。

ユーザーより先にドリフトを検出するには

ドリフトには明確に4種類あり、最後の1つしか監視しないリグレッションスイートは、ほとんどのリグレッションを取りこぼします。

ほとんどのスイートが測定するのは品質ドリフトです。金曜午後のリグレッションが潜むのは、たいてい残りの3つです。Divinciは4種類すべてをベースラインマニフェストに対して追跡し、PRごとにスライス別スコア内訳を表示し、ドリフトが蓄積する前に検出する週次ジャッジキャリブレーションジョブを備えています。

多次元評価 — スライスごとに4つを同時にスコアリング

単一の合成スコアは、4つのスカラースコアより劣るシグナルです。弊社は次の4次元でゲートします:

• タスク完了 — レスポンスが実際に質問に答えたか。ルーブリックに対してキャリブレーション済みジャッジでスコアリング。スライス対応。
• 忠実性 — 検索コンテキストを参照したレスポンスについて、すべての主張がそのコンテキストに基づいているか。ハルシネーションはここに最初に現れます。
• 安全性 — 拒否の正しさ、ジェイルブレイク耐性、PII / ポリシー露出。ほぼ常に合格率 ≥ 0.99 でゲート。安全性は柔軟なトレードオフではなく、ハードウォールです。
• レイテンシ予算 — スライスのSLA内における p95。レスポンスあたりトークン数が倍増したプロンプト変更は、品質が上がってもリグレッションです。

各次元はスライス別のベースラインとしきい値を持ちます。ゲート時に単一の加重スカラーへまとめることは絶対にしません。スライスごとに4つのスコアとして表示し、最初にしきい値を超えた指標でブロックします。医療スライスで忠実性を1ポイント犠牲にしてタスク完了を4ポイント獲得したモデルは、依然リグレッションです。

カスタムLLMのデプロイをブロックすべきゲートは何か

弊社は3層アーキテクチャを運用し、各層がパイプラインの異なる段階をゲートします(段階分類は第1回を参照)。

第1層 — スモーク(コミットごと、約90秒)。 インパクトの大きいスライスから抽出した20〜30件のクリティカルケース。フルスイートが計算リソースを消費する前に、壊滅的なリグレッションを捕捉します。スモークが失敗すれば、残りは実行されません。

第2層 — フルスイート(PRごと、約12分)。 完全なゴールデンデータセットを、4次元すべてでスライス別にスコアリング。ベースラインマニフェストに対するスライス対応の Spearman ρ。しきい値違反はマージをブロックします。PRコメントには、どのスライスのどの次元がどれだけ動いたかと、失敗ケースの例5件が列挙されます。

第3層 — ベースライン比較(リリース候補、約25分)。 候補モデルを直近14日の本番トレースに対してリプレイします――第1回で出荷したクローズドループの本番トレースリプレイです。ゴールデンデータセットをスコアリングするのと同じキャリブレーション済みジャッジが、リプレイ出力もスコアリングします。リプレイスコアがオフラインスコアからしきい値以上に乖離したスライスがあれば、リリースをブロックします。この層こそ、ゴールデンデータセットがまだ把握していないドリフトを捕捉する場所です。

ジャッジを信用する前にキャリブレーションする

LLM-as-judge は、これらすべてを数百ケースを超えてスケールさせる仕組みです。同時に、ジャッジが更新されたりデータ分布が動いたりしてもキャリブレーションを維持する義務は何もないため、リグレッションスイートが密かに機能停止する場所でもあります。

弊社は、ゴールデンデータセットと同じスライスで層化した、少なくとも100ケースの凍結された人間ラベル監査セットに対して、すべてのジャッジプロンプトをキャリブレーションし、毎週再実行します。出荷基準は Spearman ρ ≥ 0.7(ヒューマンレーター中央値に対して)、安全性のバイナリ判定では Cohen’s κ ≥ 0.6 です。両者は、MT-Bench型のジャッジが人間間一致レベルで人間レーターを追跡するとされるしきい値^[2]を上回ります。

週次キャリブレーションがしきい値を下回ると、ジャッジは自動的に引退させられ、オンコール評価エンジニアにページが飛びます。リリースパイプラインは、もはや測りたいものを測れていないジャッジでゲートするのではなく、候補を保留状態にします。

# 週次ジャッジキャリブレーションジョブを実行
curl -X POST https://api.divinci.ai/v1/regression/judges/calibrate \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "judge_id":     "rubric-v7",
    "audit_set":    "human-labels-2026-04",
    "min_spearman": 0.70,
    "min_kappa":    0.60,
    "on_fail":      "retire_judge_and_page"
  }'

Divinci の差別化要因 — クローズドループの本番トレースリプレイ

第3層ゲートは、ほとんどのリグレッションスイートが持っていない部分です。フローは第1回で出荷したものと同じで、リグレッションテスト向けに一点だけ特化しています――すべてのリリース候補について、オフラインのゴールデンデータセットでのスコアと、14日間ウィンドウでリプレイした本番トレースでのスコアを、スライスごとに比較します。ゴールデンデータセットはモデルにこうあってほしかった姿を測ります。リプレイは、モデルが先週実際にどう振る舞っていたであろうかを測ります。

両者がスライス別の乖離許容量を超えて開くと、リリースはブロックされます。その不一致がシグナルです――ゴールデンデータセットがもはや代表的でない(カバレッジドリフト)か、候補が本番の前処理と検索によって形作られたトレース上で異なる振る舞いをしている(本番ドリフト)か、いずれにせよ、ユーザーより先に把握できます。

オフライン実行をスコアリングするジャッジと、リプレイ実行をスコアリングするジャッジは同一です。監査ログには、両方のスコアセット、両方のジャッジバージョン、リプレイされたトレースID、ブロックを発火させた乖離量が記録されます。乖離量そのものが、弊社が持つ最も有用な診断シグナルであり、第6回の診断ツリーを次に引き継ぐ担当者の手に渡されます。

vindex レシートでゴールデンデータセットをアンカーする

スイート内のあらゆるスコアは、後で再現できなければ無意味です。弊社はリリースごとにゴールデンデータセットをハッシュ化し、そのハッシュをモデルSHA、プロンプトSHA、ジャッジSHA、キャリブレーション記録とともに vindex レシートにチェーン化します。レシートは外部からアンカー可能で、監査人は6か月後でも弊社の正確なリグレッション実行を再現し、申告したスコアを検証できます。

{
  "release_id": "rel_3f1a-2026-05-26",
  "model": { "sha": "0c1f9…", "weights_uri": "r2://models/custom-v7.2", "open_weights": true },
  "prompt": { "sha": "c4a8e…", "template_id": "support-v3.4" },
  "retrieval": { "index_sha": "b21f0…", "embedder": "e5-mistral-7b-instruct" },
  "judge": { "sha": "d8e21…", "rubric_id": "rubric-v7", "spearman_vs_humans": 0.74 },
  "dataset": { "sha": "a90b1…", "n": 512, "slices": 17, "stratified_at": "2026-04-30" },
  "scores": { "aggregate": 0.872, "by_slice": { "/* … */": "/* per-slice scalars */" } },
  "replay": { "trace_window_days": 14, "n_traces": 8430, "max_gap": 0.018 },
  "vindex_anchor": "sha256:f0bfd2…",
  "verifiable_at": "https://vindex.divinci.ai/rel_3f1a-2026-05-26"
}

オープンウェイトに関する但し書き。 上記レシートが重みの来歴を保証するのは、モデルがオープンウェイトの場合に限られます――vindex は実際の重みバイトをアンカーします。クローズドAPIのモデル基盤(OpenAI / Anthropic / Google のマネージドモデル)では、レシートには引き続き意思決定チェーンが記録されます――各ゲートスコア、各ジャッジ結果、キャリブレーション記録――が、重みフィールドは空となり、モデルアーティファクトを独立に検証することはできません。これはレシート内およびコンプライアンスドキュメントで明記し、監査人に誤った印象を与えないようにしています。完全な vindex チェーンの恩恵が最大化されるのは、自分で重みを管理しているリリースです。

弊社が実際に出荷してきた4フェーズの実装タイムライン

初週でアーキテクチャを丸ごと出荷しようとするチームは、ツール選定で足踏みします。以下は、実際にうまくいく順序です。

フェーズ1 — ベースライン(第1週)。 直近30日分の本番トレースから層化サンプルを抽出。エンジニア2名にそれぞれ100ケースずつタスク完了を手動ラベリングしてもらいます。レーター間一致度(目標 Cohen’s κ ≥ 0.6)を算出します。その値が出発点となるヒューマンベースラインで、他のあらゆるものはこれに対してキャリブレーションされます。

フェーズ2 — ハーネス(第2〜3週)。 100ケースのデータセット上で評価ハーネスを立ち上げます。人間ラベルに対してキャリブレーション済みのジャッジを追加。ハーネスが ρ ≥ 0.7 の範囲で人間スコアを再現することを検証します。多くのチームは、最初のジャッジプロンプトでこれに失敗し、2度書き直すことになります――これは普通のことです。

フェーズ3 — ゲート(第3〜4週)。 ハーネスをCIにブロックではなく警告として接続。2週間観察します。誤検知率を見ながら発見されたしきい値だけが、生き残るしきい値です。誤検知率が5%を下回ってからブロッキングに昇格させます。

フェーズ4 — リプレイループ(継続)。 ゲートが安定してブロックするようになったら、本番トレースリプレイ層を有効化します。ここでスライスカバレッジのギャップが浮上し、すべてのポストモーテムがゴールデンデータセットにケースを戻し始めるようになります。

これで解決できないこと

本シリーズの各回と同じ姿勢で、誠実な制限を3点。

1. スイートのドリフト対応は終わりのない作業。 リグレッションテストはプロジェクトではなくインフラです。ゴールデンデータセットは四半期ごとに再層化、ジャッジは毎週再キャリブレーション、しきい値予算はポストモーテムごとに再チューニングが必要です。「スイートを出荷したら歩み去る」というバージョンはありません。
2. 完璧にキャリブレーションされたジャッジでも結局はモデル。 人間レーターに対する Spearman ρ = 0.74 は、ジャッジの判定の約4分の1が人間中央値と不一致であることを意味します。その残余不一致が、すべてのスコアにおけるノイズフロアです。リリースレポートで明示的に提示しますが、その存在を忘れたチームはいずれ驚くことになります。
3. クローズドAPI基盤は検証可能範囲を制限する。 クローズドAPIモデルでは、リグレッションスイートは挙動を測定できますが、重みの来歴は検証できません。完全な再現性が必要な場合――規制業種、監査対象デプロイ――トレードオフはモデル選択にあり、スイートにはありません。

次回

シリーズ最終回となる第8回は、CI内部のループを閉じます。本回と第5回がゲートで何を動かすかの話だったのに対し、次回はゲートがスコアリングする候補そのものを生み出すCIレイヤー――マージ前評価、プロンプトテンプレートの契約テスト、12分間の評価スイートを予算を破綻させずに回すためのCIフリートのサイジング――を扱います。これまで書いてきたすべての下にあるエンジニアリングレイヤーです。

FAQ

LLM評価とLLMリグレッションテストの違いは?

評価は、絶対的なルーブリックに照らして、モデルがある時点で品質基準を満たしているかを測定します。リグレッションテストは、候補が凍結されたベースラインと同じ挙動をしているかを、スライス別・多次元で測定します。ベースラインの存在こそがリグレッションテストたる所以であり――Divinciは両モードを出荷し、リグレッションモードでは (model_sha, prompt_sha, judge_sha, dataset_sha) を固定するため、スコアが動いたときにどの入力が動いたのかを特定できます。

ゴールデンデータセットには何件あればよいですか?

思っているより少なく、思っているより上手く層化することです。明確に定義した5スライスについて200ケースで有用なリグレッションカバレッジを出荷したこともありますし、層化されていなかったために重要なものを全く捕捉できなかった5,000ケースのデータセットも目にしてきました。まずは層化された200件から始め、ポストモーテムを通じてリプレイバケットを一件ずつ育てるのがよいでしょう。

人間レビュアーと LLM-as-judge のどちらを使うべきですか?

両方を、人間がジャッジをキャリブレーションする形で使います。人間はリリースサイクルのCIゲートが必要とするスコアリング量に追いつけません。ジャッジが量をこなし、人間がジャッジをキャリブレーションする――週次で Spearman ρ ≥ 0.7 を測定します。どちらか片方だけでは失敗モードです。

非決定論的な出力はどうテストすればよいですか?

文字列ではなく分布をスコアリングします。表現の揺れを跨いでジャッジが適用できるルーブリックでスコアリングし、各入力を温度 > 0 で3〜5回実行することで、スライス対応スコアが単一サンプルではなく補完の分布の上で算出されるようにします。決定論的出力が真に必要なケース(構造化出力のツールコール、分類)に限って、温度を絞ります。

最初のCI品質ゲートではどのメトリクスを優先すべきですか?

タスク完了と、安全ゲートを1つ。いずれもスライス別に。最初の2つがキャリブレーションされる前に次元を増やすとノイズが発生します。多く出荷しすぎたチームは、結局そのノイズでゲートする羽目になります。検索を有効化するときに忠実性を追加し、最初の2つが安定したらレイテンシを追加します。

参考文献

1. Pan, Tianpan. "The Semver Lie: how a minor LLM update broke production." 2026年4月29日。スライス対応リグレッション分析における2026年の代表的失敗モードの命名元。集約スコアは平坦のまま、低ボリュームスライスが密かにリグレッションする。
2. Zheng et al. "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." arXiv:2306.05685。強力なLLMジャッジがオープンエンドタスクにおいて、ほぼ人間間一致レベル(約80%)で人間レーターと一致するという実証的証拠。報告された失敗モードは、人間に対するキャリブレーション監査が検出を狙うものでもある。
3. Kirkpatrick et al. "Overcoming catastrophic forgetting in neural networks." PNAS / arXiv:1612.00796。ファインチューニングされたニューラルネットワークにおける破滅的忘却の基礎的成果――ファインチューンされたカスタムLLMが、目標タスクでのゲインだけでなく、汎用能力の損失についてもリグレッションテストされなければならない理由。
4. Amazon Web Services. "SageMaker Deployment Guardrails — blue/green deployments and canary monitoring." クローズドAPIとの対比: スライス別のセマンティック品質ではなく、インフラメトリクス(レイテンシ、エラー、CPU)でゲートする。
5. Spearman, C. "The proof and measurement of association between two things." American Journal of Psychology, 15(1):72–101, 1904年。スライス対応ゲートを支える順位相関係数――ジャッジのスコアリングスケールのドリフトに対して頑健であり、まさにそれが必要としていた性質。
6. DORA / Google Cloud. "Accelerate State of DevOps — change-failure-rate and time-to-restore-service metrics." 「デプロイがインシデントを引き起こす頻度」と「復旧速度」の業界横断ベースライン。ゲートでブロックするリグレッションスイートは前者を下げ、即時ロールバック([第5回](/ja/blog/automated-llm-ci-cd-pipelines-with-instant-rollback/))は後者を下げる。