❤️

あったらいいなを3時間でプロトタイプ作成

2025/05/16に公開

アイデアがカタチになる、って感動体験ですね！
それを共有したく、本記事を書きます。

やったこと / 使用したツール

やったこと	使用したツール	費用
要求整理	Gemini 2.5 Pro	無料枠
システム要件	Gemini 2.5 Pro	無料枠
システム設計	Gemini 2.5 Pro	無料枠
プロトタイプ作成	Claude 3.7 Sonnet	無料枠

Step1. 漠然としたイメージを殴り書きする。

（詳細は、要求整理.mdを参照）

要求整理.md

(目的)
　・人を勇気づけたい。
　・そのためにも、その日感じた小さな幸せを、しっかりとかみしめる。
　
(手段)
　・vibe codingでつくってみたい。
　・スマートフォンアプリでつくってみたい。

(実現したいことイメージ)
<ユーザー>
・ログイン（グーグル認証）
　・カレンダー選択し、その日に幸せに感じたことを記録（新規登録、更新、削除）
　・自分専用の幸せに感じることをマスタ情報登録
　・ダッシュボードで月ごとに自分が幸せに感じたことのベスト3が確認できる
　・ダッシュボードで月ごとに自分が幸せに感じた日のベスト3が確認できる
　
<システム管理者>
・幸せに感じることをマスタ情報登録
・ログイン（グーグル認証）

Step2. Geminiに要求整理.mdをプロンプトにて伝え、Geminiからの質問に回答する。

要求の壁打ち

Step3. Geminiにてシステム要件.mdを出力する。

Geminiへの依頼風景

システム要件.md

 1. アプリの目的ユーザーが日々の小さな幸せを記録し、それを振り返ることで自己肯定感を高め、

勇気づけられることを目指す。

 2. ターゲットユーザー個人利用がメイン（他者との情報共有機能はなし）。

 3. プラットフォームスマートフォンアプリ（Android）

 4. 主な機能
 4.1. ユーザー認証Googleアカウントによるログイン機能を提供する。
アカウント削除（退会）機能を提供する。

 4.2. 幸せマスタ管理ユーザー作成マスタ:
ユーザーは「幸せに感じる項目」（例：「美味しいコーヒーを飲んだ」）を自由に作成、編集、削除できる。
登録可能な「幸せの項目」の上限は100個までとする。
管理者提供マスタ:
システム管理者は、一般的な「幸せのサンプル項目」を事前に登録しておく。
ユーザーはこれらのサンプル項目を選択して利用できる。
ユーザーによるサンプル項目の編集は不可とする。
ユーザーは、自身のマスタリストから管理者提供のサンプル項目を非表示にする機能を持つ。

 4.3. 日々の幸せ記録カレンダーで日付を選択して記録を開始する。過去の日付への記録も可能とする。未来の日付への記録は不可とする。
記録フロー:
マスタ項目選択: ユーザー作成マスタ、または管理者提供マスタ（非表示にしていないもの）の中から、記録したい「幸せの項目」を選択する。
新規マスタ項目作成: 該当するマスタ項目がない場合は、その場で新しい「幸せの項目」をユーザー作成マスタとして登録し（上限100個以内）、それを使用できる。
気分の選択とポイント付与: 選択/作成したマスタ項目に対し、以下の3段階の「気分」を選択する。気分に応じてポイントが自動的に記録される。
「とても幸せ」：5ポイント
「幸せ」：3ポイント
「ちょっと幸せ」：1ポイント
エピソード入力: その幸せに関する具体的なエピソードをテキストで入力する（文字数上限:300文字）。
記録した内容は後から更新、削除が可能とする。

 4.4. ダッシュボード毎日、当月分のデータが自動集計されて表示される。
