カスタム言語モデルにおける CI/CD リリース障害 10 選 — どのパイプライン段階がどれを捕捉するか

リリースサイクルからのノート — Part II

本シリーズの第 1 回 では、私たちが出荷している 4 段階のリリースパイプライン — Register → Gate → Roll → Observe — を順に解説しました。本記事は、その領収書です: 実際に捕捉した 10 の具体的な故障モード、それぞれが現場でどう見えたか、そして本番に到達するのをパイプラインのどの段階が止めたかをお見せします。

このリストは深刻度ではなく段階で整理しています。段階こそが、自分で同様のものを構築する場合に どこに投資すべきか を教えてくれるからです。ゲートが弱点であれば、以下の 10 件のうち 6 件があなたを襲い続けます。オブザーバーが弱点であれば、そのうち 2 件はサイレントに襲ってきます — つまり、唯一得られるシグナルが顧客からのクレームだということになり、これは最悪のシグナルです。

10 件すべてを捕捉するパイプラインは、機能の一覧ではありません。それは、一貫して行われたごく少数のアーキテクチャ上の意思決定です。以下の各障害は、どの意思決定が該当するかを明記しています。

このリストの読み方

各障害には、それを捕捉する段階のタグが付いています:

• ① REGISTER — マニフェスト層。状態が複数システムにまたがって分散していたため、どの変更が本番を壊したのか特定できない、という障害を防ぎます。
• ② GATE — キャリブレーション済みの人間アンカー付きジャッジに対するドメイン単位の Spearman。集計スコアの内側に隠れる障害を防ぎます。
• ③ ROLL — 5% → 25% → 100% のカナリア、各チェックポイントで品質モニターを実施。スケール時にのみ顕在化する障害を防ぎます。
• ④ OBSERVE — 候補モデルを通じて本番トレースを継続的にリプレイし、ゲートのジャッジでスコアリング。レイテンシや 5xx では気づけないサイレントな品質低下を防ぎます。

各セクションの末尾には 修正 — Divinci で実際に出荷している構成と、私たちを使わない場合に自前で構築すべきもの — を記しています。

Stage ① — Register

1. モデル + プロンプト + ルーティングを 1 つのバンドルで同時デプロイし、どれが壊したのか分からない

何が起きたか。 同じリリースで 3 つを変更しました: ベースモデルを Gemma 4 E2B から Gemma 4 26B-A4B にアップグレードし、法務ドメインのシステムプロンプトに「条文を引用せよ」という指示を追加し、どのトラフィッククラスをどのモデルに振り向けるかを決めるルーティングルールを調整したのです。契約書ドラフトの精度が 7 ポイント低下しました。3 つの変更はいずれも独立にテストされていませんでした。デバッグには 2 日かけて変数を 1 つずつ戻していく必要がありました。

なぜ今はパイプラインで捕捉できるか。 Divinci のリリースは、model_ref、prompt_template_ref、routing、dataset_version を 1 つの SHA-256 アドレス可能なアーティファクトにバンドルしたイミュータブルなマニフェストです。パイプラインは、複数の変更をバンドルしたマニフェストのデプロイを拒否します — 例外は、直前のリリースの SHA を比較基準として参照している場合 のみ です。3 つの変更を一度に出荷したい場合は、マニフェストでそれを明示する必要があり、次のリリースは強制的に 1 変数ずつに戻されるため、故障の帰属パスはクリーンに保たれます。

修正。 人間が手作業でリリースを組み立てられないようにします。リリースマニフェストは、サイレントなバンドルが できない パイプラインによって生成されるべきです。API については Stage 1 — Register を参照してください。

2. ダッシュボードでシステムプロンプトを編集し、コードレビューなしで出荷

何が起きたか。 誰かが管理 UI でシステムプロンプトを「モデルをもう少し簡潔にする」よう調整しました。一見、一語の編集に見えました。結果として得られたプロンプトは 38 文字短くなり、これによって長さしきい値を下回ったため、下流のプロンプトリライタが安全性のボイラープレートを追加するかどうかを判断する際の境界を割ってしまいました。2 時間後、モデルは本来拒否すべき質問に回答していました。

