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.md、Agent SDKのシステムプロンプト、Claude APIへの直接指示のいずれにも書き込めます。

この技法はどのモデルに効くか

公式ガイドの原文は、この項目を「Claude Opus 4.6」を主語にして説明しています。ただし骨格は「明示的な指示を与えなければ判断基準が無いまま実行する」という一般的な性質です。システムプロンプトに指示を追加する技法自体は、特定モデル専用の機能として説明されているわけではありません。新しいモデルに切り替えたときは、確認を求めてほしい操作の具体例が想定どおり機能しているかを、実際に指示して確かめておくと安全です。

確認を求めるべき「不可逆操作」の具体例

ガイドが挙げる具体例は、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.

第1段落は「ローカルで元に戻せる操作は自分で進めてよい」という許可と、「元に戻せない・共有システムに影響する・破壊的な操作は確認する」という制約をセットで書いています。許可だけを書かず、どこまでは自律的に進めてよいかを明示するのが特徴です。全部を確認対象にすると、後述のとおり確認疲れを招きます。

第3段落は具体例の列挙だけでは防げない抜け道への注意です。--no-verify でのフック回避や、見覚えのないファイルを作業中のものと判断せず削除することを、障害に対する「近道」として使わないよう明記しています。障害物にぶつかったときほど、この種の近道に流れやすいための一文です。

自分のプロダクトに適用するときは、3つの具体例リストを自分のドメインの操作に置き換えます。例えばECサイトの運用エージェントなら「注文のキャンセル」「返金処理」「顧客への通知メール送信」が該当します。カスタマーサポートのエージェントなら「チケットのクローズ」「返金額の確定」「顧客への一斉配信」のように、元に戻すのが難しい操作と他者に見える操作をそれぞれ具体名で挙げるのが公式サンプルの構成に沿った書き方です。

プロンプトの確認は強制力を持たない — Claude Codeの権限システムとの違い

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

この表はプロンプトの内容に関係なく適用されます。Bashコマンドの実行やファイル変更は、CLAUDE.mdに何も書かなくても既定で承認を求めます。プロンプトへの追記が意味を持つのは、ユーザーが標準の確認フローを自分で緩めた場面です。「Yes, and don't ask again」で特定のコマンドを許可済みにした後や、auto modeで分類器に判断を委ねた後がこれに当たります。

auto modeでは、承認プロンプトの代わりに分類器モデルが実行前に各アクションを審査します。分類器は git reset --hard や git clean -fd のようなコマンドを「未コミットの変更を破棄する操作」とみなし、既定でブロックします。rm -rf / や rm -rf ~ のようなクリティカルパスへの削除も同様です。こちらはallowルールや PreToolUse フックが許可を返していても、分類器が拒否します。

つまり公式ガイドがプロンプトに書くよう勧める3分類のうち、force-pushや破壊的な削除の一部は、Claude Code側では既にプロンプトなしで機械的にブロックされています。プロンプトへの追記は、この機械的なブロックが及ばない範囲、つまり分類器が想定していない自社ドメイン特有の破壊的操作を埋めるための手段と位置づけるのが実態に近い理解です。分類器が実際に何を止めるかはAIエージェントの自動承認と責任の設計で構造として整理しています。

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

Agent SDKで自分のアプリケーションを構築する場合、プロンプトより強い強制力を持つ手段が用意されています。canUseTool コールバックです。

このコールバックは2つの場面で呼ばれます。Claudeがツールの許可を必要とするとき(ファイル削除やコマンド実行など)と、AskUserQuestion ツールで確認質問を出すときです。コールバックは実行を一時停止し、開発者が返す応答を待ちます。

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

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 フックの使用を案として挙げています。フックは許可フローの残りより先に実行され、許可・拒否・変更のいずれも返せます。

適用面ごとの違い

同じ「確認させるプロンプト」でも、実行する面によって実効性が変わります。

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

確認疲れを避ける書き方のコツ

確認を求める範囲を広げすぎると、ほぼ全部にYesと答えるだけの確認フローになり、注意力を消費するだけで判断として機能しなくなります。公式サンプルが3つの具体例リストで範囲を限定しているのは、この確認疲れを避けるためです。前述のauto modeが承認プロンプトを分類器に置き換えたのも、確認の回数を減らすための仕組みです。

書き方としては、次の2点を意識します。

• 「リスクがありそうな操作は確認して」のような抽象的な指示ではなく、自分のドメインの具体的な操作名を列挙する
• ローカルで完結し元に戻せる操作(ファイル編集・テスト実行)は自律的に進めてよいと明示し、確認対象と自律対象の境界を両方書く

境界を書かずに「危険な操作は確認して」とだけ書くと、Claudeにとって何が危険かの判断基準があいまいです。具体例のリストは、この判断基準そのものを共有する役割を果たします。

まとめ

破壊的操作の確認を求めるプロンプト設計は、プロンプトだけで制御する構成では確認をモデルの判断に委ねる仕組みです。Claude CodeやAgent SDKで使うときは、既存の権限システムやアプリ側の実行コードが機械的にブロックしない範囲を埋める補助という役割になります。まず自分の実行環境がどの層に当たるかを確認し、権限システムやフックで強制できる部分と、プロンプトの判断に委ねるしかない部分を分けて設計することが出発点です。

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