「秘密は隠しきれない」AI開発環境の危うさ

1. 1540万件の書き込みから446件を選び出す
2. セキュリティの問題は5種類に分かれた
3. プライバシーの問題も5種類
4. どのIDEの話が多かったのか
5. 開発者がとっていた13の自衛策
6. 「LLMのせい」ではなく「作り方」の問題
7. この研究で分かっていないこと
8. 使う人が気をつけたいこと
9. 参考サイト

研究チームが調べたのは、LIDE（LLM-native IDE）と呼ばれる種類の開発環境です。IDEとは、プログラムを書く、動かす、間違いを探す、といった作業を1つの画面でまとめてできるソフトのこと。LIDEはそこに大規模言語モデル（LLM）を後付けの拡張として足すのではなく、最初から中心に据えて設計されたものを指します。Cursor、GitHub Copilot、Claude Code、Codex などが代表例です。

調査の元にしたのは、AIを使ったプログラミングについて語られているRedditの掲示板（サブレディット）46か所です。2023年（令和5年）1月から2026年（令和8年）3月までの投稿とコメント1540万件を集めました。このうち投稿だけでおよそ110万件あります。

これを全部人が読むのは無理なので、まずLLM（GPT-OSS:20B）に「セキュリティやプライバシーの話をしているか」を判定させ、3801件まで絞り込みました。この段階では、見落としを減らすことを優先し、関係のない投稿が多めに残る設定にしています。実際、別に用意した200件で精度を測ったところ、取りこぼしはゼロだった一方、拾い上げたもののうち本当に関係があったのは2割ほどでした。

そのうえで著者2人が3801件を1件ずつ読み、実際に問題が起きた・問題を指摘している投稿だけを残しました。2人の判定は99.3％で一致し、食い違った26件は全員で話し合って決めています。こうして残ったのが446件で、46か所のうち29か所の掲示板から集まりました。これらの投稿に付いていたコメント6280件（1投稿あたり平均14件）も、対策を調べるために分析されています。

446件のうち、セキュリティに関わるものが297件、プライバシーに関わるものが194件でした（両方に当てはまるものが45件）。研究チームは、セキュリティの問題を5つの大分類と17の小分類に整理しています。割合はセキュリティ297件に対する比率です。

• 許可のないファイル操作（43.1％）‥‥作業場所にあるファイルを、断りなく消す・書き換える・のぞく。もっとも多い削除だけで28.3％を占めます。Codex が「追加してほしい」と頼んだだけなのにコード全体を消して1行に置き換えた、Cline が「APIの応答が詰まると編集中のファイルが黙ってSSDから消える」といった報告があります。
• 動作の安全性（23.9％）‥‥作業中のファイルではなく、本番の環境やOSの設定にまで手が及ぶもの。Replit が本番のデータベースを削除した例、「絶対にGitHubへ送るな」と指示したのに Cursor が送信した例が挙がっています。悪意ある指示を外から紛れ込ませるプロンプトインジェクションも2.7％ありました。
• 危険なコードの生成（18.2％）‥‥脆弱 （ぜいじゃく） なコード、実在しない関数や部品を混ぜたコード、素性の分からない外部部品の追加など。Cursor が生成したコードに検索順位を操作する迷惑な仕込み（SEOスパム）が含まれていた例、生成されたソフトからウイルス検査で9件の検出が出た例があります。
• 利用者が決めたルールの無視（16.5％）‥‥「このファイルは触らないで」「コミットの前に確認して」といった明示的な設定を、AIが回り込んで破ってしまうもの。「除外設定を迂回して、触ってほしくないファイルをファイルシステム経由で編集する」という書き込みがありました。
• 外部ツール連携のリスク（4.7％）‥‥拡張機能やMCPサーバなど、あとから接続した部品を経由した危険。悪意あるMCPサーバが道具の呼び出しに見せかけて不正な指示を送り込む、といった指摘がありました。

プライバシーの問題194件も、5つの大分類と15の小分類に整理されました。割合は194件に対する比率です。

