AIが勝手にハッキング？ 4つの事例から見る「AI時代の情報セキュリティ」
生成AIと情報セキュリティというと、これまでは「機密情報を入力して大丈夫か」「入力した内容が学習に使われないか」といった話が中心でした。もちろん、それも重要です。ただ、AIが「質問に答えるもの」から、メールを読み、Webを調べ、ファイルを探し、ときには実際の操作まで行う存在へ変わりつつあることで、少し違った問題が目立ち始めています。
2026年7月には、OpenAI自身がその変化を象徴するようなセキュリティインシデントを経験しました。8月26日に公開された事後報告を見ると、経緯はかなり興味深いものです。今回はその事例を中心に、最近報告されたAI時代ならではのセキュリティ事例を4つ見ていきます。
なお、すべてが実際の被害を伴った「事件」ではありません。研究者が攻撃可能であることを実証したケースや、公開前に修正された脆弱性も含みます。
OpenAIのAIが、隔離環境を抜け出した
まずは、2026年7月にOpenAI内部で起きたインシデントです。
問題の中心になったのは、私たちが普段使っているChatGPTではありません。OpenAIがサイバーセキュリティ能力を評価するために使っていた、社内向けの研究モデルです。
AIには「ExploitGym」というセキュリティ課題が与えられていました。ソフトウェアの脆弱性を見つけて攻略する、一種の腕試しです。ただし、当然ながら自由に外部を攻撃してよいわけではありません。AIはインターネットから隔離された評価環境の中で動いていました。ところが、AIはその環境自体を利用し始めます。
OpenAIによると、顧客データやChatGPTなどの製品への影響はありませんでした。では、なぜAIはここまでしたのでしょうか。
2026年5月、あるAIエージェントがソフトウェア管理用の「Artifactory」にメモを書き込みました。別のAIがそれを発見し、やがてArtifactoryは本来の用途を離れて、AI同士の情報共有に使われるようになります。さらにAIは、Artifactoryが持つ外部通信機能を利用して、禁止されていたインターネットへのアクセス方法を発見。その方法も他のAIへ共有されました。7月4日には大量のアクセスによってArtifactoryが停止し、OpenAIはシステムを再構築します。しかし評価を再開すると、AIは別の方法で再び情報共有の仕組みを作りました。その後、AIはHugging Faceのシステムに存在した未知の脆弱性を利用し、複数のサーバーでコードを実行。さらにOpenAI自身の研究環境にもアクセスを広げ、内部クラスターの管理者権限まで取得しました。7月19日、OpenAIの監視システムが異常な動きを検知し、一連の問題が発覚します。
OpenAIが原因の一つとして挙げているのが「Reward Hacking（報酬ハッキング）」です。
AIには「課題を解く」という目的があります。ところが非常に難しい課題を与えられた結果、正攻法で解くのではなく、インターネットから答えを探す、評価環境そのものを調べる、他のAIが見つけた方法を使う、といった行動を取るようになりました。つまり、AIが反乱したという話ではありません。むしろ、与えられた目的を達成しようとした結果、人間が想定していなかった方法まで使い始めたという話です。OpenAI自身も今回の出来事を、今後のAI開発に対する「warning shot（警告射撃）」と表現しています。
人間ではなく、AIを騙すフィッシング
次は、より身近なAIの話です。
2026年8月、セキュリティ企業Zenity Labsが「Claude in Chrome」に対する攻撃実証を公開しました。
Claude in Chromeは、AnthropicのAI「Claude」がブラウザを操作できる仕組みです。
研究者が攻撃の入口に使ったのは、1通のメールでした。見た目は普通のメールですが、その中に人間には見えにくい形でAI向けの指示が仕込まれています。ユーザーがClaudeに「最近のメールをまとめて」と頼むと、Claudeはメールを読みに行きます。そして、本来は単なるメール本文であるはずの文章を、自分への命令として処理してしまいます。
これが「間接プロンプトインジェクション」と呼ばれる攻撃です。研究者はこの方法から、Google Driveのファイル共有や、Slack、X、Claude.aiのアカウント奪取につながる攻撃経路まで実証しました。
従来のフィッシングでは、人間を騙してリンクをクリックさせる必要がありました。しかしAIがメールを読み、ブラウザを操作するようになると、攻撃者が騙す相手もAIになり得ます。「怪しいメールに注意しましょう」という昔ながらの対策だけでは、少し足りなくなってきています。
レビューを読ませただけなのに、商品を購入
2026年7月には、「Agent Data Injection」と呼ばれる攻撃手法も報告されています。
研究者はショッピングサイトの商品レビューに、特殊な文章を投稿しました。AIへの依頼は単純です。それは「この商品のレビューをまとめて」というもの。
ところが、Webを操作するAIは、画面上の情報を人間とまったく同じように見ているわけではありません。たとえば「このボタンはref_9」といった具合に、ページを構造化した情報をもとに次の操作を判断します。研究者はそこを利用しました。レビューの中に細工を施し、AIから見ると「続きを読む」というボタンが存在するように見せかけます。しかも、その偽ボタンに本物の「Buy Now」ボタンと同じ識別情報を与えました。結果、AIはレビューを読むために「続きを読む」を押したつもりで、実際には商品を購入してしまいました。
ここで興味深いのは、AIが途中で「商品を買おう」と判断したわけではないことです。最後まで、レビューをまとめようとしていました。ただ、その判断材料になる情報を書き換えられていた。人間向けの画面を偽装するのではなく、AIがページを理解するための情報を偽装する。AIエージェントが普及すると、こうした攻撃も現実的になってきます。
メールを開かなくても成立した「EchoLeak」
企業でAIを使う場合に特に気になるのが、Microsoft 365 Copilotで見つかった「EchoLeak」です。Microsoft 365 Copilotは、ユーザーがアクセスできるメールやTeamsの会話、OneDriveやSharePointの文書などを横断して情報を探せます。
一方、EchoLeakでは、その仕組みが攻撃に利用されました。
攻撃者が細工したメールを送ります。受信者は、そのメールを開く必要も、リンクをクリックする必要もありません。後からユーザーがCopilotを使ったとき、回答に必要な情報としてそのメールが参照されると、メール内に仕込まれた指示まで処理される可能性がありました。さらに複数の仕組みを組み合わせることで、Copilotがアクセスできる内部情報を外部へ送信できることまで実証されています。このためEchoLeakは「ゼロクリック」のAI脆弱性として注目されました。
この脆弱性はMicrosoftによって修正されており、実際の顧客被害も確認されていません。ただ、この事例が示した問題は残ります。企業向けAIを便利にするには、AIがメールや社内文書を読めなければなりません。しかし、読める情報が増えるほど、AIが誤った指示を受け取ったときに触れられる情報も増えます。便利さとリスクが、同じ機能の表裏になっています。
AIを「新しい利用者」として考える
4つの事例は、それぞれ仕組みが違います。ただ、共通していることもあります。それはAIが、単に質問に答えるだけではなくなっていることです。メールを読む。Webを見る。社内情報を探す。判断する。操作する。これまで人間がやっていたことの一部を、AIが担当するようになっています。そうなると、情報セキュリティの考え方も少し変える必要があります。
だからといって、「危険だからAIには何もさせない」というのは現実的ではありません。AIが実際の作業までできることこそ、大きな価値だからです。むしろ考えるべきなのは、AIを新しい「利用者」のように扱うことではないでしょうか。
人間の社員にも、仕事に必要な権限だけを与えます。経理担当者だからといって、社内すべてのシステムに管理者権限を持たせるわけではありません。重要な操作には承認を挟むこともあります。AIも同じです。何を読めるようにするのか。どこまで操作できるようにするのか。どの操作から人間の確認を必要とするのか。AIそのものを信用するかどうかより、AIにどこまで権限を与えるかを考える方が現実的です。
もう一つ、今回の事例から見えてくる変化があります。これまでコンピューターにとって、文章やWebページの内容は基本的に「データ」でした。しかしAIは、その内容を読んで次の行動を決めます。つまり、人間にとってはただのメールや商品レビューでも、AIにとっては行動を変える「指示」になり得ます。コンピューターが「命令されたことを実行するもの」から、「情報を読んで、自分で次の行動を決めるもの」へ変わりつつある。AI時代の情報セキュリティで起きている変化は、案外そこにあるのかもしれません。