Claudeに破壊的操作を確認させるプロンプト設計

Claudeに破壊的操作の確認を求めるプロンプト設計とは

Claudeは自律的にタスクを進めるとき、ファイルの削除やコマンドの実行を自分の判断で行います。公式のプロンプトエンジニアリングガイドは、この判断に「取り消せるかどうか」という基準を足す書き方を示しています。ローカルで元に戻せる操作は自分で進めてよい。元に戻しにくい操作や共有システムに影響する操作は、実行前にユーザーへ確認する。これを指示するプロンプトです。

ガイドは次のように書いています。

Without guidance, Claude Opus 4.6 may take actions that are difficult to reverse or affect shared systems, such as deleting files, force-pushing, or posting to external services. If you want Claude Opus 4.6 to confirm before taking potentially risky actions, add guidance to your prompt.

指示を与えなければ、削除・force-push・外部サービスへの投稿をClaudeが自分の判断だけで実行しうる、という前提です。ガイドの原文はこの項目を「Claude Opus 4.6」を主語に説明していますが、システムプロンプトに指示を足す書き方は、他のモデルでも同じように使えます。CLAUDE.md、Agent SDKのシステムプロンプト、Claude APIへの直接指示のどれにも書き込めます。モデルを切り替えたときは、確認させたい操作が想定どおり確認されるか、実際に指示して試しておくと安全です。

ただし、このプロンプトが効く範囲は、動かしている環境によってかなり違います。Claude Codeにはプロンプトより手前で働く権限の仕組みがあるためです。以降は、プロンプトの書き方、権限の仕組みとの分担、環境別の使い分けの順に進みます。

確認を求める操作は3つの性質で挙げる

公式サンプルは、「危険な操作」と抽象的に書かず、操作を3つの性質に分けて具体名で列挙しています。

抜けやすいのは3分類目です。技術的には取り消せる操作でも、一度でも他者の目に触れれば実質的には取り消せません。送信したメッセージやpush済みのコードは、削除やrevertをしても「一度出た」という事実が残ります。

公式サンプルプロンプトの3段構成

サンプルは英語で書かれており、原則・具体例・抜け道の禁止の順に並びます。

Consider the reversibility and potential impact of your actions. You are encouraged to
take local, reversible actions like editing files or running tests, but for actions that
are hard to reverse, affect shared systems, or could be destructive, ask the user before
proceeding.
 
Examples of actions that warrant confirmation:
- Destructive operations: deleting files or branches, dropping database tables, rm -rf
- Hard to reverse operations: git push --force, git reset --hard, amending published commits
- Operations visible to others: pushing code, commenting on PRs/issues, sending
messages, modifying shared infrastructure
 
When encountering obstacles, do not use destructive actions as a shortcut. For example,
don't bypass safety checks (e.g. --no-verify) or discard unfamiliar files that may be
in-progress work.

自分のプロダクトに使うときは、3分類の具体例を自分のドメインの操作名に置き換えます。ECサイトの運用エージェントなら「注文のキャンセル」「返金処理」「顧客への通知メール送信」、カスタマーサポートのエージェントなら「チケットのクローズ」「返金額の確定」「顧客への一斉配信」といった具合です。

プロンプトは強制力を持たない — 権限の仕組みとの違い

プロンプトの確認は、Claudeの判断に委ねる指示です。システム側の強制力はありません。Claude Codeは、ツールの種類ごとに承認の要否を固定した権限システムを別に持っています。

この表はプロンプトの内容と無関係に適用されます。CLAUDE.mdに何も書かなくても、Bashコマンドとファイル変更は承認を求められます。プロンプトに書き足す意味が出るのは、標準の確認フローが緩んだ場面です。「Yes, and don't ask again」で特定のコマンドを許可済みにした後や、権限モードを切り替えた後がそれに当たります。

手元のclaudeで選べるモードを見る

どのモードで動いているかが、プロンプトの出番を決めます。v2.1.289の claude --help には、権限モードの選択肢が次のように出ます。

claude --help | grep -A4 -e "--permission-mode"

  --permission-mode <mode>              Permission mode to use for the session
                                        (choices: "acceptEdits", "auto",
                                        "bypassPermissions", "manual",
                                        "dontAsk", "plan")

存在しない値を渡すと、同じ選択肢の一覧がエラーとして返ります。

error: option '--permission-mode <mode>' argument 'foo' is invalid. Allowed choices are acceptEdits, auto, bypassPermissions, manual, dontAsk, plan.

manual は、毎回承認を求める既定のモードです。設定ファイルやSDKではこのモードの値が default で、CLIでは manual の別名も受け付けます。manual の名前と別名はv2.1.200以降です。

もう1点、起動時のモードも見ておく必要があります。auto modeはv2.1.283以降、対話型ターミナルとVS Codeのセッションで、プランやプロバイダを問わず初期モードになります。対応モデルを使うセッションでは、承認を毎回求めるモードではなく、分類器が審査するモードで始まることになります。対応していないモデルのセッションは、Manualで始まります。

