Boltの基本的な使い方

Boltは、自然言語で指示するとwebsite、web app、mobile appを作れるAI builderです。

現在はBolt Cloudにhosting、database、authentication、domain、analyticsなどがまとまっているため、初めて使う場合でも、

promptを書く → 動作確認 → 小さく修正 → database確認 → publish

という順で進めると迷いにくくなります。

最初に知っておきたいこと

Boltはbrowser内で動きます。

公式HelpではChromeやEdge、BraveなどChromium系browserを推奨しています。

mobile browserは完全対応ではありません。

またbackendはJavaScript / Node.js系が中心で、PHPやPython backendはBoltのWebContainerでは直接対応していません。

WordPress / PHP案件をそのままBoltで動かすtoolではない点に注意します。

1. Boltを開いて最初のpromptを書く

Bolt homepageを開き、作りたいものを普通の文章で入力します。

たとえば、

「会員登録できる読書記録Webアプリを作って。トップ、ログイン、記録一覧、追加フォームが必要。落ち着いたminimal designにする」

のように、

• 何を作るか

• 誰が使うか

• 必要画面

• 必要機能

• design方向

を一度に伝えます。

「いい感じのアプリを作って」だけより、初期構造が安定しやすくなります。

2. 最初から全部詰め込みすぎない

Bolt公式Troubleshootingでも、大きな変更は小さく分けることを推奨しています。

最初のbuild後は、

1. loginを確認

2. database保存を確認

3. responsiveを確認

4. UI修正

5. payment追加

のように一つずつ進めます。

一度に10機能を修正させると、意図しない変更が増えやすくなります。

3. Previewで動作を確認する

生成後はPreviewを見ます。

designだけでなく、

• buttonが動くか

• form送信できるか

• navigationが正しいか

• mobile widthで崩れないか

• errorが出ていないか

を確認します。

問題があれば「直して」だけではなく、

「新規登録後にdashboardへ遷移せずloginへ戻る。原因を確認し、この動作だけ修正して」

のように現象と期待結果を明記します。

4. databaseは自動作成できる

Bolt Cloudにはbuilt-in databaseがあります。

appにdatabaseが必要だとAgentが判断すると、tableやauthenticationを自動作成できます。

database iconから、

• table

• record

• User Management

• activity

• secrets

等を確認できます。

外部管理が必要ならSupabaseへ接続・claimする選択肢もあります。

5. Project Knowledgeへ固定ルールを書く

projectが長くなると、毎回同じ前提を書くのが面倒になります。

Project Knowledgeには、

• product goal

• design rule

• terminology

• coding constraint

• workflow

などを背景instructionとして保存できます。

「brand colorはこれ」

「TypeScriptを使う」

「既存componentを優先」

といったルールをproject単位で持たせると、chatだけに依存しにくくなります。

6. 複雑な変更はPlanning workflowを使う

いきなりcodeを変更させず、

• architectureを相談

• error原因を調査

• 実装方針を比較

したい場合はPlan Modeが利用できるAgentでは、まず変更案と対象範囲を整理してから実装へ進められます。Discussion Modeはlegacy v1 Agentでのみ利用できると公式Helpが案内しているため、画面のAgentに合わせて使います。

公式tutorialでも、まずreasoning / planningしてから実装するflowを推奨しています。

token節約にもつながります。

7. GitHubへ同期して逃げ道を作る

productionへ近づいたらGitHub連携を検討します。

repoへcodeを同期しておけば、

• version control

• external IDE

• code review

• backup

• CI/CD

へ広げやすくなります。

Boltだけで閉じず、source codeをGit側でも管理する方がhandoffしやすいです。

8. Publishする

Bolt Cloudではprojectを直接publishできます。

各projectにはbolt.host subdomainを使える構成があり、paid userはcustom domainも接続できます。

最初はtest URLで、

• login

• database

• mobile

• browser

• performance

を確認してからcustom domainへ進みます。

まずは使ってみる

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

• 

  Bolt.new

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

9. Mobile appを作る場合

BoltはExpoを使ったmobile appにも対応しています。

initial promptへ「mobile app」と明記するとExpo-compatible appを作るよう案内されています。

ただしmobile browserでBolt自体を操作するのではなく、desktop browserでbuildし、Expo workflowでdevice previewする方が基本です。

10. token消費を抑える

Boltはproject filesを読みながらAIが処理するため、projectが大きくなるほどtoken消費が増えます。

節約するには、

• 変更を小さくする

• 同じerrorへ何度もpromptしない

• clearなinstructionを書く

• Discussionで原因を絞る

• 不要contextを増やしすぎない

ことが重要です。

初回のおすすめ手順

1. 小さなappをprompt

2. Preview確認

3. 一つずつ修正

4. database / auth確認

5. Project Knowledge設定

6. GitHub連携

7. Publish

8. production前にsecurity review

この順で進めると、いきなり大規模appを作るよりBoltの特徴を理解しやすくなります。

AIものさしの判断

Boltは、非engineerでもideaから動くfull-stack productまで進めやすいbrowser-based AI builderです。

最初からすべてを任せるより、小さい変更を積み重ね、Preview・database・GitHubを確認しながら進める方が安定します。

PHP / Python backend中心のprojectや既存大規模repoでは、別の開発環境も比較します。

最初のpromptを実装可能な依頼にする

「読書記録appを作って」だけでは、認証方式や保存単位、完了条件をBoltが補ってしまいます。初回依頼は、目的・画面・data・制約・確認方法を分けて書くと、Previewで何を検証するか明確になります。

目的：自分の読書記録を保存し、あとから検索する小さなWeb app

利用者：個人。公開ユーザー登録は初期版に含めない

画面：一覧、記録追加、記録詳細

入力：本の題名、読了日、評価、短いメモ

保存：再読み込み後も記録が残ること

制約：スマートフォン幅で操作可能。既存画面とdataを壊さない

完了条件：

- 空の題名では保存できない

- 保存後に一覧へ戻り、新しい記録が表示される

- 再読み込み後も同じ記録が残る

- 追加・編集・削除のerrorが画面に表示される

まず画面とdata modelを提案し、実装前に確認点を示す

これは依頼文の型であり、実際にBoltで検証した成果を示すものではありません。個人データを扱うappなら、login、access control、削除、backup、利用するdatabaseを別途決めてから追加します。

変更ごとの検証を固定する

生成された差分を確認するときは、機能名ではなく受け入れ条件で見ます。

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

変更	Previewで行う確認	失敗したとき
form	空欄、正常値、境界値を送信	validationとerror表示を分けて修正
database	保存、再読み込み、別record表示	schema・query・permissionを一つずつ確認
authentication	未ログイン、別user、権限なしでアクセス	表示だけでなくserver-side access controlを確認
responsive	390px程度で主要画面を操作	問題箇所のcomponentだけ直す
publish	preview URLと公開URLを別browserで開く	secret・env・公開範囲を確認してから再publish

database接続時は、画面の成功表示だけで保存完了と判定しません。readbackでrecordを確認し、別userが読めてはいけない情報ならアクセス権限も検証します。認証や決済を含む変更を一度に生成させず、先にdataの境界とtest accountを決めます。

Boltだけで完結しない条件

PHP / Python backendが必須、既存の複雑なrepoを壊さず変更する必要がある、監査可能なrelease工程が必要、といった条件では、生成Previewだけを完成判定にしません。source codeをGitHubへ同期し、専門環境のtest・security review・deployment pipelineへ渡す設計が必要です。Boltのbuilt-in database / hostingで必要な運用証跡やbackupを満たせない場合も、導入前に別環境と比較してください。