Divinci AI で LLM CI/CD パイプラインを構築する方法

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

LLM を通常の CI/CD パイプラインでリリースしようとした最初の試みでは、ビルドはグリーンに通り、デプロイは成功し、そして 7 分以内にカスタマーサポートにチケットが入り始めました。

「壊れた」ものは何もありません。4,200 件すべての統合テストはパスし、レイテンシも変わらず、200 OK のレートも安定していました。しかし、ある特定の種類の法務領域の質問について、新しいモデルがひっそりとヘッジを始めていたのです — 以前のバージョンが正しく答えていた質問にコミットせず、回答を避けるようになっていました。私たちはまだそのテストを書いていなかったため、どのテストもこれを検出できませんでした。

私たちはロールバックしましたが、そのロールバック自体がひとつのイベントでした。モデルアーティファクトは 3 つの場所に存在し、プロンプトテンプレートは 4 つ目の場所、ルーティングルールは 5 つ目の場所にあり、どれもお互いのことを知りませんでした。以前の良好な状態に戻すまでに 2 時間強かかりました。その間にヘッジ回答を受けた顧客は、お世辞にも満足したとは言えませんでした。

このパイプラインが存在する理由は、その障害にあります。以下は、私たち自身のリリースで実際に運用しているパイプラインであり、また顧客が自社のリリースに使えるよう Divinci API 経由で公開しているものです。register、gate、roll、observe の 4 段階で構成され、すべてのステップに、人間が起きていることを前提としないロールバック経路があります。

4 つの段階

各段階は意図的に厳格にしてあります。すべてのリリースは、この順序で各段階を通過します。評価をスキップする「ホットフィックス」経路は存在しません — 一度試して、結果は分かりました。

Stage 1 — Register

リリースとは、モデルのウェイトファイルではありません。リリースとは、以下をバンドルしたイミュータブルなマニフェストです:

• モデルアーティファクト(HF リポジトリ + コミット SHA、または vindex パッチ)
• プロンプトテンプレート(すべての変数、すべてのシステムメッセージ)
• ルーティングルール(どのトラフィッククラスがどのバージョンに着地するか)
• ゲートしきい値の計算に使われたデータセットバージョン
• 直前のリリースの SHA(ロールバックを一意に決定するため)

curl -X POST https://api.divinci.ai/v1/releases \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -d '{
    "model_ref": "Divinci-AI/gemma-4-e2b@a7c91f",
    "prompt_template_ref": "templates/legal-qa@v14",
    "routing": { "domain": "legal" },
    "dataset_version": "scored-qa-medical-v3",
    "previous_release": "rel_8f72b1"
  }'
# → { "release_id": "rel_a01c66", "manifest_sha256": "9abaeaf6..." }

マニフェスト SHA が、パイプライン内で誰もが扱う唯一のハンドルです。2 人が同じリリースだと思ってデプロイしようとしても、SHA が異なっていればパイプラインがそのデプロイを拒否します。このルールによって、これまでに 2 つのバグを未然に防ぎました。

Stage 2 — Gate

ゲートこそ、ほとんどの CI パイプラインが取り違える部分です。Lighthouse 的なヒューリスティック — perplexity、BLEU、ROUGE — は、リグレッションがひとつのドメインに集中している場合、それをすり抜けさせてしまいます。集計スコアでは洗い流されてしまうのです。

Divinci のゲートは、リリースマニフェストとともに登録された scored-QA スイートを実行し、カテゴリ単位で Spearman しきい値を適用します:

上のチャートのリリースは、集計ゲートであれば通過してしまいます(平均 0.64 は「ほぼ十分」)。しかし Divinci のゲートでは失敗します。なぜなら IP ライセンスが従来の 0.68 から 0.41 へと急落しているからです — まさに、ノートブックでは決して捕捉できない局所的リグレッションです。