今月の幸せ項目ベスト3:
集計対象: ユーザーが記録時に選択/作成した「幸せマスタ項目」ごと。
集計方法: 各マスタ項目に紐づく記録のポイントの月間合計値でランキング。同ポイントの場合の扱いや3件未満の場合の表示は別途検討。
表示内容: マスタ項目名と、その合計ポイント数。
今月の幸せ日ベスト3:
集計対象: 日ごと。
集計方法: 1日に記録された全ての幸せ記録のポイントを合計し、その日の総合ポイントでランキング。同ポイントの場合の扱いや3件未満の場合の表示は別途検討。
表示内容: 日付と、その日の合計ポイント数。

 4.5. カレンダー表示日々の幸せ記録機能で利用するカレンダーにおいて、幸せを記録した日付には、小さなハートマークなどの視覚的な印を表示する。

 4.6. データ管理ユーザーが記録した「幸せの項目」、「日々の幸せ記録」、「ポイント」などのデータは、ユーザーのGoogleアカウントに紐づけてサーバー側で安全に保管する。
機種変更時にも、同じGoogleアカウントでログインすることでデータが引き継がれるようにする。
データのエクスポート機能は不要とする。

 5. 通知機能毎日決まった時間に幸せの記録を促すリマインダー通知機能は不要とする。

 6. デザインシンプルで温かみのあるデザインを目指す。

 7. その他検討事項利用規約・プライバシーポリシーの作成とアプリ内での明示。
アクセシビリティ（フォントサイズ変更、スクリーンリーダー対応など）への配慮。

Step4. Geminiにてシステム設計.mdを出力する。

Geminiへの依頼風景

システム設計.md

 1. システムアーキテクチャ本システムは、以下のコンポーネントから構成されるクライアントサーバーアーキテクチャを採用します。
クライアントサイド（Androidアプリ）:
ユーザーインターフェース（UI）の提供
ユーザー入力の受付
サーバーAPIとの通信（リクエスト送信、レスポンス受信・表示）
ローカルでの一時的なデータ保持（必要な場合）
Googleアカウント認証のフロントエンド処理
サーバーサイド（バックエンドAPI）:
ビジネスロジックの実装
データベースとの連携（データの永続化、取得）
ユーザー認証（Google IDトークンの検証）
各種APIエンドポイントの提供
データベース（DB）:
ユーザー情報、幸せマスタ、日々の幸せ記録などのデータを永続的に保管
データの整合性、一貫性を担保
外部サービス連携:
Google認証サービス: Googleアカウントによる認証のため

 2. データベース設計（主要エンティティと属性）以下に主要なエンティティ（テーブル）とその主な属性を示します。リレーションシップも考慮します。
Users (ユーザー)

user_id (PK, UUID or Auto Increment) : ユーザーID（システム内部識別子）

google_id (UNIQUE) : Googleアカウント識別子

email (VARCHAR) : メールアドレス（Googleアカウントから取得）

display_name (VARCHAR) : 表示名（Googleアカウントから取得）

created_at (TIMESTAMP) : 作成日時

updated_at (TIMESTAMP) : 更新日時
HappinessMasters (幸せマスタ)

master_id (PK, UUID or Auto Increment) : マスタID

content (TEXT) : 幸せの項目内容 (例: 「美味しいコーヒーを飲んだ」)

is_admin_provided (BOOLEAN) : 管理者提供フラグ (true: 管理者提供, false: ユーザー作成)

created_by_user_id (FK to Users.user_id, NULLABLE) : 作成ユーザーID (管理者提供の場合はNULL)

created_at (TIMESTAMP) : 作成日時

updated_at (TIMESTAMP) : 更新日時

deleted_at (TIMESTAMP, NULLABLE) : 削除日時 (論理削除用、ユーザー作成マスタの場合)
UserHiddenAdminMasters (ユーザー非表示管理者マスタ)

user_id (PK, FK to Users.user_id) : ユーザーID

master_id (PK, FK to HappinessMasters.master_id where is_admin_provided = true) : 管理者提供マスタID

hidden_at (TIMESTAMP) : 非表示設定日時
HappinessRecords (日々の幸せ記録)

