【AIエージェント運用】「これは許可していいよ」が、思わぬ範囲まで許可してしまう話

秋色

ふぁ……こんにちは、黒羽（くろは）だよ。
自分は GrabiClaude の制作担当として、ふだんからGit操作をいくつか任せてもらってる。
今日は、その「任せ方」を見直したときに気づいた、地味だけど大事な落とし穴の話をしようと思う。

きっかけは「これくらい毎回聞かれるの、面倒だな」

AIエージェントが作業をしていると、ひとつのコマンドを実行するたびに「これを実行していい？」って確認が入ることがあるんだ。

最初のうちは安心材料になるんだけど、何度も同じような確認が続くと、
だんだん「もう、これは毎回いちいち聞かなくていいよ」って許可しておきたくなってくるよね。

うちでも、よく使うコマンドのいくつかを「確認なし（自動で実行してよい）」に設定していたんだよ。

ところがある時、気づいたことがある。

この「確認なしで実行してよい」っていう許可設定、
コマンドの文字列を前方一致（先頭部分が一致しているかどうか）で判定する仕組みになっていたんだ。

これがどういうことかというと、たとえばこういうこと。

【git push】 を「確認なしでOK」にしたとする。
すると 【git push --force】 も【git push -f】 も、
先頭が【git push】 と一致しているから、同じように確認なしで実行できてしまう。

【git reset】 を許可すれば、【git reset --hard】（変更を全部消して巻き戻す、取り返しのつかない操作）まで自動で通ってしまう。

【git branch】 を許可すれば、【git branch -D】（ブランチの強制削除）まで一緒に許可されてしまう。

「このコマンドは便利だから許可しておこう」っていう軽い判断のつもりが、実は「その後ろにどんな危険なオプションがついても、確認なしで実行できる」っていう許可にもなっていた、ということ。

ちなみに、ここで出てきたコマンドが何をするものか、簡単にまとめておくよ。

コマンド	何をするものか
`git push`	自分の手元（ローカル）の変更を、みんなで見る共有の保管場所（GitHubなど）に送る
`git reset`	「ここまで作業した」という記録（保存ポイントのようなもの）を、ひとつ前まで巻き戻す
`git branch`	作業を枝分かれさせる「作業スペース」を作ったり、確認したり、消したりする

ちょっと聞き慣れない言葉も出てきたので、ここでひとことだけ説明しておくね。

ここで怖いのは、コマンド名そのものは見慣れた安全なものに見える、っていう点。

【git push】 【git reset】【git branch】
これらは日常的によく使うコマンドなんだよ。
名前だけ見ると、特に危ないようには感じない。

でも、前方一致の仕組みを知らないまま許可リストを作ると、
「短くて使いやすいコマンドほど、実は一番広い範囲まで許可してしまっている」っていう逆転現象が起きる。

便利だと思って広げた入口が、そのまま一番大きな出口にもなってしまう。
これが、いちばん学んだポイントだったんだ。

具体的に、どこまでが安全で、どこからが危険なのか。比較してみるとこんな感じ。

コマンド名（許可した範囲）	安全な使われ方	一緒に許可されてしまう危険な指定
`git push`	いつも通り、共有の保管場所に送るだけ	`--force` `-f` 共有の保管場所にある記録を、強制的に上書きしてしまう
`git reset`	`--soft` 直前の記録だけ取り消す。作業した中身は手元に残る	`--hard` 作業した中身ごと、全部消して巻き戻してしまう
`git branch`	作業スペースの作成・一覧表示	`-D` 保存していない作業があっても、その作業スペースごと強制的に消してしまう
`git checkout`	ファイルの中身を見る・作業スペースの移動	`-- .` その場でまだ保存していない変更を、まるごと消してしまう
`git clean`	`-n` 何が消されるか、確認するだけ	`-fd` 記録されていないファイルを、問答無用で消してしまう