production-audit

プロダクション監査

このスキルは、ユーザーがアプリケーションの出荷準備ができているか、本番で何が壊れる可能性があるか、ローンチ前に修正すべき点は何かと尋ねたときに使用します。これは、古くなったコミュニティ版の production-audit アイデアをメンテナーセーフに書き直したものです。プロダクション readiness という有用なレンズを維持しつつ、固定されていない外部実行や第三者データ共有を排除しています。

使用すべき場合

• ユーザーが「これはプロダクション対応ですか」「本番で何が壊れるか」「何を見逃したか」「このリポジトリを監査して」「出荷準備はできていますか？」と尋ねた場合。
• 機能がマージされ、デプロイ前またはマージ後のリスクパスが必要な場合。
• 公開ローンチ、デモ、顧客ロールアウト、または投資家向けウォークスルーが近づいている場合。
• CIはグリーンだが、テストステータスだけでなくプロダクションリスクも確認したい場合。
• 証拠収集のために、デプロイされたURL、リリースブランチ、PR、または現在のチェックアウトが利用可能な場合。

使用すべきでない場合

• アクティブな実装中で、適切なレンズが行レベルのセキュアコーディングである場合。まず security-review を使用してください。
• 純粋なライブラリ、テンプレート、ドキュメントのみのリポジトリ、またはスキャフォールドの場合。ただし、ユーザーがアプリケーション readiness ではなくパッケージング/リリース readiness を求めている場合は除きます。
• ユーザーが正式なコンプライアンス監査を求めている場合。このスキルはエンジニアリングトリアージであり、法的、財務、医療、規制の認証ではありません。
• 利用可能な唯一の証拠が製品アイデアであり、リポジトリ、デプロイ、CI、またはランタイムの表面がない場合。

仕組み

監査はローカルおよびユーザーが承認した証拠から構築します。固定されていないリモートコードを実行したり、リポジトリの内容を第三者サービスにアップロードしたり、外部スキャナーを呼び出したりしないでください。ただし、ユーザーがその特定のツールとデータフローを明示的に承認した場合は除きます。

次の順序で行います：

1. リリース表面を確立する。
2. 最近の変更と現在のブランチ状態を読み取る。
3. リポジトリに実際に存在するランタイム、認証、データ、支払い、バックグラウンドジョブ、AI、およびデプロイの境界を検査する。
4. CI、テスト、マイグレーション、環境ドキュメント、およびロールバックパスを確認する。
5. 特定の修正を含む、出荷/ブロックの短い推奨事項を作成する。

証拠チェックリスト

安価なローカルシグナルから始めます：

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

次に、プロジェクト固有の表面を検査します：

• パッケージスクリプト、CIワークフロー、リリーススクリプト、Dockerファイル、およびデプロイマニフェスト。
• APIルート、Webhook、認証ミドルウェア、バックグラウンドワーカー、cronジョブ、およびデータベースマイグレーション。
• 環境変数のドキュメントと起動時チェック。
• 可観測性フック、エラーレポート、ログ、ヘルスチェック、およびダッシュボード。
• ロールバック、シード、マイグレーション、バックフィルの手順。
• 最も重要なユーザーパスのE2Eカバレッジ。

デプロイされたURLがスコープ内にある場合は、そのURLに対するブラウザまたはHTTPチェックのみを使用し、ユーザーが安全なテストアカウントを提供しない限り、認証付きアクションは避けてください。

リスクレンズ

セキュリティと認証

• 公開ルート、APIルート、管理ルートは明確に分離されていますか？
• 認証と認可はサーバーサイドで強制されていますか？
• シークレットはクライアントバンドル、ログ、出力例、およびチェックインされたファイルから除外されていますか？
• レート制限、CSRF保護、CORSポリシー、アップロード検証は、アプリが必要とする場所に存在していますか？
• AIまたはエージェントの表面は、プロンプトインジェクション、ツールの悪用、および信頼できないコンテンツが特権アクションにクロスするのを防御していますか？

データ整合性

• マイグレーションは正常に前方実行され、ロールバックまたはリカバリ計画はありますか？
• 破壊的なマイグレーション、バックフィル、データインポートは安全にステージングされていますか？
• データベースポリシー、権限、サービスロールの境界は、アプリのテナンシーモデルと一致していますか？
• 書き込み、ジョブ、Webhookハンドラーのリトライは冪等ですか？

