お疲れ様です。
案件を探す中で「AI駆動開発」が必須要件に入っている現場が多いなという強い印象をうけました。さすがに無視できないと思い、私もAI駆動開発でのアプリ開発に挑戦してみました。
約１週間で行った内容を共有します。
目次
- Cursorについて
- 開発するアプリについて
- 開発成果について
- AI駆動開発をやってみて
1. Cursorについて
採用理由
様々なAIツールがありますが、以下の理由からCursorを採用しました。
- IDEの学習コストが低い
VS CodeからクローンされたIDEのため、キーバインドや拡張機能の使い心地が概ね同じです。移行コストやツールの使い方を学びなおすコストが低いです。 - 独自のLLMに加えて、他社のLLMも使用できる
有料プランであれば支払ったクレジットの範囲内でClaudeやSonnet, GPTなどの他社LLMを切替えて使用することができます。
Cursor独自のLLMのComposerまたはAutoを選択しておけば、その分は別のプールから消費される仕様になっています。
プランについて
今回は無料プランから使用を始めて、無料分クレジットが底をついた段階でProプラン（$20 / month）を契約しました。
2. AI駆動開発するアプリについて
開発の進め方
今回はWebアプリの要件定義からAIと共に行いました。要件の頭出しは自分で行いましたが、それ以降の具体的な要件定義書の作成はCursorを使用して作成しました。
コード実装に関しては完全にCursorに対応してもらいました。「環境構築 -> バックエンド -> フロントエンド」の順で進め、それぞれステップに分けて対応しました。
アプリ概要
ユーザーがアップロードした画像からAIが顔を検出し、座標情報と特徴量を抽出しDBに保持します。
ユーザーが「この顔は〇〇さん」と人物情報を一度設定（アノテーション）すると、以降に新しい画像がアップロードされた際、顔の特徴量を自動的に追跡し、タイムライン形式で履歴を追うことができるフルスタックなアプリです。
技術スタック
全体の技術構成を提示します。
| レイヤー | 採用技術 | 役割 |
|---|---|---|
| フロントエンド | Next.js, Tailwind CSS, Tanstack Query | 画像アップロード、顔アノテーションUI、タイムライン表示 |
| バックエンド | FastAPI（Python） | REST API, 画像処理, InsightFaceの制御 |
| データベース | PostgreSQL + pgvector | ユーザー情報・顔情報・画像情報・顔特徴量ベクトルの保存 |
| ストレージ | MinIO（S3互換） | アップロードされた画像ファイルの保存 |
| AIエンジン | InsightFace | 顔検出 & 特徴量の抽出 |
| インフラ共通 | Docker compose | 各レイヤーを連携させるローカル開発環境構築 |
3. 成果
約一週間やった成果をまとめます。
生成結果
- 画面数：11画面
- API数：18本
- 総コード量：5,336行
- フロントエンド：3,078行
- バックエンド：2,258行
これらはすべてAgentに指示を出して実装されたコードです。
アプリについて
想定要件はすべて動作していますが、ローカルの動作環境の問題もあり、バックエンド側（API, モデル処理）の応答時間に課題が残っています。
クレジットに対するLLM使用量
全体では4%となり、内訳としてはすべてAuto + Composerを使用しました。
4. AI駆動開発をやってみて
良かった点
ローカル環境構築が爆速
Next.js, FastAPI, Postgres, MinIOというコンポーネントを連携させるDocker環境（docker-compose.yml, 各Dockerfile）が一発で生成されました。自分でこの環境を整えるだけでも時間がかかるのでプロジェクト立ち上げのスピードが段違いに早いです。
コンテキスト理解の深さ
最初に要件定義書を作成し、その後は常に要件定義書を参考に製造を行うというルールに設定することで、仕様のズレを感じることなく実装を進められた。
苦労した点
コストの消費感覚の迷い
「どの操作でどれくらいクレジットが減るのか」という感覚が掴めず、迷いからプロンプト作成のスピードが落ちてしまうことがありました。
ルールの理解
全体的なルールやプロジェクト単位のルールを設定することで、LLMから出力される結果が変化します。コスト削減や制度向上にもつながるため、内容調査やルールの作成に時間を割く必要がありました。
進め方の理解
今回はCursorのエディタで作業を進めました。
Agent機能を使用する際、いきなりコードを書かせるのではなく、「Planモード」で作業計画を策定→問題なければ「Agentモード」にファイルを書き込ませる、という流れでなるべく小さいステップで作業を進めました。
理由としては、一気にAgentに作業を投げてAIが間違えた際の手戻り発生のリスクと、無駄にクレジットを使用してしまうことの懸念があったためです。
ただ、この進め方は安全な反面、時間がかかるため、バランスはまだまだ手探りな状態です。
終わりに
初めて0からAIとともに開発を行いましたが、指示をするだけフルスタックアプリが形になりました。
今回はCursorの細かな使い方、ルール策定、コスト計算の調査に手探りで時間を使ってしまいましたが、結果として1週間使ってもクレジットはわずか4〜5%の消費でした。「もっと高頻度にAIを使ってもよかった」というのが反省点です。
今後はAI駆動の特性を理解しつつ、状況に応じてGPT-5.xやSonnet4.6など、他社LLMの特性を切替えた開発も試していきたいと思います。