なぜ今はパイプラインで捕捉できるか。 プロンプトは登録されたマニフェストの一部です。ダッシュボードでプロンプトを編集するということは、新しいマニフェストを切るということ、つまり新しい SHA を生成するということであり、その変更に対してゲートが走ることを意味します。ダッシュボードで編集すること自体は引き続き可能です。ただし、ゲートに見せずに出荷することはできません。

修正。 プロンプトをコードと同じように扱ってください: コンテンツハッシュでバージョン管理し、リリースの一部として登録し、scored-QA スイートでゲートします。Tianpan の Semver Lie の解説^[1]は、まさにこの故障モードが実際に起きた様子を記述しています — プロンプト変更が「コードレビューを通り、評価ゲートなしでデプロイされ、ユーザー単位の A/B なしで本番に到達し、自動ロールバックもトリガーされなかった」というものです。

3. 学習時とサービング時の前処理の乖離

何が起きたか。 学習パイプラインでは、特定のフィールドについて空白を正規化し、小文字化していました。サービングパイプラインではしていませんでした。モデルもプロンプトもルーティングも同じ — 違うのはバイトレベルでの入力でした。開発フィクスチャではすべて通りました。実トラフィックでは、モデルがノイズの多いデータで再学習されたかのように振る舞いました。なぜなら、モデルの視点からすればまさにそうだったからです。

なぜ今はパイプラインで捕捉できるか。 マニフェストは model_ref と並んで preprocessing_ref を登録します。ゲート評価は、本番サービングスタックが使用するのと同じ前処理を通って実行されます。両者が乖離すると、ゲートのオフライン数値が本番と一致しなくなり、スライス単位の Spearman が promote 前に測定可能な形で低下します。

修正。 前処理をバージョン管理されたアーティファクトとしてコンテナ化してください。マニフェストからそれを参照してください。本番が使用するのとは異なる前処理バージョンに対してゲートが計算されている場合はデプロイを拒否してください。

Stage ② — Gate

以下の 4 つの障害は、集計スコアのゲートであれば出荷してしまっていたものです。集計ゲートがこれらを見逃すのは構造的な理由であって、パラメータチューニングの問題ではありません — スライス横断で平均を取ることは、ひとつのスライスに局在化したリグレッションを捕捉するために使うはずのシグナルそのものを破壊するからです。

