AIで本番公開後のWebアプリ不具合確認手順を作る方法

本番公開後に不具合が疑われたら、まず公開URLで再現するかを確認し、影響する利用者・画面・操作を記録します。その後、直近の変更、実行時ログ、主要な操作経路、外部サービスの順に切り分けます。Buildが成功した事実だけでは、本番の環境設定・権限・データ・外部連携まで正常とは判断できません。原因が分からないまま設定やデータを変更せず、影響が広い場合は組織の障害対応手順へ移してください。

最初にするのは修正ではなく、症状と影響範囲の固定です。「動かない」だけでは原因を追えません。どのURLで、どの利用者が、どの入力から、どの結果になったかを、再現時刻とともに記録します。ログや画面共有に認証情報・個人情報を含めないようにし、必要な証拠を安全な範囲で残してください。

公開後トリアージ表

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

観測した症状	まず確かめること	次の確認先
ページが開かない	URL、端末、対象利用者、発生範囲	DNS・配信状態・Route
画面は開くが操作できない	再現手順、入力、画面上の状態	Browser console・Network
APIがエラーを返す	Request時刻、対象route、応答status	Runtime log・APIの依存先
一部の利用者だけ失敗	Role、権限、アカウント条件	Access rule・権限設定
Previewでは正常、本番だけ失敗	環境、Domain、データ、権限の差	Deployment・環境設定・外部連携
広い範囲で影響する	影響routeと重要操作	Incident担当・復旧手順
表示は成功だが結果が誤っている	保存・更新の実結果、対象データ	API応答・データ状態・監査記録

この表は原因を断定する診断表ではありません。最初の観測から次に調べる範囲を絞るためのものです。HTTP 200でも画面が空、古いデータ、権限を無視した結果などがあり得るため、status codeだけで正常と決めず、利用者が目的の操作を完了できたか確認します。

公開直後のSmoke Testを作る

公開後の確認は、すべての画面を一度に深く試すのではなく、利用者が目的を達成する主要経路から始めます。たとえば公開ページなら、Homeから対象機能へ進む経路、認証がある場合は許可された利用者のログイン、入力・保存・結果表示などの重要操作を短いチェックリストにします。アプリごとに必要経路は違うので、例をそのままコピーせず、対象サービスのCore Jobへ合わせてください。

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

確認対象	記録すること	正常と判断する条件
公開先	開いたURL、表示されるrelease識別子	予定した公開先と版が一致
主要Route	代表URL、画面タイトル、読み込み結果	対象利用者が意図した画面を開ける
Core Flow	開始状態、入力、結果、終了状態	利用者が操作を完了し結果を確認できる
API / 保存	Requestと応答、保存前後の状態	成功応答だけでなく結果も一致
権限	利用Roleと許可・拒否の両方	許可対象は使え、対象外は保護される
Assets	CSS、JavaScript、画像等の読込	主要画面の表示・操作を壊す失敗がない
外部依存	利用した連携先と結果	timeoutや認証失敗時の扱いが分かる

テストデータは本番利用者の記録を不用意に作成・変更しない方法を選びます。送信、課金、メール通知、外部連携など不可逆な操作は、テストモードや承認済みの検証用データがあるかを先に確認してください。確認できない場合は本番操作を行わず、担当者へエスカレーションします。

再現手順を短く残す

障害を見つけた人が別の担当者へ渡せるよう、次の形式で記録します。

• 発生時刻とタイムゾーン：

• 公開URL / Route：

• 公開releaseまたはcommit識別子：

• 利用者Role（個人情報は除く）：

• 再現前の状態：

• 実施した操作：

• 期待した結果：

• 実際の結果：

• 再現頻度・影響する範囲：

• Browser console / Networkの安全な要約：

• 関連するRuntime logのRequest IDなど：

• 直近の変更、設定または連携差分：

• まだ確認していないこと：

ログは全文を無制限に共有せず、必要な範囲を選びます。Token、Cookie、個人情報、申込内容などが含まれていないか確認し、報告用に値をマスクしてください。ログに秘密値が出ていたら、そのログを別の共有場所へ転載せず、組織の情報管理手順に従って扱います。

切り分けは公開版と操作経路から始める

まず、想定したreleaseが公開されているか識別します。表示中の版や配信先が想定と異なる場合、ブラウザのキャッシュだけでなく、公開先、配信設定、反映状況を確認します。版が正しければ、問題のRouteを新しいセッションでも再現し、同じ入力・同じRoleで操作します。再現条件を変える場合は、一度に一つだけ変え、何を変えたか記録します。

ページ表示だけを見て、完了まで確認しないのもよくある見落としです。ボタンが反応したかだけでなく、Requestが送られたか、応答が何だったか、保存や次画面まで反映されたかを順に追います。Network上にRequestがないなら、入力Validation、JavaScript実行、Event handlerなど画面側を調べます。Requestがあるなら、応答内容、権限、Server側の処理、下流サービスを分けて見ます。実装環境で参照できる項目は異なるため、取得できないログを存在する前提にしないでください。

Runtime logを使う場合は、再現時刻・Route・Request ID等で対象を絞り、Previewと本番の記録を取り違えないようEnvironmentを確認します。Build logはビルド中に起きたこと、Runtime logは公開後の処理で起きたことを調べる材料です。どちらにも答えが出るとは限らず、記録されていない情報はBrowser Network、アプリの状態、サービス提供元の状態など別の根拠で確認します。Vercelを使うプロジェクトでは、公式のRuntime Logsやrollback手順が確認先の例になりますが、他のHosting環境へその画面やコマンドを当てはめません。

