サイトの記録を読むAI機能を、有効にしてよいか

記録に仕込まれた指示で、AIの機能がデータを外へ送った報告

2026年4月7日、セキュリティ企業のNoma Securityは、監視の道具として使われるGrafanaのAIの機能に対する攻撃（GrafanaGhost）を報告しました。使われたのはプロンプトインジェクション（AIに読ませる文章の中へ指示を紛れ込ませ、動作を乗っ取る手口）です。研究者は、外の人が入力でき、製品のデータとして保存されて後からAIに読み込まれる場所を見つけ、そこへ指示を仕込みました。

仕込んだ指示は、機密のデータをURLに含めた画像を、AIに表示させるものです。画像を表示するとき、ブラウザはそのURLへ読み込みの要求を送ります。URLの先が攻撃者のサーバーなら、要求に載ったデータが攻撃者の手元に届きます。Nomaによると、研究者はGrafanaの側の制限の抜け道を見つけ、データを外へ送れたとしています。

Nomaは、攻撃にはログインも罠のリンクも不要で、利用者の操作なしに、背後で自律的にデータが外へ送られたと主張しています。一方、GrafanaのCISO（情報セキュリティの責任者）は報道機関のCyberScoopへのメール（外部サイト）で、この主張のうち、利用者の操作が要らないという点と、背後で自律的に動くという点を否定しました。成功には、AIが利用者に悪意のある指示を知らせた後も、利用者が、AIにその指示に従うよう繰り返し求める必要があったとしています。実際に悪用された証拠は無く、Grafana Cloudからデータは漏れていないとも述べています。

Grafanaは問題を修正しました。ただし、Grafana自身の公表は見つからず、Grafanaの説明は報道が引用したものです。どちらの説明が正しいかを第三者が確かめた資料も、見つかっていません。両社の説明が重なるのは、保存された内容に含まれた指示をAIの機能が読む、という点です。

同じ形は、別の製品でも報告されている

画像の読み込みを使って外へ送る形は、Grafanaに限りません。OpenAIは2026年7月6日、macOS版のCodexのデスクトップアプリの脆弱性（CVE-2026-14898）を公表しました。アプリは、AIの返答に含まれる外部の画像を表示していました。信頼できない内容に仕込まれた指示でAIが機密のデータを含む画像のURLを作ると、アプリは表示のときにそのURLを自動で読み込んでいました。利用者が別にクリックしなくてもデータが攻撃者のサーバーへ送られるおそれがあった、とOpenAIは書いています。

修正は、返答の中の外部の画像を読み込まないようにすることでした。実際に悪用された例は知られていません。

セキュリティの指針をまとめるOWASPも、プロンプトインジェクションの解説（外部サイト）で、隠れた指示でAIにURLへつながる画像を差し込ませ、非公開の会話を持ち出す場面を例に挙げています。この例は想定の場面で、実際の事件ではありません。

3つの条件がそろうと、外へ送る経路ができる

開発者のSimon Willison氏は2025年6月、AIが「非公開のデータに届く」「信頼できない内容を読む」「外部と通信できる」の3つを併せ持つと、攻撃者はデータを読ませて自分へ送らせやすくなると整理しました。同氏が主に念頭に置いているのは、道具を自分で組み合わせて使う利用者です。同氏の整理を、サービスに組み込まれたAIの機能を有効にするかの判断に当てはめるのは、当方の判断です。

同氏は、外部と通信する手段に、API（別の仕組みとデータをやり取りする窓口）への要求だけでなく、画像の読み込みや、利用者にクリックさせるリンクも含めています。GrafanaとCodexの例は、どちらも画像の読み込みでした。

WordPressのサイトでは、アクセスログの一部の欄は、アクセスしてきた側が中身を決められます。どの欄がそれに当たるかは、ログをAIに読ませて調べるときの注意で扱っています。

提供元の対策だけでは、経路を外しきれないことがある

提供元も、外へ送る経路を塞ぐ対策を入れています。Nomaの報告では、GrafanaGhostでも最初の試みは、画像のURLを検査して外部のドメインの画像を読み込ませない仕組みで止められました。ところが同社によると、ブラウザ側のこの検査は、同じサイトの中を指すURLかどうかを、URLが「/」で始まるかで判定していました。研究者は、この判定を通りながら実際には外部のドメインを指すURLを使い、確認をすり抜けたとしています。

AI自身の安全策も、Nomaの報告では回避されています。AIは、画像を含む指示を攻撃のおそれがあるとみなして拒みましたが、研究者は指示に特定の語を入れることで拒否を避けられたと書いています。OWASP（外部サイト）も、プロンプトインジェクションを確実に防ぐ方法があるかは分からないとしています。

ここからは当方の判断です。提供元が入れた対策も、GrafanaGhostのように、すり抜けられることがあります。修正の前か後かにかかわらず、URLを選り分ける対策に頼らず、返答の画像の表示そのものをやめる作りや設定があるかを確かめておく必要があります。

有効にする前に、提供元に確かめること

次の項目を、提供元の説明書や問い合わせで確かめます。答えが得られない項目は、当てはまるものとして扱います。

• AIが読む範囲：どの記録やデータを読むか。外の人が書いた文章や、外に出したくないデータが入るか。読む範囲を絞れるか。
• 返答の画像やリンクの扱い：返答に含まれる画像を自動で読み込むか、外部へのリンクを出すか。返答に画像を一切表示しない設定や、リンクを出さない設定があるか。
• 外への接続と操作：AIが外部のサイトへ接続したり、メールを送ったり、外から見える場所へ書き込んだりできるか。できる操作を絞れるか。
• 機能を切れるか：AIの機能だけを止められるか。止めたときに、ほかの機能に影響が出るか。

この記事の説明が当てはまらない場合

AIの機能が外部へ接続できず、メールの送信や外から見える場所への書き込みもできず、返答に画像もリンクも出さない作りなら、返答が外へ届く手段を持つという条件が欠けます。読む中身が社内の人の書いた文章だけで、外の人が書いた文章が入らない場合は、外の人が書ける文章を読むという条件が欠けます。条件が欠けて閉じるのは、この記事が扱う、外へ送る経路だけです。ただし、アクセスログや問い合わせのように、外の人の文章が混ざる記録があるため、読む範囲は実際の中身で確かめます。

AIの機能がWordPressの保存するデータを読む場合、サイトを静的なサイトへ移すと、移した後に届くフォームの送信内容やコメントは、WordPressに保存されなくなります。それらだけを読むAIの機能なら、保存済みの分も消すことで、外の人の文章を読まない状態にできます。静的なサイトへ移しても、アクセスログや、フォームの送り先（外部のサービスや問い合わせのメール）は残るため、それらを読むAIの機能なら条件は欠けません。

この記事が扱うのは、サービスに組み込まれたAIの機能が、記録やデータを自動で読む場合です。どの作業をAIに任せるかは、AIに任せる範囲の決め方で扱っています。

すでにデータが外へ送られた疑いがあるなら、有効にするかを決めるより先に、AIの機能を止め、どの記録とデータに届いていたかを控えます。そのうえで、AIの機能が読んだ内容と返答の履歴、外部への接続やメールの記録が残っているかを提供元に問い合わせます。この記事の2つの例では、返答の画像の読み込みは利用者のブラウザやアプリから出ていたため、社内に通信の記録があれば、読み込まれた先をそちらでも確かめます。