AIで公開前のWebアプリチェックリストを作る方法

Webアプリは、buildが通っただけでは「公開してよい状態」になりません。公開前に見るべきなのは、主要なUser Flow、権限境界、環境変数、外部API、エラー時の挙動、監視、そして問題が起きたときに戻せるかです。AIはチェック項目の漏れを洗い出す補助に使えますが、合否は実際のPreview環境や本番相当環境で確認します。

この記事のゴールは、一般的なチェック項目を眺めることではありません。自分のWebアプリについて「何を、どの環境で、どう確認し、何ができればPASSか」を具体化し、担当者・結果・Evidenceまで残せる公開判定表を作ることです。

先に結論：チェックリストは「項目」ではなくPASS条件まで書く

「ログインを確認」「フォームを確認」だけでは、誰が実施しても同じ判定になりません。各項目をTest、Expected、Evidence、Ownerの4つに分けます。

表は横にスクロールできます

Check	Test	Expected	Evidence
Login	正常ユーザーでログイン	Dashboardへ遷移	Preview URL / 結果記録
Unauthorized	未ログインで保護URLへ直接アクセス	Loginへ誘導または403	応答・画面記録
Form	正常値を送信	1件だけ保存・通知	DB / log / 通知確認
Invalid input	必須値を空で送信	保存せずError表示	UI・status確認
External API	正常Requestと失敗Case	成功時と失敗時を分けて扱う	Runtime log
Rollback	戻し手順を確認	担当者が復旧手順を実行可能	手順書・対象deployment

AIにチェックリストを作らせる場合も、「認証がある」「決済はない」「問い合わせformがある」「外部APIを2つ使う」のように機能を渡し、この表の形へ落とします。

最初にCore Flowを3〜5本へ絞る

全ページを同じ深さで確認する必要はありません。公開時に壊れると読者・顧客への影響が大きいFlowから優先します。たとえば会員制Webアプリなら、登録→ログイン→主要操作→保存→再表示がCore Flowです。問い合わせサイトなら、ページ閲覧→入力→送信→管理側受信がCore Flowになります。

Core Flowごとに「開始状態」「操作」「完了状態」を書きます。途中の画面が表示できることより、ユーザーが目的を最後まで完了できるかを確認してください。

例：

開始：未ログイン

→ 新規登録

→ メール確認

→ ログイン

→ Profile入力

→ 保存

→ 再読み込み

完了条件：保存内容が保持され、別ユーザーから見えない

この一連を通せば、Routing・認証・DB保存・Session・表示まで横断できます。単独ページの見た目確認だけでは見つからない不具合を拾いやすくなります。

Preview環境で「Localでは通った」を捨てる

Localで成功しても、PreviewやProduction相当環境では環境変数、Domain、Cookie、CORS、外部Webhook、Database接続先などが変わります。公開前QAでは、実際に配置されたURLを起点に確認します。

VercelなどDeployment単位のPreviewを持つPlatformでは、対象deploymentを固定し、そのURLでCore Flowを通します。どのcommit・deploymentを検証したかが分からないと、修正後に古いPreviewを見て「直った」と判断する事故が起きます。

Evidenceには最低限、確認したURLまたはdeployment、確認日時、結果、担当者を残します。Screenshotは有用ですが、APIやDBの成否は画面だけで判断せず、必要に応じてNetwork・Runtime log・保存結果も確認します。

認証・認可は「ログインできるか」より拒否できるかを見る

認証があるアプリでは、成功Caseだけでなく拒否Caseが重要です。未ログイン、権限の低いRole、他人のresource ID、期限切れSessionなどを使い、見えてはいけないデータや操作が本当に拒否されるか確認します。

確認例：

1. 未ログインで保護URLを直接開く。

2. 一般UserでAdmin URLを開く。

3. User Aのresource IDをUser BのSessionで要求する。

4. UI上でButtonが隠れていても、APIを直接呼んだとき拒否されるか確認する。

5. Logout後に戻る操作や古いtabから保護dataへ入れないか確認する。

「ボタンを表示しない」は認可ではありません。重要な操作はServer側でも権限条件を確認し、拒否結果をEvidenceとして残します。

環境変数と外部依存は一覧にする

公開前に、使っている環境変数と外部Serviceを一度表へ出します。Secretの値そのものをチェックリストへ書く必要はありません。必要なのは「変数名が存在するか」「対象環境の値か」「誰が管理するか」「失敗したとき何が起こるか」です。

表は横にスクロールできます

Dependency	確認すること	Failure時
Database	接続先・migration・権限	読み書き失敗を検知できる
Email	From、送信Domain、送信結果	Userへ再試行/案内
Storage	Bucket・公開範囲・容量	Upload失敗を表示
Payment	Test/Live環境、Webhook	二重処理を防ぐ
AI/API	Key、Model/Endpoint、Rate limit	Timeout/429を扱う
Analytics	Measurement ID、event	欠落してもCore Flowを壊さない

AIへ一覧化を頼むなら、repo内のenv参照箇所や構成ファイルから「利用している変数名と用途」を抽出させ、実際のSecret値は出力させない方が安全です。

