即時ロールバックを備えた LLM CI/CD パイプラインの自動化

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

前四半期に最も引用されたのに公開されなかったページは、午前 2 時 14 分にオブザーバーが独自に発火させたものでした。候補リリースはゲートを通過し、必要な 4 分間 5% で滞留し、25% に進んだあと、そこで止まっていました。1 分ごとの品質モニターは法務領域スライスで連続 3 回の閾値未満の測定値を検知し、ロールアウトを停止して、ルーティングを以前のリリースに戻しました。オンコールエンジニアの通知が発火した時点 — 障害ではなくレシート用の通知 — では、本番トラフィックはすでに 9 分間、既知の良好なリリース上で動作していました。

誰も何もする必要はありませんでした。本シリーズの第 1 回の記事で述べたアーキテクチャは、4 つの段階が何であるかを記述しています。本記事は、人間の承認の合間で実際に何が動作するか — アーキテクチャの下層にある自動化レイヤー、すなわちパイプラインが自律的に正しい判断を下せるかどうかの境界 — についてです。

中心的な主張: パイプラインの判断の大半は自動化されるべきだが、すべてではない。境界が重要です。すべてを自動化するパイプラインは、いずれ人間が止めるべきリリースを昇格させてしまいます。何も自動化しないパイプラインは、存在意義がありません。その境界を正しく引くことが、本記事のテーマです。

自動化のスペクトラム

すべてのパイプラインの判断は、*「人間の通知なしで自律的に発火する」から「明示的な署名付き承認なしには進行を拒否する」*までのスペクトラム上のどこかに位置します。以下は、当社がリリース済みのパイプラインにおいて、負荷を担う各パイプライン動作がそのスペクトラム上のどこに位置するかを示したものです。

上の図のマーカーのうち 2 つは、ゾーンの色ではなく赤で示されています。これは非対称な判断 — パイプラインが「誰が何を呼び出してよいか」について強い立場を取る 2 つの場所 — です。自動ロールバックトリガーは問い合わせずに発火します。設定でオフにすることはできません。これを備えている目的そのものが、午前 2 時 14 分に機能することだからです。ゲートフェイルオーバーライドは書面の根拠なしには進行を拒否します。これも設定でオフにすることはできません。これを備えている目的そのものが、将来の自分がその理由を読む必要があることだからです。パイプラインのその他の部分の多くは設定可能ですが、この 2 つだけは違います。

自動ロールバックが実際にどう発火するか

自動ロールバックについて最もよく聞かれる質問は*「誤った理由で発火しないようにする仕組みは何か?」*です。正直な答えは「単独で防いでいる仕組みは何もない」です。保護は、このトリガーがどう配線されているかから生まれます。

Observe ステージは、1 分ごとのスコアリングループを実行します。毎分次を行います:

1. アクティブリリースから直近の本番トレースの小さなセットをサンプリング。
2. 各トレースをアクティブモデルで再生(候補ではなく — 実際に提供しているものをスコアリングしている)。
3. Gate-2^[1]を駆動したものと同じ、人間アンカー付きでキャリブレーションされたジャッジを使って各リプレイをスコアリング。
4. サンプル全体に対する単一の出力品質スコアを計算。これを CanaryHealthSample に書き込み。

ロールバックは、1 分ごとのサンプルが連続 3 回ロールバック閾値を下回ったときに発火します(既定値: ゲート閾値の 0.85 — つまりゲートが 0.65 なら 0.55)。1 分の悪化ではなく、3 分連続です。3 分間のロックアウトは最も安価なノイズフィルタであり、単発の異常値は何もトリガーしませんが、持続的な回帰は引き起こします。

ロックアウトが解除されると、ロールバックワーカーは次を実行します:

# 実際には — パイプラインが自律的にこれを実行する。人間の ack は不要。
POST /api/v1/releases/<previous_release_sha>/activate
# レスポンスは <1s; ~100 レプリカのサービスで処理中のドレインは ~12s

レシートが発火します。オンコールエンジニアは Slack の通知をレシート用に見るのであり、障害用ではありません。レシートを開くと、3 つの閾値未満の測定値、経過時間、そして vindex_sha256_before/after^[2] のハッシュが見えます。12 秒は処理中のドレイン時間で、スワップ自体は 1 秒未満です。エンジニアが「自分で何かする必要があるか?」と尋ねられるほど目が覚める頃には、その答えは「いいえ、ただしゲートがこれを通した理由は確認すべきです」になっています。

実際の自動ロールバックレシート

これが本番でのレシートの見た目です。コンプライアンスページに記載されているのと同じハッシュチェーン形式で、自動ロールバックイベント固有の追加フィールドが付加されています:

