---
title: "agent-browserの使い方｜Vercel製CLIのプロキシ設定・インストール・MCP連携【0.39対応】"
url: "https://www.issoh.co.jp/tech/details/10588/"
published: 2026-01-13
updated: 2026-10-22
categories: ["AIエージェント・MCP"]
publisher: "株式会社一創"
---

# agent-browserの使い方｜Vercel製CLIのプロキシ設定・インストール・MCP連携【0.39対応】

agent-browserは、Vercel Labs（vercel-labs）が公開しているAIエージェント向けのブラウザ操作CLIです。Rust製のCLIと常駐デーモンがChrome DevTools Protocol（CDP）でChromeを直接動かし、デーモンはPlaywrightにもNode.jsにも依存しません（npm・npxで入れた場合は、起動時にNode.js製のランチャーを通ります）。この記事では最新版0.39.1（2026年10月13日リリース）を前提に、導入、基本操作、社内ネットワークで詰まりやすいプロキシ設定、Vercelの保護されたプレビューを安全に開く方法、MCP連携を整理します。プロキシの挙動は、2026年10月22日にmacOS・agent-browser 0.39.1・Chrome for Testing 156.0.8078.47（mac-x64）で、検証用プロキシの接続ログを使って確認しました。

## まとめ

| 項目        | 内容（2026年10月22日時点）                                   |
| --------- | --------------------------------------------------- |
| 提供元・ライセンス | vercel-labs・Apache-2.0                              |
| 最新版       | 0.39.1（2026-10-13）                                  |
| 実行時の構成    | Rust製CLI＋デーモン→CDP→Chrome                            |
| 導入        | npm・Homebrew・Cargo＋`agent-browser install`          |
| ブラウザ      | Chrome for Testing（今回は156.0.8078.47を取得）             |
| プロキシ      | `--proxy`＞`AGENT_BROWSER_PROXY`＞設定ファイル＞`HTTP_PROXY` |
| MCP       | `agent-browser mcp`（既定プロファイルはcore）                  |

- 操作の型は「`open`で開く→`snapshot -i`で参照ID（`@e1`など）を得る→IDに対して操作する」の3手です。
- プロキシは`--proxy`か`AGENT_BROWSER_PROXY`で明示します。標準の`HTTP_PROXY`と`HTTPS_PROXY`を両方入れると、HTTPSのページでも`HTTP_PROXY`側が使われます。
- `socks5://user:pass@...`は通りません。ChromeがSOCKS5のユーザー名認証を提示しないためです。
- `install`・`doctor`・URL指定の`read`は`--proxy`を使いません。通したいならシェルの`HTTPS_PROXY`を設定します。
- Vercelの保護されたプレビューは、短命のOIDCトークンをヘッダーで渡して開きます。保護を外したり、公開例外を作ったりはしません。

## agent-browserの仕組み：RustデーモンとCDPによるChrome操作

### Playwright・Node.jsに依存しないRust製デーモン

