authoring-release-runbook

authoring-release-runbook — SKILL.md

バリアント： 標準 · 使用する場面： リリースの本番投入用運用ランブックを作成するとき。内容に詳しくないオンコールエンジニアでも、ランブックだけを頼りにデプロイを実行し、成否を確認し、安全にロールバックできる水準を目指します。

概要

このスキルは、優れたリリースランブックの書き方、つまりシステムを安全かつ確実に本番環境へリリースするために、デプロイ担当者やオンコールエンジニアが従う運用手順を扱います。前提条件と承認、デプロイ前の実施可否チェック、順序立てたデプロイ手順、デプロイ後の検証、ロールバック手順、オンコール／エスカレーションおよび監視に関する情報を網羅する、幅広い本番稼働開始用ドキュメントです。このスキルが担うのは作成者の判断、すなわち SRE／運用調査の手法 と 実行可能性／安全性の基準 であり、セクション一覧ではありません。ここでは、セクションの 構成 を提供する リリースランブックのテンプレートツール と、確立された実践に基づいて手順を裏付ける 深掘り調査機能 の2つの協力者を想定しています。作成者には、計画でこのランブックの作成に必要と判断された上流ドキュメント（通常は architecture-doc + technical-design + test-plan）が渡されます。そこから 実際に実行可能な手順を導き出す 必要があり、汎用的なひな形を出力してはいけません。達成すべき基準は、システムをデプロイしたことがないエンジニアが、ランブックだけを頼りにリリースを実行し、成功を確認し、安全にロールバックできることです。また、すべての手順に期待される結果が記載され、すべての変更に文書化された取り消し手順があり、シークレットが直接記載されておらず、何も捏造されていないことも必要です。ランブックは 継続的に更新されるドキュメント でもあります。リリースのたびに再実行され、インシデントのたびに強化されます。そのためこのスキルでは、初回の作成だけでなく、バージョン管理された差分としての 改訂 も扱います。改訂後はエンドツーエンドで再検証します（ステップ7）。

有効化する場面

• システムまたはサービスの本番リリース／デプロイ／本番稼働開始用ランブックを作成するとき。
• デプロイに伴う手動手順、検証、ロールバックの手順を文書化するとき。前提条件、実施可否の判断、順序立てたデプロイ手順、デプロイ後のスモークテスト、ロールバック、エスカレーション、監視に関する情報が対象です。
• 調査に基づき、実行可能で上流ドキュメントから導き出された内容をリリースランブックのテンプレートに記入するとき。
• 上流の変更（デプロイ構成、ロールアウト、終了基準の変更など）、またはインシデント後の学び（障害によってロールバック手順や障害モードの欠落が判明した場合など）を受けて、既存のランブックを 改訂 するとき（ステップ7）。

次の場合は有効化しないでください：

• CI/CD パイプラインの自動化自体（ビルド・テスト・デプロイの YAML／設定）を作成するとき。それは cicd-plan の対象です。ランブックではパイプラインを呼び出し、その前後の手順を文書化しますが、パイプラインの設定は作成しません。
• 事後のインシデント振り返りやポストモーテムを書くとき。ランブックはロールバックも含めた 事前に計画された 手順です。振り返りはインシデントの発生後に書きます。
• QA の対象範囲、レベル、カバレッジ、テストケース一覧を定義するとき。それは test-plan の対象です。ランブックではデプロイ後の検証に test-plan の終了基準を 再利用 しますが、QA 戦略は再定義しません。
• ランブックが参照する architecture-doc／technical-design を作成するとき。これらはここでは 上流の入力 です。
• 完成したランブックをレビューまたは評価するとき。同じ基準を適用する実行時ゲートの reviewing-release-runbook を使用してください。

入力

プランから渡されたすべてのドキュメント（depends_on セット、つまり上流のドキュメントのうち、探索によって本書に関係すると判断されたもの）を読み、このランブックの内容がそれらに基づいていることを確認してください。入力が固定されていると想定しないでください。このスキルで挙げる一般的な上流ドキュメントは手法の指針であり、受け取るドキュメントの上限ではありません。

