Antigravityのブラウザ操作｜設定とできない時の原因3つ

Antigravityのブラウザ操作は、/browserと打てばそのまま動くものではありません。つまずくのは機能そのものではなく許可の設計です。エージェントは普段のChromeではなく専用プロファイルで動きます。開けるURLは初期状態でlocalhostだけです。さらに、ページを読む権限とクリックする権限は別々に分かれていて、どちらも既定は毎回確認するAskです。承認のボタンはタスクの進捗の中に「Pending Steps」としてまとめて出るため、そこを開かないかぎりエージェントは待機したままになります。この記事では、/browserでの呼び出し方と、公式ドキュメントで確認できる設定項目を整理しました。allowlistとdenylistの二層判定、動かないときの原因3つと直し方も、Google公式ドキュメントの記述と突き合わせて確かめています。ログイン状態が毎回消えて見える理由は、専用Chromeプロファイルの項目で扱います。

Antigravityのブラウザ操作とは？エージェントがChromeで何をするのか

Antigravityのブラウザ操作とは、エージェントがローカルのChromeを起動し、ページを読み、クリックや入力まで実行する機能です。公式ドキュメントの書き出しは「Google Antigravity can open, read, and actuate a local Chrome browser」となっています。閲覧だけでなく、画面を実際に動かすところまでが範囲に入ります。主な用途は、開発中のサイトの動作確認、ドキュメントの読み取り、繰り返しのブラウザ作業の自動化です。

実行を担当するのは、汎用のエージェント本体ではなくbrowserという専用のサブエージェントです。公式のサブエージェント一覧は「Operates sandboxed web browsers to perform interactive browser testing」と説明しています。そこには起動経路が/browserスラッシュコマンドのみである点も明記されています。この経路を知らずに「ブラウザで確認して」と自然文で頼み続けると、いつまでも起動しません。

あなた ──「/browser このページのフォームを送信して」
   ↓
メインのエージェント
   ↓
browser サブエージェント（/browser でのみ起動する）
   ↓
専用プロファイルの Chrome を起動
   ↓
URL の判定
   ・第1層 denylist（サーバに問い合わせ）
   ・第2層 allowlist（ローカルの許可ファイル）
   ↓ 通過した URL だけ
タブを開く／読む／クリック・入力する
   ↓
スクリーンショット＋操作の録画 → Artifact として保存

ブラウザ操作でできること

公式が挙げている用途は3つあります。開発中のサイトのテスト、ドキュメントを情報源として読むこと、ブラウザ上の定型作業の自動化です。実務に置き換えると、ローカルサーバーで立ち上げた画面をエージェント自身に開かせ、表示崩れを確認させる使い方になります。フォームに値を入れて送信まで通す、管理画面の数値を拾ってレポートに書き起こす、といった流れも同じ枠です。コードを書いた本人ではなくエージェントが動作確認まで担当する点が、従来のコード補完型ツールとの分かれ目になります。ツール全体の位置づけはAntigravityとCursorの比較記事で整理しています。

操作の記録はスクリーンショットと動画で残る

ブラウザ操作の結果は、文章の報告だけでは終わりません。Browser Overviewには「capturing screenshots and saving action videos as interactive artifacts」と書かれています。つまり、静止画のスクリーンショットと操作の動画が、どちらもArtifactとして残ります。

動画についての記述はさらに具体的です。「Every time the browser subagent actuates on the Browser, it may choose to generate a recording of the agent’s actions for your review」と記されています。操作のたびに録画が生成される場合がある、という書き方です。録画はBrowserステップのUI下部で再生でき、同時にrecording artifactとしても保存されます。エージェントが「送信できました」と言ったときに、本当にボタンを押したのかを目で確認できる仕組みです。

ブラウザ操作の使い方｜/browserコマンドで呼び出す4ステップ

使い方は、Chromeを既定ブラウザにする、/browserで指示を書く、承認に答える、記録を確認する、の4段階です。順に見ていきます。

ステップ①Chromeを既定ブラウザにする

Google公式のCodelabsは、/browserコマンドの条件を明示しています。「requires Google Chrome browser to be your default browser to start a debugging session」という一文です。デバッグセッションを張る都合上、既定ブラウザがEdgeやSafariのままだと最初の一歩で止まります。切り替えは、macOSならシステム設定のデスクトップとDock、Windowsなら設定の既定のアプリから行えます。本体のインストールと初回設定がまだなら、Google Antigravityの導入と日本語化の手順を先に済ませてください。この後に出てくる画面名が一致します。