{
  "kind": "auto_rollback",
  "release_id": "rel_a01c66",
  "previous_release_id": "rel_8f72b1",
  "trigger_at": "2026-05-29T02:14:23Z",
  "completed_at": "2026-05-29T02:14:35Z",
  "elapsed_seconds": 12,
  "trigger_reason": "observer_quality_threshold_breach",
  "observer_readings": [
    { "minute_at": "2026-05-29T02:11:00Z", "quality_score": 0.523, "below_threshold": true,  "slice": "legal-IP-licensing" },
    { "minute_at": "2026-05-29T02:12:00Z", "quality_score": 0.508, "below_threshold": true,  "slice": "legal-IP-licensing" },
    { "minute_at": "2026-05-29T02:13:00Z", "quality_score": 0.491, "below_threshold": true,  "slice": "legal-IP-licensing" }
  ],
  "rollback_threshold": 0.55,
  "active_manifest_sha256_before": "9abaeaf6c91f8b...",
  "active_manifest_sha256_after":  "8f72b1de4a93c5...",
  "audit_chain_signature": "sha256(...)",
  "notified_users": ["oncall@customer.example"],
  "notification_sent_at": "2026-05-29T02:14:36Z"
}

レシートそのものが、オンコールにとっての最初の接点です。これを読めば、半分眠っているエンジニアが実際に尋ねるであろう質問 — 何がトリガーしたか、どのスライスが失敗したか、どれだけ失敗したか、スワップにどれだけかかったか、今何が動いているか — に答えが出ます。そこから次のアクションは通常*「そもそもゲートがこれを通した理由を確認しに行く」*になります — そして失敗したリリースのレシートにはスライス単位の Spearman テーブルがすでに含まれています。

パイプラインが自律的に行わないこと

「自動ロールバックは問い合わせずに発火する」の系として、その他のいくつかの動作は能動的に行えないようになっています。3 つの明示的な拒否があります。

ゲートに失敗したリリースを、署名付きオーバーライドなしには昇格させません。 ゲート失敗はリリースを gate_fail としてマークします。/activate エンドポイントはそのマニフェスト SHA を受け付けることを拒否します。これを回避するコマンドラインの呪文はありません。前進する唯一の道は、forceGateOverride: true AND overrideReason: "<自由記述>" による強制オーバーライドです。理由フィールドは必須で、自由記述、ユーザー ID と並んで監査ログに記録されます。将来の自分が、現在の自分がスライス回帰を許容と判断した理由を読めるよう設計されています。実際の運用でオーバーライドを使ったのは 3 人です。彼らの根拠は今も監査ログに残っています。

いずれかのモニターが劣化している場合、カナリアから 100% へ進行しません。 チェックポイント滞留終了時に p95 レイテンシ、5xx レート、または出力品質スコアのいずれかが帯域から外れている場合、パイプラインはそのチェックポイントで停止しページします。先に進んで後で謝罪する、ということはしません。

コールドスタートリリースを自動でカナリアに乗せません。 本番トラフィックの履歴がないリリース — 新しいデータセットに対する新規ファインチューニングなど — は、出力品質を比較する対象を持ちません。パイプラインはコールドスタートリリースでカナリアを開始することを拒否します。まず 24 時間のシャドーデプロイメントが必要で、これは候補を実際の本番トレースに対して観察しますが、応答は一切提供しません。24 時間後には品質ベースラインが得られます。その後、カナリアを進められます。遅い、誠実、そして設定不可です。

エンドツーエンドの復旧速度はどれくらいか

当社が公開している復旧時間の数値は 12 秒です。これは ~100 レプリカのサービスでの処理中のドレイン時間です。マニフェストスワップ自体は 1 秒未満です。読者にとって有用にするためには、12 秒を分解する必要があります:

• ロールバック前の 0〜60 秒: 連続 3 回の閾値未満の測定値が到着します。最初の閾値未満の測定値がロックアウトタイマーを開始します。その後の毎分、品質が依然として閾値を下回っていればロックアウトが延長されます。
• t = 0: 3 回目の閾値未満の測定値が CanaryHealthSample に書き込まれます。ロールバックワーカーが 3 回目のストライクを検知し、/activate previous_release を発行します。
• t < 1 秒: ルーティング層のアクティブリリースポインタ(Redis 上)が切り替わります。新しいリクエストは以前のリリースに到達し始めます。
• t = 1 〜 ~12 秒: 候補リリースは、スワップ時点で処理中だったリクエストの応答を継続します。処理中のドレインです。一部のストリーミング応答は自然に完了するまで 8〜10 秒かかるため、典型的なサービスではクリーンアップの尾は約 12 秒です。
• t ≈ 13 秒: 監査ログレシートが書き込まれ、署名されます。通知が発火します。

