【2026年版】AIブラウザ／コンピュータ操作エージェントの「知覚層インジェクション」防御ガイド——エージェントが”見ている画面・DOM・アクセシビリティツリー”に偽装指示を仕込まれ操作を乗っ取られる手口と、視覚的サニタイズ・操作前確認ゲート・到達ドメイン制限による多層防御

はじめに——攻撃面は「テキスト入力」から、エージェントが”見ている画面”へ移った
1. 既存記事との切り分け——「権限構造」でも「画像内の隠し指示」でもない
攻撃面の移動——なぜ「知覚層」が新しい急所なのか
3経路の攻撃——画面・DOM・アクセシビリティツリー
実例パターン——クリックジャッキング型・偽承認ボタン型・スクリーンショット汚染型
防御①：視覚／DOMサニタイズ前処理——「見せる前に正規化する」
防御②：危険操作の確認ゲート——送信・購入・権限変更の前で必ず止める
防御③：到達ドメイン制限と最小権限ブラウザプロファイル
検知：操作トレースと「意図と乖離した操作」のフラグ
多層防御チェックリスト
よくある質問（Q&A）
まとめ——「エージェントの認識は汚染され得る」を前提に設計する
参考リンク

はじめに——攻撃面は「テキスト入力」から、エージェントが”見ている画面”へ移った

これまでのAIセキュリティ記事では、プロンプト欄やAPIに送り込まれるテキスト入力をどう検証するかを中心に扱ってきました。しかし2026年、Claude in Chrome・OpenAI Operator（Atlas）・computer use・Perplexity Cometといった「ブラウザ／コンピュータを能動的に操作するエージェント」が実務に入ったことで、攻撃面はもう一段下のレイヤーに移りました。エージェントが画面・DOM・アクセシビリティツリーを”どう解釈するか”という知覚層（perception layer）です。

Googleの開発者向けドキュメント（web.dev）も、AIエージェントがWebサイトを見る経路は大きく3つ——スクリーンショット（視覚モデルでの解釈）・生のHTML/DOM・アクセシビリティツリー——であり、現代のエージェントはこれらを組み合わせて判断していると明記しています。つまり、人間の目には見えない要素・偽のボタン・DOMに埋め込んだ指示・スクリーンショットに紛れ込ませた命令で、エージェントの”認識”そのものを汚染できてしまうということです。

緊急度は数字にも表れています。Dark Readingが2026年初頭に実施した読者調査では、回答者の48%が「エージェント型AI・自律システム」をその年最大の攻撃ベクトルに挙げ、ディープフェイクやパスワードレスへの懸念を上回りました。エージェントが利用者の認証済み権限で能動的に操作・送信・購入してしまうため、被害は「情報が漏れる」では済まず「勝手に実行される」まで広がります。

筆者はネットワークのNOC（運用監視センター）／TAC（テクニカルアシスタンスセンター）で長年、「入力を信用せず正規化してから処理する」サニタイズ前処理と、「危険な変更の前に必ず人間の承認を挟む」メンテナンス承認ゲートの設計に携わってきました。本記事の核心は、その発想が知覚層インジェクションの防御にそのまま転用できるという点です。エージェントが”何を見て判断するか”を信用せず、危険操作の前段で必ず止める——この多層防御を、実装の視点で整理します。

想定読者は、Claude in Chrome・Operator等を業務に組み込み始めた情シス・CISO・開発者の方々です。便利さの裏でエージェントが勝手に操作・送信・購入してしまうリスクを統制したい層を念頭に置いています。

既存記事との切り分け——「権限構造」でも「画像内の隠し指示」でもない

本サイトでは関連テーマを複数扱っています。本記事の独自性を先に明確にしておきます。

