Claude Code に「全部やって」は禁句：暴走を防ぐ安全な指示の書き方

「このあたり、よしなに直しといて」

そう投げた数十秒後、Claude Code は git push まで済ませて「完了しました」と返してきました。直したのは1ファイル。でも、ついでに「不要そうな」テストファイルが3つ消えていて、しかもそれが本番ブランチに乗っていた。気づいたのは、CI が真っ赤になってからです。

背筋が冷えました。

誤解しないでほしいのは、Claude Code が暴れたわけじゃない、ということです。僕が「どこまでやっていいか」を書かなかった。それだけ。ファイルを編集して、シェルを叩いて、git を操作できる道具に、ゴールも境界もない一文を渡せば、道具は素直に最短距離を走ります。事故の原因はモデルじゃなくて、指示書のほうにあったんです。

この記事は、危険なプロンプトを怖がらせるためのものじゃありません。「全部やって」を、事故らない依頼文に書き換えるための話です。2026年6月7日時点の公式ドキュメントを確認しながら、指示の書き方・dry-run・権限・フックの4段構えで、機械的に止める設計までいきます。

この記事の要点

• 事故の正体は「悪い命令」ではなく、範囲・権限・完了条件が空白の依頼文。穴を埋めれば9割は防げる。
• 危険な言い方には、ほぼ1対1で安全な置き換えがある。下の対訳表をそのまま使える。
• 削除・本番反映・課金など戻せない操作は、まず一覧/SQL生成だけ（dry-run）→人間が承認の二段にする。
• 言葉のお願いは破れる。settings.json の deny ルールとフックで機械的に止めるのが本丸。評価順は deny → ask → allow で、deny が常に勝つ。

危険なプロンプトって、何が危険なのか

ここでいう「危険」は、ハッキングみたいな悪意の話じゃありません。もっと地味で、もっと日常的なやつです。範囲・権限・完了条件の3つが空欄のまま、強い操作を任せる依頼。これが危険の正体です。

たとえるなら、新人さんに「倉庫、片付けといて」とだけ言って外出するようなもの。本人は真面目だから、よかれと思って「古そうな箱」を全部捨てる。その中に来期の在庫が入っていても、止める理由が指示書のどこにもない。能力じゃなくて、指示の解像度の問題なんですね。

Claude Code は、プロジェクトのファイルを読み、検索し、編集し、テストや git コマンドを実行できます。公式も、ローカルではユーザーがターミナルでできることを Claude Code も扱える、と明記しています。つまり権限とは、初心者向けに言えば「AI がファイルを書き換えたりコマンドを走らせたりする前に、人間に確認を取る境界線」のことです。この線を引かずに強い道具を渡すと、AI は確認なしで走り切ってしまう。

だから依頼文には、「何をしてよいか」と同じ熱量で、**「何をしてはいけないか」**を書く必要があります。

危険な言い方 → 安全な置き換え（対訳表）

まずは即効性のあるところから。よくある危険な一言と、僕が実際に使っている置き換えを並べます。左をそのまま打たない、右をコピーして使う。これだけで体感がかなり変わります。

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

ポイントは、右側がどれも「範囲を狭める」「戻せない操作を保留する」「根拠を分ける」のどれかになっている点です。難しい言い回しはいりません。空欄を埋めるだけ。

公式で確認した権限の境界

ここからは「言葉のお願い」より一段固い話です。Claude Code の permission mode（権限モード）は、チャットで「安全にやってね」と書いても切り替わりません。CLI なら Shift+Tab で循環、起動時は --permission-mode、恒久設定は settings.json の defaultMode。これが正しい切り替え方です。

2026年6月7日時点の公式の主なモードはこうです。

モード	確認なしで動く範囲	向いている場面
default	読み取りだけ	最初の一歩、慎重にやりたい作業
plan	読み取りだけ（編集しない）	変更前の調査・計画
acceptEdits	読み取り＋ファイル編集＋mkdir等	自分でレビューしながら反復
auto	ほぼ全部（裏で安全チェック）	プロンプト疲れを減らしたい長作業
dontAsk	事前許可した道具だけ	ロックダウンしたCI・スクリプト
bypassPermissions	全部（確認を飛ばす）	隔離コンテナ/VM 専用

