Cursor Cloud Agentsを使ってみて - 実運用でつまずいた4つのこと

個人開発でCursorを日常的に使っています。最近はローカルのエージェントだけでなく、Cursor Cloud Agentsも本格的に試し始めました。

「ブランチを切って、実装して、PRまで」という流れをクラウド側に任せられるのは大きいです。一方で、実際に回してみると、ドキュメントだけでは見えにくいハマりどころがいくつか出てきました。

この記事では、実運用でつまずいた4つのことを一本にまとめ、それぞれ何が起きて、次にどうするかを整理します。

なお、この記事でいう「ルール」は、Cursorプロジェクト内の .cursor/rules（エージェント向けの指示ファイル）のことです。

前提: Cloud Agentsで何をやろうとしていたか

やりたかったことはシンプルです。

1. main から作業用ブランチを切る
2. そこに実装を進める
3. 必要ならUIの確認まで任せる
4. モデルはできるだけ意図した設定のまま使う

ローカルで自分でやる流れを、クラウド側に寄せるイメージです。便利さはすぐに感じた一方で、「設定したつもり」と「実際に動いた結果」がズレる場面が続きました。

① ブランチがネストして、Git Graphが汚れた

最初のつまずきはブランチ運用でした。

main から新しいブランチを切って実装させるつもりだったのに、エージェントはそのブランチからさらに別ブランチを切って実装を進めました。結果として、マージにマージを重ねる形になり、Git Graphがかなり汚くなりました。

原因を追うと、.cursor/rules 自体は用意していました。問題は、「参照する（Apply / Agent Requested など）」設定になっていなかったことです。ファイルとして書いてあるだけでは読まれません。Cloud Agentsが実際にその .cursor/rules を見る状態になっていませんでした。

なお、このルールはもともと alwaysApply: false だけでした。そこに globs で対象ファイルを指定する設定を追加したところ、ネストブランチの問題は解決しました。

なぜ痛いのか

Cloud Agentsは作業が速いです。その分、ブランチ戦略が崩れたときのダメージも速く出ます。ローカルなら途中で気づいて止めやすいですが、クラウド側に任せていると、気づいたときにはすでに履歴が複雑になっていることがあります。

次にやること

• 作業開始時に、どのブランチから切るかを明示します
• 可能なら「既存の作業ブランチからさらに切らない」を .cursor/rules に追記します。

ブランチ運用は後から綺麗にするコストが高いです。最初の数回でここを固めておく価値は大きいと感じています。

② Composer 2.5が、勝手にFastになる（ように見える）

次に気になったのがモデル選択です。ダッシュボード側では Composer 2.5 を Fastなし に設定していました。

それなのに、実装が始まると勝手に Fast モードで動き始めました。

フォーラムを読み進めた結果

この件は、Cursor Forumでも報告されていました。

参考: Cloud Agents always start in fast mode in web

スレッドを読み進めると、ポイントはこうです。

• UI（モデルピッカー）では Fast がONに見える
• ただし裏側の実リクエストは、通常の（non-Fast）Composer 2.5 で動いているケースがある
• Cursorスタッフ側でも、該当エージェントのリクエストが Fast ではなく通常モデルに向いており、Fast料金も発生していなかった、と確認されています
• つまり、少なくとも一部は「本当にFastで動いている」のではなく、表示上のバグ（display issue） だと考えられます

当初は「勝手にFastになった」と捉えていましたが、フォーラムを追うと Fastが表示されているだけで、実際にはノーマルモードで動いている ということがわかりました。

③ UIの目視確認は便利。ただし課金モデルに注意

UIまわりの実装では、終わりにVMを使って目視確認までしてくれる機能がありました。この機能自体は以前から知っていましたが、今回初めて本格的に使いました。

体験としてはかなり良いです。実装して終わりではなく、見た目としてどうかまで見てくれるのは安心感があります。

一方で、コスト面の落とし穴がありました。

確認時に使われたモデルが claude-4.5-sonnet で、Other Modelの使用量が16%まで跳ねました。

実装本体のモデルとは別に、確認工程が高めのモデルを使います。ここを見落とすと、実装は想定内なのに、Usageだけ急に減ることになります。

次にやること

• 目視確認が必要かどうかは、タスクごとに決めます
• 不要なときは .cursor/rules で確認不可にします
• 確認を入れる場合は、そのモデル分のコストを最初から見積もります

便利機能ほど、オンにした瞬間の副作用を先に書いておくべきだと感じました。

④ Fast表記がない。料金はどうなるのか（②とつながる）

④は、当初は「UsageにFast表記がない。では料金はどうなるのか」という観察メモでした。

ダッシュボードの Usage を見ると、Fast の表記がありません。

では、Cloud Agents上で Composer 2.5 Fast が使われたとき、課金は通常の Composer 2.5 と同じ扱いなのでしょうか。

②のフォーラム確認を踏まえると、ここにも一本筋が通ります。

• UIでは Fast に見えても、実リクエストは通常モデルというケースがある
• その場合、Usage側に Fast が出ない／通常料金で計上される、という見え方とも整合します
• 逆に言えば、画面表示だけを信じて「Fast課金された」と判断するのは危ないです

いまのところ、「表示」と「実課金」を分けて見る必要があります。少なくとも②についてはフォーラム上で「表示バグ＋裏はノーマル」という確認例があります。

4つに共通する論点

振り返ると、①〜④は別々の話に見えて、共通点があります。

Cloud Agentsは「設定したつもり」と「実際の挙動（または表示）」の差分が出やすいです。

領域	起きること	対策の方向
ブランチ	.cursor/rules が未参照でネストブランチ	globs 指定などで参照される形にする
モデル	UI上はFast、裏はノーマルの可能性	Usageと実挙動を突き合わせる
UI確認	高額モデルでUsage急増	確認のON/OFFをタスク単位で
課金表示	Fast表記が見えない／紛らわしい	表示と請求を分けて確認する

ローカルエージェントでも似たことは起きますが、Cloud Agentsは実行が向こう側なので、差分に気づくのが遅れやすいです。だからこそ、最初の運用方針を .cursor/rules に短くてもいいので明文化しておくことが大事です。

いまの自分用チェックリスト

次回以降、作業を投げる前にこれを見ます。

1. Cloud Agents向けの .cursor/rules は参照される設定か（alwaysApply: false なら globs も見たか）
2. ベースブランチと「追加で切らない」方針は .cursor/rules に書いたか
3. 使うモデル（Fast含む）は意図どおりか。UI表示だけで判断していないか
4. UI目視確認は今回必要か。不要なら .cursor/rules でオフにしたか
5. 開始直後に、実モデル（Usage含む）とブランチを一度確認したか

この5つだけで、今回の①〜③はかなり防げるはずです。④は②とセットで、引き続き観察します。

まとめ

Cursor Cloud Agentsは、個人開発の実装速度を確実に上げてくれます。特に「切って、実装して、確認する」までの一連を任せられるのは大きいです。

ただ、速さの裏側で次の4点がつまずきどころでした。

1. .cursor/rules は書いただけでは読まれません（参照設定が必要です。alwaysApply: false だけだった場合は globs 追加で解決しました）
2. モデル表示は実行時にズレて見えることがあります（Fast ONに見えるが、裏ではノーマルの確認例あり）
3. UI目視確認は便利ですが、確認用モデルのコストが見えにくいです
4. Usage上のFast表記と実課金の関係は紛らわしいので、表示と請求を分けて見る必要があります

便利さを否定する話ではありません。むしろ、最初にこの差分を押さえておけば、Cloud Agentsはもっと安心して使えます。

参考フォーラム: Cloud Agents always start in fast mode in web