release-readiness

「問題ないと思います」では、金曜日の午後6時に、練習したことのないロールバックでは取り消せないバグを出荷してしまいます。このスキルでは、「リリース可能」を測定可能な状態にします。各項目の根拠を示す go/no-go チェックリスト、5分未満で完了するスモークテストスイート、指標を条件とした昇格を伴う段階的ロールアウト、デプロイ前に定義するロールバックのしきい値、デプロイ後の検証を用意します。どのセクションにも、願望ではなく具体的な基準が示されています。

---

確認事項

まず .agents/qa-project-context.md を確認してください。存在する場合はその内容を使い、すでに回答されている質問は省略します。その後、不足していることだけを尋ねてください。

リリースの頻度とプロセス：

• リリースの頻度と go/no-go の判断者を教えてください。（継続的／毎日／毎週のリリースか、エンジニアリングリード／QA リード／リリースマネージャーかによって、チェックリストの厳密さが決まります。）
• リリーストレインのスケジュールがありますか。それとも随時リリースですか。
• 開発環境から本番環境までの間に、いくつの環境がありますか。（ステージング、プリプロダクション、カナリア）

現在の状況：

• 現在の go/no-go プロセスはどのようなもので、文書化されていますか。
• リリースをロールバックしたことはありますか。完了までどれくらいかかりましたか。（ロールバックが実際に可能なのか、単なる理想なのかがわかります。）
• 直近のリリースインシデントと、その根本原因は何でしたか。現在、リリースを阻止するバグはありますか。

インフラストラクチャと機能：

• ロールバック機能はありますか。ロールバックにはどれくらいかかりますか。
• 段階的／カナリアデプロイは可能ですか。
• フィーチャーフラグはありますか。どのように管理していますか。（フラグによるロールアウトと、インフラストラクチャレベルのロールアウトのどちらにするかが決まります。）
• どのようなモニタリングとアラートが導入されていますか。データベースのマイグレーションは元に戻せますか。

チームとコミュニケーション：

• リリース中とリリース後のオンコール担当者は誰ですか。
• 関係者への通知方法と、リリース用の連絡チャネルの有無を教えてください。
• リリースノートはどのように作成していますか。

---

基本原則

1. リリースへの確信は、感覚ではなく根拠から得られます

「問題ないと思います」は go/no-go の基準ではありません。根拠とは、すべての CI パイプラインが成功していること、ステージングでスモークテストに合格していること、パフォーマンス予算を満たしていること、未解決の P0/P1 バグがないことです。データを示せないなら、リリースの準備はできていません。

各結果を、候補コミット、デプロイ済みビルド、環境、設定、実行時刻に紐づけてください。最初の試行での失敗と再試行の結果を保持してください。合格、失敗、スキップ、ブロック、未実行のチェックは、それぞれ分けて記録してください。終了コードが成功でも、対象外にされたテストが隠れていることがあります。変更後の準備状況を示す根拠として、以前のコミットの根拠を使うことはできません。決済サンドボックスを利用できない場合、決済チェックは合格ではなくブロックとして記録してください。指名された承認者の実際の判断は QA の推奨とは別に記録し、楽観的な見方から承認を推測しないでください。

2. スモークテストは最後の安全網であり、安全網のすべてではありません

スモークテストは致命的な障害を検出しますが、開発サイクル全体を通した十分なテストの代わりにはなりません。スモークテストスイートだけが本番環境との間にあるなら、上流のプロセスに問題があります。

3. 段階的ロールアウトで影響範囲を抑えられます

ユーザーの100％に同時にデプロイすると、バグがあればユーザーの100％に影響します。段階的ロールアウト（カナリア、割合ベース、リングベース）なら、すべてのユーザーではなく1％のユーザーに影響している段階で問題を検出できます。

4. ロールバックの基準はリリース前に定義する必要があります