• アーキテクチャドキュメントに記載されたデプロイ可能なコンポーネント／サービスとデプロイトポロジー、および技術設計に記載されたロールアウト／移行の詳細から、デプロイ手順を導き出します。
• テスト計画の終了／完了基準から検証内容を導き出します。デプロイ後のスモークテストでは、これらの基準を再利用します。
• 自己完結型で、柔軟に対応できる内容にします。実際に受け取ったコンテキストに基づいてランブックを作成してください。想定される上流ドキュメント（例：オブザーバビリティ／モニタリングの参照先やテスト計画）がない場合は、手元にある情報で進め、不足している内容を明示的な前提として示してください。補うためにコマンド、ホスト、エンドポイントを決して捏造しないでください。
• 利用可能な場合は、リサーチ機能（deep-research）を使い、テンプレートを埋めるだけでなく、確立された SRE／運用の実践に基づいてランブックを作成してください。

ワークフロー

ステップ 1：テンプレートツールから構成を取得する — 独自のアウトラインを作らない

リリースランブックのテンプレートツール（包括的なバリアント）からセクション構成を取得します。ここでセクション一覧を再掲したり、独自に導き出したりしないでください。このスキルが示すのは、各セクションを適切に埋めるための方法です。前提条件／承認、デプロイ前の実施可否判断、デプロイ手順、デプロイ後の検証、ロールバック、エスカレーション、モニタリングの参照先といった、このジャンルで重要なセクションはテンプレートで定義されています。あなたの役割は、それらを埋める内容の質を高めることです。

ステップ 2：上流ドキュメントを読み込み、それに基づいて手順を作成する

渡されたドキュメントを読みます。これらは入力であり、白紙ではありません。アーキテクチャドキュメントから、デプロイ可能なすべてのコンポーネント／サービスとデプロイトポロジーを特定します。技術設計から、ロールアウト／移行計画、変更を適用する順序、下位互換性に関する制約を確認します。テスト計画から、デプロイ後の検証で確認する終了基準を取得します。上流ドキュメントの内容が乏しい、または存在しない場合は、不足分を明示的な前提として記載します。黙って既定値を設定したり、コマンドを捏造したりしないでください。

ステップ 3：リサーチに基づき、SRE／運用の実践を反映する

ディープリサーチを行い、確立された実践に基づいてランブックを作成します。調査の目的は捏造ではありません。冪等性、各手順の検証、ロールバックのトリガー、参照によるシークレット管理といった運用上の慣例や、デプロイ戦略の仕組みを、信頼できる情報源で確認してください。上流ドキュメントに記載された内容に沿って設計します。リサーチ機能が利用できない場合は、コマンド、しきい値、ホストを捏造しないでください。リリース前に検証が必要な、明示的にフラグを付けた前提として記載します。

ステップ 4：デプロイ戦略を選択する

デフォルトではブルーグリーンを採用します。待機環境にデプロイしてスモークテストを実施し、その後トラフィックを切り替えます。ロールバック時は旧環境にトラフィックを戻します。アーキテクチャドキュメント／技術設計でプロジェクトに最適な戦略が示されている場合、またはユーザー／システム／エージェントから戦略を指定された場合は、デフォルトを変更します。デプロイ手順とロールバック手順は、戦略ごとに異なります。

戦略	デプロイの流れ	ロールバックの流れ
ブルーグリーン（デフォルト）	待機環境にデプロイし、スモークテストを実施してから、トラフィックを切り替えます	旧環境にトラフィックを戻します（即時）
ローリング	インスタンスの一部ずつ更新し、各バッチを検証します	新環境を縮小し、旧環境を拡大します（段階的）
カナリア	トラフィックの一部（1～10%）を振り分け、メトリクスを確認してから段階的に拡大します	トラフィックの振り分けを 0% にするか、新環境を縮小します（影響範囲を限定）
リクリエイト	旧環境を停止し、デプロイしてから新環境を起動します（ダウンタイムが発生）	以前のアーティファクトを再デプロイします

