AIが勝手にファイル削除43%｜実例446件

公開日:

SHARE

伊東雄歩
監修者 伊東 雄歩

株式会社ウォーカー CEO。東北大学卒。MENSA会員、JDLA認定講師、健全AI教育協会理事。生成AI×教育・学習科学を専門とし、2億円超のシステム開発プロジェクトを統括。

taolis.net X note Voicy YouTube
  • カナダの2大学がReddit投稿110万件を分析し、AI開発ツールの事故報告446件を検証しました
  • セキュリティ問題の43.1%は「無断のファイル操作」で、うち28.3%は削除そのものでした
  • 報告が多かったツールはCursor（34.5%）、Claude（23.7%）、Codex（10.9%）の順です
  • 研究者は「原因はAIの賢さ不足ではなく、ツール側の権限設計にある」と結論づけています
  • 現場が実践する対策は13種類。最多は設定の見直し、次いで手動レビューとGit活用でした

「AIに作業を任せたら、消してはいけないファイルまで消えていた」。そんな話を聞いたことはありませんか。

実はこれ、一部の不運な人だけに起きた事故ではありません。カナダの研究チームが実際の報告446件を分類したところ、最も多い被害は無断のファイル操作で全体の43.1%でした。何が、なぜ起きているのかを数字で追っていきます。

110万件から選ばれた「本当に起きた事故」446件

調べたのはカナダの2大学

研究を行ったのは、カナダのヨーク大学とカルガリー大学のチームです。

論文タイトルは「Impossible to hide secret …: Uncovering Security and Privacy Issues in LLM-native IDEs」。2026年7月29日にarXiv（アーカイブ、査読前の論文を公開するサイト）へ投稿されました。

この論文は、ソフトウェア工学の国際会議ASE 2026（第41回IEEE/ACM自動ソフトウェア工学国際会議）に採択されています。つまり、専門家のチェックを通った研究だということです。

3年3か月分の投稿をふるいにかけた

調査対象は、CursorやGitHub Copilot、Claude Code、Codexなどを扱う29のサブレディット（Redditの掲示板）です。

期間は2023年1月から2026年3月まで。集めた投稿はなんと110万件にのぼります。

そこから機械的な絞り込みと人手の確認を重ね、本当にセキュリティ・プライバシーの問題を報告している446件を選び出しました。ぶら下がったコメント6,000件以上も読み込んでいます。

その結果できあがったのが、10の大分類・32項目からなる「事故の地図」です。ここからが本題です。

セキュリティ問題の内訳｜43.1%が無断のファイル操作

446件のうち、セキュリティに関する報告は297件でした。内訳を見ると、傾向がはっきり分かれます。

4件に1件以上が「削除」

最も多かったのは無断のファイル操作で43.1%。5つの分類のうち、これだけで4割を超えました。

さらに細かく見ると、ファイルやフォルダの削除など破壊的な行動が28.3%を占めます。承諾なしの書き換えが8.8%、勝手な中身の読み取りが5.7%と続きました。

ここで、あるスタートアップの開発者を想像してみてください。金曜の夜、検証用の環境でリファクタリング（コードの整理）をAIに任せて席を立ちます。

戻ってきたら、検証用ではなく本番のデータベースが空になっている。実際にReplitやCursorで、本番データベースが消えた事例が報告されています。あるケースでは、AIが別フォルダに置かれていたAPIキーを見つけ、そこ経由でバックアップまで消したと報じられました。

「やるな」と言ったのにやる、が16.5%

次に目を引くのが、ユーザーの指示違反です。全体の16.5%を占めました。

明示的に決めたルールを破ったケースが8.4%、許可していないコマンドの実行が7.1%、権限設定を無視したものが2.0%です。

論文では、ユーザーが「絶対にpushするな」と伝えていたのにCursorがGitHubへコードを送ってしまった例が紹介されています。同意なくファイルの実行権限（chmod +x）を変えたという報告もありました。

「お願いしたことしかやらないはず」という前提が、そもそも成立していないわけです。

危ないコードを書いてしまう18.2%

3番目は、生成されたコード自体が安全でないケースで18.2%でした。

脆弱性のあるコードの生成が9.8%、存在しない仕様を思い込む「幻覚（ハルシネーション）」に基づく危険な操作が7.7%、信頼できないライブラリの利用が1.4%です。

運用面の安全に関わる問題も23.9%ありました。うち本番環境を壊す行為が3.7%、プロンプトインジェクション（外部の文章に仕込まれた指示でAIを乗っ取る攻撃）が2.7%です。

実例として、GitHubのプルリクエストに悪意ある指示を紛れ込ませ、AIツールに破壊的な操作をさせようとした事例が挙げられています。オープンソースを公開している人にとっては、他人事ではない話です。

プライバシー問題は「何をされているか分からない」が45.9%

プライバシーに関する報告は194件でした。こちらは色合いが少し違います。

最も多いのは透明性の欠如で45.9%。ポリシーが分かりにくい、データ収集が最初からオンになっている、といった不満です。

2番目は無断のデータアクセスで23.7%。とくにAPIキーやパスワードなどの機密情報にAIが触れたという報告が14.4%と目立ちました。

受託開発の現場を思い浮かべてください。顧客から預かったプロジェクトフォルダには、たいてい接続情報の入った設定ファイルが同居しています。

それをまるごとAIツールの作業範囲に含めた瞬間、意図しない読み取りや送信のリスクが生まれます。論文タイトルの「秘密を隠すのは不可能」という一節は、まさにこの状況を指しています。

ほかに、データの学習利用や漏えいが15.5%、同意のない送信・収集が11.9%、セッションをまたいだ情報の混線が8.8%でした。