最初は default か plan で十分です。bypassPermissions は、ネットから切り離したコンテナやVM以外では使わない。これは僕の意見じゃなくて公式の前提です。各モードの意味と段階的な使い分けは、権限設定リファレンスに早見表でまとめています。

そして許可ルール。/permissions で Allow・Ask・Deny を管理できて、評価順は deny → ask → allow、最初に一致したルールが勝つ。だから deny が常に最優先です。チームなら git push --force、.env 読み取り、本番デプロイ系を deny に寄せておくと、依頼文の出来に関係なく事故が減ります。

機械的に止める：コピペで使える 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(rm -rf *)"
    ]
  }
}

コツは、便利な操作を全部 allow にしないこと。Bash(*) のような広すぎる許可は、確認フローをただの飾りにします。毎回安全に走らせたい npm run test や git diff だけを allow に置く。これでスピードとレビューの釣り合いが取れます。

ひとつ正直に書いておくと、Bash(git push --force *) のような「引数で縛る deny」は万能じゃありません。公式も警告しているとおり、URL=... && curl $URL のように変数や別表記で書かれると、パターンをすり抜けることがあります。だから「最後の砦」はパターンじゃなくて、次のフックとサンドボックスです。

言葉が破れても止める：フックとサンドボックス

deny ルールの上に、もう一枚かぶせます。

ひとつ目は PreToolUse フック。Claude Code がツールを呼ぶ直前に、自分で書いたシェルを挟める仕組みです。終了コード 2 で返すと、その操作は権限ルールを評価する前に止まる。「Bash は基本 allow にしておいて、特定の危険コマンドだけフックで弾く」という運用もできます。下は本番ブランチへの直 push を機械的に止める最小例です。

#!/usr/bin/env bash
# PreToolUse フック：main/master への直接 push を問答無用で止める
# 標準入力に来る JSON から、実行されようとしているコマンドを読む
command=$(jq -r '.tool_input.command // empty')

case "$command" in
  *"git push"*main* | *"git push"*master*)
    # 終了コード 2 = この操作をブロック。理由は stderr に書くと AI に伝わる
    echo "main/master への直接 push は禁止。PR を作ってください。" >&2
    exit 2
    ;;
esac

# それ以外は素通り（通常の権限ルールへ）
exit 0

ふたつ目は サンドボックス。これは OS レベルで、Bash コマンドのファイルアクセスとネットワークを縛る仕組みです。権限ルールが「AI に試させない」線だとすれば、サンドボックスは「仮に AI が試しても、OS が拒否する」線。プロンプトインジェクション（外部の文章に紛れた指示で AI を誘導する攻撃）でルールをすり抜けられても、ここで止まります。

順番で覚えると楽です。依頼文で狭める → deny で機械的に弾く → フックで例外を潰す → サンドボックスで OS が最後に止める。穴の埋め方を、この4段で重ねていく。厳しめから始めて、検証できた操作だけ少しずつ allow に格上げする手順は、権限の“はしご”で5段に分けて書きました。

戻せない操作は二段にする：dry-run の型

削除・本番反映・課金・migration。この手の「戻せない操作」は、いきなり実行させないのが鉄則です。まず計画や一覧、SQL を生成するだけ（dry-run）→ 人間が中身を見て承認 → 本番。この二段を依頼文で強制します。

たとえばバグ修正なら、こう書きます。

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