record_id (PK, UUID or Auto Increment) : 記録ID

user_id (FK to Users.user_id) : ユーザーID

master_id (FK to HappinessMasters.master_id) : 選択された幸せマスタID

record_date (DATE) : 記録日

mood_level (INTEGER) : 気分レベル (例: 1: ちょっと幸せ, 3: 幸せ, 5: とても幸せ)

points_awarded (INTEGER) : 付与ポイント (mood_levelに応じて自動設定)

episode (TEXT, Max: 300 chars) : エピソード

created_at (TIMESTAMP) : 作成日時

updated_at (TIMESTAMP) : 更新日時
リレーションシップの補足:

Users と HappinessMasters: ユーザーが作成したマスタ項目 (created_by_user_id)

Users と UserHiddenAdminMasters: ユーザーが非表示にした管理者提供マスタ

Users と HappinessRecords: ユーザーの日々の記録

HappinessMasters と HappinessRecords: 記録がどのマスタ項目に基づいているか

 3. API設計（主要エンドポイント）RESTful APIを基本とし、JSON形式でデータをやり取りします。

 3.1. ユーザー認証 (/auth)POST /auth/google/login
リクエスト: Google IDトークン
レスポンス:
成功時: ユーザー情報、アクセストークン（本システム用）
失敗時: エラーメッセージ

POST /auth/delete_account
リクエスト: (要認証)
レスポンス:
成功時: 成功メッセージ
失敗時: エラーメッセージ


 3.2. 幸せマスタ管理 (/masters)GET /masters/admin
説明: 管理者提供の幸せマスタ一覧を取得
レスポンス: 管理者提供マスタリスト (ユーザーごとの非表示設定はクライアント側で考慮するか、専用APIを設ける)
GET /masters/user
説明: ユーザーが作成した幸せマスタ一覧を取得 (上限100件)
リクエスト: (要認証)
レスポンス: ユーザー作成マスタリスト
POST /masters/user
説明: ユーザーが新しい幸せマスタを作成
リクエスト: (要認証) { "content": "新しい幸せ項目" }
レスポンス: 作成されたマスタ情報
PUT /masters/user/{master_id}
説明: ユーザーが作成した幸せマスタを更新
リクエスト: (要認証) { "content": "更新された幸せ項目" }
レスポンス: 更新されたマスタ情報
DELETE /masters/user/{master_id}
説明: ユーザーが作成した幸せマスタを削除 (論理削除)
リクエスト: (要認証)
レスポンス: 成功メッセージ
POST /masters/admin/{master_id}/hide
説明: 管理者提供マスタを非表示にする
リクエスト: (要認証)
レスポンス: 成功メッセージ
DELETE /masters/admin/{master_id}/unhide
説明: 管理者提供マスタの非表示を解除する
リクエスト: (要認証)
レスポンス: 成功メッセージ

 3.3. 日々の幸せ記録 (/records)POST /records
説明: 新しい幸せを記録
リクエスト: (要認証) { "master_id": ID, "record_date": "YYYY-MM-DD", "mood_level": 1or3or5, "episode": "エピソード内容" }
レスポンス: 作成された記録情報
GET /records?date=YYYY-MM-DD (または /records/date/{date})
説明: 特定の日付の幸せ記録一覧を取得
リクエスト: (要認証)
レスポンス: 記録リスト
GET /records/month/{year}-{month} (カレンダー表示用)
説明: 特定の月の記録済み日付一覧を取得（ハートマーク表示用）
リクエスト: (要認証)
レスポンス: { "recorded_dates": ["YYYY-MM-DD", "YYYY-MM-DD", ...] }
PUT /records/{record_id}
説明: 既存の幸せ記録を更新
リクエスト: (要認証) { "master_id": ID, "mood_level": 1or3or5, "episode": "更新されたエピソード内容" } (record_dateは変更不可とするか要検討)
レスポンス: 更新された記録情報
DELETE /records/{record_id}
説明: 既存の幸せ記録を削除
リクエスト: (要認証)
レスポンス: 成功メッセージ

 3.4. ダッシュボード (/dashboard)