何かが炎上してからロールバックするかどうかを決めていたのでは、重要な時間を議論に費やしてしまいます。基準はベースラインを基に事前に定義してください。「15分以内にエラー率がベースラインの2倍を超えたら、ロールバックします。議論は不要です。」トリガーを DORA の目標値に結び付けてください。エラー率が変更失敗率の目標値を超える原因となるリリースや、復旧によって MTTR の目標値を超えてしまうリリースを止めるために、ロールバックルールを設けます。

5. すべてのリリースは学びの機会です

デプロイ後の検証は、バグの検出だけが目的ではありません。うまくいったこと、時間がかかったこと、ストレスになったことを記録してください。プロセスを継続的に改善してください。

---

現在のローカル証拠を収集する

QA Skills のチェックアウトがすべて揃っている場合は、候補の設定済みチェックに対して node <qa-skills>/scripts/qa.mjs run --project <project> --goal "Check release readiness" を実行します。report.html と result.json の両方を読みます。 失敗、ブロック中、未完了、スキップ、未実行の項目はすべてリリース チェックリストに含めます。レポートは記載されたチェックの証拠であり、自動的なリリース承認ではありません。 risk-based-testing を使って、現在のテストスイートに含まれていない重要なフローを特定し、 Go／No-Go を推奨する前に、それらのドメインワークフローを実行します。

Go／No-Go チェックリスト

これをテンプレートとして使用してください。状況に合わせて調整してください。各項目は、「確認した」だけでなく、証拠によって検証できる必要があります。記入済みのチェックリストは、バージョン管理された成果物（例：RELEASE-<version>.md または追跡対象の課題）として保存し、承認記録を監査できるようにしてください。

チェック項目、候補／ビルド、環境、コマンドまたはレポートへのリンク、 実行時刻、結果、未解決のギャップを含む証拠テーブルを用意してください。準備状況のレビューは、正当に No-Go の推奨と証拠不足を残して終了する場合があります。チェックリストを完全に見せるために、デプロイやデプロイ後の作業を行う必要はありません。

自動チェック（必須）

• すべての CI パイプラインが成功 — 単体テスト、統合テスト、E2E テスト、型チェック、リンティング
• ステージング環境でスモークテストスイートが成功 — ステージング環境で重要なユーザージャーニーを検証済み
• このリリースに関する未解決の P0／P1 バグがない — 課題トラッカーを確認し、マイルストーン／ラベルで絞り込み
• パフォーマンス予算を満たしている — API の応答時間とバンドルサイズがしきい値内。フロントエンドのリリースでは Lighthouse CI を使用（API／バックエンドのみのリリースでは Lighthouse を省略 — ページの読み込みを測定するものであり、サービスの健全性を測定するものではありません）
• セキュリティスキャンに問題がない — npm audit／Snyk／Dependabot で高または重大な脆弱性がない
• API コントラクトテストが成功 — 公開 API に破壊的変更がない
• ビジュアルリグレッションテストが成功 — 意図しない視覚的変更がない
• アクセシビリティチェックが成功 — axe-core のスキャンで新たな違反が検出されない

手動チェック（Go の前に確認）

• フィーチャーフラグを確認済み — このリリースで有効／無効にするフラグを記録し、本番環境での状態を確認
• モニタリングとアラートを設定済み — 新機能に対応するアラート（エラー率、レイテンシー、ビジネスメトリクス）がある
• ロールバック計画を文書化し、テスト済み — 手順書があり、ステージング環境でロールバックを実施済み
• データベースのマイグレーションをテスト済み — 前方マイグレーションをテスト済み。スキーマ変更を元に戻せる場合は、後方マイグレーションも検証済み
• サードパーティ依存関係の変更をレビュー済み — 新規またはアップグレードされた外部依存関係について、破壊的変更がないか確認
• リリースノートを準備済み — 変更履歴を更新し、関係者向けの概要を作成
• オンコールエンジニアを特定済み — 担当者が対応可能で、リリース内容を把握している
• コミュニケーション計画を準備済み — 関係者にリリース予定を知らせ、サポートチームに変更点を共有
• 競合するリリースがない — 他のチームが同時にデプロイしていない
• デプロイ時間帯を確認済み — トラフィックのピーク時や週末前（継続的デプロイの場合を除く）にはデプロイしない

