Cursor Agentの使い方｜Cloud Agentの設定・料金・実力【2026年10月】

Cursor Agentは、AIエディタCursorに載っている自律コーディング機能です。指示を出すと、コードベースの検索・ファイル編集・ターミナルコマンドの実行までをエージェントが自分で進めます。起動はサイドパネル（Cmd+I）から。既定がAgentで、計画を先に作らせたいときだけShift+TabでPlan Modeに切り替えます。無料のFreeプランでもAgentとChatを制限付きで試せます。2026年10月14日時点の公式料金ページでは、Cloud agentsとautomationsはPremium（月30ドル）以上に含まれます。

• できること：ファイル検索・読み込み・編集、シェルコマンド実行、Web検索、ブラウザ操作、画像生成までエージェントが自分で回す。公式は「1つのタスク中のツール呼び出し回数に上限はない」と明記
• 基本の使い分け：まずAgentに投げ、複数ファイルにまたがる変更のときだけPlan Mode（Shift+Tab）で計画を挟む
• 本格活用の鍵：.cursor/rulesのプロジェクトルール（.mdc拡張子が必須）と、Cloud Agentの環境設定

「Cursorを入れてはみたけど、Agentモードって結局どこまで任せていいんだろう」——タブ補完だけ使っている段階から先に進もうとすると、たいていここで止まります。

そして2026年9月現在、この記事を最初に書いた7月から公式ドキュメントの構成がかなり変わっています。「Askモード」のページは無くなりました（/docs/agent/modes は /docs/agent/plan-mode へ転送されます）。カスタマイズの説明ページも404になり、ルールは4種類に整理し直されています。Cloud Agent側には「Builds」という新しい概念が入りました。

そこでこの記事では、2026年9月23日に公式ドキュメントを取り直し、Cloud Agentの設定手順・モードの使い分け・.cursor/rulesの書き方・料金と上限を現行仕様に合わせて書き直しました。公式に書かれていない項目は、推測で埋めずに「記載がない」と書いています。

Cursor Agentとは何か：AgentとPlan Modeの違いから理解する

Cursor Agentを理解する近道は、チャットのモードの違いを押さえることです。ただしここは7月から変わっています。2026年9月23日時点の公式ドキュメントに「Ask モード」のページはありません。左ナビのAgent配下は Overview / Agents Window / Projects / Agent Review / Planning / Prompting / Debugging / Design Mode / Tools / Security で、/docs/agent/modes を開くと /docs/agent/plan-mode へ転送されます。

つまり現行は、Agentが既定で、必要なときにPlan Modeへ回すという2段構えです。加えて、スキルをチャットにピン留めする「Custom Mode」が2026年8月19日のアップデートで入りました。

モード	役割	切り替え	向いている作業
Agent（既定）	コードの生成と実装を自分で進める	Cmd+Iでサイドパネルを開く	機能実装、リファクタ、バグ修正、テスト追加
Plan Mode	コードを書く前に調査して、人がレビューできる実装計画を作る	Shift+Tab、またはモードピッカー	複数ファイルにまたがる変更、要件がはっきりしない機能、設計の判断
Custom Mode	スキルをチャットにピン留めして「常時オンのスキル」にする	/でスキルを選び ⌥⏎（Win/Linuxは Alt+Enter）	決まった手順を毎回なぞらせたいとき

Plan Modeは、Agentがコードベースを調べ、必要なら確認の質問を返したうえで、レビューできる実装計画を作るモードです。公式ドキュメントが挙げる流れは、①確認の質問 ②コードベースの調査 ③実装計画の作成 ④チャットかMarkdownで人が編集 ⑤Buildをクリックして実行の5段。計画は既定でホームディレクトリに保存され、「Save to workspace」を押すとワークスペースへ移せます。チームで共有したりドキュメントとして残したりするならこちらです。

公式が挙げるPlan Modeの出番は、①有効な進め方が複数ある複雑な機能 ②多くのファイルやシステムに触るタスク ③要件がはっきりせず、範囲を掴むために調べる必要があるとき ④先に方針をレビューしたいアーキテクチャの判断、の4つ。逆に「小さな変更や、何度もやったことがある作業はAgentモードに直行して構わない」とも書かれています。

もうひとつ、公式が勧めている使い方があります。出来上がったものが違ったら、追加の指示で直そうとせず計画まで戻るというものです。変更を巻き戻し、計画を具体的に書き直してからもう一度走らせるほうが、動いているエージェントを修正するより速く、結果もきれいになる、と明記されています。

Agentが使えるツール一覧

Agentは、公式ドキュメントによると次のツールを組み合わせてタスクを進めます。しかも「1つのタスク中にAgentが呼べるツールの回数に上限はない」と明記されています。

ツール	内容
ファイル検索	ファイル名検索とキーワード・パターン検索でコードベースを探索
ファイル読み込み	ソースコードの読み込み（画像ファイルにも対応）
ファイル編集	編集内容を提案し、差分として適用
シェルコマンド実行	ターミナルでのコマンド実行（ビルド、テスト、依存関係インストール等）
Web検索	最新のドキュメントや情報をWebから取得
ブラウザ操作	スクリーンショット取得、ページ操作、ビジュアル検証
Fetch Rules	適用対象のルールを読み込む
画像生成	必要な画像をその場で作る
質問	判断に迷ったら人に聞き返す

