AIの「直しました」を信用する前に確認する7項目｜小さなWebアプリのチェックリスト
AIにコードの修正を頼むと、作業が終わったときに「修正しました」と報告してくれます。
ただ、その一文だけでは、既存の機能や保存データまで正常だとは判断できません。
前回、小さなWebアプリの安全な複製を使い、AIへの修正依頼とGitによる復旧を試しました。
通常の修正依頼では、別の機能は壊れませんでした。一方、追加実験として保存キーを意図的に変えると、画面にエラーが出ないまま、保存済みの2件が0件に見える状態を再現できました。
しかも、その状態でも新しいデータは保存できました。
新規登録を1回試すだけでは、「問題なく直った」と判断してしまうところでした。
そこで今回は、AIから修正完了の報告を受け取った後に、自分で確認する7項目をまとめます。
対象は、HTML・CSS・JavaScriptで作る小さなWebアプリです。Gitの基本操作を使いますが、難しいコマンドを覚えることより、確認する順番を決めることを目的にしています。
1. 変更されたファイルを確認する
最初に見るのは、AIの説明ではなく、実際に変更されたファイルです。
git status --short
git diff --name-only`git status --short`では、変更・追加されたファイルを確認できます。`git diff --name-only`では、まだステージしていない変更のファイル名を一覧にできます。
たとえば、見出しの修正を頼んだのに、保存処理のJavaScriptまで変わっていたら、理由を確認する必要があります。
ここで確認することは次の3つです。
変更されたファイルは、依頼内容と合っているか
変更を頼んでいないファイルが含まれていないか
新しく作られたファイルや、消えたファイルはないか
想定外のファイルがあっても、その時点で不具合とは限りません。ただし、理由が分からないまま次へ進めないことが大切です。
2. 依頼していない箇所の差分を見る
次に、ファイル名だけでなく、変更された行を確認します。
git diff特定のファイルだけを見る場合は、ファイル名を指定します。
git diff -- index.html script.js style.css前回の実験で依頼したのは、画面の見出しを変えることでした。正常な変更は、index.htmlの1行だけでした。
一方、故障を再現する追加実験では、script.jsの保存キーを変えました。
-const STORAGE_KEY = 'article-ideas-v1';
+const STORAGE_KEY = 'article-ideas-v2';見出しの変更に、保存キーの修正は必要ありません。
差分を見ると、「なぜ保存処理まで変わっているのか」と、画面を操作する前に気づけます。
すべてのコードを理解できなくても、依頼した範囲以外が変わっていないかは確認できます。分からない差分があれば、AIへ次のように聞き返します。
依頼したのは画面の見出し変更です。
script.jsも変更されていますが、この変更が必要な理由を説明してください。
既存の保存データへの影響も確認してください。
追加修正は、説明を確認するまで行わないでください。3. 主要機能を修正前と同じ手順で試す
修正した箇所だけ動かしても、別機能への影響は分かりません。
作業前に、アプリの主要機能と正常な結果を短く書き出しておきます。
記事ネタ管理アプリでは、次の項目を確認しました。
入力欄と一覧が表示される
タイトル・カテゴリ・メモ・ステータスを保存できる
新しいデータが一覧の先頭へ追加される
件数が正しく増える
一覧からステータスを変更できる
再読み込み後も内容が残る
空白だけのタイトルは保存されない
この一覧が、修正後の確認項目になります。
ポイントは、修正前と修正後で同じ操作を試すことです。操作や入力内容が違うと、修正による変化なのか、確認条件の違いなのか判断しにくくなります。
毎回すべてを大規模にテストする必要はありません。小さなアプリなら、壊れると困る操作を数個に絞り、毎回同じ順番で確認するだけでも違います。
4. 画面上のエラーとブラウザのエラーを確認する
エラーには、画面に表示されるものと、ブラウザの開発者向け画面にだけ出るものがあります。
修正後は、少なくとも次を確認します。
エラーメッセージが画面に出ていないか
ボタンを押しても反応しない箇所がないか
表示が消えたり、崩れたりしていないか
ブラウザのコンソールに赤いエラーが出ていないか
ただし、エラーが0件でも正常とは限りません。
前回の故障版では、保存済みデータが2件から0件に見えても、画面にもコンソールにもエラーは出ませんでした。プログラムは「別の保存先にデータがない」という状態を、正常に処理していたためです。
エラーの有無と、表示された結果が正しいかは、別々に確認します。
5. 保存済みデータへの影響を確認する
localStorageやデータベースを使うアプリでは、新規データを登録できるかだけでなく、修正前のデータを読めるか確認します。
確認用には、秘密情報を含まない合成データを使います。
修正前に、次の情報をメモしておきます。
保存件数
タイトル
カテゴリ
メモ
ステータス
修正後は、同じブラウザ・同じURLで開き、件数と内容を照合します。その後、新規登録、ステータス変更、再読み込みも試します。
前回の追加実験では、保存キーを変えると元の2件が見えなくなりました。しかし、新しいキーへの登録は成功しました。
つまり、次の2つは別の確認です。
新しいデータを保存できるか
修正前のデータを引き続き読めるか
この違いを意識すると、「登録できたから保存機能は正常」と早く判断するのを防げます。
6. Gitの場所と現在の状態を確認する
Gitのコマンドは、実行した場所によって対象が変わります。
復旧や差分確認の前に、現在地とGitの管理範囲を確認します。
Get-Location
git rev-parse --show-toplevel
git status --short`Get-Location`は現在のフォルダ、`git rev-parse --show-toplevel`はGitリポジトリの一番上の場所を表示します。
ここで見るのは、次の3点です。
修正対象のプロジェクトを開いているか
別の実験用フォルダと混同していないか
自分やAIが作業中の未コミット変更が残っていないか
未コミット変更がある状態で、内容を確認せずに全体を戻す操作をすると、必要な作業まで失う可能性があります。
前回は元の作業ツリーに別の変更が残っていたため、アプリを実験専用フォルダへ複製し、その中でだけGit復旧を試しました。
7. 元の状態へ戻せるか確認する
修正前に退避していても、実際に戻せるかは別の問題です。
安全な複製で、復旧後に同じ主要機能を確認します。
前回の実験では、正常ファイルをGitのインデックスへ登録した後、変更したファイルだけを次のコマンドで戻しました。
git restore --worktree -- index.html script.js
git diff --exit-code1行目は、指定した2ファイルを退避した状態へ戻す操作です。2行目は、作業ファイルと退避した状態に差分がないか確認します。
実行前には、現在地、戻すファイル、消えて困る差分がないことを確認します。
コードを戻した後は、画面が開くだけで終わらせません。
修正前の保存データが表示される
件数と内容が一致する
新規登録ができる
ステータスを変更できる
再読み込み後も内容が残る
前回は、正常コードへ戻すと元の2件が再表示されました。ただし、故障版の別キーに保存した1件は自動で統合されませんでした。
Gitで戻せるのはコードです。ブラウザ内のデータまで同時に復元できるわけではありません。
7項目を1枚にまとめる
AIから修正完了の報告を受け取ったら、次の順番で確認します。
変更されたファイルを確認する
依頼していない箇所の差分を見る
主要機能を修正前と同じ手順で試す
画面とブラウザのエラーを確認する
保存済みデータへの影響を確認する
Gitの場所と現在の状態を確認する
元の状態へ戻せるか確認する
すべて正常なら「確認済み」と記録します。確認していない環境は、「問題なし」ではなく「未確認」と残します。
コピペして使える確認記録
修正ごとに、次の項目を短く残します。
修正の目的：
依頼した変更範囲：
実際に変更されたファイル：
依頼していない差分：
主要機能の確認結果：
画面上のエラー：
ブラウザコンソールのエラー：
既存データの比較結果：
Gitリポジトリの場所：
修正前の退避方法：
元へ戻した結果：
未確認の環境：
最終判断：適用できる / 追加確認が必要記録を長くする必要はありません。
たとえば、前回の見出し変更なら次のように残せます。
修正の目的：画面の見出し変更
依頼した変更範囲：index.htmlのh1
実際に変更されたファイル：index.html
依頼していない差分：なし
主要機能の確認結果：追加・状態変更・再読み込みが正常
画面上のエラー：なし
ブラウザコンソールのエラー：確認範囲でなし
既存データの比較結果：1件を保持、新規追加後は2件
Gitリポジトリの場所：実験専用フォルダ
修正前の退避方法：実験用Gitのインデックス
元へ戻した結果：正常版と差分なし
未確認の環境：スマートフォン、他ブラウザ
最終判断：今回確認した環境では適用できる「なし」と「未確認」を分けると、後から記録を読み返したときに、どこまで試したかが分かります。
AIへ追加確認を頼むときのプロンプト
想定外の変更や未確認項目が見つかった場合は、すぐ全体を書き換えさせず、調査と説明を先に依頼します。
修正完了の報告を確認したところ、次の点が未確認です。
- 想定外に変更されたファイル：
- 理由が分からない差分：
- 失敗した操作：
- 表示されたエラー：
まず原因と影響範囲を調査してください。
追加で変更が必要な場合は、変更対象と確認方法を先に説明してください。
既存ファイルを全体的に書き換えたり、未コミット変更を削除したりしないでください。具体的なファイル名、操作、エラーを入れると、次の調査対象が明確になります。
今回のチェックリストで扱っていないこと
この7項目は、今回試した小さなWebアプリを基準にしています。
スマートフォン、複数ブラウザ、複数タブの同時編集、データベース、ログイン、決済、外部APIを使うアプリでは確認項目が増えます。
また、バックアップを取る前に削除されたデータを、この手順だけで回収できるわけではありません。公開中のサービスでは、利用者のデータや公開環境への影響も別途考える必要があります。
今回の環境と、保存キーを変えた追加実験、Gitで復旧した手順は、前回の記事に詳しく記録しています。
AIに修正を頼むと別の機能は壊れる？小さなWebアプリの複製で再現・復旧を試した
AIの完了報告は、確認を始める合図として使う。
変更ファイル、差分、主要機能、エラー、保存データ、Gitの状態、復旧。この7項目を順番に見ることで、少なくとも「直しました」の一言だけで作業を終えずに済みます。
開発・修正のご相談
Webアプリの小さな修正について、技術構成・変更範囲・日程を伺ったうえで対応可否を確認します。作業の進め方、制作例、相談先は、自己紹介記事にまとめています。