選択した戦略に応じたデプロイ手順とロールバック手順を記載します。汎用的な手順にはしないでください。

ステップ 5：実行可能性と安全性を重視して各手順を記述する

この方法に沿って、テンプレートの各セクションを埋めます。小規模なリリースで不要なセクションは簡潔にし、無理に内容を追加しないでください。

• 前提条件と承認 — 必要なアクセス権やツール類、リリースする不変のアーティファクト（ID／タグで特定し、ビルドまで追跡可能なもの）、必要な承認（QA／テストの承認、変更承認、オンコール担当者の確認）。承認が必要なことだけでなく、誰が承認するのかを記録します。
• デプロイ前チェック（実施可否） — デプロイの直前に検証する環境／設定の前提条件を、それぞれの期待される結果とともに記載します。いずれかのチェックに失敗した場合は手順を停止するNO-GOとなる、明示的なGO／NO-GOゲートを設けます。ロールバック先となる現在の稼働バージョンの特定も含めます。
• デプロイ手順 — 順序が明確で、冪等かつ安全にコピー＆ペーストできる手順を記載します。各手順は、明確に示した<placeholders>を使う実際のコマンド／操作とし、曖昧な説明（「サーバーを設定する」など）は使いません。手順を再実行しても安全でなければなりません（1回限りの操作にはガードを設け、IF NOT EXISTSを使い、追記ではなく上書きします）。すべての手順に期待される出力と検証チェックを記載し、客観的に測定できる基準（ステータス、配信されるバージョン、ヘルス値）を設けます。未検証の手順がある場合、先へ進みません。
• 状態を持つ変更／マイグレーションの安全性（リリースでスキーマまたはデータを変更する場合） — ロールバックを常に安全に行えるよう、後方互換性のある**拡張と縮小（並行変更）**の手順を優先します。拡張（古いものをその場で削除／名前変更せず、新しい列／テーブルを追加する）、移行（新しい構造を使うコードをデプロイし、両方を共存させる。必要に応じてバックフィルする）、縮小（不要になった要素を後の別リリースで削除する）の順で行います。可能であれば、スキーママイグレーションとコードのデプロイを分離します。不可逆な変更（DROP、破壊的な変換、確定済みのデータ変更）には、クリーンなダウンマイグレーションはありません。ロールバック手順に復旧方法を記載し（以下を参照）、実在しない取り消し手順を記述しないでください。
• デプロイ後の検証／スモークテスト — 測定可能な成功基準を持つ具体的なチェックを記載し、テスト計画の終了基準を再利用します。指定した期間、状態を観察（ベイク）します。成功は数値で定義します（エラー率 < しきい値、p99 レイテンシ < しきい値、または SLO エラーバジェットのバーンレートが許容範囲内）。「問題なさそう」とは記載しません。
• ロールバック手順 — 明示的な発動条件（測定可能なもの：エラー率／レイテンシ／SLO エラーバジェットのバーンレート／スモークテストの失敗）、すべての前進変更に対応する、変更順の逆順で実行するロールバック手順を記載します。ロールバック手段は戦略に合わせます（ブルーグリーン＝トラフィックを切り戻す、カナリア／ローリング＝ルーティングを0％にする／スケールダウンする、再作成＝古いアーティファクトを再デプロイする、機能フラグ方式＝フラグをオフにする（局所的にほぼ瞬時に切り替え可能））。前進変更が不可逆な場合は、元に戻すのではなく前進させます。データを失う実在しないダウンマイグレーションではなく、修正のための追加変更／封じ込め／補償トランザクション／バックアップからの復元の方法を記載します。ロールバック後は、デプロイ前のベースラインに対する再検証で手順を締めくくります。
• オンコール／エスカレーション — 実際に機能する連絡経路を記載します。ページングする相手、重大度の段階、重大度ごとの応答時間枠、エスカレーションポリシーを含めます。
• モニタリング／可観測性の参照先 — 監視対象のダッシュボード／アラート／ログを、それぞれ「正常な状態」の説明とともにリンクで示します。モニターへのリンクを掲載し、ライブパネルを埋め込まないでください。
• メンテナンス時間／告知（デプロイがユーザーに影響する場合） — 関係者への事前通知、ステータスページでのメンテナンス時間の告知、復旧後の通知を含む連絡計画を記載します。メール／ステータスページ／アプリ内バナーの各チャネルに担当者を割り当てます。影響に応じた対応を行います。社内向け、またはユーザーへの影響がないデプロイでは不要です（空欄にします。これは問題ではなく、適切な記載です）。