ステップ②/browserで指示を書く

チャット欄で/を打つとスラッシュコマンドの候補が出るので、/browserを選びます。そのうえで、開く場所と、そこで何をしてほしいかを1文で続けます。指示が「確認して」だけだと、エージェントは何をもって完了とするかを判断できません。合否の条件まで書くと、録画を見返したときの判定が早くなります。

/browser http://localhost:3000/contact を開いて、
氏名・メール・本文を埋めて送信し、
完了メッセージが表示されるかを確認してください。
表示されなければ、コンソールのエラーも拾ってください。

ステップ③read_urlとexecute_urlの承認に答える

Codelabsは/browserの動きを「spawns up a browser sub-agent that attempts to launch a debugging session with Chrome and asks your permission first」と説明しています。つまり、最初に出てくるのは許可の確認です。この許可は2種類に分かれます。公式の権限ドキュメントによると、read_urlがページの読み込みと表示を、execute_urlがクリックや入力といった操作を管轄します。どちらも既定はAskで、承認するまでエージェントは待機したままです。

承認プロンプトが出る場所

承認のボタンは、タスクの進捗ログの中に出ます。公式のTools & Task Groupsには「Sometimes, there are pending steps, such as browser setup or terminal commands requiring approval, that are created inside these progress updates」と書かれています。進捗の更新が折りたたまれていると、待機していること自体に気づけません。反応がないと感じたら、ログを上から追うより先にタスクの末尾を開きます。

AskがAllowに勝つ理由

権限はDeny、Ask、Allowの順で評価されます。強い指定が先に当たる設計です。execute_url(*)をAskに残したまま特定ドメインだけAllowにしても、Askが先に当たって毎回止まります。承認の回数を減らしたいなら、Askの側に広い指定を置かないことが前提になります。

read_urlとexecute_urlはどう組み合わさるか

2つの権限をAllow、Ask、Denyのどれにすると何が起きるかを、公式の記述に沿って並べます。

実務で使いやすいのは、read_urlだけAllowにして、execute_urlはAskに残す組み合わせです。読むところまでは自動で進み、クリックや入力の手前で必ず止まります。調査目的でページを読ませたいだけなら、これで足ります。なお指定はホスト名で照合され、サブドメインまで一致します。パス部分は無視されます。

ステップ④録画とスクリーンショットで結果を確かめる

実行が終わったら、Browserステップの下部に出る再生と、Artifactに保存された録画を見ます。指示どおりのボタンを押しているか、途中で別のページへ飛んでいないか。この2点は、文章の報告よりも録画のほうが速く判断できます。フォーム送信や決済画面のように取り返しのつかない操作を任せたときほど、報告文より先に録画を開くという運用にすると安全です。

ブラウザ操作の設定はどこにある？Browserセクションの項目

設定はUser Settingsの「Browser」セクションにあります。ただし、公式ドキュメントがこのセクションの項目として名前を挙げているのは2つだけです。ブラウザツールを丸ごと止める項目と、専用Chromeプロファイルを作る場所を変える項目です。JavaScript実行の扱いは、Settingsページのstrict modeの説明のなかで触れられています。

ここで注意したい点があります。これらの項目の初期値は、公式ドキュメントに書かれていません。Browser Toolsが最初からオンなのか、Browser Javascript ExecutionがStrict Mode以外でどう動くのかは、2026年9月時点の公開情報からは確認できません。初期値がはっきり書かれているのはallowlistだけで、Allowlist / Denylistのページにlocalhostのみと明記されています。

Strict Modeを入れると何が変わるのか

Strict Modeは、エージェントの外部アクセスを一段締めるモードです。公式ドキュメントによると、ブラウザまわりでは2つの変化があります。

allowlistとdenylistがMarkdown画像とRead URLにも適用される

公式ドキュメントの「Browser URL Allowlist/Denylist」という見出しは、Browserセクションの設定項目ではありません。strict modeの説明の一部として置かれた見出しです。Strict Modeでは、外部のMarkdown画像とRead URLツールの自動実行が、allowlistとdenylistの判定に従います。画像については「The Agent will only render images from URLs that are allowed」と書かれています。許可されていないURLの画像は描画されません。Read URLツールも、許可済みのURLでしか自動実行されなくなります。

JavaScript実行が毎回確認になる

