Cursorのクラウドエージェントに開発を頼んだら、成果物が手元に無かった話
Cursor のクラウドエージェント（自分のPCではなくCursor側のマシンで動くAI）にブログの機能追加を依頼したところ、作業が終わっても手元のフォルダにはファイルが1つもありませんでした。
普段はターミナルで動く Claude Code を使っています。使用量の枠が足りなくなったため、開発だけ Cursor（Pro契約・月20ドル）に移すことにしました。2026年9月1日に Cursor 3.18.9 を使い始めた初日の記録は、前回の記事にまとめています。
この記事は前回の続きです。 前回：Claude CodeユーザーがCursor 3を入れた初日。VS Codeのつもりで開くと3か所で迷う
初日は手元のファイルを触ってほしかったので、クラウドエージェントには入らず「Local」に切り替えて引き返しました。今回は実際に任せてみた記録です。
手元を触らないこと自体は仕様として知っていました。 それでも詰まったのは、成果物がどこに出るのかと、そこに気づけなかったことのほうでした。
頼んだ作業：記事ページへの前後リンク追加
依頼したのは、このブログの記事ページ下部に「前の記事」「次の記事」へのリンクを表示する機能の追加です。指示は1行だけ渡しました。
時系列：指示から本番反映まで
2026年9月3日の流れです。すべて日本時間です。
| 時刻 | 起きたこと |
|---|---|
| 10:40:36 | 別の記事を公開してデプロイ（本番サイトに反映する作業） |
| 14:09:38 | クラウドエージェントがGitHubにブランチとプルリクエストを作った |
| 14:36:45 | プルリクエストをマージ（変更を本体に取り込む操作） |
| 15:11:44 | 手元に取り込んだ。ここまで手元には何も無かった |
| 15:12:07 | 手元から再デプロイ。本番サイトに前後リンクが出た |
プルリクエストが出てから手元に届くまで、1時間2分あります。 その間、手元のフォルダは何も変わっていません。
出てきた成果物は次のとおりです。
- ブランチ（作業用に枝分かれさせたコードの置き場）：
cursor/add-prev-next-post-nav-d502 - プルリクエスト（変更を本体に取り込む提案）：#1「記事ページに前後の記事リンクを追加」
- 変更量：3ファイル / +75行 / -2行
src/components/PostNav.astro（前後のリンクを表示する部品、新規31行）src/pages/blog/[...slug].astro（前後の記事を渡す処理を追加）src/styles/global.css（見た目）
結果として、公開済みの12記事すべての下部に前後リンクが表示されるようになりました。ただしコードの中身は読んでいません。表示を見て動いていることだけ確認しています。
問題1：成果物はGitHub側にだけ出る
クラウドエージェントは Cursor 側の仮想マシン（Cursorが用意する、自分のMacとは別のコンピュータ）で動きます。そこにコードを複製して作業するので、手元のファイルは書き換わりません。
では成果物はどこへ行くかというと、GitHub（コードを預けて共有する場所）です。作業用のブランチが作られ、プルリクエストの形で提出されます。手元だけを見ていると、何も起きていないように見えます。
検証もクラウド側で済んでいました。エージェントは仮想マシンの中で画面を開いて確かめ、記録を残しています。
- スクリーンショット3枚（中間の記事・最新の記事・最古の記事の3パターン）
- 動作を録画した動画1本
これらはCursorのエージェント画面にそのまま出るので、見落とすものではありません。 ただし実体の置き場は cursor.com 側で、手元のフォルダには1枚もありません。コードも確認の記録も、まとめて向こうにあります。
手元のAIは、これに気づけない
実際に起きたことです。普段使っている Claude Code に手元から状況を尋ねたところ、「このリポジトリには入っていません」と返ってきました。リポジトリとは、そのプロジェクトのファイル一式が入った置き場のことです。
誤りの原因は単純で、手元の情報が古いままだったからです。git fetch（GitHub側の最新情報を手元に取り直す操作）をしていなければ、向こうに新しいブランチができていても手元には見えません。取り直したら、ブランチもプルリクエストも普通に見つかりました。
手元のAIに聞いても分からない、というのがこの仕組みの厄介なところです。クラウドエージェントを使ったら、手元ではなくGitHubを見に行く必要があります。
問題2：手元とGitHubが枝分かれしていた
もうひとつ、危ないところでした。
| 置き場 | その時点で持っていた変更 |
|---|---|
| 手元 | 表示速度の修正（_headers）、サイトマップの更新日、10:40に公開した記事 |
| GitHub | クラウドエージェントが作った前後の記事リンク |
手元の直近2回のコミット（変更の記録）が、まだGitHubに送られていませんでした。クラウドエージェントは、GitHubにある古い状態から枝を切ります。 そのため、手元とGitHubが別々の方向に進んでいました。
ずれの大きさは記事の本数に出ていました。エージェントが土台にしたのは記事が11本の状態で、そのとき手元には12本ありました。 10:40に公開した記事が、向こうには無かったということです。
ここで「GitHub側に手元を合わせる」操作をしていたら、手元にしかない表示速度の修正が消えて、問題が再発するところでした。
助かったのは、手元で直していたファイルとエージェントが触ったファイルが完全に別だったことです。マージ（両方を1つに合流させる操作）で、どちらも消えずに残りました。
手元のコミットは、依頼する前にGitHubへ送っておく必要があります。 これは運の要素が大きかったので、次からは先に送ります。
モデルを指定しなかったら、Claude Opus 4.8 で走っていた
そもそもモデルを気にしていたのには理由があります。Grok で同じ開発ができるか見てみたかったからです。Grok は Cursor に統合されていて、Pro の契約で使えます。Claude 以外でも同じものが作れるなら、道具の分け方の幅が広がります。
ところが、クラウドエージェントを動かしていたモデルを確認したら Claude Opus 4.8 でした。普段 Claude Code で使っているのは Opus 5 なので、同じ Opus でも版はひとつ前ということになります。
そこで分かったのが、クラウドエージェントは作業の途中でモデルを変更できないことです。起動する段階で指定しておく形になっています。Grok で試したければ、最初に指定しておく必要がありました。 起動時に選び直すのは、まだ試していません。
これは失敗ではない
「同じ Opus なら、Cursorに移した意味がないのでは」と思うかもしれません。そうではありません。
Cursor を入れた目的は、Claude Code 側の週の使用量を空けることでした。Cursor の中で何が動いていても、消費しているのは Cursor の契約枠です。Claude Code 側の枠は減っていません。 目的は達成されています。
むしろ、移行で品質が落ちる心配はかなり薄くなりました。 版はひとつ前とはいえ、普段使っているものと同じ系統です。出力がまったく同じになるとは限りませんが、大きく崩れることは考えにくいと思っています。
分かれたのは請求先だけで、中身は変わらなかった、ということになります。
原因は「混ぜたこと」だった
3つ書きましたが、振り返るとどれもクラウドとローカルを混ぜたから起きたことです。
クラウドエージェントの中だけで完結させていれば、成果物の場所も確認の記録も画面に出ています。迷いようがありません。今回は途中から手元に持ってきて、手元から公開まで済ませようとしました。そこで置き場の違いと枝分かれが、一度に表に出たわけです。
どちらでやるかを先に決めておく。 混ぜるなら、手元の変更をGitHubへ送って揃えてから渡す。
もっと言うと、今回はローカルで頼めば何も起きませんでした。 クラウドエージェントを選んだのは、単に興味があったからです。手元のフォルダを直接触ってもらえば、成果物の置き場も枝分かれも問題になりません。選べるモデルもローカルのほうが多いので、Grokで試したいという当初の目的にも、そちらのほうが合っていました。
クラウドが要るのは、Macを閉じても走らせ続けたいときや、同時に何本も回したいときだと思います。今回の作業は、どちらにも当てはまりませんでした。
まとめ
- クラウドエージェントの成果物は手元に出ない。GitHubにブランチとプルリクエストの形で出る
- 検証のスクリーンショットや動画はエージェント画面で見られる。ただし実体は手元ではなく
cursor.com側 - 手元のAIに聞いても分からない。 手元の情報が古いままだと「何も無い」と返ってくる。
git fetchで取り直す - 手元のコミットを送っていないと枝分かれする。依頼する前にGitHubへ送っておく
- 途中でモデルは変更できない。起動時に指定する
- 担当が Opus 4.8 でも、Claude Code 側の枠は減らないので目的は満たせる
- そもそもローカルで頼めば、上のどれも起きない。 選べるモデルもローカルのほうが多い
手元の環境を用意せずに作業を任せられるのは、確かに楽でした。ただしそれが要る場面かどうかは別です。クラウドで完結させるか、手元でやるか。決めてから渡せば、今回の3つはどれも起きません。