AI エージェントに安全にブラウザを自動操作させるために、隔離環境を作る(1)
目次
今回、AI エージェントに安全にブラウザを自動操作させるために、隔離環境を作る方法を2つ紹介します。1つ目は技術的には大して面白い話でもないので、2つ目について詳しく説明したいところですが、文字数の関係で詳細は次回説明します。
前提
今回の話は、主に個人で AI エージェントを動かす場合の話です。会社の業務として行う場合には管理面が重要になってくるため、今回紹介する方法をそのまま使うのではなく、さらに手を加える必要があります。
背景
MCP サーバーでは出来ない事が多く、現時点ではブラウザ操作が必要
Claude Cowork や Claude Code 単体で出来る処理は、かなり大雑把にはローカルファイルの読み書き実行とウェブ検索などの限られたものだけです。そこで登場するのが MCP サーバーです。MCP サーバーを使うと外部のサービスに接続出来たり、AI エージェントが出来る事は格段に広がります。素晴らしいですね。
ただ、現実問題としては MCP サーバーを提供していない SaaS が結構あったり、MCP サーバーがあっても対応していない処理が多かったり、結果として AI エージェントで出来ない事も多いです。
そこで登場するのが Claude in Chrome です。Claude Cowork や Claude Code からブラウザを直接できるという画期的なもので、個人的には何となく未来を感じます。今年になって話題になっている OpenClaw や Hermes Agent なども同様にブラウザ操作できる機能があります。
セキュリティが心配
でも、AI エージェントがブラウザ操作できると言うことは、AI エージェントが勝手に Gmail でメールを返信したり、ローカルにある機密情報をどっかの掲示板に投稿したり、という事も理論上は考えられます。（各種防御機構がある事は知ってます。）
一時期 OpenClaw を動かすために Mac mini を買った、みたいな人が沢山いましたが、その人達は Mac mini に
- 必要なファイルだけを置く
- 必要なサイトだけログインしておく
という形でセキュリティを担保しようとしているのだと思います。
とは言えあんまりお金をかけたくない
Mac mini。良い方法だと思います。お金さえあれば、の話ですが。
Mac mini はそんなに高くないとはいえ10万円くらいはします。また、あるタスク・プロジェクトと別のタスク・プロジェクトでファイルを共有したくない場合もあると思います。その場合、Mac mini を複数台買うのでしょうか・・・
選択肢1: OS のユーザーを分ける
ここからが本題です。1つ目の選択肢としては、OS のユーザーを分けることです。私は Mac, Windows 両方使っていますが、どちらも OS のユーザーを複数作成して、必要なときに切り替えることが出来ます。
やり方
例えば以下のような形でユーザーを作成します。
- kashima -> 管理者権限、通常作業、ソフトのインストール等
- agent1 -> 非管理者権限、ホームディレクトリに必要なファイルのみ配置、ブラウザでは必要なサイトのみログイン状態にする
- agent2, agent3 -> agent1 と同様
管理者権限のアカウントで、Claude Code なり OpenClaw の AI エージェントやその他必要なツール類をインストールします。
あるプロジェクト・作業をエージェントに任せる場合は、例えば agent1 に切り替えて、ホームディレクトリ上に必要なファイルのみを持ってきて、Chrome も必要なサイトのみログイン状態にしておきます。
良い点・悪い点
良い点は何と言っても簡単なことです。ある程度 IT リテラシーのある方であれば、やり方が分からないということはないでしょう。
悪い点は以下の2点かなと思います。
- ユーザーの切り替えが若干面倒
- 必要なファイル「のみ」を持ってくるのが若干面倒
1点目は説明不要かと思いますので2点目について説明します。
必要なファイルを Google Drive, Box, GitHub などから持ってくることを考えます。通常は自分自身のアカウントでログインしてファイルをコピー、あるいは git pull をしますが、自分自身のアカウントは必要なファイル以外にアクセスする権限もあります。それらのアカウントにログインした状態にしておくと、理論上は AI エージェントが関係無いファイルに参照することも考えられます。ファイルコピー後にログアウトすれば良いのですが、ファイルを更新するときに都度ログイン・ログアウトをするのは若干面倒です。
どちらも致命的ではありませんが、若干面倒な2点を悪い点として挙げました。
選択肢2: コンテナ内で Xvfb, Chromium, noVNC を起動する
2つ目の選択肢は、Docker コンテナ内で必要なものを全て起動する方法です。長くなってきたので、今回は概要のみを示して、細かい設定方法、用語の解説などは次回書きます。
やり方
Docker コンテナ内に以下を起動します。
- Xvfb (X Virtual Framebuffer): 物理デバイス無しで起動する X サーバー
- Chromium: ブラウザー
- noVNC: ウェブブラウザ上でアクセス出来る VNC サーバー
これをプロジェクト毎に起動します。
人間は、noVNC 経由で Docker コンテナ内のブラウザにアクセスして、サイトへのログインなどを行います。AI エージェントは CDP (Chrome DevTools Protocol) 経由でブラウザの操作を行います。
良い点・悪い点
良い点から挙げます。
- ユーザーの切り替えが不要、複数のプロジェクトを同時に確認できる
- VPS などでも実行可能
- 比較的軽量
1番目ですが、noVNC はブラウザ上で動くので、タブを切り替えるだけで他のプロジェクトの画面を確認できます。VNC や noVNC を知らない人には分かりにくいかと思いますので、スクリーンショットを載せておきます。
http://127.0.0.1:6091/vnc.html が noVNC の URL で、その中で Chromium が開いていて Mobalab の LinkedIn ページが開いているのが分かるかと思います。
2番目ですが、この方法は Mac mini のようにグラフィックボードがあり（ディスプレイは別売りですが）画面表示が出来る環境だけでなく、VPS のように GUI がない環境でも動作します。
3番目は「比較的」軽量です。Xvfb, Chromium を含むので、イメージサイズはそれなりに大きいですが、VPS 上で複数起動できる程度には軽量です。
悪い点は何と言っても設定が複雑な点でしょう。とは言っても、今は AI がその辺の面倒なこともやってくれるので、普段 AI エージェントを業務で使っているエンジニアであればそこまで面倒ではないと思います。
まとめ
AI エージェントでブラウザ操作できる時代になりました。とはいえ、何も考えずに使うとセキュリティリスクになりかねません。そのため、隔離された環境でブラウザを実行するのが解決策なのですが、その方法として2つ紹介しました。2つ目の方法は少し複雑なので、次回もう少し詳細を解説します。
雑感: MCP が本命、だと思う
AI エージェントでブラウザを操作できるようになったとはいえ、今後これが本格的に普及していくようにもあまり思えません。やはり、AI エージェントが MCP 経由で色んな事を出来るようになる方が綺麗な解決策ですし、私はそちらを推したいと思います。
最後に宣伝ですが、MCP サーバーを一元管理するサービスを作っていて現在β版です。興味のある方は触ってもらえればと思います。私も普段の業務で使ってます（dogfooding）。
Bloque – All Your MCPs, Centrally Managed.
今後は、チームでも使えるようにメンバー管理、3LO などを実装予定です。
← 前の投稿
oEmbed に対応してみた
コメントを残す