AIコーディングエージェントの事故に学ぶ権限設計 ― アクセス範囲がそのまま被害範囲になる

AIコーディングエージェントが引き起こす事故で被害が広がる背景には、与えたアクセス範囲がそのまま被害の最大範囲になるという構造があると私たちは考えています。「不要なファイルを整理して」のような曖昧な指示は、エージェント側の解釈次第で具体的な削除コマンドに変換されてしまうことがあります。この構造への備えは、単一の設定に頼るのではなく、①エージェント側の権限設定 ②OS・ファイルシステム側の制限 ③バックアップ、という三層で組む必要があります。DXやAI活用を検討している担当者にとって、権限設計はエージェント導入の後回しにできる項目ではなく、最初に決めるべき土台です。

全データ消失を招いた「整理して」の一言 ― Cursorでの実例

2026年7月、AIコーディングツール「Cursor」のエージェント機能を使っていた開発者(Zenn、iwaken71氏)が、「不要なブランチを整理して」と依頼したところ、Dドライブ全体が削除されたという体験談を公開しました。削除はOSのごみ箱を経由しない完全削除で、進行中の開発プロジェクト(一部はGitHubから復旧できたもの)、GitHubにpushしていなかったローカルの変更(復旧不能)、Dドライブにインストールされていた各種アプリケーション、対象リポジトリとは無関係な他の作業フォルダまでが失われました。

チャット履歴・ターミナル履歴も同時に失われたため、著者自身、事後にどのコマンドが実行されたのかを特定できていません。著者はこの点を明言した上で、未確定の推測として2つの仮説を挙げています。一つは、git clean -fdx のような一括削除コマンドがリポジトリのルートではなくドライブのルートに対して実行された可能性。もう一つは、削除コマンドに渡すパスの解決が誤り、対象パスが空またはドライブルートになってしまった可能性です。

ここで大事なのは、この事故を「Cursorというツールの欠陥」と断定しないことです。著者自身が原因を特定できていないと明記している以上、私たちもそこは確定情報ではなく推測として扱います。一方で、この体験から著者が導き出した教訓そのものは、特定製品の話にとどまらず、AIコーディングエージェント全般に当てはまる構造だと私たちは考えています。

曖昧な指示が破壊的コマンドに化ける仕組み

今回の事故を手掛かりに整理すると、「整理して」という指示には、何をどこまで消してよいかという範囲の定義がありません。AIエージェントは自然言語の指示を実行可能なコマンドへ翻訳する過程で、この曖昧さを独自に補って具体化することがあります。その結果として、git clean のような後戻りできない削除コマンドが選ばれる可能性が生まれます。

見落としてはいけないのは、git clean がファイルを整理するコマンドではなく削除するコマンドだということ、そしてコマンドラインからの削除はOSのごみ箱を経由しないという点です。GUI操作の感覚で「間違えてもごみ箱から戻せる」と思っていると、その前提自体が崩れます。

私たちが権限設計を考える上で軸に置いているのは、著者自身が導き出したこの一点です。エージェントに与えたアクセス範囲は、そのまま事故が起こったときの被害の最大範囲になります。Dドライブ全体への書き込み権限を持つエージェントは、Dドライブ全体を失わせる力を持つということです。裏を返せば、権限設計とは「エージェントに何をさせるか」を決める作業ではなく、「エージェントに何を失わせ得るか」を先に決めておく作業だと私たちは捉えています。

権限設計は三層で組む ― エージェント設定・OS制限・バックアップ

曖昧な指示による事故を単一の設定でゼロにすることはできません。実務で機能するのは、エージェント側の設定・OSやファイルシステム側の制限・バックアップという三層を組み合わせる考え方です。

エージェント側の権限設定

