ソース・ファイルの削除が報告されたIssue #5904——「動いた」の次に確認したいこと

コードが通り、テストも緑になり、デプロイも成功する。ここまで揃えば完成に見えます。けれど、今回見るのは失敗表示が出ないまま起きた、または公開報告として訴えられた問題です。

公開情報で確認できること

添付事例集では、OpenAI Codexについて「Deleted/Reset File With Uncomitted Changes w/o Backup, Unable to Restore」と記録されています。影響分類は「ファイル・設定・データ消失」、根拠レベルは「公開Issue・当事者報告（未独立検証）」です。根拠資料は#5904で確認できます。

根拠は製品の公式GitHubリポジトリに投稿された公開Issueです。ただし、Issueの存在はベンダーによる事実認定や原因確定を意味しません。再現性、環境、影響範囲が未確認の可能性があるため、この記事でも「報告された内容」として扱います。

この記載から確実に言えるのは、公開情報上で「ファイル・設定・データ消失」に分類される事象が報告・整理されていることです。添付ファイルにない実行環境、追加被害、ベンダーの判断、報告後の修正状況は創作しません。情報が限られている場合ほど、分からない部分を分からないまま残すことが信頼性につながります。

速さの裏で抜けやすい確認

「元に戻す」「整理する」「作り直す」といった言葉は、人間には対象が明らかでも、コマンドには範囲が必要です。未コミット変更や未追跡ファイルは、AIが作ったものか以前からあったものかをGitが区別できません。実行前の保存地点と差分確認が安全性を左右します。

OpenAI Codexに限らず、AIへ任せる範囲が広がるほど、人間が確認すべきなのはコードの一行一行より「どこまで変更できるか」「失敗したらどこへ戻るか」になります。能力を疑うのではなく、失敗を前提に境界を置くことで、便利さを捨てずに被害を小さくできます。

止める場所を先に決める

• 作業開始前に既存差分をcommit、stash、パッチで退避する
• 削除予定の絶対パスと一覧を実行前に表示させる
• dry-runがあるコマンドは先に対象だけ確認する
• 未追跡ファイルを含む破壊的Git操作を自動承認しない

これらは、公開事例から導く一般的な確認方法です。今回の報告で、すべての対策不足が原因として確定したという意味ではありません。自分の構成に同じ条件があるかを確認し、必要なものだけを実装してください。

第三者視点を入れる入口

Code診断ラクダは、このローカル・クラウド内部の事故そのものを直接検出したり、失ったデータを復元したりするサービスではありません。役割は、公開済みWebサービスに残る別のリスクをURLから見直すことです。約1分の無料簡易診断で、カードもGitHub連携も不要。ローカルのバックアップや権限確認とは分けて使ってください。

「動いた」「処理が終わった」という表示だけで次へ進む前に、変更範囲、公開範囲、戻し方を一度確認する。その短い停止が、AIの速さを安心して使い続けるための工程になります。

いまのあなたの環境で「ソース・ファイルの削除が報告されたIssue #5904」と同じ結果を起こさないための停止条件と復旧地点を、具体的に説明できますか？

#Git #データ消失 #AIエージェント #バイブコーディング #Code診断ラクダ

機密情報の外部公開