リスク評価

• 変更範囲を分類済み — 小（設定変更、文言更新）、中（新機能、リファクタリング）、大（アーキテクチャ変更、マイグレーション）
• 影響範囲を推定済み — 問題が発生した場合、ユーザーの何％に影響する可能性があるか
• 元に戻す際の複雑さを評価済み — 5 分未満で元に戻せるか。元に戻す際にデータマイグレーションが必要か

---

スモークテストスイートの設計

含める内容

スモークテストでは、重要なユーザージャーニーのみを対象にします。これらが失敗する場合、アプリケーションに根本的な問題があります。

一般的なスモークテストスイート（5～8件）：

1. アプリケーションの稼働状況 — ホームページが読み込まれ、200を返し、コンソールにJavaScriptエラーがない
2. 認証 — ユーザーが有効な認証情報でログインでき、セッションが確立される
3. コアワークフロー — 主な価値を提供する操作が機能する（例：ドキュメントを作成する、フォームを送信する、カートに追加する、購入フローを完了する）
4. データ取得 — 主要なデータが正しく読み込まれる（ダッシュボードにデータが表示される、検索結果が返される、製品ページが読み込まれる）
5. 決済／取引（該当する場合） — テスト用認証情報で決済フローが完了する
6. APIの稼働状況 — 主要なAPIエンドポイントが、正しいスキーマで有効なレスポンスを返す
7. ナビゲーション — 重要なナビゲーション経路が機能する（ディープリンク、リダイレクト、メニュー項目）
8. エラー処理 — 無効なルートに対して、アプリケーションがユーザーフレンドリーなエラーページを表示する（404）

含めない内容

• エッジケース（回帰テストの対象です）
• 視覚的な完成度（ビジュアル回帰テストの対象です）
• パフォーマンスベンチマーク（パフォーマンステストの対象です）
• 網羅的なフォーム検証（単体テスト／統合テストの対象です）

高速に保つ

目標：スモークテストスイート全体を5分以内に完了します。

• 可能な場合はテストを並列実行します
• セットアップにはUI操作ではなくAPI呼び出しを使います（登録フォームではなく、API経由でテストユーザーを作成します）
• 重要度の低いアサーションは省略します（文言が完全に一致するかではなく、要素が存在するかを確認します）
• 専用のテストアカウントを使い、データを事前に作成しておきます（実行のたびにデータを一から作成しません）
• 不要な待機を避け、スマートな待機を使います（sleep(3000)／waitForTimeoutではなく、要素が表示されるまで待機します）

環境別のスモークテスト

ステージングのスモークテスト：

• スモークテストスイート全体（5～8件）
• テスト用決済プロバイダーを使用できます
• 今後のリリース設定で、フィーチャーフラグを有効にした状態でテストできます
• データベースのマイグレーションをテストできます

本番環境のスモークテスト：

• ステージングのスモークテストの一部（3～5件）
• 合成テストアカウントを使用します（分析に影響しないよう、明確にラベル付けします）
• 実際の決済取引では絶対にテストしません（サンドボックスモードを使用するか、省略します）
• アプリケーションの読み込み、認証、コアとなる読み取り操作、APIの応答に重点を置きます

デプロイ後のスモークテスト：

• デプロイ完了後、すぐに（60秒以内に）実行します
• 本番環境のスモークテストと同じ内容です
• いずれかが失敗した場合は、アラートを発報し、ロールバックの評価を開始します

ステージング環境は本番環境ではありません。データ量、トラフィックパターン、サードパーティの設定、インフラストラクチャの規模が異なります。この差があるからこそ、ステージングでの検証に加えて、本番環境およびデプロイ後のスモークテストが必要です。

---

段階的ロールアウトの検証

ロールアウトの段階

一般的な段階的ロールアウトです。フラグベースのロールアウトで同じ段階を設ける場合は、25%の段階が追加されます（下記を参照）。