私たちは面白半分にスライス単位ゲートを発明したわけではありません。これは、現行の LLM ポストモーテムで直接名指しされている故障モードです。Tianpan の “The Semver Lie” の解説^[6]では、あるプロンプト変更が「コードレビューを通り、評価ゲートなしでデプロイされ、ユーザー単位の A/B なしで本番に到達し、自動ロールバックもトリガーされなかった」と記されています。このインシデントを単なる迷惑ではなく壊滅的なものにしたのは、リグレッションが集計では維持されていながら、ひとつのスライス — ひとつのユーザージャーニークラス — に集中していたことです。2026 年に調査したすべての LLM リリースツールは、単一のグローバルスコアでゲートを設けているか、まったくゲートしていないかのどちらかでした。ゲートをスライスしているものはひとつもありません。

ゲート失敗は、ソフトな警告ではありません。release_id は gate_fail としてマークされ、マニフェストはアーカイブされ、いかなる deploy コマンドもそれを受け付けません。コールドスタートのリリース — 比較対象となる過去の Spearman を持たない真新しいモデル — は、ワンタイムの --force-gate-override 経路を通り、そこには書面での理由付けが必須です。理由、ユーザー ID、gate_override_sha256 がそのまま監査証跡に入ります。オーバーライドが存在するのは正当なケースがあるからで、監査証跡が存在するのは将来の自分がその理由を読む必要があるからです。

Stage 3 — Roll

Divinci におけるカナリアとは、5%、25%、100% の 3 つのチェックポイントを意味します。各チェックポイントで、パイプラインは設定された滞留時間または設定されたリクエスト数のいずれか遅い方まで保持します。デフォルトは 5% で 4 分 / 1,000 リクエスト、25% で 15 分 / 10,000 リクエストです。

各チェックポイントで、3 つのモニターが基準を満たす必要があります:

1. p95 レイテンシ: 直前リリースの p95 の 1.2 倍以内
2. 5xx レート: 直前リリースのレートの 1.5 倍以内
3. 出力品質モニター: 最近の本番トレースを候補リリースに対して継続的にリプレイし、Stage 2 を駆動したのと同じキャリブレーション済みジャッジでスコアリング

3 つ目こそ、ほかのどのリリースパイプラインも提供していないものです。SageMaker、KServe、BentoML、Vertex AI — いずれもレイテンシとエラーレートを監視します。しかし、いま本番で問われている実際の質問に対する候補の出力をスコアリングするものはありません。候補はアクティブリリースが受け取ったのと同じプロンプトを受け取り、それを 5% のミラーで実行し、キャリブレーション済みグレーダーに対する候補回答の Spearman ρ を計測します。モデルが静かにヘッジしたり、拒否したり、ハルシネーションを起こしていても、5xx レートはクリーンなままになり得ます。実際にこれが起きるのを私たちは目撃しています。それを捕捉するのが、このトレースリプレイモニターです。

リプレイ集合には上限があり、コストを予測可能にするため、チェックポイントごとに各スライスにつき最近のトレースを 50 件に制限しています。5% トラフィック時点で、グレーディングには約 90 秒かかります。固定パーセンテージカナリアより遅く、顧客がチケットを起票するのを待つより速い、という塩梅です。

# roll コマンドは fire-and-forget です。パイプラインが自身で保持します。
curl -X POST https://api.divinci.ai/v1/releases/rel_a01c66/roll \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -d '{ "strategy": "canary", "dwell_5pct_seconds": 240, "dwell_25pct_seconds": 900 }'
# → { "rollout_id": "rol_b3e2", "next_checkpoint_at": "2026-05-26T09:04:00Z" }

Stage 4 — Observe、ロールバック、そしてレシート

この段階こそ、パイプラインの存在意義を成り立たせる段階です。

オブザーバーはロールアウト完了後も継続的に動作します。ローリング 5% のトレースリプレイサンプルで、分単位の出力品質スコアを計算します。スコアがロールバックしきい値(デフォルト: ゲートしきい値の 0.85 倍。ゲートが 0.65 なら 0.55)を 3 分連続で下回ると、ロールバックが自動的に発火します。ページャー呼び出しも、人間の判断も、議論もありません。

ロールバックそのものはひとつの命令です — ルーティングをマニフェストの previous_release に再ポイントすること。直前のリリースは完全にバンドルされたマニフェストだったため、ウェイト、プロンプト、ルーティング、データセット — すべてのコンポーネントがアトミックに切り替わります。

