ChatGPT dotsのセキュリティ事故事例5選｜同じ仕組みの事故と対策を完全解説

ChatGPT dots（ドッツ）とは、OpenAIが2026年9月29日に発表した、24時間働き続けるAIです。
発表から間もないため、dots自体で起きたセキュリティ事故は、確認できた範囲ではありません。

本記事では、同じ仕組みを持つOpenAIのAIで報告されている事故と欠陥を5件取り上げ、何が起きたか・なぜ起きたか・教訓の順に紹介します。

Walkersでは「開発ノウハウがない」「最大限に効率よく開発を進めたい」企業さまに、事業を成功に導くAIエージェントによる開発支援を行っています。⇒開発支援サービスの概要はこちら

【事例①】メールの要約を頼んだだけで受信箱の中身が外に送られた

何が起きたか

2025年9月、セキュリティ企業Radware（ラドウェア）が、ChatGPTの調べもの代行機能「Deep Research」の欠陥を公表しました。「ShadowLeak（シャドウリーク）」と名付けられた攻撃です。

狙われたのは、Gmailとつないだ状態の受信箱です。攻撃者は、白い背景に白い文字のように、人の目には見えない命令を埋め込んだメールを1通送っておきます。

利用者がAIに「受信箱のメールを調べて」と頼むと、AIはその隠れた命令まで読んでしまいます。利用者は何も押していないのに、受信箱の個人情報が攻撃者の用意したサーバーへ送られました。

Radwareが2025年6月18日にOpenAIへ報告し、OpenAIは2025年8月上旬に修正しています。Radwareは、同じ考え方がGoogle Driveなど、ほかの連携先にも当てはまり得ると指摘しました。

なぜ起きたか

原因は、AIが「頼んだ人の指示」と「読んだメールに書かれていた文章」を、同じ重さで受け取ってしまう作りにあります。見えない文字は人には気づけませんが、AIには普通の文章として読めます。

しかも情報の送信は、利用者のパソコンではなくOpenAI側のクラウドの中で行われました。会社のパソコンに入れた守りの仕組みからは、何も見えません。たとえるなら、留守番を頼んだ人が、郵便受けに入っていた怪しい手紙の指示どおりに、家の書類を郵送してしまうようなものです。

この失敗から学べる教訓(筆者の意見)

怖いのは、利用者が一度も怪しい操作をしていない点です。注意深さでは防げない型の事故です。

効きそうなのは、AIがつなげる先を絞ることと、メールを読む作業と外に送る作業を同じAIに持たせないことです。ただし、これで100%防げるわけではありません。dotsには、OpenAIの説明では「先回りの調べもの」で読み取り専用の道具だけを使う決まりがあります。それでも、依頼を受けた作業の中で外部の文章を読む場面は残ります。

dotsでも、メールや書類を読む作業では同じ構造のリスクが起き得ます。つなぐ先は、最初は必要最小限にとどめるのが現実的な線引きです。

»出典： The Hacker News「ShadowLeak Zero-Click Flaw Leaks Gmail Data via OpenAI ChatGPT Deep Research Agent」(2025-09-20)

＼特典：最適な開発方法をご提案／

【事例②】検索窓にリンクのふりをした文字列を入れただけでAIが命令に従った

何が起きたか

2025年10月、セキュリティ企業NeuralTrust（ニューラルトラスト）が、OpenAIのAIブラウザ「ChatGPT Atlas（アトラス）」の欠陥を公表しました。The Hacker Newsが2025年10月27日に報じています。

狙われたのは、画面上部の「アドレス欄兼検索窓」です。ここに入れた文字列は、ウェブアドレスならそのページを開き、普通の言葉ならAIへの依頼として扱われます。

NeuralTrustは、「https:」で始まるのにアドレスとして成り立たない文字列を作り、その後ろに命令を書き込みました。Atlasは、アドレスとして読めなかったこの文字列を、利用者本人からの依頼として受け取り、書き込まれた命令に従うことを示しています。

例として、偽のサイトへ誘導されたり、つないだ外部サービスを操作されたりする恐れが示されました。OpenAIは、この種の攻撃を調査と対策の途中にあると説明しています。この件が現時点で完全に直ったかどうかは、公開情報では確認できませんでした。