もう1つは、Browser Javascript Executionが「Request Review」へ固定される点です。JavaScriptを走らせる前に、必ず確認が入ります。同時に、ターミナルコマンドの自動実行とArtifactのレビューも「Request Review」へ変わります。ターミナル側については、allowlistそのものが無視される点まで書かれています。共有端末や受託案件の環境なら、Strict Modeを既定にしておくと事故が起きにくくなります。

通常時とStrict Mode時で変わるところ

公式ドキュメントに記載のある範囲で、2つの状態を並べます。

allowlistとdenylistはどう動く？初期値はlocalhostだけ

allowlistとdenylistは、URLを二層でふるいにかける仕組みです。denylistが危険なURLを止め、allowlistが信頼したURLを通します。この2つは対等ではなく、denylistが常に優先されます。

ブラウザが URL を開こうとする
   ↓
［第1層］denylist の照会
   ・ホスト名をサーバへ問い合わせて判定する
   ・該当したら拒否。allowlist に足しても覆せない
   ・サーバに到達できない場合は、既定で拒否
   ↓ 該当なし
［第2層］allowlist の照合（ローカルのテキストファイル）
   ・載っている   → そのまま開く
   ・載っていない → 「always allow」の確認が出る
                    押すと allowlist に追加される
   ↓
ページを開いて操作できる

denylistが常に優先される

denylistは端末側のリストではありません。Googleが運用するBadUrlsCheckerというサービスで維持されています。ブラウザがURLへ移動しようとするたびに、ホスト名がサーバ側のdenylistへ問い合わせられる設計です。公式ドキュメントには「If the server is unavailable, access is denied by default」という注記があります。照会先に届かないときは通さない、という判断です。社内ネットワークの制限やオフライン環境でブラウザ操作が全滅するなら、この既定拒否が疑わしい候補になります。回線を切り替えて再現するかどうかで切り分けられます。

allowlistにURLを足す2つの方法

allowlistはローカルのテキストファイルで、いつでも編集できます。初期状態で入っているのはlocalhostだけです。追加する方法は2つあります。

always allowボタンを押す

許可していないURLへ移動しようとすると、確認が出ます。そこで「always allow」ボタンを押す方法です。押した時点でallowlistへ追記され、そのページを開いて操作できるようになります。手を動かす量がいちばん少ない足し方です。

ファイルを直接編集する

もう1つは、allowlistのテキストファイルを開いて、行を足したり消したりする方法です。複数のドメインをまとめて登録するときや、案件が終わって不要になったドメインを外すときは、こちらが速く済みます。ただし公式ドキュメントには「you cannot allowlist a URL that appears on the denylist」と書かれています。denylistに載っているURLは、手で足しても通りません。

ログイン状態が引き継がれないのはなぜ？専用Chromeプロファイルで動くから

普段のChromeでログイン済みのサイトが、エージェントの操作ではログアウト状態に見える。この理由は別のChromeプロファイルで動いているからです。公式ドキュメントの説明は「Since Chrome profiles are isolated, this will not share any of the cookies or sign-in information from your normal browsing profile」となっています。Cookieもサインイン情報も、普段の環境からは引き継がれません。

［普段の Chrome プロファイル］      ［Antigravity 用の別プロファイル］
 ・自分のブックマーク                ・エージェントが操作するのはこちら
 ・自分の Cookie / ログイン          ・Cookie もログインも普段の分とは別
 ・自分が入れた拡張機能              ・一度サインインすれば次回も保持される
          │                                    │
          └────── 共有されない ──────┘

 ※ 普段の Chrome を開いたまま起動すると、別アイコンの
    アプリケーションとして並ぶ
 ※ Chrome を開いていなければ、見た目は既定プロファイルと同じ
 ※ 元へ戻すには、いったん終了して Chrome を起動し直す

ログインが必要なサイトを操作させる手順

やることは単純です。エージェントが開いたそのウィンドウで、いつもどおりサインインするだけで済みます。公式ドキュメントには「all sign-ins will be persisted such that anytime you open the browser in the future, all your accounts will still be there」と書かれています。一度入れておけば次回以降も保持されるので、毎回入り直す必要はありません。プロファイルの分離は、セキュリティ上の面倒ごとではなく業務アカウントと検証アカウントを分けられる仕組みと考えたほうが実態に合います。本番の管理画面へ入るアカウントを、エージェント用プロファイルにはあえて入れない。そういう運用も取れます。

普段のプロファイルに戻す方法