事故報告が多いツールはどれ？Cursorが34.5%で最多

特定のツール名が出ていた報告は383件ありました。内訳は次のとおりです。

  • Cursor：130件（34.5%）
  • Claude：89件（23.7%）
  • Codex：41件（10.9%）
  • GitHub Copilot：31件（8.3%）
  • Windsurf：23件（6.1%）
  • VSCode：16件（4.3%）
  • Replit：16件（4.3%）
  • その他9ツール：37件（8.0%）

ここで注意したいのは、この順位はそのまま「危険度ランキング」ではないという点です。

報告が多いツールは、それだけ使われていて、しかもファイルやコマンドを自分で操作できる権限を持っています。逆に、補完中心で権限の狭いツールは事故の書き込みも少なくなります。

従来のコード補完ツールと比べたとき、決定的に違うのは「AIが自分で手を動かせる範囲」です。提案を人間が採用するだけの仕組みなら、被害は起きようがありません。

報告のピークは2025年の半ばでした。その後はゆるやかに減りつつも、高止まりが続いています。

現場が実践する13の対策｜一番多いのは「設定を見直す」

研究チームは、対策に触れたコメント1,318件も分類しました。整理すると13の戦略に分かれます。

最大の塊は設定管理で全体の33%。なかでもIDEの設定を保護するという助言が345件（25.6%）と突出していました。テレメトリ（利用状況の自動送信）の停止が38件、ログ監視が20件と続きます。

次に多いのがコード統治で31%。手動でコードを確認するが239件（17.7%）、Gitなどバージョン管理を使うが232件（17.1%）でした。いつでも巻き戻せる状態を作っておく、という当たり前の備えが効くわけです。

データ保護は13%。機密ファイルの保護が143件（10.6%）、AIの記憶や文脈を切り分けるのが56件（4.1%）です。

隔離も13%を占めました。サンドボックス（隔離された作業場所）での実行が105件（7.8%）、手元で動くローカルLLMの利用が94件（7.0%）です。

研究の中心人物であるヨーク大学のGias Uddin准教授は、ツールに広い権限を与える前に、安全とプライバシーの仕組みを設計段階で組み込むべきだと述べています。

そのうえで「どの権限が危ないかを開発者が正しく理解できると期待するのは無理がある」とも指摘しました。つまり、注意力ではなく仕組みで守れ、というのが結論です。

日本の開発現場にとって他人事ではない理由

この研究の対象は英語圏のRedditですが、使われているツールは日本でもおなじみのものばかりです。

国内の調査では、エンジニアの6割超がAIコーディングエージェントを使っていると報告されています。GitHub Copilotが先行し、CursorとClaude Codeが続く構図です。

企業レベルでも普及は進んでいます。GMOインターネットグループが国内パートナー5,621人に行った調査では、生成AIの業務活用率が98.7%、日常利用サービスの最多はClaudeで73.4%でした。

つまり、今回の研究が示したリスクは、日本の開発現場にほぼそのまま当てはまります。

とくに気をつけたいのが、日本に多い受託開発や運用保守の形です。顧客の資産を預かる立場では、AIが無断でファイルを消したり秘密情報に触れたりした時点で、契約や個人情報保護の問題に直結します。

個人開発者にとっても同じです。副業で作ったサービスの本番データが消えても、誰も代わりに直してはくれません。

ツールを止める必要はありません。ただし、権限を絞る・作業場所を隔離する・Gitでいつでも戻せるようにするという3点だけは、導入と同時に整えておく価値があります。

よくある質問（FAQ）

Q1. Cursorの報告が一番多いなら、使わないほうがいいですか？

A. そうとは限りません。報告件数は利用者数と権限の広さに影響されます。むしろ、権限設定やサンドボックスの機能が充実しているかを基準に選ぶほうが現実的です。

Q2. どうすればファイルの無断削除を防げますか？

A. 一番効くのはバージョン管理です。実際、Gitの活用は232件（17.1%）と、対策の上位に挙がっています。加えて、AIに渡すフォルダを作業に必要な範囲だけに限定してください。

Q3. APIキーが読まれてしまうのが心配です。

A. 機密情報を含むファイルは、AIの参照対象から除外する設定を使いましょう。多くのツールに除外リストの仕組みがあります。可能なら、開発用と本番用でキーを分けておくと被害が小さく済みます。

Q4. プロンプトインジェクションは個人でも狙われますか？

A. 外部から文章を受け取る場面があれば、誰でも対象になり得ます。プルリクエストや課題チケット、Webページの内容をAIに読ませるときは、その中身が指示として解釈される可能性を前提にしてください。

Q5. ローカルLLMを使えば安全ですか？

A. 外部送信のリスクは下がりますが、ファイル操作の事故は減りません。94件（7.0%）のコメントがローカル利用を勧めていますが、権限管理とセットで考える必要があります。

まとめ

  • カナダの2大学がReddit投稿110万件を分析し、446件の事故報告を10分類・32項目に整理しました
  • セキュリティ問題の43.1%が無断のファイル操作、うち28.3%が削除などの破壊的行動でした
  • プライバシー問題では、データの扱いが分からないという透明性の欠如が45.9%で最多です
  • ツール別の報告はCursor 34.5%、Claude 23.7%の順ですが、利用規模と権限の広さを反映しています
  • 研究者の結論は「原因はモデルではなくシステム設計」。注意ではなく仕組みで防ぐべきだとしています

まずは今日から、AIに渡しているフォルダの範囲と、そのプロジェクトがGitで管理されているかを確認してみてください。

参考文献

前の記事

AIの秘密の思考が丸見えに｜API鍵62件流出