「AI が 100 行近く書いてくれて、最後の 1 行だけ気に入らないから ⌘Z を 1 回押した。そうしたら、残したかった 99 行ごと一気に消えた」――Antigravity を毎日触っていると、この瞬間に何度か出会います。私も先週、TypeScript のリファクタリング中にまさにこれをやってしまい、AI への再依頼で同じ品質のコードが返ってこなくて 20 分ほど呆然としました。
これは Antigravity の不具合というより、AI 生成コードと従来エディタの Undo モデルが噛み合っていないことから来る、構造的な現象です。原因を理解しておけば、9 割は予防できます。残りの 1 割に備える復旧手段も合わせてまとめておきますので、安心して AI にコードを書かせてください。
なぜ「Cmd+Z 一発」で大量に巻き戻るのか
VS Code 系のエディタは、一定時間内の連続編集を 1 つの「編集グループ」としてまとめます。普段の手入力では文字単位・単語単位で区切られるため、⌘Z を押すと数文字ずつ綺麗に戻ります。ところが AI 生成は事情が違います。
Antigravity の AI が applyEdit API でコードを差し込むとき、典型的なパターンは「短時間に大量の編集オペレーションを連射する」です。場合によっては「対象ファイル全体を一気に置き換える」というオペレーションが 1 件だけ発行されることもあります。エディタから見ると、これは「ユーザーが超高速で大量タイプした 1 つの編集」と見分けがつかないため、Undo グループが 1 つにまとまります。
つまり ⌘Z を 1 回押した瞬間、その「巨大な 1 グループ」がそのまま吹き飛びます。100 行であろうが 1,000 行であろうが、Antigravity 視点では「最後にユーザーが行った 1 操作」なのです。
私の経験上、特にリスクが高いのは次の 3 パターンです。
- AI に「全ファイルを書き換えて」とお願いしたとき
- Manager Surface のエージェントが複数ファイルにまとめて編集を行ったとき
- インラインチャットで「○行目から○行目までを書き換えて」と範囲指定したとき
このどれかに当てはまる作業をしているときは、Undo の挙動がいつもと違うかもしれない、と頭の片隅に置いておくと安全です。
巻き戻りを止める 3 つの基本テクニック
予防策として、私が普段から心がけている 3 つを共有します。どれも 1 分以内で習慣化できる軽い対策です。
1. AI 編集の前に Git で「線」を引く
最も確実なのが、AI に編集させる直前に必ず git add で意思的なステージングを切ることです。コミットまでしなくて構いません。ステージング済みの状態を作っておけば、巻き戻りが起きても git restore --staged と git checkout -- . の組み合わせで元に戻せます。
# AI に大規模編集を依頼する前のおまじない
git add -A
# この瞬間の状態が、Undo の最終防衛ラインになりますタスクファイル（.antigravity/tasks/*.md）を使っているなら、その先頭に「Before you edit, the user has staged the working tree. Make atomic commits per logical change.」と書いておくと、AI 自身がコミット粒度を意識してくれることもあります。
2. Manager Surface のチェックポイントを使う
Antigravity の Manager Surface には、エージェントが複数ファイルに変更を加えた直後に「チェックポイント」が自動生成されます。エージェント実行履歴のサイドバーで、各ステップに小さな旗のアイコンが表示されているのがそれです。
⌘Z ではなく、このチェックポイントから「Restore to this point」を選ぶと、編集グループ単位ではなく「エージェントの 1 ステップ単位」で巻き戻せます。粒度が違うので、消したい変更だけを安全に取り消せます。
私はインライン編集を使うときも、まず一度 Manager Surface 経由でエージェントを走らせる癖をつけました。チェックポイントが残るだけで、心理的な負担が大きく減ります。
3. 大規模編集を 1 回でやらせない
AI に「このファイル全体を直して」と頼むよりも、「まず関数 A だけ直して」「次に関数 B」「次にテスト」と、論理単位で分割して依頼するほうが、結果的に巻き戻り耐性が上がります。
これは品質の問題でもあります。1 回の編集で 200 行を生成すると、AI 自身もコンテキストが散って細かい品質が落ちがちです。30〜50 行ごとに区切って依頼すれば、Undo 単位もそれに合わせて細かくなり、修正もしやすくなります。少し急がば回れですが、長期的には作業時間が短くなる体感があります。
Undo の粒度を設定で広げる
設定で多少の改善も可能です。Settings → Editor を開き、Editor: Undo Stop Granularity（環境により名称が editor.undo.granularity などになる場合があります）を lineByLine または paragraph に変更してください。
// settings.json — Undoスタックを行単位に細かく刻む
{
"editor.undo.granularity": "lineByLine",
"editor.undo.maxStackSize": 1000
}ただしこれは、ユーザー自身の手入力に対して効くもので、AI が API 経由で送り込む 1 件の巨大オペレーションを分割してくれるわけではありません。「手で書いた部分は細かく戻せる、AI が書いた部分は依然として 1 ブロック」と理解しておくと、過信せずに済みます。
maxStackSize を増やしておくと、長時間のセッションでも履歴が削られにくくなり、後述の復旧手段が効きやすくなります。私はワークステーション側のメモリに余裕があれば、ここを 2,000 まで上げています。
それでも巻き戻ってしまったときの復旧手順
予防していても、油断した瞬間に事故は起きます。慌てなくていいよう、復旧手順を知識として持っておきましょう。
最初に試すのは ⌘⇧Z（Redo）です。当たり前のように見えますが、Undo した直後ならこれで瞬時に戻ります。問題は、Redo した直後に何か別の編集を入れてしまうと Redo スタックが消える点です。⌘Z で巻き戻ったら、まず手を止めて何もタイプしないのが鉄則です。
Redo が効かない場合は、VS Code の「Local History」機能を使います。⌘⇧P でコマンドパレットを開き、Local History: Find Entry to Restore を実行すると、ファイル単位の自動バックアップが時系列で並びます。Antigravity はこの機能を有効にしたまま継承しているので、AI 編集前後のスナップショットが拾えるはずです。
# Local History の保存先（macOS の場合）
~/Library/Application\ Support/Antigravity/User/Historyターミナルから grep -r "復元したいキーワード" ~/Library/Application\ Support/Antigravity/User/History/ で検索すれば、手動で該当ファイルを掘り当てることもできます。私はこれで一度、消えたと思った 80 行のテストコードを救出しました。
最後の手段は、エージェントログからの再生成です。Manager Surface のエージェントセッションには、AI が生成したコードがそのまま会話履歴として残っています。「直前の応答をもう一度コードブロックだけ出力して」と頼めば、同じ内容のコードを再取得できます。これは Cmd+Z で消えても、AI とのチャット履歴は別管理になっているためです。
AI と共に書く時代の編集設計
ここまでの話を踏まえて、私自身が運用している「AI 主導編集の作法」をまとめておきます。読者の方の参考になればと思います。
エージェントに大規模編集を依頼する前には、必ず git add -A でステージングを切る。インライン編集よりも Manager Surface 経由のエージェントを優先し、チェックポイントを残す。1 回の依頼で書かせるのは 30〜50 行を上限とし、長尺の改修は明示的に複数ステップに分ける。AI 編集後は数分以内に git commit -m "wip: ai-edit" で WIP コミットを切り、後でまとめて git rebase -i で整える。
エージェントの設計や生成プロセスをもう一段深掘りしたい方には、Antigravityのエージェントコード変更が反映されないときの診断ガイドや、Antigravityのコードベース・コンテキスト診断ガイドも合わせて読むと、Undo 以外の事故も予防しやすくなります。リトライ運用についてはAntigravityのリトライ機能を使いこなすガイドもおすすめです。
Git まわりの取り回しを腰を据えて
「いまの依頼はどの種類か」を一拍考える
すべての AI 編集が同じ Undo リスクを持つわけではありません。私は最近、依頼を送る前に頭の中で「これはどの種類の編集か」とラベルを貼る癖をつけました。これだけで事故からの復旧時間がほぼゼロになりました。
インラインの 1 行補完はほぼ無害で、Undo も普通に行単位で巻き戻ります。30 行ほどを選択してインラインチャットでリファクタを依頼するケースは、グループが大きくなり始めるものの、まだ ⌘Z 1〜2 回で何とかなるレンジです。危険なのは、ファイル全体を書き換えるようなリクエストと、Manager Surface のエージェントが複数ファイルに編集を入れるケースです。この 2 つは、データベースのマイグレーションと同じ気構えで Git スナップショットを切ってから走らせる、と決めておくと安全です。
実用的な目安として「編集対象が画面の表示範囲を超えるなら、5 秒だけ手間をかけてステージングを切る」と覚えておくとちょうどよいです。テストファイルが行方不明になったときの心労に比べれば、ステージングの手間は誤差です。
チームで共有するときの伝え方
チームで Antigravity を使っている場合、共有プレイブックに一言メモを残しておくのがおすすめです。伝え方が大事で、これは「誰かのミス」ではなく「エディタとモデルの構造の問題」だと位置づけてください。「気をつけてね」では、同じ事故が来週別の人に起きるだけです。
「AI の編集は手入力とは違う動きをする」と全員が共通認識として持てると、ヒヤリハットが共有されやすくなり、復旧も早くなります。失敗を共有してもいい空気が、結局は一番の安全網になります。
まずは今日 1 つだけ習慣にする
すべてを一度にやろうとせず、まずは「AI に大規模編集を頼む直前の git add -A」だけを今日から徹底してみてください。これだけで、⌘Z 事故の体感ダメージが 8 割減ります。慣れてきたら Manager Surface のチェックポイント運用、さらに編集の分割依頼へと、自分のリズムで広げていけば十分です。
AI と共にコードを書くというのは、エディタの操作モデルを少しずつアップデートしていく作業でもあります。焦らず、一緒に磨いていきましょう。