reviewing-release-runbook

reviewing-release-runbook — SKILL.md

バリアント： 標準 · 使用する場面： 完成したリリース／デプロイ手順書を受け入れゲートとして評価する場合 — 不慣れなオンコールエンジニアが手順書だけでデプロイを実行し、確認して、ロールバックできるかをチェックし、実行可能な指摘とともに VERDICT: approve|revise を出力します。

概要

このスキルは、リリース手順書の作成・評価ペアにおける「レビュー」側です。完成したリリース／デプロイ手順書、つまりデプロイ担当またはオンコールエンジニアがシステムを安全かつ検証可能な形で本番環境にリリースするための運用手順（前提条件と承認、デプロイ前の実行可否判断、順序立てたデプロイ手順、デプロイ後の検証、ロールバック手順、エスカレーション、監視に関する情報）を手にしたレビュアーが読み込み、次の1つの問いに照らして文書を評価します。このシステムを一度もデプロイしたことのないエンジニアが、秘密情報を直接記載したり、何かを捏造したりすることなく、この手順書だけでリリースを実行し、成功を確認し、安全にロールバックできるでしょうか？ 固定の実行可能性と安全性に関する11項目のチェックリストを適用します。これはリリース手順書の作成者が目指す基準（作成者によるステップ6とステップ7のセルフチェック）と同じもので、作成時とレビュー時の基準がずれないようにします。そのうえで、機械的に解析できる判定を1つと、作成者が1回の改訂で対応できる指摘を出力します。また、既存の手順書に対するバージョン付きの差分である改訂も、差分の範囲に絞ってレビューします（条件9）。これは受け入れゲートです。手順書の作成、修正、書き換えは行いません。評価して指摘を返し、作成者が改訂します。

評価基準は authoring-release-runbook スキルと一元化されています。つまり、リリース手順書の作成者が目指す実行可能性と安全性に関する同じ11項目の条件です。レビュアーが独自の基準を作ることはありません。

有効化する場面

• 完成したリリース／デプロイ手順書を、デプロイ担当者またはオンコールエンジニアに渡す前に、承認または修正の判断が必要な場合。
• 作成者が作成した手順書を独立したレビュアー／ゲートとして確認し、コマンドや検証内容をスポットチェックするための関連資料（architecture-doc／technical-design／test-plan）を持っている場合。
• 以前に revise 判定を受けて改訂された手順書を再評価する場合。

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

• リリース手順書を作成または修復する場合 → リリース手順書作成スキルを使用してください（このスキルが適用するものと同じ基準に沿って作成します）。このスキルが文書を作成することはありません。
• QA テスト計画（何を、どのレベルで、どの範囲までテストするか）をレビューする場合 → テスト計画レビュー用スキルを使用してください。基準が異なります。テスト計画のレビュアーは、リスクに応じた網羅性と、テスト可能な完了基準を確認します。このゲートが確認するのは運用上の実行可能性とロールバックの安全性です。手順書はデプロイ後の検証にテスト計画の終了基準を再利用しますが、QA 戦略を再定義するものではありません。
• エンジニアリング設計文書（仕様書、計画書、technical-design、RFC、ADR）をレビューする場合 → 設計上の主張をコードベースと照合して検証する設計レビュー用スキルを使用してください。そちらは設計を評価します。このスキルが評価するのは運用上の本番リリース手順です。対象となる成果物も基準も異なります。
• CI/CD パイプラインの設定（ビルド・テスト・デプロイの自動化）を確認する場合 → これは別の対象です。手順書はパイプラインを呼び出しますが、このゲートが評価するのはその周辺の手順であり、YAML ではありません。
• テンプレートやセクションへの準拠を確認する場合 → それはテンプレートに関する確認事項です。このスキルが評価するのは基準に対する品質であり、すべての見出しが含まれているかどうかではありません。
• 実際のデプロイや稼働中のサービスを評価する場合 → このゲートが評価するのは手順書であり、本番システムではありません。

ワークフロー

ステップ 1：新鮮な目で、予備知識のない状態でランブック全体を読み、上流資料を確認する

