デルタメモ

AI開発

gitignoreのローカル実データをForce削除しない

エージェントが掃除や移動のつもりでローカル実データをForce削除し、Gitにもゴミ箱にも残らず復元不能になった事故の型と、再発防止のルール。

リポの移動と掃除をエージェントに任せたら、gitignoreしていた実データのフォルダがForce削除されていました。Gitの履歴にもゴミ箱にも残っていません。戻す手段はありませんでした。Remove-Item -Recurse -Force や rm -rf は確認を飛ばして一度に消すので、Git管理外のデータはそのまま戻らないことがあります。読み終わると、エージェントのルールファイルにForce削除の禁止が理由つきで入り、削除の前に「何を消すか」と「消えても取り直せるか」を確かめる手順が決まった状態になります。

善意の先回りが事故になる話全般はAIエージェントのよかれが事故になるときにまとめています。この記事は不可逆な削除だけを扱います。

この記事でわかること

Force削除が起きる流れと、復元できない理由を先に示します。そのうえで、再発を止める判定をルールファイル・元データの置き場・移動の手順の3つに分け、削除が本当に必要なときの進め方と、作業前にAIへ渡す貼り付け文をまとめます。

起きたことの型

典型は、取得結果や作業用キャッシュをリポジトリの data/ などに置き、秘密や大きなファイルをコミットしないようgitignoreしている構成です。エージェントが整理・移動・重複の解消のつもりで、そのディレクトリをForce削除します。gitignore配下なのでGitに履歴がなく、コマンドによる削除はゴミ箱を通りません。クラウド側にもまだコピーが無ければ、どこからも取り戻せなくなります。

「ローカルはキャッシュだから消してよい」が成り立つのは、消えても取り直せる元データが別の場所にあるときだけです。

Force削除がほかの削除より危ない理由

手段よくある結果
Remove-Item -Force / -Recurse -Force確認プロンプトを出さずに一気に消える
rm -rf / rd /s /q同上。ディレクトリ丸ごと消しやすい
エクスプローラなどでゴミ箱へ送る取り戻せる余地が残ることが多い

gitignore配下には、そもそもGitの安全網がありません。バックアップやクラウド側の版管理がまだ無い段階では、手元のフォルダが唯一のコピーになっていることもあります。その状態のForce削除は、本番データを消すのと同じ重さです。

失敗1 「消して」と言われたらForceで消す

状況は、ユーザーが「古いデータを消して」「リポをきれいにして」と頼んだ場面です。エージェントは指示があったので消してよいと判断します。

悪い例は、対象を確かめずに Remove-Item -Recurse -Force data を実行して「消しました」と報告することです。良い例は、消す予定のパスを並べて確認を求め、了承されたらゴミ箱へ送るか、ユーザー自身に消してもらうことです。

消し方をエージェントの判断に任せないために、毎回読まれるルールファイル（AGENTS.md、CLAUDE.md、Cursorのrulesなど）に例外なしで書いておきます。禁止の文だけでなく、「gitignoreの実データをForce削除し、復元できなくなった」という理由の一文も添えます。理由があると、次のセッションのエージェントが「今回は例外」と軽く扱いにくくなります。

合格条件は、ルールファイルに「明示指示があっても -Force では消さない」という文と、その理由が書いてあることです。

失敗2 元データの置き場を決めないまま、ローカルをキャッシュ扱いする

data/ を「どうせキャッシュ」と見なしていても、取り直すための元データがまだどこにも無いことがあります。

悪い例は、設計メモに置き場の記述が無く、エージェントも人間も「たぶんクラウドにある」と思い込んでいる状態です。良い例では、gitignore配下の実データごとに、元データをどこに置いているか（オブジェクトストレージかDBかGitか）を設計メモに書きます。あわせて、版管理やスナップショットがあるか、誤って消したときにどう戻すかも書いておきます。

元データがクラウドにあれば、ローカルを消しても取り直せます。手元にしか無いなら、削除禁止と退避を一緒に決めます。

合格条件は、gitignore配下の実データそれぞれについて、元データの置き場が一文で書いてあることです。

失敗3 移動や付け替えのつもりで、中身を消す

データを別の場所へ移し、元の場所には参照だけを残す整理（ポインタ化）の途中には、「元を消す」工程が入ります。移動のつもりが削除になる取り違えは、ここで起きます。

悪い例は、コピーが終わったかを確かめずに元のフォルダをForce削除することです。良い例では、コピー先のファイル数と容量が元と合うことを確かめてから、元をゴミ箱へ送ります。

合格条件は、移動の手順で「コピー先の確認」が「元の削除」より前にあることです。

削除が本当に必要なときの進め方

  1. 消すパスを並べ、それぞれの元データがどこにあるかを確かめる
  2. 元データが無ければ、先にコピーかアップロードで退避する
  3. Forceを使わず、ゴミ箱へ送るか、ユーザーに消してもらう
  4. エージェントは、消す前に「このパスを消してよいか」を出し、了承を得てから動く

削除・デプロイ・本番相当の書き込みは、どれも実行前に確認する運用にしておきます。

作業前にAIへ渡す入力

人間向けの長い手順は書きません。次はすべて、作業前にAIに読ませる文と貼る文です。

AI向けの永続ルール（rulesやAGENTS.mdに書く）

ローカルに対する「Remove-Item -Force」「Remove-Item -Recurse -Force」「rm -rf」「rd /s /q」相当は禁止。
リポ掃除・移動を理由にしたディレクトリ丸ごとのForce削除も禁止。
明示指示があっても「-Force」では消さない。対象を列挙して確認し、ゴミ箱へ送るかユーザー自身に削除してもらう。
理由は、gitignore配下の実データをForce削除し、Gitにもゴミ箱にも残らず復元できなくなった事故があったため。
gitignore配下の実データがありそうなパスは特に触らない。
移動では、コピー先のファイル数と容量を確かめてから元を消す。
実データ・秘密の削除、デプロイ、本番書き込みは、やる前に確認する。

AI向けの開始時に貼る文

削除や掃除の作業に入る前に、消すパスを列挙し、それぞれについて消えても取り直せる元データがどこにあるかを報告せよ。「-Force」や「rm -rf」相当は使うな。元データが無ければ先に退避案だけ出せ。実装・削除は確認後。

人間向け

なし。上をAIに渡すだけでよい。

関連