プロダクションレディネス (MVP → 本番) は何をしますか？

目標: エビデンスに基づいて、プロダクトが実際のユーザーにとって準備ができているかどうか、何がリリースを妨げているか、そしてギャップを埋めるための最小限の作業セットをオーナーに伝えること。プロダクトに適したサイズにカスタマイズされます。決して汎用的な200項目のウィッシュリストではありません。

ハードルール

エビデンスがないか、未知。 すべての項目は PASS / GAP / N/A / UNKNOWN であり、PASSには証拠（ファイルパス、設定、CI実行、ダッシュボード、ドキュメントリンク）が必要です。READMEの主張からPASSとマークしないでください。
ティアに合わせて適正化。 50ユーザーのベータ版にマルチリージョンDRを要求しないでください。各ギャップには、それが要求されるティアをタグ付けしてください。
プラットフォームルールを実際に確認。 アプリストア、OAuth、決済、メール送信者のルールは毎年変わります。ストア/ベンダーの要件を引用する前に、ベンダーの公式ドキュメント（ウェブ検索）を確認し、リンクと確認日を引用してください。
再利用、重複禁止。 pm-ai-shipping:ship-check、security-audit-static、performance-audit-static、derive-tests が利用可能な場合は、コードレベルのエビデンスを取得するためにそれらを実行し、結果を組み込んでください。このスキルはコード周りのすべてを担当します。
プレーンな出力。 オーナーは1ページのスコアカードを読みます。詳細は付録とバックログに記述します。
ワークフロー内でのガバナンス、最後にやらない。 作業が行われる場所（CI、PRテンプレート、pre-commit、プロダクト内のガードレール）で実行されるチェックを、リリース前に実施するレビューミーティングよりも優先します。最後にしか実行しないゲートはボトルネックになります。
リリース ≠ 採用。 ほとんどのプロダクトは、コードの失敗ではなく、人とプロセスが変わらなかったためにリリース後に失速します。準備には、システムだけでなく、導入計画（ドメイン13）も含まれます。

準備ティア

ティア	意味	典型的な基準
T1 パブリックベータ	実ユーザー、低スケール、ある程度のダウンタイムを許容	シークレット漏洩なし、認証堅牢、バックアップ復元可能、エラートラッキング、法的ページ、ロールバック動作
T2 GA	有料ユーザー、SLA期待	+ SLO/アラート/オンコール、ロードテスト、ランブック、サポートパス、統合フォールバック
T3 エンタープライズ/規制対象	B2B契約、PHI/PCI/子供、監査	+ SSO/SCIM、監査ログ、DPA/BAA、ペネトレーションテスト、SOC 2 / HIPAAコントロール、DR訓練

ワークフロー

ステップ 0 — プロダクトのプロファイル (一度質問し、質問をまとめる)

以下を取得: ターゲットティアとリリース日; 1つの成功指標とその目標 (このリリースを成功とするもの、測定方法、期限); 指名されたオーナーと署名権限のあるステークホルダー (プロダクト、エンジニアリング、セキュリティ、法務/プライバシー、サポート、マーケティング — 個人データ、AI出力、規制対象ユーザーが関与する場合は初日から法務/プライバシーにフラグを立てる); サーフェス (ウェブ、iOS、Android、デスクトップ、公開API、CLI、ブラウザ拡張機能、開発者ツール/プラグイン/ライブラリで他の開発者に配布); ホスティング/スタック; データタイプ (PII、PHI、決済、未成年のデータ); ユーザー (B2C/B2B)、地域 (米国/EU/その他); AI/LLM機能; 決済; すべての外部統合 (利用するAPI、受信するWebhook、公開するマーケットプレイス/アプリストア、SSO/IdP)。まずリポジトリをスキャン (パッケージマニフェスト、envテンプレート、SDKインポート) して統合リストを事前入力し、オーナーに確認/ギャップの埋め合わせのみを依頼します。