専用プロファイルのChromeは、通常のChromeとは別のアプリケーションとして扱われます。普段のChromeを開いた状態で起動すると、別アイコンが並びます。逆にChromeを開いていない状態で起動すると、見た目は既定プロファイルと変わりません。そのまま普段のブラウジングを続けてしまいがちな場面です。元のプロファイルへ戻すには、いったんそのアプリケーションを終了し、Chromeを起動し直します。プロファイルの作成場所を変えたいときは、Browserセクションの設定から指定できます。

Antigravityのブラウザ操作ができない3つの原因と直し方

ブラウザ操作が動かないとき、原因はほぼ3つに収まります。既定ブラウザ、設定と権限、URLの許可です。上から順に潰していくと、当てずっぽうに再インストールするより早く切り分けられます。まず、画面に出ている症状から原因を引いてください。

原因①Chromeが既定ブラウザになっていない

最初に疑うのはここです。Google公式のCodelabsが、デバッグセッションを開始する条件としてChromeが既定ブラウザであることを挙げています。既定がEdgeやFirefoxのままだと、/browserを打っても起動段階で止まります。Chromeがそもそも入っていない環境でも同じです。ただし、エージェント自体が立ち上がらない、アプリが落ちるといった症状なら、ブラウザ側ではなく本体側の問題です。その場合はAntigravityが起動しないときの対処を先に確認したほうが早く解決します。

原因②Browser Toolsがオフか、権限がAskで止まっている

公式ドキュメントには「To completely disable browser tools, you can toggle the Browser Tools setting in the ‘Browser’ section of the User Settings」と書かれています。この項目をオフにすると、ブラウザ関連のツールは丸ごと使えません。社内配布のプロファイルを適用した端末では、意図せずオフになっていることがあります。

もう1つ多いのが、承認待ちで止まっているだけのケースです。公式の権限ドキュメントは「Actions for read_url and execute_url default to Ask」と明記しています。既定では、読み込みも操作も毎回確認されます。承認ボタンが画面下部の折りたたまれた領域にあると、止まっていることに気づかないまま待ってしまいます。Tools & Task Groupsのページには「pending steps, such as browser setup or terminal commands requiring approval」という記述があります。承認待ちの項目は、進捗の更新のなかにPending Stepsとして作られる設計です。まずそこを開きます。

権限を先に許可しておく書き方

毎回の承認をなくしたいドメインは、Allowリストへ書いておきます。指定はホスト名で照合され、サブドメインまで一致します。公式ドキュメントの記法に沿うと、次のような書き方になります。

# Allow list — 確認なしで実行する
read_url(localhost)              # ローカルの開発サーバを読む
read_url(example.com)            # 自社サイトをサブドメインまで読む
execute_url(localhost)           # ローカル画面のクリック・入力を任せる

# Ask list — 毎回止めて確認する
execute_url(admin.example.com)   # 本番管理画面の操作は都度確認する

Askリストに広い指定を残すと、Allowに書いたドメインまで毎回止まります。Deny、Ask、Allowの順で評価されるためです。承認を減らしたいなら、Ask側は本当に止めたいドメインだけに絞ってください。

原因③URLがallowlistに無い、またはdenylistに載っている

allowlistの初期値がlocalhostだけである以上、外部サイトを開こうとすれば止まります。これは正常な動作です。「always allow」の確認が出ているなら、押せば通ります。確認すら出ずに拒否されるなら、denylist側で止まっている疑いが濃厚です。denylistの判定はサーバへの問い合わせで行われ、その問い合わせ先へ届かないときも既定で拒否されます。社内プロキシやVPN配下で全URLが通らないなら、回線を変えて再現するかどうかが切り分けの手がかりになります。

それでも動かないときに確認する3つ

3つの原因を潰しても解決しないときは、Strict Modeの有無、Browser Javascript Executionの状態、モデルの利用枠を見ます。Strict Modeが有効だとJavaScript実行が毎回確認になるため、動きが止まったように見えます。利用枠については、ブラウザ操作が枠を消費するかどうかを公式ドキュメントが明記していません。ただ、エージェント自体が応答しない状態ではブラウザ操作も進みません。残量の考え方はAntigravityの制限とリセット周期で確認しておくと、切り分けが早くなります。

ブラウザ拡張機能は必要？ストアで探さず/browserから始める

結論から書くと、ストアで拡張機能を探す必要はありません。編集部が2026年9月時点でantigravity.googleのサイトマップに含まれるドキュメントURLを全件確認しました。ブラウザ関連の公式ページはBrowser Overview、Allowlist / Denylist、Separate Chrome Profile、Browser Recordingsの4本です。拡張機能単体の解説ページは存在しませんでした。検索で公式の案内にたどり着けないのは、そもそも用意されていないためです。