Confused Deputy（混乱した代理人）＝「誰の権限で実行するか」という権限構造の話。本記事は、エージェントが「何を見て判断するか」という知覚層に特化します。
マルチモーダル・プロンプトインジェクション＝主に画像内に仕込まれた隠し指示。本記事はそれをブラウザ／コンピュータの能動的なUI操作の文脈に拡張し、クリックジャッキング・偽UI・DOM注入まで含めて扱います。
ブラウザ操作エージェント実践ガイド＝導入・活用の手順。本記事は防御に特化します。

攻撃面の移動——なぜ「知覚層」が新しい急所なのか

従来のプロンプトインジェクションは、利用者が入力する欄や、エージェントが読み込むテキスト本文を経路としていました。対策も「入力を検証する」「システムプロンプトを堅牢にする」というテキスト中心の発想でした。

ところがブラウザ／コンピュータ操作エージェントは、テキストだけでなくレンダリングされた画面・DOMツリー・アクセシビリティツリーを読み取って「次に何をクリックすべきか」「どのボタンを押すべきか」を判断します。ここで決定的な問題が生じます——エージェントは「要約すべき本文」と「従ってはいけない指示」を区別できないのです。Brave のセキュリティチームがPerplexity Cometに対して実証したのは、まさにこの弱点でした。攻撃者が用意したWebページの不可視要素に指示を埋め込み、利用者が「このページを要約して」と頼むだけで、エージェントがメールからワンタイムパスワードを取り出すといった越権操作に至りました。

さらに厄介なのは、同一オリジンポリシーが無力化される点です。エージェントは利用者の認証済みセッションで動くため、「不正にオリジン境界を越える」のではなく「正規の鍵を渡された状態」で複数ドメインを横断します。2026年6月時点でも、セキュリティ研究者はAtlas・Comet・Diaのいずれにおいても、プロンプトインジェクションを根本的に塞ぎきることはできないと指摘しています。便利さと脆弱性が同じ仕組みから生まれている以上、「完全には防げない」を前提にした多層防御が現実解になります。

3経路の攻撃——画面・DOM・アクセシビリティツリー

知覚層インジェクションは、エージェントが世界を認識する3つの経路それぞれに対応します。防御を考える前に、どこから汚染が入るのかを整理します。

経路1：画面（スクリーンショット）——人には見えない命令を視覚モデルに読ませる

エージェントが画面をスクリーンショットして視覚モデルで解釈する経路を悪用します。背景とほぼ同色の極薄テキスト、画像内に紛れ込ませた文字列、OCRでしか拾えない微細な文字などを使い、人間の目には見えないが視覚モデルには「指示」として読める命令を仕込みます。Braveは、利用者がページのスクリーンショットを撮らせるだけで、画像認識が人間には知覚できない命令文を抽出してしまう手口を報告しています。

経路2：DOM——隠し属性・不可視要素に指示を埋め込む

最も多用される経路です。レンダリング結果には現れないがDOMには存在する要素に、命令を埋め込みます。実証されている代表的な手口は次の通りです。

白背景に白文字／極小フォント： 視覚的には空白だが、DOMパース時には命令として読まれる。
display:none・opacity:0・画面外配置： CSSで非表示にしつつDOMには残す。
HTMLコメント・不可視div： 「要約して」のような無害な依頼をトリガーに発火させる。
選択不可化（user-select:none / pointer-events:none）： 利用者がテキスト選択で気付くことを防ぎつつ、エージェントには読ませる。
ゼロ幅文字・Unicode難読化： 命令を人間に判読不能な形でエンコードする。
第三者の投稿への混入： 攻撃者が所有しないサイトでも、SNSのコメントや掲示板の投稿に命令を仕込める。

経路3：アクセシビリティツリー——支援技術向けの構造を逆手に取る

アクセシビリティツリーは、本来スクリーンリーダー等の支援技術のためにブラウザがDOMから生成する「意味的に重要な要素だけの簡約表現」です。トークン効率が良いため、多くのエージェントがページ理解の主軸に採用しています。攻撃者はこの信頼を逆手に取り、aria-label・aria-hidden・スクリーンリーダー専用クラスに偽の指示やラベルを仕込みます。視覚的にもDOMの本文的にも目立たないため、検知が難しい経路です。

