「ボタンの色を直してください」と頼んだだけのつもりでした。返ってきた変更には、色の修正に加えて、近くの関数のリファクタ、変数のリネーム、ついでの依存バージョン更新まで入っていました。どれも善意で、しかも動きます。ですが、私が見たかったのは一行の色の変更だけで、残りはレビューを膨らませ、意図しない差分を紛れ込ませる種になりました。
個人開発で複数のアプリを回していると、この「気を利かせすぎ」は地味に効いてきます。一回ごとは小さくても、積み重なると、どの変更を自分が意図したのか分からなくなる。ここで縛りたいのは権限ではありません。書き込み権はあってよいのです。縛りたいのは、頼んだ範囲を超えて動くことです。
これは権限ではなく「範囲」の問題
エージェントの暴走対策というと、まず権限（permission）の話になりがちです。何に書き込めるか、何を実行できるか。それも大切ですが、今回の問題は別の層にあります。色を直す権限はあってよい。問題は、色を直すついでに別のことまでやってしまうこと。つまりタスクの範囲を超えて気を利かせることです。
権限で縛ると、できることが減ります。範囲で縛ると、できることは変えずに「今回やってよいこと」だけを限定できます。私が欲しいのは後者でした。
権限層が固まっても、範囲の事故は残る
この区別は、抽象論ではなく実装の話です。2026年7月16日の Antigravity CLI 1.1.3 で、権限層の穴が二つ塞がれました。
一つは、ヘッドレス実行（-p）の挙動です。確認が必要なツールに当たると、そこで固まってしまうか、あるいは黙って自動承認してしまう、という二択でした。修正後はソフト拒否になり、許可に必要な allow ルール名が stderr に出ます。もう一つは always-proceed モードで、ワークスペース外へのファイル書き込みが誤って自動承認されていた問題です。
夜間に自動でタスクを回している身としては、後者はひやりとしました。ワークスペースの外に書けてしまう自動承認は、権限層のバグとして正しく修正されるべきものです。
けれど、直ったあとで自分の「ボタンの色」問題を見返すと、一つも解決していないことに気づきます。あの時の書き込み先はワークスペースの中でしたし、権限は正しく付いていました。リファクタもリネームも依存更新も、権限の観点では全て合法です。
| 層 | 問いの形 | 7/16 の修正が効くか | 残る事故 |
|---|
| 権限 | そこに書いてよいか | 効く（外部書き込みの自動承認を封鎖） | — |
| 範囲 | 今回それをやってよいか | 効かない（権限は正当なまま） | ついでのリファクタ・リネーム |
権限層が固まるほど、残る事故は範囲層に寄っていきます。ツールが安全になったから安心、ではなく、ツールが安全になったぶん、自分が設計すべき層がはっきりした、と受け取っています。
タスク範囲契約を結ぶ
そこで、依頼ごとに範囲を明示する短い契約を、ルールやプロンプトに入れています。中身は三つだけです。
- やること（in-scope）を一文で書く。
- やらないこと（out-of-scope）を、起きがちなものだけ列挙する。
- 範囲外に触れたくなったら、実行せず提案だけして止まる、と宣言する。
## このタスクの範囲
- やること: 送信ボタンの色を brand-primary に変更する。
- やらないこと: 近隣コードのリファクタ、変数・関数のリネーム、
依存バージョンの更新、フォーマッタの一括適用、他ファイルへの波及。
- 範囲外に触れたくなった場合: 実行せず、「提案」として一行で挙げるだけにする。
判断は人間に渡す。
肝は三つ目です。「ついで」を全面禁止にすると、本当に必要な波及まで止まってしまう。そうではなく、「ついでにやりたくなったら、やらずに提案だけ残す」に変える。これで、気づきは捨てずに、実行だけを範囲内に閉じ込められます。
範囲を越えたときの挙動を決める
契約だけでは弱いので、越えたときにどう振る舞うかを受け入れ条件として書きます。
| 依頼 | 範囲内 | 誘惑される範囲外 | 越えたときの挙動 |
|---|
| ボタンの色変更 | 該当の色指定一行 | 近隣リファクタ・リネーム | 提案として記録し実行しない |
| バグ一件の修正 | 原因箇所と必要なテスト | 無関係な警告の一括解消 | 別タスクとして切り出す |
| 文言の修正 | 対象の文字列 | 周辺の整形・import 整理 | 件数だけ報告し触れない |
| 依存の一件追加 | その依存と最小の結線 | 他の依存のまとめて更新 | 停止して人間に確認 |
この表を一度作っておくと、依頼の型ごとに「越えたらどうするか」が定型化されます。毎回ゼロから契約を書かなくても、型を選んで貼るだけで済みます。
ヘッドレス実行に範囲契約を載せる
対話しながら進めているうちは、範囲を越えた瞬間に気づけます。難しいのは -p で回すときです。人が見ていない場所で、契約が守られたかどうかを後から確かめる必要があります。
私は依頼文に契約を混ぜず、ルールファイル側に置いています。-p に渡すのは依頼だけにして、契約は毎回同じ場所から読ませる。こうしておくと、依頼文が長くなって契約が埋もれる事故を避けられます。
# 範囲契約はルールファイル側に常駐させ、-p では依頼だけを渡す
antigravity -p "送信ボタンの色を brand-primary に変更してください" \
2> "$HOME/agy-scope.err"
# ソフト拒否された操作と、許可に必要な allow ルール名を確認する
grep -i 'allow' "$HOME/agy-scope.err"
1.1.3 以降は、拒否された操作について「これを許可するにはどの allow ルールが要るか」が stderr に出ます。ここで一つだけ、自分に禁じ手を課しています。出てきたルール名を、エラーを消すために足さないことです。
止まった理由を読まずにルールを足すのは、範囲を広げる決断を、エラーメッセージに代行させる行為です。そのルールが今回の in-scope に本当に必要かを確認してから足す。必要でなければ足さずに、そのまま範囲外として扱う。ソフト拒否が便利なのは、この判断のための材料が手元に残るからです。
逸脱を差分で拾う
契約は宣言であって、強制力を持ちません。守られたかどうかは、差分を見れば分かります。
# 今回触ってよいと宣言したファイル
cat > "$HOME/scope-allow.txt" <<'EOF'
src/components/SubmitButton.tsx
EOF
# 宣言外のファイルが変更されていれば、その名前が出る
git diff --name-only | grep -vxF -f "$HOME/scope-allow.txt"
出力が空なら契約は守られています。空でなければ、そのファイル名がそのまま逸脱の記録です。冒頭の「ボタンの色」の件をこの形にかけていたら、宣言1ファイルに対して差分は4ファイル。レビューを開く前に、数のずれだけで気づけたはずでした。
この数行を作業ログに添えておくと、どの依頼型で逸脱が起きやすいかが溜まっていきます。私の場合、逸脱はほぼ「修正のついでに周辺を整える」型に集中していました。逸脱の起きる場所が分かれば、out-of-scope に書くべき項目も具体的になります。
止まりすぎないための粒度設計
範囲を厳しくしすぎると、今度は何をするにも止まって確認を求めてきます。これはこれで消耗します。鍵は、許可された波及の粒度を決めておくことです。
私は「同一関数の中で閉じる整形は範囲内、ファイルをまたぐ波及は範囲外」という線を既定にしています。たとえば、色を直した一行の前後でインデントが乱れたら、その関数内で直すのは構わない。けれど、別ファイルの同種の箇所まで一括で直しに行くのは範囲外、という具合です。
この線引きは、先ほどの差分チェックとも噛み合います。ファイルをまたぐ波及を範囲外に置いておけば、逸脱の判定が「宣言したファイル名に入っているか」だけで済むからです。粒度の設計と検証の手軽さは、だいたい連動します。
粒度は依頼の重さで変えます。使い捨ての小修正なら範囲は狭く、設計を伴う作業なら波及をある程度許す。私自身は、AdMob まわりの設定のような外部影響を含む依頼では範囲を最も狭く取り、内部のテスト整備なら波及を広めに許す、という二段階で運用しています。範囲は固定値ではなく、依頼ごとに選ぶダイヤルだと捉えると、止まりすぎと暴れすぎの間を取りやすくなります。
提案を捨てずに回す
範囲外を実行させない代わりに、提案として残させると、それ自体が良質な次タスクの種になります。「色の修正のついでに気づいたが、この関数は分割した方がよい」という一行は、いま実行されると困りますが、別タスクとしては価値があります。
私は、提案を作業ログの末尾にまとめて転記し、週末に見返しています。実行されなかった気づきが溜まっていくと、それが次に手を入れるべき場所のリストになります。範囲を縛ることは、エージェントの観察力を捨てることではありません。観察は受け取り、実行だけを範囲内に閉じる。この分離が、レビューの軽さと変更の意図の明確さを同時に守ってくれます。
ツール側の権限は、7/16 の修正のように、これからも着実に固まっていくはずです。そのぶん、何をどこまで頼んだのかという範囲の設計は、依頼する側にしか書けない領分として残ります。
次の一手として、いちばんよく出す依頼の型を一つ選び、その「やらないこと」を三つだけ書き出してみてください。三つの out-of-scope を添えるだけで、気を利かせすぎる変更はかなり減ります。