つまり「コードを書く」だけでなく、「調べて、書いて、実行して、確認する」までの一連のループをエディタ内で完結できるのがCursor Agentの本質です。この点で、単なるコード補完とは根本的に別物と考えたほうがよいでしょう。

また、Agentには自動チェックポイントがあり、重要な変更の前にスナップショットが作られます。気に入らなければチャットのタイムラインからその時点に戻せるので、「勝手に壊されるのが怖い」というハードルはかなり下がります。注意点は2つ。復元はファイルだけを戻し、会話のメッセージは消えません。そしてチェックポイントはローカル保存でGitとは別物なので、恒久的なバージョン管理はGitで行ってください、と公式が明記しています。

作業中のエージェントへの話しかけ方

Agentが動いている最中の操作も、公式ドキュメントに整理されています。ここを知っているかどうかで待ち時間の使い方が変わります。

やりたいこと	操作	挙動
次の指示を積んでおく	Enter	キューに入り、いまのタスクが終わってから順に処理される。ドラッグで並べ替え可
いますぐ割り込む	Cmd+Enter	キューを飛ばして直前のメッセージに追記され、すぐ処理される
止めずに方向を変える	「Send now」または Enter を2回	次のツール呼び出しの境目で届くので、動作を途中で切らずに軌道修正できる
脇道の質問をする	/side または /btw	本線を止めずに別会話を開く。親スレッドを隠れた文脈として使い、あとで@メンションで呼び戻せる
長い目的を持たせる	/goal	完了するまで追い続ける目的を渡す。CLIでは Ctrl+C で一時停止。/loop と組み合わせて定期実行も可
過去の会話を探す	Agents Windowで Cmd+K	会話を横断して検索。開いている会話の中は Cmd+F

/goal は公式が「rolling out」と書いている段階の機能です。見当たらない場合は新しいチャットで試してください。

Cloud Agentの設定手順（公式どおり）

Cloud Agentは、クラウド上の隔離されたVMに「ノートPCと同じような開発環境」を用意してエージェントを走らせる仕組みです。リポジトリがクローンされ、依存が入り、シークレットが渡され、起動コマンドが流れ、ネットワークにも出られる状態でエージェントが動きます。公式ドキュメントは「環境設定がCloud Agentの効果を上げるいちばん重要な手順」とはっきり書いています。

順番に見ていきます。設定名とコマンドは、2026年9月23日時点の公式ドキュメントに載っているものだけを使っています。

手順1：アカウント管理者がソース管理をつなぐ

リポジトリからCloud Agentを起動するには、その前にCursorアカウントの管理者がソース管理を接続しておく必要があります。対応しているのはGitHub（CloudとEnterprise Server）、GitLab（Cloudと自己ホスト）、Bitbucket Cloud、Azure DevOpsです。エージェントはリポジトリをクローンして別ブランチで作業し、最後に変更をpushして受け渡します。自分と依存リポジトリ・サブモジュールへの読み書き権限が要ります。

リポジトリを用意せずに始めたい場合は、リポジトリピッカーで「Start from scratch」を選びます。Cursorが背景で下書きのOriginリポジトリを作り、最初のターンからそこで作業します（有料プランとOriginが必要）。

手順2：環境を作る（エージェント主導かDockerfileか）

Cloud Agentsダッシュボードから新しい環境を作ります。方法は公式に2つ示されています。

• エージェント主導のセットアップ（公式推奨）：ダッシュボードかデスクトップアプリのAgents Windowからガイド付きセットアップを開始します。GitHub・GitLab・Azure DevOps・Bitbucketのアカウントをつなぎ、リポジトリを1つ以上選び、依存のインストールと実行に必要な環境変数とシークレットを渡すと、エージェントが自分で依存を入れ、環境を検証し、最初のBuildまで作ります。公式は「10分もかからない」と書いています
• Dockerfileでの手動設定（上級者向け）：システムレベルの依存、特定のコンパイラバージョン、ベースOSの変更が必要なときに使います。.cursor/environment.json でDockerfileを指定します。プロジェクト全体を COPY してはいけません（ワークスペースの管理と正しいコミットのチェックアウトはCursor側がやります）

どちらの方法でも、インストールスクリプトを指定できます。

# 注意: 実際に投入する前に、テスト用のリポジトリで一度Buildを通してください。
# .cursor/environment.json の例（公式ドキュメント記載の形）

{
  "build": {
    "dockerfile": "Dockerfile",
    "context": ".."
  },
  "install": "pnpm install && ./custom_script.sh"
}

環境の解決順も決まっています。①リポジトリの .cursor/environment.json ②個人の保存済み環境 ③チームの保存済み環境、の順で最初に一致したものが使われます。チーム標準を置きつつ、個人が上書きして新しい設定を試せる、という設計です。

