AIに修正を頼むと別の機能は壊れる？小さなWebアプリの複製で再現・復旧を試した

AI開発実践ラボ｜会社員エンジニア

2026年9月7日 10:59

前回までに、CodexでX・noteの記事ネタ管理アプリを作り、Gitで管理するところまで進めました。

次に気になったのが、修正を頼んだときの影響です。

「ここだけ変えて」と頼んだのに、保存や一覧表示が動かなくなったら、どう気づき、どう戻せばよいのでしょうか。

今回は、普段のアプリを壊さず、安全な複製を使ってCodexに検証を依頼しました。 操作と確認はCodexが実行し、そのログからこの記事をまとめています。

先に結果を書くと、通常の修正依頼では別機能は壊れませんでした。そのため追加実験として、保存先を示す文字列を意図的に1行変え、「既存のネタが見えなくなる」状態を作りました。

自然発生した事故の記録ではありません。通常依頼の結果と、復旧練習用に作った故障を分けて紹介します。

対象アプリと実験環境

アプリの機能は、タイトル・カテゴリ・メモ・ステータスの入力、一覧表示、一覧からのステータス変更です。データはlocalStorageというブラウザ内の保存領域を使います。

以前の作成先は `outputs/` でしたが、現在の正本はプロジェクト内の `apps/content-idea-manager/` です。古いブラウザURLだけを頼りにせず、Gitの管理対象、README、実際のファイルを照合しました。旧場所のindex.htmlは存在しませんでした。

確認日：2026年9月7日
OS・操作環境：Windows、PowerShell、Codex In-app Browser
実行環境：Node.js v24.19.0、Git 2.45.1.windows.1
AI：Codex。修正担当が確認できるモデル識別子は未取得
アプリ：HTML / CSS / JavaScriptのみ
起動先：実験用の `http://127.0.0.1:4174/`
入力データ：実験用に作った合成データのみ

ローカルサーバーは実験アプリの3ファイルだけを配信しました。本体の保存データには触れていません。

修正前に「正常」を決める

最初に、次を確認しました。

入力欄と一覧が表示される。
タイトル、カテゴリ、改行を含むメモ、状態を保存できる。
新しいネタが先頭に入り、件数が増える。
一覧から状態を変えられる。
再読み込み後も内容と状態が残る。
空白だけのタイトルを拒否する。
保存失敗や不正データを正常扱いしない。

ブラウザで通常の入力・状態変更・再読み込みを確認しました。全5カテゴリと4ステータスの20組、保存失敗、破損JSONなどは、Node.jsでDOMと保存領域を模擬する検査を使いました。実ブラウザの保存容量を使い切ったわけではありません。

正常版の模擬テストは9項目すべて成功しました。編集・削除・エクスポートは最初から未実装です。

AIに入力した最初のプロンプト

変更内容は、見出しの名前だけにしました。実際に送った指示の全文です。長いパスは今回の実験フォルダを指定するためのものです。

安全な複製への実際の修正依頼です。作業可能範囲は C:/Users/shota/Projects/ai-sidebusiness-lab/experiments/codex/002-webapp-regression-recovery/lab のみです。リポジトリのAGENTS.mdを守り、本体 apps/ や他のファイルを編集しないでください。commit・push・公開・サブエージェントは禁止です。依頼本文：『記事ネタ帳の見出しを「発信ネタ帳」に変更してください。』既存HTML/CSS/JS構成を維持し、必要な最小変更を実行してください。開始・終了時刻、変更ファイル、変更内容、実行した確認、完了報告を返してください。モデル識別子が自身で確認できない場合は未取得としてください。ブラウザは親側で確認するので操作しないでください。

この指示は、検証を進めるCodexから別の修正担当へ1回送っています。ユーザーが短い一文だけを新しいチャットへ入力した実験ではありません。共通の安全条件も含めた依頼です。

実際に変わったのは1行だった

修正担当は22秒で完了を報告しました。取得した差分は次の1行でした。

-      <h1>記事ネタ帳<span> / </span></h1>
+      <h1>発信ネタ帳<span> / </span></h1>

変更ファイルはindex.htmlだけ。保存処理のscript.js、見た目のstyle.css、ブラウザのタブ名に使うtitle要素は変わっていません。

追加、状態変更、再読み込みを再確認し、タブを閉じて同じURLを開いても2件が残りました。模擬テストも9項目成功。確認した範囲では、依頼していない変更も、別機能の破損もありませんでした。

追加実験：見出し以外も変わった場合を再現する

ここからは意図的に作った故障です。通常依頼でAIが勝手に入れた変更ではありません。

見出し変更後の複製で、検証担当がscript.jsの1行を変えました。