ドライラン／リハーサル（参考であり、ゲートではありません）。 本番実行の前に、本番環境に近いステージング環境で手順全体を実行し、障害を注入してロールバックが実際に機能することを確認します。また、チーム外のエンジニアに手順に沿って実行してもらいます（「不慣れなエンジニア」でも実行できるという基準を、実際に確認します）。テンプレートの最終検証日フィールドに日付を記録します。これはランブックが今もシステムに合致していることを示す鮮度の指標です。初回作成のランブックはリハーサル未実施です。これは品質の指標であり、実施の前提条件ではありません。

ステップ 6：引き渡し前に、実行可能性と安全性の基準を満たしているかセルフチェックする

以下のすべてを満たしていることを確認します（これは、実行時の reviewing-release-runbook ゲートが検証する基準です。作成者とレビュアーが同じ11項目の基準を作成・判定することで、認識のずれを防ぎます。番号はレビュアーの条件と一致しています）。各状況に応じて適用される項目は、該当しない場合は n/a となります。これは適切な範囲設定であり、欠落ではありません。

1. 初見のエンジニアでも実行できる — デプロイ／ロールバックの各手順が具体的で、プレースホルダーが明示されたコピー＆ペースト可能な内容になっています。曖昧な表現はなく、手順を再実行しても安全です（冪等性があります）。
2. 手順ごとの検証 — 各手順に、期待される結果と、測定可能な検証方法（実測のしきい値またはSLOのバーンレート）が記載されています。検証を行わずに手順を先へ進めることはありません。
3. 実行可否の判定ゲートがある — デプロイ前チェックがデプロイ実施の可否を判定します。チェックに1つでも失敗した場合、明示的に NO-GO として手順を停止します。
4. トリガーを含む、完全かつ安全なロールバック — 測定可能なトリガー条件（バーンレートを含む）があります。フラグによる切り替えが指定されている場合はそれも含め、すべての変更を、対応する戦略に合った手段で逆順に戻します。不可逆な変更は、明記された復旧手順に沿って前進方向にロールアウトし、ベースラインへの復旧を再検証します。
5. デプロイ後の検証で具体的なチェックを再利用する — スモークテストには測定可能な成功基準があり、引き継がれたテスト計画の終了基準がある場合はそれを再利用し、明記されたベイク期間中に検証します。
6. 具体的なエスカレーション先と監視方法 — 実際のオンコール／エスカレーション経路と、実際の監視先（リンクと「正常時の状態」の説明を含む）が記載されています。プレースホルダーではありません。
7. シークレットを直接記載しない — ランブックに実際のトークン／パスワード／キーを記載しません。シークレットは、保管先／ボールト／環境変数名で参照します。
8. 捏造しない — すべてのコマンド、ホスト、エンドポイントの根拠が引き継がれた上流情報にあり、そうでない場合は前提として明示されています。
9. ステートフルな変更の安全性（状況に応じて適用 — スキーマ／データの変更がない場合は n/a）— スキーマ／データの前方変更は、元に戻せる／後方互換性がある（拡張と縮小の順序に沿っている）か、ロールフォワード／封じ込め／復元の復旧手順を明記しています。
10. コミュニケーション／メンテナンスウィンドウ（状況に応じて適用 — デプロイがユーザーに影響しない場合は n/a）— ユーザーに影響するデプロイでは、告知／メンテナンスウィンドウの計画を明記しています。