そしてレシートが発火します。

すべてのリリース判断 — register、gate-pass、gate-fail、gate-override、checkpoint-promote、checkpoint-hold、auto-rollback、manual-rollback — は、リリースレシートを発行します: JSON-with-SHA-256 形式のアーティファクトで、その顧客の前のレシート、およびそのリリースの前のレシートとハッシュチェーンで連結され、顧客が設定したスケジュールで外部に錨を打ち込みます。

リリースがオープンウェイトモデル — Gemma、Qwen、Llama、Mistral、GPT-OSS、ウェイトがアドレス指定可能で編集可能なあらゆるもの — に支えられている場合、レシートは vindex アテステーションを埋め込みます: 判断時点のアクティブなウェイトが、マニフェストに登録されたウェイトと一致することの暗号学的証明です。これが、より厳しいコンプライアンス要件(GDPR 第 17 条 忘れられる権利、EU AI Act の出所性)を満たす経路です。なぜなら、何がデプロイされたかだけでなく、基盤となるウェイトが主張されたとおりのものであることまで証明できるからです。

リリースがクローズドウェイトモデル — OpenAI、Anthropic、Google、不透明な API 経由でしか提供されないもの — に支えられている場合、レシートは引き続き判断の連鎖(どのマニフェスト、どのゲート結果、どのモニター読み取り値、どのユーザーがどのアクションをトリガーしたか)をカバーしますが、基盤ウェイトをアテストすることはできません。なぜなら、私たちにはそれが見えないからです。これはパイプラインの限界ではなく、プロバイダーがウェイトを公開しない場合に検証可能な範囲の限界です。この区別を重視する監査人は、レシート自体の中で正直な答えを得られます。

いずれにしても、現在の監査人はログを得ているだけです。このパイプラインを使えば、実際に証明可能なすべてに関する証明を得られます。市場でこれを提供している事業者はほかに見当たりませんでした。いずれは登場すると見ています — EU AI Act のタイムラインを考えれば、それは必然です。私たちはいま提供することを選びました。

これらは私たちの数値ではありません — 実際のポストモーテム、プラットフォーム文書、および DORA フレームワークの公開された一次出典の数値です。このコントラストこそが Divinci の設計を動機づけています。Atlassian の 2022 年 4 月の障害^[1]がサイトあたり 12 時間かかったのは、状態が複数のシステムにまたがって分散しており、それらを再び整合させるために調整が必要だったからです。Cloudflare の 2022 年 6 月の障害^[2]がリバートに 44 分かかったのは、彼ら自身の言葉によれば、エンジニアたちが互いのリバート作業を踏みつぶし合ったからです。AWS SageMaker のカナリアデプロイメントガードレール^[4]は、ロールバックが完全に完了するまでにデフォルトで 10 分のターミネーション待機を文書化しています。DORA^[3] の障害デプロイ復旧におけるエリートしきい値は「1 時間未満」 — これはハイパフォーマンスな組織が超えるべきバーであって、上限ではありません。

12 秒も魔法の数字ではありません。ルーティングレイヤーがインフライトのリクエストをドレインし、アクティブマニフェストをスワップし、新しい状態をリージョン間で ACK するのに必要な時間です。遅いのはインフライトドレインです。生成途中のレスポンスをドロップしない限り、これより速い経路はありません。

ほかの LLM リリースツールにはなくて、これにはあるもの

このパイプラインを構築する前、2026 年に他の 12 のツールを調査しました — LangSmith Deployment、W&B Models、MLflow、SageMaker Deployment Guardrails、Vertex AI Endpoints、Seldon Core、BentoCloud、KServe、Humanloop、Braintrust、Patronus AI、Arize Phoenix。これらは、噛み合わない 2 つの陣営にクラスタリングされます。

eval-CI 陣営 — Braintrust、Humanloop、Patronus — は、オフライン評価スコアで PR マージをゲートします。稼働中のサービスには一切触れません。本番でモデルの品質が落ちると警告は出しますが、ロールバックは別の誰かがやらなければなりません。