段階	トラフィック割合	期間	目的
カナリア	1%	15～30分	クラッシュ、例外、明らかな障害を検出する
アーリーアダプター	10%	1～2時間	エラー率、レイテンシー、ビジネス指標を検証する
部分ロールアウト	25～50%	2～4時間	大規模環境での安定性を確認する
全面ロールアウト	100%	—	デプロイ後24時間、監視する

段階間で監視する項目

次の段階に進む前に、以下のすべてを確認します。

エラー指標：

• エラー率（HTTP 5xx）がベースラインを上回っていない
• 例外の件数がベースラインを上回っていない
• ログに新しい種類のエラーが現れていない

パフォーマンス指標：

• P50およびP95のレイテンシーが許容範囲内にある（絶対的な上限ではなく、ベースラインとの比較）
• タイムアウトエラーが増加していない
• データベースクエリの所要時間が安定している

ビジネス指標：

• コンバージョン率が低下していない
• ユーザーエンゲージメント（ページビュー、アクション）が安定している
• 収益／取引量が通常どおりである（該当する場合）

インフラストラクチャ指標：

• CPUおよびメモリの使用量が正常である
• キューの深さやメッセージの滞留が増加していない
• 新たなロギングによるディスク容量の問題がない

自動プロモーションの基準

ステージ間の自動プロモーションルールを定義します。各ゲートは、エラー率の上限、ベースラインに対する相対値で示すレイテンシの上限、安定性の監視期間、さらに上位ステージではビジネスメトリクスのガードレールを組み合わせます。canary→10%→50%→100% の完全なプロモーションルールについては、references/rollout-automation.md を参照してください。

フィーチャーフラグによる段階的ロールアウト

インフラレベルのカナリアデプロイに代わる方法です。

1. フィーチャーフラグを OFF にして、新しいコードを 100% にデプロイします
2. まず内部ユーザーに対してフラグを有効にします（ドッグフーディング）
3. ユーザーの 1% に対して有効にします（カナリア相当）
4. 徐々に割合を増やします：10%、25%、50%、100%
5. ロールアウトが 1 週間安定したら、フラグを削除します

利点： ロールバックが迅速（フラグを切り替えるだけ）で、インフラの変更が不要であり、特定のユーザーセグメントを対象にできます。

欠点： コードが複雑になる（分岐ロジック）ほか、古いフラグが技術的負債になり、インフラの問題を検出できません。

ツール

プラットフォーム	得意分野	備考
LaunchDarkly	エンタープライズ規模、Guarded Rollouts（自動カナリア分析、2025 年 5 月に一般提供開始）、プロンプト／モデルのロールアウト向け AI Configs、エージェントグラフ	2025 年に Highlight.io を買収 — フラグと連携した可観測性も提供
Statsig	実験を重視する文化、両面マーケットプレイス向け Switchback 実験（2026 年 2 月のアップデート）、自動調整	2025 年 9 月に OpenAI が買収。2026 年半ば時点では独立運営を継続していますが、複数年にわたるインフラ投資を決める前に、買収やロードマップのリスクを考慮してください
GrowthBook	OSS を重視、コード参照スキャンによる古いフラグの検出、SQL ベースの実験	セルフホストし、ベンダーロックインを避けたい場合に最適です
Unleash	OSS、GitOps スタイルのフラグ定義、環境のスコープ設定	Apache 2 ライセンス。SSO／監査向けの Enterprise ティアあり
Flagsmith	キルスイッチを主要機能として提供、カナリアアラート、OSS オプション	2026 年に「キルスイッチとは」と「リリーステスト」のガイドを公開
Harness FME（旧 Split）	デプロイパイプラインと連携したターゲット指定ロールアウトと監視、データウェアハウスネイティブの実験とフラグのアーカイブ（2026 年）	Harness による買収後にブランドを変更