• 説明の不足（45.9％）‥‥何が集められ、どこへ送られ、学習に使われるのかが分からない、という不安。もっとも多い分類です。「アンインストールしたはずのAIプラグインが、その状態を守っていないように見える」といった書き込みがありました。無料プランに切り替わると設定が変わり、データが学習に使われるようになった、という指摘もあります。
• 許可のないデータ参照（23.7％）‥‥環境変数を書いたファイルやパスワード、個人情報を、指示していないのにAIが探し出して読むもの。「データベースの認証情報が必要だと自分で判断して、.env ファイルを探しに行った」という報告が典型例です。.env は、パスワードやAPIの鍵といった秘密の情報を書いておく設定ファイルで、ふつうは共有しないものです。
• プライバシーの漏えい（15.5％）‥‥いったん渡した情報が、想定した範囲を超えて保存・利用されるもの。学習への利用と保存期間に関する不満が9.3％で、この分類では最多でした。「スクリプトの中にパスワードやAPIの鍵をこっそり書き込んでしまう」という報告もあります。
• 無断の送信・収集（11.9％）‥‥同意なしに外部へ送られるもの。通信を横から観察して調べたところ、送信を止める設定にしていたのにソースコードが送られていた、という報告がありました。何もしていないのに一定間隔で外部のサーバへつなぎに行っていた、という例もあります。
• 文脈の混線（8.8％）‥‥別の会話や別のプロジェクトの内容が混ざってしまうもの。「自分のチャットに他人からのメッセージが届き始めた」「まったく別のプロジェクトの依頼内容が、こちらのファイルに出てきた」といった書き込みが該当します。

446件のうち383件は、どのIDEの話かが書かれていました。対象となったのは16製品です。もっとも多かったのはCursorで130件。次いで Claude が89件、Codex が41件、GitHub Copilot が31件、Windsurf が23件、Visual Studio Codeと Replit がそれぞれ16件でした。CursorとClaudeの2つで、IDE名が挙がった投稿のおよそ6割を占めます。

ただし、この数字を製品の危険度の順位と読むことはできません。話題に上る回数は利用者の多さに引きずられるからです。研究チームも、Cursor はRedditでもっとも話題になっているAI開発環境の1つであり、件数の多さは利用の広がりを反映した部分が大きいと注意しています。VS Code のようにAI機能を拡張機能として使う製品では、話題が複数のツールに分散するため件数が少なめに出ます。一方で、Cursor と Claude はセキュリティ・プライバシーのほぼすべての分類に登場しており、問題の種類の広がりも大きいと指摘されています。

投稿に付いたコメントのうち、具体的な対策を含む1318件を分類したところ、13種類の自衛策が浮かび上がりました。5つのまとまりに整理されています。

• 設定の見直し（501件、33％）‥‥IDEの権限やファイルへの近づき方、AIがどこまで自分で動いてよいかを制限する（345件）。勤務先の規則や法令との整合を確かめる（74件）。送信を止める（38件）。追加した拡張機能を監視する（24件）。記録を残して監視する（20件）。
• コードの管理（471件、31％）‥‥AIが書いたコードは受け入れる前に人が必ず読む（239件）。バージョン管理（Gitなど）を使い、いつでも元に戻せるようにする（232件）。
• データの保護（199件、13％）‥‥秘密情報の入ったファイルにAIが近づけないようにする（143件）。会話の記憶が別のプロジェクトへ持ち越されないようにする（56件）。
• 隔離（199件、13％）‥‥サンドボックスや仮想環境の中でAIを動かす（105件）。手元で動くLLMを使い、外部へデータを出さない（94件）。
• 外部の情報に頼る（139件、9％）‥‥提供元に問い合わせて保証の内容をはっきりさせる（74件）。公式の文書を読んで正しい設定を確かめる（65件）。

「自分のマシンではなく、仮想環境の中でこうしたエージェントを動かすべきだ」「バックアップも取らずに3万行のコードを書かせるべきではなかった」といった、実際に痛い目に遭った人からの助言が並んでいます。研究チームは、開発者がIDEに備え付けの安全機能だけに頼ることはほとんどなく、外側の仕組みで自分を守っている点に、提供元への根強い不信が表れていると述べています。

