CursorのAuto-reviewとは?承認を減らしながら安全にエージェントを動かす仕組み
X-tech推進本部 川端Cursor 3.6では、新しい実行モード「Auto-review」が追加されました。
コーディングエージェントにシェルコマンドを実行させる場合、安全性を重視して操作のたびに承認を求めると、何度も確認ダイアログに対応しなければなりません。一方、すべての操作を自動承認すると、意図しないファイル変更や外部システムへのアクセスといったリスクが高まります。
Auto-reviewは、この「安全性」と「エージェントの自律性」のバランスを取るために追加されたモードです。
本記事では、Auto-reviewの判断フローと設定方法、サンドボックス環境を利用する時に判明した実務上の注意点を紹介します。
Auto-reviewの仕組み
大まかな流れは次のとおりです。
- Allowlistに一致する操作は、そのまま実行する
- サンドボックスで実行可能な操作は、制限された環境内で実行する
- それ以外の操作は、内蔵されているClassifierという分類器が内容を確認する
Classifierは、実行しようとしている操作だけでなく、ユーザーから依頼された内容や現在の文脈も参照します。そのうえで、操作を許可するか、別の安全な方法を試すようエージェントへ返すか、ユーザーに承認を求めるかを判断する、という部分が特徴的になっています。
Classifierの判断は設定で調整できる
Auto-reviewのClassifierには、permissions.jsonを使って追加の指示を自然言語で与えられます。
{
"autoRun": {
"allow_instructions": [
"プロジェクト内を対象とした読み取り専用の操作は許可する"
],
"block_instructions": [
"ファイルを削除する操作では必ずユーザーの確認を求める",
"プロジェクト外のファイルを変更する操作は許可しない"
]
}
}
allow_instructionsには許可寄りに判断してほしい操作を、block_instructionsにはレビューのために保留してほしい操作を自然言語で記述します。
ただし、ClassifierはLLMによる判断であり、厳密なセキュリティ境界ではないことに注意が必要です。重要な操作を確実に制限したい場合は、Allowlistを設定するなど、Classifierへの指示だけに依存するのは避けたほうがよいかもしれません。
サンドボックスとビルドキャッシュ
サンドボックスは、エージェントがアクセスできるファイルやネットワークが制限された実行環境です。意図しない変更の影響を抑えられる一方、通常のシェル環境とは挙動が異なることがあります。
その一例がビルドキャッシュです。
サンドボックスから通常のキャッシュディレクトリへアクセスできないと、npm、Cargo、pipなどが毎回依存関係やビルド成果物を作り直し、処理が遅くなる可能性があります。
Cursorの~/.cursor/sandbox.jsonでは、共有ビルドキャッシュを有効にできます。
{
"enableSharedBuildCache": true
}
Windows環境でuvとPlaywrightを組み合わせたスクリプトをエージェントに実行させる場合は、次のような設定が考えられます。
{
"enableSharedBuildCache": true,
"additionalReadwritePaths": [
"~/AppData/Local/uv",
"~/AppData/Local/ms-playwright"
]
}
additionalReadwritePathsへ追加したディレクトリはサンドボックス内から読み書きできるようになります。便利な設定ですが、アクセス可能な範囲が広がるため、sandbox.json のリファレンスに従って必要なディレクトリだけを指定した方がよいでしょう。
Windowsにおけるサンドボックスの動向
Cursorのサンドボックス実装解説によると、Windowsに既存のサンドボックス機構はあるものの、シェル、Git、Python、パッケージマネージャーなどを幅広く利用するコーディングエージェント向けの制御を、ネイティブ機能だけで実現するのは難しいとのことです。
サンドボックスを利用してエージェントの自律実行範囲を制御する取り組みは、Cursor以外のコーディングエージェントにも広がっています。OpenAIもCodex向けに独自のWindowsサンドボックスを構築したことを先日発表しており、その詳細はOpenAIによるWindowsサンドボックスの解説で紹介されています。
さらにMicrosoft自身も2026年6月、AIエージェント向けの実行基盤「Microsoft Execution Containers(MXC)」を早期プレビューとして発表しました。MXCは、エージェントがアクセスできるファイルやネットワークなどをポリシーで定義し、WindowsまたはWSL上でその制約を適用する仕組みです。
こうした動きから、サンドボックスによって安全な実行範囲を設ける考え方は、今後のコーディングエージェントに共通するトレンドになっていくのかもしれません。
まとめ
今回のAuto-reviewは、単なる便利機能ではなく、安全性と自律性のバランスを取るための試みとして興味深いものでした。今後も各社から同様の仕組みが登場すると考えられます。
一方で、私たちもその仕組みを利用するだけでなく、どのような前提で安全性が担保されているのかを理解していきたいと思います。