はじめに
こんにちは、あじさいです。
Cursor Advent Calendar 2025の記事をお届けします。
今回は、AI駆動型開発の一部として、Cursorを活用した開発プロジェクトでの経験について書こうと思います。
「AIで開発が全部自動化できる！」と期待して始めたプロジェクトでしたが、現実はそう甘くありませんでした。
実際にCursorを導入して、要件定義から製造まで各工程で使ってみた結果、思ったことや苦労したことをお伝えします。
AI駆動型開発の実践 〜Cursorで開発工程を効率化した経験談〜
プロジェクト概要
今回のプロジェクトでは、「Cursorを使って開発工程を効率化できないか？」と試してみることにしました。
要件定義から製造まで、できるだけCursorに頼ってみる作戦です。
利用した開発工程
以下の工程でCursorを活用しました。
| 工程 | 利用ツール | 備考 |
|---|---|---|
| 要求仕様 | Cursor | 文書ベースの要求仕様から要件定義書を生成 |
| 要件定義 | Cursor | 要件の整理・文書化 |
| 基本設計 | Cursor + Figma MAKE | 画面レイアウトはFigma MAKEで作成 |
| 詳細設計 | Cursor | 詳細設計書の作成 |
| 製造 | Cursor | コード生成・実装 |
結論：すべての工程をCursorで実施するのは不可
まず、結論から言うと、すべての工程をCursorで実施するのは無理でした。
ある程度は手動で対応する必要があります。
「AIが全部やってくれる」と期待していたのですが、やっぱりそうはいきませんでした。
AIは確かに強力ですが、万能じゃないんですよね。
特に以下のような場面では、人間の判断や手動での調整が必須でした：
- ビジネス要件を深く理解して判断する場面
- 複雑な技術的制約を考慮する場面
- 生成されたコードの品質を保証する場面
- プロジェクト固有のルールや規約に合わせる場面
こういう部分は、まだまだ人間がやらないとダメだなと実感しました。
成果が出た点
工数削減の実績
各工程でCursorを使ってみた結果、思った以上に工数が削減できました。
「これは使える！」と思えたポイントを紹介します。
1. 要求仕様（文書ベース）→要件定義
最初に試したのが、文書ベースの要求仕様から要件定義書を生成することでした。
結果、見栄え的にも、綺麗に生成してもらえました。
マークダウンのフォーマットも整っていて、「これは手動で作るより早いな」と感じました。
要件の整理と構造化が大幅に効率化され、この時点で「Cursor、使えるかも」と思い始めました。
2. 要件定義 → 基本設計の作成（7～8割ほど工数削減）
要件定義書を基に、Cursorが基本設計書の骨組みを自動生成してくれました。
画面遷移図や機能一覧の作成が大幅に短縮され、「これ、手動でやったら何時間かかるんだろう……」と思いながら、生成された内容を検証していました。
人間は生成された内容の検証と調整に集中できるので、作業の質が上がった気がします。
3. 基本設計 → 詳細設計の作成（7～8割ほど工数削減）
基本設計書から詳細設計書への展開が自動化されました。
データベース設計やAPI設計の詳細仕様を効率的に生成してくれるので、「ここも手動で書いていたら大変だったな」と実感。
画面レイアウトはFigma MAKEを活用し、視覚的な設計も支援してもらえました。
この工程でも、やはり7～8割ほど工数が削減できたと思います。
4. 詳細設計 → 製造の作成（7～8割ほど工数削減）
詳細設計書から実装コードへの変換が大幅に効率化されました。
ボイラープレートコードの生成が自動化され、「毎回同じコードを書くの、めんどくさかったんだよな……」という悩みが解決。
実装パターンの一貫性も向上し、コードレビューが楽になりました。
この工程でも、やはり7～8割ほど工数が削減できました。
5. AIコードレビューによる前工程の乖離確認
これは個人的に「これは便利！」と思った機能です。
各工程で生成された成果物を、AIコードレビューで前工程との整合性を確認できます。
「設計と実装が乖離してないか？」を自動でチェックしてくれるので、手戻りが大幅に減りました。
設計と実装の乖離を早期に発見・修正できるようになり、品質向上と手戻り削減を実現できました。
苦労した点
1. ユニットテスト：都合の良いテストコードを書いてくる
最も苦労した点の一つが、ユニットテストの生成でした。
Cursorが生成するテストコードは、通すことを前提に修正される傾向がありました。
「テストが通ればいいんでしょ？」という感じで、実装コードを都合よく解釈してくるんです。
- テストが常に成功するように、実装コードを都合よく解釈
- エッジケースや異常系のテストが不十分
- テストの意図が不明確で、何をテストしているのか分からない
「これ、本当にテストになってるの？」と何度も思いました。
対策：
- テストコードの生成後は、必ず人間がレビュー
- テストケースの網羅性を手動で確認
- 実装コードとテストコードの整合性を検証
結局、テストコードは人間がしっかりレビューしないとダメだなと実感しました。
2. モデルによって、成果物のレベルが異なる
Cursorでは複数のAIモデルを選択できますが、モデルによって成果物のレベルが大きく異なることが判明しました。
最初は「モデルなんてどれでもいいでしょ」と思っていたのですが、実際に使ってみると全然違いました。
最も成果が出たモデル：Sonet 4.5
プログラミングは成果が出ていたモデルです。
- コード生成の精度が高く、実装パターンも適切
- エラーハンドリングや例外処理も考慮されている
- 「これは使える！」と思える品質
その他のモデルとの違い
- モデルによって、生成されるコードの品質に大きな差
- 設計書の生成では、別のモデルの方が適している場合も
- 用途に応じてモデルを切り替える必要がある
「このモデル、プログラミングは弱いけど設計書はいいな」みたいな感じで、用途によって使い分けが必要でした。
対策：
- 工程ごとに最適なモデルを選択
- 複数のモデルで生成した結果を比較検討
- プロジェクトの特性に合わせてモデルを選定
結局、モデル選びも重要だなと実感しました。
3. シーケンス図の構文エラーが多数発生
Cursorが生成するシーケンス図（mermaid記法など）で、構文エラーが頻繁に発生しました。
「シーケンス図も自動生成できるでしょ」と思って依頼したのですが、生成された図を見ると構文エラー。
「修正して」と依頼しても、また別の構文エラーが発生する……。
- 生成されたシーケンス図の構文が正しくない
- 図が表示されない、または意図した通りに描画されない
- 修正を依頼しても、また別の構文エラーが発生する
「これ、手動で直した方が早いな……」と何度も思いました。
対策：
- シーケンス図の生成後は、必ず構文を手動で確認
- エラーが発生した場合は、人間が直接修正
- 複雑なシーケンス図は、最初から手動で作成することも検討
シーケンス図に関しては、まだまだ手動対応が必要だなと感じました。
4. リーダー兼任による確認作業のスタック
今回のプロジェクトでは、リーダーも兼任していたため、確認をしないといけない状況でした。
AIによりメンバーの作業が早い分、確認対象がスタックしてしまう事件が発生しました。
「生成された成果物を確認しないと……」と思っている間に、次の工程の成果物がどんどん生成されてくる。
確認が追いつかず、「あれ、これどれから確認すればいいんだっけ？」という状態に。
- AIの作業速度が速すぎて、確認が追いつかない
- 確認対象がどんどん積み上がっていく
- リーダーとしての確認責任と、開発作業のバランスが取れない
「AIが速すぎて、むしろ困る……」という、予想外の悩みでした。
対策：
-
AIコードレビューによるレビュー効率化
- AIコードレビューを活用して、レビュー作業自体を効率化
- 自動でチェックできる部分はAIに任せ、人間は重要な部分に集中
-
先工程に進んでいただき、レビューの分の指摘事項を後から取り込み
- 確認が追いつかない場合は、先に次の工程に進んでもらう
- レビューで出た指摘事項は、後からまとめて取り込む方式に変更
- 作業の流れを止めずに、品質も確保する方法を模索
結局、AIのスピードに合わせて、レビューのやり方も変える必要があるなと実感しました。
今後の展望
Cursor Browserを利用したテスト自動化
今後試したい点として、Cursor Browserを活用したブラックボックステストの自動化を検討しています。
期待される効果
-
ブラックボックステストの自動化
- ブラウザで実際に操作しながら、テスト仕様書を自動生成
- 手動テストの工数を大幅に削減
-
テストカバレッジの向上
- 人間が見落としがちなテストケースを自動で発見
- 回帰テストの自動化
-
テストドキュメントの自動生成
- 操作ログからテスト仕様書を自動生成
- テストケースの可視化と管理
まとめ
AI駆動型開発は、開発工程を大幅に効率化する可能性を秘めています。
実際に使ってみて、以下の成果を実感しました：
- 工数削減：各工程で7～8割の削減を実現
- 品質向上：AIコードレビューによる前工程との整合性確認
- 効率化：ボイラープレートコードの自動生成
「これは使える！」と思える場面が多かったです。
しかし、すべてをAIに任せることはできません。
- ユニットテストの品質は人間のレビューが必須
- モデルによって成果物のレベルが異なるため、適切な選択が必要
- ビジネス要件の深い理解は人間の判断が不可欠
- シーケンス図などの図表は、まだまだ手動対応が必要
「AIが全部やってくれる」と期待していたのですが、現実はそう甘くありませんでした。
AIは強力なアシスタントであり、パートナーです。
人間とAIが協力することで、より効率的で高品質な開発が実現できると考えています。
本記事が、AI駆動型開発を検討しているエンジニアの参考になれば幸いです。