まず AI Studio を開く、という習慣
個人開発でアプリの紹介ページや、自分用の小さな管理ダッシュボードが必要になるたび、私はまず Google AI Studio を開きます。
理由は単純で、デザインの当たりを数分で「動く画面」として確認できるからです。頭の中のイメージを言葉にして渡すと、その場で触れる試作が返ってきます。完成品というより、議論のたたき台が一瞬で手元に来る感覚に近いです。
Gemini が Web アプリ生成で評価されるようになったきっかけは、2.5 Pro が WebDev Arena というベンチマークで上位を取ったことでした。WebDev Arena は、生成された Web アプリの見た目と使い勝手を人間が比較投票して順位を決める仕組みです。その後モデルは 3 系へ更新されましたが、ここで紹介する「AI Studio で試作してから固める」流れは、モデルが変わっても変わらず使えます。
Google AI Studio からの開発フロー
ステップ1: AI Studio でプロトタイプ
AI Studio にアクセスし、コーディング向きのモデルを選びます。たとえば次のような指示を渡します。
シンプルなポモドーロタイマーのWebアプリを作ってください。
要件:
- 25分の作業と5分の休憩をカウントダウン
- 残り時間を大きな円形プログレスバーで表示
- セッション完了時に音で通知
- ダークテーマ
- レスポンシブデザイン（PC/スマホ対応）
- HTMLファイル1つで完結
この指示だけで、ブラウザですぐ動く HTML が返ってきます。
ステップ2: イテレーション
返ってきた画面を触り、足りないところをチャットで足していきます。
作業時間を25分/50分から選べるようにしてください。
また、今日完了したポモドーロの回数を画面の下部に表示してください。
ここで大事なのは、一度に多くを頼まないことです。変更は1〜2項目ずつ伝えると、意図しない箇所が書き換わる事故を減らせます。
ステップ3: デプロイ
固まったコードは、Antigravity に渡して仕上げるか、Cloudflare Pages や Vercel にそのまま置けます。HTML 一枚なら、ドラッグ&ドロップで公開できる手軽さがあります。
プロンプトの組み立て方
要件は具体的に、箇条書きで
❌「天気アプリを作って」
✅「現在地の天気を表示するWebアプリを作ってください。
OpenWeather APIを使用。
気温、湿度、天気アイコン、3日間の予報を表示。
ガラスモーフィズムのカードデザイン。
HTMLファイル1つで完結。」
曖昧な依頼ほど、出力も平凡になります。何を表示し、どんな見た目で、どこまでを1ファイルに収めるか。この3点を最初に書き切ると、手戻りが目に見えて減ります。
デザインの方向性を言葉で渡す
Gemini はデザインの語彙によく反応します。
- 「ガラスモーフィズム」「ニューモーフィズム」「ミニマリスト」
- 「Apple 風」「Material Design 風」
- カラーパレットの指定（例: 「#667EEA をメインカラーに」）
- 動き（例: 「フェードイン」「スライドの切り替え」）
抽象的な「おしゃれにして」よりも、参照したいスタイル名や色コードを直接渡すほうが、狙いに近づきます。
一枚の HTML で完結させる強みと限界
Gemini が最も安定して作れるのは、HTML・CSS・JavaScript を1ファイルにまとめた自己完結型のアプリです。計算機、ダッシュボード、簡単なゲーム、設定ツールなど、外部サービスに依存しないものほど精度が上がります。
一方で、限界もはっきりしています。ファイルが大きくなると、生成の途中で末尾が切れたり、前回のコードの一部が抜け落ちたりします。私の場合、目安として1ファイルが 600 行を超えたあたりから、この種のほころびが増える印象です。
そうなったら、機能ごとにファイルを分けるか、AI Studio での試作はここまでと割り切り、続きはエディタ側で手を入れる判断に切り替えています。試作で速度を取り、仕上げで確実さを取る。この線引きを持っておくと、無理にチャットで直し続けて泥沼にはまらずに済みます。
実際に詰まったところ
外部 API キーがコードに直書きされる
天気や地図など外部 API を使うアプリを頼むと、Gemini はサンプルキーをそのまま HTML に埋め込んできます。試作中は便利ですが、このまま公開するとキーが丸見えになります。本番では、キーをサーバー側（たとえば Cloudflare Workers）に逃がす構成へ必ず置き換えてください。「クライアントにキーを置かない前提で書き直して」と一言添えると、構成案ごと提案してくれます。
修正のたびに別の箇所が変わる
「ボタンの色だけ変えて」と頼んだのに、レイアウト全体が組み替わって返ってくることがあります。これは、長い会話の文脈をモデルが再解釈してしまうために起きます。回避策はふたつあります。ひとつは、変更点を1つに絞って渡すこと。もうひとつは、気に入ったバージョンのコードを一度手元に保存し、おかしくなったらそこへ戻すことです。
会話が長くなると精度が落ちる
同じセッションで延々とやり取りを続けると、初期の要件をモデルが忘れ始めます。区切りのいいところで、最新のコードを貼り直して「これをベースに続けて」と仕切り直すと、精度が戻ります。
もうひとつ、地味ですが効くのが「目的の一文」を毎回先頭に置くことです。たとえば「これは個人開発者向けの軽量なポモドーロアプリです」と冒頭で前提を固定しておくと、会話が長引いても方向がぶれにくくなります。私自身、込み入った画面を作るときほど、この一文を最初に置くようにしています。
実践例: ダッシュボードの作成
セールスダッシュボードのWebアプリを作ってください。
要件:
- ダークテーマ、サイドバーナビゲーション
- KPIカード: 売上合計、注文数、平均注文額、前月比
- 月別売上の折れ線グラフ（Chart.jsを使用）
- 地域別売上の円グラフ
- 直近の注文一覧テーブル
- デモデータを含める
- HTMLファイル1つで完結
グラフライブラリ（ここでは Chart.js）を名指しすると、読み込みタグまで含めて整った形で返ってきます。デモデータを含めるよう頼んでおくと、その場で見栄えを確認できるので、クライアントへの提案資料の下地としても使えます。
どのモデルを選ぶか
2026 年半ば時点では、コーディング・エージェント用途の主力は Gemini 3.5 Flash です。試作の往復は速さが効くので、まずは Flash 系で回し、デザインの作り込みやロジックが複雑な画面だけ上位モデルへ切り替える、という使い分けが私には合っています。
App Store 向けアプリのプロモ用ランディングページのように、見た目の完成度が成果に直結するものは、最初から上位モデルに任せたほうが結果的に手戻りが少なく済むこともあります。タスクの「見た目重視か、速さ重視か」で選ぶと迷いません。
まずは手元の小さなツール、たとえば普段の作業で「あったら便利」と思っていた変換ツールや計算機を、AI Studio で一枚の HTML として作ってみてください。プロンプトの効き方が体でわかると、次からの試作が一気に速くなります。