Cowork削除承認はなぜどのモードでも外せないのか

Coworkの承認モードには「Manual」「Auto」「Skip」の3種類があり、モードによって確認の頻度は大きく変わります。ただしファイルの完全削除だけは別枠です。どのモードを選んでいても、Claudeがファイルを完全に削除する直前には必ず「Allow」を選ぶ確認画面が挟まります。Skip(すべての承認を省略するモード)であっても、この一点だけは省略されません。公式の安全ガイドは「Cowork requires your explicit permission before permanently deleting any files」と明記しており、モード設定で回避できる項目ではないと位置づけています。

この確認画面自体はCowork自動承認モードとはやCowork Approval Gatesを部門ごとに設計する考え方でも触れられている既知の挙動です。ここではその先の2点を掘り下げます。この保護が正確には何を対象にしているのか、そしてなぜ数ある取り消しにくい操作の中で削除だけがモード非依存の例外になっているのかです。

Cowork削除承認が対象にしているのは「ファイル」だけ

公式ドキュメントの文言を注意深く読むと、この保護は「ファイルの完全削除(permanently deleting any files)」に対象が限定されています。Coworkが扱う書き込み系の操作は、メール送信・カレンダー招待の作成・コマンド実行など幅広くありますが、削除保護の記述はそのすべてを指してはいません。

ここで見落としやすいのが、コネクタ経由の削除操作との関係です。Coworkは、Salesforceの取引先レコードのように、コネクタが削除系ツールを提供している場合は外部サービス側のデータも削除できます。こうした削除は、Claude自身のファイルシステム機能とは別のMCPツール呼び出しとして実行されるため、通常の書き込み系ツールと同じ扱いになります。つまりモード・コネクタ側の権限設定(常に許可・要承認・ブロック)・組織設定という3層の掛け合わせで挙動が決まり、ファイル削除のような「モードに関わらず常に確認」という特別扱いを受けるとは公式には明記されていません。

削除の種類によって承認の決まり方が変わります。

「削除なら常に安全」と思い込むと、コネクタ経由の削除操作をAlways allow(常に許可)に設定したまま気づかないうちに実行させてしまう事故につながります。ファイル削除の確認画面が出ることと、業務データの削除が安全に扱われていることは、別々に確認する必要がある2つの事柄です。コネクタ側の権限設定(常に許可・要承認・ブロックの3段階)の内訳はClaude CoworkのConnectors一覧にまとめています。

承認モードは他の書き込み操作をどう分岐させているか

削除保護がどれだけ特殊かは、他の書き込み系操作の挙動と比べると見えてきます。Manualはすべての書き込み操作に毎回確認を求め、Autoはデータ持ち出しやプロンプトインジェクションの兆候をClaudeが実行前にチェックしたうえで進め、危険と判定したものだけ止めます。Skipはコネクタ側でBlockedに指定されているもの以外、確認なしで実行します。

つまりメール送信・カレンダー変更・スプレッドシートの更新といった操作は、選んだモードとコネクタ側の権限設定次第で、確認が挟まったり挟まらなかったりします。ファイルの完全削除だけが、この分岐のロジックから外れた場所にあります。Autoの安全性チェックが「危険ではない」と判定しても、Skipで確認を一切省く設定にしていても、削除の直前だけは必ずダイアログが出ます。モードという可変のレイヤーの外側に、削除専用の固定レイヤーがもう1枚あるとイメージすると挙動が理解しやすくなります。

Team/Enterpriseの組織設定でも解除できない

Team・Enterpriseプランには、書き込み系ツールの「常に許可」をメンバー個人の判断だけで有効化できるかを管理者が決める組織設定があります。この設定は既定でオフで、オンにすると個人の「常に許可」設定がそのまま反映されるようになります。しかしファイルの完全削除は、この組織設定の対象からも外れています。管理者が組織全体で「常に許可」をオンにしていても、削除の直前だけは個々のメンバーに確認画面が出続けます。

生産性を優先して確認を減らしたい管理者にとっては、この一点だけは調整の対象外だと理解しておく必要があります。削除の確認を減らす公式な設定経路は存在しないため、頻繁に削除確認が発生して業務が滞るようであれば、削除を伴わない設計にタスクの手順自体を見直すほうが現実的な対処になります。

なぜ削除だけがモード非依存の例外なのか

