ANTIGRAVITY LABEN
記事一覧/Agents & Manager
Agents & Manager/2026-07-04上級

エージェントが実ブラウザで自己デバッグするとき、証跡と承認をどこに置くか

Antigravity 2.0 はビルド中に実際の Chrome を起動し、ボタン操作やスクリーンショットで自己修復します。速さは魅力ですが、そのまま本番に出すのは危険です。証跡の残し方と承認境界の引き方を設計します。

Antigravity 2.014ブラウザエージェント2自己デバッグ2検証設計エージェント運用8

プレミアム記事

Antigravity 2.0 は、ビルドの途中で実際の Chrome を立ち上げます。生成したUIを自分で開き、ボタンを押し、フォームに文字を入れ、スクリーンショットを撮り、DevTools を人間が開かなくても不具合を見つけて直そうとします。初めて見たときは、正直に言って少し怖くなりました。速いのです。数分で「動くように見えるもの」が返ってきます。

問題は、その「見える」の中身です。エージェントが何を確認し、どのボタンを押し、どこで直したのかが手元に残らないと、本番に出す判断ができません。速さと引き換えに、検証の透明性が失われては本末転倒です。実ブラウザ自己デバッグを日常運用に組み込むために、証跡(evidence)の残し方と、承認境界の引き方を具体的に設計していきます。

なぜ実ブラウザ自己デバッグは速く、そのままでは怖いのか

従来のエージェントは、コードを書いて「たぶん動く」と言い切るところで止まりがちでした。実ブラウザ自己デバッグは、その先の「実際に開いて確かめる」までを一続きで行います。レンダリング崩れ、クリックしても反応しないボタン、コンソールに出ている例外——これらは静的解析では拾えません。実際に触ってはじめて分かる不具合を、エージェント自身が拾って直せるのは大きな前進です。静的解析だけの検証に比べ、実際に触る検証は不具合の発見率が体感で2倍近く上がります。

一方で、実ブラウザは副作用を持ちます。フォーム送信は本物のリクエストを飛ばし、リンクは本物のページに遷移します。もし開発用と本番用の環境が曖昧なまま自己デバッグが走れば、テストのつもりが本番データを書き換えてしまう可能性があります。さらに、修復の過程が記録されなければ、「なぜ直ったのか」も「本当に直ったのか」も後から検証できません。

つまり必要なのは、速さを殺さずに二つを足すことです。ひとつは証跡、もうひとつは承認境界です。

証跡を3層で残す

自己デバッグの一回の実行を「run」と呼び、run ごとにタイムスタンプ付きのディレクトリを切ります。その中に3種類の証拠を残します。スクリーンショットは人間が一目で状態を掴むため、DOM スナップショットは差分比較のため、ネットワークログはどんな副作用が起きたかを確かめるためです。

残すもの役立つ場面
スクリーンショット各ステップ前後のPNG崩れ・空白・エラー画面を目視で即判定
DOMスナップショットouterHTMLの整形テキストrun間の差分(textダイフ)で「何が変わったか」を機械比較
ネットワークログメソッド・URL・ステータス・宛先ホスト本番宛のPOST等、危険な副作用の検知

次のスクリプトは、Playwright でブラウザセッションをラップし、エージェントが操作するたびに3層を保存する最小の実装です。エージェントのブラウザ操作を、この薄いラッパー越しに実行させる前提です。

// evidence-session.mjs — 実ブラウザ操作を証跡付きで包む薄いラッパー
import { chromium } from 'playwright';
import { mkdir, writeFile, appendFile } from 'node:fs/promises';
import { join } from 'node:path';
 
const RUN_ID = new Date().toISOString().replace(/[:.]/g, '-');
const RUN_DIR = join('evidence', RUN_ID);
 
export async function openEvidenceSession() {
  await mkdir(RUN_DIR, { recursive: true });
  const browser = await chromium.launch({ headless: false });
  const context = await browser.newContext();
  const page = await context.newPage();
 
  // ネットワーク層: すべてのレスポンスを1行JSONで追記
  page.on('response', async (res) => {
    const req = res.request();
    const line = JSON.stringify({
      t: Date.now(),
      method: req.method(),
      url: res.url(),
      status: res.status(),
      host: new URL(res.url()).host,
    });
    await appendFile(join(RUN_DIR, 'network.jsonl'), line + '\n');
  });
 
  let step = 0;
  // スクリーンショット層 + DOM層をステップ単位で保存
  async function capture(label) {
    const n = String(++step).padStart(3, '0');
    await page.screenshot({ path: join(RUN_DIR, `${n}-${label}.png`) });
    const html = await page.evaluate(() => document.documentElement.outerHTML);
    await writeFile(join(RUN_DIR, `${n}-${label}.html`), html);
    return n;
  }
 
  return { browser, page, capture, RUN_DIR };
}

このラッパーの狙いは、エージェントの操作を止めないことです。人間が逐一確認するのではなく、あとから確認できる材料を黙って積み上げます。速さは維持したまま、検証可能性だけを足します。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
実ブラウザ自己デバッグの結果を「スクリーンショット・DOMスナップショット・ネットワークログ」の3層で証跡化する具体的な保存レイアウト
読み取りは自動・書き込みと本番URLは人間承認、という境界をコードで強制するガードの実装
同じ修復を再現するための実行シード固定とrun-idの付け方、非決定性を減らす運用手順
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

Agents & Manager2026-06-28
Antigravity の計画を、承認する前に削る
Planning モードが出してきた実行プランを、丸ごと承認するのではなく、危険なステップだけ削ってから渡す。部分編集という運用を、個人開発の現場目線で整理しました。
Agents & Manager2026-06-27
dynamic sub-agents が枝分かれしすぎる前に — 深さ予算とファンアウト上限の設計
Antigravity 2.0 の dynamic sub-agents は実行中に自分でサブエージェントを生やせます。便利ですが、深さとファンアウトを制御しないとトークン予算を一晩で溶かします。3つのガードの実装を具体コードで示します。
Agents & Manager2026-06-13
並列エージェントの変更を、後から追えるようにする設計
Antigravity 2.0 は複数エージェントの管制塔になりました。誰が・なぜ・何を変えたのかを後から追える監査トレイルの作り方を、実運用の失敗から設計します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →