05. VibeCoding用のアプリ企画書を作る

リサーチ編（Phase02）の最終章となるこの記事では、これまでに実施した市場調査、ターゲット設定（ペルソナ）、競合分析、そしてMVP機能の選定結果を1つのドキュメントに集約します。

本サイトの推奨プロセスでは、この集約ドキュメントを**「アプリ企画書（仕様書）」**と呼び、プロジェクトのルート直下に SPEC.md という名前のマークダウンファイルとして作成・保存します。

この SPEC.md は、プロジェクトの**「絶対的な憲法（マスタープラン）」**であり、デザインフェーズ（Google Stitch）からコーディングフェーズ（Spec Kit / Antigravity IDE）にわたるすべての工程で、AIエージェントがブレずに開発を行うための基準となります。

この記事のサブコンテンツ

この記事では、AIが誤解なく要件を理解し、手戻りのない開発を行うためのアプリ企画書の作り方を解説します。

VibeCodingにおけるアプリ企画書（SPEC.md）の役割
開発AIが迷わないアプリ企画書（SPEC.md）の標準テンプレート
AIの理解力と実装精度を高める記述のポイント
アプリ企画書（SPEC.md）をAIにインプットする実践手順
リサーチ編（Phase02）の総まとめ
まとめと次のフェーズ（リデザイン編）への橋渡し

1. VibeCodingにおけるアプリ企画書（SPEC.md）の役割

バイブコーディングを進める中で、コードベースや画面構成が大きくなってくると、AIは「元々何を作る目的だったのか」というコンテキスト（目的意識）を忘れがちになります。

そこで、プロジェクトの根幹に SPEC.md を配置しておくことで、以下のような絶大なメリットが得られます。

AIの暴走・不要機能の実装を防ぐ：AIが勝手に「ログイン画面」や「クラウドデータベース連携」を実装しようとするのを防ぎ、MVPのスコープ内に実装を留め置くことができます。
デザインツール（Stitch）との整合性：Stitchに「この SPEC.md に記載された3つの機能を満たす画面案を作って」と伝えるだけで、要件を満たしたワイヤーフレームが生成されます。
デバッグ時の基準点になる：アプリの動作がおかしいとき、AIに「SPEC.md の要件と現在のコードを比較して、不足しているロジックを修正して」と指示することで、正確な修正が行われます。

2. 開発AIが迷わないアプリ企画書（SPEC.md）の標準テンプレート

プロジェクト内に SPEC.md として保存するためのマークダウンテンプレートです。中身をあなたのアプリに合わせて書き換えて使用してください。

# アプリ仕様書 (SPEC.md)

## 1. プロダクト概要
- **アプリ名**: HabitFlow (ハビットフロー)
- **概要**: ログイン不要で、1タップで今日の目標進捗を記録・確認できる極小ミニマリスト習慣トラッカー。
- **独自の価値 (USP)**: 広告ゼロ、サインアップ不要、完全ローカル動作によるプライバシーの保護と、1アクションでの快適な記録体験。

## 2. ターゲットユーザー (ペルソナ)
- **ペルソナ名**: 田中さん (32歳・IT会社員)
- **主要な課題**: 残業が多く帰宅が夜遅いため、日々の自己管理アプリを開くこと自体が億劫になり挫折する。
- **解決したい仕事 (Job)**: 一日の終わりに、疲れていても10秒以内で「今日の小さな努力」を記録し、自己肯定感を得て眠りにつくこと。

## 3. 実装するコア機能 (MVP)
以下の3つの機能のみを初期バージョンとして実装する。

### ① 習慣の登録と一覧表示
- ユーザーは習慣名（例：「読書」「ストレージ」「瞑想」）を入力してリストに登録できる。
- 登録された習慣はダッシュボード画面に一覧でカード形式で表示される。

### ② 習慣の完了トグル（1タップ記録）
- 各習慣カードにある「チェックボタン」をタップすることで、当日の進捗を「完了」「未完了」に切り替えられる。
- 完了時には、カードの背景色やアイコンが視覚的に変化する。

### ③ データのローカル保存（データ永続化）
- アプリを終了したり、端末を再起動したりしても、登録した習慣や過去のチェック履歴が消失しないよう、端末のローカルストレージ（AsyncStorage 等）に保存する。