このシステムを一度もデプロイしたことがないオンコールエンジニアが、著者の説明なしに、午前3時に初めて目にした状況を想定して、ランブックを最初から最後まで読みます。予備知識のない担当者を見守るゲートキーパーとして、記載内容どおりでは担当者が手順を実行できない、成功と失敗を見分けられない、または安全にロールバックできない場合、あるいはコマンドやホストが捏造されている、または検証できない場合に限り、指摘を重く扱います。ランブックが想定するデプロイの類型（小規模な単一サービスか、マイグレーションを伴う複数コンポーネントのシステムか）を特定します。ステップ 2 の比例性の評価は、これに基づいて行います。重要なのは、提供された上流資料（アーキテクチャドキュメントのコンポーネントとデプロイトポロジー、技術設計のロールアウト／マイグレーション、テスト計画の終了基準）を必ず読み込むことです。コマンド、ホスト、検証方法の抜き取り確認における正確性の基準となります。上流資料が提供されていない場合は、ここで記録します。ステップ 4 では、実行可能な根拠をたどれない箇所を仮定として明記し、手元にある情報に基づいて判断します。検証できないコマンドが正しいと決めつけてはいけません。

ステップ 2：実行可能性と安全性のチェックリストを適用し、各条件を評価する

以下の各条件について、合格または不足と判定します。条件が不合格となるのは、実在する、明確に特定された不備がある場合に限ります。「手順の順番を自分なら変える」は不足には該当しません。不足がある場合は、該当する正確な手順／箇所と欠けている内容を記録します（ステップ 4 で、対応可能な指摘にまとめます）。以下の 11 条件が唯一の基準です（リリースランブックの作成者がステップ 6 とステップ 7 の自己チェックで用いるものと同じ条件です）。独自の条件を追加してはいけません。条件 9～11 は条件付きです。条件 9（修正）は既存のランブックに対する差分をレビューする場合のみ、条件 10（状態を持つ変更の安全性）はリリースでスキーマ／データを変更する場合のみ、条件 11（コミュニケーション）はデプロイがユーザーに影響する場合のみ適用します。それ以外の場合は、いずれも該当なしとし、不足とは判定しません。リリースのプレッシャー下でも使えることは、ランブック全体を評価するための包括的な観点（ステップ 3 の姿勢）であり、番号付きの条件ではありません。

