THREAT BRIEFING · AI アシスタントへのプロンプトインジェクション
Tenable Research（Liv Matan）が2025年9月30日に公表した研究を一次情報とする。同社は3件をまとめて「Gemini Trifecta」と名づけ、いずれも修正済みと記載している。本記事は2026年8月9日時点の取得に基づき、判断は一次情報の本文テキストによる（同社が公開している実証動画3本は検証していない）。
「3つの脆弱性が Gemini からデータを盗んだ」と読まれた事案である。だが一次情報を読むと、3件はそもそも同じ問いを検証していない。
最初に、誤読を防ぐための否定
これは実際に誰かが被害を受けた事件ではない。研究者が自分の環境で組み立てた実証であり、一次情報に登場する被害者はすべて「模擬被害者（mock victim）」である。野良での悪用も、実在の被害組織も、CVE の採番も、一切主張されていない。
同時に、逆方向の誤読もある。「Gemini には防御がなく、素通りだった」というのも正確ではない。後述するとおり、素直なプロンプトインジェクションはモデル側の判定に実際に弾かれている。これは一次情報が自分から書いていることである。
出典自身の枠組みは、記事冒頭の一節に置かれている。
Gemini Trifecta が示すのは、AI がそれ自体、標的であるだけでなく攻撃の乗り物にもなりうるということである。
本記事が重要だと考えるのは、この総称が覆い隠しているものである。3件は同じ問いを検証していない。#1 と #2 が確かめたのは「外部のシステムに置いておいた文を、Gemini が指示として読んでしまうか」であり、答えはどちらも「読んだ」である。#3 が確かめたのは「Gemini から機微データを外部へ出せるか」であり、答えは「出せた」である。3件とも、それぞれの問いには成立している。
揃っていないのは、その先である。記事の表題と概要は3件すべてを「データの持ち出し」として掲げているが、持ち出しが実際に起きたと実測されているのは #3 だけで、#1 と #2 に付された被害記述は条件法で書かれている。ずれているのは実証結果ではなく、実証結果と、そこに付けられた被害の見立てとのあいだである（第2節）。
同時に、本記事が抑制する主張
「実証が浅いのだから騒ぐほどではない」——この読み方は採らない。#1 と #2 は、Gemini が外部由来のデータを指示として読むことを実際に示している。それ自体が修正に値する欠陥であり、現に Google は3件とも修正したと記載されている。しかも注入の入口となるこの2件は、いずれも被害者を騙して何かを開かせる必要がない。本記事が線を引くのは、実証された結果と、そこから先の推定とのあいだである。
入口を試した2件と、出口を試した1件。3件とも、それぞれの問いには答えが出ている。
一次情報は3件を横並びには扱っていない。#1 と #2 は「侵入（infiltration）」の節に、#3 は「持ち出し（exfiltration）」の節に分けて書かれている。指示を入れる経路と、データを出す経路という違いである。
ただし、ここは誤解しやすい。3件はそれぞれ独立した実証である。#3 の前提として一次情報が置いているのは「悪性のプロンプトが注入されていること」であって、その注入が #1 や #2 である必要はない。原文は「直接であれ間接であれ（either directly or indirectly）」と明示しており、実際に #3 の節で示されている試験プロンプトは、研究者が Gemini に直接与えたものである（「我々は Gemini に…と頼んだ」「我々は次のような試験プロンプトを作成した」）。
出典は「プロンプトインジェクションの成功と組み合わせれば、侵入から持ち出しまでの信頼できる攻撃経路になる」と述べている。だがこれは組み合わせた場合の見通しの表明であって、連鎖を実演したという報告ではない。本文に、#1 または #2 の注入から #3 の持ち出しまでを続けて実行したという記述はない。
そのうえで、3件が「何を確かめ」「何が起き」「概要でどう説明されたか」を並べると、ずれの在りかがはっきりする。
3件の概要を述べる箇所で、Tenable は助動詞を書き分けている。#1 は「攻撃者がクラウドサービスを悪用することを可能にしえた（could have enabled）」、#2 は「保存情報と位置情報を漏らしうる（potentially leak）」、そして #3 だけが「攻撃者が持ち出すことを可能にした（allowed attackers to exfiltrate）」である。
脅威の大きさを訴えたい事業者であれば、3件の語調を揃えるほうが自然である。揃えなかったという事実は、この区別が意図的であることを示している。
最も影響が大きいとされたシナリオは、実証されていない
#1 について一次情報が挙げる最大の想定被害は、「Gemini に公開アセット全件や IAM の設定不備を問い合わせさせ、その結果を含むハイパーリンクを作らせる」というものである。だがこれは実演の報告ではない。原文は「これは可能なはずだ（This should be possible）」という条件法で書かれている。「クラウド資源が奪われることが示された」という要約は、一次情報を超えている。
Gemini Cloud Assist はメタデータを要約していたのではなく、生ログから直接引いていた。
攻撃者は、公開されている GCP のサービスに HTTP リクエストを1本送る。その User-Agent ヘッダに指示を書いておく。値は自然に Cloud Logging に流れ込み、あとは利用者がログを Gemini に要約させるのを待つだけである。
"}}, で閉じてから指示を書く、という手法が使われている。ただし注入文の逐語は一次情報では画像として掲載されており、テキストとしては確認できない。発火の条件は特別なものではない。Log Explorer の「Explain this log entry」ボタンを押すか、あるいは「直近の Cloud Function の実行は？」「一部の利用者でうまく動かないのですが、原因を調べてもらえますか」といった、ログを見に行かせる普通の質問でよい。
影響範囲について、一次情報は User-Agent の注入が可能な GCP サービスを10種挙げている（Cloud Functions、Cloud Run、App Engine、Compute Engine、Cloud Endpoints、API Gateway、Load Balancing、Pub/Sub、Cloud Storage、Vertex AI Endpoints）。ただし原文は「これらの一部（Some of these）」と書いており、これは例示であって網羅ではない。
ここで注意が要るのは、前掲の「最大の想定被害」が実証と地続きに読まれやすいことである。実際に確認されたのは、要約に攻撃者の文とリンクが載るところまでである。
Gemini が読むのは検索履歴である。ならば、検索履歴に書き込めばよい。
Gemini の Search Personalization Model は、応答を利用者の検索履歴に合わせて調整する。つまり検索クエリは、Gemini にとって処理対象のデータである。一次情報の言い方では「検索履歴は受動的な文脈ではなく、能動的な入力だ」ということになる。
書き込みの手口は素朴だが巧妙である。悪性サイト上の JavaScript が Google 検索へのページ遷移を開始し、履歴に記録されるだけの時間を待ってから、遷移そのものを取り消す。被害者の画面は攻撃者のサイトのままだが、検索履歴には攻撃者の文が残る。
一次情報が根本原因として挙げているのは、機能の不具合ではない。「正規の利用者クエリと、外部から注入されたプロンプトを、モデルが区別できなかったこと」である。
なお #1 と #2 に共通する性質として、出典は「従来の間接プロンプトインジェクションに比べ、見えにくく、持続的で、ソーシャルエンジニアリングをほとんど必要とせず、検知がはるかに難しい」と述べている。これは Tenable による比較主張であり、独立した検証はない。
最初の試みは失敗している。それを書いているのは、ほかならぬ Tenable である。
Gemini の Browsing Tool は、外部の URL を取得して要約する機能である。ならば、機微なデータをクエリ文字列に載せた URL を「要約して」と頼めばよい——というのが着想である。
だが、素直にやると失敗した。
利用者の保存情報を送信し、外部サイトを訪問するよう Gemini に指示するプロンプトインジェクションの試みは失敗に終わった。Gemini がこの挙動を不自然であり悪性でありうると気づいたためである。
通ったのは、書き方を変えてからである。研究者は Gemini の「Show thinking」表示を見ていて、Gemini がブラウジング時に内部で使っている呼び出しの形式を知った。そこで、その形式を真似たプロンプトを Gemini に直接与えた。url= と query= を持つ呼び出しの形に、攻撃者のドメインと、保存情報を埋め込むためのプレースホルダを置いたものである。第2節で述べたとおり、ここで使われているのは #1 でも #2 でもなく、直接の注入である。
結果として Gemini はプレースホルダを実際の値に置き換え、攻撃者のドメインへ外向きの HTTP リクエストを行った。そして——3件のうち、データが実際に外へ出たのはこの1件だが——研究者はそのリクエストをサーバ側で受け取り、模擬被害者の機微データが含まれていることを確認している。
この経路には、利用者から見て不審な表示が伴わない。リンクも画像も描画されないまま、通信だけが起きる。
出典は、Google の既存対策を高く評価している
「Google は、画像マークダウンやハイパーリンクの描画といった既知の持ち出し手法をよく塞いでおり、外部エンドポイントへのデータ持ち出しは容易ではなかった」——これも一次情報の記述である。批判記事の体裁を取っていない点は、この出典を読むうえで押さえておく必要がある。
「対策が甘かった」では説明がつかない。作動した防御と、作動しなかった防御がある。
一次情報は、研究に着手する前に観測した Gemini の防御を3つ挙げている。マークダウン内のリンクは google.com のアドレスへ書き換えられる。疑わしい出力は切り詰められる。そして——プロンプトインジェクションのパターンを検知すると、Gemini が応答自体を拒否することがある。
最初の2つは出力の描画に関わる対策だが、3つ目は違う。これはモデルの挙動そのものに関する判定であり、前節で見たとおり実際に作動して最初の試みを弾いている。
したがって #3 が成立した経緯は、一段ではなく二段である。
Google 自身は、本件の3か月半前にあたる2025年6月に、プロンプトインジェクションへの多層防御について公表している。そこで挙げられた5層には、マークダウンのサニタイズと不審 URL の伏字化（描画層）と、プロンプトインジェクションの分類器（モデル層）の両方が含まれる[2]。Tenable が観測した防御の構成と符合する。
ただしこの文書は本件に一切言及していない。公表が本件より前であり、Tenable もこれを引用していない。両者を並べられるのは「Google の防御が多層で設計されていた」という点までであって、本件への対応を Google が説明した記録ではない。
一次情報が記載する Google の対応は3つである。#1 についてはログ要約の応答でハイパーリンクを一切描画しなくなった。#2 については脆弱なモデルをロールバックし、多層のプロンプトインジェクション防御を用いる。#3 については、間接プロンプトインジェクションにおけるブラウジングからの持ち出しを防ぐようになった。
#1 の修正は描画層の対策である。ここで「#3 が破ったのと同じ層ではないか」と読みたくなるが、一次情報に照らすとその含意は成り立たない。#1 について記述されている持ち出し経路は、実証された分（要約へのリンク挿入）も、想定された最大被害（資産情報を含むハイパーリンクの生成）も、いずれもハイパーリンクを経由する。描画の停止は、その両方に正面から対応している。
なお Cloud Assist が外部を取得する系のツールを持つかどうかは、一次情報に記載がない。本記事はこの点を判断しない。
この事案は、書かれていないことの量が多い。
| 論点 | 一次情報の記述 |
|---|---|
| 実世界での悪用 | 記述なし。全編が Tenable 自身の実証であり、被害者はすべて「模擬被害者」である |
| 実被害・影響利用者数 | 記述なし。「数百万人が影響を受けた」という規模の数字は一次情報のどこにもない |
| CVE | 採番なし。一次情報にも、確認した二次報道にも識別子の記載がない |
| 開示のタイムライン | 記述なし。Google への報告日も、修正が入った日も分からない |
| 修正の検証 | 「修正済み」の記載はあるが、実施日・検証方法・有効範囲のいずれも書かれていない |
| 3件の連鎖 | 本文には、#1 または #2 の注入から #3 の持ち出しまでを続けて実行したという記述がない。3件はそれぞれ別個の実証であり、#3 の試験プロンプトは直接与えられている |
| 試行の分母 | 記述なし。何件試して3件が通ったのかは分からず、この3件から Gemini 全体の状態は論じられない |
| 記事の改訂内容 | 公表8日後（2025年10月8日）に更新されているが、何が変わったかの告知がない |
| #1 の注入文 | 画像としてのみ掲載されており、逐語をテキストとして確認できない |
流通している見出しへの否定
「数百万人をサイレントなデータ侵害にさらした」——この規模の数字は一次情報に存在しない。該当する報道の本文自体も「数百万の利用者をリスクにさらした」と書いており、侵害が起きたとは述べていない。見出しだけが独り歩きしている。
「3件ともデータが盗まれた」も誤りである。持ち出しがサーバ側で実測されたのは #3 のみで、#2 は被害者のクリックを要し、#1 で実際に起きたのは要約へのリンク挿入である。ただし逆に「#1 と #2 は失敗した」と読むのも誤りで、この2件が確かめたのは注入が通るかであり、どちらも通っている。
掲載媒体の数は、情報源の数ではない。
本件は多数の媒体に載った。だがそのすべてが Tenable のブログに由来する再配信であり、独自の検証を伴うものは確認できていない。したがって本件について「複数の情報源が一致している」と書ける事項はない。
Google の対応についても同じである。前節で引いた3項目は、Tenable のブログの中に書かれている記述であって、Google 名義の公表文書ではない。Google のアドバイザリ、ブログ、広報コメントのいずれも確認できなかった。確認した範囲（The Hacker News、Infosecurity Magazine）でも、Google が各媒体に直接コメントした形跡はない。ただし Dark Reading の記事は取得できておらず、「どの媒体にもコメントがない」とまでは言えない。
もう一点、本記事自身の限界を明示しておく。Tenable は実証動画を3本公開しており、本記事はこれを検証していない。とくに #1 の動画の説明文は本文より踏み込み、「攻撃者は最終的に被害者の認証情報をフィッシングする」と述べている。さらに別の動画の説明文は、JavaScript で被害者の閲覧履歴を操作し、悪性サイトを訪問させ、Gemini に悪性プロンプトを注入し、そして被害者のデータを持ち出すまでを一続きに述べており、本文には書かれていない連鎖を示唆している。動画が本文以上の実証を含んでいる可能性は排除できない。本記事の中心的な主張——各件の実証結果と、概要が掲げた被害とのずれ——が組み替えになるとすれば、その最初の一撃はここから来る。
出典の立場について、両方向とも断定しない
Tenable は AI とクラウドのセキュリティ製品を販売する事業者であり、この記事は自社サービスへの案内で終わっている。脅威の重大性評価に事業上の利害があることは、記録しておくべき事実である。
一方で、この記事には自社に不利な記述が複数ある。素直な注入が失敗したこと、Google の既存対策を高く評価していること、#2 の手法に文字数や文字種の制約があったこと、履歴の記録条件に「ようだ」とヘッジを付けていること。したがって「利害が記述を歪めた」という主張も、同じくらい根拠を欠く。本記事はどちらも断定しない。
「Gemini Trifecta」は Tenable の命名であり、語感としてよくできている。だが3件を一語で束ね、表題に「データ持ち出し」を掲げた結果、3件がそれぞれ別の問いを検証していたことが見えなくなった。#1 と #2 が示したのは「Gemini が外部由来の文を指示として読む」ことであり、これは十分に重い発見である。#3 が示したのは「データを外へ出せる」ことである。原文が #3 にだけ「可能にした」と書き、他の2件に「しえた」「しうる」を使っているのは、この違いに対応している。名前が付いた事案ほど、原文の語調を確認する価値がある。
この事案で見落とされやすいのは、Gemini のモデル側の判定が実際に作動して最初の攻撃を弾いたという一点である。破られたという話より地味だが、意味は大きい。攻撃が成立したのは、判定を強行突破したからではなく、モデル自身が使う内部呼び出しの語彙を借りて、判定の対象に見えない形にしたからである。「AI に指示を弾かせる」対策を評価するときは、弾ける表現の範囲がどこまでかを問うことになる。
Google が既に敷いていた持ち出し対策は、画像やリンクを描かせない方向のものだった。#3 が抜けたのは、ツールの実行が描画を経由しないからである。生成 AI の機能追加を審査する立場からは、「出力に何が表示されるか」と「モデルが何を実行できるか」を別の審査項目として持つことが、この事案から取れる最も具体的な示唆になる。ただし出典自身も「UI レベルの防御の“多く”を迂回する」と限定して書いている。
本件は3件とも修正済みとされている。だが修正の日付も、検証の方法も、有効範囲も公表されていない。しかもその記述自体が、発見者側の文書の中にしか存在しない。EchoLeak には CVE があり、ベンダーによる深刻度評価があり、顧客への影響がなかったことを Microsoft が自ら確認していた。同じ「AI アシスタントからの持ち出し」でも、検証できる材料の量には大きな差がある。読者に対して確度を落として提示すべきなのは、攻撃手法の巧妙さではなく、この修正状況のほうである。