-const STORAGE_KEY = 'article-ideas-v1';
+const STORAGE_KEY = 'article-ideas-v2';

これは保存領域の中で、どの名前のデータを読み書きするかを決める文字列です。

同じブラウザ、同じURLで再読み込みすると、2件あった一覧が0件になりました。画面にはエラーが出ず、取得したコンソールの警告・エラーも0件でした。

さらに、この状態で新しいネタを1件追加すると保存できました。状態変更と再読み込みでも保持されます。

つまり、新規登録だけ試すと「動いている」と判断してしまう状態でした。

元の保存キーを前提にした模擬テストでは、9項目中5項目が失敗しました。これは検査側のエラーであり、アプリ画面に同じエラーが出たという意味ではありません。

差分から分かったこと

見出しを変えるだけなら、保存キーを変える理由はありません。今回の故障版では、index.htmlに加えscript.jsにも差分がありました。

画面を眺めるより先に「なぜ保存処理が変わったのか」と気づける手がかりです。

また、0件に見えることと、データが削除されたことは同じではありません。今回のコードは別のキーを読むようになっただけです。正常コードへ戻した後に元の2件が表示されたことも、この切り分けを支えています。

Gitで戻す前に、正常版を退避しておく

元のプロジェクトには未コミットの作業がありました。そこで、復旧操作は専用フォルダの中だけで行いました。

以下はPowerShellで、プロジェクトのルートから始める例です。実験用フォルダがすでにあれば停止します。 現在のファイルをコピーするため、未コミットのアプリ変更も複製側へ持ち込めます。

$source = Join-Path (Get-Location) 'apps/content-idea-manager'
$practice = Join-Path (Get-Location) 'work/article-004-practice'
if (-not (Test-Path (Join-Path $source 'index.html'))) {
    throw 'アプリの場所を確認してください'
}
if (Test-Path $practice) { throw '新しい実験フォルダを指定してください' }
New-Item -ItemType Directory -Path $practice | Out-Null
'index.html','script.js','style.css','README.md' | ForEach-Object {
    Copy-Item -LiteralPath (Join-Path $source $_) -Destination $practice
}
Set-Location $practice
Get-Location

ここで表示された場所が、本体ではなく実験フォルダであることを確認します。

git init
git add index.html script.js style.css README.md
git status --short

`git init`は、この複製専用のGit管理を始める操作です。`git add`で正常ファイルをインデックスという退避先へ登録します。この練習ではコミットは作りません。

これは1回の復旧練習用です。変更後に再びgit addすると退避内容が変わるので、実験中は追加のgit addをしません。長期の履歴管理の代わりではありません。

複製を開いてテスト用のネタを1件保存したら、AIにはこの複製だけを指定して修正を頼みます。データを継続確認するときは同じブラウザ・同じURLを使います。file URLで保存できない環境では、ローカルサーバーを利用します。

差分を見て、指定したファイルだけ戻す

修正後、まず何が変わったかを確認します。

git diff --name-only
git diff -- index.html script.js style.css

1つ目は変更ファイルの一覧、2つ目は内容の差分です。画面では、保存済みの件数と内容、新規追加、状態変更、再読み込みをもう一度確認します。

戻す必要がある場合は、実験フォルダであることを再確認して実行します。

Get-Location
git rev-parse --show-toplevel
git restore --worktree -- index.html script.js
git diff --exit-code

`git restore --worktree`は、指定したファイルをインデックスの正常版へ戻します。今回、実際に使った操作です。必要な修正もこの2ファイル内では戻るので、差分を記録してから行います。

最後のコマンドで差分がなく、終了コードが0なら、作業ファイルと退避版が一致しています。コミットを作っていないため、git statusに出るAは「正常ファイルをステージ済み」という意味です。

実験では、コード復旧の計測区間は約0.11秒でした。事前の変更ファイル名取得を含みます。再読み込みして元の2件を確認するまで約9秒、追加・状態変更などの確認まで含めると約29秒でした。今回の環境での値です。

ただし、故障版で別キーへ保存した1件は自動統合されませんでした。Gitが戻すのはコードで、ブラウザのデータそのものではありません。バックアップのない削除済みデータを回収した実験でもありません。

変更範囲を明示したプロンプトでも試す

正常コードへ戻してから、別の修正担当へ次を1回送りました。実際の全文です。