1. 不慣れなエンジニアでも実行できること。 すべてのデプロイ／ロールバック手順が具体的で、そのままコピー＆ペーストしても安全であること。明確に示された<placeholders>を含む実際のコマンド／操作を記載し、「サーバーを設定する」のような曖昧な文章にしてはいけません。手順を再実行しても安全であること（冪等性があること。ガードされた一度きりの操作、IF NOT EXISTS、追記ではなく上書き）。コマンドを記載すべき箇所に文章しかない場合、または再実行によって状態が損なわれる場合は、ギャップです。
2. 各手順の検証。 すべての手順に、期待される結果と、客観的かつ測定可能な基準による検証チェックが記載されていること（レイテンシ／エラー率の数値、提供中のバージョン、ヘルスステータス、SLO エラーバジェットのバーンレートなど。「体感で速くなった」ではないこと）。検証されていない手順から先へ進んではいけません。期待される結果または測定可能なチェックがなく、オペレーターが成功と気付かれない失敗を区別できない場合は、ギャップです。（バーンレートに基づく基準は、許容される測定方法であり、必須ではありません。生のしきい値でも問題ありません。）
3. Go／No-Go ゲートがあること。 デプロイ前チェックによってデプロイの可否を判定し、チェックが失敗した場合は明示的にNo-Goとして手順を中止すること。デプロイ前チェックがない場合、またはチェックがあっても失敗時にデプロイを止める仕組みがない場合は、ギャップです。
4. トリガーを含む、完全で安全なロールバック。 明示されたトリガー条件（測定可能なエラー率／レイテンシ／SLO エラーバジェットのバーンレート／スモークチェックの失敗）、すべての前進変更に対する、逆順で実行する文書化された復元手順と、戦略に適合した手段（ブルーグリーン＝トラフィックを戻す、カナリア／ローリング＝ルーティングを0％にする／スケールダウンする、再作成＝以前のアーティファクトを再デプロイする、フィーチャーフラグ方式＝フラグをオフにする）、元に戻せない前進変更について明記されたフォワードフィックス／緩和策、ロールバック後にデプロイ前のベースラインを再検証する手順があること。ロールバックが「デプロイをロールバックする」としか書かれていない場合、前進変更に復元手順がない場合、トリガーが曖昧または記載されていない場合、復元手段が戦略に合っていない場合、元に戻せない変更に緩和策が明記されていない場合、またはロールバック後に再検証しない場合は、ギャップです。影響が最も大きい欠陥の種類です。不完全なロールバックは、障害を長引かせる原因になります。（フラグの切り替え／自動カナリアロールバックは許容される手段ですが、完全性の基準は変わりません。）
5. デプロイ後の検証で具体的なチェックを再利用すること。 デプロイ後のスモークテストで、成功基準が測定可能な具体的チェックを使用し、テスト計画が提出されている場合はその終了基準を再利用して、明記されたベイク期間にわたって観測すること。デプロイ後の検証がない場合、「問題なさそう」としか定義されていない場合、または提出済みのテスト計画の終了基準を無視している場合は、ギャップです。
6. 具体的なエスカレーションと監視。 実際のオンコール／エスカレーション経路（誰にページを送るか、重大度の段階、重大度ごとの対応時間目標）と、実際の監視／オブザーバビリティ情報（ダッシュボード／アラート／ログへのリンクと、それぞれの「正常な状態」の説明）があること。プレースホルダーにしてはいけません。エスカレーションや監視が、「オンコールにページする」「ダッシュボードを確認する」のように、具体的な連絡先、リンク、正常時のベースラインを欠くプレースホルダーになっている場合は、ギャップです。
7. シークレットを直接記載しないこと。 実際のトークン／パスワード／キー／接続文字列をランブックに記載せず、シークレットのストア／ボルト／環境変数名を参照すること。ギャップです。ランブックのどこかに実際のシークレットが埋め込まれていれば、指摘事項となり、ストアを参照する必要があります。（シークレットをコミット／デプロイ／ログ出力するファイルに保存してはいけません。）
8. 捏造しないこと。コマンド／ホストが正確であること。 すべてのコマンド、ホスト、エンドポイントが、提出済みの上流資料（アーキテクチャドキュメントのコンポーネント、技術設計のロールアウト、テスト計画の基準）に根拠をたどれるか、ランブックで仮定であることを明示していること。提出済みの上流資料と照らしてコマンド／ホスト／エンドポイントを抜き取り確認し、検証できないものは正しいと決めつけず、指摘すること。テンプレートを埋めるためにコマンド／ホスト／エンドポイントを捏造して事実として提示している場合、または提出済みの上流資料と矛盾している場合は、ギャップです。
9. 差分に限定した修正 (既存のランブックに対する変更をレビューする場合のみ適用される入力条件。新規作成時は該当なし)。レビューの対象は全体の再レビューではなく、差分に限定すること。差分自体を対象とし（編集であり、書き直しではない）、差分のきっかけに対応すること（上流資料の変更を再導出する、またはインシデント後の学びをロールバックトリガー／検証ゲート／修正済み手順に反映する）。変更／追加した手順が該当する必須条件（1／2／4＋7／8）を満たすこと。修正で再検証に対処すること。つまり、手順をエンドツーエンドで再確認して後続手順の前提条件が壊れていないことを確認し、「最終検証日」の情報を更新するか、再検証が保留中であることを明示すること（ドライランの再実施を強制するのではありません。リハーサルはゲートではありません）。変更履歴（ランブックのバージョン更新と、きっかけを記載し、以前のバージョンが置き換えられたことを明記する変更履歴）を残すこと。修正でランブック全体を再生成している場合、編集によって後続手順が壊れたままの場合、復元手順のない前進変更（またはシークレット／捏造）を追加している場合、再検証をまったく考慮していない場合、または変更履歴がない場合は、ギャップです。差分に問題がなければ承認します（「すべてを再レビューしていない」「ドライランを再実行していない」ことを理由に誤って修正を求めてはいけません）。
10. 状態を持つ変更の安全性 (比例適用。リリースによってスキーマまたはデータが変わる場合のみ適用。それ以外は該当せず、ギャップなし)。スキーマ／データへの前進変更が元に戻せる／後方互換性を保つこと（拡張してから縮小する方法／並行変更の手順、つまり追加、移行、後から縮小する方法）、または元に戻せない変更について、データを失う架空のダウンマイグレーションではなく、明示された復旧経路（フォワードフィックス／影響の封じ込め／バックアップからの復元）を示すこと。判断基準は結果であり、手法の名称は必須ではありません。後方互換性のある手順も明示された復旧経路もない状態で、破壊的なスキーマ変更がリリースされる場合（データを復旧できないダウンマイグレーションを「ロールバック」とするDROP／破壊的な変換）は、ギャップです。（条件4に追加されます。致命的なマイグレーションの欠陥が両方に該当するのは、意図的に重大性を強調するためです。一度だけ修正してください。）
11. 告知／メンテナンス時間帯 (比例適用。デプロイがユーザーに影響する場合のみ適用。内部向け／ユーザー影響ゼロのデプロイには該当せず、ギャップなし。レビュアーはコメント不要)。ユーザーに影響するデプロイでは、告知／メンテナンス時間帯の計画を明記すること（事前告知／ステータスページでの時間帯の告知／復旧通知。各チャネルの担当者も記載）。判断基準は結果です。明らかにユーザーに影響するデプロイ（ダウンタイム／顧客向けの変更）に、告知計画がまったくない場合に限り、ギャップです。 相応性。「慣れていないエンジニアがデプロイし、検証し、ロールバックできるか」という基準は、デプロイの規模に応じて変わります。小規模な単一サービスのリリースでは、不要なセクションを適切に省略できます。インスタンスが1つなら複数バッチでのロールアウトは不要ですし、チームが小さければ簡潔なエスカレーション経路で十分です。対象範囲が小さければ監視リンクも少なくてかまいません。スキーマを変更しないなら cond-10 のステートフルセーフティに関するセクションは不要ですし、ユーザーがいなければ cond-11 のコミュニケーション計画も不要です。これは適切な規模調整であり、欠落ではありません。文章量やセクション数ではなく、オペレーターが実行して復旧できる能力を評価してください。適用される条件をすべて満たす、小規模で完結したランブックは合格です。簡潔さを理由に欠落をでっち上げないでください。（条件4、7、8は規模に関係なく適用されます。すべての前進変更にリバート手段があり、シークレットが直接記述されておらず、何も捏造されていないこと。条件9、10、11は条件付きであり、該当しない場合は適用外です。）