## 4. 今回は実装しない機能 (Out of Scope / ロードマップ)
以下の機能は、デバッグの無限ループと肥大化を防ぐため、初期実装では**「絶対に実装しない」**こと。
- ユーザー認証・ログイン機能（Googleログイン、Firebase Auth等）
- クラウドデータベース連携（Firestore、Supabase等）
- リマインダープッシュ通知機能
- カレンダー以外の高度な分析グラフ画面

## 5. 技術スタック & 制約
- **フレームワーク**: Expo (React Native) + TypeScript
- **ルーター**: Expo Router (ファイルシステムベースルーティング)
- **データ管理**: AsyncStorage (ローカルキーバリューストア) によるローカル保存
- **デザイン規約**: デザインルールはプロジェクトルートにある `DESIGN.md` のトークンに従う。

3. AIの理解力と実装精度を高める記述のポイント

AIに SPEC.md をインプットする際、以下の書き方を意識することで実装の成功率が跳ね上がります。

「絶対に実装しない機能」を強調する：AIは親切心から「データベース連携があったほうが便利ですよ」と勝手に実装を始めがちです。「今回は実装しない（Out of Scope）」という項目を太字や警告形式で明記し、AIを枠内に縛り付けます。
データモデルの定義を簡潔に書く：AIがデータベース設計で迷わないよう、扱うデータのスキーマ（形）を記述しておくと親切です。
- 例: Habit = { id: string, name: string, isCompletedToday: boolean, createdAt: string }
外部依存を減らす技術制約を書く：「完全ローカル動作（AsyncStorage使用）」と書いておくことで、不要なSDKのインストールを防ぎます。

4. アプリ企画書（SPEC.md）をAIにインプットする実践手順

作成した SPEC.md は、以下のように開発工程の各ステージでAIに見せて活用します。

ステージ①：デザインフェーズ（Google Stitch）での利用

Stitchでワイヤーフレームを作る際、以下のプロンプトを投げます。

「ルート直下にある SPEC.md を読み込んでください。そこに定義されているターゲットペルソナと3つのMVP機能に基づき、ダッシュボード画面の画面案を作成してください。」

ステージ②：コーディングフェーズ（Spec Kit）での利用

開発AIにコーディングを依頼する際、以下のプロンプトを投げます。

「プロジェクトルートの SPEC.md に記載されている要件に基づき、習慣一覧画面とチェック機能のTypeScriptコードを実装してください。Out of Scopeに指定されているログイン機能等は実装しないでください。」

ステージ③：CLAUDE.md等との連携

CLAUDE.md やIDEの「Rules」に以下を追加します。

- アプリ全体の機能要件、およびMVPスコープについては、常にプロジェクトルートにある SPEC.md をマスターソースとして参照し、その範囲内でコードを記述すること。

5. リサーチ編（Phase02）の総まとめ

これで、リサーチ編（Phase02）の全5記事が完了しました！ここまでの学習プロセスを振り返りましょう。

市場調査の実施：01. Google Deep Researchでアプリのアイデアを調べるで、自律AIを使って市場のトレンドや不満点を調査しました。
ペルソナの策定：02. AIと一緒にターゲットユーザーを決めるで、具体的なターゲット像と、ユーザーが真に解決したいJobを言語化しました。
競合の弱み分析：03. 競合アプリのレビューから改善アイデアを見つけるで、既存アプリの不満の声から自社アプリ独自の強み（USP）を導き出しました。
MVP機能の絞り込み：04. 最初に作る機能を3つに絞るで、開発初期の肥大化を防ぐために、実装する機能を3つに厳しく限定しました。
仕様書の集約：05. VibeCoding用のアプリ企画書を作る（この記事）で、すべての決定事項を SPEC.md という1枚の憲法にまとめ上げました。

6. まとめと次のフェーズ（リデザイン編）への橋渡し

完璧な SPEC.md がプロジェクトルートに配置されたことで、アプリ開発の「目的」と「やること・やらないこと」が100%クリアになりました。

次からは、この SPEC.md をデザインの形に変えていく「Phase03：リデザイン編（仮）」に入ります。Google Stitchを使い、仕様書を行動可能な画面デザインやユーザー導線（プロトタイプ）へと具体化させていきましょう！

さっそく、リデザイン編の第1歩である「01. Google Stitchでアプリの画面案を作る」へ進みましょう。