※この記事は Zennの記事 からの転載です。
AI エージェントに作業を任せていると、必ずぶつかる問いがあります。どこまで自動で進めさせて、どこで人が確認するかです。
確認を増やすと、承認の画面が多すぎて、人は中身を読まずに「はい」を押すようになります。確認を減らすと、ある日 AI が本番のデータを消したり、間違ったメールを送ったりします。
この記事では、承認の置き場所を決めるための考え方を整理します。軸は1つ、その操作は取り消せるかです。
操作を3つに分ける
AI がやる操作を、取り消せるかどうかで分けます。
| 種類 | 例 | 間違えたとき |
|---|---|---|
| 読むだけ | ファイルを読む、ログを見る、検索する | 何も起きない |
| 取り消せる書き込み | 手元のファイルの編集、下書きの保存、テスト環境への反映 | 戻せば済む |
| 取り消せない・外に出る操作 | 本番への公開、メール・チャットの送信、データの削除、支払い、権限の変更 | 戻せない。他人に届く |
人が止めるべきなのは、3つ目だけです。1つ目と2つ目まで毎回確認していると、承認の数が増えて、3つ目の確認まで流し読みになります。
逆に言えば、2つ目を増やす工夫（下書きを経由する、テスト環境を挟む、バックアップを取ってから書く）をすると、3つ目に当たる操作そのものが減ります。
原則1：承認は「作業ごと」に、記録に残る形で
「公開していい？」「いいよ」という会話の中の承認は、あとから何を承認したのかが分からなくなります。AI のほうも、会話の流れから承認の範囲を広く取り違えることがあります。
承認は、作業ごとに、対象を特定して残します。
- 2026-10-28 人：承認（対象：下書き 7281〜7299 の19件を公開）
- 2026-10-28 AI：公開を実行。19件とも外から表示を確認
こうしておけば、AI が実行したコマンドが承認の範囲に収まっているかを、あとで照合できます。
原則2：道具の既定を「何もしない」にする
AI に渡すスクリプトやコマンドは、何も付けずに動かしたら、何も書き込まない作りにします。
deploy --dry-run # 何をするか出すだけ（既定）
deploy --apply --only item-01 # 1件だけ、下書きとして書く
deploy --apply --publish --only item-01 # 1件だけ公開する
- 書き込みは
--applyを明示したときだけ - 取り消せない操作（公開）は、さらに別の引数を明示したときだけ
- 対象を1件ずつ絞れる
こうしておくと、AI が引数を間違えても、被害は「何も起きない」か「下書きが1件増える」で止まります。逆に、引数なしで本番に書き込む道具は、どんなに便利でも AI に渡しません。
原則3：AI は自分の権限を広げられない
AI エージェントには、「許可リスト」（確認なしで実行してよいコマンドの一覧）を持たせることが多いです。このリストを AI 自身が書き換えられると、確認の仕組みは意味を失います。
権限を広げるのは、必ず人です。広げ方も段階を踏みます。
| 段階 | 許可の範囲 | 向いている場面 |
|---|---|---|
| 1 | 承認した作業のコマンドそのもの（1行） | 初めての操作、まだ道具を信用しきれないとき |
| 2 | そのスクリプト全体（どの引数でも） | 道具が原則2の作りになっていて、承認の記録も残る運用が回っているとき |
| 3 | 操作の種類ごと自動 | 取り消せる操作だけ |
取り消せない操作を、3まで広げることはしません。
原則4：終わったかどうかは、結果の側で数える
コマンドが成功（終了コード 0）で終わっても、本当に終わったとは限りません。公開したつもりのページが下書きのまま、送ったつもりのメールが下書き箱のまま、ということは起きます。
取り消せない操作のあとは、外から結果を数えます。
for path in $(cat targets.txt); do
code=$(curl -s -o page.html -w '%{http_code}' "https://example.com/$path/")
echo "$code $(grep -c undefined page.html) $path"
done
- 全件が見えているか（下書きのままなら 404）
- 表示が崩れていないか（テンプレートの埋め忘れは
undefinedとして出やすい）
これを AI に必ずやらせると、「やりました」の報告を人が信じる必要がなくなります。
例：AI 側の安全装置に止められたとき
私は AI（Claude Code）に、Web サイトのページの公開まで任せています。人が承認した19件のページを公開させたところ、AI 側の自動チェックで「本番への配備」として止められました。AI が許可リストにスクリプトを足そうとすると、それも「自分の権限の変更」として止められました。
これは、原則3がそのまま実装されている状態です。私は、承認した作業のコマンドそのものだけを許可して公開させ、外から19件の表示を確かめさせました（原則1・4）。スクリプトが原則2の作りになっていることを確かめたうえで、許可を広げるかを決めることにしています。
まとめ
| 人が止める場所 | 取り消せない・外に出る操作だけ。読む・取り消せる書き込みは止めない |
| 承認の残し方 | 作業ごとに、対象を特定して記録に残す |
| 道具の作り | 既定は何もしない。書き込み・公開は引数で明示。対象は1件ずつ絞れる |
| 権限 | 広げるのは人だけ。コマンド1行 → スクリプト全体 と段階を踏む |
| 終わったか | 結果の側で数える。終了コードを信じない |
確認の数を減らしたいときは、確認を外す前に「その操作を取り消せる形に変えられないか」を考えてみてください。