Claude Code誤削除を防ぐ安全運用ガイド｜5層の多層防御スタック総点検
先に結論: Claude Codeの誤削除・事故対策は、permissions・Sandbox・hooks・gitワークフロー・rewindという5層の多層防御で考えます。今日やるべきことは、denyへの破壊的コマンド追加、こまめなgitコミット、hooksかSandboxの導入の3つです。
Claude Codeにコード変更やファイル整理を任せていると、「うっかり大事なファイルを消してしまった」「意図しないコマンドが実行されていた」という事故の報告は珍しくありません。
2026年8月時点でも、海外の開発者コミュニティでは同じ週内に大きな誤削除・誤操作の報告が複数件重なり、大きな反響を呼びました。事故の実例だけを知っても、次に自分が同じ目に遭うかどうかは防げません。
本記事では、Claude Codeにもともと備わっている5つの防御機構を「多層防御スタック」として体系的に整理し、それぞれの最低限の設定と、万一事故が起きたときの復旧手順、避けるべき危険なパターンをまとめます。
基本操作からおさらいしたい方は「Claude Codeの使い方完全ガイド」もあわせてご覧ください。
この記事の要点
- Claude Codeの事故対策はpermissions・Sandbox・hooks・gitワークフロー・rewindの5層による多層防御で考えます。
- Sandboxはネイティブ版のWindowsでは動作せず、WSL2上での実行が必要です。
- 事故発生時はまず
/rewind、次にgit、最後にOS・クラウドのバックアップという優先順位で復旧を試みます。- rewindはbashコマンドによる変更やサブエージェントによる編集を追跡対象外とする制約があります。
- 今日やるべきことは、
denyへの破壊的コマンド追加、こまめなgitコミット、hooksかSandboxの導入の3つです。
前提・動作環境
この記事はターミナル版のClaude Code(2026年8月時点の最新版)を前提にしています。ここで紹介する5つの機構はいずれも追加のプラン契約なしに使えますが、Sandboxはネイティブ版のWindowsでは動作せず、WSL2上での実行が必要です。
各機構の詳しい設定手順は、本文中のリンク先にある個別記事を参照してください。
多層防御の全体像:5層のスタックで事故を防ぐ
Claude Codeの安全機構は、それぞれ役割が異なる独立したレイヤーとして重なっています。
どれか1つを完璧にすれば安全というものではなく、「そもそも実行させない」「実行範囲を制限する」「危険な操作を機械的に止める」「変更を復元できる状態にする」「巻き戻す」という5層で事故の芽を段階的に摘むのが基本的な考え方です。
1層で防ぎきれなかった変更を次の層が受け止める構造になっているため、1つの層だけに依存すると、その層をすり抜けた事故が直接ファイルに及んでしまいます。以下、各層の役割と最低限の設定を順番に見ていきます。
各層の役割と最低限の設定
**権限管理(permissions)**は最初の関門です。ツール呼び出しごとに確認を求める階層型の仕組みで、allow/deny/askの3種類のルールと、default(Manual)・acceptEdits・plan・auto・dontAsk・bypassPermissionsという複数のパーミッションモードを使い分けます。最低限の設定として、rm -rfのような破壊的コマンドをsettings.jsonのdenyに明示しておきましょう。実践としてはrm -rfに加えてgit push --forceや.env系の機密ファイルへの操作もdenyへ登録し、後述するhooksのPreToolUseで機械的なブロックを二重化しておくと安心です。仕組みと設定例は「権限管理の仕組みと設定方法」で詳しく解説しています。
Sandboxは、許可されたコマンドが実際にどのファイル・ネットワーク先へ触れられるかをOSレベルで制限する仕組みです。macOSは追加インストール不要、Linux・WSL2はbubblewrapとsocatが必要です。書き込み範囲を作業ディレクトリに閉じ込めておけば、誤ったコマンドが実行されても被害を局所化できます。有効化の手順は「Sandboxの使い方」を参照してください。
hooksは、CLAUDE.mdへの「お願い」と違い、決められたタイミングで必ず実行されるシェルコマンドです。PreToolUseフックで危険なコマンドのパターンを検知し、exit 2やpermissionDecision: "deny"を返せばツール実行そのものをブロックできます。rm -rfを含むコマンドを機械的に止める最後の砦として機能させられます。書き方は「hooks入門」で解説しています。
gitワークフローは、ここまでの3層をすり抜けた変更が起きても被害を最小限にする命綱です。こまめにコミットを積んでおけば、Claude Codeのファイル編集ツールによる変更はいつでも差分から復元できます。「コミットして」と頼むだけの運用方法は「Claude CodeでGit操作を自動化」で紹介しています。
**rewind(チェックポイント)**は、プロンプトを送るたびに自動でスナップショットが作られる、セッション内の安全網です。/rewindやEscキー二度押しで直前の状態に戻せますが、bashコマンドによる変更(rm・mv・cpなど)やサブエージェントによる編集は追跡対象外という制約があります。使い方は「rewind・チェックポイントで安全に巻き戻す方法」で詳しく解説しています。
事故が起きたときの復旧手順:rewind→git→バックアップの優先順位
実際にファイルが消えてしまった、または想定外の変更が入ってしまったときは、闇雲に手を動かす前に次の優先順位で確認すると復旧の見込みが立てやすくなります。
まず/rewindでその場の巻き戻しを試すのが最速です。ただし対象はClaudeのファイル編集ツールによる変更に限られるため、bashコマンドでrmされたファイルは戻せません。その場合は次にgitの出番です。
git statusやgit diffで現状を確認し、直前のコミットが残っていれば復元できます。ここでも戻せない、そもそもコミットしていなかった場合は、OS標準のゴミ箱やバックアップソフト、クラウドストレージの変更履歴などを確認します。
Claude Code自体にファイル復元機能はないため、この3段構えの外側にある備え、つまり日頃のコミット習慣と定期バックアップが最終的な命綱になります。
危険なパターン集:これをやると事故が起きやすい
--dangerously-skip-permissions(bypassPermissionsモード)を通常の開発マシンで常用する: 公式ドキュメントでもインターネットに接続していない隔離環境専用と明記されています。rm -rf /やrm -rf ~のようなコマンドには確認が入る仕組みがありますが、それ以外の任意のパスへの操作は無防備なままです。- 「このフォルダを整理して」のような曖昧な指示で削除系の操作を丸投げする: 何を消すかの解釈がずれると、意図しないファイルまで巻き込まれます。削除範囲は具体的なパスで指定しましょう。
allowルールにBash(*)のような広すぎる許可を書く: 特定のコマンドだけを許可したつもりでも、ワイルドカードの範囲が想定より広いと歯止めが効きません。- Sandboxのauto-allowモードだけに頼り、gitのコミット習慣を整えない: Sandboxは触れる範囲を制限する仕組みであり、変更そのものを取り消す機能ではありません。
- チームで
.claude/settings.jsonのdenyルールを設定しないまま複数人で共有リポジトリを触る: 個人の権限設定に依存すると、メンバーごとに防御レベルがばらついてしまいます。 - 「バックアップを取って」の指示がそのまま
rm -rfによる全消去に転じる: 海外コミュニティでは、AIエージェントにバックアップ作成を頼んだところ保存先ディレクトリを取り違え、ホームディレクトリやドライブ全体をrm -rfで削除してしまったとする報告が複数見られます(2026年8月時点)。いずれもAnthropicが公式に認めた不具合ではなく、あくまで利用者側からの報告ですが、rm -rf系のパターンをsettings.jsonのdenyへ明示登録しておくこと、そして「バックアップ」をAIの実行任せにせず日頃から別経路(OS標準のバックアップ機能やクラウドストレージ)でも取っておくことが、被害を防ぐ実効性の高い対策です。
画像に埋め込まれた指示にも注意する
ここまでのパターンはいずれもテキストの指示やコマンドが対象でしたが、入力の「形式」によって安全判断の精度が揺らぐ場合がある点にも触れておきます。
海外コミュニティのr/ClaudeCodeでは、スクリーンショットなど画像内に書き込まれた指示によって、本来なら拒否されるはずの操作の判断がすり抜けたとする利用者報告が投稿され、1,000件超の支持を集めました。
これはAnthropicが公式に認めた不具合ではなく、あくまで一利用者からの報告であることは明確にしておく必要がありますが、テキスト以外の入力経路では安全判断の一貫性が下がりうるという注意喚起として参考になります。
対策としては、スクリーンショットや画像に写っているコマンド・指示であっても本文の指示と同じように内容を確認してから実行を承認する、破壊的な操作につながる画像はそのまま鵜呑みにせず自分で読み直す、といった基本を徹底することが有効です。
なお、Claudeが生成した画像にはC2PA規格に基づく来歴メタデータ(電子透かし)が付与されますが、これは「誰が生成したか」を示す仕組みであり、画像内に埋め込まれた指示を検知・遮断する安全機構ではありません(2026年8月時点)。混同しないよう注意してください。用語は「用語辞典」で解説しています。
よくある質問
5つの機構をすべて今すぐ設定しないといけませんか?
必須ではありません。まずはdenyルールでの破壊的コマンドのブロックと、こまめなgitコミットの習慣化から始めるのがおすすめです。効果が高く導入コストの低いものから順に取り入れましょう。
bypassPermissionsは絶対に使ってはいけませんか?
そうではありません。インターネットに接続していないコンテナやVMなど、誤動作しても実害が出ない隔離環境に限定すれば有効な選択肢です。通常の開発マシンで常用しないことが重要です。
rewindだけ覚えておけば十分ですか?
不十分です。rewindはbashコマンドによる変更やサブエージェントの編集を追跡できないため、恒久的な履歴管理としてはgitの併用が欠かせません。rewindはあくまでセッション内の一時的な巻き戻し手段と考えてください。
まとめ
Claude Codeの事故対策は、permissions・Sandbox・hooks・gitワークフロー・rewindという役割の異なる5層を組み合わせた多層防御で考えると整理しやすくなります。今日やるべきことは3つです。
1つ目はsettings.jsonのdenyに破壊的コマンドを追加すること、2つ目はこまめなgitコミットを習慣にすること、3つ目はhooksかSandboxのどちらか1つを導入して機械的なブロックを1層加えることです。
それぞれの詳しい設定は「権限管理の仕組みと設定方法」「Sandboxの使い方」「hooks入門」「Claude CodeでGit操作を自動化」「rewind・チェックポイントで安全に巻き戻す方法」を、Claude Code全体の使い方は「Claude Codeの使い方完全ガイド」もあわせてご覧ください。