Cursorのエージェントモードとは｜機能・使い方・法人導入のポイントを解説

「Cursorのエージェントモードは結局どこまで自動でやってくれるのか」「勝手にコードを書き換えられないか」と調べている方も多いのではないでしょうか。Cursorのエージェントモードは、目的を伝えるとAIが複数ファイルを横断して実装まで進める機能で、無料のHobbyプランでも制限付きで使えます。本記事では、Agent・Plan・Debug・Askの4モードの使い分け、自動実行を制御するRun Modes、ルール設定と巻き戻しの仕組みを整理し、AI経営総合研究所が​独自に取材した先行企業の活用実態​もあわせて紹介します。

弊社では、生成AIの運用に役立つ資料を配布しています。導入設計やリスク管理、プロンプトの考え方が分かる内容です。AIを使いこなして望むアウトプットを引き出す、AIが根付く組織体制を整えるノウハウを知れますので、ぜひご覧ください。

Cursorエージェントモードとは？

Cursorのエージェントモードは、目的を伝えるとAIがコードベースを調べ、複数ファイルを横断して生成・修正・実行まで進める機能です。人が1行ずつ指示を出す補完型とは異なり、タスク単位でAIに作業を委ねる点が違いになります。

従来のAIコーディング支援は「人が書き始め、AIが続きを補完する」形が中心でした。エージェントモードではこの関係が逆転します。エンジニアが「ログイン機能を追加して」と目的を伝えると、AIが関連するルーティング・データモデル・UIのファイルを自分で探し出し、必要な変更をまとめて提案します。

Cursorの公式ドキュメントでは、エージェントを次の3つの要素の組み合わせとして説明しています。

• Instructions（ルール）​​：どう振る舞ってほしいかを与える指示とコンテキストです
• Tools（ツール）​​：ファイル検索・読み取り・編集、シェルコマンド実行、Web検索、ブラウザ操作などの実行手段です
• Model（モデル）​​：実際に判断と生成を担うAIモデルです

エージェントが1つのタスクで呼び出せるツールの回数に上限はありません。そのため、調査から修正、動作確認までを1回の指示で連続して進められます。

変更内容は差分として表示され、人が確認してから反映する運用が基本です。さらに、大きな変更の前には自動でスナップショットが作られ、あとから巻き戻せる仕組みも用意されています。自律性と人の統制を両立させる設計になっている点が、エージェントモードの中核です。

Cursorそのものの基本機能や料金体系から知りたい方は、Cursorの基本機能とVSCodeとの違いをまとめた解説もあわせてご覧ください。

Agent・Plan・Debug・Askの4モードと使い分け

現在のCursorには、Agent・Plan・Debug・Askの4つのモードがあります。Shift+Tab でモードを順に切り替えられ、タスクの性質に応じて選び分けることで、手戻りと確認コストを減らせます。

かつて説明されていた「Manualモード」という区分は、現行のUIには存在しません。モードの選択肢は次の4つです。

モード	役割	使うタイミング
Agent	目的を伝えるとファイルを横断して実装まで進めます	仕様が固まっている実装・修正
Plan	確認質問→コードベース調査→レビュー可能な計画の作成、という順で進めます	影響範囲が読めない変更、大きめの機能追加
Debug	仮説を立て、計測コードを入れて再現し、ログを解析して原因を特定します	競合状態、性能劣化、リグレッション
Ask	コードを変更せず、質問への回答だけを返します	既存コードの理解、方針の相談

Planモード｜作る前に計画をレビューする

Planモードは、いきなり実装に入らず、まずAIから確認質問を受け、コードベースを調査させ、レビュー可能な計画を出させるモードです。計画に納得してから編集を許可するため、方針違いの大量修正を未然に防げます。

作成した計画はホームディレクトリに保存され、「Save to workspace」を選ぶとリポジトリ内に置いてチームで共有できます。公式ドキュメントでは、実装が途中で迷走したときは修正を重ねるより、計画からやり直すほうが速いと案内されています。仕様が曖昧なタスクほど、Planモードを起点にする進め方が有効に働きます。

