見出し画像

「ITニュース」｜Cursor 3.6 — Auto-review は「y 連打」を減らすが、セキュリティ境界ではない

まるしょー｜ITニュース分析配信

はじめに

Cursor は 2026年5月29日、Changelog で Cursor 3.6 と Auto-review Run Mode を公開しました。エージェントが ターミナル（Shell）・MCP・Fetch のツールを呼ぶとき、許可リスト → サンドボックス → LLM 分類器（classifier） の3段で通し、承認ダイアログを減らしつつ実行を続けやすくする、というモードです。

Agent Security ドキュメント では Cursor 3.6 以降、Auto-review が推奨デフォルト と説明されています。一方、Cursor 公式フォーラム（Auto-review Run Mode）では、分類器は 非決定論的で誤りうる ため、Auto-review は便利さのための best-effort であり、セキュリティ境界ではない と明記されています。

読みどころは次の2点です。

  • 3段ゲート — 何が即実行され、何がサンドボックスに入り、何が分類器や人間の承認に回るか

  • 名称の混同 — Auto-review Run Mode（実行承認）と Agent Review（コード diff のレビュー機能）は 別物

※本記事は Cursor の Changelog、ドキュメント、フォーラム、および他社の公開情報をもとにした一般的な整理です。契約、法務、セキュリティ、監査の判断は、最新の公式ドキュメント、自社の契約・設定画面、専門家・担当部門の確認に従ってください。Cursor への取材は行っていません。

この記事での用語


1. 何が起きたのか

先に結論です。

  • 2026年5月29日、Cursor 3.6 として Auto-review Run Mode を Changelog で公開

  • 対象は Shell（ターミナル）・MCP・Fetch のツール呼び出し

  • 各呼び出しは 許可リスト → サンドボックス → LLM 分類器 の順で判定

  • Settings > Cursor Settings > Agents > Run Mode で選択。3.6 以降は Auto-review が推奨デフォルト（Agent Security）

  • `.cursor/permissions.json` の autoRun（`allow_instructions`／`block_instructions`）で分類器を自然言語指示可能

  • 公式は best-effort（最善努力） であり bypass（迂回）も可能。セキュリティ保証ではない（docs・フォーラム）

忙しい方向けに一言でいうと、
Cursor が「エージェントの y 連打」を減らす Run Mode を標準推奨にしたが、厳格な統制が必要なら Allowlist＋手動承認か管理者設定を選べ、と公式自身が線引きしている、というニュースです。

2. 公式情報ベースの要点

2-1. 3段ゲートの流れ

フォーラム告知（Colin, May 29, 2026） では、各ツール呼び出しが次の順で処理される、と説明されています。

  1. 許可リスト（Allowlist） — ターミナルまたは MCP の許可リストに一致すれば 即実行

  2. サンドボックス（Sandbox） — サンドボックス実行可能なら、ネットワーク・ファイルシステム制限付き で実行。macOS、Linux、Windows（WSL2 経由） で利用可能。それ以外のプラットフォームはこの段をスキップし分類器へ

  3. LLM 分類器（Classifier） — 上記に該当しない呼び出しは、現在のリクエスト と カスタム指示 付きで分類器へ。実行許可／別アプローチの試行／通常の承認プロンプト のいずれかを選ぶ

分類器について、フォーラムでは 既存の agent 利用に追加コストはかからない と記載されています。Changelog 本文には課金の記述はありません（執筆時点）。

2-2. Run Mode の4種類

Agent Security では、Run Mode は次の4種類です。

Cursor 3.6 より前 は、旧名称として Run in Sandbox、Ask Every Time、Run Everything が使われていた、と docs に記載があります。

いずれのモードも best-effort で、bypass が可能、と docs は明記しています。

2-3. permissions.json — リポジトリで共有可能なポリシー

permissions.json Reference では、次が整理されています。

ファイルの場所

  • `~/.cursor/permissions.json` — ユーザー全体

  • `<workspace>/.cursor/permissions.json` — リポジトリ単位（コミットしてチーム共有可能）