失敗Caseを最低1つずつ作る

公開前QAが正常系だけだと、Productionで最初の外部API障害や入力ミスが起きた瞬間に挙動が分かりません。重要なFlowごとに、少なくとも一つはFailure Caseを作ります。

代表例：

• 必須入力を空にする

• 不正なIDを指定する

• APIがtimeoutした想定にする

• 取得結果0件を返す

• Networkが切れた状態で再送する

• Upload上限を超えるfileを渡す

• 同じ送信を2回行う

ここで見るのは、きれいなError Messageが出るかだけではありません。二重保存されないか、途中dataが壊れないか、再試行してよいか、運用側がlogから原因を追えるかまで確認します。

データ変更があるFlowはBefore / Afterを確認する

Form送信、Profile更新、注文作成などdataを変える操作では、UIの完了表示だけでは不足です。処理前と処理後で、対象recordが何件増えたか、更新すべきfieldだけが変わったか、同じ操作を再送して重複しないかを見ます。

特にWebhookや外部APIを含むFlowは、Browser側でtimeoutしてもServerや外部Serviceでは処理済みのことがあります。再送時に二重作成が起こらない設計か、IDやStateで追えるかを公開条件に入れておくと、障害時の復旧が楽になります。

AIに公開前チェックリストを作らせる依頼例

次のようにApplicationの境界を渡すと、一般論のチェックリストから自分のアプリ用へ寄せられます。

以下のWebアプリの公開前QAチェックリストを作ってください。

Stack：Next.js / Database / 外部Email API

主要機能：

• Email login

• Dashboard

• 問い合わせForm

• 管理者だけ見られる一覧

公開前環境：Preview deployment

各項目を次の列で出してください。

1. Area

2. Test procedure

3. Expected result

4. Evidence

5. Severity if failed

6. Owner

必須Area：

• Core Flow

• Authentication / Authorization

• Data write

• Environment variables

• External API

• Error / Empty state

• Responsive / Browser

• Logs / Monitoring

• Rollback

「確認する」だけで終わらず、具体的な操作とPASS条件を書いてください。

Productionへ変更を加える手順は含めないでください。

AIが出した項目はそのまま採用せず、自分のアプリに存在しない機能を消し、逆に独自の高リスク機能を追加します。

Severityで公開Blockerを分ける

すべての不具合を同じ優先度にすると、公開判断が曖昧になります。少なくともBlocker / High / Medium / Lowのように影響を分けます。

表は横にスクロールできます

Severity	例	公開判断
Blocker	Login不能、他人のdata閲覧、決済誤処理	公開しない
High	Core Flow完了不可、data消失	原則修正後に再QA
Medium	一部BrowserでUI崩れ、代替手段あり	影響を見て判断
Low	軽微な文言・余白	既知Issueとして管理可能

Severityは技術的な大きさではなく、User Impactと復旧難易度で決めます。1行の権限Bugは実装修正が小さくてもBlockerになり得ます。

Rollbackと公開後Smoke Testを公開前に決める

公開前に「問題が出たらどう戻すか」を決めます。直前deploymentへ戻すのか、feature flagを切るのか、DB migrationがある場合はどう扱うのか。戻せない変更が含まれるなら、その時点でQAと承認を厚くする必要があります。

同時に、公開後5〜10分で行うSmoke Testも作っておきます。Home表示、Login、Core Flow 1本、主要API、Error監視など、短時間でProductionの健全性を確認できる項目に絞ります。Local / Previewで成功したこととProductionで成功したことは分けて記録してください。

公開判定に使える最終チェックリスト

最低限、次を埋めれば「何となく大丈夫」ではなく、Evidence付きでGo / No-Goを判断できます。

□ 対象commit / deploymentを固定した

□ Core Flowを開始から完了まで通した

□ 未ログイン・低権限Roleの拒否Caseを確認した

□ data writeのBefore / Afterを確認した

□ 環境変数・Domain・外部依存を確認した

□ API失敗・空データ・無効入力を試した

□ Browser / mobile幅で主要画面を確認した

□ Runtime / Build logで重大Errorがない

□ Analyticsや通知など非Core機能がCore Flowを壊さない

□ Rollback手順と担当者が決まっている

□ 公開後Smoke Testの手順がある

□ Blocker / High Issueが0、または明示的に承認されている

AIものさしの判断

公開前チェックは、項目数を増やすことより「このアプリで壊れると困る境界」を具体化することが重要です。Core Flow、権限、data write、外部依存、Failure、Rollbackを中心に、Test ProcedureとExpected Resultまで書いてください。

低リスクの静的ページ更新なら短いSmoke Testで足りることもあります。一方、認証・決済・個人情報・DB migrationを含む変更は、影響に応じて拒否Case、data検算、復旧手順、担当者承認を厚くします。

実務ではまず、今回公開する変更についてCore Flowを3本以内に絞り、このテンプレートへTest / Expected / Evidence / Ownerを書いてください。その3本がPreviewで通ってから周辺項目を確認すると、チェックリストが形骸化しにくくなります。