（条件 9 — 差分の範囲に限定した修正 — は、既存のランブックを修正する場合にのみ適用されます。セルフチェックはステップ 7です。リリースのプレッシャー下でも使えること — オンコール担当のエンジニアが、午前3時でも作成者に確認することなく、上から順に手順として実行できること — は、番号付き項目ではなく、ランブック全体に対する総合的な観点です。）

入力不足時のゲート： 提供された情報や、妥当な範囲で想定できる情報からデプロイの内容を信頼できる形で記述できない場合、コマンドを捏造して取り繕うのではなく、ブロッカー（「ランブックの記述が不十分 — デプロイトポロジー／ロールアウトの判断が必要」）として明示します。

ステップ 7：既存のランブックを修正する（継続的に更新するドキュメントの手順）

リリースランブックはリリースのたびに再実行され、インシデントのたびに強化されます。既存のランブックと変更依頼を受け取ったら、再生成せずに修正してください。

1. 変更の範囲を、影響を受ける項目に絞ります。デプロイ手順、ロールバック手順とトリガー、Go／No-Go チェック、デプロイ後のチェック、デプロイ戦略、ステートフルな変更の手順、エスカレーションまたは監視の参照先、コミュニケーション計画が対象です。
2. トリガー（双方向）を特定します。上流の変更（アーキテクチャドキュメントのトポロジー、技術設計のロールアウト、またはテスト計画の終了基準が変更されたため、影響を受ける手順を再導出する）か、インシデント後の学び（停止によって、ロールバック手順の欠落、未検証の障害モード、または遅すぎる／欠落したトリガーが明らかになったため、インシデントで必要とされたロールバックトリガー、検証ゲート、または修正済みの手順を追加する）です。
3. 書き直すのではなく、編集します。影響を受ける手順のみを修正してください。
4. エンドツーエンドで再検証します。ランブックは実行順序に依存する手順であるため、変更した手順によって、後続手順の前提条件が気づかないうちに崩れることがあります（環境変数名の変更、マイグレーションの順序変更、ヘルスエンドポイントの変更など）。後続手順の前提条件が崩れていないか、手順全体を確認してください。可能であればドライランを再実施し、「最終検証日」を更新するか、再検証が未完了であることを明示してください（再リハーサルは役立ちますが、必須ではありません）。
5. 変更内容が基準を満たしていることを確認します。変更・追加した手順は、該当する拘束条件を満たす必要があります。実行可能かつ検証済みであること（cond-1/2）、新たな前方変更には取り消し手段と測定可能なトリガーがあり、不可逆な変更にはロールフォワードの手順があること（cond-4/cond-10）、秘密情報を直接記述していないこと（cond-7）、事実を捏造していないこと（cond-8）。
6. バージョン管理、変更履歴の記録、旧版の置き換えを行います。ランブック独自のドキュメントバージョン（デプロイするリリースのバージョンとは別）を上げ、トリガーを明記した変更履歴を追加し、旧バージョンを置き換え済みとして示してください。

これが、レビュー担当者のcond-9（変更範囲に絞った修正）が求める基準です。グリーンフィールドでの初回構築では、cond-9 は該当しません。

ルール

必ず守るルール（例外なし）：

• 冪等で、コピー＆ペーストして安全に実行できる手順にします。 コピーして再実行しても安全でないものは、手順ではありません。コマンドを記載すべき箇所に、曖昧な文章を書いてはいけません。
• すべての手順に期待される結果を記載します。 検証ゲートのない手順は完了ではありません。検証していない手順のまま次の手順に進んではいけません。
• 変更を進める手順には、実行条件を含む、元に戻す手順を必ず記載します。 ロールバックには、いつ実行するか（測定可能な条件）と、どのように実行するか（変更ごとに対応する手順を逆順で実行し、戦略に合った手段を使用）を記載し、ベースラインへの復元を再検証します。また、元に戻せない変更とその緩和策も明記します。
• 状態を変更する操作は、後方互換性を保つか、元に戻せないことを明示します。 スキーマやデータの変更は、ロールバックを容易にするため、拡張してから縮小する手順で実施します。元に戻せない変更には、ロールフォワード、封じ込め、または復元の手順を記載し、データを失う架空のダウンマイグレーションを記載してはいけません。
• 再生成ではなく、修正します。 既存のランブックへの変更依頼を受けた場合は、該当する手順を編集し、手順全体を最初から最後まで再検証して、ランブックのバージョンと変更履歴を更新します。黙って書き換えてはいけません（ステップ 7）。
• シークレットを直接記載してはいけません。 シークレットストア、Vault、または環境変数名を参照します。実際のトークン、パスワード、キーがランブックに含まれている場合は不備です。シークレットをコミット済み、デプロイ済み、またはログに記録されるファイルに含めてはいけません。
• コマンド、ホスト、エンドポイントを捏造してはいけません。 それぞれの出典を上流までたどります。確認できない場合は、リリース前に検証すべき前提として明示します。
• 概要を重複して作らず、組み立てます。 セクション構成はテンプレートツールから取得します。このスキルはその構成を埋める方法です。競合する別の概要を貼り付けてはいけません。
• 検証にはテスト計画の合格基準を再利用します。 QA 戦略を再定義せず、テスト計画にすでに定められている基準を適用します。
• パイプラインそのものではなく、パイプラインに沿った手順を記載します。 ランブックでは CI/CD 自動化を呼び出し、手動手順、検証、ロールバックを記載します。パイプラインの設定は作成しません。それは cicd-plan の役割です。
• 実行可能で、安全かつ完全でなければ、完了ではありません。 初めて担当するエンジニアが、そのランブックだけを使ってデプロイとロールバックを実行できないなら、引き渡してはいけません。

望ましい事項（必要に応じて変更可能）：

• 「包括的」とは、出力の目標の高さを指します。分量ではなく、運用上不可欠な手順の網羅性を重視し、内容を適切な規模に保ちます。必要のないセクションは、小規模なサービスでは省略します。
• デプロイ戦略は、デフォルトでブルーグリーンにします。上流の設計がローリング、カナリア、またはリクリエイトを想定している場合や、戦略が固定されている場合は、それに合わせます。
• 各手順は、フェンス付きのコマンドスニペットと期待される出力ブロックで示します。検証は、測定可能な合格基準を含むチェック表で示します。
• 連絡・メンテナンス時間の計画はユーザーへの影響に応じたものにします（内部向けのデプロイでは不要です）。ドライラン・リハーサルと「最終検証日」は情報の鮮度を保つためのものであり、最初のランブック作成の必須条件ではありません。

注意点