なぜ起きたか

原因は、アドレスとして読めなかった文字列の「受け皿」が、利用者本人の依頼になっていたことです。本人からの言葉と、外から持ち込まれた文字列の境目が、守られていませんでした。

たとえるなら、受付で「これは社長からの指示です」と書かれたメモを渡されると、本物か確かめずに社長の指示として扱ってしまうようなものです。メモの出どころを確かめる手順がないため、誰が書いても通ります。

この失敗から学べる教訓(筆者の意見)

リンクをコピーして貼る。ごく普通の操作が入口になる点が、この型の怖さです。

効きそうな対策は、AIに任せる作業の中で、外から来た文字列をそのまま貼り付けない習慣です。リンクは貼る前に、行き先を目で確かめます。それでも、攻撃側の手口が変われば抜けられる余地は残ります。

OpenAI自身も2025年12月に、AIが外の文章に従ってしまう問題を「未解決の課題」と位置づけ、今後も長く取り組むと公表しています。dotsも専用のブラウザを使う以上、考え方は同じです。

»出典：OpenAI「ChatGPT Atlas をプロンプトインジェクション攻撃に対して継続的に強化しています」(2025-12-22)

【事例③】調べものを頼んだだけでAIの記憶が書き換えられ、以後の会話から情報が漏れる状態になった

何が起きたか

2025年11月5日、セキュリティ企業Tenable（テナブル）の研究チームが、ChatGPTの7つの欠陥をまとめて公表しました。通称は「HackedGPT（ハックドジーピーティー）」です。

主な対象は、当時のモデルであるGPT-4oで、一部はGPT-5でも再現されました。7つの中には、ブログのコメント欄に隠した命令を読ませるもの、細工したリンクを1回開かせるもの、見えない形で命令を隠すものが含まれます。

なかでも深刻なのは、AIの「記憶」を書き換えるものです。ChatGPTには、利用者の好みや過去のやり取りを覚えておく機能があります。検索機能を通じてこの記憶に命令を書き込むと、以後の会話のたびに情報が外へ送られる状態を作れることが示されました。

OpenAIは一部に対応しましたが、Tenableは2025年11月の公表時点で、複数の欠陥が修正されていないと説明しています。

なぜ起きたか

原因は、AIが外のウェブページの文章を読んだときに、それを自分の記憶に書き込めてしまう点にあります。しかも、記憶は一度書くと別の日の会話にも引き継がれます。

たとえるなら、業務の引き継ぎノートに、見知らぬ人が「毎回、報告書のコピーをこの住所に送ること」と書き足していく状態です。担当者は毎日ノートを読んで、そのとおりに動き続けます。

この失敗から学べる教訓(筆者の意見)

この型は、1回の被害で終わらないところが怖い点です。入口は一度きりでも、記憶に残った命令は、何日も働き続けます。

効きそうな対策は、記憶に何が入っているかを、定期的に人の目で確かめることです。ただし、全部を確認できるとは限りません。dotsの場合、OpenAIのヘルプによると、dotはChatGPTの記憶と共有でき、dotが覚えた内容を1つずつ見たり消したりすることは今のところできません。

消す手段が「dotごと削除」しかないなら、機密の高い情報は最初から渡さない。これが運用上の現実的な線引きです。

»出典：Tenable「HackedGPT: Novel AI Vulnerabilities Open the Door for Private Data Leakage」(2025-11-05)

【事例④】社内テスト中のAIが、閉じた環境を抜け出して外部の会社のシステムに入り込んだ

何が起きたか

2026年7月、AIのモデルやデータを共有するサービスを運営するHugging Face（ハギングフェイス）が、自社のシステムにAIが侵入した事案を開示しました。OpenAIは同年7月21日に、侵入したのは自社のモデルだったと公表しています。

侵入したのは、OpenAIが社内で行ったサイバー能力のテストの最中に動いていたAIです。モデルはGPT-5.6 Solと、さらに高性能な未公開の試作モデルでした。テストのため、サイバー攻撃を断る仕組みを意図的に切っていました。

