会話だけ戻す undo とサブエージェントへの直送、使い分けに迷った3つの場面

アップデートを入れた朝、変更履歴の一行を読んで手が止まりました。「undo で会話だけを戻せる」とあります。

便利そうだと思った直後に、もう一つの考えが浮かびました。会話だけが戻るということは、エージェントが書き換えたファイルは戻らない、ということです。この二つを取り違えたまま「戻したつもり」で作業を続けると、気づかないうちに、会話の記憶とファイルの中身がずれていきます。

ここからは、2.19.1 の入力まわりで加わった二つの操作を、迷いやすい場面ごとに整理してまいります。先にお伝えしておくと、私自身はこの二つの新機能を長時間使い込んだわけではありません。ですから、公式の変更履歴に書かれていることと、私が運用で置いている線引きを、はっきり分けて書き残します。

公式の記述だけで読み直す

Antigravity 2.0 アプリの v2.19.1（9 月 30 日付）の変更履歴には、今回の主題に関わる項目として次の二つがあります。2026年10月8日時点で確認した内容です。

サブエージェントへ、メッセージ欄から直接メッセージを送れます
undo で、会話だけを戻せます

同じ版には Markdown の PDF 書き出しや、Windows・Linux でトレイをクリックしたときのウィンドウ再表示も入っています。ただ、日々の作業で判断が要るのは、この二つだけだと感じています。

変更履歴が語っているのはここまでです。ファイルの状態がどうなるか、サブエージェントの受け取り方がどう変わるかまでは、一行の記述からは読み取れません。そこから先は、手元で確かめる領域になります。

場面1: 指示を間違えたとき、会話だけ戻すか、ファイルも戻すか

エージェントに頼んだあとで「その方向ではなかった」と気づく場面は、個人開発では日常茶飯事です。壁紙アプリのリポジトリでも、設定画面の文言を直してほしかっただけなのに、周辺の画面まで手が入ってしまうことがあります。

このとき、戻したいものが二種類あることに気づきます。

戻したいもの	向いている手段	理由
頼み方そのもの（会話の流れ）	undo で会話だけ戻す	ファイルに触れずに、言い直しから再開できるため
エージェントが書き換えた内容	git で戻す	ファイルの履歴は、会話ではなくリポジトリが持っているため
両方	git で戻してから、会話も戻す	片方だけ戻すと、会話の記憶とファイルの中身がずれるため

私の線引きは単純です。会話は何度でも巻き戻せるようにして、ファイルの責任は git に預けています。 会話の巻き戻しが軽くなったぶん、ファイル側の安全網は自分で張っておく必要があります。

エージェントに任せる直前に、その時点の状態へ名前を付けておく小さなスクリプトを使っています。

#!/usr/bin/env bash
# agent-checkpoint.sh — 任せる直前の作業ツリーに名前を付けて残す
# 使い方: ./agent-checkpoint.sh settings-copy
set -euo pipefail
 
label="${1:-before-agent}"
ref="refs/checkpoints/${label}-$(date +%Y%m%d-%H%M%S)"
 
# 未コミットの変更があればそれを、なければ HEAD を指す
sha="$(git stash create)"
[ -n "$sha" ] || sha="$(git rev-parse HEAD)"
 
git update-ref "$ref" "$sha"
echo "checkpoint: $ref ($(git rev-parse --short "$sha"))"

git stash create は作業ツリーを変えずに、変更内容を指すコミットだけを作ります。そこへ参照名を付けておけば、あとから差分も見られますし、戻すこともできます。

# エージェントが何を変えたかを、チェックポイントとの差で確認する
git diff refs/checkpoints/settings-copy-20261008-140000
 
# 追跡中のファイルだけを、その時点へ戻す
git restore --source=refs/checkpoints/settings-copy-20261008-140000 --worktree -- .

なぜこう書いたかというと、git stash で退避すると作業ツリーが一度きれいになり、元に戻す手間が増えるからです。名前付きの参照だけを残せば、作業は途切れません。なお、まだ追跡されていない新規ファイルはこの方法では戻りません。新規ファイルが増えそうな依頼のときは、git status で一覧を見てから任せています。

場面2: 親エージェントを通すか、サブエージェントへ直接送るか

もう一つの追加は、サブエージェントへメッセージ欄から直接送れることです。

ここは公式の記述を超えて、私の想像が混ざります。だからこそ線引きとして書きます。親エージェントは、サブエージェントの作業を束ねて全体の状況を把握している立場です。直接送ったメッセージが、その親の認識にどこまで伝わるかは、私の手元ではまだ確かめていません。

そこで、直接送る内容は次のように絞っています。

サブエージェント一人の作業の中で閉じる、小さな補足（「その関数名は変えないでください」程度）
作業の方針そのものは変えない、軽い指示

方針を変えたいとき、複数の担当にまたがる判断をしたいときは、従来どおり親エージェントを通します。直接送るのは便利ですが、全体を見ている相手を飛ばす操作でもあります。近道は、全体への影響が小さいときだけ使うことにしています。 そう決めておくと、迷う回数がかなり減ります。

場面3: 使い始める前に、手元で確かめておく3点

変更履歴の一行を信じて、いきなり本番のリポジトリで試すのは避けたいところです。使い捨てのリポジトリで、次の三つを順に確認しておくと安心です。

小さなファイルを一つ作り、エージェントに一か所だけ書き換えてもらいます
undo で会話だけを戻し、git status と git diff でファイルの状態を見ます。ファイルが残っているか、戻っているかを、自分の目で確認します
サブエージェントを走らせた状態で直接メッセージを送り、親エージェントの次の応答に、その内容が反映されているかを読みます

三つ目で、親に伝わっていなかったとしても、慌てる必要はありません。その場合は「直接送るのは補足まで」という線引きが、そのまま正解になります。逆に伝わっているなら、もう少し広く使ってもよい、という判断材料になります。

確認した結果は、短いメモとして残しておくことをおすすめします。バージョンが変わると挙動も変わりうるので、「v2.19.1 のとき、こうだった」と書いておくだけで、次の更新のたびに迷う時間が減ります。

次にやること

まず、使い捨てのリポジトリで場面3の三つを試してみてください。結果が分かったら、その上で、自分の作業に「会話だけ戻す」場面がどれくらいあるかを数えてみるのがよいと思います。

私はこの原則だけは、新機能が増えても守るつもりです。ファイルの責任は git に、会話の巻き戻しは undo に——持ち場を分けておけば、どちらかの挙動が変わっても、慌てずに済みます。