4. IP ライセンスの崩壊(スライス単位リグレッション #1)

何が起きたか。 QLoRA ファインチューンによって法務 Q&A の精度が 5 つのサブドメインで向上し、IP ライセンスで崩壊しました — 契約書ドラフト 0.71、法令解釈 0.74、判例要約 0.69、規制コンプライアンス 0.66、管轄分析 0.62、IP ライセンス 0.41。6 つ全体の集計 Spearman ρ は 0.64。ゲートしきい値は 0.65。単一の集計スコアで見れば、リリースは線をほんのわずか下回っただけでした。スライス単位で見れば、ひとつのサブドメインが 27 ポイント崩落していました。

なぜ今はパイプラインで捕捉できるか。 ゲートのしきい値は集計ではなくスライス単位です。いずれか 1 つのスライスがそのしきい値を下回れば、平均がどう見えるかに関係なく、リリースは gate_fail としてマークされます。第 1 回のゲートしきい値チャートは、このようなリリースについてパイプラインが実際に生成する可視化です。

修正。 ゲートをスライスしてください。重要なスライスは、輸入してきた評価フレームワークに入っている分類体系ではなく、顧客セグメントのサブドメインです。

5. 小児腫瘍学スライスのリグレッション(スライス単位リグレッション #2)

何が起きたか。 医療 Q&A モデルを追加の成人循環器データでファインチューニングしました。集計医療精度は 4 ポイント向上しました。小児腫瘍学の精度は 11 ポイント低下しました — どうやら新しい学習データが小児用量調整の重みを微妙に下げていたようです。集計ゲートであれば昇格させていたでしょう。

なぜ今はパイプラインで捕捉できるか。 小児腫瘍学は、顧客が scored-QA スイートを登録した際に設定したスライスのひとつでした。Gate-2 の評価が生成したスライス単位の Spearman ρ は 0.72 から 0.61 に低下し、小児腫瘍学のしきい値 0.68 を下回りました。gate_fail としてマークされ、デプロイなし。

修正。 プラットフォーム定義ではなく、顧客定義のスライスを使ってください。プラットフォームは、コードを書かずに顧客がスライスとスライス単位のしきい値を追加できるようにすべきです — なぜなら、Divinci の誰一人として、顧客のドメインの端を顧客自身ほどよく知らないからです。

6. 多言語のサブ言語ドリフト(スライス単位リグレッション #3)

何が起きたか。 多言語モデルをフランス語の応答改善のためにファインチューニングしました。集計フランス語精度は 3 ポイント向上しました。しかし「フランス語」の内側では、モデルはベルギーフランス語とスイスフランス語の地域変種で以前より悪化していました — 学習コーパスがパリ風フランス語に偏っていたためです。集計フランス語ゲートであれば出荷していたでしょう。

なぜ今はパイプラインで捕捉できるか。 ロケール変種は言語スライスのサブスライスです。サブスライス単位の Spearman が promote 前にベルギー変種のリグレッションを捕捉しました。そのリリースは、(a) より多様な学習データ、または (b) 書面での根拠付き force-override(「集計フランス語の改善が本ロールアウトでより重要であるため、地域リグレッションを受け入れる」) のいずれかで返却され、オーバーライドは監査証跡に入ります。

修正。 スライスの深さが重要です。「フランス語」は粗すぎます。「ベルギーフランス語」が、リグレッションが実際に隠れるレベルです。

7. 書面によるオーバーライド根拠なしにゲートをバイパス

何が起きたか。 高圧的なリリースウィンドウ。ゲートが 1 つのスライスで失敗 — チームの判断では非クリティカル。誰かが force-override フラグに手を伸ばしました。以前のバージョンのパイプラインでは、force-override は単一のブール値でした。フラグが立ち、リリースが出荷され、3 週間後には、誰がどのスライスについて何を決めたのか誰も再構築できなくなっていました。

なぜ今はパイプラインで捕捉できるか。 force-override は 2 フィールドのゲートになっています: forceGateOverride: true AND overrideReason: "..."。理由は必須の自由記述文字列で、オーバーライドされたスライス単位ゲート結果およびユーザー ID とともに監査ログに書き込まれます。理由がなければ、パイプラインはオーバーライドを拒否します。オーバーライド自体は引き続き可能です — ただし匿名でのオーバーライドはできません。

修正。 ガバナンスゲートは別段階ではありません。ゲート段階のひとつの性質です: すべてのオーバーライドは、根拠テキスト付きの署名済みレシートです。

Stage ③ — Roll

8. トラフィックを 0% から 100% へワンステップで移行

何が起きたか。 あるモデルがゲートをクリーンに通過しました。即座にトラフィックの 100% にプッシュされました。会話長のあるクセにより、新モデルは ~2,400 トークンを超える応答でタイムアウトしました — このふるまいは、テストプロンプトがすべて短かったため、ゲートの 100 問の評価セットでは表面化しませんでした。誰かが手動でロールバックするまでの 18 分間、15% のユーザーがタイムアウトを受けました。

なぜ今はパイプラインで捕捉できるか。 Roll 段階は、5% で dwell_5pct_seconds(デフォルト 240) または requests_5pct(デフォルト 1,000) のいずれか 遅い方 に達するまで保持されます。5% トラフィックで、長会話のタイムアウトは ~3 分以内に 5xx レートモニターに表面化します。いずれかのチェックポイントモニターが帯域を超過した場合、パイプラインは 5% から先への進行を拒否します。停止までの平均時間は 4 分、停止後の完全ロールバックまでの平均時間は約 12 秒でした。

修正。 レイテンシと 5xx だけでなく 品質 モニターを伴う 3 ステップのカナリアにしてください。「5% で 20 秒、おしまい」というパターンは危険なほうです。「5% を 4 分間」というパターンが安全なほうです。

Stage ④ — Observe

以下の 2 つの障害は、インフラ指標のカナリアであれば昇格させてしまっていたものです。インフラ指標がこれらを見逃すのもまた構造的な理由です — モデルがひっそりとヘッジしたり拒否したり幻覚したりしている間、レイテンシと 5xx は完全にクリーンなままでいられるからです。

9. 法務クエリでのサイレントなヘッジ(サイレント品質低下 #1)

何が起きたか。 セーフティチューンされたモデル更新により、法務ドメインのアシスタントが目に見えて保守的になりました。レイテンシは同じ、5xx レートも同じ、トークン使用量も同じ。しかし、以前のバージョンが「時効は X 年です」と答えていたところで、新バージョンは「弁護士にご相談ください」と答えるようになりました。顧客は数時間で気づきました。ダッシュボードは一切動きませんでした。

なぜ今はパイプラインで捕捉できるか。 Stage 4 のオブザーバーは、本番トレースをアクティブモデルを通じて継続的にリプレイし、Gate-2 を駆動したのと同じキャリブレーション済みジャッジでスコアリングします。ヘッジは即座に表面化します。なぜならキャリブレーション済みジャッジ — 「良い」法務回答とはどのようなものかについての人間評価にアンカーされている — は、回答が期待される場面での拒否にペナルティを与えるからです。出力品質モニターが 3 分連続で帯域を下回り、パイプラインが自動ロールバックしました。所要時間合計: 5 分未満。

修正。 レイテンシと 5xx だけを監視してはいけません。実際の本番トレースに対するキャリブレーション済みジャッジから導出される 品質 スコアを監視してください。SageMaker のデプロイメントガードレール^[2]は CloudWatch アラームで自動ロールバックします — インフラには有用ですが、アラームは指標で発火する必要があり、「モデルがヘッジしている」は CloudWatch から見える指標ではありません。

10. ファインチューニング後の日付の幻覚(サイレント品質低下 #2)

何が起きたか。 スケジューリングアシスタントのファインチューンが、入力に存在しない日付を自信を持って挿入し始めました。「ご予定は 3 月 32 日木曜日です。」 レイテンシ変わらず。5xx レート変わらず。幻覚は安全性フィルターを通過しました。「3 月 32 日」を有害だとフラグするものは何もなかったからです — 単にあり得ないだけです。

なぜ今はパイプラインで捕捉できるか。 オブザーバーのキャリブレーション済みジャッジ — 合成ではなく実際の本番スケジューリングトレースで稼働 — は、自信に満ちた誤答に、適切な「分かりません」拒否よりも悪いスコアを与えます。幻覚クラスの低下が、毎分のオブザーバーしきい値を 2 分以内にトリガーしました。自動ロールバックが発火しました。

修正。 ドメイン専門性に対してキャリブレーションされたジャッジを使ってください。汎用 LLM-as-judge は、人間がざっと読んだときに「3 月 32 日木曜日」を見逃すのと同じように、これを見逃します。ドメインキャリブレーション済みジャッジ — ドメインエキスパートの評価に対してアンカーされたもの — は見逃しません。

10 の障害をパイプラインにマッピング

赤で色付けされたバーは、このパイプラインを出荷している 最中 に発見した障害です — これらこそが、皆と同じくインフラ指標を伴う汎用カナリアを出荷するのではなく、スライス単位ゲートとトレースリプレイ型オブザーバーを特に構築するに至った理由です。

LLM CI/CD はソフトウェア CI/CD と何が違うのか?

手短に言えば: LLM リリースは決定論的なアーティファクトではありません。同じプロンプトが、実行ごとに異なる出力を生成します。同じ評価セットが、ハードウェアごとに異なるスコアを生成します。同じモデルが、評価に含めていないスライスでサイレントに失敗していながら、集計品質チェックを通過することがあります。従来の CI/CD が前提としていた仮定のほとんどは、確率的システムと接触すると生き残れません。

3 つの具体的な帰結があります:

1. expect(output).toEqual(X) のアサーションは書けません。 フィクスチャに対する等価性ではなく、人間アンカー付きグレーダーに対する順位相関を取り込む、分布を意識した評価が必要です。
2. 「CI 通過」したモデルが壊れたふるまいを出荷することがあります。 CI が通るということは、コードが走るということです。モデルが正しいということではありません。リリースパイプラインは、CI が提供する 正しさ のゲートの上に、品質 のゲートを強制する必要があります。
3. ロールバックはオプションでも遅くもありません。 故障モードが確率的であり、かつそのいくつかはインフラ層ではサイレントであるため、ロールバック経路はバックアッププランではなく、主たるインフラでなければなりません。リリースマニフェストは、まさにロールバックをアトミックにするために存在します。

本シリーズの第 1 回は、これらの帰結に応える 4 段階アーキテクチャを記述しています。本記事は、それが捕捉する障害を記述しています。

カスタム LM 向けの耐障害性 CI/CD パイプラインはどう構築するか?

正直な答え: 障害は起きると受け入れ、障害発生 から 本番トラフィックが既知の良好なバージョンに復帰 するまでの時間を最小化することです。上記の 4 段階パイプラインは、その原則の具体的な実装ですが、重要なのは原則そのものです。

Divinci を使わずに同等のものを構築したい場合、荷重を担う部品は以下です:

• イミュータブルなリリースマニフェスト: モデル + プロンプト + ルーティング + データセット + 前処理を 1 つの SHA にバンドル。これが 1、2、3 を捕捉可能にします。(Stage 1)
• スライス単位のゲート: しきい値はプラットフォームオーナーではなくドメインオーナーが定義。これが 4、5、6 を捕捉可能にします。(Stage 2)
• 各チェックポイントで品質モニタリングを伴うカナリア: レイテンシと 5xx だけではない。これが 8 を捕捉可能にし、9 と 10 が本番に到達した場合に 生存可能 にします。(Stage 3)
• 継続的なオブザーバー: ゲートを駆動したのと同じキャリブレーション済みジャッジで、アクティブモデルを通じて実本番トレースをスコアリング。これが 9 と 10 を捕捉可能にします。(Stage 4)
• すべての判断に対する署名済み監査レシート。 ハッシュチェーン化され、外部にアンカー可能。オープンウェイトモデルバッキングの場合、レシートには vindex ウェイトアテステーションが埋め込まれ、アクティブウェイトがマニフェストに登録されたものであることを証明します。クローズド API バッキングの場合、レシートは判断連鎖をカバーしますが、ウェイトの来歴は主張できません — 監査証跡はそのことを明示します。

各部品は個別には新規ではありません。あらゆる MLOps プラットフォームがそのうち 1 つか 2 つを持っています。組み合わせ — スライス単位ゲート + 本番トレースオブザーバー + アトミックロールバック + 証明可能なレシート — こそが、2026 年に他の誰も出荷していない部分です。

次に読むべきもの

• 姉妹記事 — Divinci AI で LLM CI/CD パイプラインを構築する方法 — アーキテクチャと API を扱います。
• コンプライアンスページ — すべてのリリース判断を裏付ける vindex レシート形式と、それが EU AI Act、GDPR 第 17 条、HIPAA、NIST AI RMF にどうマッピングされるかを記述しています。
• AutoRAG プロダクトページ — Gate-2 と Stage-4 オブザーバーを駆動するキャリブレーション済みジャッジと自然に組み合わさる、RAG 側の幻覚低減を扱います。
• API リファレンス — 本シリーズで参照されたすべてのコマンドは実在のエンドポイントです。

FAQ

カスタム言語モデルにおいて最も一般的な CI/CD 障害は何ですか?

私たちが出荷してきたリリースを通じて、最も損害が大きい単一の障害は 集約ゲートを通過してしまうスライス単位のリグレッション です。これは、平均では改善しているように見えながら、特定のサブドメインで静かに崩壊するモデルのことです(上記の障害 4、5、6 に該当します)。ロールバックの欠如よりも一般的で、プロンプトドリフトよりも一般的で、そのいずれよりも検出が困難です。修正はパラメータ調整ではなく構造的なものです。平均ではなく、スライスごとにゲートを設けるのです。

不良な LLM リリースをどれくらい速くロールバックできるべきですか?

オーダーとしては分単位ではなく秒単位です。Divinci パイプラインの平均ロールバック時間は約 12 秒です。これは約 100 レプリカ規模のサービスにおけるインフライトリクエストのドレイン時間であり、マニフェストの差し替えそのものではありません(後者はサブ秒で完了します)。これを可能にしているアーキテクチャ上の判断が、バンドル化されたリリースマニフェストです。すべてのコンポーネント(重み、プロンプト、ルーティング、データセット)が単一の SHA から参照されているため、ロールバックは単一のアトミックな再ポイント操作になります。これを公開されたポストモーテムと比較してみましょう。Cloudflare の 2022 年 6 月のインシデント^[3]では、エンジニアたちが互いのリバートを踏み合っていたために、復旧に 44 分かかりました。Atlassian の 2022 年 4 月の障害^[4]では、状態が複数のシステムに分散していたために、影響を受けたサイトあたり 12 時間の復旧時間を要しました。

なぜプロンプトの変更がこれほど多くの本番障害を引き起こすのですか?

プロンプトは CI/CD パイプラインの外側で日常的に編集されているからです。ダッシュボード上、管理 UI 上、ときにはエンジニアリングレビューを経ない人の手によっても編集されます。プロンプトは設定として扱われていますが、実際にはコードのように振る舞います。システムプロンプトへの 38 文字の編集が、モデルの再学習よりも下流のモデル挙動を大きく変えることがあります。修正策は、プロンプトをリリースマニフェストの一部として登録し、モデルが通過するのと同じゲートを通過させることです。

LLM 出力におけるサイレントな品質劣化はどのように検出しますか?

インフラのメトリクスでは検出できません。レイテンシ、5xx 率、トークン使用量では、ヘッジ表現、回答が期待されている場面での拒否、幻覚された日付などを捕捉できません。検出シグナルは、キャリブレーション済みのジャッジが実際の本番トレースに対して算出する 品質 スコアから得る必要があります。Divinci のパイプラインにおける Stage 4 オブザーバーは、本番トレースのローリングサンプルをアクティブモデルで再生し、Gate-2 を駆動したものと同じ人間アンカー型 Spearman ジャッジでスコアリングし、品質スコアが 3 分間連続でしきい値を下回ったときに自動ロールバックを発動します。

AI モデルのデプロイにはどのような監査証跡の要件が適用されますか?

EU AI Act、GDPR 第 17 条(消去権)、HIPAA、NIST AI Risk Management Framework のいずれも、組織に対してモデルバージョン、評価結果、承認判断、ロールアウトの記録を維持することを要求しています。これら 4 つすべての背後にある明文化されていない要件は、その記録が 検証可能 でなければならないということです。監査可能であるとは、「ログを取っている」以上のものを意味します。Divinci の vindex レシートはハッシュチェーン化されており、外部にアンカリング可能です。これは、監査人が私たちのログを信頼しなくてもチェーンを検証できることを意味します。オープンウェイトのモデルバッキングについては、レシートに重み証明(weight-attestation)も埋め込まれます。クローズド API のバッキングについては、重みの来歴を主張していないことがレシートに明示的に記載されます。

References

1. Tianpan — The Semver Lie: how an LLM minor update breaks production (April 2026). Names the dashboard-prompt-edit failure mode directly. Companion: LLM postmortem template — fields SRE missed.
2. AWS SageMaker — Use canary traffic shifting. The standard infrastructure-metric-driven auto-rollback. Useful comparison for what Stage 4 Observe is doing differently (quality score, not CloudWatch alarms).
3. Cloudflare — Cloudflare outage on June 21, 2022. 44-minute revert because engineers walked over each other's reverts. Cited as the "rollback is its own kind of incident" anchor.
4. Atlassian — Post-Incident Review: April 2022 Outage. 12 hours per site to restore. State-spread-across-systems failure mode in its worst form.
5. DORA — Software delivery performance metrics. The "failed deployment recovery time" elite-performer threshold is documented as under one hour. Useful framing for "how fast is fast enough" on rollback.
6. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv:2306.05685, 2023). The reference for why LLM-as-judge can match human ratings overall but vary widely per category — which is exactly the pattern that makes per-slice gating necessary.

本シリーズの次回: 規制領域におけるカスタム LM の検証とリリース。 上記のパイプラインはアーキテクチャです。コンプライアンス経路は、それを使う実践です。EU AI Act、GDPR 第 17 条、HIPAA、NIST AI RMF — それぞれがリリースプロセスに求めるものと、どの vindex レシートフィールドがどの要件をカバーするか。