この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Linuxの最小権限・各コマンドの公式manualを確認する前提で、AI生成コマンドを人間が検証するための実務チェックとして整理しています。
検証ステータス：安全確認フロー設計済み・危険コマンドの実行検証なし
AIが生成したコマンドは、見た目が自然でも対象パスや権限、shell展開を間違えることがあります。sudo を付ける前に5段階で読みます。
1. 読み取りか変更か
ls や cat のような確認なのか、削除・上書き・権限変更なのかを最初に分類します。変更系なら次へ進む前に対象を狭めます。
2. 対象パスを展開後まで考える
*、変数、相対パス、~ が何を指すか確認します。AIへ渡す例では実在の内部パスや秘密情報を使わず、/tmp/papanda-demo のようなテスト領域へ置き換えます。
3. sudoが本当に必要か
通常権限で確認できるならsudoを外します。「Permission deniedが出たからsudo」ではなく、その操作に管理者権限が必要な理由を確認します。
4. 破壊的オプションを見る
--force、recursive、overwrite等が含まれる場合、何を広げるオプションか公式manualで確認します。危険な例を本番パスで試しません。
5. dry-run・backup・rollbackを決める
対応コマンドにdry-runがあれば先に使い、なければテストディレクトリやread-only確認へ分解します。戻せない操作ならバックアップ方法を先に決めます。
プロンプトも1か所変える
AIへ「コマンドを出して」だけでなく、次を追加します。
実行コマンドの前に、変更対象、必要権限、破壊的オプション、dry-runまたは安全な確認方法、元に戻す方法を分けて示してください。不明な点は推測せず不明と書いてください。
同じ依頼でこの条件の有無を比べ、検証材料が増えるかを観察します。
仕事で使うなら
サーバー保守、AI生成PowerShell、SQL、クラウドCLIでも「まず変更範囲と権限を読む」という考え方は共通です。
まとめ
AIの出力は実行許可ではありません。read/change → scope → privilege → destructive option → rollbackの順に人間が確認します。
