Google Antigravity(Gemini)は圧倒的なコンテキスト容量を誇る一方、既存のパイプラインを無視して不要なブラウザ操作を実行し、トークンを枯渇させてしまう問題が発生します。プロンプトによる制約で暴走は抑えられたものの、人間の確認コストが増える新たな課題が浮き彫りになりました。
困ったもんです。
なぜAntigravityはブラウザ操作でトークンを使い切るのか
Antigravityは巨大な情報量を保持できる広大なコンテキストウィンドウを持っています。しかし、タスクの実行手順において、既に構築されているハーネスやパイプラインを使わず、自発的にブラウザ操作を開始してしまう現象が見られます。

ブラウザの自動操作はDOM解析や画面のレンダリング処理が伴うため、消費トークン数が急増します。その結果、作業が完了する前にトークン上限に達し、処理が停止します。どれほど広い倉庫があっても、作業動線が非効率では実用性に影響が出るという感じです。
プロンプト制約による効果と発生した運用課題
無駄な行動を抑制するため、プロンプトへ以下の2つの制約を追加して検証をしてみました。
「ブラウザ操作をしないでね。」
「問題が発生したら勝手に進めず相談してね。」
この指示により、意図しないブラウザ操作やトークンの急激な消費は防ぐことができましたが、エラーや判断の分岐点に差し掛かるたびAIが人間に指示を仰ぐので、手動での対応回数が大幅に増加しました。トークン枯渇は回避できたものの、作業自動化という目的からは本末転倒な状況ですね。
自律型AI(Claude・Gemini)を連携させた環境構築へ
スムーズなタスク実行が得意なClaudeと、大容量コンテキストを保持できるAntigravity(Gemini)には、それぞれ異なる長所が存在します。
| AIモデル / 環境 | 主なメリット | 運用の課題 |
| Google Antigravity (Gemini) | 大規模な長文コンテキストの保持力 | 非効率な動線によるトークン早期消費 |
| Claude (Pro / Max) | タスク実行の滑らかさと高い指示順守率 | 契約プランに応じた利用制限 |
単一のプロンプト調整のみで制御するのではなく、情報の集約とタスクの実行をそれぞれの適性に応じて切り分ける自律型連携システムの構築が必要です。