ステップ 3：判定を決める

• approve — 適用される条件をすべて満たしている（該当しない条件付きの cond. 9/10/11 は欠落ではなく適用外です）。また、ランブックがリリース時のプレッシャー下でも使える内容である（全体的な観点として、作成者がいなくても午前3時に手順を追える）。慣れていないエンジニアが、記載どおりにこのランブックを使ってデプロイを実行し、成功を確認し、安全にロールバックできます。シークレットは直接記述されておらず、何も捏造されていません。**修正（amend）**の場合は、変更差分の範囲に絞った問題のないレビュー（cond. 9）を承認してください。変更されていないランブックを再度審査しないでください。文体上の改善点を思いついても承認してください。基準となるのは実行可能性と安全性であり、完璧さでも、過剰な網羅性でもありません。
• revise — 適用される条件のうち1つ以上に、安全な実行を妨げる具体的な欠落があります（検証手順のないデプロイ手順、リバート手段のない前進変更、直接記述されたシークレット、捏造されたコマンドや検証不能なコマンド、go/no-go ゲートの欠落、仮置きのエスカレーション経路、復旧手段のない破壊的なスキーマ変更、後続の前提条件を壊した修正など）。

努力を示すため、またはあるとよいだけの項目を求めるために修正を要求しないでください。条件は満たされているか、満たされていないかのどちらかです。該当しない条件に関して、簡潔なランブックに修正を要求しないでください。

ステップ 4：判定と実行可能な指摘を出力する

判定は 1 行で出力します。VERDICT: approve または VERDICT: revise の文字列をそのまま単独行に記載し、前後にコードフェンス、引用符、余分な語句を付けないでください（ここでのフェンスは説明用です）。

VERDICT: approve

次の行から、指摘を列挙します。revise の場合、各指摘はすべて実行可能な内容にします。不合格となった条件、正確な手順／箇所、修正方法を明記し、作成者が一度で解決できるようにしてください。approve の場合、指摘は任意の非ブロッキングな注記です。修正が必要だと誤解させないでください。

上流資料が提供されていない場合は、その旨を指摘で明示的な前提として記載します（例：「architecture-doc は提供されていません。コマンド／ホストの正確性（条件 8）は、runbook の内部整合性に基づく抜き取り確認のみです。完全なトレースには上流資料を提供してください」）。それ以外の条件は、手元にある資料に基づいて判定してください。実行不能な正確性チェックを黙って見過ごしてはならず、検証できないコマンドが正しいと決めつけてはなりません。

適切な指摘では、不足点と修正方法を明記します。

revise — 完全性と安全なロールバック（条件 4）、「ステップ 5：スキーマ移行を実行」：この変更には、文書化された差し戻し手順もロールバックのトリガーもありません。修正方法：逆方向の移行手順を追加してください。元に戻せない場合は、その旨と、前進修正／バックアップからの復元による緩和策を明記し、ロールバックを発動する測定可能なトリガー（例：10 分間の監視期間中にエラー率が 2% を超える）を設定してください。

revise — インラインにシークレットがないこと（条件 7）、「ステップ 2：デプロイ」：この手順には、パスワードを含む稼働中のデータベース接続文字列が埋め込まれています。修正方法：シークレットを値ではなく、シークレットストアまたは環境変数の名前（例：Vault の $DATABASE_URL）で参照してください。値は出力せず、存在だけを表示してください。実際のシークレットを runbook に含めてはなりません。

