ここからは、実際にこのお風呂アプリをどのように実装していったか、
特に Antigravity を使った開発プロセスとプロンプト設計についてまとめます。
今回は「最初のMVP実装 → デザイン調整」までの流れを整理します。
最初はかなりシンプルな状態からスタートしました
実際に一回目の実行では、以下のような 最低限のUI・構成でアプリが生成されました。
今回は Antigravity の無料版を使用していたため、実行回数の制限を超えないこと、超えた場合自分で調整しやすい形に整える事を最重要視しました。
そのため、最初のプロンプトでは以下を徹底しています。
- 試行回数を増やさない
- 一度で「動く状態」まで持っていく
- 後からいくらでも拡張できる形にする
という状態を目指しています。
最初に使用したプロンプトのポイント
以下は、実際に最初に Antigravity に渡したプロンプトをもとに、
「なぜこの書き方にしたのか」「どこを重視したのか」を解説します。
（全文は長くなるため、ここではポイントのみ抜粋しています）
役割と制約を最初に明示する
あなたは React（TypeScript）で最小構成のWebアプリを実装するエンジニアです。
このタスクでは 試行回数・変更範囲・ファイル数を最小化してください。
最初に 役割とゴールを固定します。
ここで「最小構成」と明示することで、Antigravity が勝手に機能を盛り始めるのを防げます。
1. 「絶対条件」を最初に明示する
プロンプトの冒頭では、以下のような制約を明確に書いています。
- 確認質問はしない
- 機能追加・最適化はしない
- 外部APIや通知は使わない
- データ保存は localStorage のみ
- CSSや画像は仮でOK
これは、無料版の実行回数を無駄に消費しないためです。
Antigravityは指示が曖昧だと、「確認 → 修正 → 再実行」という流れになりやすいため、最初に「やらないこと」「迷わなくていいこと」をすべて固定しました。
2. 目的を1文でシンプルに書く
プロンプト内では、目的を以下のように簡潔に定義しています。
お風呂に入るのを後回しにする人向け。
時間が経つほどキャラクターが汚くなる（4段階）＋辛口コメントで行動を促す。
機能説明よりも先に 「誰の・どんな行動を変えたいか」 を書くことで、UIやロジックの方向性がブレにくくなります。
3. 画面数とルーティングを最初に固定する
/ ：ホーム（今日）
/calendar：達成カレンダー
/settings：設定
このように、 画面数とルートを最初に固定しておくことで、
- 不要なページが増えない
- ファイル数が増えない
- 修正時の影響範囲が限定される
というメリットがありました。
特に無料版では、「あとからページが増える」＝「再実行が増える」ため、最初に枠を決めておくことが重要だと感じました。
4. ロジックを文章で具体的に書く
Stage切り替えや達成判定については、 曖昧な表現ではなく分単位で条件を明示しています。
- Stage0：目標時刻より前
- Stage1：目標時刻〜14分遅れ
- Stage2：15〜44分遅れ
- Stage3：45分以上遅れ
また、「連続達成日数」は
AchieveDone（目標時刻以内に完了）を基準にすることも明記しました。
このように、ロジック部分を言語化しておくことで、生成後の修正がほぼ不要になりました。
5. 最初は「完成度」を求めない
画像・CSS・UIについては、
プレースホルダーでOK
後から差し替える前提
と明記しています。
最初の実行では 「動くかどうか」だけ確認できれば十分と割り切り、デザインや体験の調整は、後からプロンプトを分けて追加しました。
理想のUIは画像で伝えるのが一番早い
デザイン調整フェーズでは、自分の頭の中のイメージだけで指示するのではなく
- 他のアプリ
- UIデザイン集
- Dribbble / Pinterest / 参考サイト
などから 理想に近いUI画像を探し、それを添付しながらプロンプトを書きました。
文章だけで
「生活感あるUIにしてください」
「ゆるいデザインにしてください」
と書くよりも、
「この画像のような余白感・カードUIにしてください」
と 視覚情報付きで指示 した方が、圧倒的に精度が高くなります。
実際に行ったデザイン調整の流れ
デザイン調整では、以下の順序でプロンプトを実行しました。
- 既存UIは変更しないことを明示
- 追加のみで拡張することを指定
- 参考画像は雰囲気のみ反映
- レイアウト・余白・カード化を調整
実際に指示した前提条件がこちらです。
前提条件
- 現在実装されている画面構成・文言・ロジックは一切変更しない
- 既存の表示内容（文言、数値、判定ロジック、状態管理）はそのまま維持
- 既存コンポーネントは削除・置換せず、追加のみで拡張する
- 既存UIは「機能的にはそのまま」、見た目のみ調整する
ここを明示しないと、
- ロジックが書き換わる
- state管理が壊れる
- 画面遷移が変わる
といった 事故的リファクタ が発生します。
デザイン調整フェーズでは、
「触っていいのはCSSとレイアウトだけ」
と明確に制限するのが重要です。
参考デザインを使う際の注意点
UI画像を参考にする際は、以下の点にも注意が必要です。
- そのままコピーしない
- 配色・余白・構造など「雰囲気のみ」参考にする
- 利用規約や著作権に配慮する
特に公開記事やポートフォリオに載せる場合は、
「参考：○○のデザイン構成をベースに調整」
など、出典や参考元の明示をしておくと安全です。
まとめ：精度の高いプロンプトを書くために意識したこと
今回のプロンプト設計で意識したのは、
- 一度に完成させようとしない
- 迷わせない指示を書く
- 無料枠を「実行回数」ではなく「設計」で節約する
- デザインは後から分離して調整
- 理想UIは画像で伝える
- 既存ロジックは絶対に触らせない
この流れにすることで、
無料版の制限内でも精度の高いアプリ生成が可能になります。