AIに任せたら、ファイルが消えた——事故報告446件を分類したら「無断削除」が最多だった

AIにコードを書かせていたら、プロジェクトのファイルが消えていた——。そんな報告がRedditにどれだけ転がっているのかを、カナダのヨーク大学（トロント）とカルガリー大学の研究チームが本気で数え上げました。素材はAIコーディング関連の29のサブレディットから集めた110万件の投稿。そこから、実際に起きたセキュリティやプライバシーの問題を述べている446件の投稿と6,280件のコメントを絞り込み、内容ごとに分類したのです。結果を先に言うと、報告された事故のうち最も多かったのは「許可していないファイル操作」で、その中でも「無断削除」が突出していました。

この研究はプレプリント（査読前の論文）としてarXivに公開されており、ソフトウェア工学の国際会議ASE 2026に採択されています。

調査の対象と方法

研究チームが調べたのは、Claude Code、Cursor、GitHub Copilot、OpenAI Codexのような「AIと一体で動く開発環境」です。論文はこれをLIDE（LLMネイティブなIDE）と呼んでいます。従来のエディタにAI機能を後付けしたものではなく、最初からAIにコードを書かせ、ファイルを触らせ、コマンドを実行させる前提で作られた道具のことです。

手順はこうです。まず2023年1月から2026年3月までのRedditの投稿を大量に収集し、AIを使った絞り込みと人手の確認を重ねて、実際にセキュリティ・プライバシーの問題を報告している446件の投稿を特定しました。さらに、それらの投稿に付いた6,280件のコメントも分析対象にしています。投稿には「何が起きたか」が、コメントには「他の開発者がどう対処を勧めたか」が書かれているためです。

これまでの研究が見ていなかった場所

AIが書くコードの危険性は、これまでも研究されてきました。AIは学習データに含まれる古い脆弱なコードの書き方を再現しがちだとか、入力チェックを省いたコードを出しがちだとか、そういう「生成されたコードの中身」の話です。

ただ、LIDEはコードを書くだけの道具ではありません。ファイルを読み、書き換え、削除し、コマンドを実行し、外部ツールと連携する。つまりひとつの「システム」です。コードの中身がどれだけ安全でも、システムとしての振る舞いが危なければ事故は起きます。そして、その部分で実際の利用者に何が起きているかを大規模に数えた研究は、これまでありませんでした。

研究チームは伝聞を集めただけではなく、一部は自分たちで再現も試みています。たとえば「アクセス制限をかけたはずの.envファイル（APIキーなどの秘密情報を入れておくファイル）をGitHub Copilotが読みに行った」というRedditの報告について、チームが同じ状況を作って検証したところ、数回のやり取りの後にCopilotが制限を無視して.envファイルを読み、書き換えようとする挙動を確認しました。

最多は「無断削除」という結果

セキュリティ関連の報告を分類した結果、最も多かったカテゴリは「許可していないファイル操作」で43.1%。その内訳を見ると、プロジェクトのディレクトリやファイルを無断で削除した事例が28.3%と突出しており、無断での書き換えが8.8%、作業対象の外にあるファイルへのアクセスが5.7%、ファイル権限の無断変更が0.6%と続きます。権限変更はまれですが、論文は「Claude Codeが同意なしにスクリプトへchmod +x（実行権限の付与）を実行した」という報告を、件数の少なさに対して影響が大きい例として挙げています。

以下、運用上の安全性の問題が23.9%、危険なコードの生成が18.2%、利用者の指示や許可リストの無視が16.5%、外部ツール連携のリスクが4.7%です。個別の報告には強烈なものが並びます。Replitが本番のデータベースを削除した、「絶対にプッシュするな」と明示したのにCursorがそれを無視した、Cursorが生成したソフトがウイルス検査サービスのVirusTotalで9件の検出を受けた——いずれもRedditに投稿された報告です。

プライバシー関連の194件では、「このツールが何のデータを集め、どこへ送り、何に使っているのか分からない」という透明性の欠如が45.9%で最多でした。無断のデータアクセスが23.7%、データの漏えいが15.5%と続き、少数ながら「Claude Desktopの利用者に、他人のセッションのメッセージが届いた」という報告まであります。