• コマンドが必要な箇所の曖昧な説明。「サーバーを設定して再起動する」では、午前3時に実行できません。プレースホルダーを明示した正確なコマンドと、期待される出力を記載してください。
• 期待される結果がない手順。 検証のゲートがなければ、担当者は成功と何も起きないままの失敗を見分けられず、次の手順に進んだ結果、不整合な状態が残ります。期待される出力と確認方法を明記してください。
• 「ロールバックする」としか書かれていないロールバック。 安全策となるのは、すべての変更を逆順に戻す手順、それを実行する測定可能なトリガー、そして不可逆な変更についての明記です。「デプロイをロールバックする」だけでは不十分です。
• シークレットの直接記載。 実際のトークンや接続文字列を手順に貼り付けると、ランブックが保存されるあらゆる場所に漏えいします。値ではなく、保存先／ボルト／環境変数の名前を参照してください。値そのものではなく、設定されていることだけを出力してください。
• デプロイ戦略を考慮していないロールバック。 ブルーグリーン方式ではトラフィックを切り替えてロールバックしますが、再作成方式では古いアーティファクトを再デプロイします。間違った戦略向けに書かれたロールバックは機能しません。選択した戦略に合わせてください。
• でっち上げたホスト名／コマンド。 完全に見せるためにホスト名や CLI フラグを作り上げると、初回から失敗するランブックになります。上流の情報をたどるか、仮定であることを明記してください。
• 安全にロールバックできない一括のスキーマ変更。 コードが使わなくなるのと同じリリースでカラムを削除／改名すると、安全に元に戻せなくなります。各手順を個別にロールバックできるよう、拡張・縮小の順序（新旧のカラムを併存させ、新しいカラムへ移行し、後で古いカラムを削除する）で進めてください。
• 不可逆な変更に対する、実行できないダウンマイグレーション。 データをすでに破壊した DROP に対して「ロールバック：ダウンマイグレーションを実行」と書くのは、データを失う偽りの安全策です。代わりに、ロールフォワード／封じ込め／バックアップからの復元を明記してください。
• 小さな変更でランブック全体を作り直すこと。 トポロジーの1行の修正に全面的な書き直しは不要です。該当する手順を修正し、最初から最後まで再検証してください（変更した手順が後続手順の前提条件を損なう可能性があります）。さらに、バージョンを更新して変更履歴を記録してください（ステップ 7）。
• 内部デプロイに後付けされたコミュニケーション計画。 コミュニケーションの規模はユーザーへの影響に応じたものにします。ユーザーに影響しない、または影響がゼロの内部デプロイには不要です。そのような場合にステータスページの項目を無理に追加しても、安全性ではなく水増しです。
• テンプレートの概要を繰り返すこと。 内容の中（またはこのスキル内）でセクション一覧を再構成すると、テンプレートツールと重複し、内容にずれが生じます。代わりに、判断を加えて各セクションを埋めてください。

アンチパターン

• 「デプロイ担当者はコマンドを知っているので、概要だけ書けばよい」 基準となるのは、プレッシャーの下にいる不慣れなエンジニアです。すべての手順が具体的で、安全にコピー＆ペーストできなければ、最も必要なときにランブックは役に立ちません。
• 「ロールバックはデプロイを逆にするだけ」 それぞれの変更に、個別の取り消し手順と測定可能なトリガーが必要です。元に戻せない変更には、明記された緩和策が必要です。ロールバックを曖昧にすると、障害が長引くことになります。
• 「手順がそのまま実行できるよう、トークンを直接書き込もう」 それではシークレットが漏えいします。保存場所を参照してください。ランブックにはシークレット名を記載し、値は記載しません。
• 「監視先を渡されていないので、もっともらしいダッシュボードの URL を書こう」 エンドポイントをでっち上げると、インシデント時にリンク切れになります。代わりに、監視先が不明であることを前提条件として明示してください。
• 「パイプラインの YAML もここに書こう」 それは cicd-plan です。ランブックに記載するのはパイプラインの設定ではなく、パイプラインを使う手順です。
• 「アウトラインは自分で書こう」 テンプレートツールと重複します。構成はテンプレートツールから取得してください。
• 「マイグレーションは 1 行で済むから、カラムを削除しよう」 後方互換性のある手順がない破壊的なスキーマ変更は、ロールバックできないデプロイの最も一般的な原因です。拡張・縮小方式を使うか、元に戻せない変更として明記し、ロールフォワードしてください。
• 「小さな変更だから、ランブックを書き直そう」 該当する手順を修正し、エンドツーエンドで再検証してください。変更履歴が失われ、後続の前提条件が壊れるおそれがあるため、黙って書き直すのは避けてください。
• 「調査は省こう。デプロイ方法はわかっている」 調査は、実証された SRE の慣例（冪等性、検証ゲート、ロールバックトリガー、戦略の仕組み）に基づいてこのランブックを作成するためのものです。デプロイに関する俗説に頼るものではありません。

出力

