Antigravity でエージェントが途中で止まったとき、つい脊髄反射で「Retry」ボタンを押していませんか。
私も最初の頃は同じことをしていました。けれども、同じ入力で同じようにリトライしても、大半のケースで同じ箇所で再び失敗します。Retry は「ガチャのリロール」ではなく、「失敗の原因を1つ仮説として潰してから、賢く再開する」ための機能です。この違いを理解すると、同じトークン予算でも成功率が目に見えて変わります。
Retry ボタンの正体 — 何が再開され、何が再実行されないのか
Antigravity の Retry は、直前のエージェント実行を「同じコンテキスト」で再開する仕組みです。エージェントが利用していた会話履歴、読み込んだファイル、参照したツール呼び出しの結果はすべて保持されます。再実行されるのは、失敗したタスク以降の「次のステップ」のみです。
ここを誤解していると危険です。たとえばエージェントがファイル編集に失敗した場合、Retry を押しても「再度同じ編集を行う」ではなく「会話履歴を踏まえて次に行うべきアクションを決め直す」ことになります。つまり、前回失敗した箇所の理由（テストが落ちた、ツール呼び出しがタイムアウトした、パーサーがエラーを返した）は、エージェントが「直前の失敗ログ」を読める状態で考え直してくれるのです。
このため、Retry は以下のようなケースで効果を発揮します。
- 一時的なネットワークエラーやレート制限
- ツール呼び出しのタイムアウト
- テスト実行時にたまたま依存サービスが落ちていた
- エージェントが短期的に「迷子」になって似た候補を往復していた
一方で、次のようなケースでは Retry を押しても状況は改善しません。
- 要件自体が曖昧で、エージェントが誤った方向に進んでいる
- 参照している外部ドキュメントの URL が古い
- 前提となるライブラリのバージョンを取り違えている
こうした場合に必要なのは、Retry ではなく「コンテキストの修正」です。
コンテキストを整えてから Retry する — 3つの実践パターン
私が実際に Retry を使うときは、ほぼ必ず「Retry を押す前の1アクション」をはさみます。この「準備運動」があるかないかで、成功率は倍くらい変わります。
パターン 1：補足情報を1メッセージだけ投げる
もっとも効くのがこれです。エージェントが詰まっている原因について、あなたが知っている情報を1メッセージだけ送り、その直後に Retry します。
// 例：エージェントが API リクエストでタイムアウトしていた場合
このエンドポイントは EU リージョン経由だとレイテンシが高く、
3秒のデフォルトタイムアウトでは不足することが多いです。
requests.get のタイムアウトを 15 秒に設定してから再試行してください。この1行を入れるだけで、エージェントはタイムアウト値の引き上げを含めた修正プランに切り替えてくれます。
パターン 2：参照ファイルを手動で添付し直す
エージェントの作業が進むと、序盤で読み込んだファイルの内容がコンテキストから押し出されていることがあります。Antigravity は賢く要約してくれますが、細部まで保持されているとは限りません。
失敗が「ファイルの細部に関わるエラー」のときは、Retry の直前に当該ファイルを @ 記法で再添付します。とくに、エージェントが使っている型定義やスキーマ定義のファイルは、再添付するだけで成功率が上がります。
パターン 3：Checkpoints に戻してから Retry する
Retry だけでは解決しない、けれども会話履歴自体は残したい。そんなときは Antigravity の Checkpoints 機能と組み合わせます。
- 直前の Checkpoint（エージェントが動き始める直前の状態）に戻す
- 会話側ではタスクを少し言い直す、または制約条件を追加する
- その上で再実行する
「コードの状態はきれいに戻しつつ、会話の学びだけ残す」ことができるので、長時間のセッションで迷走したときに重宝します。
Retry とクレジットの関係 — コスト意識を持った使い方
Retry を無制限に押すと、当然ながらクレジット消費が膨らみます。私が目安にしているのは以下の3つです。
- 同じタスクで3回連続で失敗したら Retry はやめる（根本原因がコンテキスト側にある）
- 1タスクあたりの Retry 予算を事前に決めておく（例：最大5回まで）
- 失敗の「種類」が2回続けて同じなら、Retry ではなく人間が介入する
とくに3つ目が重要で、「同じエラーで2回落ちたら仕組みを疑う」くらいの姿勢がちょうどよいと感じています。たとえば ModuleNotFoundError が2回続いたら、仮想環境の構成やインタプリタのパスそのものが問題です。ここで Retry を5回押しても、状況は好転しません。
なお、Retry に関連する機能としては Antigravity のチェックポイント機能とロールバック操作のガイド を合わせて読むと、より深い運用ができます。失敗と回復をセットで設計する発想が、安定したエージェント運用には欠かせません。
Retry を押さない方がよい場面
ここまでの話とは逆に、Retry 以外の選択肢を積極的に取るべき場面もあります。
- エージェントが「同じ関数」を何度も書き直してループしている → 新しい会話で仕様を整理してから再依頼
- 認証情報や環境変数が未設定でエラーが出ている → まずは環境を整えてから実行
- 明らかに要件の理解がズレている → 会話履歴ごと捨てて、要件定義をやり直す
「エージェントの状態が腐敗している」と感じたら、新しいセッションで仕切り直すほうが結果的に安上がりです。私は、1つの会話で Retry が5回以上続いたら、いったん要件を自分で書き直してから新規会話で再開するようにしています。
明日からできる1つの実験
まずは今取り組んでいるタスクで、Retry を押す前に「エージェントが詰まっている理由を自分なりに1文で書く」習慣をつけてみてください。その1文を会話に投げてから Retry するだけで、Antigravity の体感成功率が変わります。
エージェントの挙動は、こちらがどれだけ情報を整理して渡せるかで決まります。Retry は、その整理を試すための短いフィードバックループとして使うのが、もっとも費用対効果の高い付き合い方です。さらに実践的なパターンを知りたい方は、Antigravity マルチエージェント設計の実践パターン も参考になります。
Retry の考え方を、より大きな「エージェント運用」の文脈で位置づけられます。