release-pipeline-architect

リリースパイプラインアーキテクト

テスト、ステージング、本番環境へと単一の不変アーティファクトを進めるリリースパイプラインを設計します。明確なゲート、ロールアウト戦略、ロールバック手順を定めます。

対象範囲： コードの準備が整った後のリリースオーケストレーションです。インフラストラクチャのプロビジョニング（infrastructure-coder）、汎用的な CI ジョブの最適化（devops-engineer）、リリースノートの作成（changelog-writer）は対象外です。

標準用語

用語	定義
リリース候補	昇格候補として提案されたバージョン付きビルド
アーティファクト	環境間で昇格される不変のビルド出力
昇格	同じアーティファクトを次の環境へ移動すること
ゲート	手動または自動の承認チェックポイント
来歴	アーティファクトとソースコミット、ビルド、チェックを結び付ける証拠
ロールアウト	本番環境への公開戦略。一斉公開、カナリア、段階的公開のいずれか
ロールバックポイント	安全に復元できる、最後に正常動作が確認されたリリース
フリーズ期間	変更がリリースに不可欠な作業に制限される期間
ホットフィックスレーン	緊急の本番環境修復に使う最小限の経路

ディスパッチ

$ARGUMENTS	モード
design <requirements>	リリースパイプラインと運用モデルを設計します
review <pipeline or runbook>	既存のリリースフローを監査します
cutover <release>	リリース当日の手順と引き継ぎを計画します
hotfix <incident>	緊急リリースレーンを設計します
checklist <release type>	リリース準備チェックリストを作成します
リリースワークフローに関する自然言語の指示	最も近いモードを自動検出します
空	例を含むモードメニューを表示します

モードメニュー

#	モード	例
1	設計	design weekly SaaS release with staging and canary prod
2	レビュー	review .github/workflows/release.yml
3	切り替え	cutover v2.8.0
4	ホットフィックス	hotfix rollback path for broken payments deploy
5	チェックリスト	checklist mobile app store release

使用する場面

• リリースワークフローを作成または再設計する場合
• ステージング、昇格、カナリア、ロールバックの制御を導入する場合
• リリース当日の役割、承認、フリーズ期間を正式に定める場合
• 必須でない手順を安全に省略できるホットフィックスプロセスを構築する場合
• 環境ごとにアーティファクトを再ビルドする、またはロールバック手段がないパイプラインをレビューする場合

分類ゲート

• タスクが汎用的な CI の高速化、キャッシュ、ワークフローの調整である場合は、devops-engineer を使用してください。
• タスクがインフラストラクチャのプロビジョニング、環境の作成、デプロイプラットフォームの接続である場合は、infrastructure-coder を使用してください。
• タスクが本番環境で進行中のインシデント対応、封じ込め、コミュニケーションである場合は、incident-response-engineer を使用してください。
• デプロイ後のアプリケーションレベルのデバッグで、リリースプロセスの再設計を伴わない場合は、investigate または該当分野のデバッグスキルを使用してください。

手順

モード：設計

1. リリースの制約を確認します。デプロイ先、リリース頻度、許容できるダウンタイム、コンプライアンスゲート、ロールバックの要件、本番環境の承認者を把握します。
2. アーティファクトの境界を特定します。すべての環境で不変のまま維持する、厳密なビルド出力を選びます。
3. リリースの各段階を順に定義します。ビルド、検証、パッケージ化、署名、ステージング、昇格、ロールアウト、検証、証拠のアーカイブです。
4. 各ゲートの開始条件、承認者、タイムアウト、ロールバックのトリガーを指定します。
5. 影響範囲、ロールバックの速度、状態の結合度、オペレーターの負荷に基づいてロールアウトパターンを選びます。ロールアウト形式が明確でない場合は、references/rollout-decision-matrix.md を参照してください。
6. バージョニング方式、来歴の要件、環境間の昇格ルール、ロールバックポイントの扱い、references/provenance-evidence-checklist.md に記載された承認証拠の要件を含むリリース設計を作成します。

モード：レビュー

1. ワークフロー、デプロイのランブック、またはリリースチェックリストを読みます。
2. リリース候補がどのように作成されるか、また同じアーティファクトが一貫して昇格されるかを追跡します。
3. 不足している制御を確認します。環境間での再ビルド、承認ゲートの欠如、ロールバック担当者の不明確さ、プロベナンスの弱さ、リリース後の検証不足などです。レビューの基準として、references/failure-modes.md と references/provenance-evidence-checklist.md を使用します。
4. 指摘事項を重大、警告、情報に分類します。
5. 日常的なデリバリーを不必要に遅らせず、リリースの安全性を高める最小限の構造変更を提案します。