ステップ 6 の実行可能性と安全性の基準（11 項目の基準：不慣れなエンジニアが実行可能であること、各ステップに検証ゲートがあること、実施可否の判定ゲートがあること、トリガーを含む完全かつ安全なロールバックがあること、元に戻せない変更にはロールフォワードがあること、テスト計画の終了基準を再利用したデプロイ後検証があること、具体的なエスカレーション先と監視先が示されていること、シークレットが直接記載されていないこと、捏造がないこと、該当する場合は状態を持つ変更の安全性とコミュニケーション計画があること、リリース中のプレッシャー下でも使えること）を満たす包括的なリリースランブック。または、改訂の場合は、バージョン管理され、エンドツーエンドで再検証された差分（ステップ 7）。Markdown 形式のテキストで表現します。具体的には、番号付きの手順、フェンス付きのコマンド／チェック用スニペット、期待される出力のブロック、検証／チェック表、ダッシュボード／モニターへのリンク（ライブパネルの埋め込みではありません）を含めます。手法と基準は形式に依存しません。想定する利用者は、リリースを実行するデプロイ担当／オンコールエンジニアと、同じ基準を適用するランタイムの reviewing-release-runbook ゲートです。ランブックは、入力として引き渡された上流資料（通常は architecture-doc、technical-design、test-plan）に依存します。ランブックの構成はテンプレートツールから取得し、このスキルが提供するのは内容の品質です。

関連項目

• リリースランブックのテンプレートツール（例：コンテンツ／テンプレートゲートウェイ）— このスキルで内容を埋めるセクション構成を提供します。組み合わせて使用し、アウトラインを再掲しないでください。
• ディープリサーチ機能 — 確立された SRE／運用の慣例（冪等性、検証ゲート、ロールバックトリガー、デプロイ戦略の仕組み、シークレットの参照方式）に基づいてランブックを作成します。
• 上流の architecture-doc、technical-design、test-plan（存在する場合）— ランブックの基礎となる、デプロイ可能なコンポーネント、ロールアウト、終了基準を提供します（入力であり、ここで書き直すものではありません）。
• reviewing-release-runbook — 完成したランブックに同じ実行可能性と安全性の基準が満たされているかを確認するランタイムゲートです。著者とレビュアーが同じ基準を共有することで、基準のずれを防ぎます。
• cicd-plan（別個のものであり、この構成には含まれません）— ランブックが呼び出すパイプライン自動化です。ランブックに記載するのは、パイプラインの設定ではなく、その周辺の手順です。

段階的な開示

• references/stateful-and-rollback.md — 状態を変更する際の安全性とロールバック手段について詳しく説明します。拡張・縮小方式／並行変更による移行フェーズ、不可逆な変更におけるロールフォワードとロールバックの判断および影響封じ込め、SLO エラーバジェットのバーンレートの根拠、機能フラグ／自動カナリアによるロールバック手段を扱います。リリースでスキーマやデータを変更する場合、または段階的デリバリーを利用する場合に読み込んでください。
• references/amend-and-rehearsal.md — ステップ 7 の修正手順（2 つのトリガーと、エンドツーエンドの再検証への波及）、本番前のドライラン／リハーサルの実践方法、メンテナンス時間帯／関係者への連絡計画について詳しく説明します。既存のランブックを修正する場合、またはユーザーに影響するデプロイを計画する場合に読み込んでください。
• references/sources.md — SRE／運用手法と、実行可能性／安全性の基準に関する調査の出典です（AWS Well-Architected のランブックに関するガイダンス、Google SRE のカナリアリリース／信頼性の高いリリースと SLO に基づくアラート、OneUptime／Upstat のランブックの実践、拡張・縮小方式による移行とロールフォワードの出典、デプロイ戦略の比較、機能フラグ／ダークローンチ、シークレット管理に関するガイダンス）。ガイダンスの出典を監査する場合にのみ読み込んでください。

本文の上限

• description は 1,024 文字以下です（agentskills.io の上限）。Claude は、スキル一覧で description と when_to_use を合わせた文字数が 1,536 文字を超えると、末尾を切り捨てます。
• 本文は約 500 行／5,000 トークン以下です。
• 長い内容は references/ に置き、必要に応じて読み込みます。