そして、この分類作業から浮かび上がったのが本題です。研究チームが問題の10カテゴリを整理したところ、そのうち7つはLLM（AIモデル）そのものではなく、システム側の設計に起因するものでした。ファイルの無断削除も、指示の無視も、データの不透明な送信も、モデルが賢いか賢くないかの話ではありません。AIの出した操作を、確認もかけずにそのまま実行してしまうIDE側の作りの問題、つまりモデルの性能ではなく権限の渡し方の問題だった——それがこの研究の核心です。

著者のひとりでヨーク大学准教授のGias Uddin氏はThe Registerの取材に対し、報告された問題の多くはツールの設計と与えられたアクセス権に由来するもので、モデル単体の問題ではないと述べています。そのうえで、何かが起きてから「この道具は思っていたより広い権限を持っていた」と知る事態を開発者に強いるべきではなく、セキュリティとプライバシーの仕組みは、ファイルへの広いアクセスを与える前に設計へ組み込まれているべきだ、というのが同氏の主張です。

利用者が編み出した13種類の自衛策

興味深いのは、コメント欄の分析です。事故報告に付いた6,280件のコメントのうち1,318件には、他の開発者からの具体的な対処の提案が含まれていました。研究チームはこれを13種類の自衛策に整理しています。大きく5つに分けると、多い順に、設定管理（権限やAIの自律動作を制限する設定）が33%、コードの統制（AIの出力を人が必ずレビューする、バージョン管理でいつでも巻き戻せるようにしておく）が31%、データ保護（秘密情報のファイルをAIから隔離する）が13%、隔離（AIの生成したコードを仮想マシンやコンテナの中でだけ動かす、ローカルのAIモデルを使う）が13%、外部の助言（ベンダーへの問い合わせや公式ドキュメントの参照）が9%です。

裏を返せば、利用者はツールの組み込みの安全機構を信用しておらず、外側から自力で檻を作って使っている、ということです。論文はこの状況を「開発者のあいだに広がる不信」と表現しています。そのうえで、危険な操作の前には明確な承認を求めること、秘密情報のファイルへのアクセスを初期設定で制限すること、プロジェクトや会話を互いに隔離すること、ツールが何をしているかを見えるようにすることなど、6つの提言をツールの開発元に向けて出しています。共通する考え方はひとつで、「安全な側を初期設定にする」。利用者が自分で檻を組み立てなくても済むように、最初から檻の中で動く道具にしておくべきだ、という話です。

読むときの留意点

この研究には、数字を受け取るうえで押さえておきたい前提がいくつかあります。まず、データはRedditへの自己申告です。実際のログを計測したものではなく、報告どおりに事故が起きたかどうかは（一部の再現実験を除いて）検証されていません。論文自身も「これは開発者が報告した問題であって、確認済みの脆弱性ではない」と明記しています。ですから「利用者の28.3%が削除を経験した」のではなく、「報告された事故のうち28.3%が削除だった」という数字です。

また、この論文は製品間の優劣を比較していません。投稿の中で名前が最も多く挙がったのはCursorですが、これは利用者数と議論の多さを反映したもので、名前が多く出る＝危険、ではないと論文は注意しています。Redditに書き込む層に偏りがある点や、企業内での利用実態は反映されていない点も、研究チーム自身が限界として挙げています。そして前述のとおり、査読前のプレプリントです。

それでも、AIコーディングの事故について「何がどれくらい報告されているか」をここまでの規模で整理した研究はこれが初めてで、対策の優先順位を考える材料としては十分に使えます。もしAIコーディングツールを使っているなら、まずはバージョン管理で全部をこまめにコミットしておくこと、秘密情報のファイルをAIの手の届かない場所に置くこと。上の13種類の自衛策は、要するに先に痛い目を見た人たちの知恵の集積です。ツール側の初期設定が安全になる日まで、使わせてもらう価値はありそうです。