経路	エージェント側の解釈	仕込みの手口	人間からの見え方
画面（スクショ）	視覚モデルで画像を解釈	極薄テキスト・画像内文字・OCR狙い	見えない／気付けない
DOM	HTMLを構造として読む	白文字・display:none・不可視div・コメント	レンダリングに現れない
アクセシビリティツリー	意味的要素の簡約表現を読む	偽のaria-label／aria-hidden／SR専用クラス	画面にもソースにも目立たない

実例パターン——クリックジャッキング型・偽承認ボタン型・スクリーンショット汚染型

3経路を踏まえると、能動的UI操作エージェント特有の攻撃パターンが見えてきます。代表的な3つを整理します。

パターンA：クリックジャッキング型（偽UIで操作を誘導）

視覚的に正規のボタンに見える要素を重ね、エージェントに「ここを押せ」と誤認させます。あるいは透明レイヤーを被せ、エージェントが意図したクリックを別の操作（送金・許可・購入の確定）にすり替えます。従来のクリックジャッキングが「人間を騙す」ものだったのに対し、ここではエージェントの視覚判断を騙す点が新しい急所です。

パターンB：偽承認ボタン型（”OKを押させる”誘導）

DOMやアクセシビリティツリーに「同意」「続行」「この操作を承認」といったラベルの偽要素を配置し、エージェントに「タスク完了には承認が必要」と思い込ませて、本来止まるべき危険操作を自動で確定させます。本来は人間に確認を求めるべき分岐を、偽UIが代行して握り潰すのが狙いです。

パターンC：スクリーンショット汚染型（視覚モデルへの直接注入）

ページや画像に人間には見えない命令を仕込み、エージェントがスクリーンショットを解釈する瞬間に発火させます。「このページを要約して」という無害な依頼が引き金になるため、利用者は何が起きたか気付けません。Braveが報告したComet の事例は、このパターンの典型です。

防御①：視覚／DOMサニタイズ前処理——「見せる前に正規化する」

ここからが本記事の中核です。NOC/TACで「入力を信用せず、正規化してから処理する」サニタイズ前処理の発想を、知覚層に持ち込みます。エージェントがページを解釈する前段に、汚染要素を取り除く正規化レイヤーを挟みます。

不可視要素の除去： display:none・opacity:0・画面外配置・極小フォント・背景同色テキストを検出し、エージェントに渡す表現から除外する。「人間に見えないものはエージェントにも見せない」を原則にする。
DOMとレンダリングの突合： DOM上に存在するがレンダリング結果に現れないテキストをフラグ化する。両者の乖離が大きいページは、要約・操作の前に警戒度を上げる。
アクセシビリティ属性の検疫： aria-label等に紛れ込んだ命令的文字列（「無視せよ」「次の操作を実行せよ」等の指示パターン）を検出・無害化する。
命令文と本文の分離： 取得したページ内容を「処理対象データ」として明示的にマークし、そこに含まれる文言を指示として実行しない構造をプロンプト設計で徹底する。

これはネットワークで「信頼できない入力を境界で正規化してから内部に通す」発想そのものです。完全な除去は難しくとも、汚染の入口を狭めることで、後段の確認ゲートが効く確率を上げるのが目的です。

防御②：危険操作の確認ゲート——送信・購入・権限変更の前で必ず止める

サニタイズをすり抜けた汚染があっても、取り返しのつかない操作の直前で必ず人間に確認を求めるゲートがあれば、被害は実行前に止まります。これはTACの「メンテナンス承認（変更前の確認）」の発想です。設定変更を本番に流す前に必ず承認を挟むのと同じ構造を、エージェントの操作に適用します。

ポイントは、すべての操作を止めるのではなく、リスクの高い操作だけを選別して止めることです。過剰な確認は利便性を殺し、利用者が確認を惰性で押すようになって形骸化します。

