BoltでWebアプリを作る基本手順

BoltでWebアプリを作るときは、最初の指示で完成品を一気に作ろうとせず、「誰が、どの入力をし、何を受け取るか」という中心の流れを一つ動かすところから始めます。生成後は画面を眺めるだけでなく、入力・送信・保存・再表示まで操作し、失敗時に何が起きるかも確認します。小さな範囲で出力を確かめてから次の機能を足すと、意図と違う部分を早く見つけられます。

この記事のゴールは、Boltの機能を列挙することではありません。読者が、作る対象を短い仕様へ整理し、最初のpromptを用意し、Preview上で合否を判断し、次の修正を小さく依頼できることです。ログインやdatabaseを使うアプリでは、画面が表示されるだけでは完了ではありません。誰の情報がどこへ保存されるか、未ログイン時にどう振る舞うかも別の確認項目になります。

最初に「完成」ではなく最初の利用場面を決める

「予約アプリを作る」だけでは、利用者、予約対象、入力項目、確定後の画面が決まりません。一方で、最初から通知、管理画面、決済、権限設定まで含めると、生成結果が広がり、どの要件が原因で不具合になったか追いにくくなります。まず、最初の利用者が一回だけ完了できれば価値がある操作を決めます。

たとえば、会議室予約の試作なら、最初の範囲を「利用者が日付と時間を選び、空き枠を確認し、仮予約を送信し、受付結果を見る」に絞れます。管理者向け分析やメール通知は後段です。これは機能を減らすこと自体が目的ではなく、最初に正しさを確かめる対象を特定するためです。

次の簡易briefをpromptを書く前に埋めます。

表は横にスクロールできます

項目	例	先に決める理由
利用者	社内の会議室を予約する社員	表示する言葉や権限が決まる
1回の中心操作	日時を選び、予約を送る	最初に動作確認するflowになる
入力	日付、開始時刻、終了時刻、部屋	formとvalidationの範囲になる
成功結果	予約番号と内容を確認できる	送信後の状態を決められる
失敗結果	空きがない、必須項目不足	利用者に返す案内が決まる
今回は作らないもの	決済、通知、管理分析	初回buildの境界になる

この表のままpromptへ移す必要はありません。曖昧な箇所を見つけるために使います。「誰が使うか」「何を入力するか」「どの状態なら成功か」のどれかが空欄なら、まずその部分を決めてから生成します。

最初のpromptは画面名より入出力を書く

Boltの公式QuickStartは、作るものと必要な機能をpromptに伝え、生成されたPreviewを実際に操作する流れを示しています。最初のpromptには、見た目の形容詞だけでなく、利用者・入力・処理・出力・失敗時の動きを含めます。フレームワークや技術構成を自分で指定できない場合は、無理に技術名を並べず、必要な挙動を説明してください。

たとえば会議室予約なら、次のように依頼を分けられます。

「社内利用者向けの会議室予約Webアプリを作成してください。最初の画面で日付、開始時刻、終了時刻、部屋を選び、空き状況を確認できるようにしてください。予約送信後は、入力内容と受付状態を確認できる画面を出してください。必須項目が不足しているとき、または空きがないときは、どこを直せばよいか画面内に表示してください。今回の範囲は予約確認から受付表示までです。決済、通知、管理者分析は追加しないでください。幅の狭い画面では入力欄とボタンが画面外へはみ出さない配置にしてください。」

ここで「データを保存する」と「一時的な見本だけを表示する」は別の要件です。保存するなら、どのユーザーがどの予約を読めるか、更新・取消を許すかをbriefへ追加します。保存先がまだ決まっていない場合に、生成結果を本番データベースへ直結しないでください。Boltはdatabaseやhostingを含む一体型の作業環境を提供しますが、使える機能や設定はプロジェクト状況で異なるため、必要な場合は現在の公式画面と設定を確認します。

Previewでは見た目と機能を別々に通す

生成結果は、指定した機能が「画面にある」ことと、その機能が「期待どおり動く」ことを分けて確認します。たとえば予約ボタンが表示されても、押した後の画面が変わらない、連打で二重予約になる、入力エラーが消えないなら中心のJobは未完了です。見た目の整い具合から機能の完成を推定しないことが重要です。

最初のPreviewでは、次の順に操作します。

1. 空欄のまま送信し、必要な入力が指摘されるか

2. 日付だけ入れ、他の必須入力が不足していることが分かるか

3. 有効な入力をすべて埋め、確認画面へ進めるか

4. 戻って内容を変え、表示と送信内容が一致するか

5. 受付後に画面を更新し、保存仕様どおりの結果になるか

6. 幅を狭くして、form、エラー文、ボタンを操作できるか

このチェックは実サービスの動作を保証するものではありません。生成された試作品が、書いた要件を満たしているかを早く見つけるための確認です。データ永続化を要件にした場合、ブラウザを更新しても状態が残るか、別アカウントから見たときに適切に分離されるかは、保存先・認証・権限の構成を確認したうえでテストします。

操作中は、期待した結果だけでなく、実際の結果もメモします。「予約できない」ではなく、「開始時刻を選び送信すると、ボタンが反応せず、エラー表示もない」のように、入力・操作・結果を一文で残すと次の修正依頼が具体的になります。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Bolt.new

  公式サイトを見るTool詳細を見る

