AIに長時間の作業を任せるとき、怖いのは派手な暴走だけではありません。変数やコマンド置換を含む削除命令が、安全な処理に見えて素通りする。接続が一瞬切れ、同じツールがもう一度走る。どちらも人が画面を見ていない時間ほど被害が大きくなります。
Claude Code v2.1.281は、この二つをかなり具体的に塞ぎました。今回の記事では新機能を並べず、「無人運転に近いAI作業を、どこまで任せてよいか」という実務判断に絞ります。
今回変わったこと
Anthropicの公式リリースには、削除処理と再実行に関する修正が複数あります。
rm -rf "$(pwd)"のように、削除先がコマンド置換だけで決まる再帰削除は、auto modeや--dangerously-skip-permissionsでも確認を求める- 危険な削除の確認は2分で打ち切り、未回答なら拒否して書き換えを促す
- 作業ディレクトリ由来の変数や、変数の直後にトップレベルのディレクトリ名が続く削除も検知対象を広げた
- プロキシやゲートウェイから重複したストリームイベントが届いたとき、ツールが二重実行される不具合を修正した
- 途中で切れた応答を「正常完了」と誤認するケースや、空の完了応答を再要求するケースも修正した
要点は、AIが削除命令を出した理由ではなく、OSが最終的に受け取る削除先を見る方向へ寄せたことです。文字列が一見安全でも、展開後に現在地や上位ディレクトリを指すなら止める。この考え方は、社内AIへ作業を委譲するときの手綱として使えます。
なぜ「許可済みコマンド」だけでは足りないのか
権限設定でrmを禁止すれば済む、という話ではありません。開発や運用では、ビルド成果物や一時ファイルの掃除が必要です。削除を全面禁止すると、人が毎回介入することになり、AIへ任せる意味が薄れます。
逆に、特定の削除パターンを一律で許可すると、変数展開やコマンド置換が抜け道になります。たとえば「一時フォルダを消す」という意図でも、変数が空だったり、作業場所が想定外だったりすれば削除範囲は変わります。Claude Code v2.1.281の修正は、許可リストを増やすより、破壊的な結果になり得る命令を実行直前で止める設計です。
Anthropicの権限モードの説明でも、Manual、Accept Edits、Plan、Autoでは、確認の入り方が違います。モード名だけで安全性を決めず、ファイル操作、シェル、ネットワークをどの境界で止めるかを見る必要があります。
設定後の確認方法は、Claude Codeの権限境界を4段階でテストする手順で、読み取り、書き込み、外部接続、組織設定の順に整理しています。
中小企業で先に適用したい仕事
今回の更新は、Web制作や社内ツール開発のように、AIがファイルを触る仕事と相性がいいです。特に次の場面では更新を急ぐ価値があります。
- 夜間にテスト、ビルド、デプロイ準備を回している
- 複数のAIエージェントが同じリポジトリや作業フォルダを使う
- プロキシや社内ゲートウェイ経由でClaude Codeを接続している
- キャッシュや生成物を定期的に削除するスクリプトがある
一方、会計データ、顧客原本、契約書など、消失時の復旧コストが高い保存先へ直接書き込ませる判断は別です。v2.1.281へ上げても、バックアップ、書き込み先の分離、人の承認は外せません。
更新後に15分で見る5項目
- 版を固定する。 実行環境で
claude --versionを確認し、v2.1.281以降になっているか記録します。 - 削除先を限定する。 掃除用スクリプトは対象パスを固定し、空変数なら終了する条件を入れます。
- 作業場所を分ける。 本番原本ではなく、Git管理された作業コピーか使い捨てのワークツリーで動かします。
- 中断を再現する。 テスト環境で接続を切り、同じ書き込みや外部処理が二度走らないか確認します。
- 復旧を確認する。 削除や上書きが起きても、バックアップかGitから戻せるところまで実際に試します。
ログに「成功」と出ただけでは検査になりません。作成ファイル、Git差分、外部APIの記録まで見て、処理が一度だけ行われたことを確認します。メール送信や顧客登録を伴う処理では、同じ受付番号を二度処理しない仕組みも処理側に持たせます。AIの再試行を完全になくすより、再試行されても結果が増えない状態を作る方が現実的です。
限定GOとHOLD
限定GO： Git管理された開発環境、復旧可能な生成物、書き込み先を限定した定期処理。v2.1.281以降へ更新し、削除対象と再実行の検査を通した範囲から無人実行を広げます。
HOLD： 本番データを直接消す処理、決済やメール送信のように二重実行の影響が大きい処理、復元テストをしていない共有フォルダ。ここは人の承認か、処理側の冪等性が整うまで自動化しません。
今回の修正は安全装置として有効です。ただし、正しいディレクトリにある不要ファイルだけを消す保証や、外部サービス側の二重登録を防ぐ保証ではありません。AI側のガードと、業務側の復旧設計は別に持つ必要があります。
まず一つ変えるなら
夜間ジョブの削除処理を一つ選び、削除先、承認条件、復元方法を紙1枚に書いてください。そこが曖昧なままなら自動実行はHOLD。三つが説明でき、復元まで試せたら限定GOです。AIに仕事を任せる範囲は、モデルの賢さではなく、失敗後に戻せる範囲で決めます。