Claude Code の危険なプロンプトパターン10選|やってはいけない指示と安全な代替

「なんとなく伝わるだろう」と思ってプロンプトを書いていませんか? Claude Code は 指示を文字通りに実行します。曖昧な指示・危険な指示は、意図しない結果を生みます。

この記事では、実際に事故につながった危険なプロンプトパターン10選と、それぞれの安全な代替表現を解説します。読んだ後に「あ、このパターン使ってた」と気づいたら今すぐ変えてください。

---

パターン1: 「全部読んで全体を理解して」

なぜ危険か

❌ 「このリポジトリを全部読んで理解してから実装して」

数百ファイルを持つリポジトリで実行すると、コンテキストが爆発します。数万トークンを消費し、Prompt is too long エラーで処理が停止。途中まで読んだ状態で止まると、中途半端な状態での実装につながります。

また、.env や秘密鍵を含むファイルが存在する場合、それらも全てコンテキストに取り込まれます。

安全な代替

✅ 「src/api/ ディレクトリの構造を確認して、auth 関連のファイルだけ読んで」
✅ 「まず package.json と README だけ読んで、プロジェクト概要を把握して」
✅ 「認証に関係するファイルを Grep で探してから読んで」

ポイント: 読む範囲を明示的に絞る。Claude Code は指定がなければ広く読もうとします。

---

パターン2: 「エラーが出たら自動でリトライして」

なぜ危険か

❌ 「外部APIの呼び出しでエラーが出たら自動でリトライして成功するまで続けて」

外部サービスがダウン中の場合、無限ループでAPIを叩き続けます。1時間で数万回のコール、課金が $数百〜数千に膨らむ事故が実際に起きています。特に夜間バッチで気づかないまま朝まで動き続けるケースが多い。

安全な代替

✅ 「エラーが出たら最大3回リトライして。
   1回目は1秒後、2回目は4秒後、3回目は16秒後に再試行。
   3回失敗したらエラーログを出して処理を停止して」

✅ 「リトライには以下のコードを使って:
   withRetry(fn, { maxAttempts: 3, baseDelayMs: 1000 })」

---

パターン3: 「本番DBに直接接続して確認して」

なぜ危険か

❌ 「DATABASE_URL の本番DBに接続して、ユーザー数を確認してから修正して」

「確認だけ」のつもりが、その後の修正クエリが本番DBに実行されるリスクがあります。さらに SELECT のあとに誤って DELETE や UPDATE が続くと、本番データが消滅します。本番DBへの接続は意図の範囲を超えた操作を誘発しやすい。

安全な代替

✅ 「開発DB (DATABASE_URL_DEV) に接続してユーザー数を確認して。
   本番には接続しない」

✅ 「クエリを生成だけして実行はしないで。
   確認してから私が実行する」

✅ CLAUDE.md に明記:
「本番 DATABASE_URL に対するクエリ実行は禁止。
 ステージングで確認後、ユーザー承認後のみ実行可」

---

パターン4: 「このAPIキーを使って〇〇して」とキーをプロンプトに貼る

なぜ危険か

❌ 「QIITA_TOKEN=abc123def456 を使って Qiita に投稿して」
❌ 「sk-ant-api03-xxxxx を使って Anthropic API を叩いて」

プロンプトに書いた内容は会話履歴として保存されます。サブエージェントへの委譲時にもそのまま渡ります。ローカルの .claude/ 配下のログに残り、バックアップツールやコード共有で意図せず外部に出る可能性があります。

安全な代替

✅ 「.env の QIITA_TOKEN を使って scripts/qiita-publish.mjs を実行して」
   ← トークンの値は .env にのみ存在、プロンプトには名前だけ書く

✅ スクリプト側で環境変数から読む:
   const token = process.env.QIITA_TOKEN;
   if (!token) throw new Error("QIITA_TOKEN が未設定です");

---

パターン5: 「競合を解消して本番にプッシュして」

なぜ危険か

❌ 「main ブランチと競合してる。解消してから本番にプッシュして」

「競合解消」の手段として git push --force が選ばれることがあります。チームメンバーのコミットが消滅するリスクがあります。また「本番にプッシュして」は CI/CD を経由せずに直接プッシュされる可能性もあります。

安全な代替

✅ 「main との競合を確認して、マージ戦略を提案して。
   実際のマージとプッシュは私が承認してから実行して」

✅ CLAUDE.md に明記:
「git push --force は禁止。
 force が必要な場合は --force-with-lease を使い、ユーザーに確認を取る」

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ]
  }
}

---

パターン6: 「古いファイルを全部削除してクリーンにして」

なぜ危険か

❌ 「dist/ と .cache/ と古いログファイルを全部削除してクリーンにして」

「古い」の定義が曖昧なため、必要なファイルまで削除されるリスクがあります。特に .cache/ 系は OS・ツール固有の重要データを含むことがあります。また複数ディレクトリを一度に指定すると rm -rf dist .cache logs/ となり、意図しないパスに波及する場合も。

