Skip to main content

第29章：AIを“危険にしない”使い方：データ操作はガードレール必須🛡️🤖

この章はひとことで言うと、**「AIに手伝ってもらいながら、データを絶対に事故らせない習慣づくり」です😇 バックアップ・復元・初期化・volume操作は、“一発で取り返しがつかない”**のが怖いところ。だから AIを使うほど、手順と確認が大事になります💣➡️✅

1) まず押さえる：AIは便利だけど「最後に実行するのは自分」👀✋​

AIは超優秀な相棒ですが、あなたの環境の実データを見てるわけじゃないので、平気で強いコマンドも提案してきます😅 特に危険なのが、こういうやつ👇

  • docker compose down -v（volumeごと消える可能性）💥
  • docker volume rm ... / docker volume prune（消したら戻らない）🫠
  • SQLの DROP DATABASE / TRUNCATE（一瞬で空）😱

なので、この章では **「AIの出力を安全にする型」**を作ります🧰✨

2) AIに貼っていい情報 / ダメな情報（3色ルール）🎨🔒​

ここは最重要です。迷ったら **“赤は絶対貼らない”**でOKです🙆‍♂️

色送っていい？例理由
🟢OKだいたいOKdocker compose.yml（秘密なし版）、エラーログ（個人情報なし）、ディレクトリ構成事故リスクが低い
🟡注意なるべく削るdocker inspect 出力、docker compose config、SQL（本番相当）内部情報が混ざりやすい
🔴禁止貼らない.env の値、APIキー、パスワード、個人情報、顧客データ、DBダンプ本体漏えいが致命傷🧨

特に、IDE内の GitHub Copilot みたいなAIチャットでも、入力したプロンプトや応答の扱いは設定や提供形態で変わり得るので、秘密は最初から貼らないのが鉄板です🔒(GitHub Docs) （「貼らない」が一番ラクで安全☺️）

3) “AIに渡す素材”は「コンテキストパック」にして、最初に赤塗り🧹📦​

いきなりログ全部ドーン！は危険です⚠️ 代わりに、AIに渡す情報を最小セット化します。おすすめはこれ👇

**コンテキストパック（例）**📦

  • 何をしたいか：例「DBの初期化が2回目に走らない」

  • いまの状況：例「volumeは残したまま」

  • 関係ファイル（秘密は伏せる）

    • compose.yml（パスワードは ***REDACTED***）
    • init/ のファイル名一覧

  • コマンド実行ログ（必要最小限）

  • 期待する結果（例「初回だけseed投入、普段は保持」）

この形にしておくと、AIの回答精度も上がるし、漏えいも減ります😎✨

4) 破壊を防ぐ「4ステップ実行」：読む→確かめる→小さく試す→実行✅🧪​

データ操作は **“コマンドを打つ前”**が勝負です🔥

ステップ①：AIの提案を「危険タグ」で仕分け🚧​

  • ✅ Safe：確認系（例：ls, docker volume ls）
  • ⚠️ Risk：変更系（例：docker compose up -d、migration）
  • ☠️ Dangerous：破壊系（例：down -v、volume rm、prune）

ステップ②：まず「見える化」してから触る🔎​

Composeのvolumeは、トップレベルで定義してサービスから参照できます。ここが理解できると「どれ消える？」が読めるようになります🧠(Docker Documentation)

ステップ③：消す前に“隠れる”罠を疑う🫥​

bind mount は **マウント先に既にあるファイルを“見えなくする（obscured）”**動きをします。 「消えた！」じゃなく「隠れた！」の可能性、めっちゃあります😇(Docker Documentation)

ステップ④：本番級は“別名で復元テスト”してから切り替え🎭​

Dockerのvolumeは、公式ドキュメントでも バックアップ・復元・移行の手順が案内されています。 重要なのは **“復元を一発で上書きしない”**こと（別volumeに戻して動作確認→OKなら切り替え）です🧯(Docker Documentation)