安全な複製への実際の改善版修正依頼です。作業可能範囲は C:/Users/shota/Projects/ai-sidebusiness-lab/experiments/codex/002-webapp-regression-recovery/lab のみです。リポジトリのAGENTS.mdを守り、本体 apps/ や他のファイルを編集しないでください。commit・push・公開・サブエージェントは禁止です。依頼本文：『記事ネタ帳の見出しを「発信ネタ帳」に変更してください。変更対象はindex.html内のh1の文字列だけです。title要素、フォーム、一覧、CSS、script.js、保存キーarticle-ideas-v1、データ構造、読み込み・保存処理は変更しないでください。まず既存ファイルとGit差分を調べ、変更予定を説明してから最小差分で修正してください。既存の追加、全カテゴリ・ステータス、メモ、一覧からの状態変更、保存済みデータの読み込みを維持してください。修正後は差分を確認し、node ../check.cjs lab をlabディレクトリから実行して結果を報告してください。ブラウザでの追加、状態変更、再読み込み、エラー確認は親側が行います。問題があれば全体を書き換えず、原因と必要な変更を報告してください。』開始・終了時刻、変更ファイル、変更内容、実行した確認、完了報告を返してください。モデル識別子が自身で確認できない場合は未取得としてください。ブラウザは操作しないでください。

check.cjsは今回の実験用に用意した模擬テストです。読者のアプリでは、そのまま使えるとは限りません。依頼へ含める確認項目は、対象アプリの正常状態から選びます。

改善前後を比べると、成果物は同じだった

最初の依頼

試行回数：1回
変更範囲の指定：見出しを変え、最小限の変更にするよう依頼
実際の変更：index.htmlの1行
模擬テスト：検証担当が9項目すべての成功を確認
ブラウザ確認：追加・状態変更・保存保持が正常
担当の実装時間：22秒

改善版の依頼

試行回数：1回
変更範囲の指定：h1の文字列に限定し、変更してはいけない箇所も列挙
実際の変更：最初の依頼と同じ、index.htmlの1行
模擬テスト：修正担当と検証担当が、それぞれ9項目すべての成功を確認
ブラウザ確認：追加・状態変更・保存保持が正常
担当の実装時間：37秒

比較して分かったこと

両方のindex.htmlはハッシュも一致しました。今回、改善版が変更量を減らしたわけではありません。

詳しい指示で「どこを維持し、何を確認するか」は明確になりました。しかし、この各1回の結果から事故防止の効果や成功率を断定することはできません。

なお、改善版担当はGitの状態について「未追跡のため差分に出ない」と報告しました。検証担当が実験用リポジトリを直接確認すると、差分は取得できました。完了報告も確認対象だと分かった点です。

AIの「直しました」を信用する前に

今回から、完了報告を受け取った後は次を確認することにします。

変更されたファイルは依頼と合っているか。
依頼していない処理の差分はないか。
元からあった主要機能を再度試したか。
エラーがなくても、件数や内容が変わっていないか。
新規登録だけでなく、修正前の保存データも読めるか。
今いるGitリポジトリと差分の基準は正しいか。
正常版へ戻し、同じ操作を再確認できるか。

今回は通常依頼で壊れませんでした。それでも、意図的な故障を通して「保存成功の表示だけでは確認不足」という具体例を作れました。

今回確認できたこと・できなかったこと

確認できたのは、保存キーの変更で既存データが見えなくなること、そのとき新規保存は動くこと、正常コードへ戻すと元のデータが再表示されることです。

通常のAI修正で自然に事故が起こる条件、改善プロンプトの優位性、別モデルでの結果は確認できていません。

Codexが実行した修正依頼は最初と改善版の計2回。意図的な故障注入は別に1回です。ユーザー本人によるコード修正は、このタスク中にはありません。故障注入も検査コードもCodexが作りました。本人の手作業時間は未取得です。

作業中にはGitの所有者チェックで止まったこともありました。対象ディレクトリを確認し、そのコマンドにだけ例外を付けて読みました。PC全体のGit設定は変えていません。

対象外の環境

スマートフォン、他のブラウザ、ブラウザアプリ全体の終了・再起動、複数タブ同時編集、移動前の実データの移行は対象外です。確認したのは再読み込みと実験タブの閉じ直しまでです。

公開サーバー、Cloudflare、ログイン、データベース、決済、JSONファイルによるバックアップ・インポートも今回試していません。note公開、X投稿、commit、pushは行っていません。

次に試すこと

次は、見出し変更より影響範囲が広い編集・削除機能を、安全な複製で1つずつ試したいと考えています。保存済みデータを退避する方法も別途必要です。

また、完了報告の確認を普段の作業で使えるよう、「AIの『直しました』を信用する前に確認する7項目」という独立した無料記事も候補にしています。

公開・復旧キットの企画もありますが、今回のGit実験で公開やJSON復元まで確認できたわけではありません。販売中の商品としては案内しません。

まずは、修正前の複製、修正後の差分、同じ操作の再確認。この1往復を、小さなアプリで試せたのが今回の成果でした。