Debugモード｜原因の特定をAIに任せる

Debugモードは、バグの原因究明に特化したモードです。AIが複数の仮説を立て、ログ出力などの計測コードを一時的に挿入し、再現手順を実行してログを解析します。原因を絞り込んだうえで修正し、動作を検証し、挿入した計測コードを片付けるところまで一連で進みます。

再現条件が読みにくい競合状態や、いつの間にか遅くなった処理の調査など、人が当たりを付けにくい問題ほど効果が出ます。

モードを切り替える判断基準

上から順に3つの質問で切り分けると迷いません。

1. 変更する場所が自分で特定できているか → できていれば Agent を選びます
2. できていない場合、どこをどう直すかの方針は決まっているか → 決まっていなければ Plan を選びます
3. そもそも不具合の原因自体が分かっていないか → 分かっていなければ Debug を選びます

コードを変更せずに構造を理解したいだけであれば、Askで十分です。モードを選ばずにすべてAgentで進めると、調査と実装が混ざって差分が肥大化します。

エージェントモードの始め方と設定手順

エージェントモードは ⌘I（WindowsとLinuxでは Ctrl+I）で起動し、Shift+Tab でモードを切り替えます。特別な有効化作業は不要で、プロンプトを入力すればAIが関連ファイルを自動で探索します。

STEP1：エージェントを起動する（所要1分）

Cursorを開き、⌘I（Ctrl+I）を押すとエージェントのパネルが開きます。入力欄の近くにあるモードピッカーから直接モードを選ぶこともできます。Shift+Tab を押すと Agent → Plan → Debug → Ask の順にモードが切り替わります。

STEP2：対象を明示して指示を出す（所要3分）

指示文にファイル名や関数名を含めると、AIが探索する範囲が狭まり精度が上がります。@ メンションで参照先を指定する方法も用意されており、特定のファイル、ブランチ（@Branch）、過去のチャット（@Past Chats）をコンテキストとして渡せます。

エージェントの作業中に次の依頼を思いついた場合は、そのまま入力欄に打ち込むとキューに積まれます。すぐ伝えたいときは ⌘Enter（Ctrl+Enter）で割り込ませます。

STEP3：差分を確認して反映する（所要2分）

AIの提案は差分として表示されます。内容を確認して反映するか、修正を指示するかを決めます。反映後に問題が見つかった場合は、後述するチェックポイントから直前の状態へ戻せます。

よくあるトラブルと対処法

症状	主な原因	対処
コードが変更されない	モードがAskになっています	Shift+Tab でAgentに切り替えます
想定と違うファイルが編集される	対象の指定が曖昧です	ファイル名・関数名を明示するか @ で参照先を渡します
特定のファイルを読んでくれない	.cursorignore で除外しています	除外設定を見直します
会話が長くなり精度が落ちた	コンテキストが膨らんでいます	新しい会話を開始し、必要な情報だけ渡し直します

インストールから初期設定までの手順は、Cursorの導入と初期設定を手順ごとにまとめた記事で詳しく扱っています。

ルール（Rules）でエージェントの挙動を固定する

Cursorのルールは、AIに毎回渡す指示とコンテキストを恒久化する仕組みです。編集できるファイルを制限するアクセス制御機能ではありません。ファイルへのアクセスを制限する場合は .cursorignore を使います。

「Rules for AI で編集可能なファイルを限定する」という説明を見かけることがありますが、これは役割の取り違えです。ルールが担うのは、コーディング規約・命名規則・使用ライブラリ・レビュー観点といった「前提知識の共有」です。

ルールの4種類