Cursorの公式ドキュメントによると、ターミナルコマンドの実行はデフォルトで人間の承認が必要です。承認なしで自動実行させたい場合は「Run Modes」の設定が必要で、シンプルな許可リスト(allowlist)から自動レビュー分類器まで選べます。ファイルの読み取り・検索は承認不要ですが、.cursorignore を使えば特定のファイル・ディレクトリへのエージェントのアクセスを事前にブロックできます。ワークスペース内ファイルの変更も承認不要ですが、設定ファイルの変更には明示的な承認が必要です。デフォルトのネットワークリクエストもGitHub・直接リンク取得・Web検索プロバイダのみに限定されています。

より細かい制御は権限設定ファイルで行います。同じくCursorの公式ドキュメントによれば、~/.cursor/cli-config.json(グローバル)または <project>/.cursor/cli.json(プロジェクト単位)の permissions.allow / permissions.deny で許可・拒否のルールを書けます。拒否ルールは許可ルールより常に優先されるため、「基本は許可、危険な操作だけ個別に拒否する」という設計がしやすくなっています。なお --force フラグを付けると承認プロンプト自体をスキップできますが、その分のリスクは利用者側が引き受けることになります。

これらはCursorが一般的に備えている安全機能の説明であり、冒頭の事故の原因を公式に説明したものではありません。ただ、承認フローの既定値・除外設定・allow/denyの優先順位を把握しておくことは、製品を問わずAIコーディングエージェントを導入する際に確認すべき共通の項目です。

OS・ファイルシステム側の制限

エージェント側の設定はツールの実装に依存するため、それだけに頼るのはリスクです。もう一段下のレイヤーとして、OSやファイルシステム側でエージェントの実行アカウントに与えるアクセス権限そのものを絞り込む発想が要ります。プロジェクトのルート以外への書き込み権限を持たせない、業務データやアプリケーションが置かれたドライブとは別の作業領域にリポジトリを置く、といった構成にしておけば、仮にエージェント側の設定をすり抜ける操作が実行されても、被害の範囲はその作業領域の中にとどまります。

バックアップ

三層目はバックアップです。ここでも冒頭の事故が示唆に富みます。今回失われたデータのうち、GitHubにpush済みのプロジェクトは復旧できた一方、pushしていなかったローカルの変更は復旧できませんでした。こまめなpushは、エージェントの誤操作に対する最低限の保険として機能します。ただし、これはリポジトリの中身しか守りません。ドライブ上のアプリケーションや無関係な作業フォルダまでは守れないため、エージェントの操作範囲そのものから独立した場所に置く外部バックアップと組み合わせる必要があります。

まとめ: 三層防御が権限設計の出発点

AIコーディングエージェントの事故は、特定の製品の欠陥として片付けられるものではなく、「与えたアクセス範囲がそのまま被害範囲になる」という共通の構造から生まれる、というのが今回の事例から私たちが得た見立てです。曖昧な指示が具体的な破壊的コマンドに化けるリスクを踏まえると、権限設計はエージェント側の承認フロー・allow/deny設定、OS・ファイルシステム側でのアクセス範囲の限定、独立したバックアップという三層を最初から組み合わせておくことが実務の出発点になります。DXやAI活用の検討でエージェント導入を進めるなら、まず着手すべきは、エージェント側の allow/deny 設定と .cursorignore のようなアクセス除外設定を確認すること、プロジェクトの作業領域を無関係なドライブ・アプリと分けておくこと、そしてエージェントの操作範囲から独立したバックアップ(こまめな push を含む)を用意しておくことの3点です。これらは機能を使い始めた後ではなく、使い始める前に済ませておくべき作業です。

---

出典

• 「Cursorに『不要なブランチを整理して』と頼んだら、Dドライブが消えた話」(iwaken71氏、Zenn、2026-07-13): https://zenn.dev/iwaken71/articles/cursor-agent-d-drive-deleted
• Cursor公式ドキュメント「Agent Security」: https://cursor.com/docs/agent/security
• Cursor公式ドキュメント「CLI Permissions Reference」: https://cursor.com/docs/cli/reference/permissions

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)