【リテール事業者向けVibeCoding入門｜第4章 】Bolt.newでアプリを作る Vibe Coding実践

第3章では、AIコーディングツールの違いを比較し、

試作は Bolt.new、改修は Claude Code、自動化は Antigravity

という整理をしました。

では実際に、Bolt.new を使うとどのようにアプリを作れるのでしょうか。

第4章では、Vibe Codingの入口として最も触りやすいBolt.new の実践方法を解説します。

Bolt.newとは何か

Bolt.new は、ブラウザだけで完結するフルスタック開発ツールです。

通常、アプリを作るには

• ローカル環境を構築する
• Node.js やライブラリを入れる
• サーバーを立ち上げる

といった準備が必要でした。

しかし Bolt.new では、そうした手間を省いて

1. 作りたいものを文章で入力
2. AIがコードを生成
3. ブラウザ上でプレビュー
4. そのまま修正と公開

という流れで進められます。

つまり Bolt.new は、

「まず現物を最速で見たい」

というVibe Codingの考え方に最も合ったツールです。

始める前の準備

Bolt.new を使う前に、最低限確認しておきたいポイントがあります。

1. ブラウザ環境を整える

推奨されるのは Chrome や Edge などの Chromium系ブラウザです。 拡張機能やVPNが干渉することがあるため、動作が不安定なときはシークレットモードで試すと切り分けしやすくなります。

2. 最初から大きいものを作ろうとしない

Bolt.new は非常に便利ですが、最初から複雑なシステムを作ろうとすると失敗しやすくなります。

まずは

• 店舗検索
• クーポン表示
• 簡易在庫検索
• フォーム入力画面

のような、1画面で完結するミニアプリから始めるのが基本です。

最初は小さな1画面アプリから始める

Vibe Codingで重要なのは、最初から完成品を目指すことではありません。

大切なのは、

まず小さく作って、動くものを確認すること

です。

たとえばリテールの現場なら、次のような題材が向いています。

• SKUを入力すると在庫が表示されるアプリ
• 簡単なキャンペーン応募フォーム
• 3店舗分の在庫ステータス確認画面
• CSVを読み込んで一覧表示する画面

こうした小さなアプリは、Bolt.new の強みである 短時間で現物を見せるという価値を最大化できます。

Plan / Discussion / Build の使い分け

Bolt.new をうまく使うには、モードの使い分けが重要です。

Plan

要件整理や方針決めをするモードです。 コードをすぐに書かせるのではなく、

• 何を作るのか
• どんな画面構成にするのか
• 何をやらないのか

を固めるのに向いています。

Discussion

途中で迷ったときや、エラーの原因を整理したいときに使います。 コードをすぐ変えずに、会話で整理するためのモードです。

Build

実際にコードを生成・修正するモードです。 方針が固まってから短く具体的な指示を出すと、余計な変更を防ぎやすくなります。

この3つを順番に使うことで、

Plan → Discussion → Build

という、失敗しにくい開発サイクルを作れます。

良いプロンプトの作り方

Bolt.new に指示を出すときは、抽象的に書くよりも、 目的・入力・出力・ルール・安全を明確にすると精度が上がります。

例えば、在庫検索アプリなら次のように書けます。

目的：店舗スタッフが在庫状況をすぐ確認できるようにしたい
入力：SKUコード
出力：3店舗の在庫数とステータスを表示
ルール：ログイン機能は不要、CSV読み込みで動作
安全：既存データの上書きは禁止

ポイントは、曖昧な言い方を減らして、具体的な入出力を示すことです。

「いい感じに作って」よりも、

• 誰が使うのか
• 何を入力するのか
• 何を表示したいのか
• 何をしてはいけないのか

を明記した方が、意図通りの出力になりやすくなります。

在庫検索アプリを作る流れ

ここでは、リテール現場で使いやすい題材として 在庫問い合わせアプリを例にします。

1. Planで要件を整理する

まずは「店舗スタッフがSKUを入力し、3店舗の在庫数とステータスを確認できる画面を作りたい」と伝えます。

このとき

• 目的
• 対象ユーザー
• 必要な項目
• 不要な機能

を一緒に書くと、計画がブレにくくなります。

2. 提案された構成を確認する

AIが提案する画面構成やファイル構成を確認し、 「不要な機能はないか」「足りない要件はないか」を見ます。

ここでしっかり整理することで、後の手戻りが減ります。

3. Buildで実装する

方向性が決まったら Build に進みます。 生成された画面を見ながら、

• 表示項目を増やす
• ラベルを修正する
• 色やUIを整える

といった微調整を重ねます。

4. 動かして確認する

重要なのは、文章で議論し続けることではなく、 実際の画面を見ながら直すことです。

これこそが Vibe Coding の本質です。

公開とGitHub連携

Bolt.new では、作ったアプリをすぐに公開したり、GitHubに連携したりできます。

Publish

検証用URLをすぐ発行できるため、チームに共有してフィードバックをもらいやすくなります。

GitHub Sync

コードをGitHubに保存しておけば、履歴管理やバックアップができます。 Vibe Codingはスピードが出る反面、変更が大きくなりがちなので、GitHubを台帳として使うのが安全です。

PR運用

実運用に近づいたら、Pull Request ベースでレビューする流れに移るのが理想です。

つまり

Bolt.new で試作
↓
URL共有
↓
GitHubに同期
↓
レビューして改善

という流れが、現場で最も使いやすい型になります。

まとめ

Bolt.new は、Vibe Codingを体験するために最も分かりやすいツールです。

• ブラウザだけで使える
• 最速で現物を作れる
• 小さなアプリから始めやすい

そして成功のポイントは、

• 最初は1画面の小さなアプリにする
• Plan → Discussion → Build の順で進める
• 目的・入力・出力・ルールを明確に書く

ことです。

次回の記事では、

Vibe Codingで失敗しないためのプロンプト設計

をさらに詳しく解説します。