種類	置き場所	適用範囲
Project Rules	.cursor/rules/*.mdc	そのリポジトリ
User Rules	Cursorの設定画面	自分のすべてのプロジェクト
Team Rules	管理ダッシュボード（Enterprise）	組織全体
AGENTS.md	リポジトリ直下	そのリポジトリ

Project Rules はファイル拡張子が .mdc である必要があります。.cursor/rules/ の中に .md で置いたファイルは読み込まれません。ルールが効かないときは、まず拡張子を確認します。

4つの適用パターン

.mdc ファイルの先頭（フロントマター）に description globs alwaysApply を書くことで、適用のされ方を切り替えられます。

• Always Apply​：常に読み込ませます。全体の規約や禁止事項を置きます
• Apply Intelligently​：description の内容をAIが読み、関連すると判断したときだけ読み込ませます
• Apply to Specific Files​：globs で対象パターンを指定し、該当ファイルを扱うときだけ読み込ませます
• Apply Manually​：@ルール名 で呼び出したときだけ読み込ませます

全部を Always Apply にすると、毎回のコンテキストが膨らんで精度が落ちます。全体規約だけを常時適用にし、言語別・領域別の細則は globs で切り分ける構成が扱いやすくなります。

何をルールに書くか

チームで運用する場合、次の4点を書き出しておくと出力のばらつきが縮みます。

• 使用してよいライブラリと、使ってはいけないライブラリを明記します
• ディレクトリ構成と、新規ファイルを置く場所を定義します
• テストの書き方と、変更時にテストを更新する義務を明記します
• コミットメッセージとコメントの言語を統一します

書き出す内容の当たりを付けるうえで参考になるのが、Cursorを開発現場で運用している株式会社エブリーの捉え方です。同社は生成AIを「会社固有のルールや業務知識は知らない、とても賢い新人」と位置づけ、これまで言語化されてこなかった暗黙知をルールドキュメントへ落とし込み、3ヶ月単位で更新する運用を回しています。新人に説明が必要な事柄を洗い出すと、ルールに書くべき項目はおおむね出そろいます。詳しくは記事後半の他社の取り組みで紹介します。

外部ツールやデータソースと接続してエージェントの手数を増やしたい場合は、CursorのMCP設定と仕組みの解説もあわせて確認できます。

自動実行の制御｜Run Modesとサンドボックスで暴走を防ぐ

エージェントがシェルコマンドをどこまで確認なしで実行できるかは、Run Modes（Settings > Agents）で決まります。Auto-review・Allowlist・Run Everything の3段階があり、チーム利用ではAllowlistが基準になります。

かつて「YOLOモード」と呼ばれていた全自動の設定は、現在のUIではこのRun Modesに置き換わっています。古い名称で設定を探しても見つかりません。

3つのRun Modes

モード	挙動	適した場面
Auto-review​（第一候補）	許可リストのコマンドは即時実行し、その他のシェルコマンドは可能な範囲でサンドボックス内で実行、残りは分類器が判定します	個人開発で速度と安全のバランスを取る場合
Allowlist	あらかじめ許可した少数のコマンドだけを実行します。挙動が決定的になります	業務コード・チーム開発
Run Everything	確認を求めず、すべてのコマンドを実行します	破棄前提の検証環境のみ

ここで押さえておくべき点があります。Cursorの公式ドキュメントは「​Auto-review はセキュリティ境界ではない​​」と明記しています。判定を担う分類器は誤ることがあるため、危険なコマンドを確実に止める仕組みとしては設計されていません。本番リポジトリや認証情報を扱う環境では、Allowlistで許可対象を絞り込む運用が欠かせません。

この「先に枠を決める」発想は、実際に開発エージェントの適用範囲を広げている企業ほど強く意識しています。株式会社Finatextホールディングスは、AIの暴走を防ぐガードレールを作り込むことを自動化拡大の前提条件に置き、新卒社員をサポートする仕組みと同じ考え方でAIに制御をかけると説明しています（詳細は他社の取り組み）。権限を絞ることは活用範囲を狭める妥協ではなく、任せる範囲を広げるための前工程です。

サンドボックスと保護対象

サンドボックスは sandbox.json で設定します。既定では、ワークスペース内のファイル（.cursorignore の指定を尊重）、.git/config・.git/hooks・.vscode といった保護パス、ネットワークアクセス、/tmp の扱いが制御対象になります。

実行権限そのものの設定は ~/.cursor/permissions.json（個人）と <プロジェクト>/.cursor/permissions.json（プロジェクト）をマージして決まります。チームダッシュボードで設定した内容は、この両者に優先して適用されます。組織として統一したい場合は、個人設定ではなくダッシュボード側で定義します。

.cursorignore の限界を理解する

.cursorignore は .gitignore と同じグロブ構文（* ** ? !）で書きます。正規表現は使えません。エージェント・Tab補完・インライン編集・@ メンションからのアクセスをブロックしますが、​​ターミナル経由とMCPサーバーツール経由の参照はブロックできません​​。

つまり、.cursorignore に書けば機密ファイルが完全に守られる、という理解は誤りです。認証情報は環境変数や秘密管理サービスへ切り出し、リポジトリに置かない構成が前提となります。

法人での権限設計や統制要件を整理したい場合は、Cursorの法人向けプランと管理機能の解説が判断材料になります。

エージェントモードを活かす操作のコツ

エージェントの出力品質は、指示文の具体度でほぼ決まります。「目的・対象・制約・完了条件」の4点を明示すると、探索範囲が絞られ、意図しないファイルへの波及を抑えられます。

Before／After｜同じ依頼を書き換える

同じタスクでも、書き方によってAIの動きは変わります。

Before（修正前）

ログイン機能を追加して

この指示では、AIが認証方式・保存先・既存コードとの関係をすべて推測します。結果として最小限の実装だけを行うか、既存の設計と食い違う構成を作ることがあります。

After（修正後）

目的：src/features/auth 配下に、メールアドレスとパスワードによるログイン機能を追加する
対象：既存の User モデル（src/models/user.ts）を利用する
制約：セッション管理は既存の session ミドルウェアに合わせる。DBスキーマは変更しない
完了条件：ログイン成功・失敗の両方について、src/features/auth/__tests__ にテストを追加し、テストが通ること

なぜ改善されるのか

対象ファイルを明示したことで探索範囲が限定され、「DBスキーマは変更しない」という制約が波及範囲を止めます。完了条件にテストを入れると、AIが自分で検証まで実行し、生成物の妥当性を自ら確認する流れになります。

指示を安定させる3つのルール

• 「直す」「整える」といった抽象的な動詞は避け、変更後の状態を書きます
• 1回の指示に複数の目的を詰め込まず、タスクを分割します
• 触ってほしくない範囲を「〜は変更しない」の形で明示します

テンプレート化してチームで共有する

うまく動いた指示文は、ルールファイルに書き出してチームで再利用します。機能追加・リファクタリング・バグ修正の3種類について、それぞれ4点セット（目的・対象・制約・完了条件）の雛形を用意しておくと、担当者による出力差が縮まります。

エージェントモードのメリットと注意点

エージェントモードの利点は、調査から実装、検証までを一続きで任せられる点にあります。一方で複数ファイルを横断して変更できる以上、制御を設計せずに使うと影響範囲が読めなくなります。

メリット：工程をまたいだ作業を任せられる

補完型のAI支援では、人がファイルを開き、書き始め、次のファイルへ移る、という移動コストが残ります。エージェントモードはこの移動そのものをAIが担うため、リファクタリング、テスト追加、命名の統一といった「面倒だが定型的」な作業をまとめて処理できます。

Cursorが公式ブログで挙げている使い方には、テスト駆動での開発（先にテストを書かせ、それを通すコードを書かせる）、設計図やスクリーンショットの画像を渡してのUI実装、複数モデルを並べて同じタスクを走らせる比較などがあります。

注意点：影響範囲と実行権限の2つを設計する

リスクは大きく2種類に分かれます。

• ​コード変更の影響範囲​​：設定ファイルや依存関係に変更が及ぶと、アプリ全体が動かなくなる場合があります
• ​コマンド実行の権限​​：Run Everythingのまま運用すると、破壊的なコマンドも確認なしで実行されます

この2つは対策が別です。前者はチェックポイントとGitで巻き戻せる状態を保つこと、後者はRun ModesをAllowlistに寄せることで抑えます。どちらか一方だけでは片手落ちになります。

組織で使うときに決めておく4点

• エージェントモードを使ってよいリポジトリの範囲を定義します
• Run Modesの設定をチームダッシュボードで統一します
• AIが変更したコードのレビュー基準を、人が書いたコードと分けて明文化します
• .cursorignore と秘密情報の管理方針をセットで決めます

失敗を巻き戻す・レビューする仕組み

エージェントの変更は、チェックポイントでローカルに巻き戻せます。加えてAgent Reviewが変更内容を自動で点検し、Pull RequestにはBugbotがレビューを付けます。巻き戻しと点検の2層があるため、確認負荷を抑えたまま任せる範囲を広げられます。

チェックポイント｜Gitとは別系統の巻き戻し

Cursorは大きな変更を加える前に自動でスナップショットを取ります。「Restore Checkpoint」を選ぶと、その時点の状態へ戻せます。

注意点として、チェックポイントは​​ローカルに保存され、Gitとは別の仕組み​​です。公式ドキュメントも、恒久的なバージョン管理にはGitを使うよう案内しています。チェックポイントは作業中の試行錯誤を戻すための機能で、コミット履歴の代わりにはなりません。エージェントに任せる前にコミットしておく習慣は、引き続き必要です。

Agent Review｜変更を自動で点検させる

Agent Reviewは、/agent-review スラッシュコマンド、Source Controlタブ、またはエージェントのタスク完了後の自動実行で動きます。レビューの深さはQuickとDeepの2段階を選べます。

レビュー観点は BUGBOT.md に記述して固定できます。「この関数は必ずトランザクション内で呼ぶ」「外部APIの呼び出しには必ずタイムアウトを設定する」といった、チーム固有の落とし穴を書いておくと、人のレビュー前に機械的な指摘が終わります。

Bugbot｜Pull Requestに対するレビュー

Pull Requestに対しては、Bugbotがエージェント型のコードレビューを実行します。Proプラン以上では従量課金で利用でき、Teamsプランではチーム機能として含まれます。

レビュー体制を整えると、AIに任せる範囲を広げても品質の下限が保たれます。人のレビューは設計判断に集中させ、規約違反や定型的な見落としは機械側に寄せる分担が現実的です。

エージェントモードの応用活用法

基本操作に慣れたら、エージェントを並列で走らせる段階へ進めます。Agents Windowとワークツリーを使うと、複数タスクを同時に別環境で進行させられ、待ち時間そのものを削減できます。

並列エージェントとAgents Window

⌘Shift+P からコマンドパレットを開き、「Open Agents Window」を選ぶと専用のウィンドウが開きます。このウィンドウでは、複数のワークスペースを横断したエージェント管理、差分の一覧表示、複数エージェントの並列実行、ローカルとクラウド間での作業の引き継ぎができます。クラウド側でサブエージェントを走らせる運用にも対応します。

ワークツリーで作業を分離する

複数のエージェントを同じ作業ディレクトリで動かすと、互いのファイル変更が衝突します。ワークツリー機能を使うと、エージェントごとに独立したGitチェックアウトが用意され、干渉せずに並行作業を進められます。設定は .cursor/worktrees.json に記述します。この機能はAgents Windowで利用します（IDE側ではWorktree Skillsのコマンドを使います）。

日常の運用に組み込む

エージェントは、後回しになりがちな作業と相性が良い機能です。テストが不足している箇所への追加、古いコメントの更新、ドキュメントと実装の差分の解消などを、まとまった時間を取らずに進められます。

チームで運用する場合は、次の3点を記録に残す進め方が有効に働きます。

• エージェントに任せたタスクの種類と、手戻りが発生した割合を記録します
• 手戻りの原因がルール不足か指示不足かを切り分けます
• 判明した落とし穴を BUGBOT.md とルールファイルへ反映します

運用体制の整え方については、以下の資料でより深く解説していますので。ぜひご覧ください。

CopilotやClaudeとの違いを理解する

現在は主要なAIコーディングツールがいずれもエージェント機能を備えており、「補完型か自律型か」という区分では違いを説明できません。差が出るのは、統合の範囲・権限制御の粒度・並列実行への対応です。

かつては「Copilotは補完型、Cursorは自律型」という整理が使われていました。GitHub Copilotにもエージェントモードが搭載された現在、比較の軸を更新する必要があります。

ツール	主な形態	特徴	検討時の確認点
GitHub Copilot	エディタ拡張＋エージェント	VS Codeをはじめ既存のエディタにそのまま追加でき、GitHubのワークフローと接続しやすい構成です	無料プランを含む複数プラン体系があり、知財免責やデータ保護の適用範囲がプランで異なります
Claude Code	ターミナル常駐型のエージェント	エディタに依存せず、コマンドラインから対話的にファイル編集と実行を進められます	エディタ内の差分表示やインライン編集の体験は、エディタ統合型とは前提が異なります
Cursor エージェントモード​	AI前提で設計されたエディタ	計画・実装・レビュー・巻き戻しがエディタ内で完結し、Run Modesで実行権限を段階的に制御できます	エディタの移行が必要になり、既存の拡張機能や設定の引き継ぎ作業が発生します

選定の判断としては、既存のエディタ環境を変えたくない組織はCopilot、エディタごとAI前提に移行して実行権限まで統制したい組織はCursorが軸になります。

CopilotとCursorのどちらを選ぶかで迷っている場合は、CopilotとCursorの機能と選び方を比較した記事で判断基準を整理できます。

料金プランとエージェント利用上限

エージェントモードは無料のHobbyプランでも「制限付きのエージェントリクエスト」として利用できます。有料プランの主な差は機能の有無ではなく、エージェントの利用上限とアクセスできるモデルの範囲です。

「エージェントモードには有料プランが必須」という説明が流通していますが、公式の料金ページはHobbyプランの内容に「制限付きのエージェントリクエスト」を明記しています。まず無料で挙動を確かめ、上限に到達した段階で有料プランへ移行する順序で進めます。

プラン	月額（USD・税別）	エージェント利用上限	主な内容
Hobby	無料	制限付きのエージェントリクエスト	クレジットカード不要／Composerへのアクセス
Pro	$20	上限を拡張	フロンティアモデルへのアクセス／MCP・スキル・フック／クラウドエージェント／従量課金のBugbot
Pro+	$60	Proの3倍	Proと同じ機能セット
Ultra	$200	Proの20倍	新機能への優先アクセス
Teams	$40／ユーザー	Standard／Premium（PremiumはStandardの5倍）	一元化された請求と管理／チームマーケットプレイス／Bugbotによるコードレビュー／チーム全体のプライバシーモード／SAML・OIDC SSO
Enterprise	カスタム価格	使用量のプール	SCIMによるシート管理／リポジトリ・モデル・MCPのアクセス制御／自動実行・ブラウザー・ネットワークの制御／監査ログ／AIコード追跡API

（出典：Cursor公式料金ページ、2026年7月31日時点。価格はすべて税別です）

すべてのプランに一定量のモデル使用量が含まれ、超過分はオンデマンド利用として後払いで課金されます。個人で日常的にエージェントを使う場合はPro+、組織で権限統制まで求める場合はTeams以上が対象になります。

なお、Cursorのサブスクリプションは cursor.com からの直販のみで、再販業者や第三者経由の販売は認められていません。正規の経路以外からの購入は避けます。

データの扱いとプライバシーモード

プライバシーモードは、無料プランを含むすべてのユーザーが設定画面から有効化できます。有効時はコードデータが学習に使われず、Cursorは全モデルプロバイダーとゼロデータ保持契約を結んでいると公表しています。チームや企業の管理者が組織全体へ適用することも可能です。

ただし、自前のAPIキーを使う場合でもリクエストはCursorのバックエンドを経由します。また、コードベースのインデックス化では平文コードを処理後に破棄する一方、埋め込みとメタデータ（ハッシュ値・ファイル名）が保存される場合があると明記されています。完全なオフライン処理ではない点を前提に、扱うリポジトリの範囲を決める必要があります。

他社の取り組み｜Finatextホールディングスとエブリーに学ぶAI前提の開発体制

エージェントの導入で成果を分けるのは、ツール設定よりも「AIに何を渡し、どこまで任せるか」の設計です。先行企業2社は、ガードレールの整備と社内知識の言語化という異なる角度から、その設計に取り組んでいます。

株式会社Finatextホールディングス｜ガードレールを整えてエージェントの適用範囲を広げる

金融領域でサービスを展開する同社は、セキュリティと信頼性を求められる一方で生産性向上が急務だったことから、生成AIの活用を進めてきました。自社のAIガイドラインを2023年3月の初版以降も継続的に改定し、複数のAIモデルを一画面から選べる社内ツール「Alfred」を開発しています。非エンジニアであるCFOがGitHub Copilotなどを使い、システム間の自動連携を構築した例も生まれています。

同社は「​​今後は開発エージェントをより広範囲に活用し、業務のライフサイクルを自動化していきたいと考えています。そのために重要になるのが、AIの暴走を防ぐためのガードレールをしっかりと作り上げることです。新卒の社員をサポートする仕組みと同じように、AIに対しても適切な制御をかけていきます​​」と語っています。

エージェントの適用範囲を広げるほど、Run Modesや権限設定といった制御の設計が先に必要になる、という順序を示す取り組みです。詳細は株式会社Finatextホールディングスのインタビュー記事で紹介しています。

株式会社エブリー｜暗黙知を言語化してAIの精度を段階的に上げる

同社はCursorとGitHub Copilot、ChatGPTを併用し、AIを前提とした業務設計へ移行を進めています。導入後、個人の生産性は向上した一方でチーム全体の働き方は当初変わらなかったこと、現時点の実感値は生産性2〜3倍で目標は10倍に置いていることを明かしています。暗黙知の言語化とルールドキュメントの更新を重ね、AIの精度を段階的に高めた結果、一部業務ではAIが実装からリリースまで担うケースが出始めました。組織全体の変化は3ヶ月単位の振り返りで俯瞰しています。

同社は「​​生成AIはとてつもなく賢いんですけど、会社固有のルールや業務知識は知らないとても賢い新人だと認識しています​​」と語っています。

この認識は、Cursorのルール機能をどう使うかに直結します。社内固有の規約や設計思想を .cursor/rules や AGENTS.md に書き出す作業が、そのままエージェントの精度向上につながります。詳細は株式会社エブリーのインタビュー記事で紹介しています。

2社に共通する設計思想

• ツールの導入より先に、AIへ渡す前提情報（ガイドライン・ルールドキュメント）を整備しています
• 任せる範囲を一度に広げず、制御の仕組みを作りながら段階的に拡張しています
• 効果を個人の生産性ではなく、チーム全体の変化として一定期間ごとに測定しています

まとめ｜AIを安心して任せるために必要なこと

Cursorのエージェントモードは、コードを自動生成するだけの機能ではありません。4モードで進め方を選び、ルールで前提知識を固定し、Run Modesで実行権限を絞り、チェックポイントとAgent Reviewで巻き戻しと点検を用意する。この4層がそろって初めて、任せる範囲を安全に広げられます。

導入時に押さえる要点は次の4点です。

• モードは Shift+Tab で切り替え、仕様が曖昧なタスクはPlanから始めます
• ルールはアクセス制御ではなく前提知識の供給です。ファイル制限は .cursorignore で行います
• Run Modesの Auto-review はセキュリティ境界ではありません。業務コードではAllowlistを基準にします
• チェックポイントはローカル保存でGitの代替にはなりません。任せる前にコミットしておきます

無料のHobbyプランでも制限付きでエージェントを試せます。まず小さなリポジトリで挙動を確認し、ルールと権限設定を固めてからチームへ展開する順序が現実的です。

そして、ここから先の課題はツール選定ではなくなります。誰がどの範囲まで任せてよいかを組織のルールとして言語化し、AIが書いたコードのレビュー基準を定め、効果をチーム単位で測定する。先行企業2社が時間をかけて取り組んでいるのも、この部分です。

以下の資料では、導入設計や社内体制の整え方などをより詳しく解説しています。AIが根付く組織体制を整えるノウハウを知れますので、ぜひご覧ください。

よくある質問