両方ある場合、各フィールドの配列は 連結（concat） されます。

主なフィールド

autoRun の例（フォーラム掲載）

{
  "autoRun": {
    "allow_instructions": [
      "Allow read-only shell commands that inspect files, directories, git state, logs, process status, or command output without modifying files or external state.",
      "Allow read-only MCP, WebFetch, and WebSearch calls that retrieve or inspect data without creating, updating, deleting, posting, triggering, or deploying anything."
    ],
    "block_instructions": [
      "Block all npx commands, regardless of arguments or apparent intent.",
      "Block commands that create, edit, move, delete, chmod, chown, format, install, generate, or otherwise modify files outside the current project directory."
    ]
  }
}

docs では、`allow_instructions` も `block_instructions` も steering（傾け） であり enforcement（強制）ではない、と説明されています。許可リストに載っていても安全チェックは通り、ブロック指示に該当しても Cursor が承認を求める場合がある、と docs は記載しています。

優先順位 — team admin（dashboard）> permissions.json > IDE 設定 UI。Enterprise で管理者が Run Mode を制御している場合、permissions.json や IDE の許可リストで 追加の許可はできない、と docs にあります。

2-4. Auto-review Run Mode ≠ Agent Review

混同しやすい名称です。

設定画面の Agents セクションに両方が並ぶため、実行ポリシー と コードレビュー を取り違えないことが重要です。

3. 他社の動きと並べて読む — 「承認 UX」の同じ論点

Auto-review 単体では「IDE の設定が1つ増えた」以上の文脈が見えにくくなります。直近の他社発表は、レイヤ（段）が違う ものの、エージェント実行の承認 UX という同じ論点に載ります。

3-1. Anthropic — 承認疲れと Auto Mode

How we contain Claude では、Claude Code の 承認プロンプト疲れ が問題化されています。telemetry ではユーザーが 約93% のプロンプトを承認しており、承認が増えるほど 各ダイアログへの注意が薄れる、と説明されています。

対策として OS レベルのサンドボックス（macOS の Seatbelt、Linux の bubblewrap）を導入し、許可プロンプトを約84%削減 した、と記載があります。さらに Auto Mode では 別の classifier がツール呼び出しを審査する、という流れです。

Trustworthy agents in practice では Plan Mode — 個々の操作ではなく 戦略全体を先に見せて承認 する UX — も言及されています。

Cursor Auto-review は IDE 統合＋permissions.json＋3段ゲート、Claude Code Auto Mode は classifier 中心、という製品差はありますが、「都度承認の限界 → 自動ゲート＋サンドボックス」 という設計思想は近い、と読めます。

3-2. Microsoft — Agent 365 は「デプロイ前」の管理者承認

2026年5月1日 GA の Microsoft Agent 365 は、エージェントの Entra 身份・Purview データ制御・Defender 監視 を統合する 組織ガバナンス の話です。

Learn — Agent requests では、メンバーがエージェントをテナントに公開するとき 管理者がメタデータ・データソース・ツールをレビューしてから publish または reject する、と説明されています。

Agent 365 は デプロイ前・組織登録 の承認、Cursor Auto-review は 開発者 IDE 上の実行時 の承認——段が違う ため置き換え関係ではありません。社内ポリシーでは 両方 を役割分担で書くほうが現実的です。

4. Cursor 製品線の中での位置づけ

直近の Cursor 公式発表は 入口・環境・モデル・自動化・実行ポリシー で進んでいます。Auto-review は IDE 内エージェントの実行承認 を担います。

関連する note 記事

Automations で Cloud Agent が長時間・無人で動く 一方、Auto-review は 手元 IDE でエージェントが shell を叩く ときの摩擦を下げる——クラウド側のポリシー と ローカル Run Mode は別途そろえる必要があります。

5. 誰に関係する話か

6. 混同しやすい点

7. 短期・中期・長期の整理

時間軸は次のとおりです。

  • 短期: 0〜3か月

  • 中期: 3か月〜1年

  • 長期: 1年以上

7-1. 短期（0〜3か月）

