Claude Codeで危険なプロンプトを避ける: 勝手にpush・テスト省略・全部修正を防ぐ

Claude Codeに「全部直して、勝手にpushして、テストは後で」と頼むと、作業は速く見えます。けれど、ファイル編集、シェル実行、git操作、外部ドキュメント調査までできる道具では、曖昧な一文がそのまま事故の入口になります。

この記事では、危険なプロンプトを怖がらせるためではなく、実務で防ぐために整理します。2026年6月3日時点で公式のClaude Codeドキュメントを確認し、permission mode、/permissions、settings.json、Plan modeを前提に、コピペして使える安全な依頼文へ置き換えます。

flowchart LR
  A["依頼を書く"] --> B["調査だけ許可"]
  B --> C["変更計画をレビュー"]
  C --> D["小さく編集"]
  D --> E["テストとdiff確認"]
  E --> F["人間がpush/deploy判断"]

危険なプロンプトとは

ここでいう危険は、悪意のある命令という意味ではありません。「範囲」「権限」「完了条件」が曖昧なまま、Claude Codeに強い操作を任せる依頼です。初心者向けに言うと、権限とは「AIがファイルを編集したり、コマンドを実行したりする前に、人間へ確認する境界」です。

Claude Codeは、プロジェクトのファイルを読み、検索し、編集し、テストやgitコマンドを実行できます。公式ドキュメントでも、ローカル環境ではユーザーがターミナルで実行できることをClaude Codeも扱えると説明されています。だからこそ、プロンプトは「何をしてよいか」だけでなく「何をしてはいけないか」まで書く必要があります。

特に避けたいのは、次のような依頼です。

危険な言い方	安全な置き換え
全部直して	対象ファイルと対象外ファイルを指定して、まず計画を出して
勝手にpushして	diffとテスト結果を要約して。pushは私が判断する
テストは省略して	最小の確認コマンドを提案し、実行できない場合は理由を書く
本番DBで確認して	dev/stagingだけ使い、本番用SQLは生成だけにする
許可は全部スキップして	Plan modeで調査し、承認後に1ステップずつ進める
古いものを消して	削除候補の一覧を先に出し、承認後に対象だけ削除する
最新版へ全部上げて	major更新を分け、脆弱性対応と通常更新を分ける
調べて実装して	公式リンクを提示し、根拠と変更案を分ける

公式ドキュメントで確認した権限境界

Claude Codeのpermission modeは、チャットで「安全にやって」と書くだけでは切り替わりません。CLIならShift+Tabや--permission-mode、IDEやDesktopならモードセレクタ、永続設定ならsettings.jsonで管理します。

2026年6月3日時点の公式説明では、主なモードは次の通りです。defaultは読み取り以外の操作で確認します。acceptEditsはファイル編集と一般的なファイル操作を自動承認します。planは読み取り中心で調査と計画に使います。autoは安全性チェックを挟む研究プレビューです。dontAskは事前承認されていない操作を拒否します。bypassPermissionsは確認をほぼ飛ばすため、隔離されたコンテナやVM以外では使わない前提です。

/permissionsでは、Allow、Ask、Denyのルールを確認できます。Denyは最優先なので、チームではgit push --force、.env読み取り、本番デプロイ系コマンドをDenyに寄せると事故を減らせます。設定ファイルはユーザー、プロジェクト、ローカル、管理者配布のスコープを持ちます。チームで共有するなら.claude/settings.json、個人だけなら.claude/settings.local.jsonに分けるのが実務的です。

最小のsettings.json

次はそのまま出発点にできる例です。プロジェクトに合わせてテストコマンド名だけ変えてください。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)",
      "Bash(* --no-verify *)"
    ]
  }
}

ポイントは、便利な操作をすべてAllowしないことです。Bash(*)のような広すぎる許可は、確認フローを薄くします。逆に、毎回安全に実行したいnpm run testやgit diffだけをAllowにすると、スピードとレビューのバランスが取りやすくなります。

ユースケース1: バグ修正

危険な依頼は「ログイン周りを全部直して、動いたらpushして」です。これでは対象が広すぎ、pushまで一気通貫になります。

