AntigravityとGemini 3.6 Flashでサイト更新からブラウザテストまで回す

2026年7月21日にGemini 3.6 Flashが出て、同日からGoogle Antigravity 2.0の既定モデルになりました。うちのサイト（Astro製のこのcodeagent.jp）を題材に、「Antigravityに記事やUIを更新させて、そのままブラウザで実機テストまでさせる」流れを一次情報ベースで整理します。コードレビューだけで済ませず、エージェント自身にブラウザをクリックさせて確認させるところまでが範囲です。

Gemini 3.6 Flashは何が変わったか

Googleの発表で確認できる範囲だと、ポイントは効率です。

• Artificial Analysis Indexで出力トークンが3.5 Flash比で最大17%減
• マルチステップ作業で推論ステップとツール呼び出しの回数が減った
• コード編集の精度が上がり、「頼んでいない編集」と実行ループのやり直しが減った
• API価格は100万トークンあたり入力$1.50 / 出力$7.50で、トークン単価は3.5 Flashより安い

エージェント用途だと「賢さ」より「余計なことをしない」方が効きます。Flash系は速い代わりに編集が暴発しがちでしたが、3.6はそこを潰しにきた世代です。実際、AntigravityだけでなくGemini APIのマネージドエージェント（antigravity-preview-05-2026）でも既定モデルが3.6 Flashに切り替わっています。

Antigravityで3.6 Flashを使う

手順は拍子抜けするほど少ないです。

1. antigravity.google からAntigravity 2.0をダウンロード（旧版の人はアップデート）
2. Googleアカウントでサインイン
3. Agent Managerのモデルセレクタを確認。既定が3.6 Flashになっているので、選び直す必要は基本なし。難しい設計判断だけGemini 3 Pro系に切り替える

無料枠でも使えますが、レート制限は「エージェントがやった仕事量」に連動する方式で、重いタスクを投げるとすぐ429に当たったという報告が多いです。Google AI Pro / Ultraのサブスクに紐づけると、超過分をAIクレジットでまかなえます。自分はUltra特典側で使っているので無料枠の天井はまだ踏んでいませんが、無料で試すなら「小さいタスクを1個ずつ」が現実的だと思います。

サイト更新の流れ：エージェントが自分で確認しに行く

Antigravityが従来のAIエディタと違うのは、エディタ・ターミナル・ブラウザの3面をエージェントが自分で行き来する点です。サイト更新に当てはめるとこうなります。

各ステップの証跡が「Artifacts」として自動保存されるのが実務では大きいです。エージェントが「直りました」と言うだけでなく、操作録画とスクリーンショットが残るので、あとから検証の妥当性を確認できます。

ブラウザテストの3つの方式

「ブラウザでの直接テスト」には現状3つの入り口があります。GoogleのCodelabが3方式を全部扱っていて、これが一番まとまった一次情報です。

まずIDE内のBrowser Agent。Antigravity 2.0デスクトップに組み込まれていて、Chrome DevTools Protocol（CDP）経由でブラウザを直接操作します。「ログインしてダッシュボードのタイトルを検証して」といった高レベルの指示をCDPコマンドに翻訳し、画面フレームをマルチモーダルで解析しながら進む方式です。録画とスクショが自動でArtifactsに残ります。CLI（agy）からはまだ使えません。

CLI派には残り2つ。BrowserMCPとPlaywrightスキルです。

BrowserMCPの登録は ~/.gemini/config/mcp_config.json に数行足すだけです。

{
  "mcpServers": {
    "browsermcp": {
      "command": "npx",
      "args": ["-y", "@browsermcp/mcp@latest"]
    }
  }
}

Playwrightスキルは、Microsoftのリポジトリから雛形をそのまま持ってきます。

npm install -g @playwright/cli@latest
npx playwright install chromium
npx degit microsoft/playwright-cli/skills/playwright-cli ~/.gemini/skills/playwright-cli

Astroサイトでの実プロンプト例

このサイトで使うならこういう指示になります。Codelabの例をAstro向けに書き換えたものです。

npm run dev でdevサーバーを起動して、Playwrightで http://localhost:4321 に接続。
トップページから最新記事のリンクをクリックして記事ページを開き、
h1が frontmatter の title と一致すること、目次リンクが機能することを確認。
モバイル幅(375px)でも崩れがないかスクリーンショットを output/ に保存して報告。

ポイントは「何をもって合格とするか」を指示に入れることです。「確認して」だけだと、エージェントはページが開けた時点で合格にしがちです。検証条件（タイトル一致、リンク動作、指定幅でのレイアウト）を書くと、Browser Agentは条件を1つずつ潰しに行きます。

それでもレビューゲートは残す

エージェントがブラウザテストまで済ませてくれると、diffを見ずにマージしたくなります。ここは踏みとどまった方がいいです。Browser Agentの検証は「指示した条件を満たしたか」の確認であって、「余計な変更が混ざっていないか」は見てくれません。3.6 Flashで不要編集は減ったとはいえ、ゼロではない。

自分の運用では、Artifactsの録画で挙動を確認したあと、diffだけは人間（かレビュー担当のエージェント）が別途見る二段構えにしています。テストの自動化とレビューの省略は別の話、というのが今のところの結論です。

まとめ

• Gemini 3.6 FlashはAntigravity 2.0の既定モデル。選ぶ操作は不要で、効率と編集精度が上がった
• サイト更新は「依頼→編集→devサーバー起動→ブラウザ実機テスト→Artifacts報告」まで一気通貫で任せられる
• ブラウザテストはIDE内Browser Agentが本命。CLIなら有人確認はBrowserMCP、CI向けはPlaywrightスキル
• 合格条件をプロンプトに明記する。検証の質は指示の具体性で決まる
• ブラウザテストが通ってもdiffレビューは省略しない

Flashクラスに実装と実機検証を任せて、人間は受け入れ基準とレビューに集中する。Claude Code側でやってきた役割分担と同じ形にAntigravityも収束してきた、というのが触ってみた実感です。