AIの暴走を防ぐ!Claude Codeで危険なコマンド rm -rf を禁止する安全設定 🛡️
皆さん、先日X(旧Twitter)でこんな投稿が話題になっているのを見かけたことはありますか?
AIコーディングアシスタントが、意図せずホームディレクトリを丸ごと削除するコマンド rm -rf ~/ を実行しようとしてしまう、という内容です。この投稿主もClaude Codeからの滅びのバーストストリームを受け悲惨なことになっていました。明日は我が身なので是非この記事から学びを得てください。
今回は、このようなAIの意図せぬ暴走を防ぐため、AnthropicのClaude Codeに搭載されている強力なパーミッション機能を使って、特定の危険なコマンドをあらかじめ禁止しておく方法をご紹介します。
なぜ rm -rf ~/ は危険なのか
すでにご存知の方も多いと思いますが、このコマンドがなぜ危険なのかを簡単におさらいしておきましょう。
-
rm: ファイルやディレクトリを削除するコマンド(removeの略) -
-r: ディレクトリ(フォルダ)を中身ごと再帰的に削除するオプション -
-f: 確認メッセージなどを表示せず、強制的に実行するオプション -
~/: ユーザーの「ホームディレクトリ」を指す特別なパス
つまり、rm -rf ~/ は**「警告なしで、あなたのPCの個人ファイル(ドキュメント、デスクトップ、写真など)をすべて削除する」**という非常に危険な命令です。
Claude Codeで危険なコマンドを禁止する方法
Claude Codeには、特定のツールやコマンドの実行を許可・拒否するための settings.json という設定ファイルがあります。ここに設定を書き込むことで、AIの動作を安全に制御できます。
settings.json の作成場所
この設定ファイルは、適用したい範囲に応じて2つの場所に置くことができます。
-
プロジェクト固有の設定:
プロジェクトのルートディレクトリに.claudeフォルダを作成し、その中にsettings.jsonを配置します。チームで設定を共有したい場合に便利です。
プロジェクトのルート/.claude/settings.json -
グローバル設定(すべてのプロジェクトに適用):
ホームディレクトリに.claudeフォルダを作成し、その中にsettings.jsonを配置します。個人用のPCで、常にこの設定を有効にしたい場合はこちらがおすすめです。
~/.claude/settings.json
設定内容
どちらかの settings.json を開き、以下の内容を記述してください。
{
"permissions": {
"deny": [
"Bash(rm -rf /)",
"Bash(rm -rf ~)",
"Bash(rm -rf ~/*)",
"Bash(rm -rf /*)"
]
}
}
この設定で何が起きるか
permissions オブジェクトの中の deny 配列は、実行を禁止するルールのリストです。
-
"Bash(rm -rf /)": ルートディレクトリ/を丸ごと削除しようとするコマンドをブロックします。 -
"Bash(rm -rf ~)": ホームディレクトリ~を丸ごと削除しようとするコマンドをブロックします。 -
"Bash(rm -rf ~/*)": ホームディレクトリ直下の全アイテムを削除しようとするコマンドをブロックします。 -
"Bash(rm -rf /*)": ルートディレクトリ直下の全アイテムを削除しようとするコマンドをブロックします。
これにより、AIが誤ってこれらの危険なコマンドを生成しても、実行フェーズでClaude Code自身がブロックしてくれるようになります。
「じゃあ普通のファイル削除もできなくなるの?」
ご安心ください。この設定は、あくまで危険なパターンの rm コマンドだけを禁止するものです。
例えば、AIが作業中に作った一時ファイルを削除する rm temp-file.log のような、単一ファイルを対象とする安全なコマンドは、これまで通り問題なく実行できます。
まとめ
AIコーディングアシスタントは非常に強力なツールですが、その力を安全な範囲で活用するための仕組みも用意されています。今回ご紹介した permissions 設定は、ほんの数行の記述で、予期せぬ事故のリスクを大幅に減らすことができる非常に効果的な方法です。
Claude Codeをお使いの方は、ぜひこの設定を追加して、より安全で快適なコーディングライフをお送りください。
Discussion
rm -Rf /rm -r -f /rm -fr /文字列なんかな? なら
rm -rf /home/meとかrm -rf /usr/local/../..とかでも回避できるんじゃないかな。それだったら、やっぱり dockerとかchrootとかで制限する方が安全なんじゃないかな..