フロントエンド・バックエンド・インフラ・共有ライブラリが別リポジトリに分かれているなら、環境を作るときに複数のリポジトリを選ぶ「マルチリポ環境」にできます。エージェントはワークスペース全体を見て、横断的に変更し、触ったリポジトリそれぞれにプルリクエストを開きます。

手順3：シークレットを渡す

人間の開発者と同じようにコードを動かして試すには、APIキーやデータベースの認証情報が要ります。公式が推奨しているのはcursor.comのSecretsタブで、ここに入れた値は環境変数としてエージェントに渡ります。1つの環境だけに効かせたいなら「環境スコープのシークレット」も使えます。

ログインが必要なアプリなら、ローカルで使っているのと同じユーザー名・メール・パスワードをシークレットとして追加します。TOTPベースの2要素認証を使っている場合は、共有シークレット（root secret）も入れておけば、エージェントが oathtool --totp -b "$TOTP_SECRET" でその時点の6桁を作れます。AWSは、長期のアクセスキーを渡す代わりにIAMロールをassumeさせる構成に対応しています。

モノレポで .env.local が複数ある場合は、すべての値を同じSecretsタブに入れ、キーがぶつかるところは NEXTJS_* CONVEX_* のように名前を分けて各アプリから参照する、というのが公式の案内です。

手順4：Buildを作る

2026年9月時点で押さえておきたいのがBuildsです。Buildは「準備済みのCloud Agent環境を、そのまま起動できるスナップショットにしたもの」で、エージェントの実行前に背景で作られます。

Buildのライフサイクルは公式に5段で書かれています。①トリガー（定期・設定変更・手動・エージェントからの要求）②準備（ベースイメージから起動し、環境内の全リポジトリを既定ブランチでクローンし、installコマンドを最後まで実行）③スナップショット（ディスク状態を、環境のバージョンと各リポジトリの正確なコミットSHAとともに保存）④アクティブ化（成功したBuildがアクティブになる）⑤エージェントの起動（新しいエージェント・自動化・コードレビューがアクティブなBuildから始まる）。

ここで効いてくるのが、失敗したBuildはアクティブなBuildを置き換えないという仕様です。依存の更新やDockerfileの変更でBuildが壊れても、エージェントは直前に成功したBuildから起動し続けます。壊れた原因はBuildsタブのログで追えます。

installスクリプトには制約が1つあります。冪等でなければなりません。Buildのたびに走り、すでに準備済みのディスク状態の上で動くこともあるためです。依存のインストール、コード生成、成果物のコンパイル、ディスクキャッシュの温めなど「先にやっておける作業」はinstallへ。Docker・データベース・トンネル・開発サーバーのような動き続けるプロセスは、installではなく start か terminals に書きます（Buildが保存するのはディスクの状態だけで、動いているプロセスやシェル変数は引き継がれません）。

手順5：タスクを渡す

ここまで整えば、あとはどこからでも起動できます。公式が挙げる起動チャネルは次のとおりです。

起動方法	内容
Cursor Web	cursor.com/agents からブラウザで起動
Cursor Desktop	エージェント入力欄の下のドロップダウンで「Cloud」を選択
Cursor for iOS	ネイティブアプリから起動（AndroidはChromeでcursor.com/agentsを開きInstall AppでPWA化）
Slack	@cursor コマンドで起動
GitHub / Bitbucket	PRやissueに @cursor とコメントして起動
Linear	@cursor コマンドで起動
API	プログラムから直接呼び出し

動いているアプリを確認したいときは、Agents Windowの「Forwarded Ports」メニューを開きます。エージェント環境内のプロセスが待ち受けているポートが「Detected」に出るので、Auto-Forward Portsを有効にするか、ポート番号を自分で入れて転送します。転送したポートで「Open in internal browser」を選べばブラウザでプレビューでき、Design Modeで画面の要素を指しながら指示を出せます。

うまく動かないときに公式が挙げる3点

• シークレット：必要なAPIキーや認証情報がSecretsタブ経由で渡っているか。クラウドのロールには長期キーよりOIDCトークンを使う
• Egress制御：ネットワーク制限をかけているなら、ローカル開発で必要なURLがすべて許可されているか
• ローカルでテストできる状態か：VMから到達できない外部サービスに依存していると、人間が手元でテストしにくいリポジトリはエージェントにとっても同じく難しくなる

公式は「エージェントは賢いが文脈の少ない開発者だと思え」と書いています。テストやデバッグの手順は、スキルと AGENTS.md に書いて渡すのが早道です。Cursorの社内でも、モノレポでよく使うマイクロサービスの動かし方とデバッグのコツを AGENTS.md に並べている、と公式ドキュメントに書かれています。

ローカルのAgentの基本：最初の1タスクを流す

ここからは手元のマシンで動くAgentの話に戻ります。使い始める手順はシンプルです。

Step 1：Agentパネルを開く

Cursorをインストールしてプロジェクトを開いたら、Cmd+I（Windows/LinuxではCtrl+I）でサイドパネルのAgentを開きます。モードピッカーでAgentが選ばれていることを確認してください。既定がAgentなので、そのままで構いません。

Step 2：具体的なタスクを指示する

