【初心者】Cursorで「家計簿アプリ」を爆速開発②|AI駆動開発のコツを公開

目次

この記事で分かること

プログラミングができないから、アプリを開発するのは無理…

そんな常識が、AI技術の進歩によって覆されています。今では、プログラミング未経験の方でも、AIを相棒にすることで本格的なアプリ開発が可能になりました。

この記事では「家計簿アプリ」を題材にして、AI駆動開発の具体的な方法を分かりやすく解説します。

プログラミング未経験の方も、この記事を参考にしでアプリ開発にトライしてみてください!

この記事のポイント
  • コーディング作業を全てAIに任せる具体的な方法
  • 開発の手戻りが発生しづらくするための工夫
  • 家計簿アプリの設計内容

Cursorとは?

AI駆動開発に欠かせないツールが「Cursor」です。

このツールを一言で説明するとAIがコードを書いてくれる魔法のエディタ」です。

エディタとは?
  • エディタは、テキストファイルやコードを作成・編集するためのソフトウェアです。
  • メモ帳のようなシンプルなものから、Visual Studio CodeやVimのような高機能なものまで様々な種類があります。

従来のプログラミングでは、エラーが出るたびに検索して解決策を探したり、複雑な文法を覚えたりする必要がありましたが、Cursorなら日本語で「〇〇を作って」と指示するだけで、AIが実際に動くコードを生成してくれます。

Cursorの特徴

  • 自然言語での指示が可能:
    • 「ログイン画面を作って」「データベースに保存する機能を追加して」など、普通の会話でコードを作成
  • リアルタイムでのコード修正:
    • エラーが発生しても、AIが瞬時に原因を特定し、修正案を提示
  • 既存コードの理解:
    • プロジェクト全体を把握して、一貫性のあるコードを生成
  • 多言語対応:
    • Python、JavaScript、HTML/CSSなど、様々なプログラミング言語に対応

Cursorの料金プラン

Cursorには以下の料金プランがあります:

  • 無料プラン:
    • 基本的な機能を体験可能(月間利用制限あり)
  • Proプラン(月額20ドル):
    • 本格的な開発に必要な機能がフル活用可能
  • Urtraプラン(月額200ドル):
    • 最高性能のAI機能を提供する最上位プラン

実際の開発ではProプランの利用をおすすめします。

無料プランでは月間の利用制限があるため、継続的な開発作業には向いていません。Proプランなら、AIとの対話回数を気にせず、思う存分アプリ開発に集中できます。

また、Proプランには2週間の無料トライアルが用意されています。なので、まずはこのトライアルで実際にAI駆動開発の威力を体験してみることをおすすめします。2週間あれば、簡単なアプリを一つ完成させることも十分可能です。

実際に開発したアプリ

ここからは、Cursorで開発した「家計簿アプリ」を解説します。

[概要]
個人の収支管理を効率化するWebアプリ

[解決したい課題]
・家計簿を続けたいけど、取引入力が手間
・支出の目標を設定して、その月の支出を評価して支出削減に繋げたい

[使用ツール]
Cursor, GitHub

[プログラミング言語]
JavaScript(React)

実際に開発した「家計簿アプリ」

開発したタスク管理アプリはWeb公開しているので、お気軽にアクセスしてみてください。

機能①:取引登録機能

「お金の出入りを簡単に記録」

機能説明
  • 金額入力:
    • 電卓形式で金額を入力できる簡単操作
  • カテゴリ選択:
    • 「食費」「交通費」「娯楽費」などをドロップダウンで選択
  • メモ機能:
    • 「◯◯スーパーで買い物」などの詳細を記録
  • 日付選択:
    • カレンダーから直感的に選択可能

機能②:ダッシュボード

「家計の状況を一目で把握」

機能説明
  • 今月の収支:
    • 収入と支出の差額を大きく表示
    • カレンダー形式で日にち毎の収支を表示
  • 予算との比較:
    • 設定した予算に対する達成率を表示
  • 収支の推移:
    • 収支の過去推移を折れ線グラフで表示
    • 表示期間は「6か月・1年・全期間」から選択可能

機能③:収支リスト

「過去の取引を管理・編集」

機能説明
  • 全取引の一覧表示:
    • 日付順で整理された見やすいリスト
  • 絞り込み:
    • 期間で絞り込み可能
  • 編集機能:
    • 間違った入力をその場で修正
  • 削除機能:
    • 不要な取引を安全に削除