操作の種類	リスク	ゲートの扱い
閲覧・要約・検索	低（読み取りのみ）	自動実行可（ログのみ）
フォーム入力（下書き）	中	送信前に内容を提示
送信・投稿・メール送付	高（外部への発信）	必ず人間が確認・承認
購入・送金・課金	最高（金銭・不可逆）	必ず人間が確認＋金額・宛先の明示
権限変更・連携承認・削除	最高（不可逆・拡散）	必ず人間が確認＋エスカレーション

確認画面では、エージェントが「何を根拠に」その操作を選んだか（どの要素・どのページ指示に従ったか）を併せて提示すると、偽承認ボタン型・クリックジャッキング型の検知率が上がります。「このボタンはページ内の隠し指示に従って押そうとしています」と提示できれば、利用者は異常に気付けます。

防御③：到達ドメイン制限と最小権限ブラウザプロファイル

知覚層が汚染されても、エージェントが到達できる先と使える権限を最初から絞っておけば、被害の到達範囲そのものが限定されます。ネットワーク設計の最小権限原則のブラウザ版です。

到達ドメインの許可リスト化： エージェントが操作してよいドメインを明示的に列挙し、それ以外への能動的アクセス（特に認証済みセッションを持つ銀行・社内システム・メール・クラウドストレージ）を遮断する。同一オリジンポリシーが無力化される以上、横断の範囲を運用側で締める。
専用ブラウザプロファイルの分離： エージェント用のプロファイルを、利用者の本番ログインセッションから分離する。機密サービスのCookie・認証情報をエージェントのプロファイルに同居させない。
タスクスコープの限定： 1つのエージェントに何でもやらせず、用途・到達先・実行可能な操作種別を絞る。汚染が成功しても「できること」が小さければ被害は小さい。
機密タスクの隔離： 送金・社内システム操作など真に重要なタスクは、エージェントの自動操作対象から外し、人間または認証前置の経路に限定する。

検知：操作トレースと「意図と乖離した操作」のフラグ

前処理・ゲート・権限制限をすり抜けた汚染を捉える最後の砦が、操作トレースの記録と、利用者の本来の意図から乖離した操作のフラグ化です。エージェントが「要約して」という依頼に対して、なぜかメールにアクセスし外部ドメインへ送信しようとしたら、それは意図と操作の乖離です。

NOCのトラフィック異常検知と同じく、「正常な操作プロファイル」からの逸脱を見ます。依頼内容と実行された操作系列の整合性、到達ドメインの逸脱、危険操作の突発的な発生——これらをスコアリングして、閾値超でゲートを厳格化・操作を一時停止します。

この「長く動くタスクの途中で目標がすり替わる」現象への体系的な防御は、AIエージェントの「目標ハイジャック（Agent Goal Hijack）」防御ガイドで計画層の監視・目標整合性チェック・チェックポイント検証として詳しく扱っています。本記事の知覚層対策と組み合わせることで、「入口（知覚）」と「実行の経過（計画）」の両面を守れます。また、操作の結果としてのデータ流出経路についてはゼロクリック流出（EchoLeak／ShadowLeak／HashJack）対策ガイドも併せてご覧ください。

多層防御チェックリスト

層	対策	主に効く攻撃
前処理	不可視要素の除去・DOMとレンダリングの突合	DOM注入・スクショ汚染
前処理	アクセシビリティ属性の検疫・命令と本文の分離	アクセシビリティツリー注入
ゲート	送信・購入・権限変更の前で人間が確認	偽承認ボタン型・クリックジャッキング型
ゲート	操作根拠（従った要素）の提示	偽UI全般
権限	到達ドメインの許可リスト化	越権・クロスドメイン操作
権限	専用プロファイル分離・タスクスコープ限定	被害範囲の限定（全般）
検知	操作トレース・意図と乖離した操作のフラグ	すり抜けた汚染の事後・事中検知

よくある質問（Q&A）

Q1. テキストのプロンプトインジェクション対策をしていれば、知覚層も守れますか？