プロファイルによって、どのモジュールを適用するかが選択されます。レポートの先頭に記録します。

ステップ 1 — エビデンスの収集

リポジトリ (コード、CI設定、IaC、envテンプレート、マイグレーション)、利用可能な場合はホスティングダッシュボード/コネクタ (Vercel、Railway、Supabase、Render など)、課題トラッカー、既存のドキュメント。利用可能な監査スキルを実行します。検査できなかったものは UNKNOWN とマークします。

ステップ 2 — コアドメイン (常に) + 該当モジュールを評価

各項目をスコアリングします。重大度: BLOCKER (ターゲットティアでリリース不可) / HIGH (最初の2週間以内に修正) / LATER。

ステップ 3 — 成果物

スコアカード (1ページ): Go / Go-with-conditions / No-go。ブロッカーの数。ドメイン別RAGテーブル。上位5つのリスクを平易な英語で。
ギャップバックログ: ギャップごとに1チケット — タイトル、なぜ重要なのか、受け入れ基準、クローズに必要なエビデンス、ティア、重大度、概算サイズ (S/M/L)。Linear/Jira/GitHub Issues が接続されている場合は、プロジェクト/マイルストーンとして作成するオプションを提供し、そうでない場合はテーブルを生成します。
ハードニングキット (オンデマンド): リポジトリ固有のCI品質ゲート、エージェントルールファイル (CLAUDE.md/.cursorrules)、.env.example、ランブックのスケルトンを生成します。テンプレートダンプではなく、リポジトリが実際に使用しているものから構築します。
再実行モード: その後の実行では、前回のレポートとの差分を表示し、変更があったもののみを表示します。

コアドメイン (常に評価)

1. シークレットと設定 — コードやgit履歴にシークレットがない (gitleaks/trufflehog で全履歴をスキャン)。.env が無視され、.env.example が存在する。本番シークレットはプラットフォームのシークレットストアに格納。開発/ステージング/本番用に別々のキー。ローテーション計画とローテーションできる人。シークレット漏洩時の対応手順。

2. IDとアクセス — 実績のある認証プロバイダーまたは高評価のライブラリ (自作の暗号化は不可)。すべてのデータルートでサーバーサイドの認可 (IDOR / テナントフィルターの欠落 / 緩すぎるRLS をチェック)。セッション/トークンの有効期間と失効。ログイン、サインアップ、パスワードリセット、OTP に対するレート制限。管理者向け MFA。最小権限のサービスアカウント。管理者アクションのログ記録。

3. エッジとアプリケーションセキュリティ — HTTPS + HSTS。セキュリティヘッダー (CSP、frame-ancestors など)。タイトなCORS。バウンダリでの入力検証。ファイルアップロードの制限/タイプチェック。URLフェッチャーに対するSSRFガード。T2+ でのWAF/ボット対策。依存関係スキャン + ロックファイル。CI内のSAST。T3 でのSBOMとライセンスチェック。

4. データ — 自動バックアップ およびテスト済みの復元 (実際の復元時間を記録)。DBでサポートされている場合はポイントインタイムリカバリ。後方互換性のあるマイグレーション (拡張 → マイグレート → 縮小)。ステージングでは生のPIIを使用しない。保持期間 + 削除パス (ユーザーアカウントの削除で、DB、ストレージ、ログ、ベンダー全体から実際に削除されること)。保存時/転送時の暗号化がデフォルトで確認されていること。

5. 信頼性 — すべてのアウトバウンド呼び出しにタイムアウト。べき等な操作にのみ、バックオフ+ジッター付きのリトライ。決済/Webhook/ジョブに対するべき等キー。耐久性のあるキュー上のバックグラウンド処理。依存関係ダウン時のグレースフルデグラデーション。T2+ で定義されたSLO (可用性、レイテンシ)。T2+ で予想ピークの3倍のキャパシティ/ロードテスト。