参照点として引用し続けている公開ポストモーテムと比較すると、Cloudflare の 2022 年 6 月の障害^[3]は「何を戻すべきか分かった」から「戻し作業完了」まで 44 分を要しました — しかもそれはインフラ層での話です。Atlassian の 2022 年 4 月の障害^[4]は、ステートが複数のシステムに分かれていたため、サイトごとに 12 時間を要しました。DORA^[5]の「エリートパフォーマー」のデプロイ失敗復旧の閾値は 1 時間未満です。12 秒はエリート閾値より一桁優れているのではなく、三桁優れています。これを可能にするアーキテクチャ上の判断は、Stage 1 のバンドル化されたリリースマニフェストです。マニフェストがなければ、ルーティングを再ポイントできる単一のオブジェクトが存在しません。

ロールバックドリル — 誰も実行しない地味な実践

ここはほとんどのチームが省略する部分です: ロールバック経路が機能するという唯一の信頼できるシグナルは、計画的にスケジュールされたドリルを実行して確認したことです。 四半期ごとに 1 回実行しています。ドリルは次の通りです:

1. ランダムにスケジュールされた、平日の営業時間帯を選びます。チームには来ることは伝えますが、具体的な時間は伝えません。
2. カナリアスライスに合成的な品質回帰を注入します。(候補モデルがマジックヘッダーに対して「回答を拒否します」と応答できるテストモードフラグを用意しています — キャリブレーションされたジャッジで確実に失敗します。)
3. テストリリースをゲートを通して押し込みます(通過します — 私たちはロールバックを試験しているのであり、ゲートではありません)。カナリアを開始します。
4. オブザーバーが連続 3 回の閾値未満の測定値を検知します。自動ロールバックが発火します。
5. オンコールエンジニアが反応するのを待ちます。反応にかかる時間を計測します。アラーム状態にページバックしないほどレシートを信頼しているかをメモします。
6. 監査ログのロールバックレシートにテストモードフラグが表示されることを検証し、将来の監査でドリルと実際のインシデントを区別できるようにします。

私たちが初めて実行したドリルはエンドツーエンドで 19 秒かかりました(12 秒のスワップ + 修正が必要だった 7 秒の整定遅延)。最も最近のドリル — 2026 Q1 — は 12 秒でした。ドリルを省略することはできません。四半期ごと、すべての顧客クラスタで。

ほとんどのチームは計画的なロールバックドリルを実行したことがありません。彼らのロールバック経路が初めて動作するのは、実際のインシデントの最中、プレッシャーの下、複数の人がコールに参加している状況です。ドリルこそが、12 秒という数値を「願望」ではなく「実数」たらしめるものです。

本記事が解決しないこと

3 つの率直な制限事項:

自動ロールバックはピンポンする可能性があります。 候補リリースと以前のリリースの両方が悪い場合 — 例えば以前のリリースにも誰も気づかなかった緩やかなスライス回帰があった場合 — パイプラインはロールバックでき、その後以前のリリースもロールバック後オブザーバーで失敗し、ロールバック先となる第 3 のリリースが存在しなくなります。パイプラインは右往左往するのではなく、メンテナンスページにトラフィックを止めます。修正策は、マニフェストチェーンに 1 つを超える健全なリリースをインデックス化し、ロールバック先を設定可能にすることです。

オブザーバーは推論コストを追加します。 5% サンプルでアクティブモデルを通して本番トレースを再生することは、推論コストに約 5% を追加します。これは正しいトレードオフだと考えています。一部の顧客は低マージンワークロードでは高すぎると感じ、サンプルレートを下げたいと考えます。そのダイヤルは存在します。

悪いジャッジはジャッジがないより悪いです。 オブザーバーを駆動するキャリブレーション済みジャッジ自体がミスキャリブレーションされている場合 — 人間アンカーから乖離している、または陳腐化したコーパスで訓練されている — オブザーバーは誤った理由で自動ロールバックを発火させる可能性があります。再キャリブレーションのケイデンスが重要です。Calibrating-the-Judge^[6]の記事に手順が記載されています。運用上の要件は、実際にそれを実行することです。

FAQ

なぜロールバックトリガーは 1 分ではなく連続 3 分なのですか?

LLM の品質スコアにはノイズフロアがあるからです — 1 分の異常な測定値は、サンプリングの偶然(5% のトレースサンプルがたまたま難しいスライスに当たった)から来る可能性があり、必ずしも実際の回帰ではありません。3 分間のロックアウトは、総反応時間を 1 分半未満に保ちつつ最も安価なノイズフィルタです。両方向にチューニングした結果、3 分が当社の顧客の典型的なトラフィック形状に対するスイートスポットでした。トラフィック形状が異なる場合、滞留時間はリリースごとに設定可能です。

自動ロールバックは「オフ」に設定可能にすべきですか?