最初の指示文は、対象・条件・完了条件がわかる形にするのがコツです。次のようなプロンプトから試してみましょう。

Agentへの実装依頼プロンプトの例です。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

src/api/users.ts のユーザー一覧取得APIに、
ページネーション（page, per_page クエリパラメータ）を追加してください。

条件:
- per_page のデフォルトは20、上限は100
- 既存のレスポンス形式は変えず、meta フィールドに total / page / per_page を追加
- 対応するテストを tests/api/users.test.ts に追加
- 最後に既存のテストスイートを実行して、全件パスすることを確認

不足している情報があれば、最初に質問してから作業を開始してください。

ポイントは次の3つです。

• ファイルパスを明示する：探索の初動が速くなり、誤ったファイルへの変更を防げます
• エッジケースと上限値を先に指定する：エージェントの裁量に任せる範囲を狭めるほど精度が上がります
• 「テスト実行まで」を完了条件に含める：Agentはシェルコマンドを実行できるので、検証までワンセットで任せられます

Step 3：差分をレビューして受け入れる

Agentの作業中は、生成される差分をそのまま確認できます。完了後はAgent Reviewで行単位にチェックし、問題なければ受け入れます。納得できない変更はチェックポイントから戻せばやり直せます。公式のベストプラクティスでも「生成中に差分を眺める」「完了後にReviewで行単位に確認する」の二段構えが推奨されています。チームで使っているなら、PRでのBugbotによる自動レビューが三段目になります。

Plan Modeで精度を上げる：大きめのタスクの任せ方

単一ファイルの修正ならAgentに直接指示すれば十分ですが、複数ファイルにまたがる変更ではPlan Modeを経由したほうが手戻りが減ります。Cursor公式ブログ「Best practices for coding with agents」（2026年1月9日公開）でも、経験のある開発者ほど先に計画を立てるとして、Plan Modeファーストの進め方が勧められています。

Plan Modeへの依頼プロンプトの例です。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

認証まわりをセッションベースからJWTベースに移行したい。

まず以下を調査して、実装計画を作成してください:
- 現在の認証フローがどのファイルにまたがっているか
- 影響を受けるミドルウェアとテスト
- 段階的に移行する場合のステップ分割案

計画には各ステップの対象ファイルと検証方法を含めてください。
数字と固有名詞は、根拠(参照したファイルパス)を添えてください。

生成された計画はMarkdownとして開かれるので、実行前に自分の手で編集できます。ここで不要なステップを削り、エージェントが見落とした前提を足しておくのが要点です。公式ドキュメントも「大きな変更ほど、精密で範囲のはっきりした計画を作ることに時間をかけてほしい。難しいのはたいてい『どの変更をすべきか』を決めるところで、指示さえ正しければ実装はAgentに任せられる」と書いています。

.cursor/rulesで「毎回同じ指示」をなくす

Agentを日常的に使い始めると、「テストはVitestで書いて」「コミットメッセージは日本語で」のような同じ指示を毎回書いている自分に気づきます。これを解消するのがルール機能です。

ここも7月から整理し直されています。旧版のこの記事では「Rules と Skills の2系統」と書いていましたが、その説明が載っていた /docs/customize/overview は2026年9月23日時点で404です。現行の公式ドキュメントでは、ルールは4種類に分かれています。

種類	置き場所	効く範囲
Project Rules	.cursor/rules（バージョン管理する）	そのコードベース
User Rules	Cursorの設定	自分のCursor環境すべて
Team Rules	ダッシュボード	チーム全員・全リポジトリ（TeamとEnterpriseプラン）
AGENTS.md	リポジトリ直下	Markdownで書く簡易版。.cursor/rules の代わりに使える

ここで引っかかりやすい落とし穴が1つあります。Project ruleのファイルは .mdc 拡張子でなければなりません。.cursor/rules に置いた素の .md は、description・globs・alwaysApply を書くfrontmatterが無いためルールとして無視されます。素のMarkdownで書きたいなら AGENTS.md を使ってください。

適用のされ方は4通りで、frontmatterの3つのフィールドの組み合わせで決まります。

適用タイプ	frontmatter	効くタイミング
Always Apply	alwaysApply: true	すべてのチャットに毎回入る（globsとdescriptionは無視される）
Apply to Specific Files	alwaysApply: false ＋ globs	一致するファイルが文脈に入ったとき自動で付く
Apply Intelligently	alwaysApply: false ＋ description	Agentがdescriptionを読み、関係しそうなときに自分で引く
Apply Manually	どちらも書かない	チャットで @ルール名 と打ったときだけ

プロジェクトルールのファイル例です。.cursor/rules/ ディレクトリに .mdc で置きます。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# .cursor/rules/project-basics.mdc （拡張子は .mdc・先頭のfrontmatterが必須）

---
alwaysApply: true
---
- パッケージマネージャは pnpm を使う（npm / yarn は使わない）
- テストは `pnpm test` で実行し、変更後は必ず実行する
- エラーハンドリングは握りつぶさず、必ずログ出力かthrowを行う
- 環境変数はハードコードせず .env.example に項目を追記する