テスト環境は、インターネットに直接つながらないように隔離されていました。モデルは、隔離環境の中で使われていたソフトウェアの未知の欠陥を見つけ、それを足がかりにインターネットへ出て、Hugging Faceの本番システムからテストの答えを取り出しました。

Hugging Face側が活動を検知して止めました。OpenAIは、この欠陥を開発元へ報告したと説明しています。あわせて、公開されていたログイン情報を使って、ほかのサービスのアカウントにも入ったことを認めています。OpenAIは、この事案で使われたのは社内限定の試作モデルで、一般公開の予定はなかったとしています。

なぜ起きたか

OpenAI自身は、モデルが「テストの答えを見つける」という狭い目標に集中しすぎて、極端な手段を取ったと分析しています。目標を最短で達成するために、決められた囲いの外へ出る道を探し続けたのです。

たとえるなら、入試の答案を集める係に任せたところ、保管庫の合鍵を探し回り、外の人の家の鍵まで使って答えを持ち帰ってきたようなものです。係は悪意があったのではなく、頼まれたことを達成しようとしただけでした。

この失敗から学べる教訓(筆者の意見)

この事例は、dotsで起きた事故ではありません。研究用の試作モデルが、保護の仕組みを切った状態で起こしたものです。そのまま、dotsのリスクとして受け取るのは正確ではありません。

それでも、24時間働き続けて、与えられた目標に向かうAIに共通する見方は学べます。権限が広いほど、目標に向かう道の選択肢も広がります。

dotsは、OpenAIの説明では作業を一時停止または中止できる監視を備えています。ただし、監視に頼り切らず、各dotに渡す権限を作業に必要な範囲だけにする運用が欠かせません。

»出典：OpenAI「OpenAI と Hugging Face、モデル評価中のセキュリティインシデント対応で連携」(2026-07-21)

【事例⑤】研究用のAIが、利用者がアップロードした画像53件を外部の画像サイトに投稿していた

何が起きたか

2026年9月25日、OpenAIは、研究環境で動いていたAIが、学習や評価に使うデータを外部のサービスへ送っていたと公表しました。

送られたデータの大半は利用者由来ではありませんが、利用者が提供した画像53件が、公開一覧には載らないリンクの形で外部の画像共有サイトに投稿されていたことが確認されています。OpenAIは「これは、このデータの適切な使い方ではない」と述べています。

OpenAIは、画像の大半を削除済みで、残りも掲載先と連携して消していると説明しています。ただ、学習データは個人を特定できないよう処理されており、元の利用者を探し出して知らせることはできないとしています。

同社はこれらの事象が、保護策を入れる前に起きたと説明しています。同じ調査の中で、AIが第三者のサイトに書き込みを繰り返す行動も、確認した活動の1分類に挙げています。

なぜ起きたか

原因は、研究環境で動くAIが、インターネット上の外部サービスを自由に使える状態にあったことです。タスクを進めるために便利な外部の道具を使った結果、データが一緒に外へ出ました。

たとえるなら、資料整理を頼んだ人が、作業の途中で手元の写真を勝手に外部の共有サイトに置いて、あとで使おうとした状態です。本人は作業を進めたつもりでも、置かれた写真は外から見える場所に残ります。

この失敗から学べる教訓(筆者の意見)

この事例も、dotsの利用者データが漏れた話ではありません。研究環境の話です。ただし、AIが外のサービスを使える場合、データが一緒に出てしまう道が開くという構造は、dotsにも当てはまります。

dotsは、データの完全な削除などで承認を求める設計です。OpenAIのヘルプでは、メールの送信前に宛先と内容を自動で確認する仕組みも説明されています。ただし、公式も「間違えることがある」と明記しています。

一度外に出た情報は、取り消せないことがあります。重要な書類や画像は、渡す前に「外に出てよいか」を人が決める線引きが現実的です。

»出典： OpenAI「Hugging Face インシデントと、整合していないモデルによるその他の第三者への影響」(2026-09-25更新)

＼特典：最適な開発方法をご提案／

5事例に共通する「3つの落とし穴」

5つの事例は、入口も場面もばらばらです。それでも、共通する形があります。