当社のリリース済みパイプラインでは、いいえ。自動安全機構を備える目的は、誰も見ていない午前 2 時 14 分に機能することです。オフに設定可能な自動ロールバックは、「以前は安全網がありました」と書かれた付箋紙です。設定可能にすべきという論拠は、一部のワークロードは偽陽性のロールバックを正当化するには低リスクすぎる、というものです。私たちはその論拠が誤った場所に行き着くと考えます — ワークロードが自動ロールバックには低リスクすぎるなら、リリースパイプライン自体も必要ありません。

以前のリリースも悪かった場合はどう扱いますか?

ロールバック先は既定で previous_release ですが、マニフェストチェーンは N-1 だけでなくより多くの履歴を保存しています。オペレーターはロールバックを過去に健全だった任意のマニフェスト SHA に再ターゲットできます — /api/v1/releases/<historically_good_sha>/activate — これが自動 N-1 ロールバックが悪い古いリリースに当たったときの手動介入経路です。逃げ道は用意されています。まれです。

最適化すべき正しい指標は MTTR ですか、それとも MTBF ですか?

MTTR — 平均復旧時間 — がはるかに正しい指標です。少なくとも LLM システムにとっては。MTBF(平均故障間隔)は、LLM ワークロードが持たない決定論的な「失敗」の概念を前提とします。出力品質は連続的にドリフトします。「失敗」は閾値の判断です。高速な復旧を最適化することは閾値をどこに引くかに対して頑健ですが、決して失敗しないことを最適化することは脆く誤りです。DORA のエリート閾値^[5]自体も MTTR の用語で枠組みされており、それが正しいフレーミングです。

実際にロールバックドリルを実行していますか?

はい — 四半期ごと、スケジュール済み、レシートにテストモードフラグを含めることで監査ログ上で実インシデントと区別できるようにしています。私たちが初めて実行したドリルは、気づいていなかった 7 秒の整定遅延を露呈しました。ドリルこそが、経路が実際に機能することを知る唯一の方法です。ランブックを読むだけでは十分ではありません。ほとんどのチームは一度も実行したことがありません。それが、ほとんどのチームの MTTR 数値が測定値ではなく願望である理由です。

参考文献

1. LLM-as-judge のキャリブレーション。 Zheng ら、Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena(NeurIPS 2023)。なぜキャリブレーション済みジャッジが必要か、なぜスライス単位の一致が集約された一致より重要かの根拠。オブザーバーの 1 分ごとスコアリングループはこれに依存しています。
2. vindex ウェイトアテステーション。 Divinci コンプライアンスページに記載され、規制分野記事で解説されています。自動ロールバックレシートの `vindex_sha256_before/after` フィールドは、当社のログを信頼することなく監査人が検証できる暗号学的アンカーです。
3. Cloudflare 2022 年 6 月の障害。 Cloudflare outage on June 21, 2022。「06:58: 根本原因を特定し理解。問題の変更を戻す作業を開始… 07:42: 最後の戻し作業が完了。」インフラ層で戻しに 44 分かかった理由の一部は、エンジニアが互いの戻し作業に踏み込んだことです。「マニフェスト駆動のスワップにはその障害モードがあり得ない」という主張の根拠。
4. Atlassian 2022 年 4 月の障害。 Post-Incident Review: April 2022 Outage。サイトごとに復旧に 12 時間、883 サイトの合計で 14 日。ステートが独立してバージョン管理されたシステムに分かれていたためです。「バンドル化されたリリースマニフェストこそが、時間ではなく秒単位を可能にする」という主張の根拠。
5. DORA のデプロイ失敗復旧閾値。 DORA — Software delivery performance metrics。「デプロイ失敗復旧時間」のエリートパフォーマー閾値は 1 時間未満と記載されています。12 秒のパイプライン数値はエリート閾値より三桁低く、これが比較を読む正しい方法です。
6. AI ジャッジのキャリブレーション。 関連記事 Calibrating the AI Judge。人間アンカー付きジャッジを長期にわたってキャリブレーションに保つ手順。本記事の運用上の主張 — 自動ロールバックはそれを駆動するジャッジの良さの分だけ機能する — は、ジャッジが実際に定期的に再キャリブレーションされている場合にのみ成立します。
7. 内部 — Divinci パイプラインリファレンス。 この自動化レイヤーの基盤となるアーキテクチャ: 4 段階パイプラインの記事。API サーフェスの全容は API リファレンスに記載されており、リリース管理セクションが本記事で言及している部分です。

本シリーズの次回: 2026 年のカスタム言語モデル向け CI テスト。 本記事は人間の承認の合間の運用レイヤーについてでした。次回はパイプラインが開始される前のレイヤー — マージ前 CI: PR 時点で何を評価するか、ゲートに到達する前に実際にどの種類の回帰を捕捉するか、どの種類を捕捉できないか — についてです。