ファイルの種類ごとに分けたいときは、globsで絞ります。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# .cursor/rules/frontend/components.mdc

---
globs: src/components/**/*.tsx
alwaysApply: false
---
- named export を使う（default export は使わない）
- スタイルは同じディレクトリの module CSS に置く
- 1コンポーネントは200行まで。超えたら同じディレクトリにサブコンポーネントを切り出す

注意したいのは、公式ガイド自身が「最初はシンプルに始めて、エージェントが同じ間違いを繰り返すことに気づいたときだけルールを足す」と明言している点です。最初から数十行のルールを書き込むより、運用しながら育てるほうが結果的にノイズの少ないルールセットになります。

コンテキスト管理のコツ

公式ベストプラクティスからは、コンテキストの扱いについての指針も読み取れます。

• ファイルは手動でタグ付けしすぎない：エージェント自身に検索ツールでコンテキストを見つけさせるほうがよい
• タスクを切り替えたら新しい会話を始める：長い会話はノイズが蓄積して精度が落ちる
• 過去の作業は@Past Chatsで選択的に参照する：全部を引き継ぐのではなく必要な文脈だけを渡す

Cloud Agentで並列自律コーディング

設定の手順は前半でまとめたので、ここではローカルのAgentと何が違うのかを整理します。公式ドキュメントの説明はシンプルで、「同じエージェントの仕組みを使うが、ローカルのマシンではなくクラウドの隔離VM上で、完全な開発環境とともに動く」。そして「好きなだけ並列で動かせて、ローカルのマシンがインターネットにつながっている必要もない」と書かれています。

自分専用のVMを持っているので、変更したソフトウェアをビルドし、テストし、実際に触れます。デスクトップやブラウザの操作もできます。MCPサーバーにも対応していて、データベースやAPI、サードパーティのサービスへつなげます。MCPはHTTPとstdioの両方のトランスポートに対応し、必要ならOAuthも通ります。run診断用の「Cursor Cloud MCP」が最初から入っていて、トランスクリプト、runイベント、環境の詳細、セットアップログを取れます。

リポジトリの .cursor/hooks.json に書いたコマンド系のフックも動きます（Enterpriseならチーム管理・企業管理のフックも）。ただし ~/.cursor/hooks.json のユーザーレベルのフックは、クラウドVMから手元のホームディレクトリが見えないため動きません。

共有についても決まりがあります。エージェントのページを共有した場合、閲覧は読み取り専用です。チームの管理者が「team follow-ups」を有効にすると、ほかのメンバーも続きの指示を出せるようになります。

リソースは既定のVMプロファイルでメモリとCPUに上限があります。Enterpriseプランでリポジトリがもっと必要とする場合はサポート経由で引き上げられ、公式は「セルフサービスでのカスタム設定は近日中」としています。

起動チャネルは次のとおりです（前半の手順5と同じ内容です）。

起動方法	内容
Cursor Web	cursor.com/agents からブラウザで起動
Cursor Desktop	エディタ内のドロップダウンで「Cloud」を選択
Cursor iOS	ネイティブアプリから起動（AndroidはPWA推奨）
Slack	@cursor メンションで起動
GitHub / Bitbucket	PRやIssue上の @cursor コメントで起動
Linear	@cursor コマンドで起動
API	プログラムから直接呼び出し

ローカルとクラウドの向き不向きは、次のように分かれます。手元で書きながら相談したいならローカル、時間のかかる作業を預けて別のことをしたいならクラウド。2026年9月10日に出た「Cursor Projects」（ベータ）は後者をさらに進めたもので、コーディネーターエージェントが計画を立てて他のエージェントに実装を委譲し、クラウド上の自分の計算機で動くのでノートPCを閉じても止まりません。Slackチャンネルの監視やスケジュール実行を仕込むこともできます。

セキュリティ面では、2026年9月2日に「Self-hosted machines」が入りました。ツールの実行を自社ネットワーク内の機械に閉じられるので、コードもビルド成果物もシークレットも社内に残ります。AWS Lambda、Coder、Cloudflare、Daytona、Modal、Namespace、Vercel、E2Bといった既存の基盤上でも動かせます。

実力を最大化する運用パターン3選

公式ベストプラクティスで勧められているパターンのうち、設定の手間に対して効きやすい3つを紹介します。

パターン1：テスト駆動でAgentを回す

先にテストを書き（またはAgentに書かせてレビューし）、そのテストをパスする実装をAgentに任せる進め方です。Agentはシェルコマンドでテストを実行できるため、「実装→テスト実行→失敗箇所を修正」のループを自律的に回してくれます。完了条件がテストという客観的な形で定義されるので、エージェントの暴走が起きにくく、出力の品質も判定しやすくなります。

パターン2：難しい問題は複数モデルで並列に解かせる

公式ガイドでは、難易度の高い問題に対して複数のモデルを同時に走らせて結果を比較するアプローチが紹介されています。同じプロンプトでもモデルごとに解き方の癖が違うため、1つのモデルの出力に固執するより、並列に走らせて良いほうを採用するほうが早いケースがあります。Cloud Agentの並列実行と組み合わせると、待ち時間もほぼ発生しません。