支払いとWebhook

• Webhookの署名は、信頼できるペイロードフィールドを解析する前に検証されていますか？
• 各支払い、サブスクリプション、フルフィルメントのWebhookは冪等ですか？
• 再生、重複配信、順序不同配信は処理されていますか？
• テストモードとライブモードの認証情報は分離されていますか？

運用

• アプリは、ドキュメント化されたコマンドを使用してクリーンチェックアウトから起動できますか？
• 必要な環境変数は名前が付けられ、検証され、fail-fastですか？
• 依存関係に到達可能であることを証明するヘルスチェックはありますか？
• デプロイ、ロールバック、インシデントオーナーのパスはドキュメント化されていますか？
• ログは、シークレットや個人データを漏洩せずに有用ですか？

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

• ローンチクリティカルなパスは、デスクトップとモバイルでカバーされていますか？
• フォームは、入力ズーム、レイアウトの重なり、送信状態のブロックなしにモバイルで使用可能ですか？
• ローディング、空、エラー、および権限拒否の状態は、ユーザーに何が起こったかを伝えていますか？
• クリティカルな操作が失敗した場合のサポートまたはリカバリパスはありますか？

スコアリング

スコアは優先順位付けを強制するために使用し、数学的な確実性を示すためではありません。

バンド	スコア	意味
ブロック	0-49	最優先リスクが修正されるまで出荷しない
リスクあり	50-69	小規模ロールアウトまたは内部ベータ版でのみ出荷
注意付きでローンチ可能	70-84	所有者がリストされたリスクを受け入れる場合に出荷
強固	85-100	利用可能な証拠から明らかなローンチブロッカーなし

次のいずれかが真の場合、スコアを 69 に制限します：

• 機密データに対する認証または認可が欠落している。
• 支払いまたはフルフィルメントのWebhookが冪等でない。
• 必要なマイグレーションを安全に実行できない。
• シークレットがクライアントバンドル、ログ、またはコミットされたファイルに露出している。
• 影響の大きいリリースに対するロールバックパスがない。

CIがグリーンでない場合、またはローンチクリティカルパスがエンドツーエンドでテストされていない場合、スコアを 84 に制限します。

出力形式

最初の一文でリードします：

プロダクション監査：76/100、注意付きでローンチ可能。Webhookの冪等性とロールバックドキュメントが、公開ローンチ前に修正すべき2つのリスクです。

次にリストします：

• ブロッカー：デプロイ前に修正必須の項目。
• 高価値修正：スコアを向上させたい場合の次の修正。
• 確認済み証拠：検査したファイル、コマンド、CI、デプロイされたURL、またはPR。
• 不足している証拠：提供された場合に信頼度を変えるもの。
• 次のアクション：具体的な修正または検証手順。

強みは簡潔に保ちます。ユーザーは準備状況を尋ねているので、有用な回答は残りのリスクと次のアクションです。

例

ユーザー：

これは出荷準備できていますか？

応答：

プロダクション監査：68/100、リスクあり。StripeのWebhookは検証されているが冪等ではなく、保留中のマイグレーションに対するロールバックメモがないため。

ブロッカー：
- 注文をフルフィルする前に `checkout.session.completed` に冪等性を追加する。
- `20260511_add_billing_state.sql` のロールバックパスを作成してテストする。

高価値修正：
- データベースと支払いプロバイダーの到達可能性を検証するヘルスチェックを追加する。
- アップグレード、Webhookフルフィルメント、請求ページ更新のための1つのE2Eパスを追加する。

確認済み証拠：
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- リリースブランチのGitHub Actionsの実行

次のアクション：最初にWebhookの冪等性をパッチしましょうか？

アンチパターン

• デフォルトの監査パスとして npx <package>@latest またはリモートスキャナーを実行すること。
• 明示的な承認なしに、ソース、シークレット、顧客データ、またはプライベートトポロジーを外部監査サービスにアップロードすること。
• 確認した証拠を挙げずにスコアを生成すること。
• グリーンCIをプロダクション readiness として扱うこと。
• 「何をしたいか教えてください」という一般的な返答で終わること。

関連項目

• スキル：security-review
• スキル：deployment-patterns
• スキル：e2e-testing
• スキル：tdd-workflow
• スキル：verification-loop