5) AIに「危険な回答をさせない」プロンプトの型🧠🛡️​

AIは、聞き方で安全性が変わります👍 以下をそのままコピペで使ってOKです（秘密は伏せた状態でね🔒）

① 解析だけしてほしい（コマンド禁止）🕵️‍♂️​

あなたはDocker/Composeのトラブルシューティング担当です。
まず原因候補を3つに絞って説明してください。
この段階では「実行コマンド」を一切出さないでください（出すなら最後に候補として、危険度ラベル付きで）。
不足情報があれば質問してから進めてください。

② 手順を出してほしい（必ず安全チェック付き）🧰​

データを壊さないことが最優先です。
提案する手順は「読む/確認/小さく試す/実行」の4段に分けてください。
破壊系コマンド（down -v、volume rm、prune、DROP/TRUNCATEなど）は☠️ラベルを付け、
代替案（安全な方法）を必ず先に提示してください。

③ スクリプトレビューしてほしい（危険点に赤入れ）🩺🟥​

このバックアップ/復元スクリプトをレビューしてください。
目的：安全に運用（事故ゼロ）です。
出力は：
1) 危険点（データ消失/上書き/漏えいの可能性）
2) 修正案（より安全なやり方）
3) 実行前チェックリスト（5項目）
の順でお願いします。

6) 「AIに貼らない」ための置き換えテンプレ（赤塗りのコツ）🧽🔑​

置き換えルール（例）

  • パスワード → ***REDACTED_PASSWORD***
  • APIキー → ***REDACTED_API_KEY***
  • ホスト名/URL → example.internal
  • メール/ID → user@example.com
  • 実データ → “件数だけ”（例「ユーザー約2万件」）

これだけで、AI相談が一気に安全になります😊

7) ミニ演習：AIを使っても事故らない流れを体に覚えよう💪🎮​

演習A：初期化スクリプトが2回目に走らない🪤​

よくある原因：volumeが残ってて初期化がスキップされる AIに聞くときのポイント：

  • 「破壊コマンド禁止で原因だけ」→「安全チェック付き手順」へ段階的に

演習B：volume名が思ったのと違う😇​

やること：Compose定義 → 実際のvolume一覧 → ひもづけ確認 ここで焦って prune しがちなので、**“消さずに確認”**を徹底します✅

演習C：tarバックアップ運用の“復元テスト手順”をAIに作らせる🎭​

AIは手順書づくりが得意！ ただし、復元先は別volume、検証OKで切替、が鉄則です🧯(Docker Documentation)

8) 成果物：プロジェクト用「AI利用ルール（超短い）」📌📝​

最後に、これを docs/ai-guardrails.md として置いちゃいましょう👍

## AI利用ガードレール（データ運用）

## 絶対に貼らない
- パスワード / APIキー / .envの値
- 個人情報・顧客データ・DBダンプ本体
- 社内URLや内部構成の詳細（必要なら伏せる）

## AIに頼ってOK
- 原因候補の整理、チェックリスト作り、手順書のドラフト
- コマンドの意味の解説、リスクの洗い出し
- スクリプトの安全レビュー（危険点の指摘）

## 実行ルール
- コマンドは「読む→確認→小さく試す→実行」
- 破壊系（down -v / volume rm / prune / DROP/TRUNCATE）は最後の手段
- バックアップは“復元テストできて初めて合格”（別volumeで検証してから切替）

9) ついでに：環境まるごと移行系のときは公式手順も見る🧰💾​

「PC移行」「Docker Desktop壊れた」みたいなときは、プロジェクト単位じゃなくDocker環境全体のバックアップ/リストアが役立つ場面があります。公式の手順があるので、そういうケースではそっちを優先すると安全です🆘(Docker Documentation)

この第29章をマスターすると、AIがどれだけ強い提案をしてきても、あなたの運用が“事故らない型”で守られるようになります🛡️✨ 次の章（データ運用ルーチン）にも、そのまま直結しますよ〜🏁🎉