パターン3：コードベースの学習相手として使う

新しいプロジェクトに入ったとき、同僚に聞くように探索的な質問を投げる使い方も公式が勧めています。「この決済処理のエントリポイントはどこ？」「なぜこのモジュールはこういう設計になっている？」のような質問に、実際のコードを検索したうえで答えてくれます。2026年9月時点では読み取り専用の専用モードが無いので、コードを触らせたくない段階ではPlan Modeで調査させるか、/side で脇道の会話に切り出して聞くのが安全です。どちらにしてもチェックポイントで戻せます。

なお、指示の送信には2種類の操作があり、Enterでキューに積んで待機、Cmd+Enterで即時送信という使い分けができます。2026年8月19日のアップデートで「止めずに方向を変える」steeringも入り、Send nowかEnter2回で、動作を途中で切らずに次のツール呼び出しの境目で指示を届けられるようになりました。細かいですが、並行作業の効率にじわじわ効いてきます。

料金と上限（2026年10月14日時点）

Cursorの料金は、2026年10月14日に公式料金ページで確認した時点で次のとおりです。

プラン	料金	主な内容
Free	0ドル	AgentとChatは利用制限あり
Plus	月8ドル	CursorとGrokの共有枠。Grokモデルのみ
Premium	月30ドル	Cloud agentsとautomations。サードパーティモデルは別課金
Super	月100ドル	Premiumより多い利用枠
Ultra	月200ドル	Superより多い利用枠
Teams	1人あたり月30ドルから	チーム課金と管理、社内向けのルール・スキル・プラグインを置くTeam marketplace、共有文脈つきのCloud agentsとAutomations、Bugbotによるコードレビュー、使用状況の分析、SAML/OIDC SSO
Enterprise	要問い合わせ	プール利用枠、請求書払い、SCIMによる席管理、リポジトリ・モデル・MCPのアクセス制御、自動実行/ブラウザ/ネットワークの制御、監査ログ

利用枠はCursorとGrokの共有枠で数え、週ごとに更新

料金表の数字より大事なのがここです。2026年10月14日時点のCursorは、CursorとGrokで1つの利用枠を共有し、毎週更新されます。残量は使用状況画面で確認できます。

• CursorとGrokの共有枠：プランごとに容量が異なり、毎週更新されます
• サードパーティモデル：2026年10月14日時点のPremium・Super・Ultraでは月額に含まれず、API定価で利用した分だけ別途課金されます。

2026年10月14日時点の公式料金ページでは、PremiumはPlusの4倍、Superは15倍、Ultraは50倍の利用枠と案内されています。

2026年10月14日時点の公式料金ページでは、共有の利用枠を使い切った場合、追加購入するか、週ごとの更新を待つ方法が案内されています。サードパーティモデルは共有枠に含まれず、API定価で別途課金されます。共有枠の追加購入と、サードパーティモデルの従量課金は分けて確認してください。

Cloud Agentの課金

2026年10月14日時点の公式料金ページでは、Cloud agentsとautomationsはPremium・Super・Ultra・Teams・Enterpriseで利用できます。サードパーティモデルの使用料は月額に含まれず、API定価で別途課金されます。Cloud Agentを利用する際も、選択したモデルと使用状況画面で課金条件を確認してください。

まず試すだけならFreeで十分です。2026年10月14日時点の公式料金ページでは、Cloud agentsとautomationsはPremium（月30ドル）以上に含まれます。料金と枠は変更が頻繁なので、契約前に公式料金ページを確認してください。Copilotなど他のツールとの費用の比べ方はAI IDEおすすめ比較6選｜エージェント型の選び方【2026年9月】にまとめています。

2026年8〜9月に変わった点

この記事を最初に書いた7月から、Cursor側の動きがかなり速かったので、公式Changelogから大きいものだけ拾っておきます（2026年9月23日時点）。

日付	変わったこと	使う側への影響
2026年9月10日	Cursor Projects（ベータ・全ユーザーへ順次）	コーディネーターエージェントが計画を立てて実装を他のエージェントへ委譲する。クラウド上の自分の計算機で動くのでノートPCを閉じても止まらない。Slackチャンネルの監視やスケジュール実行も仕込める
2026年9月2日	Self-hosted machines	ツールの実行を自社ネットワーク内に閉じられる。チームプールで容量を伸縮させ、アイドル機は休止して呼び戻せる。LinuxとMacのセルフホストワーカーでcomputer useも可
2026年8月27日	リポジトリなしでCloud Agentを開始できる	「Start from scratch」でOriginの下書きリポジトリが自動で作られる。ポート転送でブラウザからライブプレビュー、Vercel連携で公開まで
2026年8月19日	Subscriptions／Custom modes／サブエージェントを個別VMへ／/goal／steeringの改善	PR・Slackスレッド・スケジュールを監視して自分で起きるようになった（クラウドエージェント限定）。作ったPRには自動で購読が付き、CIの修正やbotコメントへの対応まで進める
2026年8月17日	Origin Code Hosting（早期ベータ・有料プラン）	Cursorがコードをホストする。Originリポジトリ、プルリクエスト、GitHub同期。同期したリポジトリはGitHubが正で、Originが結果をミラーする