serving-canary 陣営 — SageMaker Deployment Guardrails、KServe、Vertex AI、BentoCloud、Seldon Core — はトラフィックを分割し、自動ロールバックを行います。しかしいずれも、トリガーするのはインフラメトリクス、つまり p99 レイテンシ、エラーレート、CloudWatch アラームです。品質リグレッションで自動ロールバックするものはひとつもありません。彼らにはできません。なぜなら、本番出力に対してジャッジを走らせていないからです。

「PR マージ時に評価をパスした」と「実際に重要なユーザージャーニーで本番カナリアをスコアリングする」の間の縫い目は、現状すべてのチームが手作業で橋渡しせざるを得ない手動の引き継ぎです。冒頭のブログ記事は、これを 2026 年における支配的な故障モードだと指摘しています^[6]。私たちはそれを閉じました。具体的には:

1. ゲートをスライス化している。 単一のグローバルスコアではなく、人間アンカー付きグレーダーに対するドメイン単位の Spearman ρ。スライス盲目性こそ、ほかのすべてのゲートが抱える問題です。
2. カナリアが p95 だけでなく出力品質を監視する。 候補に対する継続的なトレースリプレイを、ゲートを駆動したのと同じジャッジでスコアリング。これが欠落していた縫い目です。
3. すべての判断がリリースレシートを発行する。 ハッシュチェーン化され、外部に錨を打ち込み可能で、コンプライアンスページを支えるのと同じ JSON-with-SHA-256 形式。オープンウェイトモデルバッキング — Gemma、Qwen、Llama、Mistral、GPT-OSS — の場合、レシートは vindex ウェイトアテステーションを埋め込み、監査人はライブのウェイトが実際に何であったかを証明できます。クローズド API バッキングの場合、レシートは判断の連鎖をカバーしますが、プロバイダーがウェイトを公開していないため、ウェイトの出所性を主張することはできません。いずれの場合も、監査人は単なるログではなく、実際に証明可能なものの証明を得ます。

それだけです。汎用カナリア、バージョンレジストリ、インフラメトリクスベースのロールバック — それらはコモディティです。私たちは汎用カナリアを書いたのではありません。

このパイプラインが解決しないこと

正直な制約を 3 つ挙げます:

ゲートはデータセットの良さ次第。 顧客が実際に使っているドメインをカバーしていない scored-QA スイートは、そのドメインのリグレッションを捕捉できません。これを 2 度目撃しました。どちらの場合も、顧客の最初の動きはモデルを変えることではなく、新しい scored-QA スイートを出荷することでした。これが正しい動きです。

ロールバックは直前リリースが良好であることを前提とする。 リグレッションが 3 リリース連続で本番にあり、誰も気付かなかった場合、1 リリース戻しても、わずかにマシなモデルを買えるだけです。監査証跡はここで役立ちます — SHA で任意の過去マニフェストにロールバックでき、N-1 に限定されません。

コールドスタートのリリースはカナリアをバイパスする。 比較対象の本番トラフィックを持たない真新しいモデルは、意味のあるカナリアができません。代わりに 24 時間のシャドウデプロイメントを強制し、出力を提供することなく観察します。これは時間がかかり、利便性も低い方法です。しかし、これが唯一の正直な答えでもあります。

これを自前で動かす最小版

Divinci を使わずにこのようなものを立ち上げたい場合、最低限のバージョンはおおよそ次のとおりです:

1. モデル + プロンプト + ルーティング + データセットを単一のイミュータブルなアーティファクトとして保存し、コンテンツハッシュでアドレス指定するレジストリ
2. Spearman ρ で人間アンカーパネルに対してキャリブレーションされたジャッジ — そして、集計だけでなくスライス単位のスコアを参照するゲート判断
3. チェックポイントで保持し、新鮮度に上限のある品質モニターを参照するトラフィックスプリッター — モニターは合成サンプルではなく最近の本番トレースを候補にリプレイする
4. ウェイトだけでなくプロンプトテンプレートも含めて状態をアトミックにスワップできるルーティングレイヤー
5. すべてのリリース判断について、ハッシュチェーン化され外部に錨を打ち込めるレシートを発行する監査ログ — モデルがオープンウェイトの場合はウェイトアテステーションを埋め込み(クローズド API のリリースはウェイトレベルで物理的にアテスト不可能なため)

