AIにコマンドを書かせて事故らない｜破壊的コマンドを弾く確認の型
「このディレクトリ、まとめて消しておいて」とAIに頼んだら、ワンライナーが返ってきた。 意味を全部は追えないけれど、それらしく動きそうだから、そのままコピペしてEnter——。
多くの現場で、これは日常です。そして、たいていは問題なく終わります。 でも、ごくまれに、その一回が「消したくなかったファイルまで消えた」「本番のデータが飛んだ」に化けることがあります。しかも、破壊的なコマンドほど取り消しがきかない。ゴミ箱にも残らず、Ctrl+Zも効かない。
先に言っておきたいのは、これはあなたの不注意を責める話ではないということです。 AIが出すコマンドは、たいてい「一般的にはこう」で正しい。ただ、AIはあなたの環境を見ていません。今いるディレクトリ、権限、その変数に何が入っているか——それを知らないまま、平然と rm -rf や git reset --hard を混ぜてくることがある。だから必要なのは、気合いや反省ではなく、貼る前の数秒で危ないコマンドを見分ける型です。
結論：AIが出したコマンドは、①破壊系のキーワード（rm -rf/dd/git reset --hard/DROP/> ファイルなど）が含まれていないか、②対象の範囲（どのディレクトリ・どのDB・どのブランチに効くか）、③取り消せるか（バックアップ・dry-run・確認プロンプトがあるか）——この3点だけを実行前に見る。危ないと感じたら、そのまま実行せず「まず何をするコマンドか説明して」「安全に確認できる形に直して」とAIに聞き返す。わからないコマンドは実行しない、が唯一にして最強の防御です。
コマンドが読めないのは、勉強不足だからではありません。AIが自然言語で頼めば動くものを返してくれる時代に、一行ずつ意味を暗記している人のほうが少ない。だからこそ「読めなくても、危ないかどうかは見分けられる」型を持っておく。今日はその型を、コピーして使えるチェックリストと一緒に整理していきます。
なぜ「そのままコピペ」が事故るのか
AIが出すコマンドが危ういのは、あなたの状況を知らないまま断定してくるからです。
たとえば「不要なログを消したい」と頼むと、rm -rf logs/* のようなコマンドが返ってきます。一般論としては正しい。でもAIは、あなたが今どのディレクトリにいるかを知りません。もし logs/ が思っていた場所と違ったら、あるいは変数展開が空になっていたら、消える範囲はまるで変わります。
とくに怖いのは、次のようなパターンです。
- 変数が空になる：
rm -rf $DIR/の$DIRが未定義だと、rm -rf /に化ける。一文字の差が、全消去になる。 - 今いる場所が違う：相対パスのコマンドは、実行時のカレントディレクトリ次第で対象が変わる。AIはあなたのカレントを見ていない。
- 本番と開発を取り違える：接続先が本番DBのまま
DELETEやDROPを流すと、戻せない。AIは接続先を知らない。 - 上書きリダイレクト：
>は既存ファイルを問答無用で上書きする。>>（追記）のつもりが>になっていると、中身が消える。
やっかいなのは、これらがエラーにならずに"成功"してしまうことです。 文法的には正しいので、コマンドは何事もなく実行される。おかしいと気づくのは、たいてい消えた後です。だから「動かして確かめる」が使えない。動かす前に見分けるしかないのが、破壊的コマンドの難しさです。
この構造は、AIがそれらしい嘘を事実のように書くハルシネーション（もっともらしい誤り）と根は同じ。コマンドの場合、その"嘘"が一発で環境を壊しうる、という点だけが違います。
実行前に見る3つのポイント
コマンドを一行ずつ完璧に理解する必要はありません。 見るのは、危ないかどうかを分ける3点だけ。ここに引っかからなければ、たいていは安全です。
1. 破壊系のキーワードが入っていないか
まず、「消す・上書きする・戻せなくする」系の言葉が含まれていないかをざっと見ます。これが入っていたら、それだけで「一度立ち止まる」合図です。
代表的なものだけ覚えておけば十分です。
| キーワード | 何をするか | 危ない理由 | |
|---|---|---|---|
rm -rf | ディレクトリごと強制削除 | 確認なしで消え、ゴミ箱に残らない | |
dd | ディスクへ直接書き込み | 出力先を間違えるとディスクを丸ごと壊す | |
mkfs / format | ディスクを初期化 | 中身が全部消える | |
> ファイル | ファイルを上書き | 既存の中身が一瞬で消える | |
git reset --hard / git clean -fd | 変更・未追跡ファイルを破棄 | コミットしていない作業が戻せない | |
DROP / TRUNCATE / DELETE（WHEREなし） | テーブル・行を削除 | 本番だと復旧に大ごと | |
chmod -R / chown -R | 権限を再帰的に変更 | 範囲を誤ると広範囲が動かなくなる | |
kill -9 / killall | プロセスを強制終了 | 対象を誤ると別の作業も落ちる | |
| `curl ... \ | sh` | 落としてそのまま実行 | 中身を見ずに任意コードを走らせる |
全部を暗記しなくても大丈夫。「消す・上書き・初期化・強制・パイプで実行」あたりの匂いがしたら止まる、くらいの感覚で十分です。
2. 対象の範囲はどこまでか
キーワードそのものより、それがどこに効くのかのほうが重要なこともあります。同じ rm -rf でも、対象が明確な一つのフォルダなら怖くありません。
- 絶対パスか相対パスか：
/var/log/app/のような絶対パスは範囲が固定。相対パス（./tmpやlogs/）は今いる場所しだいで変わる。 - ワイルドカードの広さ：
や-r（再帰）が付くと、思ったより広く効く。が何にマッチするか、頭の中で展開してみる。 - 変数が展開されると何になるか：
$DIR$ENVなどが入っていたら、その中身を先に確認する。空だったら大惨事、という定番の事故を防げる。 - どの環境に効くか：DB接続先・対象ブランチ・サーバーが、開発か本番か。ここは、コマンドの見た目だけではわからないので自分で確かめる。
範囲を詰めるコツは、心の中で一度実行してみることです。「今このディレクトリで、この変数がこの値だったら、何が消えるか」。これが即答できないなら、まだ実行しないほうが安全です。
3. 取り消せるか（戻せる余地があるか）
最後に、もし間違っていたら戻せるかを確認します。戻せるなら、多少の不安があっても試せます。戻せないなら、慎重さの基準を一段上げます。
- バックアップやコミットは済んでいるか：
git reset --hardの前に、消えて困る変更はgit stashかコミットで退避したか。ファイル操作なら、対象をコピーしてあるか。 - dry-run（試し実行）できるか：
rsync --dry-run、git clean -n(--dry-run)、多くのツールに「実際には消さず、何が対象かだけ表示する」オプションがある。まずそれで対象を確かめる。 - 確認プロンプトを付けられるか：
rm -i（一つずつy/nを聞く）、rm -I（大量削除の前にまとめて確認）を足すだけで、暴発が一段減る。 - ゴミ箱経由にできるか：
rmの代わりに、ゴミ箱に移すツール（trashなど）を使えば、消しても後から戻せる。
この3点——破壊系か／範囲はどこか／取り消せるか——を通すのに、慣れれば数秒です。この数秒が、取り返しのつかない数分を防ぎます。
AIに頼むときのプロンプトの型
そもそも、危ないコマンドを出させにくくする頼み方があります。ポイントは、AIに「安全側の作法」を最初から指示しておくことです。
渡すと良い指示：
- まず説明させる：「実行する前に、このコマンドが何をするか一行ずつ説明して」
- 破壊系を避けさせる：「消す・上書きするコマンドは、いきなり実行形ではなく、まず対象を表示する形（dry-run）で出して」
- 範囲を明示させる：「対象のパス・接続先を決め打ちにして、変数やワイルドカードに頼らない形にして」
- 戻せる形にさせる：「削除の前にバックアップを取る手順も一緒に付けて」
聞き方の例：
次の作業をしたいので、シェルコマンドを提案してください。
## やりたいこと
（例：logs ディレクトリの30日より古いファイルを削除したい）
## 環境
- OS：（例：Ubuntu 22.04）
- 今いるディレクトリ：（例：/home/app/project）
- 対象は開発／本番：（例：開発。本番では絶対に実行しない）
## お願い
1. まず、そのコマンドが何をするかを一行ずつ説明してください。
2. 消す・上書きする操作は、いきなり実行せず、
最初に「対象一覧だけ表示する（dry-run）」形も併せて出してください。
3. 変数やワイルドカードに頼らず、対象パスは決め打ちにしてください。
4. 取り消せない操作には、その旨と、事前バックアップの手順を添えてください。「まず説明して」を挟むだけで、意味を追わずにコピペする流れが一段止まります。前提の渡し方そのものは、AIにコードを書かせる前に渡すべき前提・制約の伝え方と同じ考え方です。環境情報を先に渡すほど、あなたの状況に合った——つまり事故りにくい——コマンドが返ってきます。
実行する場所も、安全側に寄せる
コマンド単体の確認に加えて、実行する場所を安全にしておくと、うっかりの被害を小さくできます。これはAIうんぬんの前の、環境側の備えです。
- 本番に直接つながない：本番サーバー・本番DBのターミナルでは、生成コマンドをいきなり試さない。まず手元やステージングで。
- 使い捨ての場所で試す：範囲が不安なコマンドは、テスト用のディレクトリやコンテナで一度動かして、対象が想定どおりか見る。
- 権限を絞る：普段から
sudoを付けない。root権限で走らせるほど、間違えたときの被害が広がる。 - エイリアスで保険をかける：
rmをrm -i(確認あり）にしておく、trashを既定にする、といった設定で、暴発の一歩手前に確認を挟む。
「コマンドを見分ける」と「危なくても被害が小さい場所で試す」。この2枚重ねがあると、確認をひとつ見落としても致命傷になりにくくなります。とくにAIエージェントに手を動かさせる場合は、AIエージェントの自走をどこまで許すか（止める・戻す設計）も併せて考えておくと安心です。
ありがちな落とし穴と、その回避
コマンドをAIに任せるとき、つまずきやすい所を先に潰しておきます。
- 「動きそうだから」で意味を確かめない：それらしさと安全は別。破壊系が入っていたら、動きそうでも一度説明を求める。
- 変数の中身を見ずに実行する：
$DIRが空だと事故る定番。展開後に何になるかを、実行前に一度echoして確かめる。 >と>>を見間違える：追記のつもりで上書きしてファイルを飛ばす。リダイレクトの向きは指差し確認。- 本番のターミナルでいきなり試す：戻せない環境ほど、生成物をぶっつけ本番にしない。まず安全な場所で。
curl ... | shを中身を見ずに流す：ネット上のスクリプトを直接実行しない。一度ファイルに落として、中身を読んでから。- エラーが出ないのを"成功"と思う：破壊的コマンドは、間違っていてもエラーを出さずに完了する。無事＝正解、ではない。
落とし穴のほとんどは、「読めないコマンドを、読めないまま実行した」瞬間に生まれます。 わからないコマンドは実行しない。この一線を保つだけで、大きな事故のほとんどは避けられます。
明日からやること（小さく始める3つ）
いきなり全部を仕組み化しようとせず、まずこの3つから。
- 次にAIがコマンドを出したら、実行の前に「何をするコマンドか一行ずつ説明して」と一回聞き返す：意味を追わずに貼る癖を、一手間で止める。
- 削除・上書き系は、まず dry-run（
git clean -n/rsync --dry-runなど）で対象を表示させてから本番実行する：戻せない操作ほど、先に「何が対象か」を目で見る。 rmをrm -iにするなど、暴発の手前に確認を挟む設定を1つ入れる：自分の反射神経に頼らず、環境側に保険をかける。
この3つだけでも、「読めないコマンドをEnter」する夜が、少し落ち着いたものになります。
コピーして使う「コマンド実行前チェックリスト」
AIが出したコマンドを実行する前に、上から順に見てください。全部でなく、危なそうな所だけで十分です。
# AI生成コマンド 実行前チェック
## ① 破壊系か
- rm -rf / dd / mkfs / > 上書き が含まれていないか：
- git reset --hard / git clean -fd が含まれていないか：
- DROP / TRUNCATE / WHEREなしの DELETE が含まれていないか：
- curl ... | sh のような「落として即実行」がないか：
## ② 範囲はどこか
- 対象は絶対パスか（相対パス・カレント依存になっていないか）：
- ワイルドカード（*）や -r が、想定より広く効かないか：
- 変数（$DIR など）の展開後の中身を確認したか（空なら危険）：
- 効く先は開発か本番か（DB接続先・ブランチ・サーバー）：
## ③ 取り消せるか
- 消えて困るものは、バックアップ／コミット／stash 済みか：
- dry-run（試し実行）で対象を先に確認したか：
- rm -i / rm -I など、確認を挟む形にできないか：
## ④ 実行の場所
- 本番の環境でいきなり試していないか：
- 意味がわからないコマンドを、わからないまま実行していないか：最後に
AIが出したコマンドを前に、実行ボタンで一瞬ためらう——それは、慎重さの証拠です。 読めないコマンドに手が止まるのは、あなたが仕事を雑にしていないから。その一瞬の「待てよ」を、責める必要はありません。
全部のコマンドを暗記しなくて大丈夫です。今日ひとつ、次にAIがコマンドを出したら「まず説明して」と聞き返す。それだけで、事故の入口がひとつ閉じます。 AIは速い下書き係ですが、Enterを押すのはあなたです。その一線さえ持っていれば、コマンド生成は怖いものではなく、頼れる時短になります。