Go-Live Checklist
アプリを一般公開する前に、公開してよい状態かを棚卸しするスキル。目的は「公開を止めること」ではなく、公開して何が起きうるかをユーザーが理解した上で判断できる状態にすること。ただし、明らかに危険な状態（秘密情報のコミット、認証のない管理機能など）を見つけたら、修正が終わるまで公開作業には進まない。
チェックの多くはコードと設定を読めば機械的に確認できるが、「このアプリにとって何がリスクか」はプロジェクトごとに違う。手順を上から流すだけでなく、Step 1で判定したリスクレベルに応じて深さを変えること。
Step 1: 公開範囲とリスクレベルを判定する
まずユーザーに次を確認する（コードから分かることは聞かずに済ませる）。
- 誰がアクセスできるようになるか: 社内の数人 / 取引先など限定された外部 / 不特定多数
- どんなデータを扱うか: 個人情報（氏名・メール・住所等）、決済・金融情報、健康情報、他社の機密、ログイン認証情報
- 壊れたり漏れたりしたら何が起きるか: 困る人は誰で、どの程度困るか
この回答でリスクレベルを3段階に判定する。
| レベル | 目安 | 対応 |
|---|
| 低 | 社内限定・センシティブなデータなし | Step 2の全項目を確認して公開してよい |
| 中 | 外部公開だが個人情報は最小限（メールアドレス程度） | Step 2〜3を全て通し、残るリスクを明示した上で公開 |
| 高 | 個人情報を本格的に扱う、決済・健康・機密情報、規制対象の業種 | Step 2〜3を通した上で、公開前に人間の専門家によるレビューを強く推奨する。この推奨を省略しない |
高リスクと判定した場合、「Claudeのチェックだけで公開して問題ない」とは絶対に言わない。自動チェックは事故率を下げるが、認可設計の妥当性や法規制への適合はコードを読むだけでは保証できない——この限界を平易な言葉で伝え、それでも公開するかの判断をユーザーに委ねる。
Step 2: コードと設定の棚卸し
以下を実際にコード・設定・履歴を読んで確認する。ユーザーの申告を鵜呑みにしない。
秘密情報
- ハードコードされたAPIキー・パスワード・トークンがないか（
git grep で api_key, secret, password, token 等のパターンと、sk- のようなキー形式を検索）
.env 系ファイルがGit管理に入っていないか（git ls-files で確認）。過去のコミット履歴に入っていた形跡がないかも確認する（git log --all --diff-filter=A -- '*.env*' 等）。履歴に秘密情報が見つかったら、そのキーは「漏れたもの」として扱い、履歴の掃除より先にキーの無効化・再発行を案内する- 本番の秘密情報がデプロイ先の環境変数など安全な場所で管理される構成になっているか
認証・認可
- 管理機能・データ変更系のエンドポイントが認証なしで叩けないか
- ログインユーザーが他人のデータを見られる作りになっていないか（URLのIDを変えるだけで他人のリソースに届く等、コードの認可チェックの有無を読む）
- デフォルトパスワード・テスト用アカウント・開発用のバックドアが残っていないか
露出面
- デバッグ用エンドポイント・詳細なエラー表示（スタックトレース等）が本番設定で無効になっているか
- CORSが
* のような全開設定になっていないか
- DBや管理画面がインターネットから直接届く構成になっていないか（設定ファイル・IaCから読み取れる範囲で）
- HTTPSが強制されるか（ホスティングサービス任せでよいことも多いが、確認はする）
データと運用
- 個人情報を保存するなら、バックアップの仕組みがあるか、削除依頼に応えられる作りか
- 依存パッケージに既知の脆弱性がないか（
npm audit / pip-audit 等、スタックに応じて実行）
- 壊れたときに前のバージョンへ戻す手段が確認できているか（デプロイ手順・
safe-rollback スキル参照）
Step 3: /security-review を実行する
ビルトインの /security-review スキルで、公開されるブランチの変更に対するセキュリティレビューを行う。Step 2が「設定と構成の棚卸し」なのに対し、こちらはコードの脆弱性（インジェクション、XSS等）を見る層として役割が違うので、どちらか一方で済ませない。
Step 4: 結果を平易な言葉で報告し、判断を仰ぐ
チェック項目ごとに「問題なし / 直してから公開すべき / 公開後でよいが対応推奨」に分類して報告する。技術用語には一言の説明を添える。
- 直してから公開すべき項目が残っている間は、公開作業に進まない。修正してから該当項目だけ再チェックする
- すべて通っても「これで絶対に安全」とは言わない。この監査が見ていないもの（アクセス集中への耐性、GitHubやクラウドのアカウント自体の防御、法規制への適合、運用開始後に生まれる脆弱性）を必ず一言添える
- 高リスク判定の場合は、専門家レビューの推奨を報告の冒頭に置く
- 公開後の運用として最低限「Dependabot等の更新通知を放置しない」「おかしいと思ったら
safe-rollback」の2点を伝える
ユーザーが残リスクを理解した上で「公開する」と判断したら、そこで初めてデプロイ作業に進む。