「モデル名は同じなのに、ある日から出力が変わった」——LLM APIを本番で使っていれば必ず遭遇する問題です。プロバイダは安全性強化やベースモデル入替を内部で行い、公式には互換とされても挙動は確実に変化します。本稿ではサイレント更新を防ぐ4層の実務策を示します。
第1層：model_versionピン留め
gpt-4o、claude-3-5-sonnet のようなエイリアス名ではなく、gpt-4o-2024-08-06 や claude-3-5-sonnet-20241022 のようにバージョン付きIDを必ず指定します。エイリアスは将来のモデルを指すよう変更される可能性があり、これがサイレント更新の最大経路です。Anthropic・OpenAIとも日付付きIDは少なくとも6〜12ヶ月はサポートされると明記しており、この期間内に移行evalを回せます。
第2層：応答キャッシュによる比較基盤
本番リクエストのうちサンプルを (input_hash, model_id, response) 形式でS3等に保存します。目的は2つ。(1) 同一入力に対する応答の時系列変化を後追いできる。(2) 新モデル候補へリプレイして差分を可視化できる。プライバシー上の配慮として、PIIをマスクするかhash化した特徴量のみ保存する運用が現実的です。
第3層：デプロイ時eval（eval-on-deploy）
CI上でカナリアevalを通すだけでなく、本番デプロイの最終ステップとして本番環境からカナリアを叩く「canary-in-production」を入れます。ネットワーク経路・レート制限・リージョン違いで挙動が変わることがあり、CI環境だけでは捕まえられない事象を検出できます。合格判定は前記事のMcNemar + Holm-Bonferroniを再利用します。
第4層：A/Bゲートキーピング
新model_versionは全トラフィックに一気に切り替えず、5%→25%→100%のランプアップ配信とし、各段階で主要メトリクス（ユーザー満足度、解約率プロキシ、エラー率）を監視します。LaunchDarkly、Unleash等のFeature Flagシステムで実装し、問題検知時の即時ロールバックを確保します。
実装のピットフォール
(1) プロバイダSDKの自動更新：package-lock.jsonをコミットし、Renovate/Dependabotで明示レビュー。(2) temperature=0でも完全決定論ではない：cachedトークンやバックエンドシャーディングで微差が出る。キャッシュ比較は「完全一致」ではなく「意味的類似度 + ルール」で判定。(3) プロバイダ側の安全性更新：refusal率の急変はHolmでは拾えないので、別軸で監視を立てる。
組織的対応
モデルアップデートのニュース（OpenAI blog、Anthropic changelog）をRSSやSlack通知で取り、検知後24時間以内に手動evalを走らせる運用を推奨します。技術で100%防ぐのは不可能で、人の巡回を併走させるのが現実解です。