revise — 各手順の検証（条件 2）、「ステップ 4：新しい環境にトラフィックを切り替える」：期待される結果も確認方法もありません。修正方法：期待される出力（例：green にトラフィックが 100% 流れていること、/healthz が HTTP 200 を返すこと）と、次に進む前にオペレーターが実行する測定可能な確認方法を記載してください。

revise — ステートフルな変更の安全性（条件 10）、「ステップ 3.2：ALTER TABLE orders DROP COLUMN legacy_total」：これは破壊的で元に戻せない変更ですが、ロールバック手順は「down-migration を実行する」とされています。削除したカラムのデータは down-migration では復旧できません。修正方法：変更を expand-contract 方式で段階的に行い（このリリースではカラムへの書き込みを停止し、後続リリースで削除する）、またはロールバックに実際の復旧手段（<location> からのバックアップ復元／前進修正）を明記してください。

revise — 差分の範囲に限定した修正（条件 9）：変更依頼でステップ 3.1 のデプロイ先環境の名前を変更していますが、ステップ 4.2 の検証では引き続き旧ホストに対して curl を実行しています。この編集により後続の前提条件が崩れています。修正方法：手順を最初から最後まで再検証し、ステップ 4.2（およびそれ以降の該当手順）を新しいホストに更新してから、runbook のバージョンを更新し、変更理由を変更履歴に記載してください。

悪い指摘は曖昧で、実行可能ではありません。

ロールバックの節は、もっと詳しくできるでしょう。(どの変更のことですか？ どのトリガーですか？ 何を直せばよいですか？)

ルール

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

• 判定行は必ず1行だけ出力し、VERDICT: approve または VERDICT: revise とする — この文字列を単独の行に出力し、その行にはほかの文字を含めないでください。後続のツールがこれを解析します（判定解析の契約）。ほかの判定表現は使用しないでください。
• 作成するのではなく、評価してください。 指摘事項を返してください。ランブックを書き換えたり、修正したり、内容を補ったりしないでください。修正するのは作成者です。
• 単一の判断基準を適用してください。 Step 2 の11項目を基準に評価してください。これは作成者が従う基準（Step 6 と Step 7 のセルフチェック）と同じです。条件を新たに設けたり、独自のより厳しい基準を適用したりしないでください。
• 条件付きの条件は、該当しない場合に不合格扱いしないでください。 条件9（変更）は既存のランブックに対する差分がある場合のみ、条件10（ステートフルな安全性）はスキーマまたはデータを変更する場合のみ、条件11（連絡）はデプロイがユーザーに影響する場合のみ適用されます。適用されない場合は該当なしであり、欠落ではありません。該当する条件がないのに、内容が簡素なランブックを理由に修正を求めてはいけません。
• 既存ランブックの変更は、差分を対象に評価してください。 既存のランブックに対する変更を受け取った場合、変更部分を評価してください（条件9）。対象範囲内であること、該当するトリガーへの対応、エンドツーエンドの再検証への対応、変更履歴を確認します。変更されていないランブックまで評価対象にしないでください。再度のドライランを強制しないでください。リハーサルは役立ちますが、必須条件ではありません。
• ロールバックの完全性が最重要です。 すべての変更を逆順に戻す手順、測定可能なトリガー、ベースラインへの再検証が必要です。不可逆な変更は、その緩和策を明記してください。ロールバックが不完全な場合（条件4）は、影響が最も大きい欠陥です。長時間の停止につながりかねません。
• 秘密情報の直書きは、必ず指摘事項になります。 ランブック内のどこかに実際のトークン、パスワード、キー、接続文字列が含まれている場合、利便性にかかわらず条件7に違反します。保管場所、Vault、環境変数の名前を参照させてください。
• コマンドを、提供された上流資料と照合してスポットチェックしてください。検証できないものは指摘してください。 各コマンド、ホスト、エンドポイントが、上流資料（アーキテクチャ文書／技術設計／テスト計画）または明示的な前提に基づいているか確認してください。検証できないコマンドは指摘してください（条件8）。正しいと決めつけてはいけません。 捏造されたコマンドや上流資料と矛盾するコマンドは欠陥です。
• 不当な修正要求をしてはいけません。 適用されるすべての条件を満たすランブックは、たとえ小規模なデプロイ向けで簡素であっても承認してください。運用上重要な手順を網羅したうえで、規模に応じた内容にすることは欠陥ではありません。実際に存在し、具体的に特定できる欠落がある場合にのみ、修正を求めてください。
• 不当な承認をしてはいけません。 好意的に見せるために、実際の欠落を見過ごして承認してはいけません。阻害要因となる欠落があれば、revise としてください。
• デプロイ手順に検証がなければ欠落です。 期待される結果または測定可能な確認方法のいずれかがない手順は、条件2に違反します。オペレーターが、成功と検出されない失敗を見分けられないためです。
• 捏造は根拠ではなく、欠落です。 事実として示された架空のコマンド、ホスト、エンドポイント、しきい値は条件8に違反します。実際の欠落は、前提として明示すべきであり、取り繕ってはいけません。
• 上流資料の不足は、黙って見過ごさず指摘してください。 上流資料が提供されていない場合は、それを明示的な前提として示し、コマンドやホストの正確性を十分にスポットチェックできなかったことを記載してください。そのうえで、提供された情報に基づいて残りを評価してください。
• ランブックに提供された上流資料に照らして評価してください。 depends_on セット（プロジェクトが実際に作成した上流資料）を基準に評価してください。作成されていない上流資料を、修正要求の理由にしてはいけません。プロジェクトが作成していない文書を期待してはいけません。ただし、参照すべき作成済みの上流資料をランブックが無視している場合（たとえば、提供されたテスト計画の終了基準をデプロイ後検証で再利用していない場合）は、正当な指摘事項です。
• 修正を求める指摘は、すべて実行可能な内容にしてください。 違反した条件、該当箇所、具体的な修正方法を示してください。曖昧な指摘はしないでください。

