Antigravityを使っているとき、ある種類の失敗だけretryで抜けられなくなる瞬間があります。エラーメッセージはわずかに変わるのに、結局同じ箇所で詰まる。5回、10回と押し続けても前に進まありません。この状態に陥った方は多いのではないでしょうか。
私もAntigravityでエージェントに大きめの作業を任せる時に、この「堂々巡りのretry」で数時間を溶かしたことがあります。結論から申し上げると、retryを押し続けるべきではない瞬間があって、そこで手を止めて切り分けないと永久に抜けられません。
ここでは私が実際に使っている「retryで抜けられない時の切り分けフロー」を、症状別に整理してお伝えします。
なぜretryが効かないのか：3つのタイプ
Antigravityのretryは、直前の試行のコンテキストをある程度引き継いで再実行します。つまり、直前の試行で間違ったアプローチを取っていた場合、同じ間違いを微調整しながら繰り返すだけになります。これが堂々巡りの本質です。
症状は大きく3タイプに分かれます。
タイプA: 情報不足型
エージェントに必要な情報が根本的に足りていないケースです。外部APIの仕様、プロジェクト内のコーディング規約、テストの想定動作などが欠けていると、retryで何度試しても同じ誤解が続きます。症状としては、同じタスクに対して毎回違う「もっともらしく見える実装」が出てきます。
タイプB: 判断基準欠落型
エージェントが「成功とは何か」を理解していないケースです。テストを通すのがゴールなのか、ビルドが通ればいいのか、特定の仕様に従うのか、この優先順位が曖昧だと、retryのたびに異なる基準で動いてしまいます。症状としては、「修正したはずなのに別のテストが壊れた」が繰り返されます。
タイプC: ループ型
エージェントがAとBの変更の間を行ったり来たりするケースです。「aを変更 → bを変更 → aを元に戻す → bを元に戻す」というパターンです。症状としては、diffを見ると前の試行と同じファイルを反対向きに編集しています。
retryで抜けられるのはごくマイナーなタイプC初期のみで、AとBは人間が介入しないと止まりません。
切り分けフロー：retryを3回押しても進まなかったら
私のルールは単純で、retryを連続3回押しても前進が感じられなかったら、その時点でretryをやめて切り分けを始めます。4回目以降のretryは、時間とトークンの浪費になることがほとんどです。
Step 1: 直前のdiffを読む
まず、3回分のretryがそれぞれ何を変更したかを確認します。Antigravityのチャット履歴で、各試行のdiffを並べて見てください。
次の観点でチェックします。
- 3回とも同じファイルを編集していないか（タイプC: ループ型の兆候）
- 編集対象のファイルが毎回大きくずれている（タイプA: 情報不足型の兆候）
- 編集内容は一貫しているのにテストの落ち方だけが変わる（タイプB: 判断基準欠落型の兆候）
この観察だけで、症状の8割はタイプ分類できます。
Step 2: 追加情報をプロンプトに流し込む
タイプAなら、欠けている情報を補います。具体的には次のようなものを追加します。
## Context for this task
- 関連するAPI仕様: https://... のエンドポイント /foo は POST で
{ "bar": string } を受け取り、{ "baz": number } を返します。
- このプロジェクトでは async/await を使い、Promise.then は使いません。
- テストは tests/foo/ 配下の既存テストを壊さないことが必須です。
Antigravityはコードベースをある程度読みますが、外部仕様と暗黙ルールは読んでくれません。人間が明示的に渡す必要があります。
Step 3: 成功条件を明示的に書き直す
タイプBなら、ゴールの定義を整理し直します。
## Definition of done
1. tests/features/billing のすべてのテストがpassする
2. 既存の tests/features/user のテストが1つも落ちない
3. 新しい外部依存（npmパッケージ）を追加しない
4. src/config/ 以下のファイルを一切変更しない
番号付きで書くのがコツです。エージェントは順序付けされた条件のほうが優先順位を守りやすい傾向があります。
Step 4: コンテキストをリセットして再出発
タイプCなら、一度セッションを切って新しい会話で始めます。堂々巡りに入ったセッションは、エージェントの内部で「AとBが両方正しい気がする」という矛盾が抱えられていて、同じセッションでretryを続けても解けません。
新しいセッションで、Step 2とStep 3で整理した情報を最初から渡し直すと、驚くほど素直に進みます。
それでも抜けられない時の最終手段
上の切り分けをやっても前に進まない時は、次の3つを順に試します。
タスクを小分けにする
「あるテストが通るように修正する」が大きすぎる場合、タスクを分解します。
Step 1: 現在テストが落ちている原因を特定してください。
コードは変更せず、診断結果だけを説明してください。
Step 1の診断結果を人間がレビューしてから、
Step 2: Step 1の診断を踏まえて、XXファイルの関数Yだけを
修正してください。他のファイルは触らないでください。
と、スコープを厳しく絞った指示を投げます。エージェントが広い範囲を同時に扱えていない時は、この分解で解けることが多いです。
モデルを切り替える
Antigravityで利用できるモデルを複数試してください。同じエラーでも、モデルが変わると解けるケースがあります。特に、論理的な一貫性が必要な場面（状態遷移の整合、型整合）ではモデル差が出やすいです。
ログを一緒に渡す
エージェントに実際の実行ログ（テスト出力、スタックトレース、ビルドエラーのフルテキスト）を貼り付けて渡してください。Antigravityがログを直接読めないケースがあり、要約だけで判断していると原因を外すことがあります。
retryを効果的に使うための3つの習慣
この経験から、私がretry運用で習慣にしていることが3つあります。
1つ目、retryは3回まで。4回目を押すか悩んだら、そこで手を止めて切り分けを始めるルールにしています。これで時間の浪費が激減しました。
2つ目、diffは必ず見る。retryの後、エージェントの説明文だけを読んで満足せず、実際のdiffを確認します。「直した」という言葉と、diffの内容が一致していないケースが意外とあります。
3つ目、困った時は新セッション。堂々巡りの兆候が出たら、整理したコンテキストで新しいセッションを始めます。古いセッションに固執してretryを重ねるより、新セッションのほうが早く片付くことがほとんどです。
全体を振り返って：まずは「3回ルール」から
この記事の内容を全部いっぺんに取り入れるのは大変なので、まず**「retryは3回まで」のルールだけ**を導入してみてください。4回目を押したくなったら、diffを並べて症状タイプを分類する——この一手間だけで、retryで溶ける時間が目に見えて減るはずです。
Antigravityとローカルモデル（Ollama / LM Studio）を組み合わせて、さらに本格的に本番運用したい方は、Antigravity × ローカルLLM（Ollama / LM Studio）接続を本番運用する実践ガイドで、接続の安定化・モデル選定・失敗時のフォールバック設計まで踏み込んでいます。