ベンダー提供のカナリア分析（LaunchDarkly Guarded Rollouts、Statsig Auto-tune、Flagger）は現在一般的です。プラットフォームが提供している場合は、手作業で作成したロールアウトポリシーの YAML よりも、そちらを優先してください。この表にあるベンダーの変遷（Statsig→OpenAI、Split→Harness FME）を踏まえ、OpenFeature 互換の SDK（CNCF 仕様。Harness FME なども現在これを標準として採用）を優先すると、フラグツールを柔軟に切り替えられます。

AI／LLM 機能のロールアウト

AI 機能には、通常とは異なるロールアウトパターンが必要です。プロンプトのバージョンとモデル ID はコードとは別に設定でき、キルスイッチは必須です。

1. AI Configs プラットフォーム（LaunchDarkly AI Configs、カスタムデータセット、またはフィーチャーフラグの JSON）で、プロンプトテンプレートのバージョンとモデル ID を固定します。
2. フラグの背後でプロンプト／モデルの組み合わせをロールアウトします。まず内部ユーザーに適用し、その後 1%、10% などへと広げます。
3. エラー率だけでなく、コホートごとに評価メトリクス（ハルシネーション率、ジェイルブレイク成功率、リクエストあたりのコスト）を監視します。
4. コストのガードレール：モデルのリクエストあたりのコストが急増した場合、機能をオープン状態にして（適切なフォールバックを行い）停止する予算サーキットブレーカーを設けます。
5. キルスイッチ：AI 経路を無効にし、決定論的なフォールバックまたは「機能を利用できません」の状態に切り替える単一のフラグを用意します。リリース前にステージング環境でテストできるようにします。

プロンプトレベルの評価テストパターンについては ai-system-testing を、カナリアメトリクスの設計については testing-in-production を参照してください。

---

ロールバックの基準とプロセス

自動ロールバックのトリガー

デプロイ前に、これらのしきい値を定義してください。いずれかのトリガーが発動すると、自動的にロールバックが開始されます。すべてのしきい値は絶対的な上限ではなく、測定されたベースラインを基準とします。

メトリクス	しきい値	アクション
エラー率（5xx）	5 分間、ベースラインの 2 倍超	自動ロールバック
P95 レイテンシ	5 分間、ベースラインの 3 倍超	自動ロールバック
ヘルスチェック	3 回連続で失敗	自動ロールバック
クラッシュ率（モバイル）	0.5% 超	自動ロールバック
エラーバジェット	1 時間で 50% 超を消費	自動ロールバック

手動ロールバックのトリガー

人間による判断が必要ですが、明確なガイドラインを設けてください。

• 顧客から報告された重大な問題 — 複数のユーザーから同じ問題が報告されている
• データの整合性に関する懸念 — データが破損している、または誤っている証拠がある
• セキュリティ脆弱性の発見 — 現在進行中の悪用、または深刻度の高い CVE
• 監視の死角 — 新機能の重要なメトリクスを監視できないことに気付いた
• オンコールエンジニアの判断 — オンコールエンジニアは常にロールバックを開始する権限を持つ

ロールバック手順

ステップ 1：判断する（2 分以内）

• トリガーは自動ですか、それとも手動ですか？
• 手動の場合：問題はロールバックの基準を満たしていますか？満たしている場合は続行してください。議論に時間をかけないでください。

ステップ 2：ロールバックを実行する（5 分以内）

• キルスイッチ（最速。利用可能な場合は優先）： 対象機能専用のキルスイッチフラグを切り替えます。完全なコードロールバックとは異なり、再デプロイせずに 1 つの機能を無効化します。リリースのたびに、ステージング環境でキルスイッチをテストしてください。テストされていないスイッチは、スイッチではありません。
• フィーチャーフラグのロールバック： 新しいコードパスのフィーチャーフラグを無効にします。両方が存在する場合、キルスイッチよりも時間がかかります（ロールアウトフラグとキルスイッチは、それぞれ別の用途です）。
• コードのロールバック： 以前のデプロイに戻します（以前のイメージ／アーティファクトを再デプロイします）。問題が単一のフラグ付き機能に限定されない場合に使用してください。
• データベースのロールバック： 該当する場合は、後方移行を実行します。移行を元に戻せない場合は、この手順をスキップし、データを別途処理してください。
• キャッシュの無効化： 以前のバージョンで古いデータや誤ったデータが提供される場合は、CDN とアプリケーションのキャッシュをクリアしてください。