推奨事項（上書き可能）：

• 指摘事項は重大度順に並べてください。ロールバックの不完全さと秘密情報の直書きを最初にし、その後に残りを続けます。
• 作成者が基準に照らして確認できるよう、各指摘事項に条件番号または条件名を記載してください。
• 承認に添える注記は少数にとどめ、ブロッキングではないことを明確にしてください。

注意点

• 実行可能性ではなく、項目が埋まっていることを承認する。 すべてのセクションが存在していても、手順書が実行できるとは限りません（コマンドが必要な箇所に説明文がある、検証のない手順がある、ロールバックが「ロールバックする」とだけ書かれているなど）。見慣れないエンジニアがこの手順書でデプロイし、復旧できるかを評価してください。テンプレートが埋まっているかではありません。
• 完成しているように見える不完全なロールバック。 ロールバックのセクションが周到に見えても、1つの変更（スキーマ移行、フィーチャーフラグ、DNS の切り替えなど）に戻す手段がなく、それがまさに障害を長引かせる変更である場合があります。デプロイに含まれるすべての変更に、それと対応する復元手順があるかを確認してください（条件 4）。復元手順のない変更は、影響が最も大きく、見落とされやすい欠陥です。
• デプロイ戦略と一致しないロールバック。 Blue-green ではトラフィックを戻し、recreate では旧アーティファクトを再デプロイし、canary ではルーティングを 0% にしてロールバックします。実際のデプロイ戦略に合わないロールバック手順は、インシデント時に機能しません。ロールバックが手順書に記載された実際のデプロイ戦略に合っているか確認してください。
• 一見して見落としやすい、埋め込まれたシークレット。 有効なトークン、パスワード、接続文字列を手順に貼り付けると、動作するコマンドのように見えても、手順書が置かれるあらゆる場所にシークレットが漏えいします。実際の認証情報の値はすべて指摘事項です（条件 7）。保管先を参照する必要があります。「シークレット」のセクションだけでなく、コマンドの例に値が埋め込まれていないかを確認してください。
• でっち上げられたホスト名／コマンド。 完成しているように見せるために作り出されたホスト名や CLI フラグは、初回の使用で失敗する手順書につながります。コマンドやホスト名を、提出された上流資料と照合して抜き取り確認してください（条件 8）。上流資料による裏付けも、前提であることを示す記載もない場合、それは網羅性ではなく欠陥です。
• 存在しないダウンマイグレーションを前提とした、不可逆な移行（条件 10）。 DROP や破壊的な変換の「ロールバック」として、削除したデータを復元できないダウンマイグレーションが書かれていても、完成しているように見えるだけで実際には不完全です。データは失われています。破壊的なスキーマ変更が、expand-contract の順序で行われるか、実際の復旧方法（バックアップからの復元／修正を前に進める方法）が明記されているかを確認してください。ただし、これは比例原則に従って評価します。スキーマに変更がない場合は該当しません。
• 修正依頼を全面レビューとして再評価する（条件 9）。 変更依頼に対しては、差分、エンドツーエンドの整合性（編集によって後続の前提条件が壊れていないか）、変更履歴を評価してください。変更されていない手順書全体を対象にしたり、改めてドライランを必須にしたりしないでください。すべてを再レビューすること、または再検証が保留と明記されているのに、新しい「最終検証日」の記載がないことを理由に修正を求めることは、修正依頼の主な誤りです。
• 社内デプロイにコミュニケーションのセクションを要求する（条件 11）。 コミュニケーション要件はユーザーへの影響に比例させます。ユーザーがいない社内デプロイにステータスページの計画がないことを指摘して修正を求めるのは、誤った修正要求です。
• 上流資料の不足を見落とす。 上流資料が提出されていない場合、コマンドの正確性を完全には抜き取り確認できません。その不足を理由に承認してはいけません。前提事項として指摘し（条件 8 の一部が実行不能）、残りを評価してください。検証できないコマンドが正しいと決めつけてはいけません。
• 体系的な過剰指摘（誤った修正要求）。 問題の発見を求められたレビュー担当者は、特に修正案も提示しようとすると、過剰に修正し、妥当な手順書まで欠陥があると判断しがちです。基準に照らして評価してください。条件を満たしていないと判断できるのは、明確に特定できる実際の不備がある場合だけです。手順の順序や、別の書き方にしたかったという理由では不備になりません。もっともらしいだけの細かな指摘が、ここでレビュー担当者に最も多い誤りです。
• 規模に見合った手順書に対する誤った修正要求。 1つのサービスの小規模なデプロイには、それに見合った小規模な手順書が適切です。複数バッチでのロールアウトがなく、エスカレーション経路が簡潔で、監視リンクが少なくても問題ありません。これは仕様不足ではなく、適切な規模設定です。簡潔さを理由に不備を作り出すと、避けられる修正のやり取りが発生します。想定される類型に合わせて評価してください（条件 4、7、8 は引き続き適用されます。すべての変更に復元手順があること、シークレットが埋め込まれていないこと、作り出された情報がないこと）。
• これをテスト計画や設計レビューのゲートと混同する。 ここで評価するのは、運用に用いる本番稼働手順書です。テスト計画レビューでは QA の網羅性／テスト可能性の戦略を評価し、設計レビューではコードベースに照らしてエンジニアリング設計文書を審査します。デプロイ手順に QA 網羅性や設計文書の基準を適用しないでください。
• 判定トークンの不一致。 「Approved」、「LGTM」、「needs work」、または段落の途中に埋め込まれた判定は、正しく解析されません。VERDICT: approve|revise を単独の行にそのまま出力してください。