6. 可観測性 — リリースタグ付きのエラートラッキング (例: Sentry)。リクエスト/トレースIDと PII編集 付きの構造化ログ。エンドポイントごとの主要メトリクス (レート、エラー、期間)。外部からのアップタイムチェック。実際に確認する人間にルーティングされる症状ベースのアラート。リリース日に向けたダッシュボード。

7. CI/CD とリリース — main ブランチでの必須チェック (lint、型チェック、テスト、シークレットスキャン、依存関係監査)。プレビュー/ステージング環境。ワンクリックロールバックが実際に動作することを確認。リスクの高い機能に対するフィーチャーフラグ。デプロイ時にマイグレーションが安全に実行されること。リリースノート/チェンジログ。ブランチ保護。

8. テスト — カバレッジ率よりも、重要なパス (認証、決済、データ書き込み、権限) のテスト。実際のDBに対する統合テスト。デプロイ後に実行される主要ユーザージャーニーのE2Eスモークテスト。外部APIに対するコントラクトテストまたは記録されたフィクスチャ。

9. パフォーマンスとコスト — Core Web Vitals / アプリ起動予算。N+1問題とインデックス欠落のチェック。キャッシュ/CDN。ベンダーごとの支出アラートとハードキャップ (クラウド、LLM、SMS、メール)。アクティブユーザーあたりのコスト見積もり。請求額を増大させる可能性のある悪用シナリオ (サインアップスパム、LLMプロンプトループ、SMSパンピング)。

10. 運用とサポート — たとえ一人であっても、オーナー/オンコールを指名。インシデントプロセス (重大度、コミュニケーション、ポストモーテム)。上位5つの障害モードに対するランブック。T2+ でのステータスページ。サポートチャネルとSLA。一般的なサポートタスク用の管理ツール (生SQLを必要としないように)。

11. 法務と信頼 — 実際のデータフローに一致する利用規約、プライバシーポリシー。必要な場合 (EU/UK) のCookie同意。個人データを処理するベンダーとのDPA。T3 でのサブプロセッサリスト。アクセシビリティ目標 (WCAG 2.2 AA) と基本的な監査。オープンソースライセンスのコンプライアンス。プロダクト名の商標/名前のクリアランス。

12. プロダクト準備 — (同意を得た) アクティベーションファネル上の分析。オンボーディングと空の状態。トランザクションメールの配信 (Webモジュールを参照)。ヘルプドキュメント/FAQ。有料の場合は価格設定/請求が公開。フィードバックループ。問題のある機能のキルスイッチ。

13. 導入と運用モデル — リリース前に書き留められた成功指標とパイロット終了基準 (何がパイロットから「スケール」または「中止」に移行させるか)。リスクティアごとに指名された承認者がいる文書化されたリリースワークフロー (低リスク変更 = 1人のレビューア、高リスク = それ以上) と、承認が停滞しないための合意されたターンアラウンドタイム。リリースコミュニケーション (何が変わるか、変わらないか、既知の制限事項)。最初のユーザー/チャンピオングループと、彼らからのフィードバックを得る方法。プロダクト内のヘルプ、テンプレート、または例 (ユーザーがツール内で学習できるように)。レビュー頻度 (例: 30/60/90日、その後四半期ごと) のフィードバックループ (ユーザーフィードバック + 使用状況メトリクス)。使用量が増加するにつれて継続的なサポートを担当するオーナー。

条件付きモジュール

