要約

AIコード生成 ロールアウト シミュレーターは、問題のあるAI生成変更が、巻き戻されるまでに月間エラーバジェットをどれだけ消費するかを示します。トラフィック、SLO、ロールアウトの段階、ソーク時間、検知速度を入力してください。単一の100%デプロイ、人間が監視する段階的ロールアウト、自動SLOゲートを比較します。計算は手で検算できる算術だけを使います。

無料のロールアウト計画ツール

AIが書いた変更が、ロールバックまでにどこまで広がるかを試算

AIコード生成 ロールアウト シミュレーターです。トラフィック、SLO、段階的ロールアウトの設定を入力すると、不具合のあるAI生成コード変更が、単一デプロイ、ダッシュボードを見る人間、自動ゲートのそれぞれで、エラーバジェットをどれだけ消費するかを表示します。

シミュレーターを実行 計算の仕組み

AIコード ロールアウト シミュレーター

各項目を変更すると結果がすぐに再計算されます。初期値は、1秒あたり200リクエストのサービスで、SLOが99.9%、変更により20%のリクエストが失敗する場合を想定しています。

ロールアウト計画
段階トラフィック開始時刻新しいコードが処理するリクエスト
仕組み

計算は3つの式だけ。隠れたモデルはありません

エラーバジェット

バジェット = (1 - SLO) × 1秒あたりの平均リクエスト数 × 2,592,000秒（30日）。200 req/s、99.9%の場合、月に許容される失敗リクエストは518,400件です。

時間経過による露出

ロールアウトの段階は、各分で新しいコードが受けるトラフィックの割合を示します。シミュレーターは最初のリクエストから、検知時間と巻き戻し時間を足した時点までその割合を積分するため、検知が遅いと変更はより大きな段階まで進んでしまいます。

失敗リクエスト

失敗数 = 1秒あたりのリクエスト数 × 失敗率 × 露出の積分。これをバジェットで割ると、問題のある変更1件が月間で占める割合になります。同じ段階で3つの検知方式を比較します。

実際の変更で使う

AIが生成した差分から、ロールアウト計画まで

  1. 1

    悲観的な入力を選ぶ

    AIコード生成ツールが書き、短時間でレビューされた変更は、間違っていた場合の失敗率を高めに設定し、人間が検知するまでの時間は直近で最も遅かったインシデントに合わせてください。最も良かった場合に合わせてはいけません。

  2. 2

    3つのシナリオを比較する

    単一デプロイは最悪ケースを示します。段階的ロールアウトで人間が監視する場合は、現在の段階で何が防げるかを示します。自動ゲートは、SLOの指標にもとづくゲートがあれば何が変わるかを示します。

  3. 3

    計画を運用手順書にコピーする

    コピーボタンは、段階と最悪ケースのバジェット消費率をプレーンテキストで書き出します。変更チケットやプルリクエストの説明にそのまま貼り付けられます。

段階の設計が重要な理由

最初の段階で、バジェットの大部分を守れます

1%のトラフィックで20%のリクエストが失敗する変更は、0.2%のリクエストで失敗を起こします。同じ変更が100%に届くと、5件に1件が失敗します。この2つの数字の差こそが、段階的ロールアウトを行う理由です。生成ツールが数秒で数百行を出力できる場合、1行あたりのレビュー時間は減り、最初の段階が問題を見つける場所になります。

  • 1%の最初の段階は、他の何かを計測する前に、影響範囲を99%抑えます。
  • ソーク時間が役立つのは、その時間内に回帰を検知できるシグナルがある場合だけです。
  • 速く巻き戻すことも、速く検知することと同じだけ価値があります。どちらも露出の積分に加算されます。
緑のランプの中に1つだけ黄色の状態ランプが点灯するサーバーラック
出力の読み方

3つの数値をどう判断するか

単一デプロイ

もっともらしい失敗を想定したとき、この数値が月間バジェットの5%を超えるなら、一度にデプロイすることは1件の変更にバジェットを使い切る判断です。意図してそれを選ぶチームはほとんどありません。

段階的、人間が検知

オンコール担当がグラフを見ている場合の現状です。ピーク露出が100%になるなら、段階は見かけだけです。問題のある変更は、誰かが対応する前に全員に届いてしまいます。

段階的、自動ゲート

SLOの指標を読み、確認なしに巻き戻すゲートの場合です。その価値は、ゲートがSLOと同じシグナルで作動する場合にのみ実現します。わざと問題のある変更でテストしてください。

よくある質問

このAIコード生成 ロールアウト シミュレーターは無料ですか？
はい。すべてブラウザ内で動作し、登録は不要です。匿名の利用ビーコン以外はサーバーに何も送信しません。このページ自体はAIコード生成ツールではありません。生成されたコードがパイプラインに届いた後、問題のある変更がどこまで広がるかをシミュレーションするものです。
数値はどこから来ますか？
手計算で確かめられる算術からです。エラーバジェットは（1 - SLO）× 30日間のリクエスト数です。失敗リクエストは、トラフィック × 失敗率 × 新しいコードが受けるトラフィック割合を、巻き戻しが完了するまで積分したものです。ベンチマークは組み込まれていません。すべての前提は入力値です。
人間が書いたコードと違う方法で、AI生成コードをモデル化すべきですか？
計算式は同じです。変わるのは事前の見積もりです。数分で生成された大きな差分は、1行あたりの人間によるレビューが少なくなっています。そのため失敗率と検知時間は悲観的な値にすべきです。どちらも、このページではなく自分のインシデント履歴から設定してください。
実際のトラフィックには当てはまらない、シミュレーターの前提は何ですか？
定常的なトラフィック、最初のリクエストから同じ割合のリクエストを失敗させる回帰、そして巻き戻しが完了した時点で被害が即座に止まることを前提としています。実際のインシデントには、徐々に増える影響、一部だけの失敗、遅いロールバックがあります。結果は予測ではなく、被害の下限として扱ってください。
自動SLOゲートにとって、検知時間はどのくらいが適切ですか？
メトリクスの解像度とアラートの時間窓によります。1分間のエラー率を閾値と比較するゲートは、2〜5分で作動することがあります。アラートが30分のバーンレート窓を経てからページングする場合は、その値を入力してください。そのコストをシミュレーターが示します。
ソーク時間を長くすれば、常に効果がありますか？
いいえ。ソーク時間が長いと、ゲートは段階ごとにより多くのデータを得られますが、問題のある変更が特定のトラフィック割合に留まる時間も長くなります。ゲートが2分以内に検知するなら、10分のソークは主に待ち時間を増やすだけです。15分かかるなら、5分のソークでは変更が先に25%以上へ到達してしまいます。
デプロイだけでなく、フィーチャーフラグのロールアウトにも使えますか？
はい。この計算では、フラグの段階的な公開はカナリアデプロイと同じ振る舞いをします。トラフィック割合、ソーク時間、検知の遅れ、巻き戻し時間です。巻き戻し時間は、フラグのキルスイッチの遅延に置き換えてください。

ゲートに巻き戻しまで任せたいですか？

upstreamapiは、SLOゲートと自動ロールバックを備えた段階的ロールアウトを提供しています。そのため、3列目の方式こそ本番で使うべきものです。

upstreamapiを見る