アンチパターン

• 安易な承認。 修正のやり取りを避けるためにざっと目を通して承認することです。このゲートは、面識のないエンジニアが実行も復旧もできないランブックを見つけるためにあります。元に戻す手順のない変更、直書きされたシークレット、検証手順のないステップを見逃すと、デプロイの失敗や長期化する障害につながります。
• ロールバックの追跡を省略する。 「デプロイ手順に問題はなさそうなので、承認します」――すべての変更に対して元に戻す手順を追跡しないと、最も影響の大きい欠陥の種類（条件4）を見逃します。不完全なロールバックは、このゲートが最も見つけるべき問題です。
• 上流のスポットチェックを省略する。 「コマンドはもっともらしいので、承認します」――提出された上流情報と照合するスポットチェックをしないと、捏造されたコマンドや古くなったコマンドを見逃します（条件8）。上流情報が提出されているのに、それを確認せずランブックだけをレビューするのは、このゲートが禁じる近道です。
• 些細な指摘による修正要求。 ステップの順序の好み、文言の好み、あるいは必須ではない改善点を問題として扱い、承認を妨げることです。修正を求めるのは、実行可能性や安全性を実際に妨げる問題がある場合だけです。
• 黙って書き換える。 「ロールバックのステップを直したほうが早かったので、修正しました」――レビュー中に作成者が手を加えると、作成と評価の分離が崩れ、作成者が問題点から学ぶ機会が失われます。
• 条件をでっち上げる。 基準にない独自の要件（「負荷テストの付録も必要です」など）を加えると、レビュー基準が作成基準からずれ、根拠のない修正要求が生じます。評価するのは11の条件だけです。技法の補助要素（拡張・縮小の段階的適用、カナリア分析、フィーチャーフラグ、ドライラン、バーンレートの数値）は、手法の名称ではなく結果で評価し、特定の名称で要求してはいけません。
• 条件付き条件に対する誤った修正要求。 ステートレスなデプロイに「マイグレーション安全性のセクションがない」、内部ツールに「コミュニケーション計画がない」、変更修正に「ドライランを再実行していない」と指摘することです。いずれも該当なしであり、問題ではありません。条件9、10、11は適用されない場合には対象外になります。
• 過剰主義。 必要のない小規模な単一サービスのデプロイに、複数バッチでのロールアウト、完全なSREエスカレーションツリー、長大な監視項目一覧を要求することです。基準となるのは、オペレーターが実行して復旧できるかどうかであり、考えうる限り最大のランブックではありません。
• 曖昧な判定。 「おおむね承認ですが……」や、判定行を2つ書くことです。判断は1つだけ、トークンも1つだけにしてください。