ステップ 3：確認する（5 分以内）

• 本番環境のスモークテストを実行する
• エラー率がベースラインに戻ったことを確認する
• ロールバックしたバージョンが正しく動作することを確認する

ステップ 4：連絡する（10 分以内）

• 以下のロールバック用ひな形を使って、リリースチャンネルに通知する
• ユーザーに影響があった場合は、ステータスページを更新する
• サポートチームに概要を伝える

ステップ 5：調査する（翌営業日）

• 根本原因を分析する
• 問題を検出できたはずの回帰テストを作成する
• チェック漏れがあった場合は、リリース可否チェックリストを更新する
• 修正と再リリースの予定を立てる

ロールバック告知のひな形

ステップ 4 で、これをリリースチャンネルに投稿してください。リリースとロールバックのテンプレート全文については、references/communication-templates.md を参照してください。

Subject: [Rollback] v{version} — {date} {time}
Status: ROLLED BACK
Reason: {one line — e.g. error rate 4x baseline within 8 min}
Impact: {who was affected, for how long}
Current state: Running previous version v{prev_version}
Next steps:
- Root cause investigation: {owner}
- Fix ETA: {estimate or "investigating"}

データに関する考慮事項

移行をロールバックできない場合：

• 前方修正： ロールバックではなく、現在の（問題がある）バージョンに修正を適用してデプロイする
• 二重書き込み： 移行中は古いスキーマと新しいスキーマの両方に書き込み、ロールバック時に新しい書き込みを破棄する
• シャドー移行： バックグラウンドで移行し、検証してから切り替える。ロールバックでは切り替えを停止するだけで済む
• ポイントインタイムリカバリ： バックアップからデータベースを復元する（最終手段。バックアップ以降の変更は失われます）

---

デプロイ後の検証

直後（0～15 分）

• 本番環境のスモークテストに合格する
• エラー率がデプロイ前のベースライン以下である
• エラートラッカーに新しい種類の例外がない
• ヘルスチェックのエンドポイントが正常を返す
• 主要なページが正しく読み込まれる（2～3 ページを手動で抜き取り確認する）

短期（15 分～2 時間）

• 合成モニタリングで、すべての重要な経路が機能していることを確認する
• エラー率の傾向が横ばいまたは低下している（上昇していない）
• P50 および P95 のレイテンシが想定範囲内である
• サポートチケットの件数が増加していない
• ビジネス指標（コンバージョン、収益、登録）が正常である
• メモリーリークやリソース枯渇の傾向がない

中期（2～24 時間）

• 夜間バッチジョブが正常に完了する（該当する場合）
• 他の地域が稼働を始めるにつれて、タイムゾーン依存の問題が表面化していない
• メール／通知の配信が正常である
• サードパーティとの連携が機能している
• パフォーマンスが徐々に低下していない

---

アンチパターン

「ステージングでは動いた」

ステージングは本番環境ではありません。データ量、トラフィックパターン、サードパーティの構成、インフラの規模が異なります。ステージングでの成功は必要条件ですが、準備が整ったことを示す十分な根拠ではありません。 対処法： ステージングでの検証に加えて、本番環境のスモークテストと段階的なロールアウトを実施します。

ロールバック計画がない

「問題が起きたら考えます」というのは、プレッシャーの中、寝不足で、ユーザーから苦情が寄せられる状況で考えるということです。そういうときにミスが起きます。 対処法： ロールバック手順を文書化します。四半期ごとに練習し、所要時間を計測します。口伝ではなく、チェックリストにします。

金曜日の午後にデプロイする