目的: ログイン後にセッションが切れる不具合を直す。
範囲: src/auth/**, src/session/**, tests/auth/** だけを対象にする。
禁止: git push、deploy、本番DB接続、.envの読み取り。
進め方:
1. 関連ファイルを読んで原因候補を3つまで出す。
2. 変更計画を出し、私の承認を待つ。
3. 承認後に最小差分で修正する。
4. npm run test -- auth を実行し、失敗したらログを要約する。
5. 最後に git diff の要点と残リスクを報告する。

この形なら、Claude Codeは調査、編集、検証に集中できます。人間は承認点で止められるため、思い込みの修正や不要な横断変更を減らせます。

ユースケース2: リファクタリング

危険なのは「古い実装をきれいにして、不要なファイルを削除して」です。「古い」「きれい」は人間にも定義が揺れる言葉です。

目的: 決済モジュールの重複したバリデーションを整理する。
変更してよい範囲: src/billing/validators.ts とそのテスト。
変更しない範囲: migrations/**, prisma/**, public/**, package-lock.json。
削除ルール: 削除候補は一覧を出すだけ。承認なしに削除しない。
検証: npm run test -- billing と npm run lint を実行する。
出力: 変更理由、互換性への影響、追加すべきテストを短く報告する。

リファクタリングでは、成果物よりも「触らない範囲」の指定が効きます。特にmigration、lockfile、生成物は、見た目だけで不要と判断しにくいファイルです。

ユースケース3: デプロイ前確認

危険な依頼は「CIが遅いからテストを飛ばして本番へ出して」です。--no-verifyはlintだけでなく、secret scanやpre-commit hookまで飛ばすことがあります。

目的: リリース前の確認を短時間で終える。
実行してよいこと: git status、git diff、npm run test -- --runInBand、npm run build。
実行してはいけないこと: git push、deploy、--no-verify、npm publish。
判断基準:
- テストまたはbuildが失敗したらそこで停止する。
- 失敗ログは最後の80行だけ要約する。
- リリース可能かどうかを「可能 / 要修正 / 判断保留」で報告する。

デプロイは戻せるように見えて、実際には顧客通知、決済、検索インデックス、キャッシュが絡みます。Claude Codeには確認と要約を任せ、最終操作は人間が明示的に行う設計が安全です。

ユースケース4: 調査とドキュメント更新

危険なのは「最新情報を調べて、適当に記事へ反映して」です。外部情報は変わるため、根拠のリンクと反映範囲を分けます。

目的: Claude Codeのpermission modeに関する記述を更新する。
参照元: 公式ドキュメントを優先し、URLを本文末尾に列挙する。
禁止: 公式で確認できない新機能を断定しない。
進め方:
1. 現在の記述と公式ドキュメントの差分を表にする。
2. 修正案だけを出し、本文編集は承認後に行う。
3. 変更後、古いリンクとdescription文字数を確認する。

調査タスクでは、Claude Codeを「執筆者」ではなく「出典確認と差分整理の担当」に寄せると、古い情報や言い切りを減らせます。

具体的な失敗例と落とし穴

1つ目は、外部APIの無制限リトライです。「成功するまで再試行して」は、障害時に課金とレート制限を悪化させます。最大回数、待ち時間、失敗時の停止条件を書いてください。

2つ目は、.envや秘密鍵の扱いです。プロンプトに実値を書くと、会話履歴、ログ、サブエージェントへの引き継ぎに残ります。プロンプトにはQIITA_TOKENのような変数名だけを書き、値は環境変数やsecret managerに置きます。

3つ目は、依存関係の「全部最新化」です。major versionの更新は破壊的変更を含む可能性があります。npm outdatedで一覧化し、security fix、minor update、major updateを分けてレビューします。

4つ目は、削除とmigrationです。「整理して」はmigration履歴の削除に解釈されることがあります。削除対象は一覧化だけにし、DBへ影響するSQLは生成だけで止めるのが安全です。

5つ目は、「全部直して、細かいことは任せる」です。範囲が広すぎると、UI文言、依存関係、設定、テスト、生成物まで同時に変わり、レビューできない差分になります。まず「ログ出力だけ」「バリデーションだけ」「1つの画面だけ」のように単位を切ります。

6つ目は、「テストはあとでいい」です。短期的には速く見えますが、あとで壊れた箇所を探す時間が増えます。テストが重い場合でも、npm run lint、node --check、対象ファイルだけの単体テストなど、軽い確認を1つは入れる方が結果的に早いです。

レビュー前チェックリスト

このチェックリストをプロンプト末尾に貼ると、危険な一気通貫を防ぎやすくなります。

安全確認:
[ ] 対象ファイルと対象外ファイルを書いた
[ ] git push / deploy / publish を禁止または承認制にした
[ ] 本番DB、本番API、課金が発生する操作を禁止した
[ ] .env、秘密鍵、個人情報を読ませない指定をした
[ ] Plan modeまたは計画提示を先に要求した
[ ] テスト、lint、buildのうち最低1つを確認に入れた
[ ] 失敗時は停止してログを要約する条件を書いた
[ ] 最後にdiff、実行コマンド、残リスクを報告させる

ClaudeCodeLabの記事を読みながら自分の運用テンプレートも整えたい場合は、商品一覧にプロンプト集とチェックリストをまとめています。チームでCLAUDE.md、権限設定、レビュー運用、研修まで合わせたい場合は、Claude Code研修・導入相談で実リポジトリを前提に設計できます。

関連記事

• Claude Codeで起きた本番障害7事例と完全復旧手順
• Claude Codeセキュリティ対策完全ガイド
• Claude Codeの権限設定完全ガイド
• Claude Code承認フローとサンドボックス設計

公式リンク

• Claude Code: Choose a permission mode
• Claude Code: Configure permissions
• Claude Code settings
• Claude Code common workflows

実際に試した結果、Masaの運用では「まずPlan modeで調査」「変更範囲を2から5ファイルに絞る」「pushとdeployは人間が最後に判断する」の3つを入れるだけで、Claude Codeの出力は遅くなるどころかレビューしやすくなりました。危険なプロンプトを避ける目的はAIを縛ることではなく、任せる範囲を明確にして、安心して速く進めることです。