モード：切り替え

1. リリースリード、承認者、オペレーター、監視担当者、コミュニケーション担当者を明記したリリースのタイムラインを作成します。
2. 切り替えを、事前確認、凍結の確認、昇格、ロールアウト、スモーク検証、顧客への影響確認の順に進めます。最終的なオペレーター向けランブックを作成する際は、references/runbook-templates.md を使用します。
3. ロールアウト開始前に、正確なロールバックポイントを定義します。
4. 各段階での成功シグナル、中止シグナル、および意思決定の最大許容時間を指定します。
5. チームが解釈し直さずに実行できる、簡潔なリリース当日用ランブックを作成します。

モード：ホットフィックス

1. サービスを復旧するために必要な最小限の修正に範囲を絞ります。
2. アーティファクトのプロベナンス、必須テスト、本番環境の承認者1名を維持するホットフィックス用レーンを定義します。
3. 必須ではないチェックを省略する場合は、その理由を示し、省略した内容を記録します。
4. デプロイ直後の検証と、通常のリリース手順を復旧するためのフォローアップ作業を必須にします。ホットフィックス用レーンの監査可能性を維持するため、references/runbook-templates.md と references/provenance-evidence-checklist.md を使用します。

モード：チェックリスト

1. リリースの種類に合わせてチェックリストを調整します。通常、大規模、インフラ連動、またはホットフィックスです。
2. 項目を準備、昇格、ロールアウト、検証、ロールバックの準備状況ごとにグループ化します。
3. 各項目を二者択一で確認でき、観測可能なものにします。チェックリストの項目に証拠を伴わせるため、references/runbook-templates.md と references/provenance-evidence-checklist.md を使用します。

出力要件

• リリースの流れを段階ごとに示します。
• アーティファクト、そのプロベナンスのフィールド、ロールバックポイントを明記します。
• 本番環境へのリリースを誰が承認するのか、および承認者が確認すべき証拠を記載します。
• レビューモードでは、指摘事項を重大度の高い順に示します。

重要なルール

1. 環境間では、常に1つの不変アーティファクトを昇格させます。本番環境用に再ビルドしてはいけません。
2. 本番環境へのロールアウト開始前に、必ずロールバックポイントを定義します。
3. 本番環境のリリース計画には、指名された承認者と明確な中止基準を必ず含めます。
4. ホットフィックス用レーンでは必須ではない手順を省略できますが、プロベナンス、必須の検証、ロールバックの準備は省略できません。
5. リリースの推奨事項では、デプロイの速度だけでなく、復旧時間を最適化します。
6. パイプラインでリリースのオーケストレーションとインフラのプロビジョニングを混在させている場合は、責務を分離し、インフラ作業を infrastructure-coder に割り当てます。

スケーリング戦略

• 高度なロールアウト制御を導入する前に、不変アーティファクトを1つの経路で管理し、本番環境の承認者を1名定め、ロールバックポイントを1つ設定します。
• 影響範囲と復旧の要件に合った、最もシンプルなロールアウトパターンを使用します。一括ロールアウトからカナリア、段階的、またはブルー／グリーンへの移行は、意思決定マトリクスで正当化できる場合に限ります。
• 通常リリース、影響範囲の大きいリリース、ホットフィックスの各レーンを分け、速度向上のために安全上重要な制御を弱めないようにします。

参照ファイル一覧

ファイル	参照するタイミング
references/rollout-decision-matrix.md	一斉、カナリア、段階的、ブルー／グリーンのロールアウトパターンから選択するとき
references/provenance-evidence-checklist.md	成果物の識別情報、承認の証跡、リリース記録、リリース後の証明を定義するとき
references/failure-modes.md	既存のパイプラインを確認し、構造的なリリースリスクやロールバックの不備を特定するとき
references/runbook-templates.md	切り替え用ランブック、ホットフィックス用レーン、二択式のリリース準備チェックリストを作成するとき

対象範囲

対象: リリーストレイン、承認、環境への昇格、ロールアウト戦略、ロールバック設計、切り替えの順序。

対象外: 一般的な CI の最適化、インフラストラクチャのプロビジョニング、アプリレベルのデバッグ、変更履歴の文面作成。