CursorでActavia（現状β版）をゼロから構築してみたリアルな所感
β版として公開中の Actaviaサービス を、Cursorを使ってフロントエンド・バックエンド・インフラすべて含めて一気に構築した。その結果、開発体験は驚くほどスムーズで生産的だった。以下、各レイヤーでの所感と、プロダクションレベルに耐えるシステムにするために「人の手」が求められた領域をまとめる。
フロントエンド（React）
UIが固まっていれば、Reactを用いた構築は非常に高速。Cursorの提案機能により、状態管理や構造の整理もスムーズで、特に繰り返しがちなコンポーネント設計に強みを感じた。設計フェーズさえ詰めておけば、実装はほぼ迷わず進む。
バックエンド（FastAPI）
FastAPIを使ったAPI実装はシンプルかつ高速。CORS設定やログ出力といったセキュリティ周辺を事前に固めておけば、Cursorの支援でAPI構築は一気に進む。注意点はテスト。設計が曖昧だとすぐにモック多用になり、信頼性の低いテストコードが量産される。ここだけは初期設計がモノを言う。
データベース（PostgreSQL）
ここはほぼ手動設計になった。ドメインごとの複雑な要件が絡む以上、Cursorでは対応しきれない。正規化、外部キー設計、履歴管理などをきっちり設計したいなら、人間の介入は必須。特にサービス拡張を見据えるなら、初期スキーマの完成度が後の生産性を大きく左右する。
インフラ（Terraform / AWS）
TerraformによるAWS構築は、要件さえ明確であればスムーズだった。APIをパブリックサブネットに置くか、プライベートにするかといった判断が固まれば、構築はCursorの支援で自動化可能。ただし、IAMロールやセキュリティグループの設計は人の目が必要。特に権限周りは誤ると致命的。
本番運用で「人の判断」が必要だった領域
Cursorの支援で開発速度は大幅に上がったが、本番運用に耐える品質を実現するためには、以下のような領域で人の判断が不可欠だった。
ログの出力先・保存期間の設計
セキュリティ、コスト、トラブル対応の観点で設計が求められる。CloudWatchやS3など、出力先ごとにベストプラクティスが異なり、テンプレートでは吸収しきれない。
環境変数の管理方法（機密性の高い変数との分離）
すべてを.envに放り込むような雑な管理はNG。パラメータストアなどと連携しつつ、秘匿情報をどこで管理し、アクセスできるかを厳密に定義する必要がある。
拡張性と保守性を意識したDB設計
未来を見据えたスキーマ設計。JOINの負荷、インデックス戦略、マスタデータ管理……自動生成には限界がある。
DDLの管理・適用方法
Alembicなどのツールをどう組み込むか、CI/CDとどう連携させるか、本番環境で安全に適用するための戦略が必要。踏み台サーバー等の運用も決める必要あり。
ログ・アラートの出力ルールの定義
何をアラートとし、どのように通知するかは、運用体制とビジネスの重要度に依存する。PagerDutyに飛ばすのか、Slackに流すのか、通知量の最適化も重要。
インフラリソースとオートスケーリングの設定
想定ユーザー数や負荷状況に応じたチューニングは不可欠。無駄なリソース消費はコストに直結し、不足はサービス停止に繋がる。可用性とコストのトレードオフを判断するのはまだ人間の手が必要だと感じt
結論：Cursorは「開発初期の加速装置」、だが本番運用には人の設計思想がいる
以上のように、人の判断が求められる部分は残るものの、Cursorを使えば約1ヶ月でフルスタックのWebサービスを構築できたのは事実。実際に Actavia β版 はそのスピード感で立ち上がっている。
Cursorは「考える余白」を残したまま、実装を加速できるツールだった。ゼロから立ち上げるなら、今後の選択肢としてかなり有力。逆に言えば、このレベルの支援があるからこそ、設計や運用といった“本当に人間がやるべきこと”に集中できるとも言える。
最後に
🚀 プロトタイプを爆速で形にしたい人へ：Cursor、試す価値あり。
🌀 そして、僕たちが1ヶ月で立ち上げたActaviaはこちら(β版なので日々修正されています) → https://actavia.link/dashboard