金曜日の午後 4 時にデプロイし、午後 6 時に問題が発生します。チームは夕食中です。問題は一晩で悪化し、月曜日の朝には大混乱になります。 対処法： チーム全員が監視できるよう、週の早い段階かつ一日の早い時間にデプロイします。金曜日にデプロイする必要がある場合は、監視を強化して正午までにデプロイします。

「パイプラインが成功している」からスモークテストを省略する

CI パイプラインでは、テスト環境のテストデータを使ってテストします。スモークテストでは、デプロイされたアプリケーションが本番環境の構成、本番データ、本番インフラで動作することを確認します。 対処法： スモークテストは必須です。時間がかかるなら高速化し、不安定なら修正します。決して省略しないでください。

段階的なリリースではなく一括リリースを行う

6 週間分の変更を一度に巨大なリリースとしてまとめると、問題が起きる箇所が増え、原因となった変更の特定が難しくなり、リスクが高まり、ロールバックに時間がかかり、ストレスも増します。 対処法： 小規模なリリースをより頻繁に行います。継続的デプロイができない場合は、変更内容を小さく把握しやすい状態にして、毎週または隔週でリリースすることを目指します。

デプロイ後の検証を行わない

デプロイ後、次の機能に取りかかります。その 1 時間後、誰も監視していない中でユーザーにエラーが発生しています。 対処法： デプロイ後 30～60 分間、ダッシュボードを監視する担当者を決めます。適切なしきい値を設定した自動アラートを構成し、デプロイ後のスモークテストを実行します。

ロールバックをためらう

「修正まであと少しだから、ホットフィックスを追加でプッシュしましょう。」その間、プレッシャーの中でデバッグを続け、ユーザーへの影響がさらに 45 分間続きます。 対処法： まずロールバックし、その後に調査します。動作する以前のバージョンは、壊れた現在のバージョンより優れています。自尊心は立ち直れますが、ユーザーの信頼を取り戻すのはより困難です。

フィーチャーフラグの蓄積

安全なロールアウトのためにフィーチャーフラグを使うのは良いことですが、削除しないのは問題です。1 年後にはフラグが 200 個に増え、どれが有効なのか誰も分からず、フラグ間の相互作用によって不可解なバグが発生します。 対処法： 2026 年のベストプラクティスは、カレンダーのリマインダーではなく、プラットフォームレベルで古いフラグを検出することです。GrowthBook の古いフラグ検出（コード参照）、LaunchDarkly のアーカイブフロー、または Flagsmith のフラグ経過期間テレメトリーを使い、コードパスが N 週間触れられていないフラグを特定します。これに、しきい値を超えて古くなったフラグをアーカイブするか、保持する理由と担当者を文書化する四半期ごとのレビューを組み合わせます。カレンダーの日付は陳腐化しますが、コード参照のスキャンは陳腐化しません。

誤作動するカナリアアラート

ノイズが多い、到着が遅い、または一部しか集計されていないメトリクスに、自動ロールバックが結び付けられています。アラートは誤ったタイミングで発報する（または発報しない）ため、チームはアラートを信用しなくなります。その結果、本当のインシデントが発生したときに、シグナルが無視されます。 対策： カナリアアラートを他のテストと同様に扱います。偽陽性率と偽陰性率があり、その両方を測定します。アラートが判定を通知するものの、実際にはロールバックしない「シャドー」期間を設け、2週間にわたってその判定と正解データを比較します。偽陽性率が許容範囲を下回ってから、自動ロールバックに移行します。参考：https://www.flagsmith.com/blog/when-canary-alerts-go-wrong

双方向システム向けのスイッチバック実験

マーケットプレイス、ライドシェア、広告オークションなど、処置群が共有状態を通じて対照群に影響を及ぼすシステムでは、標準的な A/B テストはうまく機能しません。トラフィックを 50/50 に分割しても、実験は分離されません。両方のグループが、歪んだ同じ市場を観測するためです。 対策： スイッチバック設計を使用します。短い時間枠（数分から数時間）ごとに、システム全体を対照条件と処置条件に切り替えます。Statsig の Switchback experiments（2026年2月）は、一般的なケースでこれを自動化します。破損した A/B テストの結果をリリースの妨げにせず、適切な設計で再実行します。参考：https://www.statsig.com/updates