削除を含むリファクタリングなら、「削除候補は一覧を出すだけ。承認なしに削除しない」を必ず入れる。migrations/** や package-lock.json、生成物は、見た目だけで不要かどうか判断できないファイルです。だから成果物の指定より、「触らない範囲」の指定のほうが効きます。

デプロイ前の確認も同じ発想です。--no-verify は lint だけでなく secret scan や pre-commit hook まで飛ばすことがあるので、禁止リストに必ず入れる。実行してよいのは git status、git diff、npm run test、npm run build まで。テストか build が落ちたらそこで停止、合否は「可能 / 要修正 / 判断保留」で報告させる。最終操作は人間が明示的に押す。

僕がやらかした落とし穴3つ

偉そうに書いていますが、全部やらかしてから学びました。

ひとつ目は、「成功するまで再試行して」。外部APIの一時障害でこれをやると、リトライが課金とレート制限を雪だるま式に悪化させます。今は必ず最大回数・待ち時間・失敗時の停止条件をセットで書きます。

ふたつ目は、プロンプトに秘密の実値を直書きしたこと。トークンをそのまま貼ったら、会話履歴・ログ・サブエージェントへの引き継ぎに残りました。今は QIITA_TOKEN のような変数名だけを書き、値は環境変数か secret manager に置く。さらに .env は deny ルールで読み取り自体を塞いでいます。

みっつ目は、「テストはあとでいい」。短期的には速いんです。でも、あとで壊れた箇所を探す時間のほうが圧倒的に長い。テストが重い日でも、npm run lint や node --check、対象ファイルだけの単体テストなど、軽い確認を1つは挟む。結果的にこれが一番速い、というのが今の結論です。

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

最後に、依頼文の末尾にそのまま貼れる安全確認リストを置いておきます。これを貼るだけで、危険な一気通貫はかなり防げます。

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

自分の運用テンプレートまで整えたいなら、教材一覧にプロンプト集とチェックリストをまとめてあります。CLAUDE.md・権限設定・レビュー運用を実リポジトリ前提で設計したいときは、研修・導入相談からどうぞ。

よくある質問

Q. 結局、最初に守る指示は何ですか？ A. 3つだけで十分です。「触る範囲を2〜5ファイルに絞る」「push と deploy は人間が最後に判断する」「まず Plan mode で調査させる」。これを入れるだけで、出力はレビューしやすくなります。

Q. プロンプトで「push しないで」と書けば push は止まりますか？ A. 止まるとは限りません。言葉のお願いはモデルの判断次第で破れます。確実に止めたいなら、settings.json の deny ルールか PreToolUse フックを使ってください。ルールはモデルではなく Claude Code 本体が機械的に守ります。

Q. allow / ask / deny がぶつかったらどうなりますか？ A. 評価順は deny → ask → allow で、最初に一致したルールが勝ちます。deny が常に最優先なので、どこか1つのスコープで deny すれば、別のスコープの allow では上書きできません。

Q. dry-run って具体的に何をさせること？ A. 戻せない操作の「予告編」だけ作らせることです。削除なら対象一覧、DB変更なら SQL の生成、デプロイなら差分とロールバック手順。中身を人間が見て、問題なければ次のメッセージで実行を許可します。

Q. bypassPermissions は普段使っていい？ A. やめたほうがいいです。公式も、ネットから切り離した隔離コンテナやVM専用と位置づけています。プロンプトインジェクション対策がまったく効かないので、日常開発で使うモードではありません。

実際に試した結果

冒頭の「よしなに直して」事故のあと、僕は「AIを信じるかどうか」で悩むのをやめました。代わりに見るのは、どの段で止まったかです。

依頼文に「触らない範囲」と「push禁止」を足したら、横断的な暴走が消えました。.env を deny に入れたら、秘密の露出が原理的に起きなくなりました。本番ブランチへの直 push をフックで弾いてからは、夜中にCIが真っ赤になる回数がゼロに近づきました。

賢いAIを探すより、転んでもケガしない足場を先に作る。危険なプロンプトを避ける目的は、AIを縛ることじゃありません。任せる範囲をはっきりさせて、安心して速く進めるためです。遠回りに見えて、これが一番速い。

関連記事

• Claude Code 権限設定リファレンス
• Claude Code 権限の“はしご”：安全に allow を広げる5段
• Claude Codeで起きた本番障害7事例と完全復旧手順
• Claude Code承認フローとサンドボックス設計

公式リンク

• Claude Code: Choose a permission mode
• Claude Code: Configure permissions
• Claude Code settings
• Claude Code hooks