アプリ開発ガイド
明確なアイデアからアプリをバイブコーディングする方法
アプリをバイブコーディングする方法を学ぶなら、画面の一覧ではなく、ユーザーが完了したい1つのタスクから始めましょう。このガイドでは、新しく作る場合と既存のプロジェクトを変更する場合を分け、人によるテストが重要になる場面を説明します。
自分に合うケースを選ぶ（判断表）
すでにあるものに応じて選びましょう。新しいアイデアなら、最初に作る範囲を絞ります。既存のプロジェクトなら、現在の動作を維持できる変更を選びます。
進め方A
アイデアはあるものの、プロジェクトはまだない場合に選びます。最初のバージョンは、一度に確認できる小さな範囲に抑えましょう。
-
1
タスクとその範囲を説明する
ユーザーが誰で、何を完了し、どのような結果が画面に表示されるべきかをプロンプトに書きます。習慣トラッカーなら、毎日のチェックイン、短い履歴、記録がないときの表示を依頼します。見栄えのよい画面を、実際に動くデータサービスと取り違えないよう、サンプルデータを使うことも指定しましょう。
-
2
一連の操作を完成させる
Vibe Codeには、画面を開き、チェックインを追加し、その内容が表示されるという、使える最小限の操作フローを依頼します。分かりやすいラベル、キーボードで操作しやすいコントロール、モバイル向けのレイアウトも求めましょう。余分な画面や関係のない機能が追加された場合は、それらを前提に作り進めず、削除するよう依頼します。
-
3
実行して、うまくいかない点を説明する
デザインの変更を依頼する前に、自分で一連の操作を試しましょう。たとえば、更新するとチェックインが消えるといった確認できる問題と、期待する動作を伝えます。一度に変更するのは1つだけにし、その都度操作を試して、最後に正常に動いたバージョンのコピーを残しましょう。
パスB
プロジェクトがすでに動作している場合は、このパスを使います。動作している機能を気づかないうちに置き換えず、変更範囲を限定できるよう、アシスタントに十分な背景情報を伝えてください。
-
プロジェクトの動作するコピーと、ローカルで実行する方法 — まず、変更前のプロジェクトが起動し、主要な操作が機能することを確認してください。
-
期待する結果を明示した、具体的な変更依頼 — 例：タスクリストに項目がないときに、空の状態を示すメッセージを追加する。
-
変更してはいけない動作のリスト — 影響を受ける画面、既存のデータ形式、壊してはいけない操作を明記してください。
-
機密性のないサンプルデータを使った安全なテスト環境 — パスワード、個人情報を含む記録、稼働中のサービスのキーをプロンプトに入力しないでください。
-
編集前のバージョン管理のチェックポイント任意 — コミットしておくと、差分の確認や不要な変更の取り消しが容易になります。
-
現在の画面のスクリーンショット、または簡単な説明任意 — 余白、文言、レイアウトの崩れに関する依頼では、画面の情報が役立ちます。
関連するガイド
全体的な入門、アプリ作成に重点を置いた概要、より詳しい安全性の確認が必要なら、次に知りたいことに合ったガイドを選んでください。
最終確認
完成しているように見える画面が、必ずしも信頼できる製品とは限りません。サンプルのプロンプトとは異なる使い方をしたときに何が起こるかをテストしましょう。
プレビューではデータの永続性を証明できない
項目が保存されたように見えても、現在のブラウザーセッションにしか存在しない場合があります。共有データや永続的なデータを提供する設計なら、ページの再読み込み、開き直し、別のデバイスでの確認を行いましょう。
代わりにすべきこと
データが一時的なものかどうかを明示し、記録が保存されると説明する前に、実際の保存動作を検証しましょう。
生成されたコードはセキュリティレビューの代わりにはならない
動作するフォームでも、秘密情報が漏れたり、安全でない入力を受け付けたり、他人の記録にアクセスできたりする可能性があります。実際のデータを扱う場合や一般公開する場合は、その前にバイブコーディングの出力をレビューする必要があります。
代わりにすべきこと
改善を重ねる間はサンプルデータを使い、機密情報を扱う処理は公開前にレビューとテストを受けましょう。
一度クリックして成功しただけでは、例外的なケースを見落とす
空欄、長い文章、連続タップ、遅い接続、幅の狭い画面によって、一度のデモでは動いた操作の流れが崩れることがあります。
代わりにすべきこと
それぞれのケースをテストし、確認した不具合を記録して、修正のたびに以前のチェックを再実行しましょう。
プロンプトは製品のルールを決められない
アシスタントは初期設定を提案できますが、誰にアクセス権が必要か、どの記録を保持すべきか、どの間違いが深刻な結果を招くかは判断できません。
代わりにすべきこと
それらのルールをわかりやすい言葉で書き出し、実際の動作がルールと一致していることを確認しましょう。
このワークフローが形になるまで
プロンプトを起点とする開発は、いくつかの進歩に支えられています。しかし、ソフトウェアを調べてテストする必要がなくなったわけではありません。
-
コードの提案がエディターに登場
GitHub Copilotのテクニカルプレビューにより、使い慣れたコーディング環境でAIが生成した提案を利用できるようになりました。提案によって小さな修正を素早く行えても、周囲のプロジェクトに適しているかは開発者が判断する必要がありました。
-
指示が対話形式に
ChatGPTの一般公開により、普段の言葉で機能を説明し、返答を確認しながら依頼を練り直すことが現実的になりました。このやり取りは、コードの生成だけでなく、操作の流れを計画する際にも役立ちます。
-
大きな変更も依頼しやすくなる
コーディングができるAIツールの発達に伴い、人々は単独のコード片ではなく、画面同士のつながりや一連の動作を求めるようになりました。そのため、範囲を明確にすることがより重要になりました。依頼が漠然としていると、見た目は整っていても、未検証の前提に基づく結果が生まれかねません。
-
バイブコーディングという名前が広まる
Andrej Karpathyは、プロンプトを使ってソフトウェアを作る手法を表す言葉として、バイブコーディングを広めました。アプリ開発で大切なのは、生成された変更をすべて受け入れることではありません。小さな操作の流れを作り、動作を確かめ、修正することを繰り返すことです。
小さな機能から作り始める
Vibe Codeには、ユーザーが行う具体的なタスク、画面に表示すべき結果、「サンプルデータのみを使う」といった制約を伝えましょう。最初のバージョンができたら、自分で操作を試し、全面的な作り直しではなく、修正箇所を具体的に伝えましょう。
チュートリアルのよくある質問
想定するユーザー、1つのタスク、ユーザーが行う操作、表示されるべき結果を明記してください。モバイルでも使いやすいレイアウトや、サンプルデータのみを使うといった制約も含めましょう。将来欲しい機能をすべて求めるのではなく、小さくても動く一連の操作を依頼してください。
新しいアイデアを試したくて、残しておきたいコードがない場合は、ゼロから始めましょう。すでに動いているものに特定の変更を加えたい場合は、既存のプロジェクトを使ってください。その場合は、まず現在の動作を確認し、変えてはいけない点を説明しましょう。
プロンプトに示した例に頼らず、主なタスクを最後まで実行してみてください。次に、入力が空の場合、操作を繰り返した場合、ページを更新した場合、画面幅が狭い場合を試しましょう。データの保存や共有が必要なら、プレビューが正常に動いたことだけで判断せず、それぞれ別にテストしてください。
何をしたか、何が起きたか、代わりに何を期待していたかを説明してください。範囲を絞った修正を1つ依頼し、その修正と、それまで動いていた操作の流れの両方をテストしましょう。変更によって新たな問題が生じた場合は、最後に正常に動いていたバージョンに戻してから、別の指示を試してください。
動作を確認し、制約を明確に伝えれば、プロトタイプを共有できます。実際のユーザーが個人情報を入力する前に、データの保存方法、アクセス権限、エラー処理、外部に露出した秘密情報を確認してください。見た目が動いていそうなだけでは、こうした安全対策が整っている証拠にはなりません。