Cursorを使用した開発をして感じたこと
株式会社グローバルウェイ プラットフォーム事業部の永井です。
私の事業部では主にPythonベースのDjangoを利用したWebアプリケーションを15年以上開発しております。
そんな中、2025年はAIを活用した開発効率化を模索する年でした。なぜならChatGPTやCopilot、CursorなどのAIを活用した開発支援ツールが飛躍的に技術躍進し、真の意味で『プロンプト開発』によって機能実装が可能となった年であったと感じたためです。 実際にCursorをダウンロードし、何がどこまでできるかを試してみた内容を紹介します。
実施したこと
作成したものは、社内ポータル的なもので機能概要は以下です。
- 一般ユーザ機能
- ログイン／ログアウト機能
- トップページ（直近のお知らせ、お問い合わせ表示）
- お知らせ機能（お知らせ一覧、詳細）
- お問い合わせ機能（お問い合わせ一覧、新規お問い合わせ登録、編集）
- 管理者機能 ※一般ユーザ機能にプラスして以下
- ユーザ管理（ユーザ一覧、登録・変更・削除）
- グループ管理（グループ一覧、登録・変更・削除）
- 権限管理（権限一覧、登録・変更・削除）
- お知らせ管理（お知らせ一覧、登録・変更・削除）
- お問い合わせ管理（お問い合わせ一覧、登録・変更・削除）
さすがに何もないところから作成すると収拾がつかなくなりそうだったため、開発環境にフロントエンドは Vue（Vite）、バックエンドはDjango REST Framework（DRF）を採用し、両者を dockerコンテナで起動させるdocker_compose.yamlまでは手動で作成したものを使用しました。作成したフォルダをCursorのIDEで開き、あとはプロンプトベースで作業を依頼しました。ちなみにCursorを選んだ理由は、「指示→生成→即実行→差分編集」のループをVSCodeと同様のIDEで実行可能であった点と、空いているAIエンジンを自動で選択してくれるためです。
また、プロンプト開発の進め方としては、まずは大枠の作成を依頼（ヘッダーはタブで切り替え、左メニューに各機能を表示、右側がメイン画面程度を依頼）し、そこができた後に各メニュー単位での機能実装をプロンプトで依頼しました。
また、それらを作るうえで私が確認したかった点は以下となります。
- プロンプト開発だけで動くものが本当にできるのか
- どれくらいのスピードでできるのか
- デザインなど文字では言い表せない部分をどこまで対応できるのか
- どこまで品質が保てるのか
- 作ったものをデプロイまでできるのか
結果
1.プロンプト開発だけで動くものが本当にできるのか
結論、普通に動作するものが作成できました。もちろん、１回でうまくは動作しない場合が多いため、その都度そのエラー画面キャプチャを撮り、チャットにペーストして「ｘｘｘを実施したらエラーが発生したから確認して」など依頼する必要があります。ただ、このやり取りを繰り返していくことで簡単な画面であれば動作するようになります。体感で一覧表示や詳細表示などであれば、エラーは５回以内で修正でき、想定通りの動きを行えるイメージでした。
2.どれくらいのスピードでできるのか
今回作ったベース機能（ログイン・ホーム画面表示）だけであれば２～３時間で作成できます。その他の機能も大体１つにつき２時間ほどである程度動作するところまでは作成できます。 何より、プロンプトで依頼した後は別の作業をしていて問題ないため、他の作業をしている間に実装が終了し後は動作確認する、という流れなのでトータルの作業効率という意味では圧倒的に良いのではと感じました。
3.デザインなど文字では言い表せない部分をどこまで対応できるのか
プロンプトベースだと細かいイメージが伝わらないと思っていましたが、意外とニュアンスをくみ取り対応してくれました。また大枠のイメージであれば、例えば参考になるＵＲＬを指定して「このサイトに似たデザインにして」と依頼すると、色合いや文字などをある程度合わせてくれます。
ただし、CSSやHTMLに関して（Vueなので今回はTypeScript）は、何度も依頼していると、CSSとHTMLの両方で同様の実装をしたり不要な入れ子構造になり、思ったように修正されないケースもありました。そういう時は、一度CSSやHTMLの属性を綺麗にして、構成を１から依頼し直すことで改善できました。
4.どこまで品質が保てるのか
これはやはり１回で完璧なものは無理で、１機能あたり数回、多いときには十数回はデバックし、修正依頼を繰り返す必要がありました。そういう意味では、品質は中の下くらいかなと思いました。
また、コードをレビューしているわけではないため、実際にセキュリティ的に問題がないかなどは、別のチェックツールなどで試験するか、愚直にコードレビューをする必要はあると思います。
5.作ったものをデプロイまでできるのか
これは可能でした。実際にdocker上でローカル開発したものを、AWSのデプロイも、AIにデプロイ作業まで実行することができました。ただし、AWSへアクセスする際のtokenやsecret情報を一時的にでもAIにアクセスさせるので、セキュリティ的に問題があります。おすすめとしてはデプロイ用のScript作成までをCursorに実施してもらい、それを手動で運用するなどが良いと思いました。
6.その他、気づいた点
Cursorには１回ごとに修正内容を開発者に確認させるAskモードと、すべてを自動承認してまかせるAgentモードがありますが、Agentモードで気を抜くとDBのmodelを修正したことで起動できなくなった際に、Agentが勝手にデータを全クリアすることがありました。そのため、初期データなどは前もってinitial.yamlなどで作成しておき、そこから初期データを再構築できるようにしておくと安心です。
またCursorでは、どのAIモデルを使用するかを選べるのですが、これもAutoにしておくと日によっては返答が遅い場合がありました。私はCursorを社用アカウントで有償利用しているため、試しにcludeなどを指定すると非常に精度よく動いてくれました。一方で、clude課金は高いのと有償アカウントでもある一定量を超えると重量課金されるため、基本はAutoにしておくのがよいのかなと思いました。
結論
今回、簡単なポータルではありますが、Cursorを使うことで本格的なWebアプリをプロンプトだけで実装することが可能である、ということが体感できました。
この事実は、今まで社内DXに二の足を踏んでいた中小企業にとっては朗報で、ある程度の知識をもっていれば大きなコストをかけてSaaSを使わなくても自社向けに独自カスタマイズしたサービスを開発できる時代がきたと言えると思います。私はこれを勝手に「CSaaS」と呼んでおり（Custom Software as a Service）、今後この流れは2026年以降一層加速するものであると見ています。
一方、開発業務を担っているSIerとしては、今後社内開発が大企業を中心に加速した場合案件が減ってしまう、という危機感にもつながるかと思いました。そのため、まずはCursorなどでどこまでできるかを肌身で体感し、その境界線がどこかをしっかり見極め、その先に何ができるのかを模索し続ける必要があると考えています。
今後も、AIを利用した開発の可能性については別の機会に紹介できればと思います。