acceptEditsはrmを承認なしで通す

acceptEdits モードは、ファイル編集に加えて mkdir・touch・rm・rmdir・mv・cp・sed を承認なしで通します。範囲は作業ディレクトリと additionalDirectories の中のパスです。

つまり、作業ディレクトリ内のファイルを rm で消す操作は、acceptEdits では承認の画面が出ないまま実行されます。プロンプトの「ファイル削除は確認する」という一文が、そのまま唯一の歯止めになる場面です。権限モードを切り替えたあとは、プロンプトの確認が効いているかを見直す価値があります。

auto modeの分類器とプロンプトの重なり

auto modeは承認プロンプトの代わりに、分類器モデルが実行前に各アクションを審査します。公式サンプルの具体例が、モードごとにどう扱われるかを並べます。

最後の行は、分類器とは別のチェックが処理します。公式は、重要パスへの rm と rmdir を既定では分類器が審査しないと書いています。allowルールや、許可を返す PreToolUse フックでも承認できません。dontAsk モードでは拒否されます。

「他者に見える操作」はどうでしょうか。PR・issueへのコメントやメッセージ送信のうち、既定ブロックの一覧に載るのは限られた型です。機密の詳細を含む内容や、atlantis apply のような自動化への命令になるコメントが該当します。それ以外の投稿や共有インフラの変更は、環境に応じた判断が分類器に任されます。

auto modeでの確認についても、公式は次のように書いています。auto modeはClaudeが確認質問で止まらず作業を続けるよう促しますが、プロンプトやスキルが確認を明示的に求めているときは、Claudeは質問します。つまり、プロンプトに書いた確認はauto modeでも有効です。分類器の既定リストが覆わない、自分のドメイン特有の破壊的操作を埋める手段になります。

分類器が実際に何を止めるかの構造は、AIエージェントの自動承認と責任の設計で別の角度から扱っています。

Agent SDKで確認を強制する — canUseToolコールバック

Agent SDKで自分のアプリケーションを作る場合、プロンプトより強い手段として canUseTool コールバックがあります。呼ばれる場面は2つです。Claudeがツールの許可を必要とするとき(ファイル削除やコマンド実行など)と、AskUserQuestion ツールで質問を出すときです。コールバックは実行を一時停止し、開発者が返す応答を待ちます。

注意が必要な仕様が1つあります。公式ドキュメントは次のように明記しています。

The callback never fires for auto-approved tools. Any approval earlier in the permission evaluation flow, an allow rule or a mode like acceptEdits or bypassPermissions, resolves the call before canUseTool is consulted.

allowルールや acceptEdits モードで先に許可されたツール呼び出しには、canUseTool が発火しません。プロンプトで「確認して」と書いても、手前の許可設定でそのツールが素通りする設定なら、確認は起こりません。すべてのツール呼び出しに例外なく効かせたいチェックには、公式は PreToolUse フックを案内しています。フックは権限プロンプトより先に走り、呼び出しを拒否することも、プロンプトを強制することもできます。

ただし、フックの許可が最終決定になるわけではありません。denyルールにあたる呼び出しはブロックされ、askルールにあたる呼び出しは、フックが許可を返してもプロンプトが出ます。「確認が必ず走る」ことを保証したいなら、プロンプトに頼らず、askルールかフックで書くのが確実です。

環境ごとの使い分け

Claude APIでシステムプロンプトだけを渡す構成では、確認はモデルの判断に委ねられます。書かなければ、ガイドが警告するとおり、削除やforce-pushをモデルが自分の判断で実行しうる状態です。ただし実際にツールを実行するのはモデルではなくアプリ側のコードです。モデルが返すのは tool_use のリクエストで、実行するかどうかをコードが決めます。確認を挟む処理をそのコードに入れれば、プロンプトに頼らずに確認を強制できます。

確認疲れを避ける書き方

確認を求める範囲を広げすぎると、ほぼ全部にYesと答えるだけの確認フローになります。注意力を消費するだけで、判断として機能しません。公式サンプルのように具体例を3分類に絞った書き方は、確認対象を絞る見本になります。auto modeが承認プロンプトを分類器に置き換えたのも、同じ問題に向き合う設計と読めます。

まとめ

プロンプトが唯一の確認手段になるのは、承認の仕組みを持たない構成だけです。Claude CodeやAgent SDKでは、まず使っているモードと許可ルールを確かめ、素通りしている操作にプロンプトを足し、必ず止めたい操作にはaskルールかフックを使います。

共有インフラに触れるエージェントなら、判断そのものを不要にする設計も候補になります。取り消せない操作の見極め方やClaude Codeのサンドボックス設計が具体例です。権限をChannels経由で中継する実装は権限確認プロンプトをChannelsで中継する実装手順で扱っています。他の自律実行エージェントとの権限設計の違いはClaudeとManusの比較にあります。