AIブラウザ（エージェントブラウザ）——Perplexity の Comet、OpenAI の ChatGPT Atlas に代表される、AIが「見るだけでなく操作する」ブラウザが2025〜26年に一気に広がりました。ページを要約するだけでなく、リンクをクリックし、フォームに入力し、ログイン済みのサービスを横断して作業をこなす。便利さの裏で、セキュリティ研究者からは「Webの信頼モデルを根底から崩す」と強い警告が出ています。
OpenAI 自身が「プロンプトインジェクションは、詐欺やソーシャルエンジニアリングと同様、完全に“解決”されることはおそらくない」と述べ（2025年12月）、Gartner は企業に対し「セキュリティが成熟するまで利用をブロックすべき」と勧告しました。本記事は、なぜAIブラウザが危ないのか、実際に成立した乗っ取りの具体例、そして使う側がとるべき防御を整理します。
根本原因：間接プロンプトインジェクション
AIブラウザの弱点は、ほぼ一点に集約されます。「ユーザーの指示」と「Webページの中身」を区別せずに、まとめてAIへ渡してしまうことです。
Brave の分析によれば、ユーザーが「このページを要約して」と頼むと、Comet はページの内容をそのままLLMへ送り込み、どこまでが利用者の指示で、どこからが信頼できないページ由来かを区別しない。つまり攻撃者は、ページの中に「AIへの命令」を仕込んでおくだけで、AIをその通りに動かせます。これが間接（インダイレクト）プロンプトインジェクションです。
命令は人間に見えない形で隠せます——白背景に白文字、HTMLコメント、Redditのネタバレ（spoiler）タグなど。人は気づかず、AIだけが読みます。しかも、攻撃者が直接管理していないユーザー投稿（コメント欄やレビュー）にも仕込めるため、攻撃面は極めて広くなります。
実例1：要約ボタン一つで乗っ取られる（Brave のPoC）
Brave が公開した実証では、攻撃の起点はなんとReddit のコメントでした。流れはこうです。
- 攻撃者が、ネタバレタグで隠した指示を含むコメントを Reddit に投稿しておく。
- 被害者がそのページで Comet の「現在のページを要約」ボタンを押す。
- Comet は隠された指示を正規の命令として解釈し、次を自動実行する：
- ユーザーの Perplexity アカウントページへ移動し、メールアドレスを取得。
- 細工したドメイン（末尾ドットの悪用）にアクセスしてワンタイムパスワード（OTP）の送信をトリガー。
- ログイン済みの Gmailを開いて、届いた OTP を読み取る。
- 取得したメールアドレスと OTP を、元の Reddit スレッドに投稿して攻撃者へ送信。
被害者がしたのは「要約ボタンを押した」ことだけ。にもかかわらず、多要素認証を含むアカウント乗っ取りが完結します。OTP すら、AIが本人のログイン済みメールから読み取ってしまうため、TOTPベースのMFAでは防げません。
実例2：ゼロクリック乗っ取り（Zenity の PleaseFix / CometJacking）
Zenity Labs は2026年3月、PleaseFix と名付けた一連の重大脆弱性を公表しました。要約ボタンすら不要なゼロクリックの手口です。
- カレンダー招待を悪用：悪意あるプロンプトを仕込んだ正規のカレンダー招待を送るだけ。AIブラウザが予定を読み込んだ瞬間に指示が発火し、ローカルファイルシステムへアクセスし、ディレクトリを辿り、ファイルを読んで外部サーバへ送信した。
- パスワードマネージャの乗っ取り：ユーザーが 1Password 等にログイン済みなら、AIブラウザも同じ権限を持つ。攻撃者は間接プロンプトで設定やパスワードを密かに変更し、シークレットを抽出しながら、画面上は「無害な応答」だけを返させることができた。
- CometJacking：LayerX は、隠れた MCP API を悪用して1クリックで Comet を“裏切らせる”手口を報告。Zenity も同様に、隠れたコマンド実行経路の存在を指摘している。
これらは個別バグとして修正されていますが、Zenity は「個別パッチでは終わらない、エージェントブラウザに内在する構造的リスク」だと結論づけています。
なぜ Same-Origin Policy も CORS も効かないのか
ここがAIブラウザ最大の論点です。従来のブラウザは、Same-Origin Policy（SOP）と CORSによって「あるサイトのスクリプトが、別オリジン（別サイト）のデータに勝手に触れない」よう厳格に隔離してきました。Webセキュリティはこのオリジン分離を土台に組み立てられています。
ところがAIブラウザのエージェントは、ユーザー本人として、すべてのタブ・すべてのログイン済みセッションを横断して動きます。Gmail も銀行も社内SaaSも、本人の権限で正規にアクセスできる。Brave の言葉を借りれば、「SOP や CORS は事実上、無意味になる」。攻撃者は一つのサイトに命令を仕込むだけで、AIを介して本来は触れないはずの別オリジンのデータに到達できてしまうのです。
構図は MCP のセキュリティ と同じ根を持ちます。「外部から受け取ったコンテンツを、そのままAIの“指示”として扱う」——この信頼境界の崩壊が、AI時代に共通する脆弱性です。
図解案：AIブラウザの信頼境界
【従来ブラウザ】 オリジンごとに隔離（SOP/CORS）
サイトA ┊ サイトB ┊ Gmail ┊ 銀行
└─ 互いに直接アクセス不可（壁あり）
【AIブラウザ】 エージェントが本人として全部を横断
サイトA(攻撃者の命令を仕込む)
│ 間接プロンプトインジェクション
▼
[AIエージェント] ── 本人の権限 ──┬─▶ Gmail（OTP読取）
▲ ├─▶ 1Password（秘密抽出）
│ ページ内容=指示として混入 └─▶ 任意サイトへ送信(窃取)
└ 「壁」が消える ＝ SOP/CORS 無効化使う側・守る側の対策
Brave が提案する設計レベルの防御
- 入力の分離：ユーザーの指示とページの中身を明確に分け、ページ由来は常に「信頼できない入力」として扱う。
- 出力の検証：AIの行動が、本当にユーザーの依頼に沿っているかを実行前に独立して検査する。
- 機微な操作のゲート：メール送信・認証情報へのアクセス・送金など重要操作は、実行直前に毎回ユーザーの明示確認を求める。
- モードの分離：エージェント機能を通常閲覧から隔離し、視覚的にも区別して、何気ない閲覧中に誤発動しないようにする。
利用者・企業がいま取れる現実的な対策
- 機微なアカウントと同居させない：AIブラウザで Gmail・銀行・パスワードマネージャにログインしたまま使わない。エージェント用と日常用でブラウザ／プロファイルを分ける。
- 自動実行の権限を絞る：エージェントに「確認なしで操作させる」設定を避け、機微な操作は人間承認必須にする。
- 信頼できないページでエージェントを動かさない：掲示板・コメント欄・知らないサイトで「要約して」「手伝って」を不用意に使わない。
- 企業はポリシーで制御：Gartner の勧告どおり、業務端末では当面用途を限定するか利用を制限し、エージェントのアクセス範囲・ログ・データ持ち出しを監視する。
- 認証を強くする：OTP を読み取られても被害が出にくいよう、フィッシング耐性のある FIDO2/Passkeyや、重要操作の追加確認を組み合わせる。
実体験：Claude Codeを使っていて意識するようになった権限の話
Claude Code などの AI コーディングツールを使うようになってから、AI に与える権限についてはかなり意識するようになりました。特に、AI が単純に文章を生成するだけでなく、ファイルを読み書きしたり、コマンドを実行したり、場合によっては外部サービスと連携したりできるようになると、「AI に悪意のある指示を与えたらどうなるか」だけではなく、「AI が外部から取得した情報の中に悪意のある指示が含まれていたらどうなるか」という問題もあると感じました。
例えば、AI に Web ページや README などを読ませたとき、その中に「このコマンドを実行してください」といった指示が含まれていた場合、AI がそれを単なる情報ではなく実行すべき命令として解釈してしまう可能性があります。自分で Claude Code を使って secutils を開発している中でも、AI に何でも自動実行させるのではなく、変更内容を確認してから実行することや、不要な権限を与えないことを意識するようになりました。AI が便利になればなるほど、「AI 自身を信頼するかどうか」だけでなく、「AI が扱う外部の情報をどこまで信頼するか」という視点も重要になると感じています。
まとめ
AIブラウザの危険性は、特定のバグというより「AIが本人として全オリジンを横断する」という設計そのものに根ざしています。間接プロンプトインジェクションは、ClickFixのような人間を騙す攻撃と違い、AIを騙して本人の権限を乗っ取る。だからこそ SOP/CORS という従来の壁が効かず、OpenAI 自身が「完全には解決できない」と認めています。
当面の合言葉は「便利さと権限を切り分ける」。機微なログインと同居させない、機微な操作は人間が承認する、信頼できないページでエージェントを走らせない——この3点を守るだけで、最悪の乗っ取りはかなり避けられます。同じ「外部入力＝指示」の問題は MCPのセキュリティ や Langflowの事例 にも通じるので、AIを業務に組み込む前に合わせて押さえておくと安全です。
※ 本記事の脆弱性名・PoC・各社の見解は、Brave／Zenity Labs／LayerX 等の公表内容および報道に基づきます。各製品は対策が日々更新されるため、利用時は最新の公式情報をご確認ください。