GET /dashboard/monthly?year={year}&month={month}
説明: 指定された月のダッシュボードデータを取得（当月表示の場合はクライアントが現在年月を指定）
リクエスト: (要認証)
レスポンス:{
  "happiness_item_ranking": [
    { "master_content": "項目名1", "total_points": 50 },
    { "master_content": "項目名2", "total_points": 45 },
    { "master_content": "項目名3", "total_points": 40 }
  ],
  "happiest_days_ranking": [
    { "date": "YYYY-MM-DD", "total_points": 20 },
    { "date": "YYYY-MM-DD", "total_points": 18 },
    { "date": "YYYY-MM-DD", "total_points": 15 }
  ]
}


 4. 画面構成案（主要画面）スプラッシュ/ログイン画面
アプリ起動時に表示。
Googleログインボタン。
カレンダー画面（メイン画面）
月表示カレンダー。
日付を選択すると、その日の記録閲覧/新規記録画面へ遷移。
幸せを記録した日付にはハートマークを表示。
ダッシュボード画面への導線。
マスタ管理画面への導線。
設定（アカウント情報、ログアウトなど）への導線。
幸せ記録画面（モーダル or 別画面）
日付表示。
幸せマスタ選択（既存リストから選択 or 新規作成）。
気分選択（とても幸せ/幸せ/ちょっと幸せ）。
エピソード入力欄（300文字以内）。
保存/更新/削除ボタン。
幸せマスタ選択画面（モーダル or 別画面）
ユーザー作成マスタと管理者提供マスタ（非表示でないもの）を一覧表示。
検索機能。
新規マスタ作成への導線。
ユーザー作成マスタ管理画面
ユーザーが作成したマスタの一覧。
各マスタの編集・削除機能。
新規マスタ作成ボタン（上限100件の表示）。
管理者提供マスタ設定画面
管理者提供マスタの一覧。
各マスタの表示/非表示切り替え機能。
ダッシュボード画面
表示月の選択UI。
「今月の幸せ項目ベスト3」表示エリア。
「今月の幸せ日ベスト3」表示エリア。

 5. 主要機能の処理フロー概要
 5.1. ユーザーログインフロー
クライアント: Googleログインボタンをタップ。

クライアント: Google Sign-In SDKを利用して認証処理開始。

Google: ユーザー認証と同意。

クライアント: GoogleからIDトークンを取得。

クライアント: 取得したIDトークンをサーバーの /auth/google/login APIへ送信。

サーバー: IDトークンを検証。
有効な場合:
DBで google_id を検索。
存在しない場合: 新規ユーザーとしてDBに登録。
存在する場合: ユーザー情報を取得。
本システム用のアクセストークンを発行。

無効な場合: エラーを返す。


サーバー: ユーザー情報とアクセストークンをクライアントにレスポンス。

クライアント: アクセストークンを安全に保存し、ログイン状態とする。メイン画面へ遷移。

 5.2. 日々の幸せ記録フロー
クライアント(カレンダー画面): 日付を選択。

クライアント: 選択した日付の記録画面へ遷移。

クライアント(記録画面): 「幸せの項目」選択ボタンをタップ。

クライアント(マスタ選択画面):
サーバーからユーザー作成マスタと表示設定の管理者提供マスタを取得・表示。
ユーザーがマスタを選択 or 新規作成を選択。
新規作成の場合: マスタ作成画面で入力し、/masters/user APIで登録。成功後、そのマスタを選択状態に。



クライアント(記録画面): 選択されたマスタを表示。

クライアント(記録画面): 気分を選択 (ポイントが内部的に紐づく)。

クライアント(記録画面): エピソードを入力。

クライアント(記録画面): 「保存」ボタンをタップ。