公式の安全ガイドは、Manualへの切り替えを勧める場面として「Mistakes would be hard to undo, like sending messages or making purchases(元に戻すのが難しい失敗を招く操作、メッセージの送信や購入など)」を挙げています。ここで興味深いのは、メッセージ送信や購入も「元に戻しにくい」という同じ性質を持ちながら、モード選択というユーザー自身の判断に委ねられている点です。削除だけが、ユーザーの判断を待たずに固定の確認を挟む設計になっています。

この違いは、取り消しにくさの中身が同じではないことに理由があります。誤って送ってしまったメッセージは、訂正の連絡を入れる、相手に説明するといった事後の対処が一応は可能です。誤って確定してしまった購入も、返金や取り消しの交渉という経路が残っています。一方で完全に削除されたファイルには、そもそも事後の対処という選択肢自体がありません。バックアップが別の場所になければ、その時点でデータは戻ってきません。取り消しにくい操作の中でも、削除は「事後の打つ手が原理的に存在しない」という一段階違う位置にあると見るのが妥当です。ファイル削除だけをモード非依存の固定レイヤーに置いたのは、この非対称性を踏まえた設計です。

Cowork削除承認とClaude Codeの分類器判定は何が違うか

同じAnthropicの製品でも、Claude Codeのauto modeにおける削除の扱いはCoworkと発想が異なります。Claude Codeの分類器は、rm -rf /のようなクリティカルパスへの削除は許可ルールがあっても一律で拒否しますが、それ以外の削除は「セッション開始前から存在したファイルを不可逆に破棄していないか」「クラウドストレージへの大量削除ではないか」といった文脈を都度判断して通すか止めるかを決めます。セッション中にClaude自身が作ったファイルの削除であれば、通常はそのまま実行されます。分類器の判定基準の全体像はClaude Codeのauto mode分類器は何を止めているかにまとめています。

つまりClaude Codeは「対象と状況を見て判断する」削除の扱い、Coworkは「対象を見ずに一律で確認する」削除の扱いです。この違いは製品の使われ方の差を映しています。Claude Codeは1つのセッションで数十から数百のファイル操作を繰り返す開発作業が前提のため、削除のたびに毎回確認を挟むと作業が成立しません。文脈を判断できる分類器を挟むことで、リスクの高い削除だけを止める設計になっています。対してCoworkは、日常業務のファイルを扱う場面が中心で、削除されるファイル1つ1つの価値が利用者ごとに大きく違います。分類器による細かい判定よりも、削除という行為そのものを一律に人間の目へ差し戻すほうが、誤って失う被害を避けやすいという判断です。

削除保護があっても油断できない場面

削除の確認画面が必ず出るという事実は、ファイルが安全に保たれることを保証するものではありません。確認画面が出た時点で内容を読まずに「Allow」を押してしまえば、保護は機能しません。プロンプトインジェクションによって、無関係なファイルの削除を承認するよう仕向けられるケースも理屈のうえでは起こり得ます。確認画面は「立ち止まる機会」を強制するものであって、「立ち止まって中身を確認する」ところまでは代行してくれません。

Scheduled Tasksで定期実行しているタスクに削除を伴う手順が含まれている場合は、この確認画面がむしろ運用の妨げになることもあります。人が見ていない時間帯に確認待ちで止まったまま実行が完了しない、という状態です。定型業務を自動化するときに削除系の操作をどこまで組み込むかの判断は、Cowork Scheduled Tasksで定型レポートを自動化する実践パターンで扱っている頻度・承認モードの組み合わせ方が参考になります。

まとめ

Coworkの削除保護は、ファイルの完全削除に限って、Manual・Auto・Skipのどのモードでも必ず確認を挟む固定のレイヤーです。コネクタ経由のレコード削除はこの対象に含まれず、通常の書き込み系ツールと同じくモード・コネクタ権限・組織設定の掛け合わせで挙動が決まります。メッセージ送信や購入のような他の取り消しにくい操作がユーザーの判断(モード選択)に委ねられているのに対し、削除だけが判断の外側に固定されているのは、事後の打つ手が原理的に存在しないという削除特有の非対称性を踏まえた設計です。Claude Codeの分類器が対象と文脈を見て判断するのと対照的に、Coworkは対象を問わず一律に人間の目へ差し戻す方式を選んでいます。この確認画面を過信せず、内容を確認したうえで許可する習慣そのものが、削除保護を実際に機能させる条件になります。