機能④:カテゴリ管理

「自分に合ったカテゴリをカスタマイズ」

機能説明
  • デフォルトカテゴリ:
    • 「食費」「住居費」「交通費」など基本的なカテゴリを用意
  • カスタムカテゴリ:
    • 「ペット費」「習い事費」など個人に合わせて追加可能
  • カテゴリの編集・削除:
    • 不要なカテゴリの整理が可能
  • 色設定:
    • 各カテゴリに分かりやすい色を設定可能

機能⑤:予算設定

「目標を決めて計画的な家計管理を実現」

機能説明
  • 月別予算設定:
    • カテゴリごとに月の予算を設定
  • 予算の進捗表示:
    • 現在の支出が予算の何%かを表示
  • アラート機能:
    • 予算の80%に達したら通知
  • 予算vs実績比較:
    • 月末に予算と実際の支出を比較

開発で実感したAI駆動開発の威力

このアプリを開発する過程で、「コードを書く」という作業が一切ありませんでした。私がやったのは以下のような作業だけです:

  1. 「家計簿アプリに必要な機能を教えて」とAIに相談
  2. 「取引登録画面を作って」とAIに指示
  3. 「グラフがうまく表示されない」とAIに相談
  4. 「スマートフォンでも見やすくして」とAIに改善依頼

まさに「アイデアを言葉で伝えるだけ」でアプリが完成していく体験は、従来のプログラミングとは全く異なる新しい開発スタイルでした。

次の章では、この開発過程で学んだ「AIに効果的に指示を出すコツ」について詳しく解説していきます。あなたも同じ手法を使えば、きっと想像以上に簡単にアプリを作ることができるはずです。

Cursorを活用した開発のコツ

実際の開発経験から言えることは、最初の準備がプロジェクトの成功を左右するということです。料理でいう「下ごしらえ」のように、開発でも事前準備が重要なのです。

コツ①:プロジェクトルールの作成

プロジェクトルールは、いわばAIへの「取扱説明書」のようなもので、一度設定すれば開発全体を通してAIが一貫した高品質なコードを生成してくれます。

