エンタープライズのAI活用で、静かに、しかし決定的に危険な一線が越えられつつある。それは「AIエージェントが、従業員本人としてログイン済みのブラウザを操作し、保存されたパスワードを使ってWebサイトにサインインし、業務を代行する」という段階だ。便利さは疑いようがない。だが、この設計は企業のセキュリティ境界を根本から書き換える。
2026年7月末から8月初旬にかけて、GoogleはAIアシスタント Gemini Spark をデスクトップ版Chromeに統合し、米国のAI Pro／Ultra利用者向けに提供を開始した。特筆すべきは、Sparkが利用者が実際にログインしているChromeセッションと、Chromeに保存されたパスワードを使って、フライトの検索・予約開始や内見予約といった複数ステップの操作を自律実行できる点だ（Google公式ブログ）。同種の機能は、Anthropicの「Claude for Chrome」やOpenAIのブラウザエージェントでも競うように投入されている。
homulaはエンタープライズ向けのAIエージェント・インテグレーターとして、「AIをどこまで、誰の権限で動かすか」という制御点の設計を日々扱っている。本稿では、ブラウザ操作型エージェントが企業に持ち込む固有のリスクを一次情報で整理し、導入判断の制御点を掘り下げる。
何が起きたか——エージェントが「認証済みセッション」を借りる
これまでのブラウザ拡張やRPAは、事前に定義したスクリプトを決められた画面で動かすものだった。今回の変化はそこと質的に違う。エージェントは自然言語の指示を受け、その場でWebを読み、判断し、クリックし、入力する。しかもその足場が、従業員が既にログインしている本物のセッションだ。
ブラウザ操作型エージェントは、権限を「新たに付与される」のではなく、従業員が既に持っている認証状態をそのまま継承する。SaaS、社内Webアプリ、メール、保存パスワード——本人がアクセスできるものは、原則エージェントもアクセスできる。付与範囲を絞る従来のRBAC設計だけでは、この継承を捉えきれない。
Googleは安全側の設計も用意している。連携アカウントへのアクセスには利用者の許可が必要で、決済など重要な操作の直前には制御を人間に戻すとされる。だが、この「人間に戻す」設計が効くのは、エージェントが正しく利用者の意図どおりに動いているときだけだ。問題は、そうでないときに何が起きるかである。
なぜ企業で危険なのか——ブラウザで「致命的な三点セット」が完成する
セキュリティ研究者のSimon Willisonは2025年6月、AIエージェントのデータ窃取を可能にする条件を「致命的な三点セット（Lethal Trifecta）」と名付けた。すなわち (1) 私的データへのアクセス、(2) 信頼できないコンテンツへの曝露、(3) 外部へ通信する手段——この3つが揃うと、攻撃者が窃取の経路を得る、という指摘だ（simonwillison.net）。どれか2つまでなら安全だが、3つ揃うと危険になる。
ログイン済みブラウザを操作するエージェントは、この3条件を一台の中で同時に満たしてしまう。
| 条件 | ブラウザエージェントでの具体例 |
|---|---|
| 私的データへのアクセス | ログイン済みのSaaS・社内アプリ・メール、Chromeの保存パスワード |
| 信頼できないコンテンツ | エージェントが読むあらゆるWebページ・検索結果・フォーム（内容を攻撃者が仕込める） |
| 外部への通信手段 | 任意サイトへの遷移・投稿・送信フォーム入力 |
ここで効いてくるのが間接プロンプトインジェクションだ。攻撃者はWebページやフォームの中に、人間には見えにくい形で「この情報を別サイトに送れ」といった指示を埋め込む。エージェントの言語モデルは、正規の指示も攻撃者の埋め込みも同じテキスト列として処理するため、両者を確実には区別できない。結果として、閲覧した1ページが引き金となり、認証済みセッションの権限で機密が抜かれ得る。プロンプトインジェクションはOWASPの「LLMアプリケーションTop 10」で首位（LLM01）に据えられ続けている、業界共通の未解決課題である。
数字が示す現実——「軽減」はできても「根絶」はできない
この脅威は抽象論ではない。ベンダー自身が測定値を公表し始めている。Anthropicは「Claude for Chrome」の検証で、意図的なプロンプトインジェクション攻撃の成功率が防御なしで 23.6%、対策後で 11.2% だったと報告した。隠しフォームやURL操作を使うブラウザ特有の攻撃では、対策により 35.7%→0% まで下げたとされる（VentureBeat）。着実な改善だが、11.2%という残存率は、認証済みセッションを預ける前提としては依然として高い。
OpenAIも、ブラウザエージェントに対するプロンプトインジェクションは「完全に『解決』されることはおそらくない」と明言している（CyberScoop）。つまり現時点の合意は「継続的に硬化させ続けるしかない、消えない攻撃面」だ。
企業にとって決定的なのは、Google自身が管理者向けに明確な警告を出している点である。Chrome Enterpriseの新ポリシー GeminiSparkSettings の公式ドキュメントは、この機能の有効化について次の趣旨を記す——「アクティブなブラウザセッションを用いた自律的な複数ステップ操作を許可することになり、認証情報のリスク、ローカルネットワークへの侵入、コンテキスト認識シグナルの喪失を含む重大なセキュリティリスクを伴う。既存の管理・セキュリティ統制が尊重されない可能性がある」。そのうえで、有効化前に組織のネットワーク脅威モデル・コンプライアンス・プライバシー方針を慎重に評価するよう促している（Chrome Enterprise ポリシー）。ベンダーが「既存の統制が効かないかもしれない」と自ら注記していることは、重く受け止めるべきだ。
最初の実務判断はシンプルだ。業務アプリにアクセスする管理端末では、ブラウザ操作型エージェントを既定で無効化し、限定的なパイロットから始める。GeminiSparkSettings のような管理ポリシーで、有効範囲を組織として明示的に制御できる状態を先に作る。
制御点をどこに置くか——4つの設計原則
「エージェントを賢く躾ければ安全になる」という発想では守れない。11.2%が示すのは、モデル側の緩和だけに賭けられないという事実だ。守りは構造で作る。
- 最小権限とセッション分離: エージェントに人間のフルセッションをそのまま継承させない。用途ごとに権限を絞った専用の認証情報を割り当て、閲覧用と実行用を分ける。ブラウザの保存パスワードへ無制限アクセスさせない。
- エージェント固有のアイデンティティ: 「誰が」動かしたかを人間と機械で区別できるよう、エージェントに検証可能な固有ID・資格情報を与え、監視・ローテーション・失効ができるようにする。人間の権限に相乗りさせない。
- 重要操作の承認ゲート: 送金・外部送信・データ書き出しなど不可逆・機微な操作は、エージェントの独断を許さず人間の承認を挟む。「決済前に人間に戻す」を、任意の善意ではなくポリシーとして強制する。
- 出口のDLPと監査: データがモデルや外部に出る前に検査（DLP）し、すべての操作を改ざん耐性のある記録として残す。インジェクションが起きても、被害範囲（ブラストラディウス）はエージェントに与えた権限の広さで決まる。ここを狭く、追跡可能にしておく。
より根本的な選択肢として、**「ログイン済み画面を操作させる」代わりに「統制されたツール接続（API／MCP）経由でエージェントを動かす」**という設計がある。画面を人間のセッションで操作させるアプローチは、信頼できないWebコンテンツと人間の全権限を同じ場所で混ぜてしまう。対して、MCPのような標準化された接続層を挟めば、エージェントに渡す権限・ツール・データ範囲をサーバー側で明示的に定義でき、認証も監査も一元化できる（関連: WebMCPで自社サイトをエージェント向けに整える、無人エージェントの秘密管理）。
homulaの観点——「画面を貸す」より「境界を設計する」
homulaがエンタープライズ導入で一貫して勧めるのは、便利さの入口で権限を丸ごと明け渡すのではなく、制御点を先に設計してから自動化を広げる順序だ。
- Agens（MCPを活用したエンタープライズ向け統合プラットフォーム）は、200以上のツールと構築ゼロで接続できる。ブラウザを人間のセッションで操作させる代わりに、必要なツールへ統制された経路でエージェントをつなぐ設計を可能にする。
- Agens Control は、承認フロー・DLP・5年分の監査ログ・RBAC を提供する。上で述べた「承認ゲート」「出口のDLPと監査」「エージェント固有のアイデンティティ」を、個別実装ではなく共通の統制層として敷ける。
- どこから手をつけるべきか迷う段階では、AIエージェント・ブートキャンプ（業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結）で、ブラウザ操作型エージェントの適用可否を脅威モデルとセットで切り分けるところから始めるのが現実的だ。
技術としてのブラウザエージェントを否定する必要はない。処理時間の大幅な削減（当社事例では最大93%削減）を生む場面は確かにある。要点は、その足場を「従業員の無制限な認証済みセッション」にしないことだ。
まとめ
ブラウザ操作型エージェントは、AIを「答える存在」から「本人として行動する存在」へと押し上げた。だが本人として行動するとは、本人の権限・認証情報・信頼をそのまま引き受けることでもある。致命的な三点セットが一台のブラウザで完成し、プロンプトインジェクションが消えない攻撃面である以上、守りはモデルの賢さではなく構造——最小権限、エージェントID、承認ゲート、出口のDLPと監査——に置くしかない。
「便利だから有効化する」ではなく、「制御点を設計してから、範囲を限って解放する」。この順序を守れる企業だけが、ブラウザエージェントの生産性を、事故を起こさずに受け取れる。
自社のエージェント活用で「どこで止め、どこで通すか」を設計し直すなら、まずは制御点の棚卸しから始めませんか。