クライアント: 記録情報を /records API (POST) へ送信。

サーバー: リクエストを受け取り、DBに記録を保存。

サーバー: 保存結果をクライアントにレスポンス。

クライアント: カレンダー画面に戻り、記録済みマーク（ハート）を更新。

 5.3. ダッシュボード表示フロー
クライアント(ダッシュボード画面): 表示する年月を指定（デフォルトは当月）。

クライアント: /dashboard/monthly APIへ指定年月を付けてリクエスト。

サーバー: 指定年月のデータをDBから集計。
幸せ項目ランキング: HappinessRecords と HappinessMasters を結合し、master_id ごとに points_awarded を合計してランキング。
幸せ日ランキング: HappinessRecords を record_date ごとに points_awarded を合計してランキング。


サーバー: 集計結果をクライアントにレスポンス。

クライアント: 受信したデータを画面に表示。

 6. 技術スタック（提案）クライアント (Android):
言語: Kotlin
アーキテクチャ: MVVM (ViewModel, LiveData/Flow, Repository)
UI: Jetpack Compose
HTTPクライアント: Retrofit2 / OkHttp3
認証: Google Sign-In for Android SDK
ローカルDB (必要な場合): Room
サーバーサイド:
言語/フレームワーク: Python/Django
データベース: MongoDB
認証: JWT (JSON Web Tokens) など
インフラ:
クラウドプラットフォーム: GCP (Firebase Authentication, Cloud Functions, Firestore/Cloud SQLなど)

 7. その他セキュリティ:
API通信はすべてHTTPSで行う。
アクセストークンは適切に管理し、有効期限を設定する。
サーバーサイドでの入力値バリデーションを徹底する。
Google IDトークンの検証はサーバーサイドで確実に行う。
エラーハンドリング:
クライアント、サーバーともに適切なエラーハンドリングを行い、ユーザーに分かりやすいフィードバックを提供する。
ロギング:
サーバーサイドでのアクセスログ、エラーログの記録。
クライアントサイドでもクラッシュレポートなどを収集。

Step5. Claudeにてプロトタイプを作成する。

Claudeへの依頼風景

Goal. プロトタイプ完成！

最後に

AI使って何ができるか？（方法）も大事ですが、
AI使って何がしたいか？（目的）はもっと大事です。

AI使うことで、何がしたいか？がこれまで以上に他者に伝わりやすくなります。
是非、AIと協業して、あなたの実現したいことをカタチにしてみてくださいませ。（おわり）

あったらいいなを3時間でプロトタイプ作成

やったこと / 使用したツール

Step1. 漠然としたイメージを殴り書きする。

Step2. Geminiに要求整理.mdをプロンプトにて伝え、Geminiからの質問に回答する。

Step3. Geminiにてシステム要件.mdを出力する。

1. アプリの目的

2. ターゲットユーザー

3. プラットフォーム

4. 主な機能

4.1. ユーザー認証

4.2. 幸せマスタ管理

4.3. 日々の幸せ記録

4.4. ダッシュボード

4.5. カレンダー表示

4.6. データ管理

5. 通知機能

6. デザイン

7. その他検討事項

Step4. Geminiにてシステム設計.mdを出力する。

1. システムアーキテクチャ

2. データベース設計（主要エンティティと属性）

3. API設計（主要エンドポイント）

3.1. ユーザー認証 (`/auth`)

3.2. 幸せマスタ管理 (`/masters`)

3.3. 日々の幸せ記録 (`/records`)

3.4. ダッシュボード (`/dashboard`)

4. 画面構成案（主要画面）

5. 主要機能の処理フロー概要

5.1. ユーザーログインフロー

5.2. 日々の幸せ記録フロー

5.3. ダッシュボード表示フロー

6. 技術スタック（提案）

7. その他

Step5. Claudeにてプロトタイプを作成する。

Goal. プロトタイプ完成！

最後に

Discussion