修正は一回に一つの原因へ絞る

複数の変更を一度に依頼すると、どの指示が結果へ影響したか分かりにくくなります。見た目の文言調整とデータ保存の変更を同じpromptへ混ぜないでください。問題を「再現条件」「期待結果」「実際の結果」「変更してよい範囲」に分けてから依頼します。

修正promptの例です。

「予約内容を入力して送信すると、受付済み画面へ進むはずですが、現在は入力画面に戻ってしまいます。送信後の画面遷移だけを調査してください。予約データのschema、色、余白、他の画面は変更しないでください。まず原因を短く説明し、修正後に同じ入力で確認する手順を示してください。」

色・文字サイズ・余白など画面上で範囲を指定できる調整なら、Visual Editsや小さな指示が向いています。状態管理、validation、API、認証のような動作変更では、対象componentと期待する状態遷移を明示し、変更後にCode viewや差分を確認します。「全部整えて」のような広い依頼に戻すと、必要のない場所まで変更される可能性があります。

うまくいかなければ、続けて別の修正を積み重ねる前に、現在の状態を保存または履歴で確認し、原因を説明させます。直前の変更が原因なら戻せる状態か、別の要件が衝突しているのかを切り分けてから次へ進みます。生成された差分は、内容を把握できないまま採用せず、画面と機能の両方で再確認します。

保存とログインを加える境界

単なる入力フォームの試作品なら、最初は固定の見本データで中心操作を確かめられる場合があります。アカウントを作る、ユーザーごとの履歴を保存する、外部APIを呼ぶ段階では、画面だけで完了とは言えません。誰が記録を作成し、誰が読み、誰が更新できるかを決め、その権限をUIの表示だけでなくサーバー・database側でも確認します。

ここでは、要件を次の三つに分けると抜けを発見しやすくなります。

表は横にスクロールできます

層	決めること	確認例
画面	利用者が見て操作する内容	自分の予約だけを一覧表示する
認証	利用者をどう識別するか	ログイン前後で画面が変わる
認可	識別後に何を許すか	他人の予約IDを指定しても読めない

これは実装方式の指定ではなく、利用者が困らない条件の確認です。実データを扱うなら、テスト用のデータとユーザーで、作成・読取・更新・削除を別々に試します。たとえば利用者Aが作った予約を利用者Bの画面に表示してしまう問題は、一覧画面を隠しただけでは解決しません。URLや直接リクエストからも読めないか、権限を確認します。

API keyなどの秘密情報は、公開されるclient側のcodeへ埋め込まず、サービスの適切なsecret管理やserver-side機能を使います。生成ツールへ接続情報を渡す前に、その情報をどこへ保存するか、公開後に誰が使えるかを確認してください。既存databaseを接続・変更する場合は、対象projectとenvironment、backup、変更範囲を先に確認し、agentが触れてよい操作を限定します。databaseやaccountの置換が必要な操作は、説明と影響範囲を確認しないまま確定しないでください。

公開前に中心の一往復を再確認する

公開はボタンを押してURLを得ることと、そのURLで利用者のJobが完了することを分けて考えます。公開前に、別の利用者が初めて開く想定で最初から一周します。ログインが必要なら、招待・登録・ログアウト後の挙動も確認し、テスト中の記録が本番利用者に見えないことを確かめます。

表は横にスクロールできます

確認点	合格の見方	不合格なら
初見で目的が分かる	誰向けかと中心操作が画面内で分かる	説明を追加する前に機能範囲を整理
入力	必須・任意、形式、制限が分かる	field名・エラー表示を明確にする
成功	送信後の結果と次にできることが分かる	success stateと戻る方法を定義
失敗	原因と修正方法が表示される	error pathをpromptへ追記
小画面	主要操作が横にはみ出さず完了する	該当sectionだけ修正
保存・権限	更新後に期待するデータが見え、他者情報は見えない	認証と認可を分けて再確認
更新・復旧	変更履歴または復旧方法を説明できる	公開前のrestore点を決める

公開後にも、実際のURLで同じ中心操作を再度試してください。Previewで動作しても、公開URLでは設定、domain、認証、database接続などが異なる場合があります。特にAPIを使う画面では、機能を一回押して終わりではなく、成功時、入力ミス時、通信失敗時を見ます。問題があった場合、まず利用者へ影響する範囲を把握し、更新を止めるか、以前の安定状態へ戻すかを判断できるようにします。

AIものさしの判断

BoltでWebアプリを作る作業は、promptを送ることではなく、中心の利用場面を要件として置き、生成結果を操作で検証し、必要な変更だけを加える一連の作業です。最初の依頼は小さく、成功と失敗の判定を含めます。databaseや認証を使う段階では、保存先と権限を別の要件として扱います。

次の行動は、briefの空欄を埋めてから最小の一往復をpromptにすることです。生成後は入力、送信、結果表示、更新後の状態まで実際に操作し、未達の条件を一つずつ記録してください。未確認の仕様を「Boltなら自動で安全」と見なさず、利用する機能の現在の公式説明とproject設定を照合します。これなら、作りたいものがまだ曖昧な人は要件を整理でき、すでに試作品がある人は次の修正箇所を絞れます。