AIに任せた作業で、なぜ作業範囲外のデータ消失が報告されたIssue #13511は起きたのか

2026年8月13日 12:13

深夜の開発で「あと一つだけ直して公開しよう」とAIに頼む。画面が期待どおり動けば、そのまま次へ進みたくなります。ただ、正常に見える画面と、裏側の安全性は別の成果物です。

まず、報告された事実を分けて読む

添付事例集では、OpenAI Codexについて「Codex deleted my entire Drive」と記録されています。影響分類は「ワークスペース外データ破壊」、根拠レベルは「公開Issue・当事者報告（未独立検証）」です。根拠資料は[#13511]

で確認できます。

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

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

AIエージェントがシェルへアクセスできると、作業フォルダの外側も操作対象になり得ます。パスの誤解、リンクやジャンクション、広いOS権限が重なると、依頼したプロジェクト以外へ影響が広がります。指示の丁寧さだけでなく、権限境界が必要です。

テストが通ったことは、期待した入力で期待した結果が出た証明です。ワークスペース外データ破壊のような問題は、別ユーザー、誤ったパス、途中失敗、再起動、権限超過といった正常系の外側で見つかります。AIに確認させる場合も、実装時とは別の会話と前提で試す価値があります。

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

この事例のような端末内の削除やセッション消失は、URL診断の対象外です。一方、復旧して公開するサービスに別の設定不備が残っていないかは、[Code診断ラクダ]

で確認を始められます。URLだけ、約1分、無料で、GitHub連携とカード登録は不要です。守る対象の違う確認を重ねるために使います。

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

いまのあなたの環境で「作業範囲外のデータ消失が報告されたIssue #13511 」と同じ結果を起こさないための停止条件と復旧地点を、具体的に説明できますか？