---

検証

デプロイ完了直後に、最小のチェックから順に実行します。references/rollout-automation.md のエラートラッカーのクエリを拡張してください。

# Health endpoint returns healthy
curl -s https://your-app.com/health | jq .

# Response time + status in one shot
curl -o /dev/null -s -w "HTTP %{http_code} in %{time_total}s\n" https://your-app.com

# New errors since deploy (Sentry CLI) — should be empty
sentry-cli issues list --project your-project --query "firstSeen:>15m"

# Datadog: compare 5xx count for the service before vs after deploy — must not increase

合格基準：ヘルスチェックが healthy を返し、レイテンシ予算内にステータスが 200 となり、Sentry クエリで新しい問題が検出されず、デプロイ後の 5xx 件数がデプロイ前のベースライン以下であること。

---

完了条件

• Go／No-Go チェックリストに、対象項目ごとの根拠または明示的な不足が記録され、候補の識別情報が正確に記載されており、バージョン管理された成果物として保存されていること。推奨と実際の承認者による判断は区別され、不足している承認を承認済みとして扱わないこと。
• スモークテストの結果がリリース候補を対象としており、失敗、再試行、スキップ、ブロック、未実行のチェックが明示されていること。Go 推奨はプロジェクトで合意された根拠のゲートを満たすこと。それ以外の場合は、具体的な未完了作業を添えて No-Go または条件付きの推奨を提示すること。
• ロールバック基準が、ベースラインを基準とした具体的なしきい値として文書化され、ロールバック手順がステージング環境で少なくとも一度は実践されていること
• トラフィック割合、各段階の昇格基準、各段階のガードレールメトリクスを含む段階的ロールアウト計画が定義されていること
• 準備状況のみを確認するレビューについて、デプロイ後の検証が定義されていること。デプロイと検証が対象範囲に含まれ、承認されている場合は、実際の結果をそれぞれ別に記録すること。

参考ファイル（references/ 内）

• rollout-automation.md — 自動的なカナリア→10%→50%→100%の昇格基準（ベースライン基準）と、デプロイ後の検証用コマンドスニペット。
• communication-templates.md — リリースまたはロールバックの告知を作成する際に読み込みます。記入式のリリーステンプレートとロールバックテンプレートが含まれています。

関連スキル

• testing-in-production — 段階的なロールアウトと直接重複します。リリース時に適用する安全なリリースの手法（フラグ、カナリア、ダークローンチ、ガードレール指標）については、こちらをご覧ください。リリースを実施するかどうかを決める判断については、こちらをご覧ください。
• synthetic-monitoring — リリース後に継続して実行される定期的なプローブです。リリース準備状況では、デプロイ後に一度だけ行う検証期間を扱います。synthetic-monitoring では、継続的な SLA 検証を扱います。
• qa-metrics — go/no-go の判断やロールバックのしきい値で参照する、DORA の根拠となる指標（変更失敗率、MTTR）と、エラー率／成功率の数値の情報源です。
• ci-cd-integration — CI パイプラインがグリーンであることが前提条件です。パイプラインの構築にはこちらを、パイプラインをリリース判断の条件にするにはこちらをご覧ください。
• ai-system-testing — AI／LLM 機能をリリースする場合に利用します。プロンプトバージョンの評価テストやキルスイッチの設計を扱います。こちらのロールアウトパターンから参照しています。
• compliance-testing — go/no-go の前に、EU AI Act／EAA／GDPR の要件によってリリースが法的に制限される場合に利用します。
• playwright-automation — スモークテストは、こちらで実装されることがよくあります。テストの構成については、こちらをご覧ください。どのユーザージャーニーがスモークテストの必須対象かについては、こちらをご覧ください。
• quality-postmortem — リリースで問題が発生した場合、ポストモーテムで明らかになった不足チェックを、この go/no-go チェックリストに反映します。