プロジェクトルールは.cursor/rulesディレクトリに保存します。(拡張子は.mdc

プロジェクトルールの適用タイミング

ファイル毎にルールタイプを設定でき、それによって適用されるタイミングが異なります:

  1. Always(常時適用)
    • 常にモデルのコンテキストに含まれる。
    • チャットやインライン編集を使用する際に、自動的に適用される。
  2. Auto Attached(自動添付)
    • 指定されたglobパターンにマッチするファイルが参照された時に適用される。
    • 例:*.tsパターンのルールは、TypeScriptファイルを扱う際に自動的に適用。
  3. Agent Requested(エージェント要求)
    • AIが必要と判断した時に自動的に含まれる。
    • 説明(description)が必要で、AIがその説明を基に関連性を判断。
  4.  Manual(手動)
    • @ruleNameで明示的に言及された時のみ適用される。
    • 手動で呼び出すまで適用されない。

以降では、タスク管理アプリを開発した際に作成した、プロジェクトルールの設定内容を解説します。

1. コーディング規約

「どんなコードを書いてほしいか」をAIに伝える

---
description: 
globs: 
alwaysApply: true
---
# コーディング規約

## 全般
- TypeScriptを使用し、型定義を厳密に行う
- ESLintとPrettierを使用してコードの品質とフォーマットを統一
- コメントは日本語で記述

## 命名規則
- コンポーネント: PascalCase (例: `ExpenseList.tsx`)
- 関数・変数: camelCase (例: `getMonthlyTotal`)
- 定数: SNAKE_CASE (例: `MAX_AMOUNT`)
- インターフェース: 接頭辞に`I`をつける (例: `IExpense`)
- 型定義: 接頭辞に`T`をつける (例: `TCategory`)

## コンポーネント
- 関数コンポーネントとHooksを使用
- Props型は必ず定義
- コンポーネントは単一責任の原則に従う
- 再利用可能なコンポーネントは`components/common`に配置

## スタイリング
- CSS Modulesを使用
- レスポンシブデザインはモバイルファーストで実装
- カラーコードは変数化して管理

## テスト
- Jest + React Testing Libraryを使用
- コンポーネントの主要機能は必ずテストを作成
- テストファイルは実装ファイルと同じディレクトリに配置

効果:
• AIが生成するコードの品質が安定する
• 後から見返した時に理解しやすいコードになる
• バグが発生しにくい堅牢なコードが生成される

適用タイミング:
Always(常時適用)

2.プロジェクト概要

「どんな構造でアプリを作ってほしいか」をAIに伝える

---
description: 
globs: 
alwaysApply: true
---
# プロジェクト構造

## ディレクトリ構成
```
src/
├── components/          # コンポーネントディレクトリ
│   ├── common/         # 共通UIコンポーネント
│   │   ├── Button/
│   │   ├── Input/
│   │   ├── Modal/
│   │   └── Card/
│   ├── expense/        # 支出関連コンポーネント
│   │   ├── ExpenseForm/
│   │   ├── ExpenseList/
│   │   └── ExpenseItem/
│   ├── income/         # 収入関連コンポーネント
│   │   ├── IncomeForm/
│   │   ├── IncomeList/
│   │   └── IncomeItem/
│   ├── budget/         # 予算関連コンポーネント
│   │   ├── BudgetForm/
│   │   └── BudgetChart/
│   └── analysis/       # 分析関連コンポーネント
│       ├── MonthlyReport/
│       └── CategoryAnalysis/
├── pages/              # ページコンポーネント
│   ├── Dashboard/
│   ├── Expenses/
│   ├── Income/
│   ├── Budget/
│   └── Analysis/
├── hooks/              # カスタムフック
│   ├── useExpense.ts
│   ├── useIncome.ts
│   └── useBudget.ts
├── store/              # Redux関連
│   ├── actions/
│   ├── reducers/
│   └── types/
├── utils/              # ユーティリティ関数
│   ├── calculations.ts
│   ├── formatters.ts
│   └── validators.ts
├── types/             # 共通の型定義
│   └── index.ts
├── styles/            # グローバルスタイル
│   ├── variables.css
│   └── global.css
└── assets/           # 画像やアイコンなど
    ├── images/
    └── icons/
```

## 主要ファイル
- [src/App.tsx](mdc:src/App.tsx): アプリケーションのルートコンポーネント
- [src/index.tsx](mdc:src/index.tsx): エントリーポイント
- [package.json](mdc:package.json): 依存関係の管理
- [tsconfig.json](mdc:tsconfig.json): TypeScript設定

## ファイル命名規則
- コンポーネント: `ComponentName.tsx`
- スタイル: `ComponentName.module.css`
- テスト: `ComponentName.test.tsx`
- カスタムフック: `useHookName.ts`
- 型定義: `types.ts`



実際の効果:
• プロジェクト全体で一貫した構造が保たれる
• 新しい機能を追加する時も迷わない
• ファイルの場所が予測しやすくなる

適用タイミング:
Always(常時適用)

3.要件定義

「どんなアプリを作りたいか」をAIに伝える

---
description: 
globs: 
alwaysApply: true
---
# プロジェクト概要

## 目的
家計の収支を簡単に管理・分析ができるようになることで、優先度の低い支出を明らかにし、
限られた収入の中で家計を最適化できるようになる。

## ゴール
- ユーザーが収支を簡単に記録・管理できる
- 収支の傾向を視覚的に分析できる
- 予算管理と支出の最適化をサポートする

## 主要タスク
1. 基本機能の実装
   - 収支の記録・編集・削除機能
   - カテゴリ管理機能
   - 月次予算設定機能

2. 分析機能の実装
   - 月次レポート生成
   - グラフ表示機能
   - 予算達成状況の可視化

3. UI/UX改善
   - レスポンシブデザイン対応
   - アクセシビリティ対応
   - パフォーマンス最適化

## 進捗管理
- 詳細な作業項目と進捗状況は[progress.md](mdc:progress.md)で管理
- 作業状態は以下の4段階で管理:
  - ❌ 未着手:まだ作業を開始していない状態
  - ⏳ 待機中:依存タスクの完了待ちなどの状態
  - 🔄 進行中:現在作業を実施している状態
  - ✅ 完了:作業が完了し、レビューも通過した状態

- 作業フロー:
  1. 新規タスク着手時は`progress.md`で作業内容を確認
  2. 作業開始時にステータスを更新(❌→🔄)
  3. 作業完了時にステータスを更新(🔄→✅)
  4. 依存タスクがある場合は待機状態に更新(🔄→⏳)

実際の効果:
• AIが機能の目的を理解して適切なコードを生成
• 一貫したユーザー体験が実現される
• 開発途中で方向性がブレなくなる

適用タイミング:
Always

④コンポーネント構造

Reactでコンポーネントを整理整頓するルールをAIに伝える

---
description: 
globs: 
alwaysApply: true
---
# コンポーネント構造

## 基本構造
```tsx
// インポート
import React from 'react';
import styles from './ComponentName.module.css';

// 型定義
interface IComponentProps {
  // propsの型定義
}

// コンポーネント
export const ComponentName: React.FC<IComponentProps> = (props) => {
  // ステートとフック
  // イベントハンドラ
  // 副作用
  // レンダリング
};
```

## コンポーネントの分類

### ページコンポーネント
- URLに紐づくメインコンポーネント
- ルーティング、データフェッチ、状態管理を担当
- 配置: `src/pages/`

### 機能コンポーネント
- 特定の機能を持つ再利用可能なコンポーネント
- 例: ExpenseForm, BudgetChart, IncomeList
- 配置: `src/components/{domain}/`

### 共通コンポーネント
- UIの基本要素として再利用可能なコンポーネント
- 例: Button, Input, Modal, Card
- 配置: `src/components/common/`

## データフロー
- Reduxを使用して全体の状態を管理
- コンポーネント間のデータ受け渡しはpropsを使用
- グローバルな状態変更はアクションを介して実行

## エラー処理
- try-catchでエラーをハンドリング
- エラー状態はErrorBoundaryで管理
- ユーザーフレンドリーなエラーメッセージを表示

## 画面実装ルール
- 画面実装の際は必ず`ワイヤーフレーム.drawio`を参照すること
- ワイヤーフレームと異なる実装が必要な場合は、チームで協議の上で変更を決定
- レスポンシブ対応については、ワイヤーフレームの各ブレイクポイントの指示に従うこと
- コンポーネントの配置や余白は、ワイヤーフレームの指示を厳守

実際の効果:
・ コードが探しやすくなる
・同じものを何度も作らなくて済む

適用タイミング:
Always

コツ②:開発の進捗管理ファイルの作成

開発作業の進捗管理を行うファイルを作成することで、開発の迷子状態を防ぎ、効率的に進めることができます。

今回の開発では、progress.mdファイルを作成し、AIに指示を出した後に開発進捗を記録・更新させるようにします。

# 進捗管理

## 作業状態の定義

- ✅ 完了:作業が完了し、レビューも通過
- 🔄 進行中:現在作業を実施中
- ⏳ 待機中:依存タスクの完了待ちなど
- ❌ 未着手:まだ作業を開始していない

## 1. 基盤構築

- ✅ プロジェクト初期化(Create React App + TypeScript)
- ✅ ESLint + Prettier の設定
- ✅ 必要なパッケージのインストール
  - TypeScript 関連(@types/\*)
  - Redux 関連(@reduxjs/toolkit, react-redux)
  - ルーティング(react-router-dom)
  - スタイリング(tailwindcss, @emotion/react)
  - テスト(jest, @testing-library/\*)
- ✅ 環境変数の設定(.env)
- ✅ エラー処理の基盤実装
- ✅ ローディング状態の基盤実装

## 2. アプリケーション設計

- ✅ ディレクトリ構造の作成
- ✅ グローバルスタイルの設定
- ✅ ルーティング設計
- ✅ Redux ストアの設計
  - ✅ State 型定義
  - ✅ Slice 設計
  - ✅ Store 設定
- ✅ 共通型定義(収支、予算、カテゴリ等)
- ✅ API クライアントの実装(LocalStorage 用)

## 3. 共通コンポーネントの実装

- ✅ デザインシステムの定義
  - 色・フォント・スペーシング
  - コンポーネントの振る舞い
- ✅ Button コンポーネント
- ✅ Input コンポーネント
- ✅ Modal コンポーネント
- ✅ Card コンポーネント
- ✅ Form コンポーネント
- ✅ 共通コンポーネントのテスト作成
- ✅ Navigation コンポーネント
  - ✅ PC/スマホ対応レイアウト
  - ✅ アクティブ状態の表示
  - ✅ スマホ用追加ボタン
    - ✅ ボタンの配置
    - ✅ 取引登録フォームの表示

## 4. 画面実装

### 4.1 ダッシュボード画面

- ✅ 今月の収支サマリー
  - ✅ 収入・支出・収支バランスの表示
  - ✅ 予算達成状況の表示
- ✅ カレンダー形式での収支表示
  - ✅ 日別収支金額の表示
  - ✅ 収支バランスの色分け表示
  - ✅ 日付クリックで詳細表示
- ⏳ 収入・支出・収支の推移グラフ

### 4.2 収支管理画面

- ✅ 取引一覧表示
  - ✅ 日付でのグループ化表示
  - ✅ 金額、メモ、カテゴリの表示
  - ✅ レスポンシブデザイン対応
- ✅ 取引の登録・編集
  - ✅ 収入/支出切り替え
  - ✅ 日付選択
  - ✅ カテゴリ選択
  - ✅ 金額入力(電卓スタイル)
  - ✅ メモ入力
  - ✅ バリデーション実装
- ✅ 取引の削除
  - ✅ 削除確認ダイアログ
- ✅ 月次表示切替
  - ✅ 前月・翌月ナビゲーション
  - ✅ 今月へのショートカット

### 4.3 予算管理画面

- ✅ 月次予算の設定
  - ✅ カテゴリ別予算の設定
  - ✅ 予算の追加・編集・削除機能
  - ✅ 予算サマリーの表示
  - ✅ バリデーション実装
  - ✅ エラーハンドリング

### 4.4 カテゴリ管理画面

- ✅ カテゴリ一覧
  - ✅ 収入・支出カテゴリの分類
  - ✅ カテゴリの並び替え
  - ✅ カテゴリの有効/無効切替
- ✅ カテゴリの登録・編集
  - ✅ カテゴリ名の設定
  - ✅ 収入/支出の分類
  - ✅ 予算管理有無の設定
- ✅ カテゴリの削除
  - ✅ 削除確認ダイアログ
  - ✅ 関連データの処理

作成することで得られるメリット:
・作業の見える化
・モチベーション維持
・問題解決の効率化

今回開発の振り返り

実際にAI駆動開発でアプリを作ってみて、「これは良かった!」と「次回はこうしよう」という点がはっきりと見えてきました。

次回の開発では、良い点は継続・悪い点は改善することで、より効率的なAI駆動開発を目指していきます。
本記事を読んでいる方も、開発時には以降の内容を参考にしてもらえると嬉しいです。

良かった点:設計内容をプロジェクトルールに記載したこと

今回最も効果的だったのは、開発したいアプリの設計内容をプロジェクトルール(AIに指示を与えるためのファイル)に詳しく記載したことです。 

なぜこれが良かったのか

  • 自分自身のイメージが明確になった
    • 「何を作りたいか」を文字にして整理することで、自分の中で曖昧だった部分がはっきりしました。
    • AIに説明するために考えを整理する過程で、「本当に必要な機能は何か」「どんな見た目にしたいか」が明確になります。
  • AIの回答の良し悪しが判断できるようになった
    • 設計を明文化していたおかげで、AIが作ったコードが「求めていたものに近いか」「方向性が間違っていないか」を判断できました。
    • プログラミング未経験でも、「これは違う」「これは良い」という感覚が持てるようになります。
  • AIが大きく方向性を外すことが少なかった
    • 詳細な設計が書いてあることで、AIが全く違うものを作ってしまうリスクを大幅に減らせました。
    • 「タスク管理アプリを作りたい」と伝えるより、「ドラッグ&ドロップでステータス変更できるタスク管理アプリ」と具体的に伝える方が、期待通りの結果が得られやすいのです。

改善点:プロジェクトルールが読み込まれていない

一方で、開発が進むにつれて気になったのが、AIがプロジェクトルールの内容を忘れているような動作をすることが多々あったことです。

具体的に起こった問題

  • 開発後半になると、最初に設定したデザインルールと異なるコードを提案してくる
  • 既に決めていた機能の仕様を無視した修正提案をしてくる
  • 一貫性のないコードスタイルになってしまう

次回への改善案

この問題を解決するために、次回はプロジェクトルールに「ファイルが読み込まれたことを確認する出力」を追加する予定です。

具体的には、AIに「最初に必ず『Read xxx.mdc』と出力してから回答する」ような指示を入れることで、ルールが適用されているかどうかを毎回確認できるようになります。この対応によって、プロジェクトルールが読み込まれていない場合は開発者側から指摘できるようになるので、解決が期待できます。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次