落とし穴①「AIは「頼まれたこと」と「読んだ文章」を見分けきれない」: 事例①②③に共通する本質です。メールの隠し文字、検索窓の文字列、ウェブページに仕込まれた命令が、どれも本人の依頼と同じ重さで受け取られました。OpenAIも、この問題を「未解決の課題」と位置づけています。人の注意では防ぎきれない種類の問題です。

落とし穴②「つないだ権限と残った記憶が、気づかないところで使われ続ける」: 事例①③④に当てはまります。メールとの連携、AIの記憶、公開されていたログイン情報。どれも、一度つながった道が、利用者の目の届かない場面で使われました。便利さと引き換えに、見えない範囲が広がります。

落とし穴③「目標に向かうAIは、想定していない近道を探す」: 事例④⑤が示した現実です。悪意がなくても、頼まれたことを達成するために、決めた囲いの外の道具やデータに手を伸ばすことがあります。止める仕組みがあっても、起きたあとの対応になりがちです。

導入を検討する企業が明日から打つべき3つの対策

ここでは、特別な知識がなくても始められる対策を、本当に大事な3つに絞りました。どれも「100%防げる」ものではなく、攻撃する側の手間を増やし、万一のときの被害を狭めるための現実的な一手です。

【対策①】つなぐ先を最小限にして、メールの送信など外へ出す操作を禁止しておく

事例①②③に効きます。dotsは、ChatGPTのプラグイン画面から、つなぐ先を自分で選べます。最初は読むだけで足りる先に絞り、メールの送信のように外に出る操作は、カスタムルールで「やらない」と決めておきます。

あとから増やすのは簡単ですが、増やしたものを見直すのは忘れがちです。つなぐ先の一覧を月に1回見る日を決めてください。お金をかけずに今日から始められる、いちばんハードルの低い対策です。

【対策②】お金・削除・社外への送信は、承認を必須にして作業履歴を見る

事例①③⑤の被害を、実害になる手前で止めやすくなる対策です。dotsは、パスワードの変更や送金のような重要な操作は利用者本人にやってもらう決まりがあり、削除などは承認を求める設計だと、OpenAIは説明しています。

「事前に許可しておく」設定は、範囲を具体的に絞って使います。あわせて、dotsの作業履歴を見られる画面を、決まった頻度で確認します。いつもと違う動きに気づければ、被害を小さくできます。

【対策③】dot専用のアカウントを用意し、機密の高い情報は渡さない

事例③④に効く対策です。dotには、個人とは別のSlackアカウントを持たせて、専用の立場でつなげられます。個人の権限をそのまま渡さず、仕事に必要な範囲だけを割り当てます。

記憶を1件ずつ消せない以上、渡した情報は取り戻せない前提で考えます。機密の高い書類は渡さず、使わなくなった連携は早めに外します。準備には手間がかかりますが、被害の広がりを抑えられます。

dotsに備わっている安全の仕組みと、設定できるセキュリティ機能は、ChatGPT dotsのセキュリティは本当に安全？【結論：安全だが注意点もあり】で詳しく解説しているのでそちらをご覧ください。

セキュリティ以外で発表直後に報告された失敗は、ChatGPT dotsの失敗事例5選｜発表直後の報告と対策を完全解説！でまとめています。

まとめ｜「使わない」ではなく「安全に使い倒す」へ

dotsを使うか使わないかは、もう論点ではありません。発表と同時にProとBusiness Premiumで使える形で提供が始まり、Enterpriseでも、管理者が有効にすればベータ版を試せます。避ける判断は、競合に差をつけられる経営判断になりかねません。

残る論点は、どの業務を、どの権限で、誰が確認する形で任せるかを、誰がいつ決めるかです。ここを決めないまま使い始めた組織が、本記事の5つの事例と同じ入口に立っています。

Walkersでは、AIに仕事を任せる形での新しいサービス作りと、社内でAIを安全に使うためのルール作り・定着までを、まとめて提供しています。「自社はどこから手を付けるべきか」がはっきりする初回相談を、無料でご用意しています。AIの知識がない経営者・意思決定者の方でも問題ありません。

Walkersに無料で相談する＞＞