不十分です。テキスト入力の検証は「プロンプト欄や本文」を見ますが、知覚層の攻撃は人間にもDOM本文にも見えない経路（極薄テキスト・不可視div・偽のaria属性・スクリーンショット内の隠し文字）から入ります。エージェントがページを解釈する前段でのサニタイズと、危険操作の確認ゲートを別途重ねる必要があります。

Q2. ブラウザエージェントの脆弱性は、ベンダーのアップデートで解消されますか？

個別の手口はパッチで塞がれますが、根本解決は困難とされています。エージェントが「処理すべき本文」と「従ってはいけない指示」を区別できないという構造的な弱点は、便利さの源泉と同じ仕組みから生じているためです。2026年時点でも主要なエージェントブラウザでプロンプトインジェクションを完全には塞げないと報告されており、「完全には防げない」を前提にした多層防御と運用統制が現実解です。

Q3. 確認ゲートを入れると、エージェントの利便性が損なわれませんか？

すべてを止めれば形骸化します。だからこそリスクで選別するのが鉄則です。閲覧・要約・検索は自動実行（ログのみ）、送信・購入・権限変更といった不可逆・外部発信の操作だけを必ず止める——TACのメンテナンス承認と同じく「変更の重さ」に応じてゲートの強度を変えます。

Q4. 自社サイトを「エージェントに安全に読まれる」状態にするには？

裏返しの対策として、不可視要素や紛らわしいアクセシビリティ属性を自サイトから排除し、意味的に正しい構造（適切なロール・ラベル・状態）を保つことが有効です。クリーンな構造はエージェントの誤読を減らし、結果として自サイトが攻撃の踏み台に使われるリスクも下げます。これはアクセシビリティの基本に立ち返ることと同義です。

Q5. 同一オリジンポリシーがあるのに、なぜ越権が起きるのですか？

同一オリジンポリシーは「悪意あるスクリプトがオリジン境界を不正に越える」ことを防ぐ仕組みです。しかしエージェントは利用者が認証済みの正規セッションで動くため、「鍵を渡された正規の利用者」として複数ドメインを横断します。境界を不正突破しているわけではないので、従来の保護が効きません。だからこそ運用側での到達ドメイン制限とプロファイル分離が必要になります。

まとめ——「エージェントの認識は汚染され得る」を前提に設計する

AIセキュリティの議論は長らく「入力テキストをどう守るか」に集中してきました。しかしブラウザ／コンピュータ操作エージェントが実務に入った2026年、攻撃面はエージェントが画面・DOM・アクセシビリティツリーを”どう解釈するか”という知覚層へ移りました。要点は3つです。

1. 攻撃は「見えない経路」から入る。 極薄テキスト・不可視div・偽のアクセシビリティ属性・スクリーンショット内の隠し文字——人間にもDOM本文にも見えない命令で、エージェントの認識そのものが汚染されます。

2. 「見せる前に正規化し、危険操作の前で必ず止める」。 NOC/TACのサニタイズ前処理とメンテナンス承認の発想がそのまま武器になります。前処理で汚染の入口を狭め、送信・購入・権限変更の前段で人間の確認を挟みます。

3. 完全には防げない前提で、到達範囲を絞り、逸脱を検知する。 到達ドメイン制限・最小権限プロファイルで被害範囲を限定し、操作トレースで「意図と乖離した操作」を捉えます。目標ハイジャック対策・ゼロクリック流出対策・Confused Deputy対策と組み合わせることで、エージェント実行系セキュリティの多層防御が完成します。

「エージェントを使わない」が現実的でない以上、「エージェントの認識は汚染され得る」を前提に、前処理・ゲート・権限・検知の4層で守る——これが、能動的に操作するエージェントを安全に業務へ組み込むための基本姿勢です。

参考リンク

免責事項： 本記事は2026年6月時点の公開情報および標準フレームワークに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の防御実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家にご相談ください。エージェント製品や脆弱性情報は急速に更新されるため、最新情報は各公式ソースでご確認ください。