予想される動き — 3.6 アップデート ユーザーが Auto-review デフォルトに触れ、長時間 agent セッションが増える。permissions.json の autoRun 例（npx 禁止・read-only 許可等）がテンプレとして流通しやすい。

不確実性 — 分類器の誤許可／誤拒否 の実例がフォーラムに集まるか。Windows ネイティブ（WSL なし）での体感。Enterprise team admin 強制 テナントでの挙動。

効果が出にくい条件 — ユーザーが Allowlist＋手動承認 のまま変更しない。Auto-review と Agent Review を混同し設定ミス。

7-2. 中期（3か月〜1年）

予想される動き — リポ単位 permissions.json がチーム標準に。classifier＋sandbox＋allowlist 三層 が開発者向けエージェントの よくあるパターン になりうる。Enterprise では Agent 365（組織）＋ IDE Run Mode（個人実行） の二層整理。

不確実性 — 決定論的 gateway（コミュニティ製フック等）との併用・置換。規制・監査 が LLM classifier 承認を認めない業界。

効果が出にくい条件 — 重大インシデント 1件で組織が Run Everything 禁止＋手動のみ に回帰。分類器精度 が改善せず 承認疲れが classifier 疲れ にすり替わる。

7-3. 長期（1年以上）

予想される動き — 実行時ポリシーが permissions.json から Entra Conditional Access 等 へスペクトラム拡張。戦略承認（Plan）＋実行時 classifier＋OS sandbox の多層が製品横断の参照モデルになりうる。

不確実性 — クラウドエージェント中心（Cursor Cloud Agents 等）への移行で ローカル shell Run Mode の相対的重要性低下。Zero Trust ベンダー が 決定論的ポリシーゲート を標準装備し LLM classifier は補助に降格。

効果が出にくい条件 — 業界が ローカル shell 実行自体 を縮小し、IDE 内 Run Mode の議論が薄れる。

8. まず確認したいチェックリスト

  1. Run Mode が Auto-review か、意図的に Allowlist かを確認したか

  2. Auto-review Run Mode と Agent Review を混同していないか

  3. 機密リポ で Run Everything を使っていないか

  4. `.cursor/permissions.json` を置く場合、team admin 制御 の有無を確認したか

  5. autoRun を 強制 と誤解していないか（steering のみ）

  6. Windows 環境で WSL2 の有無とサンドボックス段の挙動を把握したか

  7. MCP 接続 は信頼できるサーバーに限定しているか

  8. 破壊的コマンド（`rm -rf`、本番 DB 操作等）を 許可リストに載せていない か

  9. Automations（Cloud Agent） 側のポリシーと IDE Run Mode を 別管理 しているか

  10. 社内文書に 「IDE Auto-review は convenience、本番・データ操作は別ゲート」 と書いたか

9. まとめ

Cursor 3.6 の Auto-review Run Mode は、エージェントの Shell／MCP／Fetch 実行を 許可リスト → サンドボックス → LLM 分類器 の3段で通し、長時間作業の中断を減らす ための公式機能です。permissions.json の autoRun で分類器を自然言語指示できる点は、チームで リポジトリにポリシーをコミット しやすい設計です。

ただし Cursor 自身が best-effort・非決定論・セキュリティ境界ではない と明言しています。厳格な統制 が必要な環境では Allowlist＋手動承認、Enterprise の team admin 設定、そして Agent 365 等の組織レイヤ を組み合わせる、という読み方が公式の意図に沿います。

最初の一歩としては、read-only コマンドだけ許可リストに載せたうえで Auto-review を試し、分類器の誤判断が出たら Allowlist モードに戻す か autoRun の block_instructions を足す——この 往復 を前提に運用するのが現実的です。

主な参照

免責

本記事は公開情報をもとにした一般的な整理です。契約、法務、セキュリティ、監査、本番導入の判断は、Cursor の最新ドキュメント、自社の契約・設定画面、社内規程、専門家・担当部門の確認に従ってください。投資判断の材料ではありません。

【PR】
私も転職エージェントを利用して転職しました。

いいなと思ったら応援しよう！