アプリの広告管理画面の数字をブラウザエージェントに読ませようとして、返ってきた結果が「Sign in」の一行だけだった朝がありました。普段使いの Chrome ではログイン済みで、ダッシュボードはいつもどおり開けます。それなのに、エージェントの目には入口の扉しか映っていなかったのです。
最初のうちは、エージェントの側が壊れているのだと思い込み、プロンプトを書き直すことを三度繰り返しました。結果は芳しくありませんでした。原因は指示文ではなく、エージェントが操作している Chrome が、私の普段の Chrome とは別物だったことにありました。
最初にお伝えしたいのは、これは不具合というより仕様だということです。同じ場面で足を止めている方が、順番に確かめられる4点を書き残します。
まず、エージェントはどの Chrome を触っているのか
公式ドキュメントによると、Antigravity のブラウザエージェントは、ローカルの Chrome を開いて読み取り・操作を行います。このとき使われるのは「完全に別の Chrome プロファイル」です。個人データを守るための設計で、普段のブラウジングの Cookie やサインイン情報は共有されません。
つまり、私の Chrome でログインしていることと、エージェントがログインしていることは無関係です。ここを取り違えると、いくらプロンプトを磨いても事態は変わりません。
一方で、このプロファイルの中で一度サインインすれば、その状態は残ります。次回以降もアカウントはサインイン済みのままだと、公式ページには書かれています。
確認点1: 触っているのは別プロファイルのウィンドウか
Chrome がすでに開いている状態でエージェントがブラウザを起動すると、別アプリのように Dock に別アイコンが現れます（macOS の場合）。Chrome が開いていなければ、見た目は普段の Chrome とほぼ同じになります。
見た目だけでは判別しにくいので、プロセスの起動引数を見るのが確実です。
# macOS / Linux: Chrome が使っているプロファイルのディレクトリを一覧する
# 環境によって表示は異なります。--user-data-dir の値が2種類出れば、プロファイルが分かれています
ps -axo command | grep -i "[u]ser-data-dir" | grep -o -- "--user-data-dir=[^ ]*" | sort -u値が1種類しか出ないときは、エージェント側のブラウザがまだ起動していないか、判別できていない可能性があります。エージェントにブラウザを開かせたうえで、もう一度実行してみてください。
なぜこう書くかというと、「どちらの Chrome か」という曖昧な状態を、ディレクトリ名という具体に置き換えたいからです。推測で設定を触り始める前に、まず事実を一つ手に入れます。
確認点2: そのプロファイルで、人間が一度サインインしたか
多くの場合、解決はここで済みます。エージェントが起動したウィンドウで、私自身の手で対象サービスにサインインします。二段階認証がある画面は、エージェントに任せず人が通すほうが安全です。
サインインが済んだら、次の依頼ではログイン済みの前提で頼めます。確認用に、私は次のような短い依頼から始めています。
対象サービスのダッシュボード URL を開き、ページ上部に表示されているアカウント名またはメールアドレスだけを答えてください。
サインイン画面が表示された場合は、操作を止めて「未ログイン」と報告してください。読み取る量を最小にして、ログイン状態だけを確かめる依頼です。数字の抽出を頼む前にこの一手間を挟むと、「未ログインなのに該当なしと報告される」という誤読を防げます。
確認点3: URL がアクセス制御に弾かれていないか
公式ドキュメントでは、エージェントがアクセスできる URL は、拒否リストと許可リストの二層で制御されると説明されています。ログイン後のページが開かないとき、サインインの問題ではなく、こちらで止まっているかもしれません。
サインイン画面までは表示されるのに、遷移先のドメインだけが開かない場合は、認証の途中で別ドメインへ飛ぶ構成かもしれません。大手のサービスは認証用に別のドメインを挟むことが多いからです。個別のルールは公式の許可リスト・拒否リストのページで確認し、必要なドメインだけを足します。広げすぎないことが、この確認点のいちばんの注意点です。
確認点4: プロファイルの場所や設定を変えていないか
ブラウザ設定の「Browser」セクションでは、プロファイルの場所を変更できます。場所を変えると、以前サインインしたプロファイルとは別のものを見ている可能性があります。ログイン状態が突然消えたように見えたら、直近で場所や設定を触っていないかを思い出してみてください。
あわせて、同じセクションにある「Browser Tools」のトグルがオフになっていると、ブラウザツール自体が無効になります。ログインの話以前に、そもそも動かない状態です。
整理すると、症状と原因は次のように対応します。
| 見えている症状 | 疑う場所 | 最初にやること |
|---|---|---|
| サインイン画面だけが返る | 別プロファイルで未ログイン | エージェント側のウィンドウで人がサインインする |
| サインイン後に特定ページだけ開かない | 許可リスト・拒否リスト | 弾かれているドメインを特定して必要分だけ許可する |
| 以前は入れたのに急に未ログインになった | プロファイルの場所変更 | 設定の Browser セクションで場所を確認する |
| ブラウザが一切動かない | Browser Tools がオフ | トグルの状態を確認する |
線引き: エージェント用の別プロファイルには、渡す権限も別にする
別プロファイルだと分かって、いちばん悩んだのは「ここに本命のアカウントでサインインしてよいのか」という点でした。便利さを優先すれば、管理者権限のあるアカウントで入るのが手っ取り早いのです。
私は、閲覧だけに絞った権限のアカウントを用意して、そちらでサインインする形にしています。エージェントが操作を誤ったときの影響範囲を、最初から小さくしておくためです。
エージェントに渡すのは、ログインではなく、閲覧できる範囲のほうです。 この線引きだけは、急いでいる日でも崩さないようにしています。
なお、同じブラウザエージェントでも、ページの描画待ちで空に見える問題はまた別の原因です。そちらは Antigravity の Browser Sub-Agent が SPA を空ページと誤認する原因と待機戦略 に、実際の運用の様子は AdMob メディエーション順位を Antigravity の Browser Sub-Agent に任せた2週間の所感 にまとめています。
次の一歩
今日できるのは一つだけです。エージェントにブラウザを開かせて、そのウィンドウで対象サービスにサインインし、上の短い依頼文で「アカウント名だけ答えて」と頼んでみてください。
答えが返ってきたら、ログイン状態は整っています。返ってこなければ、確認点3から順に辿っていただければ、原因はだいたいそこに見つかります。私も、いまだにこの順番で確かめています。