エイリアス地獄
OpenAI の `gpt-4`、Anthropic の `claude-3-5-sonnet`、Google の `gemini-1.5-pro` のような名前は、多くの場合「その時点で最新のスナップショットにルーティングされるエイリアス」である。バックエンドの重みは予告なく差し替わり得る。これは UX としては便利だが、プロダクション品質保証の観点では地雷原だ。同じコード、同じプロンプトが昨日と今日で異なるモデルを叩いている可能性がある。
サイレント更新の症状
サイレント更新が起きると次のような症状が観測されると報告される。(1) 評価スコアが理由なく数ポイント動く。(2) システムプロンプトへの従順度が変わり、JSON パースエラー率が変動する。(3) refusal 率や「I cannot...」の出現頻度が変わる。(4) トークン使用量が増減しコストが揺らぐ。(5) レイテンシ分布が変わる。これらはモデル自体の変更、安全フィルタの調整、推論最適化（量子化・投機デコード）のいずれによっても起こり得、ユーザー側では区別がつかない。
Snapshot ID 固定の必須性
- 年時点、主要ベンダーはすべて固定スナップショット ID を提供している。`gpt-4-0613`、`gpt-4o-2024-08-06`、`claude-3-5-sonnet-20240620`、`gemini-1.5-pro-002` のような形式だ。プロダクションでは例外なくこれを使う。エイリアスは検証環境や使い捨てスクリプトだけに限定する。スナップショット ID は、OpenAI でいう `seed` パラメータや `system_fingerprint` と組み合わせて初めて再現性の足場ができる。
EOL（deprecation）との戦い
固定スナップショットには寿命がある。典型的には 6-12 ヶ月でベンダーが deprecation を予告し、数ヶ月後に停止する。品質保証の観点で重要なのは (1) deprecation 通知を Slack/メール以外にコードのヘッダ警告として取り込む、(2) 移行候補スナップショットを並行稼働させ、golden set で差分を取る、(3) 挙動差分がプロダクト要件上許容範囲か SLO に照らして判定、(4) ユーザー可視の変化（出力長、口調、refusal）については changelog を出す、の 4 点だ。
ルーティングの透明性を要求する
マルチモデルルーター（安い要求は軽量モデル、難しい要求は重いモデル）を導入する場合、どのリクエストがどのモデルに当たったかをログすることが再現性の前提になる。自社ルーターなら response ヘッダに `x-model-used` を仕込む。ベンダー側のフォールバック（メインが混雑で別モデルに回る）は厄介で、ログに記録されない限り後から追えない。契約上、ベンダーに使用モデル ID のレスポンス返却を要求できるかを確認すべきだ。
チェックリスト
最後に最小チェックリストを置く。(1) コードベースから `gpt-4` 等のエイリアス文字列をプロダクションから排除した。(2) すべての LLM 呼び出しで model、snapshot、temperature、seed、system prompt バージョンを observability に送っている。(3) 週次 golden set で 2σ 超の差分が出たら自動アラート。(4) deprecation 90 日前から移行検証を開始する運用がある。(5) ルーティングを使う場合は使用モデルをログに含める。ここまで整えて、ようやく「品質が落ちたか」を議論できる土台に立てる。