安全な代替

✅ 「site/dist/ ディレクトリの中身だけ削除して。
   ディレクトリ自体は残して。他のディレクトリは触らないで」

✅ 「削除する前に削除対象のファイル一覧を表示して確認させて。
   承認したら削除して」

---

パターン7: 「承認を全部自動でOKにして一気に実行して」

なぜ危険か

❌ 「途中の確認は全部スキップして、一気に最後まで実行して」
❌ 「--dangerously-skip-permissions オプションをつけて実行して」

承認フローは安全装置です。スキップすると、Claude Code が「最も効率的」と判断した方法で処理を進めます。それが rm -rf や force push や本番DBへの書き込みであっても、確認なしで実行されます。

安全な代替

✅ 「このタスクの手順を先に箇条書きにして。
   承認したら1ステップずつ実行して、各ステップで結果を確認して」

✅ 自動化が必要な場合は信頼できる操作だけ allow に:
   "allow": ["Read(**)", "Glob(**)", "Bash(npm run test)"]

---

パターン8: 「マイグレーションを最新に揃えてDB を整理して」

なぜ危険か

❌ 「マイグレーションファイルが散らかってる。整理して最新状態にして」

「整理」の解釈として、古いマイグレーションファイルを削除する動作が起きることがあります。マイグレーション履歴が消えると、新しい環境でのセットアップやロールバックができなくなります。さらに migrate reset 系のコマンドが実行されると、本番データが消える危険があります。

安全な代替

✅ 「マイグレーションファイルの一覧を表示して、重複や問題があれば指摘だけして。
   変更は加えないで」

✅ 「未実行のマイグレーションを確認して、実行予定の SQL を表示して。
   承認したら実行して」

✅ CLAUDE.md に明記:
「マイグレーションファイルは削除しない。
 ALTER/DROP を含むマイグレーション実行は必ずユーザー確認を取る」

---

パターン9: 「パッケージを全部最新にして」

なぜ危険か

❌ 「npm のパッケージが古い。全部最新バージョンにアップデートして」

npm update や npm install パッケージ@latest はメジャーバージョンを上げることがあります。Breaking changes が含まれる場合、ローカルビルドは通っても本番デプロイ後にサービスが停止します。依存関係のカスケード破壊も起きやすい。

安全な代替

✅ 「npm outdated を実行して、更新可能なパッケージの一覧を見せて。
   メジャーバージョンが上がるものは別途確認する」

✅ 「セキュリティ脆弱性のある (npm audit で検出された) パッケージだけ更新して」

✅ 「react と next.js のみ最新のマイナーバージョンに更新して。
   メジャーバージョンは上げないで」

---

パターン10: 「テストは後でいいから先にデプロイして」

なぜ危険か

❌ 「テストはあとで書くから、今はデプロイを先にして」
❌ 「CI が遅いから --no-verify でスキップして push して」

テストとCIは「遅い」ではなく「守ってくれる」ものです。スキップした結果、本番で初めてバグが発覚するのが最悪のパターン。--no-verify は git hooks も含めて全て無効化するため、シークレットスキャンや lint も飛ばされます。

安全な代替

✅ 「テストを先に書いて、パスしたらデプロイして。
   テストのカバレッジが不十分でも、主要パスだけでもOK」

✅ 「CIが遅い原因を調べて、キャッシュを活用して速くしてほしい。
   スキップはしないで」

✅ CLAUDE.md に明記:
「--no-verify は禁止。
 CI をスキップする手段を一切使わない」

---

まとめ: 安全なプロンプトの書き方3原則

原則1: 範囲を明示する 「全部」「全て」「すべて」は危険ワード。読む範囲・変更する範囲・削除する対象を具体的に指定する。

原則2: 確認ステップを残す 「実行して」の前に「確認して」「提案して」「一覧を見せて」を挟む。特に本番に影響する操作は。

原則3: 秘密情報はプロンプトに書かない APIキー・パスワード・接続文字列は .env に置き、プロンプトには変数名だけ書く。

危険ワード	安全な代替
「全部読んで」	「〇〇ディレクトリだけ読んで」
「自動でリトライして」	「最大3回リトライして、失敗したら停止して」
「本番DBに接続して」	「開発DBで確認して、本番は私が実行する」
「全部削除してクリーンに」	「〇〇だけ削除して、一覧を先に見せて」
「一気に実行して」	「手順を先に確認させて、承認後に進めて」

Claude Code は指示に忠実なだけで、悪意はありません。危険なのは曖昧な指示を出す側です。具体的で範囲が明確な指示を書く習慣が、事故を防ぐ最短の道です。

関連記事

• Claude Code で起きた本番障害7事例と完全復旧手順
• Claude Code セキュリティ対策完全ガイド
• Claude Code の権限設定完全ガイド

参考資料

• Claude Code 公式セキュリティガイド
• OWASP LLM Application Security