ドキュメント側の変更も見ておく価値があります。前述のとおり /docs/agent/modes は /docs/agent/plan-mode へ転送され、/docs/account/pricing は /docs/models-and-pricing へ移り、/docs/customize/overview は404になりました。半年前の解説記事を参照するときは、リンク先が生きているかを先に確かめてください。

【要注意】よくある失敗パターンと回避策

失敗1：最初から巨大なタスクを丸投げする

❌「この管理画面を全部作り直して」
⭕ Plan Modeで計画を作成→レビュー→ステップごとにAgentで実装

なぜこれが重要か：エージェントは自律的に動けるがゆえに、曖昧で巨大な指示だと想定外の方向へ突き進みます。計画のレビューを挟めば、走り出す前に軌道修正できます。

失敗2：調べたいだけなのに、いきなり実装させる

❌「この認証処理どうなってる？」と聞いて、そのまま直させる
⭕ Plan Modeで調査させて計画を出させ、内容を読んでから実行する。脇道の疑問は /side で本線を止めずに聞く

なぜこれが重要か：2026年9月時点の公式ドキュメントに「Askモード」はもうありません。読み取り専用のモードに逃がす代わりに、Plan Modeでコードを書く前に調査と計画を出させるのが現行の型です。チェックポイントがあるので戻せますが、そもそも走らせない判断のほうが速い場面は多くあります。

失敗3：長い会話を引きずったまま別タスクを始める

❌ 1つの会話でバグ修正→機能追加→リファクタと続ける
⭕ タスクが変わったら新しい会話を開始する。脇道の質問は /side で別会話に切り出し、必要になったら@メンションで本線へ引き戻す

なぜこれが重要か：長い会話にはノイズが蓄積し、エージェントの精度が目に見えて落ちます。会話は使い捨て、永続化したい知識は.cursor/rulesへ、が正しい役割分担です。

失敗4：エージェントの変更をレビューせずに受け入れる

❌ テストが通ったからそのままマージ
⭕ 生成中の差分確認、完了後のAgent Review、PRでのBugbot自動レビューを組み合わせる。2026年10月14日時点の公式料金表では、BugbotはPremium・Super・Ultra・Teams・Enterpriseで利用できます。機能の利用対象と、追加料金の条件は分けて確認してください。

なぜこれが重要か：エージェントの出力にはハルシネーションのリスクが常にあります。テストの成否だけでは設計上の問題は検出できません。人間のレビューを省略しない前提で「どこまで任せるか」を設計しましょう。

よくある質問

Q. Cursor Agentの料金はいくらですか？

A. 2026年10月14日時点の公式料金ページでは、Free 0ドル、Plus 月8ドル、Premium 月30ドル、Super 月100ドル、Ultra 月200ドル、Teamsは1人あたり月30ドルから、Enterpriseは要問い合わせです。CursorとGrokの共有枠は週ごとに更新され、サードパーティモデルはAPI定価で別途課金されます。

Q. Cloud Agentと通常のAgentは何が違いますか？

A. 動く場所が違います。通常のAgentは自分のマシンで動き、サイドパネル（Cmd+I）から開きます。Cloud Agentはクラウドの隔離VMで、リポジトリ・依存・シークレット・ネットワークまで揃った開発環境ごと動きます。公式は「好きなだけ並列で動かせて、ローカルのマシンがインターネットにつながっている必要もない」と説明しています。ノートPCを閉じても止まらないので、レビュー待ちの時間に別のタスクを進められるのがいちばんの違いです。

Q. Cloud AgentはGitHub連携が必須ですか？

A. リポジトリから起動する場合は、先にCursorアカウントの管理者がソース管理を接続しておく必要があります。対応はGitHub（CloudとEnterprise Server）、GitLab（Cloudと自己ホスト）、Bitbucket Cloud、Azure DevOpsです。ただし2026年8月27日から「Start from scratch」が使えるようになり、リポジトリも外部のソース管理も無い状態から始められます。この場合はCursorが下書きのOriginリポジトリを作り、気に入ったタイミングで「Create repo」を押して保存します（有料プランとOriginが必要）。

Q. 並列で何本くらい動かせますか？

A. Cloud Agentについては、公式ドキュメントが「好きなだけ並列で動かせる」と書いています。具体的な本数の上限は2026年9月23日時点で明記されていません。ただしリソース面の制限はあり、各Cloud Agentは既定のVMプロファイル（メモリとCPUに上限あり）で動きます。Enterpriseプランで足りない場合はサポート経由で引き上げられ、公式は「セルフサービスでのカスタム設定は近日中」としています。2026年8月19日からはサブエージェントも個別のVMで動かせるようになりました。

Q. AgentモードとGitHub Copilotのエージェント機能はどう違いますか？