M1. 利用する統合 (ベンダーごとに1シート) — 本番アカウント/キー (サンドボックスではない) とアカウントの所有者。レート制限とクォータ vs 予想ピーク。価格の上限とアラート。認証タイプとトークンリフレッシュ。Webhook署名検証、リプレイプロテクション、べき等ハンドラー、リトライ/バックオフ、デッドレター。APIバージョンの固定 + 非推奨の監視 (チェンジログに登録)。タイムアウト + サーキットブレーカー + ユーザーに見えるフォールバック。ベンダーステータスページに登録。利用規約があなたの使用 (再販、AIトレーニング、スクレイピング) を許可していること。終了計画 — データ/プロンプト/設定を所有してエクスポート可能であり、契約に解除条項なしの複数年のロックインがないこと。データレジデンシー/DPA。OAuthアプリの確認/レビュー要件 (例: Googleの機密/制限付きスコープ、Microsoftパブリッシャー確認、Slack/Zoomアプリレビュー) — 現在のルールを実際に確認。

M2. 公開するAPI — OpenAPI/仕様が公開されている。バージョニングと非推奨ポリシー。スコープ、ローテーション、失効機能付きのAPIキー/OAuth。キーごとのレート制限とクォータ。ページネーション、POSTに対するべき等キー。一貫したエラーフォーマット。サンドボックス環境。送信するWebhookは署名され、リトライされ、リプレイ可能であること。開発者向けドキュメント + チェンジログ。課金されている場合は使用量測定。

M3. モバイルとアプリストア — 引用する前に、それぞれを現在の公式ドキュメントと照らし合わせて確認:

Apple: App Reviewガイドライン。プライバシー栄養ラベルが実際の収集と一致していること。サードパーティSDKを含むプライバシーマニフェスト。アカウント作成が可能な場合のアプリ内アカウント削除。サードパーティログインを提供する場合の「Appleでサインイン」ルール。デジタルグッズに対するIAPルール。TestFlight外部テスト。書き出しコンプライアンス。
Google Play: 現在のターゲットAPIレベルの期限。データセキュリティフォーム。新しい個人開発者アカウントに対するクローズドテスト要件。Playアプリ署名とアップロードキーの管理。アカウント削除用のWebリンク。
両方: クラッシュレポート。破壊的なAPI変更に対する強制/ソフトアップデートメカニズム。ディープ/ユニバーサルリンク。会社アカウントが所有するプッシュ資格情報。ストア掲載アセット、年齢レーティング、サポートURL、プライバシーURL。リリース計画におけるレビュー拒否バッファ (時間単位ではなく日単位で計画)。

M4. Webとメール — カスタムドメイン、会社アカウントが所有するDNS、レジストラロック + 自動更新。検索性が重要な場合のSEO基本 (タイトル、サイトマップ、robots、OGタグ)。404/500ページ。メール送信者認証 SPF、DKIM、DMARC、および一括メールのワンクリック購読解除 (現在のGmail/Yahoo送信者ルールを確認)。バウンス/苦情処理。トランザクションメールとマーケティングメールの分離。

M5. AI / LLM機能 — フォールバックモデル付きのプロバイダー抽象化またはゲートウェイ。429/5xx に対するタイムアウトとリトライ。スキーマ (Zod/Pydantic) で検証された構造化出力。プロンプト/モデル変更前にCIで実行される実際のケースの評価セット。モデルが信頼できないコンテンツを読み取るか、ツールを呼び出すことができる場合のプロンプトインジェクション防御 (最小権限ツール、破壊的なアクションには人間の確認)。ユーザーごとおよびグローバルなコストキャップ。PII処理とプロバイダーデータ保持設定。追跡されたモデル非推奨日。必要な場合のユーザーへのAI開示。生成された出力に対するブランド/品質ガードレール (禁止用語、トーンチェック、リスクに応じた段階的な人間によるレビュー)。UIはユーザーに制限事項を伝える (「事実を確認」、主張に対して出典を表示)。プロンプト/モデルの変更は、最初にサンドボックスで過去のデータまたはサンプルデータを使用してテストされ、その後すべてのトラフィックに展開する前に、トラフィックのごく一部にロールアウトされる。スケジュールされた (例: 半年ごとの) モデル/ベンダーレビュー。

