エージェントの画面に、見慣れない英数字の行がすごい速さで流れていく。その横で「実行を許可しますか」というボタンが光っている——初めて Antigravity を触った方の多くが、この場面で手を止めます。
私自身、個人開発の合間に壁紙アプリのストア文言を整理してもらっていたとき、何を許可したのか分からないまま「許可」を押し続けてしまった夜がありました。結果は問題なく終わったのですが、翌朝に残ったのは安心ではなく、「たまたま無事だっただけかもしれない」という落ち着かなさでした。いま思えば、不安の正体は、確認の型を持っていないことでした。
最初にお伝えしたいのは、すべてを理解してから許可する必要はないということです。見る場所を3か所に絞れば、コマンドが読めなくても、取り返しのつかないことはほぼ避けられます。
全部読もうとするから、怖くなる
エージェントが実行する文字列の大半は、ファイルを開く、一覧を出す、パッケージを入れるといった、ごく普通の作業です。ところが画面上では、無害な行も危うい行も同じ見た目で並びます。そのため「全部が分からない」ことが、そのまま「全部が危ない」という感覚に変わってしまいます。
ここで発想を切り替えます。理解する範囲を広げるのではなく、確認する場所を狭くするのです。
- 作業を頼む前の、戻り口づくり
- 許可を押す前の、先頭の動詞の確認
- 終わったあとの、差分の確認
この3つは、順番どおりに「事前・実行中・事後」に対応しています。どれか1つが抜けても、残り2つがある程度は受け止めてくれます。
1か所目: 頼む前に「戻り口」を作る
先に、何を解決する手順なのかをお伝えします。エージェントが何をしても、頼む前の状態へ丸ごと戻せるなら、途中で何が起きても致命傷にはなりません。そのために Git を使います。難しい操作はなく、作業フォルダの「いまの状態」に名前をつけて残しておくだけです。
# 作業フォルダで、頼む前の状態に名前をつけて保存する
git status --short
git add -A
git commit -m "エージェントに頼む前の状態"git status --short は「変更中のファイルがあるか」の確認です。何も表示されなければ、きれいな状態という意味になります。あとの2行で、その時点を保存します。
なぜこう書くのかというと、保存した時点は、あとから何度でも呼び戻せる目印になるからです。エージェントの作業が思わぬ方向へ進んでも、この目印があれば「頼む前」に帰れます。Git を使っていない作業フォルダでは、フォルダごとコピーを取っておくだけでも同じ役目を果たします。
2か所目: 許可を押す前に、動詞だけ見る
承認ダイアログには、長いコマンドが出ます。ここでは全文を読まず、先頭にある動詞と、触る対象の場所だけを見ます。下の表は、私が自分用に書き出した「見分け表」を整えたものです。
| 先頭の言葉 | 意味 | 見るポイント |
|---|---|---|
| ls / cat / git status | 見るだけ | 基本的にそのまま許可して大丈夫です |
| npm install / pip install | 部品を足す | 入れる名前が、頼んだ内容と合っているか |
| rm / rm -rf | 消す | 消す対象が、作業フォルダの中だけか |
| git push --force / git reset --hard | 履歴を上書きする・戻す | 理由が説明されていなければ、いったん止める |
| curl や wget、sudo | 外から持ってくる・強い権限で動かす | 頼んでいない外部アドレスや権限が出たら断る |
読むのは、表の左の列だけです。「消す」系の動詞が出たら、対象が作業フォルダの外へ伸びていないかを一度だけ確かめます。それでも迷うときは、許可の代わりにチャットで「いまのコマンドは何をするものですか」と聞いてください。エージェントは、自分の実行内容を説明するのが得意です。
承認ダイアログが何度も繰り返し出て困っている方は、原因と対処を別の記事に整理しています。Antigravity の許可ダイアログが何度も表示される・「常に許可」が効かないときの診断と解決ガイドも、あわせてご覧ください。
3か所目: 終わったあとに、差分を見る
実行中の確認が不安でも、終わったあとに「何が変わったか」を見れば、ほとんどの問題は拾えます。ここでも読むのは文字列ではなく、ファイルの名前と増減の量だけです。
# 保存した時点から、何が変わったかを一覧で見る
git diff --stat HEAD
# 気になるファイルだけ、中身の差分を見る
git diff HEAD -- path/to/file--stat をつけると、変更されたファイルの名前と、増えた行・減った行の目安が一覧で出ます。頼んだ内容と関係のないファイルが並んでいたら、そこが立ち止まる場所です。反対に、頼んだ範囲のファイルだけが変わっていれば、まず安心して構いません。
なぜ一覧から見るのかというと、中身を1行ずつ読む前に、「範囲」がずれていないかを確かめるほうが、はるかに早いからです。範囲が合っていれば、中身は必要に応じて見れば足ります。
もし範囲がずれていたら、1か所目で作った目印へ戻します。
# 変更をすべて捨てて、保存した時点へ戻す（実行前に差分を確認してください）
git restore .このコマンドは、保存したあとに書き換えられたファイルを元に戻します。エージェントが新しく作ったファイルは残りますので、不要であれば手で消してください。戻したくない変更があるときは、先にそのファイルだけ別の場所へ避けておきます。
私が決めている線引き
最初のうちは、「許可を押すたびに全文を読む」ことに挑戦していました。結果は芳しくありませんでした。読めない行が出るたびに手が止まり、作業そのものが進まなくなったからです。
いまは次の線引きにしています。読めなくても、戻れる状態と、見る場所さえ決まっていれば、前へ進めます。 理解が追いつくのを待たなくても、確認の型があれば、エージェントに頼む作業を少しずつ広げていけるのだと、いまは感じています。
この型は、Lab のサイト運用で何かを書き換えてもらうときにも、そのまま使えます。更新の前に戻り口を作り、実行の前に動詞を見て、終わったあとに差分を見る——道具が変わっても、骨組みは変わりません。
まずは明日の作業の前に、git commit を1回だけ打つところから始めてみてください。それだけで、エージェントとの付き合い方がかなり楽になります。