# Cursorを使ったワークフロー：アイデアからデプロイまで

[English](../en/15-cursor-workflow-from-idea-to-deploy-en.md) · [繁中](../zh/15-cursor-workflow-from-idea-to-deploy-zh.md) · [Español](../es/15-cursor-workflow-from-idea-to-deploy-es.md) · [日本語](../jp/15-cursor-workflow-from-idea-to-deploy-jp.md) · [Português (BR)](../pt-br/15-cursor-workflow-from-idea-to-deploy-pt-br.md)

**著者：** Danko Peng（[@dankopeng](https://x.com/dankopeng)）  
**更新：** 2026年3月  
**読了時間：** 約8分

-----

## 理論より実践

これまでの記事でVibe Codingの概念、ツール、セキュリティ、相談の仕方を説明してきた。この記事では、実際に1つの機能を開発するフローを最初から最後まで追ってみる。

使う例：**在庫不足警告機能**——在庫が設定した閾値を下回ったときに管理者にメール通知する機能。

-----

## ステップ1：要件を整理する（5分）

コードを一行も書く前に、何を作るかを言葉にする。

```
在庫不足警告機能を実装したいです。先にコードは書かないでください。

要件：
- 商品の在庫が10個以下になったら管理者にメール通知
- 通知は1商品につき1日1回まで（頻繁すぎる通知を防ぐ）
- 管理者のメールアドレスは環境変数で設定
- メール送信はResendを使用（vibefast.appに統合済み）

現在のデータベース：
- products テーブルに stock カラムがある
- orders テーブルが存在する

この要件で理解した点と、実装前に確認すべき点を教えてください。
```

### AIの返答から学ぶ

AIがいくつかの質問を返してくるだろう：

- 「在庫が10個以下になったとき、という判定はいつ行いますか？注文完了時？定期チェック？」
- 「同じ商品で在庫が10→9→8と毎回減っていくとき、毎回通知しますか？」
- 「管理者が複数いる場合は全員に送りますか？」

これらの質問が重要だ。答えることで要件が明確になる。

**回答例：**
```
良い質問です。整理します：

- 判定タイミング：注文完了時（Stripe Webhookの payment_intent.succeeded 処理後）
- 同じ商品の連続通知：在庫が閾値を下回った最初の1回だけ通知（その後は在庫が回復して再度下がったときのみ）
- 管理者：単一のメールアドレス（環境変数 ADMIN_EMAIL）

この仕様でD1のテーブル設計と実装方針を提案してください。
```

-----

## ステップ2：設計を確認する（10分）

AIが設計案を出す：

```
提案された設計：

テーブル：stock_alerts
- id
- product_id
- alerted_at（最後に通知した日時）

APIの変更：
- Webhook処理の中で在庫チェックロジックを追加
- stock_alertsテーブルで「今日すでに通知済みか」を確認
- 未通知 or 前回通知から24時間以上経過している場合にメール送信

この設計を確認してください。
問題があれば指摘してください。問題なければ実装を進めます。
```

設計を確認し、納得できたら実装の承認を出す：

```
設計でOKです。実装を進めてください。
まず stock_alerts テーブルのマイグレーションSQLから始めてください。
```

-----

## ステップ3：段階的に実装する（30-60分）

一度に全部実装させるのではなく、段階的に進める：

**段階1：データベース**
```
stock_alerts テーブルのマイグレーションSQLを生成してください。
```

→ SQLを確認して実行

**段階2：在庫チェックのロジック**
```
在庫チェックとアラート判定のロジックを実装してください。
関数として独立させてください（テストしやすいように）。
Webhook処理本体はまだ変更しないでください。
```

→ コードを確認、ロジックが正しいか確認

**段階3：Webhook処理に組み込む**
```
前に作った在庫チェック関数を、Stripe Webhookの処理に組み込んでください。
payment_intent.succeeded の処理が完了した後に呼び出してください。
```

→ 変更されたファイルを確認

**段階4：メール送信**
```
在庫不足のメール通知を Resend で送る実装を追加してください。
メールのテンプレートは：
件名：[在庫警告] {商品名} の在庫が残り {在庫数} 個になりました
本文：商品名、現在の在庫数、管理画面へのリンク
```

-----

## ステップ4：ローカルでテストする（15分）

実装が完了したら、必ずローカルでテストする：

```bash
npm run dev
```

テスト手順をAIに聞く：
```
実装した在庫不足警告機能をローカルでテストする方法を教えてください。
Stripe Webhookのローカルテストと、
実際に在庫が減った場合のシミュレーション方法も含めてください。
```

テストが通れば次のステップへ。通らなければデバッグ（次の記事で詳しく説明する）。

-----

## ステップ5：コミットしてデプロイする

テストが通ったら：

```bash
git add .
git commit -m "在庫不足警告機能を実装：閾値10個以下で管理者メール通知"
npm run deploy
```

デプロイ後、本番環境でも確認する。

-----

## このワークフローで大切な習慣

**1. 一度に1つの変更**

「在庫通知 + メール履歴 + 通知設定画面を全部実装して」という依頼は避ける。一度に多くの変更を加えると、何かが壊れたときにどこが原因かわからなくなる。

**2. 各ステップでコードを確認する**

AIが生成したコードを全く見ずに次のステップに進まない。コードが何をしているかを理解してから承認する。理解できない部分があれば「このコードが何をしているか説明してください」と聞く。

**3. ローカルで確認してからデプロイ**

「とりあえずデプロイしてみて確認」は避ける。ローカルで動かないものはデプロイしても動かない。ローカルのテストを省かない。

**4. こまめにコミット**

各ステップが完了したらコミットする。問題が起きたときに前の状態に戻れる。

-----

## 実際の時間配分

この機能（在庫不足警告）の実際の開発時間：

```
要件整理（AIと相談）：5分
設計確認：10分
実装（段階的）：45分
ローカルテスト：20分
バグ修正：15分（あれば）
コミット・デプロイ：5分
本番確認：10分

合計：約2時間
```

「全部一気に実装して」とやった場合、最初は速く見えるが、後でバグを追うのに2-3時間余分にかかることが多い。段階的にやる方が結果として速い。

-----

**Danko Peng**  
[X](https://x.com/dankopeng) · [YouTube](https://www.youtube.com/@DankoPeng) · [Threads](https://www.threads.com/@dankopeng)

-----

👉 [チュートリアルトップに戻る](../README-jp.md)

完全なCloudflareフルスタックテンプレートを今すぐ使い始めたい方へ：  
👉 **[vibefast.app](https://vibefast.app/pricing)** — アーリーバード $99、2026年8月1日より $199 に値上がり。