最初の一日は「読むだけ」を頼む。Antigravity に任せる範囲を、壊せない順に広げる 5 段

壁紙アプリのストア文面を、公開前に見直していた夜のことです。新しく入れたエージェントに、勢いで「この文面を整えて、翻訳も全部直しておいて」と頼みました。返事は早く、画面には変更の一覧が並びました。ところが翌朝、どのファイルが何のために変わったのか、私には説明できなくなっていたのです。

エージェントが悪かったわけではありません。頼み方が、私の確認できる範囲を超えていたのだと思います。

はじめて Antigravity を開く日に何を頼み、何をまだ頼まないか。5 段の梯子としてお伝えします。コードを書かない方も、そのまま使えるように書きました。

最初に決めておくこと：頼む前に、戻せる状態を作る

最初にお伝えしたいのは、プロンプトの工夫ではありません。戻せる状態を先に作ることです。

フォルダが Git で管理されていれば、エージェントが何を変えても、変更前の状態へ戻れます。管理していないフォルダなら、せめて丸ごとコピーを一つ取っておきます。Antigravity の画面操作でチェックポイントを使う方法はこちらの記事にまとまっていますが、Git のほうが、ツールが変わっても持ち歩けます。

手を動かす前に、次の三つだけ確かめます。

1. 作業フォルダが Git 管理下にあるか（git status が動くか）
2. 未コミットの変更が残っていないか
3. 大事なファイルが、そのフォルダの外にもコピーとして存在するか

この三つがそろった状態を、以降「足場がある」と呼びます。

5 段の梯子：壊せない順に任せる範囲を広げる

任せる範囲は、一気に広げません。次の表は、私が使っている段の分け方です。上の段ほど、失敗したときに取り返しがつきにくくなります。

はじめての日は、段 1 と段 2 まで進めば十分です。段 3 以降は、二日目以降に回しても何も困りません。

段 1：読んで説明してもらう

最初の依頼は、書き換えを一切含まない文面にします。たとえば次のようなものです。

このフォルダの構成を読んで、何のためのプロジェクトかを 5 行で説明してください。
ファイルは一切変更せず、読むだけにしてください。

返ってきた説明が、自分の理解とどれだけ合っているかを見ます。ずれているなら、エージェントの読み違いか、自分のフォルダの整理不足か、どちらかです。どちらであっても、書き換えを頼む前に知れたのは収穫です。

「変更しないでください」と書いても、守られたかどうかは文面からは分かりません。そこで、次の節の道具で確かめます。

段 2：新しいメモファイルに書いてもらう

段 1 に慣れたら、書き込みを許します。ただし場所は、新しい 1 フォルダに限定します。

notes/ フォルダの中にだけ、このプロジェクトの TODO を洗い出した notes/todo.md を作ってください。
notes/ の外のファイルは変更しないでください。

既存のファイルには触れさせず、成果物が新しいメモとして残るだけです。気に入らなければ削除して終わりですから、失敗の代償はほぼありません。

作業の前後で「どこが動いたか」を数える

ここで、先ほど触れた道具の出番です。エージェントに「触らないで」「この中だけで」と頼んでも、守られたかは返事の文面ではなく、実際に変わったファイルで確かめるほうが確実でした。

次のスクリプトは、作業前に Git の位置へ印を付け、作業後に「許可した場所の外が動いていないか」を調べます。

何を解決するか：頼んだ範囲を超えて動いたファイルを、数秒で一覧にします。

#!/usr/bin/env bash
# session-guard.sh — エージェントに任せる前後で「触られた範囲」を数える
# 使い方: session-guard.sh before            # 作業前に印を付ける
#         session-guard.sh after notes/      # 作業後。notes/ の外が動いていたら警告
set -euo pipefail
MARK=".git/agent-session-mark"
 
case "${1:-}" in
  before)
    if [ -n "$(git status --porcelain)" ]; then
      echo "未コミットの変更があります。先にコミットか退避をしてください。" >&2
      exit 1
    fi
    git rev-parse HEAD > "$MARK"
    echo "印を付けました: $(cut -c1-7 "$MARK")"
    ;;
  after)
    [ -f "$MARK" ] || { echo "先に before を実行してください。" >&2; exit 1; }
    allowed="${2:-}"          # 触ってよい場所（前方一致）。空なら「何も触らない」前提
    base=$(cat "$MARK")
    changed=$( { git diff --name-only "$base"; git ls-files --others --exclude-standard; } | sort -u )
    [ -z "$changed" ] && { echo "変更なし。読むだけの仕事でした。"; exit 0; }
    echo "$changed" | sed 's/^/  変更: /'
    if [ -z "$allowed" ]; then outside="$changed"
    else outside=$(echo "$changed" | grep -v -- "^${allowed}" || true); fi
    if [ -n "$outside" ]; then
      echo "⚠ 許可した場所の外が動いています:"
      echo "$outside" | sed 's/^/  外: /'
      exit 2
    fi
    echo "許可した場所の中だけでした。"
    ;;
  *)
    echo "usage: $0 before | after [allowed-prefix]" >&2; exit 64
    ;;
esac

なぜこう書くか。git diff は追跡済みファイルの変更しか拾わないため、新しく作られたファイルは git ls-files --others で別に集めています。終了コードを 0（問題なし）と 2（範囲外あり）に分けてあるので、あとで自動化したくなったときも、そのまま条件分岐に使えます。

手元の小さなリポジトリで試した結果は、次のとおりでした。

• 何も頼まなかったとき：「変更なし。読むだけの仕事でした。」
• notes/ に 1 ファイル作らせて notes/ を許可したとき：「許可した場所の中だけでした。」
• 許可外の a.txt も動いていたとき：外のファイルを名指しして、終了コード 2

段 1 の依頼のあとに実行して「変更なし」と出れば、読むだけという約束が守られたと確かめられます。段 2 では、notes/ を許可先として渡します。

梯子を上るときの目安：「説明できる」が条件

上の段へ進む条件を、私は回数ではなく自分が説明できるかにしています。

• 段 2 → 3：作ったメモを読み直して、内容が正しいと自分で言えるか
• 段 3 → 4：差分（git diff）を読んで、なぜそう変わったのかを自分の言葉で言えるか
• 段 4 → 5：承認画面に出るコマンドが、何をするものか分かるか

分からないまま進むと、私が最初の夜にやったように、あとから説明できない変更が積み上がります。分からないところは、エージェント自身に「この差分を初心者向けに説明して」と頼んでみてください。説明が腑に落ちるまで、同じ段に留まって構いません。

まだ頼まないこと

はじめての日に、あえて見送るものがあります。

• 複数ファイルにまたがる書き換え
• 自分で意味の分からないコマンドの実行
• 離席中に動かし続ける設定
• 公開や送信など、取り消せない操作

どれも便利な機能です。ただ、足場と説明できる範囲が整うまでは、置いておくほうが安全だと私は考えています。

頼む範囲は、自分が確かめられる範囲の少し手前まで。 この線引きは、機能が増えても変えないつもりです。

今日の次のアクション

まず作業フォルダで git status を実行し、足場があるかを確かめてください。そのうえで、段 1 の依頼を一つだけ出し、session-guard.sh after で「変更なし」と出るのを見届けます。それができたら、その日の仕事は十分です。二日目に、段 2 から再開してください。