「ボタンの色を直してください」と頼んだだけのつもりでした。返ってきた変更には、色の修正に加えて、近くの関数のリファクタ、変数のリネーム、ついでの依存バージョン更新まで入っていました。どれも善意で、しかも動きます。ですが、私が見たかったのは一行の色の変更だけで、残りはレビューを膨らませ、意図しない差分を紛れ込ませる種になりました。
個人開発で複数のアプリを回していると、この「気を利かせすぎ」は地味に効いてきます。一回ごとは小さくても、積み重なると、どの変更を自分が意図したのか分からなくなる。ここで縛りたいのは権限ではありません。書き込み権はあってよいのです。縛りたいのは、頼んだ範囲を超えて動くことです。
これは権限ではなく「範囲」の問題
エージェントの暴走対策というと、まず権限（permission）の話になりがちです。何に書き込めるか、何を実行できるか。それも大切ですが、今回の問題は別の層にあります。色を直す権限はあってよい。問題は、色を直すついでに別のことまでやってしまうこと。つまりタスクの範囲を超えて気を利かせることです。
権限で縛ると、できることが減ります。範囲で縛ると、できることは変えずに「今回やってよいこと」だけを限定できます。私が欲しいのは後者でした。
タスク範囲契約を結ぶ
そこで、依頼ごとに範囲を明示する短い契約を、ルールやプロンプトに入れています。中身は三つだけです。
- やること（in-scope）を一文で書く。
- やらないこと（out-of-scope）を、起きがちなものだけ列挙する。
- 範囲外に触れたくなったら、実行せず提案だけして止まる、と宣言する。
## このタスクの範囲
- やること: 送信ボタンの色を brand-primary に変更する。
- やらないこと: 近隣コードのリファクタ、変数・関数のリネーム、
依存バージョンの更新、フォーマッタの一括適用、他ファイルへの波及。
- 範囲外に触れたくなった場合: 実行せず、「提案」として一行で挙げるだけにする。
判断は人間に渡す。
肝は三つ目です。「ついで」を全面禁止にすると、本当に必要な波及まで止まってしまう。そうではなく、「ついでにやりたくなったら、やらずに提案だけ残す」に変える。これで、気づきは捨てずに、実行だけを範囲内に閉じ込められます。
範囲を越えたときの挙動を決める
契約だけでは弱いので、越えたときにどう振る舞うかを受け入れ条件として書きます。
| 依頼 | 範囲内 | 誘惑される範囲外 | 越えたときの挙動 |
|---|
| ボタンの色変更 | 該当の色指定一行 | 近隣リファクタ・リネーム | 提案として記録し実行しない |
| バグ一件の修正 | 原因箇所と必要なテスト | 無関係な警告の一括解消 | 別タスクとして切り出す |
| 文言の修正 | 対象の文字列 | 周辺の整形・import 整理 | 件数だけ報告し触れない |
| 依存の一件追加 | その依存と最小の結線 | 他の依存のまとめて更新 | 停止して人間に確認 |
この表を一度作っておくと、依頼の型ごとに「越えたらどうするか」が定型化されます。毎回ゼロから契約を書かなくても、型を選んで貼るだけで済みます。
止まりすぎないための粒度設計
範囲を厳しくしすぎると、今度は何をするにも止まって確認を求めてきます。これはこれで消耗します。鍵は、許可された波及の粒度を決めておくことです。
私は「同一関数の中で閉じる整形は範囲内、ファイルをまたぐ波及は範囲外」という線を既定にしています。たとえば、色を直した一行の前後でインデントが乱れたら、その関数内で直すのは構わない。けれど、別ファイルの同種の箇所まで一括で直しに行くのは範囲外、という具合です。
粒度は依頼の重さで変えます。使い捨ての小修正なら範囲は狭く、設計を伴う作業なら波及をある程度許す。私自身は、AdMob まわりの設定のような外部影響を含む依頼では範囲を最も狭く取り、内部のテスト整備なら波及を広めに許す、という二段階で運用しています。範囲は固定値ではなく、依頼ごとに選ぶダイヤルだと捉えると、止まりすぎと暴れすぎの間を取りやすくなります。
提案を捨てずに回す
範囲外を実行させない代わりに、提案として残させると、それ自体が良質な次タスクの種になります。「色の修正のついでに気づいたが、この関数は分割した方がよい」という一行は、いま実行されると困りますが、別タスクとしては価値があります。
私は、提案を作業ログの末尾にまとめて転記し、週末に見返しています。実行されなかった気づきが溜まっていくと、それが次に手を入れるべき場所のリストになります。範囲を縛ることは、エージェントの観察力を捨てることではありません。観察は受け取り、実行だけを範囲内に閉じる。この分離が、レビューの軽さと変更の意図の明確さを同時に守ってくれます。
次の一手として、いちばんよく出す依頼の型を一つ選び、その「やらないこと」を三つだけ書き出してみてください。三つの out-of-scope を添えるだけで、気を利かせすぎる変更はかなり減ります。