agent-browserは、コマンドを受け取るCLIと、コマンド間で生き続けるデーモンに分かれています。デーモンはRustで書かれ、ChromeへCDPで直接つながります。[公式リポジトリのREADME](https://github.com/vercel-labs/agent-browser)は「No Playwright or Node.js required for the daemon」と明記しており、ソースからのビルドにはNode.js 24以降・pnpm 11以降・Rustが必要です。npm・npxで導入する場合もNode.jsが必要で、0.39.1のnpmパッケージはNode.js 24以降を要求しています。「Node.jsデーモンがPlaywrightを動かす」という2026年初めの解説は、現行版には当てはまりません。

デーモンが常駐するので、CLIを何十回叩いてもブラウザの起動は最初の1回で済みます。エンジンはChrome以外に`lightpanda`と、0.39.0で実験的に加わった`obscura`を`--engine`で選べます。

### snapshotと@refによる要素の指定

`snapshot`はアクセシビリティツリーを出力し、要素に`@e1`・`@e2`という参照ID（ref）を振ります。エージェントは`click @e2`のようにIDで操作します。`-i`を付けると操作できる要素だけに絞られます。

HTMLを丸ごと渡すより入力が小さく、クラス名の変更でも壊れません。0.38.0（2026年9月16日）からrefは同じ文書内のDOM変化を越えて保たれますが、要素の置き換えやページ遷移で無効になるため、画面が変わったらsnapshotを取り直します。同じ版の`snapshot --delta`は2回目以降の変化分だけを返します。

### Playwright・Playwright MCP・Stagehandとの使い分け

決まったシナリオを回すCIのE2Eテストは、アサーションとレポートを持つ[Playwright（プレイライト）とは？仕組み・できること・Seleniumとの違いを解説](/tech/details/3167/)の領分です。agent-browserは、次の操作をLLMがその場で決める用途の道具です。

エージェント向けでも、MCPのツールとして渡すのが[Playwright MCPとは？設定・使い方からDify連携まで実務ガイド【2026年版】](/tech/details/6172/)、TypeScriptのコードから自然言語で操作を書くのが[Stagehandとは｜AIブラウザ自動化の使い方とPlaywrightとの違い【v3対応】](/tech/details/5281/)です。シェルを実行できるエージェント（Claude Code・Codex・Cursorなど）にBashのコマンドとして渡すならagent-browserで、ツール定義でコンテキストを埋めずに済みます。[Next.js DevTools MCPの使い方｜next-devtools-mcp 0.4の設定と/\_next/mcpの9ツール](/tech/details/9941/)も、ブラウザ操作はagent-browserに任せる構成です。

## agent-browserのインストール（npm・Homebrew・Cargo・Windows）

### npm・Homebrew・Cargoによる導入とChromeの取得

どの経路でも、初回に`agent-browser install`でChrome for Testingを取得します。既存のChrome・Brave・Playwright・Puppeteerのブラウザが見つかれば、それを使います。

```
# npm（グローバル）
npm install -g agent-browser
agent-browser install

# macOS（Homebrew）
brew install agent-browser
agent-browser install

# Rustツールチェーンがある場合（ソースからビルド・2〜3分）
cargo install agent-browser
agent-browser install

# インストールせずに試す
npx agent-browser install
npx agent-browser open example.com
```

macOSで0.39.1の`install`を実行すると、196MBのChrome 156.0.8078.47を`storage.googleapis.com`から取得し、`~/.agent-browser/browsers/`に置きました。npmパッケージには各OS向けのネイティブバイナリが同梱されており、npm 11.17.0で`postinstall`が承認待ちの警告を出してもローカル導入はそのまま動きました。

### Linuxの依存ライブラリとWindowsの注意点

Linuxのサーバーやコンテナでは、Chromeが要る共有ライブラリが足りないことが多く、`agent-browser install --with-deps`で依存パッケージごと入れます。1つでも入れられなければ0以外で終わります。

Windowsはx64のバイナリが配布されています。ARM64機では、ネイティブのARM64実行ファイルがあればそれを、無ければx64版をエミュレーションで動かします（0.35.1で修正）。0.37.1からヘッドレスのChromeは非表示の別デスクトップで起動し、画面に空の枠が残らなくなりました。

### agent-browserの更新・診断・アンインストール

```
agent-browser upgrade                    # 導入経路（npm・Homebrew・Cargo）を判別して更新
agent-browser doctor                     # 環境・Chrome・デーモン・設定・ネットワーク・起動テスト
agent-browser doctor --offline --quick   # ネットワークと起動テストを省く
agent-browser doctor --fix               # Chrome再取得・古い状態ファイル削除など破壊的な修復も行う
```

アンインストール専用のコマンドはありません。`npm uninstall -g agent-browser`か`brew uninstall agent-browser`で本体を消し、完全に消すなら設定・状態・取得したChromeが入った`~/.agent-browser/`も削除します。Playwright側のブラウザ取得の問題は[Playwrightのインストール方法とできない時の対処｜バージョン確認・Windows・Python](/tech/details/3563/)で扱っています。

## agent-browserの基本コマンドと操作手順

### open→snapshot→操作→get→closeの流れ

```
agent-browser open https://example.com
agent-browser snapshot -i              # 操作できる要素だけ（@e1, @e2 …）
# フォームのあるページで、snapshotに表示された入力欄のrefを使う例:
# agent-browser fill @e2 "user@example.com"
agent-browser click "a"
agent-browser snapshot -i
agent-browser get text body
agent-browser screenshot shot.png
agent-browser close                    # 全セッションなら close --all
```

待ち合わせは`wait`で、セレクタ・ミリ秒・`--text`・`--url`・`--load networkidle`を指定できます。公式は`networkidle`を通信が静まると分かっているページに限り、通常はページ固有のセレクタや文字列で待つよう勧めています。操作の既定タイムアウトは25秒（`AGENT_BROWSER_DEFAULT_TIMEOUT`・ミリ秒）で、CLIの応答待ちは通常30秒を下限としますが、wait系などtimeoutを持つコマンドでは、指定タイムアウトに10秒を加えた値と30秒の大きいほうになります。

### batch・JSON出力・readによる一括実行と結果取得

```
agent-browser batch "open https://example.com" "snapshot -i" "get title"
agent-browser snapshot -i --json
agent-browser read https://example.com/article --outline
```

`--json`で結果を機械可読にし、`batch`で往復を減らします。`read`はURLの本文をMarkdownや`llms.txt`を優先して取得し、URLを省けば開いているタブの描画後のDOMを読みます。

## agent-browserのプロキシ設定と通信経路

### プロキシ設定の指定方法と優先順位

[公式のProxyページ](https://agent-browser.dev/proxy)が挙げる指定方法は、CLIフラグ、専用の環境変数、標準のプロキシ環境変数の3系統です。どれが勝つかをソース（`cli/src/flags.rs`）で確かめ、ログを取る検証用プロキシを2つ（AとB）立てて`open https://example.com`がどちらに届くかを見ました。

| 順位 | 指定先                          | 0.39.1での確認             |
| -- | ---------------------------- | ---------------------- |
| 1  | `--proxy`・`--proxy-bypass`   | どの設定よりも優先              |
| 2  | `AGENT_BROWSER_PROXY`        | B指定＋`HTTP_PROXY`\=A→Bへ |
| 3  | `agent-browser.json`の`proxy` | B指定＋`HTTP_PROXY`\=A→Bへ |
| 4  | `HTTP_PROXY`                 | A＋`HTTPS_PROXY`\=B→Aへ  |
| 5  | `HTTPS_PROXY`                | 4が無いときだけ               |
| 6  | `ALL_PROXY`                  | 4と5が無いときだけ             |

つまずきやすいのは4と5です。見つけた1つ目の値がChromeの`--proxy-server`に渡るだけで、スキーム別には使い分けません。`HTTP_PROXY`と`HTTPS_PROXY`が別のシェルでは、HTTPSのページも`HTTP_PROXY`側へ流れます。除外は`--proxy-bypass`→`AGENT_BROWSER_PROXY_BYPASS`→設定ファイル→`NO_PROXY`の順で、`NO_PROXY=example.com`を入れた回はexample.comがプロキシに来ませんでした。

```
# フラグで指定（最優先）
agent-browser --proxy "http://proxy.example.com:8080" \
  --proxy-bypass "*.internal.example.com" open https://example.com

# 専用の環境変数（認証情報はURLに埋めず分けて渡す）
export AGENT_BROWSER_PROXY="http://proxy.example.com:8080"
export AGENT_BROWSER_PROXY_USERNAME="user"
export AGENT_BROWSER_PROXY_PASSWORD="$PROXY_PASSWORD"
export AGENT_BROWSER_PROXY_BYPASS="*.internal.example.com"
```

設定ファイルは`~/.agent-browser/config.json`（ユーザー単位）と`./agent-browser.json`（プロジェクト単位）の2か所で、後者が勝ちます。公式の設定ページにある「環境変数が設定ファイルより強い」は`AGENT_BROWSER_*`の話で、標準の`HTTP_PROXY`は設定ファイルに負けます。

### 認証付きプロキシとSOCKS5

Basic認証を要求するプロキシに`--proxy "http://u1:p1@127.0.0.1:18733"`で接続すると、agent-browserはURLから資格情報を外してChromeに渡し、407が返った時点で認証を送ります。検証では407の後に認証付きのCONNECTが通り、ページ取得まで成功しました。`AGENT_BROWSER_PROXY_USERNAME`と`_PASSWORD`に分けても同じ結果です。資格情報を渡さなかった回は`net::ERR_INVALID_AUTH_CREDENTIALS`で止まりました。

SOCKS5は`ALL_PROXY="socks5://127.0.0.1:1080"`のような認証なしなら通ります。ところが公式ページにある`socks5://user:pass@...`の形は、ユーザー名認証を必須にした検証用SOCKS5サーバーでは`net::ERR_SOCKS_CONNECTION_FAILED`になりました。サーバー側のログでは、Chromeが提示した認証方式は「認証なし（0）」だけで、ユーザー名・パスワード方式（2）を一度も出していません。[Chromiumのプロキシ解説](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md)も「No authentication methods are supported for SOCKSv5 in Chrome」と書いています。認証が要るSOCKSしか無い環境では、手元に認証を肩代わりするHTTPプロキシを挟むか、HTTPプロキシに切り替えてください。

### プロキシを通らない通信：install・doctor・read・localhost

「設定したのに通らない」の多くはブラウザ以外の通信です。Chromeの取得やURL指定の`read`はCLIがRustのHTTPクライアント（reqwest）で行い、`--proxy`も`AGENT_BROWSER_PROXY`も読みません。

| 通信                      | `--proxy` | `HTTPS_PROXY` |
| ----------------------- | --------- | ------------- |
| ページ表示（open等）            | 通る        | 通る            |
| `install`（Chrome取得）     | 通らない      | 通る            |
| `doctor`のネットワーク確認       | 通らない      | 通る            |
| `read <URL>`の取得         | 通らない      | 通る            |
| `localhost`・`127.0.0.1` | 直結        | 直結            |

`--proxy`付きで`install`を実行するとプロキシ側には1件も届かず、Chromeは直接ダウンロードされました。`HTTPS_PROXY`を入れて`doctor --quick`を実行すると、`googlechromelabs.github.io`へのCONNECTがプロキシに届きました。直結が禁止されたネットワークで`install`するなら、シェルに`HTTPS_PROXY`を入れたうえで、`googlechromelabs.github.io`と`storage.googleapis.com`を許可してもらいます。

また、プロキシを指定して`read <URL>`を実行すると、本文はプロキシを通らないのにChromeが1つ起動しました（ドキュメント上はChromeを起動しない）。ローカルの開発サーバーは、`HTTP_PROXY`を入れていても`http://localhost:18740`・`http://127.0.0.1:18740`ともプロキシを通りませんでした。Chromeは72以降、ループバックを暗黙の除外ルールとしてプロキシの対象から外します（前掲のChromiumのプロキシ解説の「Implicit bypass rules」）。

### TLSインスペクションする社内プロキシとCA証明書

通信を復号して検査するプロキシでは、社内CAを信頼させないとHTTPSが失敗します。0.35.0と0.39.0でCA証明書を指定できるようになりました（[v0.39.0のリリースノート](https://github.com/vercel-labs/agent-browser/releases/tag/v0.39.0)）。

- **CLI自身の通信**（`read`・`install`・`upgrade`・`doctor`）：全OSで`--ca-cert <PEM>`か、OSの信頼ストアを使う`--use-system-ca`が効きます。CAファイルの明示指定や保持済み指定がなく、明示的に解除もしていなければ、`SSL_CERT_FILE`を読みます。`--use-system-ca`との併用も可能です。
- **ブラウザ**：`--ca-cert`が効くのはLinuxで起動したChromiumだけです。セッション専用のNSSデータベースに取り込み、ホスト名と有効期限の検証は残します。`certutil`が要るので、`install --with-deps`か`libnss3-tools`を入れます。

macOSで`--ca-cert`付きの`open`を実行すると、「`--ca-cert browser trust is currently supported only on Linux (read, install, upgrade, and doctor accept it on every platform)`」で止まりました。macOSとWindowsのChromeはOSの信頼ストアを使うので、MDMで配った社内CAで通ります。`--ignore-https-errors`は改ざんを検知できなくなるため、本番の資格情報を扱うセッションでは使いません。

### プロキシの切り替えと通信経路の確認

同じセッションで`--proxy`の値を変えると、ブラウザが再起動して新しいプロキシに切り替わりました。一方、次のコマンドでフラグを省いても、直前のプロキシは残ります。プロキシを外したいときは、環境変数と設定ファイルに残るプロキシ指定も解除し、`agent-browser close`でセッションを閉じてから開き直します。

```
agent-browser --proxy "http://proxy.example.com:8080" open https://httpbin.org/ip
agent-browser get text body    # プロキシの出口IPが表示されれば経路は通っている
```

プロキシのログには、開いたページ以外に`accounts.google.com`・`update.googleapis.com`・`www.gstatic.com`など、Chrome自身の通信も載りました。これらは開いたページの読み込みとは別の通信です。プロキシのログを監査に回すなら、Chromeの背景通信とページ由来の通信を区別して集計します。監査用の原本は残し、宛先ドメインだけで一律に除外しないようにします。

## Vercelの保護されたプレビューにAIエージェントを安全に接続する方法

Vercelのプレビューは、Deployment Protection（Vercel認証）でログイン画面へリダイレクトされます。agent-browserには、保護を外さずに通る手順書が[protected-vercel-deploymentsスキル](https://github.com/vercel-labs/agent-browser/blob/main/skill-data/protected-vercel-deployments/SKILL.md)として同梱されています（0.35.0で追加）。保護の無効化、公開例外の作成、固定シークレットの要求は最初の手段にしない、という方針です。

```
export AGENT_BROWSER_SESSION="$(agent-browser session id --scope worktree --prefix vercel-preview)"
(
  TOKEN="$(vc project token my-app --scope my-team)"   # Vercel CLI 53.3.0以降
  test -n "$TOKEN" || exit 1
  agent-browser open "https://my-app-git-feature.vercel.app" --headers \
    "{\"x-vercel-trusted-oidc-idp-token\":\"$TOKEN\"}"
)
agent-browser snapshot -i
```

- 同じプロジェクトのPreviewなら、Vercel CLIが発行する短命のOIDCトークンで通ります。[VercelのTrusted Sources](https://vercel.com/docs/deployment-protection/methods-to-bypass-deployment-protection/trusted-sources)は既定で、development環境からpreviewへの呼び出しを許可しています。
- スキルによると、Vercel CLIの50.25.0〜53.2.xは`vc project token`がトークンを標準エラーへ書くため、変数に入らずログに残るおそれがあります。53.3.0未満なら更新してから使います。
- ヘッダー名は`x-vercel-trusted-oidc-idp-token`です。`x-vercel-oidc-token`は関数へワークロードIDを渡すためのもので、保護の通過には使えません。
- Productionや別プロジェクトへ通すにはTrusted Sourcesのルール追加が要り、ダッシュボードでしか変えられません。エージェントに操作させず、人が設定します。

OIDCが使えないときの代替が、[Protection Bypass for Automation](https://vercel.com/docs/deployment-protection/methods-to-bypass-deployment-protection/protection-bypass-automation)のシークレットを`x-vercel-protection-bypass`ヘッダーで送る方法です。有効化はアクセス制御の変更なので、先に権限者の承認を得ます。`x-vercel-set-bypass-cookie: true`を足すと`_vercel_jwt`クッキーが作られるので、それを含む保存済みの状態ファイルは資格情報として扱います。Vercel自体の仕組みは[Vercel（ヴァーセル）とは？サーバー不要の仕組みとできること・料金【2026年】](/tech/details/2964/)で解説しています。

## agent-browserのセッション管理とログイン状態の保存

### セッションの分離と状態の復元

```
SESSION="$(agent-browser session id --scope worktree --prefix myapp)"
agent-browser --session "$SESSION" --restore open https://example.com
agent-browser close --all
```

`--session`はセッションの分離、`--restore`は状態の自動保存と復元、`--profile`はChromeプロファイルの再利用、`--state`は保存したJSONの読み込みです。復元した状態の失効は`--restore-check-url`・`--restore-check-text`で検出できます。0.37.0からは、新しく開いたタブにもヘッダーや資格情報などのセッション設定が引き継がれます。

### 状態ファイルは既定で平文

READMEは、保存される状態ファイルがセッショントークンを平文で含むと明記しています。暗号化キーを入れない限り、`~/.agent-browser/`配下のファイルを読めばログイン状態を持ち出せます。共有マシンやCIでは先に鍵を設定します。

```
# 初回に生成した鍵をシークレット管理へ保存し、復元時も同じ鍵を設定する
export AGENT_BROWSER_ENCRYPTION_KEY="${SAVED_AGENT_BROWSER_KEY:?保存済みの暗号化キーを設定してください}"   # AES-256-GCM用の64桁の16進
# doctor --fix は暗号化キー設定の代替ではない。修復が必要な場合だけ実行する
# agent-browser doctor --fix   # 鍵が無ければ ~/.agent-browser/.encryption-key を0600で作る（上書きはしない）
```

古い状態ファイルは`AGENT_BROWSER_STATE_EXPIRE_DAYS`（既定30日）を過ぎると`doctor --fix`で消されます。使い捨ての操作なら`--restore`を付けず、終わったら`close --all`で落とすほうが安全です。

## agent-browserのMCPサーバー起動とツール範囲

```
agent-browser mcp                        # 既定のcoreプロファイル
agent-browser mcp --tools core,network   # 必要な範囲だけ足す
agent-browser mcp --tools all            # CLIとほぼ同じ範囲を公開
```

プロファイルはcore・network・state・debug・tabs・react・mobile・webmcp・allの9種です。`all`はeval・クッキー・認証・install・upgradeまで公開するので、モデルが誤って触れる範囲も最大になります。既定のcoreで始め、必要な分だけ足します。MCPで外部ツールを渡すときの危険性は[Playwright MCPのセキュリティ｜危険性とCVE-2025-9611対策](/tech/details/6077/)が参考になります。

0.36.0からは、ページ自身が公開するツールを呼べる実験的なWebMCPに対応しました。ローカルで起動したChromeでは既定で有効で、`--no-webmcp`か`AGENT_BROWSER_NO_WEBMCP`で止められます。自作エージェントから子プロセスで`agent-browser ... --json`を呼ぶ形も一般的です（[Vercel AI SDK v6とは？新機能（ToolLoopAgent・needsApproval）とv7との違い・移行【2026】](/tech/details/10402/)のツール定義から呼べます）。業務に組み込むエージェントの設計は[AIエージェント開発](/service/ai/agent/)でも支援しています。

## 本番で使う前に決めるガードレールと、選ぶべきでない場面

### エージェントの操作権限と通信先の制限

| フラグ                    | 役割                |
| ---------------------- | ----------------- |
| `--allowed-domains`    | 遷移と読み込み先を許可リストで限定 |
| `--action-policy`      | 操作の可否をJSONポリシーで定義 |
| `--confirm-actions`    | 指定カテゴリの操作前に確認を要求  |
| `--content-boundaries` | ページ出力をデータとして囲む    |
| `--max-output`         | 出力文字数の上限          |

`--allowed-domains`は遷移だけでなく、許可外ドメインへのスクリプト・fetch・WebSocket・`sendBeacon`も遮断します。ただし[公式のSecurityページ](https://agent-browser.dev/security)のとおり、WebSocketなどの遮断はコンストラクタの差し替えによるベストエフォートで、OSのファイアウォールの代わりにはなりません。`--action-policy`でevalを禁止し、ホストやネットワーク側の送信制御と組み合わせます。また`--cdp`での既存Chromeへの接続、`--auto-connect`、Chromeプロファイル、状態の復元とは併用できません。0.39.1からは、応答が途中で失われた変更系コマンドは自動で再実行されず、`outcome_unknown`が返ります。エージェント側は結果を確かめてから再試行する作りにします。

### クラウド実行と手元のChromeへの接続

並列数を増やす、手元にブラウザを置けないといった場合は、`-p`（`--provider`）でBrowserless・Browserbase・Browser Use・Kernel・AWSのAgentCoreに寄せます。Python中心なら[Browser Useとは？使い方・料金・Playwright MCPとの違いまで実装ガイド【2026年版】](/tech/details/4743/)も候補です。ログイン済みの手元のChromeを使うなら`--cdp 9222`か`--auto-connect`で、0.39.0からはChrome 144以降のリモートデバッグ許可ダイアログを最大30秒待ちます。

### agent-browserを選ぶべきでない場面

**CIの回帰テスト**には使いません。合否判定を持つPlaywrightやCypressの領分です。

**短命なサーバーレス関数の中で毎回起動する**使い方も合いません。常駐デーモン前提の設計なので、呼び出しごとに破棄される環境では毎回Chromeの起動を待ちます。Vercel上ならVercel Sandboxか外部プロバイダへ逃がします。

**手順が一切変わらない定型処理**にLLMを挟む理由はありません。決め打ちのスクリプトのほうが速く、壊れたときの原因も追えます。

## よくある質問

### agent-browserでプロキシを設定するにはどうすればいいですか？

`--proxy "http://proxy.example.com:8080"`を付けるか、`AGENT_BROWSER_PROXY`を設定します。認証は`AGENT_BROWSER_PROXY_USERNAME`と`AGENT_BROWSER_PROXY_PASSWORD`で分けて渡せ、除外は`--proxy-bypass`か`NO_PROXY`です。標準の`HTTP_PROXY`などは、それらが無いときだけ使われます。

### agent-browser install がプロキシ環境で失敗するのはなぜですか？

`install`は`--proxy`を使いません。シェルに`HTTPS_PROXY`を設定し、`googlechromelabs.github.io`と`storage.googleapis.com`への通信を許可してください。TLSを復号する社内プロキシなら`--ca-cert`か`--use-system-ca`を足します。

### Windowsでも使えますか？

使えます。x64のバイナリが配布され、ARM64機ではネイティブ版が無ければx64版をエミュレーションで動かします。画面を出したいときは`--headed`を付けます。

### npxとグローバルインストール、brewのどれが良いですか？

試すだけなら`npx agent-browser`で足ります。エージェントに繰り返し叩かせるなら、呼び出しごとのパッケージ解決が挟まらない`npm install -g agent-browser`か`brew install agent-browser`です。

### agent-browserはPlaywrightの上に作られているのですか？

いいえ。CLIとデーモンはRustで実装され、ChromeへCDPで直接つながります。Rust製デーモン自体はNode.jsに依存しませんが、npm・npxで導入する場合はNode.jsが必要です。0.39.1のnpmパッケージはNode.js 24以降を要求しています。

### Vercelのプレビューをエージェントに安全に開かせるには？

Deployment Protectionは外さず、`vc project token`（Vercel CLI 53.3.0以降）で得た短命のOIDCトークンを`x-vercel-trusted-oidc-idp-token`ヘッダーで`agent-browser open`に渡します。Productionへ通すルールの追加は人がダッシュボードで行います。

## 関連記事

- [Playwright（プレイライト）とは？仕組み・できること・Seleniumとの違いを解説](/tech/details/3167/)
- [Playwright MCPとは？設定・使い方からDify連携まで実務ガイド【2026年版】](/tech/details/6172/)
- [Stagehandとは｜AIブラウザ自動化の使い方とPlaywrightとの違い【v3対応】](/tech/details/5281/)
- [Chrome DevTools MCPの導入手順と設定｜58ツールの絞り込みと接続方式を実装目線で解説](/tech/details/17749/)
- [Browser Useとは？使い方・料金・Playwright MCPとの違いまで実装ガイド【2026年版】](/tech/details/4743/)

---

出典: [agent-browserの使い方｜Vercel製CLIのプロキシ設定・インストール・MCP連携【0.39対応】](<https://www.issoh.co.jp/tech/details/10588/>)（株式会社一創）