Previewでは正常で、本番だけ失敗する場合

同じ操作をPreviewと本番で実行し、違いを一つずつ比較します。確認候補は、公開Domain、環境変数の有無（値を表示・転載しない）、権限、参照データ、Callback URL、外部APIの許可設定、Cache、Routingです。環境変数を比べるときに値そのものをログやチャットへ貼らず、設定の存在・対象Environment・更新時期だけを確認してください。

差分が見つかったら、修正前の値や状態、変更権限、影響対象、戻し方を確認します。Production設定は、影響範囲と復旧方法を担当者が確認した後に変更します。AIへログを要約させる場合も、秘密情報を除いた必要な断片だけを使い、推測した原因を確定Factとして扱わないでください。

影響の大きさで対応経路を分ける

単一の装飾崩れと、ログイン・個人情報・保存・決済・通知が止まる問題を同じ順番で扱いません。重大度を数値で決める共通基準があるなら組織の基準を使います。基準がない場合に架空のSLAや「何分以内なら軽微」といった境界を作らず、影響する利用者、重要操作、データの正確性・機密性、拡大中かどうかを記録して、担当者が優先度を決めます。

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

条件	進め方
影響が限定され、データ・権限に関わらない	再現条件を残し、担当者へ修正候補を渡す
主要操作が止まる、対象が広がっている	Incident手順に移し、関係者と復旧手段を確認
情報漏えい、権限逸脱、誤ったデータ更新の可能性	追加テストやログ共有を止め、Security / Data担当へ連絡
原因・影響・戻し方が不明	本番で試行錯誤せず、読み取り中心に調査してエスカレーション

Rollbackは常に安全な一手とは限りません。データ変更、外部連携、環境設定など、前の版へ戻しても元に戻らない要素があります。Rollbackの条件、権限、影響、データ互換性を確認し、組織のIncident手順に従って責任者が判断します。復旧と原因調査は役割を分け、証拠を保ちながら利用者への影響を抑えます。

架空例：ログイン後の一覧が空になる

公開後に「ログインはできるが、一覧が空」と報告された架空例を考えます。最初に対象のURL、利用Role、発生時刻、使用した検証アカウント、直前に行った操作を記録します。別の権限で見えるか確認する場合は、許可されたテストアカウントを使い、他人のデータを見ようとしません。

次に、正しいreleaseか、一覧のAPI Requestが送信されたか、Responseが空なのかErrorなのかを確認します。Request自体がなければ画面側の処理、Responseが403ならRoleやAccess rule、成功応答なのに空ならQuery条件や参照データの範囲が候補になります。ここでは原因を確定せず、各仮説を別々に検証します。Productionのデータを直接追加・削除して再現する前に、安全なテスト環境で同じ条件を作れるか担当者へ確認します。

もし複数利用者の一覧が空で、保存処理やデータの誤表示も疑われるなら、個人の画面更新だけで終わらせず、影響対象とデータ範囲を確認してIncident対応へ移します。UIを直しても保存済みデータが壊れている可能性は別に調べます。再現できなかった場合は「解消」とせず、再現条件が不足している状態として記録します。

修正後の再検証

修正を公開した後は、失敗した操作だけでなく、同じ権限・同じ入力・同じRouteでCore Flowを最初から再実行します。成功した表示、Network応答、保存結果、関連する権限の拒否動作を確認し、修正前の症状が消えたことを記録します。変更の影響を受ける関連Routeも、必要な範囲で確認します。

修正前後で公開版を識別し、使った入力と確認結果を残します。もし再発したら、新しい証拠として時刻とRequest IDを記録し、前回と同じ原因だと決めつけません。問題が見えなくなったことと、原因を解消したことも別の判断です。Monitor期間や終了条件は組織・サービスの手順を使い、一般記事が期間を決めつけないようにします。

本番調査では、再現条件、影響範囲、公開版、画面から応答までの結果、Runtime log、復旧判断、修正後の再テストを一つの記録へ結び付けます。障害が拡大中、情報漏えい、権限逸脱、データ破損の疑いがあるときは、調査表を埋め終えることより組織の緊急対応手順を優先します。利用者への通知、サービス停止、切り戻しなどは権限を持つ担当者が決めてください。

Next Action

本番公開前に、主要Route、Core Flow、担当者、見に行くログ、緊急連絡先、Rollbackの権限と条件を一枚のRunbookへまとめます。公開後に不具合が起きたら、まず実Production URLの安全なSmoke Testと影響範囲を確認し、同じ条件で再現できる情報を残してください。次に画面、Request、Runtime log、外部依存を順に調べ、根拠が揃わない原因や不可逆な本番操作は責任者へ引き継ぎます。

AIものさしの判断

公開後の不具合対応は「ログにエラーがあるか」だけでは終わりません。利用者が必要な操作を完了できたか、データや権限に影響したか、どの公開版で起きたかを合わせて見ます。AIは報告の整理、ログの安全な要約、原因候補の比較を助けますが、推測をFactにせず、Rollback・Production設定変更・利用者連絡を自動で決めさせないでください。具体的な証拠と人が承認した復旧手順を結びつけることが、次の判断につながります。