ノートPCでも開発作業ができるように、少し前から環境を整えていた。
普段使っているPCとは別に、Gitを入れ、Pythonを入れ、Node.jsを入れ、GitHubからリポジトリをcloneする。
面倒ではあるけれど、一度自分で作ってしまえば何がどこに入っているのか分かる。
当初は、普通にそうするつもりだった。
ところが途中で、Cursorにはクラウド上に開発環境を用意して、そこでAgentを動かせる仕組みがあることを知った。
「これならノートPCへ同じ環境を全部作らなくてもいいのでは？」
そう思って、試してみた。
結果から書くと、かなり動いた。それでも2026年8月時点では、Cursor Cloudの導入をいったん凍結することにした。
便利ではなかったから、ではない。
むしろ想像していた以上に動いた。
ただ、自分にとって「使える」と「安心して運用できる」は別だった。
ノートPCに開発環境を作る途中でCursor Cloudを知った
そもそもの目的は、帰省先でも普段の開発を続けられるようにすることだった。
そのためノートPCへ、普段使っているPCに近い環境を作り始めた。
Git、Python、Node.js。
必要なものを自分で入れて、リポジトリをcloneして、動作確認する。
昔からある普通のやり方だ。
ただ、複数のプロジェクトを扱っていると、PCが変わるたびに同じ環境を作るのはそれなりに手間がかかる。
そんな途中でCursor Cloudを試した。
Cursorの公式ドキュメントによれば、Cloud AgentsはローカルPCではなくクラウド上の隔離された開発環境で動き、リポジトリや依存関係、シークレット、起動コマンドなどを設定してコードの実行やテストまで行える。
これを見たときは、かなり魅力的に感じた。
もし開発環境そのものをクラウド側に置けるなら、ノートPCはCursorを操作できればいい。
PCごとに同じ環境を再現する必要がなくなるかもしれない。
実際に試したら、Pythonプロジェクトはかなり動いた
そこで、実際に使っているPythonプロジェクトをCursor Cloudへ持っていった。
ブログの記事群をまとめるハブページを自動生成するための、小さなCLIプログラムだ。
幸い、このプロジェクトはPython標準ライブラリだけで動いていた。
Cloud側にはpython3は入っていたもののpythonコマンドがなかったので、symlinkを用意した。
その程度の調整で、
- Pythonスクリプトのコンパイルチェック
- 記事データからHTMLを生成
- 生成結果のvalidation
- テスト用データを書き換えてHTMLへ反映されることの確認
まで成功した。
最初は「AIがコードを編集できれば十分」くらいに考えていたので、実際に生成から検証まで回ったときは、
「これ、普通に使えるのでは？」
と思った。
Cursorで長時間処理を動かした経験については、以前にも書いている。
ローカルPCから処理そのものを切り離せるなら、「AIを待たない」という考え方をさらに進められる可能性も感じた。
ところがWordPressからの取得で止まった
順調だったのだが、一つ問題が起きた。
実際のWordPressから最新記事を取得する処理を動かすと、REST APIへのアクセスが403になった。
HTML生成ができないわけではない。
手元にあるデータを使う処理は正常に動いている。
しかし、最新の記事をWordPressから取得して、そのまま自動処理するところまでCloud側では完結できなかった。
原因を確認すると、VM自体がインターネットへ出られないわけではなく、WordPress REST API側のアクセス制御が関係していると考えられた。
ここで少し話が変わってきた。
「Cursor Cloudが動かない」のではない。
むしろCloud環境自体は正常に動いている。
でも、自分がやりたい開発全体を動かそうとすると、Cloud環境だけを理解すれば済むわけではなかった。
一番困ったのは、仕組みを自分で把握できていないことだった
403については、設定を詰めれば別の解決方法があるのかもしれない。
Cursor Cloud自体にも、シークレット、ネットワークアクセス、Build、環境設定、Dockerfileなど、かなり多くの仕組みが用意されている。公式ドキュメントを見ると、Agent自身に環境を構築させる方法だけでなく、Dockerfileによる手動設定なども用意されている。
でも、そこで自分の中に別の違和感が出てきた。
自分が、この環境をちゃんと把握できていない。
Cloud側で何が保存されているのか。
どのタイミングでBuildが作られるのか。
どの設定が次回も引き継がれるのか。
問題が起きたとき、どこを見れば原因を切り分けられるのか。
Cursorに聞けば説明してくれる。
設定自体もAgentがかなり進めてくれる。
それでも、自分自身が構造を理解できている感覚がなかった。
これは、かなり気になった。
AIに任せられることと、自分で保守できることは別だった
AIを使った開発では、すでに似たことを何度か経験している。
AIが大量の処理をしてくれること自体は、とても助かる。
でも、「できた」という結果だけを見て進めてしまうと、不具合が起きたとき急に何も分からなくなる。
大量の記事をAIで移行したときにも、「AIへ任せる部分」と「自分が判断する部分」を分ける必要があった。
今回のCursor Cloudも、少し似ていた。
セットアップ自体はAgentがかなりやってくれる。
コードも動く。
テストも通る。
でも、自分の理解が追いつかないまま環境だけ高度になっていくと、それはそれで怖い。
ローカル環境なら、
「Pythonはここに入れた」
「Gitはこれを使っている」
「このリポジトリはここにある」
「このコマンドを実行するとこれが動く」
というところを、自分で作りながら把握できる。
多少面倒でも、不具合が起きたときの入口が分かる。
自分にとっては、その分かりやすさの価値が思っていたより大きかった。
「これなら普通にローカル環境を作った方がいい」と思った
Cursor Cloudを触り始めたときは、
「ノートPCに環境を作る必要がなくなるかもしれない」
と思っていた。
ところが数日後には、考えが逆になった。
これなら多少手間でも、自分でノートPCへ普通に開発環境を作った方がいい。
もちろん、Cursor Cloudが悪いという話ではない。
公式ドキュメントを見る限り、Cloud Agent側でブラウザを操作したり、開発サーバーを立ち上げたり、リモートVM上で変更を確認したりする機能まで提供されている。かなり強力な仕組みだ。
ただ、「高機能であること」と「今の自分に必要であること」は別だった。
このあたりはAIによる自動化全般でも同じなのかもしれない。
便利そうだから採用するのではなく、自分が保守できる範囲と、得られるメリットを比べる必要がある。
そして、そもそもノートPCで開発する必要がなくなった
もう一つ、かなり大きな理由がある。
Cursor Cloudを試している間に帰省が終わった。
つまり、今回ノートPCへ開発環境を作り始めた一番の理由そのものが消えてしまった。
自宅へ戻れば、普段使っている開発PCがある。
次にノートPCで本格的な開発をする必要が出てくるのは、かなり先になるかもしれない。
その状態で、
「新しいCursor Cloudを理解するために、さらに時間を使うべきか？」
と考えると、優先順位はかなり下がった。
Cloud環境の理解を深めるためだけに、今すぐ必要でもないプロジェクトを続けることになる。
そこまでする理由はないと思った。
そこで、ノートPC開発環境の整備プロジェクト自体をいったん凍結した。
Cursor Cloudの導入も同時に凍結した。
Cursor Cloudをやめたのではなく、今は採用しない
ここは少し区別しておきたい。
Cursor Cloudを「使えない」と判断したわけではない。
今回のPythonプロジェクトでは、実際かなりのところまで動いた。
ローカルPCを起動していなくてもAgentが作業できるような構成には、今でも可能性を感じている。
ただ、2026年8月現在の自分にとっては、
理解するコストと、今すぐ得られるメリットが釣り合わない。
そう判断した。
次に長期間外出して、本当にノートPCから開発する必要が出たときには、もう一度試すかもしれない。
そのころにはCursor Cloud側の機能も変わっているだろうし、自分の理解も変わっている可能性がある。
そのとき、
「以前はここが分からなくて凍結した」
という記録が残っていれば、今回の試行錯誤も無駄にはならない。
新しい技術を「使わない」と決めることも、検証の結果だった
新しい機能を見ると、つい使いこなしたくなる。
特にAI関連は変化が速いので、「今触っておかないと遅れるのでは」という感覚もある。
今回も最初は、Cursor Cloudを理解して、今後の標準環境にできたら面白いと思っていた。
実際に触ってみて、かなり動くことも分かった。
そのうえで、
「今は使わない」
というところへ戻ってきた。
以前だったら、ここまで試したら「せっかくなので何とか使おう」と続けていたかもしれない。
でも今回は止めた。
新しい技術を採用できたことだけが成果ではない。
自分の用途では、現時点では採用しないと判断できたことも、検証したから得られた結果だと思う。
ノートPCの開発環境が本当に必要になったら、まずは自分で把握できる普通のローカル環境を作る。
Cursor Cloudについては、必要性が生まれたときにもう一度考える。
2026年8月時点では、それが一番分かりやすい結論になった。