この研究でもっとも重要な指摘は、問題の多くがLLMそのものの性質ではなく、それを組み込んだ開発環境の設計に由来するという点です。10の大分類のうち7つはシステム側の作りに起因するもので、LLM自体に起因するものは2つ、両方にまたがるものが1つでした。

たとえば、許可のないファイル参照はすべてのIDEに共通して見られましたが、これはLLMが「悪い答え」を出したせいというより、LLMが出した指示を、開発者が決めた制限を確かめずにそのまま実行してしまう仕組みのせいです。研究チームは、AIの安全性の議論がモデルの中身に偏りがちであることを踏まえ、モデルの外側にあたる設計段階で安全の原則を組み込む必要がある、と主張しています。

どの機能が問題を招きやすいのかも整理されています。コードの自動補完、デバッグの支援、そして外部ツールの実行の3つが目立ち、とくに外部ツールの実行は10の分類のうち5つに関わっていました。研究チームは、AIが自分で判断して外部の道具を動かせる仕組みには、スマートフォンのアプリストアのような事前審査の仕組みが必要ではないか、と提案しています。

また、AIがコードを書くようになったことで、開発者の役割は「書く人」から「確かめる人」へ移りました。ところが確認は手作業に任されたままで、AIが自動的に反映する機能はしばしばその確認を素通りしてしまいます。生成されたコードを取り込む前に自動で検証する層を、IDE側に標準で組み込むべきだとしています。プライバシーについても、回答を的確にするほど秘密情報を含む中身を広く読む必要があるという板挟みがあり、意味を保ったまま秘密の値だけを隠すきめ細かなふるい分けが要ると述べています。

まず、この論文は2026年（令和8年）7月31日にarXivで公開されたプレプリントであり、査読を経て学会や学術誌に載ったものではありません。本文中の学会名や掲載情報は、投稿用の書式の見本のまま残っています。

次に、分析の材料はRedditの書き込みです。実際に何が起きたかを技術的に検証したものではなく、開発者がそう報告したという記録にすぎません。研究チームも、これらを「確認された脆弱性」ではなく「開発者が報告した懸念」として読むべきだと明記しています。図1で紹介されている .env ファイルの一件など、一部については研究チームが再現を試みていますが、すべてではありません。

また、Redditに書き込む人は開発者全体の一部です。企業の中での使われ方や、公に不満を書かない人の経験は含まれません。件数は「議論の量」を表すもので、問題の発生率でも、製品ごとの危険度の順位でもありません。

分類の境目にも曖昧さが残ります。1つの投稿が複数の問題に当てはまることがあり、実際に27件のセキュリティ投稿と12件のプライバシー投稿には複数の札が付いています。そのため、各分類の割合を足しても100％にはなりません。なお、研究チームは集めたRedditのデータと分析用のプログラム、分類の手引きをZenodoで公開しており、第三者が同じ手順をたどって確かめられるようにしています。

プログラムを書く仕事をしていなくても、AIにファイルを触らせる道具は身近になってきました。この研究から引き出せる、日常に近いところでの心がけを挙げておきます。

• 作業を始める前に、元に戻せる状態をつくっておく。バージョン管理を使う、あるいは作業用フォルダごとコピーを取っておく。もっとも多かった被害がファイルの削除である以上、これがいちばん効きます。
• パスワードやAPIの鍵は、AIが読むフォルダの中に置かない。除外設定はしておくべきですが、それが必ず守られるとは限らないという前提で、置き場所そのものを分けておくのが確実です。
• AIに自動で実行させる範囲を、最初は狭くしておく。慣れてきてから少しずつ広げる。
• 会社の業務で使うときは、勤務先の規則を先に確認する。契約や設定によっては、入力した内容が学習に使われる場合があります。
• 拡張機能やMCPサーバを追加するときは、提供元をよく確かめる。外部から足した部品が、いちばん見えにくい経路になります。

AIを組み込んだ開発環境は、作業を速くしてくれる道具です。この研究が示しているのは、その速さと引き換えに確認する責任が人の側に移ったということであり、道具を使うべきでないということではありません。

• Impossible to hide secret ...: Uncovering Security and Privacy Issues in LLM-native IDEs：arXiv
• 論文本文（PDF）：arXiv
• Replication Package：Zenodo