A. どちらも自律的にコードを編集・実行しますが、CursorはエディタそのものがAI前提で設計されていて、Plan Mode・チェックポイント・Cloud Agents・Bugbotが1つに統合されている点が違います。GitHub Copilotは既存のエディタに足す形で、対応エディタの広さ（VS Code、Visual Studio、Xcode、JetBrains、Neovim、Eclipse、Raycast、SQL Server Management Studio、Zed）が強みです。モデルの選び方はCopilotのモデル選択｜Opus 5.5・GPT-6 Sol/Luna【2026年9月】、6ツール横断の比較はAI IDEおすすめ比較6選を参照してください。

Q. Claude Codeと比べてどちらがいいですか？

A. 編集画面で書きながら助けてもらいたいならCursor、コードベース全体をまたぐ作業をまとめて預けたいならClaude Codeという分かれ方をします。2026年10月14日時点のCursor Premiumは月30ドルで、Claude Pro月22ドルとは価格帯が異なるため、料金と作業の型の両方で選びます。判断が分かれるポイントはClaude・Codex・Cursorはどのツールを選ぶ？で扱っています。手元のオープンモデルで同じことをしたい場合はLM Studio Bionicとは｜違い・使い方・料金【2026年9月】が近い選択肢です。

Q. エージェントが勝手に危険なコマンドを実行しませんか？

A. Agentのシェルコマンド実行は設定で制御でき、重要な変更の前には自動でチェックポイントが作られるので戻せます。Cloud Agent側はさらに、Secretsタブでの秘密情報の管理、外向きドメインの制限、Tailscale等での私設ネットワーク接続、監査に使えるフックといった制御があります。2026年9月2日に入ったSelf-hosted machinesを使えば、ツールの実行自体を自社ネットワーク内に閉じられます。それでも、本番の認証情報を扱うディレクトリでいきなり動かすのは避け、テスト環境と使い捨てブランチから始めてください。

Q. .cursor/rules に書いたのに効きません

A. 拡張子を確認してください。Project ruleのファイルは .mdc でなければならず、.cursor/rules に置いた素の .md はfrontmatterが無いためルールとして無視されます。素のMarkdownで書きたい場合は AGENTS.md を使います。もう1つよくあるのが、alwaysApply: false でdescriptionもglobsも書いていないケースで、この場合はチャットで @ルール名 と打ったときしか効きません。

まとめ：今日から始める3つのアクション

1. 今日やること：手元のプロジェクトでCmd+IからAgentを起動し、「テストを1本追加して実行まで」の小さなタスクを1つ流す
2. 今週中：複数ファイルにまたがる変更をPlan Mode（Shift+Tab）で1回通し、.cursor/rules/ に .mdc のルールを3〜5行だけ書く。拡張子を間違えると読まれないので、そこだけ確認する
3. 今月中：Cloud Agentの環境を作る。手順はこの記事の前半どおり、ソース管理をつなぐ→リポジトリを選ぶ→Secretsタブに値を入れる→Buildを通す→タスクを渡す、の5つ。初回に支出上限を設定するのを忘れずに。チーム導入ならTeamsプランのBugbot自動レビューまで含めて効果を測る

あわせて読みたい：

• Cursor Composer 2.5徹底解説 — Cursorの内製モデルの特徴と使いどころ
• Cursor RouterとAuto Intelligence｜3モードの違い — どのモデルが自動で選ばれるのかを理解したい方へ
• AI IDEおすすめ比較6選｜エージェント型の選び方【2026年9月】 — 料金・モデル・並列実行を6ツール横断で比較

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）

参考・出典

仕様・料金・変更点は、すべて2026年9月23日に下記の公式ページを開いて確認しました。

• Agent Overview – Cursor Docs — Cursor公式（参照日: 2026-09-23）
• Plan Mode – Cursor Docs — Cursor公式（参照日: 2026-09-23。/docs/agent/modes と /docs/agent/planning はここへ転送されます）
• Agents Window – Cursor Docs — Cursor公式（参照日: 2026-09-23）
• Rules – Cursor Docs — Cursor公式（参照日: 2026-09-23）
• Cloud Agents – Cursor Docs — Cursor公式（参照日: 2026-09-23）
• Cloud Environment Setup – Cursor Docs — Cursor公式（参照日: 2026-09-23）
• Cloud Agent Builds – Cursor Docs — Cursor公式（参照日: 2026-09-23）
• Cloud Agent Best Practices – Cursor Docs — Cursor公式（参照日: 2026-09-23）
• Models & Pricing – Cursor Docs — Cursor公式（参照日: 2026-09-23。/docs/account/pricing はここへ転送されます）
• Pricing – Cursor — Cursor公式（参照日: 2026-09-23）
• Changelog – Cursor — Cursor公式（参照日: 2026-09-23）
• Best practices for coding with agents – Cursor Blog — Cursor公式ブログ、2026-01-09公開（参照日: 2026-09-23）

このテーマの関連記事

• ▸ 【2026年10月】LM Studio Bionicの日本語化｜設定と注意点
• ▸ n8n AI Agent入門｜ノード基本編【2026年10月】
• ▸ LangGraph MCP連携3手順【2026年10月4日】
• ▸ ローカルLLM×RAGの作り方｜オフライン実装【2026年10月】
• ▸ LangGraph Studioの使い方｜可視化・デバッグ【2026年10月】