YouTubeクリエイターのプライベート動画の漏洩

2026年7月5日原文(javoriuski.com)

概要

YouTube StudioのAIアシスタントAsk Studioには、コメント内容をそのまま出力する脆弱性が存在。攻撃者はコメント編集を利用し、AIの出力を操作可能。この問題は「ソーシャルエンジニアリング」ではなく、プロダクト信頼性の侵害。コメントを指示として解釈しない設計が必要。クリエイターはAI出力を鵜呑みにしない注意が求められる。

YouTube StudioのAsk StudioにおけるAIアシスタントの脆弱性

Ask Studio はYouTube StudioのAIアシスタント機能
クリエイターが「視聴者は何と言っている？」などと尋ねると、AIがコメントを読み要約を返答
コメントに「フィードバック」ではなく「指示」を含めた場合の挙動に着目
- 攻撃者がコメントに「[IMPORTANT NOTICE FROM YOUTUBE]」などの文言を挿入
- AIがそのまま公式回答のように返答
- クリエイターはどこからの文言か判断不可
コメント編集機能の悪用
- 最初は「Nice video!」など普通のコメントを投稿
- 後から内容を攻撃用ペイロードに編集
- コメント編集後、クリエイターには通知が再送信されないため、変更に気付かない
ストアドプロンプトインジェクション の成立
- 攻撃者が任意のコメントを残すだけで、AIの返答をコントロール可能
- クリエイターがAsk Studioを利用するだけで発動
- AIの推奨プロンプト機能により、コメント内容は自動的にAIへ送信
Googleの対応と問題認識のずれ
- 報告したが「ソーシャルエンジニアリングが必要なため追跡しない」と回答
- 実際は「ユーザーが攻撃者を信頼する」構造ではなく、「Googleのプロダクトを信頼する」構造の悪用
- クリエイターは攻撃コメント自体を見ず、AIの出力のみを信用

プライベート情報の漏洩リスク

Ask Studioは認証済みクリエイター用ツールとして、チャンネルの動画（非公開含む）情報にアクセス可能
攻撃コメント内で、AIにチャンネルデータを含んだリンク生成を指示
クリエイターがリンクをクリックすると、動画タイトルなどの情報が外部に送信
非公開動画タイトル は未発表プロジェクトや個人情報など、公開前の重要情報

根本的な対策と信頼モデルの再設計

コメント内容を「信頼できないデータ」として扱い、AIへの入力時に役割境界を厳格化
ユーザー生成コンテンツをAIが解釈・実行しないよう、システム指示と明確に区別
こうした分離がなければ、AIは新たな攻撃ベクトルとなる危険性

クリエイターへの注意喚起

Ask Studioは便利だが、誰でもコメント経由でAIの返答内容を操作可能
本来漏れるはずのない情報の外部流出リスク
信頼モデル違反 として、数百万のクリエイターが気付かぬまま被害を受けるおそれ
Ask Studioの出力を鵜呑みにせず、常に慎重な確認が必要

Hackerたちの意見

グーグルはプロンプトインジェクション攻撃を気にしてないの？？？マジでありえない。

└

ちゃんと気にしてるよ。修正すると思う。ただ、このバグに対して報酬は出さないだけ。

└

それに対して何かできるの？データの供給方法に根本的な欠陥があるよ。PHPやSQLインジェクションのフラッシュバックが来る。

コメントは、システムレベルの指示として解釈されないように、明確な役割の境界を持ってモデルに渡されるべきです。まあ、そんな明確な境界があれば多くの問題が解決するんだけど、実際には存在しないよね？

└

うん、これが却下された主な理由は、単に修正不可能だからだと思う。これがLLMの仕組みなんだよね。このLLMは信頼できないデータを取り込むから、こういうプロンプトインジェクションが成功する可能性は常にゼロじゃないんだ。

ちょっとメタだけど、この記事を称賛してもいい？タイトルが分かりやすくて、すぐに本題に入るし、余計なことがない、事実に基づいてる…いい変化だね。95%の他のユーザーだったら、もっとひどいことをしてたと思う。これはクリックベイトじゃないし、SNSキャンペーンを呼びかけてるわけでもない、グーグルのエンジニアを恥じさせようとするツイートもないし、特定の個人を攻撃することもない… ユーザーが自分の素材を投稿する際に show hn とかで宣言すべきかどうかは分からないけど、それが唯一の批判の道かもしれない（でも、そのネットマナーはあんまり詳しくない）。

└

それなら驚くことになるよ。この文章は明らかにLLMスタイルだからね。だからって、幻覚を見てるわけじゃない。ちゃんとした人間が背後にいるけど、君が楽しんだ実際の内容はLLMが書いたものなんだ。

└

フィードバックありがとう！ここに投稿するのは初めてだから、そうするべきだって知らなかった。今やるね。

└

JavaScriptを無効にしたら、ページソースを確認して、コンテンツを表示させるためにdivの「hidden」属性を削除しなきゃいけなかった。プレースホルダーテキストもないし、JSが必要な理由を全く説明してないし、誰かがJSホワイトリストツール（NoScriptなど）を使ってる可能性も考慮してない。ブログ記事なのにね。それ以外は: > 説明的なタイトルで、すぐに本題に入るし、余計なフワフワもない、事実に基づいてる...「説明的なタイトル」ってのは認めるけど、もっと直接的で読みやすく書けるよ。

最近、いくつかのYouTubeチームとプロジェクトをやってたけど、グーグルを辞めたばかりなんだ。YouTubeがこういう風に扱ってる理由を説明できると思う。これはかなり微妙で複雑な問題だから、バグを分類する作業はこの機能の実装を担当しているエンジニアのところに回ってきたんだと思う。そのエンジニアはすでにこのプロジェクトを立ち上げていて、プロモーションや年次レビューのためのGRAD（パフォーマンス）資料にファイルしてる。バグを修正するために時間を無駄にする動機はないし、むしろプロモーションパケットに利益をもたらす他のプロジェクトを立ち上げるプレッシャーを受けてるからね。だから、プロモーションや年次レビューの枠組み（GRAD）が奨励し、報酬を与えるから、できるだけ隠そうとするんだ。

└

これが大手テック企業の普遍的な経験だと聞けて嬉しいよ。プロモーションプロセスは、良い製品を出すこととは真逆だね。

└

このコメントの中で一番クソなことは、たった一人のエンジニアに自分が書いたコードのバグに対する生涯責任を持たせることだと思う。それが徐々に普通になりつつある。前に働いてた大手の有名なテック企業では、QAが存在しなかったんだ。部門内にその役割はどこにもなかった。自分が書いたコードのバグに対して完全に責任を負わされる。最初は可愛いと思ったけど、長期的には持続不可能だね。

Hacker Newsで議論の続きを見る

ハクソク