出力

1つのリリース／デプロイ用ランブックに対するレビュー結果を1つ出力します。

• 判定行は1行 — VERDICT: approve または VERDICT: revise をそのまま、自分だけの行に記載します。
• 指摘事項 — revise の場合は、承認を妨げる問題ごとに、対応可能な指摘を1つ記載します（満たしていない条件＋該当箇所＋具体的な修正方法）。approve の場合は、任意で承認を妨げない注記を記載できます。

レビュー対象のランブックは、現時点ではテキスト形式です。番号付きの手順、フェンスで囲まれたコマンド／チェックのスニペット、期待される出力のブロック、検証／チェックの表、ダッシュボード／モニターへのリンク（ローカルのドキュメントバックエンドを介したMarkdown）で構成されます。レビューの手法と基準は媒体に依存しません（将来、レンダリングされた運用コンソールに変わっても、変わるのは媒体だけであり、評価内容は変わりません）。抽象的な利用者とは、作成->レビューのループを調整するものです。approve は、デプロイ担当／オンコールエンジニアが使用できるようランブックを承認し、revise は、指摘事項を作成者に返して、範囲を限定した修正作業を依頼します。

関連項目

• release-runbook-authoring スキル（authoring-release-runbook）— このペアの作成側です。このスキルが評価するものと同じ11 条件の実行可能性＋安全性の基準を満たすランブックを作成します（その Step-6 ＋ Step-7 のセルフチェック）。この 2 つを組み合わせることで、基準を一元化し、作成とレビューで基準がずれないようにします。
• test-plan-review スキル — QA テスト計画（カバレッジ、レベル、テスト可能な完了基準）のゲートです。対象となる文書も基準も異なります。ランブックではデプロイ後の検証にテスト計画の終了基準を再利用します（条件 5）が、このゲートが評価するのは QA 戦略ではなく、運用手順です。
• design-review スキル — エンジニアリング設計文書（spec、plan、technical-design、RFC、ADR）のゲートです。設計上の主張をコードベースと照合して検証します。対象となるゲートも成果物も異なり、運用上の go-live ランブック向けではありません。
• 上流の architecture-doc ＋ technical-design ＋ test-plan（提供されている場合）— デプロイ可能なコンポーネント、ロールアウト、終了基準です。このゲートでは、これらを基にランブックのコマンドと検証内容を抜き取り確認します（条件 8 ／条件 5）。
• release-runbook template ／ content-template ツール — セクションの構成を担います。このスキルが評価するのは、基準に対する品質であり、構造への準拠ではありません。

段階的な開示

• references/executability-safety-bar.md — 11 条件の基準を詳しく説明します。条件ごとの合格／不足の兆候と、具体的な所見に加え、掘り下げた条件（条件 2 のバーンレート、条件 4 のレバー＋戦略との一致）および新しい条件（条件 9 の修正、条件 10 のステートフルな変更の安全性とその比例的な簡素化、条件 11 のコミュニケーションとその比例的な簡素化）を記載しています。境界的な判定の調整時に読み込みます。
• references/sources.md — レビュー手法の調査出典情報（実行可能性／安全性の品質基準の一元化、および各条件の背景にある SRE／運用上の根拠 — 検証ゲート、ロールバックのトリガー、エクスパンド・コントラクト＋ロールフォワード、バーンレート、デプロイ戦略の仕組み、フィーチャーフラグ、参照によるシークレット管理）。ガイダンスの出典を監査するときにのみ読み込みます。

本文の上限

• description は 1,024 文字以下（agentskills.io の上限）。Claude は一覧表示で description ＋ when_to_use の合計が 1,536 文字を超えると切り詰めます。
• 本文は約 500 行／5,000 トークン以下 — 毎ターン、コンテキスト内に保持されます。
• 参照ファイルごとに、10k トークン超で警告、25k 超でエラー。参照ファイルの合計は、25k トークン超で警告、50k 超でエラーです。