production-audit

本番リリース監査

リリース対象の範囲を調査し、本番環境でのリスクを特定して、アプリケーションを安全にリリースできるか評価します。

契約

入力：

• リポジトリ、ブランチ、PR、リリース候補、またはデプロイ済み URL
• 任意：リリースに不可欠なフロー、テストアカウント、環境に関するメモ、または CI 実行結果

出力：

• 評点と根拠を添えたリリース可否の推奨
• ブロッカー、効果の高い修正、証拠の不足、次のアクション
• 具体的なファイル、コマンド、CI、または URL への参照

作成／変更：

• 監査モードではなし
• 明示的に依頼された場合に限り、フォローアップの修正を実施

外部への副作用：

• 読み取り専用のローカルコマンド、および許可された HTTP／ブラウザーでのチェック
• デフォルトでは、ソースのアップロード、破壊的なマイグレーション、本番環境への書き込み、スキャナーの実行は行いません

確認が必要な操作：

• 認証情報を用いる本番環境での操作、リモートスキャナーの使用、デプロイ、マイグレーション、データ変更、またはユーザーに影響するテストの実施前

委任先：

• アプリケーションのセキュリティに関する検出事項は security-audit
• リリースの仕組みは deploy-app または deployment-composer
• trunk SHA のゲート設定とリリース作成は release
• リリースに不可欠なブラウザーテストが不足している場合は playwright-e2e-init、既存のテストは test-runner

使用するタイミング

• ユーザーが「本番環境にリリースできる状態ですか？」「本番環境で何が壊れますか？」「リリースして大丈夫ですか？」「このリリースを監査してください」「何か見落としはありませんか？」と尋ねた場合
• ローンチ、デモ、顧客への展開、または投資家向けのデモが近い場合
• CI は成功しているものの、本番環境のリスクを確認する必要がある場合
• リスクの高い PR がマージされた場合や、依存関係がアップグレードされた場合
• デプロイ済みのステージング環境またはプレビュー URL のリリース準備状況を確認する必要がある場合

コンプライアンス、法務、財務、医療、またはセキュリティの認証ではありません。エンジニアリング上のリリーストリアージのみを行います。

証拠の確認順序

まず、手間のかからないローカルの証拠から確認します。

git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD

次に、実際に存在する範囲を調査します。

• パッケージスクリプト、ビルドコマンド、CI ワークフロー、リリーススクリプト
• API ルート、認証ミドルウェア、Webhook、ワーカー、cron ジョブ、キュー
• マイグレーション、シードデータ、バックフィル、ロールバックに関するメモ、データアクセスポリシー
• 環境変数のドキュメントと起動時の検証
• 決済、メール、ストレージ、AI、外部プロバイダーとの境界
• 可観測性、ログ、ヘルスチェック、ダッシュボード、アラートの担当者
• リリースに不可欠なユーザーパスを対象とする E2E テストまたはスモークテスト
• 対象に URL が含まれる場合は、デプロイ済み URL のチェック

CI が成功しているというだけで、リリースに問題がないと判断してはいけません。

リスクの観点

セキュリティと認証

• 機密性の高いルートはサーバー側で保護されていますか？
• 認可チェックはテナントを考慮し、データアクセスの近くで適用されていますか？
• クライアントバンドル、ログ、サンプル、コミット済みファイルにシークレットが含まれていませんか？
• アップロード、CORS、CSRF、レート制限、入力検証は適切ですか？
• エージェントや AI のインターフェースは、信頼できないコンテンツと特権ツールを適切に分離していますか？

データの整合性

• マイグレーションを安全に適用できますか？
• 影響の大きい変更に対するロールバック、復旧、またはバックアップの手段はありますか？
• 破壊的なバックフィルは段階的に実行され、冪等性が確保されていますか？
• 書き込み、ジョブ、Webhook の再試行は安全ですか？
• サンドボックス、ステージング、本番環境のスキーマは、コードが想定する内容と一致していますか？

決済と Webhook

• ペイロードのフィールドを信頼する前に、Webhook の署名を検証していますか？
• 重複配信に対して、フルフィルメントのハンドラーは冪等に動作しますか？
• 順不同のイベントや再送されたイベントを適切に処理していますか？
• テスト用と本番用の認証情報は分離されていますか？
• プロバイダーの障害後も、顧客に表示される請求状態を復旧できますか？

運用

• ドキュメントに記載されたコマンドを使い、クリーンなチェックアウトからアプリを起動できますか？
• 必須の環境変数は明記され、起動時に検証されていますか？
• 依存関係への接続を確認できるヘルスチェックはありますか？
• シークレットや個人データを漏らすことなく、ログから有用な情報を得られますか？
• デプロイ、ロールバック、インシデント対応の担当者が明確ですか？

ユーザーエクスペリエンス

• リリースに不可欠なパスは、デスクトップとモバイルの両方でテストされていますか？
• 読み込み中、空、エラー、権限拒否の各状態は使いやすいですか？
• フォームは、無効な入力、応答の遅いリクエスト、二重送信に対応していますか？
• 重要な操作が失敗した場合の復旧手段やサポート窓口はありますか？

スコアリング

スコアを使って優先順位を決めます。

スコア	判定
0-49	ブロック：ブロッカーを修正するまでリリースしないでください
50-69	リスクあり：社内ベータ版、または小規模なロールアウトに限定してください
70-84	注意事項付きでリリース可能：責任者が明示されたリスクを受け入れる場合にリリースしてください
85-100	良好：入手できる証拠からは明らかなリリースブロッカーはありません

次のいずれかに該当する場合、スコアの上限を 69 とします。

• 機密データに対する認証または認可がない
• 決済またはフルフィルメントのウェブフックが冪等ではない
• 必須のマイグレーションを安全に実行できない
• クライアントバンドル、ログ、またはコミット済みファイルでシークレットが漏えいしている
• 影響の大きいリリースにロールバックまたは復旧の手段がない

CI がグリーンでない場合、またはリリースに不可欠な経路をエンドツーエンドでテストしていない場合、スコアの上限を 84 とします。

出力形式

最初に1文を記載します。

Production audit: 76/100, launchable with caveats, with webhook idempotency and rollback docs as the two risks to fix before public launch.

次に、以下を列挙します。

• Blockers：デプロイ前に必ず修正する項目
• High-value fixes：影響度の高い、次に実施すべき改善
• Evidence checked：確認したファイル、コマンド、CI、URL、または PR
• Evidence missing：確信度を高めるために必要な情報
• Next action：具体的な修正または検証手順を1つ

ブロッカーが見つからない場合も、証拠の範囲を必ず明示します。

アンチパターン

• ピン留めされていないリモートスキャナーをデフォルトの監査手段として実行する。
• 明示的な承認を得ずに、プライベートなソースコード、シークレット、顧客データ、またはトポロジーを外部にアップロードする。
• 証拠を明示せずにスコアを付ける。
• ステージング環境でのスモークテストを、データマイグレーションが安全である証拠として扱う。
• 次に実施すべき具体的なリリースアクションではなく、一般的な要約で締めくくる。