M6. 決済 — PCIスコープを最小化するためのホステッドチェックアウト。Webhook駆動の状態 (クライアントリダイレクトを信頼しない)。べき等なフルフィルメント。返金、異議申し立て、督促。地域ごとの税金徴収。テストクロック/サンドボックスがカバーされていること。収益照合。

M7. 規制対象データ — PHI → HIPAA: PHIに触れるすべてのベンダーとのBAA、アクセスログ、必要最小限。ホステッドチェックアウトを超えるPCI → SAQスコープ。子供 → COPPA/年齢制限。EU/UKユーザー → GDPRの法的根拠、DSARプロセス、移転。カリフォルニア州 → CCPA/CPRA。法務レビューのためにフラグを立てる。法的結論は下さない。

M8. B2B / エンタープライズ — テスト済みのテナント分離 (クロステナントアクセステスト)。T3 でのSSO (SAML/OIDC) とSCIM。監査ログのエクスポート。ロール/権限モデル。データエクスポート。セキュリティ質問票パック (アーキテクチャ、サブプロセッサ、ペネトレーションテスト、ポリシー)。アップタイムSLAとクレジット。

M9. 公開するマーケットプレイス — Chromeウェブストア、Slack/Teams/Zoomアプリディレクトリ、Shopify、MCP/プラグインレジストリなど: 掲載要件、レビューのタイムライン、権限の正当性、プライバシー開示 — 実際に確認。

M10. 開発ツール、ライブラリ、プラグイン、オープンソース — ライセンスが意図的に選択されている (AGPLのようなコピーレフトは企業による採用を妨げる可能性があります。MIT/Apacheのような寛容なライセンスはより速く広まります)。NOTICE/サードパーティライセンスが正しい。プライベートな報告チャネルを持つ SECURITY.md。セマンティックバージョニング、CHANGELOG、および保存されたデータまたは設定形式に対するテスト済みのアップグレード/移行パス。CIで実際にテストされたサポート対象プラットフォームマトリックス (OS × ランタイムバージョン × サポートする各クライアント/IDE)。文書化されたすべてのパスに対して、クリーンなマシンからインストールが確認されていること。各レジストリ (PyPI、npm、プラグインマーケットプレイス) で予約されたパッケージ名。署名付きリリース / ビルドの証明。テレメトリーはオフまたはオプトインであり、文書化されていること。CONTRIBUTING、行動規範、課題/PRテンプレート。ユーザーが誤用しないようにするための「これが何でないか」セクション。

スコアカードテンプレート

PRODUCT: <名前>   TARGET: T1/T2/T3   LAUNCH: <日付>   VERDICT: GO | GO-WITH-CONDITIONS | NO-GO
Blockers: N   High: N   Unknown:

---
| Domain | RAG | Blocker count |
|--------|-----|---------------|
| Secrets & config      | 🟢 🟡 🔴 | N |
| Identity & access     | 🟢 🟡 🔴 | N |
| Edge & app security   | 🟢 🟡 🔴 | N |
| Data                  | 🟢 🟡 🔴 | N |
| Reliability           | 🟢 🟡 🔴 | N |
| Observability         | 🟢 🟡 🔴 | N |
| CI/CD & release       | 🟢 🟡 🔴 | N |
| Testing               | 🟢 🟡 🔴 | N |
| Performance & cost    | 🟢 🟡 🔴 | N |
| Operations & support  | 🟢 🟡 🔴 | N |
| Legal & trust         | 🟢 🟡 🔴 | N |
| Product readiness     | 🟢 🟡 🔴 | N |
| Adoption & ops model  | 🟢 🟡 🔴 | N |

---
### Top 5 Risks
1. ...
2. ...
3. ...
4. ...
5. ...

### Go/No-Go Conditions
- ...

### Appendix / Evidence links
- ...

### Generated hardening kit (if requested)
- ...

プロダクションレディネス (MVP → 本番)