公式ドキュメントとGoogleのCodelabsが説明している導線は、拡張機能を先に入れる形ではありません。/browserを実行し、エージェントがデバッグセッションの許可を求めてきた時点で、画面の案内に従って進める形です。手順を逆から始めると詰まります。

セットアップの承認はタスク内の「Pending Steps」に出る

公式のTools & Task Groupsには、承認が必要な項目としてブラウザのセットアップとターミナルコマンドが挙げられています。これらは進捗の更新のなかにPending Stepsとして作られます。進捗をすべて展開しなくても、承認用の区画をまとめて開ける設計です。「案内が出ない」と感じたときは、進捗ログを上から追うのではなく、タスクの一番下を先に見ます。

本番サイトを触らせるときの安全な設定

ブラウザ操作は、ファイル編集と違って取り消しができません。送信したフォームも、押した削除ボタンも戻せないためです。仕様上の制約ではありませんが、次の3点を先に決めてから使うと事故が起きにくくなります。

①allowlistは案件ごとに絞る

allowlistはローカルのテキストファイルなので、案件をまたいで使い回すと許可済みドメインが際限なく増えます。初期値がlocalhostだけという設計は窮屈に見えますが、無関係なサイトへ迷い込ませないための安全弁です。案件が終わったら、その案件で足したドメインを外す。この運用にすると、許可の範囲が広がりっぱなしになりません。

②execute_urlは本番ドメインでAskのまま残す

read_urlを許可しても、execute_urlを許可しなければクリックや入力は走りません。本番の管理画面や決済まわりのドメインは、読むところまでを自動にして、操作は毎回自分の目を通す。この形にしておくと、想定外の操作が本番へ届く前に止まります。承認の手間は残りますが、1回止められれば十分に見合います。

③録画Artifactを事後確認の証跡にする

操作の録画は、うまくいったかを確かめる用途だけではありません。何をしたかを後から説明する材料にもなります。クライアントの環境で確認作業を任せた場合、「どのページで何を押したか」を録画で示せると話が早く進みます。ブラウザ操作を人に任せるときと同じ管理を、エージェントにも当てはめる考え方です。設計そのものの比較は、ClaudeのComputer Useを試した記事と読み比べると違いがはっきりします。

まとめ｜ブラウザ操作は「許可の設計」で決まる

Antigravityのブラウザ操作を動かせるかどうかは、機能を理解しているかよりも、3つの条件が揃っているかで決まります。既定ブラウザがChromeであること、Browser Toolsがオンであること、そして開きたいURLがallowlistとdenylistの二層判定を通ることです。この3つが揃えば/browserは動き、揃わなければ何度打っても止まります。

導入直後にまず試すなら、ローカルサーバーを立ち上げて/browserでその画面を開かせるところから始めるのが安全です。localhostは最初から許可されているため、allowlistを触らずに挙動を確認できます。そこで録画Artifactの見え方まで確かめてから、外部ドメインを1つずつ足していく。この順序なら、想定外の操作を招きにくくなります。本体の導入と初期設定はGoogle Antigravityの使い方、起動そのものが不安定なときは起動しないときの対処にまとめています。

• 出典：Google Antigravity Docs「Browser Overview」（antigravity.google/docs/ide/browser）
• 出典：Google Antigravity Docs「Allowlist / Denylist」（antigravity.google/docs/ide/allowlist-denylist）
• 出典：Google Antigravity Docs「Separate Chrome Profile」（antigravity.google/docs/ide/separate-chrome-profile）
• 出典：Google Antigravity Docs「Browser Recordings」（antigravity.google/docs/ide/browser-recordings）
• 出典：Google Antigravity Docs「Asynchronous Subagents」（antigravity.google/docs/subagents）
• 出典：Google Antigravity Docs「Agent Permissions」（antigravity.google/docs/permissions）
• 出典：Google Antigravity Docs「Settings」（antigravity.google/docs/ide/settings）
• 出典：Google Antigravity Docs「Tools & Task Groups」（antigravity.google/docs/tools）
• 出典：Google Codelabs「Getting Started with Google Antigravity」（codelabs.developers.google.com）
• 上記は編集部が2026年9月4日に各ページを参照して確認した内容です。仕様は更新が続くため、最新は公式ドキュメントで確認してください。