ほとんどのチームはすでに (1) と (3) を持っています。痛みを伴うのは (2)、(4)、(5) です。Divinci が存在する理由は、私たちがまず自分たちのためにこの 5 つすべてを構築し、その後、ほかの誰もがこれを必要とすることになると気付いたからです。

ビルドをスキップしたい場合は、API リファレンスはこちらで、「Release Management」セクションのリリースエンドポイントが、このパイプラインの全表面です。コンプライアンス面 — それらの vindex レシートがどのように見え、EU AI Act、GDPR 第 17 条、HIPAA、NIST AI RMF にどうマッピングされるか — はコンプライアンスページにあります。本記事のすべてのコマンドは、実在するエンドポイントです。

参考文献

1. Atlassian — Post-Incident Review: April 2022 Outage。記事より: 「加速された Restoration 2 アプローチでは、サイトの復旧に約 12 時間を要した」。883 件の顧客サイトの完全復旧には 14 日かかった。状態がインフラ、バックアップ、サイト単位の検証にまたがって分散していることが、サイト単位の数値を分ではなく時間単位に押し上げる。
2. Cloudflare — Cloudflare outage on June 21, 2022。投稿に逐語的に引用されているタイムライン: 「06:58: 根本原因を特定し理解。問題のある変更のリバートを開始… 07:42: 最後のリバートが完了」。「何をリバートすべきか分かった」から「リバートが完了した」までに 44 分。一部は、エンジニアが互いのリバート作業を踏みつぶし合ったため。
3. DORA — Software delivery performance metrics。「障害デプロイ復旧時間」のエリートパフォーマー閾値は 1 時間未満として文書化されている。DORA の過去レポートでは、低パフォーマーは数週間から数ヶ月で計測される。
4. AWS SageMaker — Use canary traffic shifting および関連の Auto-Rollback Configuration and Monitoring ページ。例示の TerminationWaitInSeconds は 600(10 分)、MaximumExecutionTimeoutInSeconds は 1800(30 分)で上限。ベイキングウィンドウ内でアラームが発火するとロールバックが起動: 「ベイキング期間中にアラームのいずれかが発火した場合、SageMaker AI はロールバックを開始し、すべてのトラフィックは Blue フリートに戻る」。
5. Divinci AI — リリースマニフェスト経由のアトミックなルーティングフリップ。12 秒は約 100 レプリカのサービスにおけるインフライトドレイン時間。マニフェストスワップ自体はサブ秒。この数値はベンチマークではなく自社サービス由来。これを可能にするアーキテクチャは、上記(Stage 1 — Register)で説明したバンドルマニフェスト。
6. Tianpan — The Semver Lie: how an LLM minor update breaks production (April 2026)。記事は故障パターンを直接名指ししている: 「コードレビューを通り、評価ゲートなしでデプロイされ、ユーザー単位の A/B なしで本番に到達し、自動ロールバックもトリガーされなかった」。関連記事 — LLM postmortem template — fields SRE missed — では、現状のポストモーテムが体系的に省いているスライス / ジャーニー / ユーザー単位のフィールドを列挙している。

このチャートに含まれていないものについてのメモ。Kubernetes の kubectl rollout undo 時間は、maxSurge / maxUnavailable の設定と Pod のウォームアップに支配され、コマンド自体ではありません。上記 4 つの出典のように測定された数値を公開している一次資料を見つけられなかったため、推定値で埋めるのではなく省きました。

シリーズ次回: カスタム LM で捕捉した 10 件の CI/CD リリース失敗と、パイプラインのどの段階が各々を捕捉するか。 10 件のうち 3 件は、集計ゲートが見逃したであろうスライス単位のリグレッションです。さらに 2 件は、インフラメトリクスベースのカナリアが昇格させてしまったであろうサイレントな品質低下です。残りは、どのリリースパイプラインも本来捕捉すべき種類の故障モードです — これらを並べるのは、集計ゲートのパイプラインでも実際に自力で捕捉できるものはどれか、を明言する価値があるためです。