Bolt.newの評判と料金プラン徹底解説：向いている人と制限事項
Bolt.newは月額$25から利用できるブラウザ完結型AIアプリ開発ツールです。データベースやトークンの上限、どのようなプロジェクトに適しているのかを整理し、Lovable、Replit、Cursorとの違いや乗り換え判断の基準を詳しく解説します。
Bolt.newは、要件が明確なWebアプリのアイデアを公開可能なプロトタイプへと迅速に落とし込み、生成されたコードの確認をいとわない個人創業者にとって、月額$25を支払う価値が十分にあります。しかし、本格的な本番稼働システム、デザイン重視で非エンジニア主導のワークフロー、あるいは手動での復旧が許されない重要なデータベースを抱えるプロジェクトには向きません。Boltのプロジェクトロールバック機能は、現時点でもデータベースを復元できないためです。
Bolt.new 評判と全体像：何ができるツールなのか
Bolt.newは、文章による指示（プロンプト）を編集可能なアプリケーションコードに変換し、オンラインの開発環境で即座に実行できるブラウザ完結型のアプリ構築ツールです。事前に各種サービスを個別契約・設定することなく、データベース、認証機能、ホスティング環境をワンストップで追加できます。ノーコードビルダーとAIコーディングエディタの中間に位置しており、対話を通じて構築を進められる一方で、最終成果物はGitHubへと移行可能な独立したコードベースとなります。そのため、プロンプトだけで設計判断のすべてを外部委託する用途ではなく、プロトタイプ、社内ツール、明確にスコープが絞られたWebプロダクトの構築において最大の真価を発揮します。
現在の製品仕様は、初期にリリースされたものから大きく進化しています。Boltのリリースノートによると、v1 AgentおよびDiscussion Modeは2026年8月3日に廃止されました。既存プロジェクトはファイルとチャット履歴を保持したままBolt Agentへ移行され、コードを即座に変更することなく構築方針を検討する場としてPlan Modeが導入されました。また、音声入力（Voice dictation）にも対応しており、話した内容が編集可能なプロンプトとして書き起こされてから送信される仕様となっています。
Bolt.newと主要代替ツールの比較一覧
プロンプト入力、コード生成、データベース、初期デプロイまでを単一のブラウザワークフローで完結させたい場合、Bolt.newが最有力候補となります。コードレベルの制御よりも見た目の洗練さやチームでのスムーズな共同作業を重視するならLovableが優れています。Replitはより広範なブラウザ開発ワークスペースを提供し、すでに対象リポジトリを保有しており、オールインワンのビルダーではなくAIネイティブなコードエディタを求める熟練エンジニアにはCursorが適しています。
この比較表には重要な背景が隠されています。Bolt.new、Lovable、Replitはいずれもゼロからの新規立ち上げを支援するツールですが、Cursorはユーザー自身がコードを直接扱うことに慣れている前提で設計されています。月額料金だけで比較すると、引き継ぎや運用の実質コストを見落とすことになります。非エンジニアの創業者がLovable Proに同じ$25を支払えば、何時間にも及ぶコード検証の手間を省ける可能性があります。一方、エンジニアであればCursorに$20を支払い、メッセージを送信するたびに肥大化したプロジェクト全体をAIに再読み込みさせる無駄なコストを回避できるでしょう。
本レビューの指針は明快です。「プロジェクトにおいて最も複雑で困難な部分を、明確に可視化できる環境を選ぶ」ということです。Boltはインフラを可視化しGitHubへ卒業させやすくします。Lovableはデザインと共同作業を可視化します。Replitは幅広い開発ワークスペース環境を可視化し、Cursorはコードそのものを可視化し続けます。
Bolt.newが向いている人・向いていない人
Bolt.newは、最初の実動バージョンを素早く手に入れることに価値を見出しつつも、その成果物を完成品と混同しない開発者に向いています。最適な購入者は、ワークフローが明確に定義されており、データ構造や権限要件を言語化でき、生成されたコードを自ら検証できる（あるいは検証できる人を巻き込める）人物です。逆に最も不向きなのは、受け入れ基準のない巨大な製品アイデアを抱え、機密データを扱い、プロンプトを重ねればアーキテクチャ上のあらゆる問題が魔法のように解決すると信じている人です。
適しているケース：単一のワークフローを検証したい個人創業者
開発チームを雇用する前に、限定されたワークフローの実現性を検証したい個人創業者にとって、Bolt.newは非常に合理的です。たとえば、個人指導講師向けのスケジュール管理サービスを立ち上げる場合を考えてみましょう。最初の実用的なバージョンに必要なのは、講師のプロフィール、予約枠、予約フォーム、確認メール、そして簡易な管理者ダッシュボード程度です。これらは、データベース、認証、ホスティングされたUIへと綺麗に落とし込めます。
創業者はユーザーの役割（ロール）を言語化し、テーブルやログインフローの作成をBoltに指示し、非公開または公開のプレビューを発行し、初期ユーザーを招待する前にコードをGitHubへ退避できます。本番運用にはテストやセキュリティ判断、保守が不可欠ですが、Boltはアイデアから実際にクリック可能な成果物までの距離を劇的に短縮してくれます。
ただし、権限チェックをフロントエンドUI側で行うべきか、データベース側で制限すべきかの区別がつかない場合、この運用は破綻します。不正なユーザーに対してボタンを非表示にするだけの処理と、堅牢な行レベルセキュリティ（RLS）ポリシーを設定することは全くの別物です。Boltはその両方を生成できますが、それが適切に機能しているかを検証するのは人間の責任です。
適しているケース：開発着手前に仕様を検証したいプロダクトマネージャー
静的なモックアップを何枚も作成する代わりに、実データが連動する説得力のあるプロトタイプを必要としているプロダクトマネージャー（PM）にもBolt.newは適しています。たとえば返品承認ツールを作成する場合、承認待ちキュー、顧客レコード、返品理由コード、役職に応じた実行アクションなどを組み込むことが可能です。エンジニアのスプリントが始まる前に、関係者が実際のフローを操作して、想定外の考慮不足や状態の欠落を発見できます。
プロダクトマネージャーは、生成されたアプリケーションを「実行可能なディスカバリーツール」として扱う必要があります。最大のメリットは、プロトタイプをそのまま本番環境に流用することではなく、仕様変更のコストが極めて低いうちにワークフローの妥当性を検証できる点にあります。GitHubに連携することでエンジニアがレビューするための有用な成果物にはなりますが、それ自体が承認済みの本番アーキテクチャに変わるわけではありません。
適しているケース：明確な引き継ぎ方針を持つ小規模受託会社
すべてのプロジェクトにおいて終了基準や引き渡し方針が徹底されている場合、小規模な制作会社や受託開発チームがキャンペーン用ツール、見積もり計算機、顧客ポータル、プロトタイプを構築する手段としても有効です。案件開始時に、成果物をBoltのホスティング上に残すのか、クライアント自身のリポジトリへ移行するのか、それとも完全なカスタム開発へ切り替えるのかをあらかじめ決定しておく必要があります。この判断によって、ドメイン、シークレット環境変数、データベースのバックアップ復旧、将来の保守体制の責任分界点が決まります。
Teamsプランの機能は、組織内でのアクセス管理やデザインシステムの共有を一元化するのに役立ちますが、メンバーごとの課金体系には注意が必要です。各メンバーに個別のトークン枠が付与され、それらのトークンはチーム内でプール（合算共有）されません。一人のメイン開発者が精力的に作業し、他のメンバーがレビューを中心に行う場合、主要な開発者のトークンが不足している横で、他のメンバーの未使用枠に無駄な費用を払い続けることになります。
見送るべきケース：デザイン重視・非エンジニア主導のチーム（Lovableを選択）
チームが見た目の洗練されたUI、共有可能な開発容量、そしてコードを意識しない意思決定プロセスを望んでいるなら、Lovableへ乗り換えるのが賢明です。Lovable Proは月額$25で100クレジットが付与され、ユーザー数は無制限、クレジットの翌月繰り越し、追加購入、カスタムドメイン、ロール管理、メンバーごとのクレジット制限、メールサポート、デザインシステムに対応しています。
この「ユーザー数無制限」という設計は、1メンバーあたり月額$30を請求するBolt Teamsプランとは対照的です。Lovableの共有クレジットが自動的により多くの利用枠を提供するわけではなく、クレジットの消費単位もBoltのトークンと直接比較できるものではありません。しかし組織面での利点は明確です。創業者、デザイナー、マーケターが、アカウント追加ごとの基本料金を支払うことなく、1つのProワークスペースで共同作業を行えます。
「チーム全員でこの画面UIを直接ブラッシュアップできるか？」を最優先するならLovableを選んでください。「同一のブラウザ上で実動するコードベース、インフラ、GitHubへの引き継ぎまでを完結させたいか？」が重要ならBoltを選択します。チーム内にコードを検証できる人が一人もいない場合、Boltの細やかな制御機能は使いこなせない余剰能力となってしまいます。
見送るべきケース：広範なクラウド開発環境を求める場合（Replitを選択）
汎用的なブラウザ開発環境、エージェントの並列処理、小さな実験から本格的な管理型開発ワークスペースへの拡張性を求めるなら、Replitを選択すべきです。Replit Coreは月額$20（年払い時は月額$18）で利用でき、2つの並列エージェント、無制限のワークスペース、最上位モデルに充当できる$20分のクレジットが含まれています。
より上位のプランを比較すると、その違いはさらに明白になります。Replit Proは月額$100（年払い時は月額$90）で、10の並列エージェント、最大15人の共同編集者、最大50人の閲覧者、そして最長28日間のデータベースロールバック機能を備えています。一方、Boltの組み込み機能であるプロジェクト履歴（Version History）では、データベースを一切復元できません。
これはReplitがあらゆる面で優れているという意味ではありません。複数の並列エージェントや仕様として保証されたデータベース復元機能を重視するなら、Boltのシンプルな$25の開始プランよりも、そうした要件を優先すべきだということです。プロンプトからアプリへの直線的な構築ならBoltを、開発ワークスペースそのものを購入したいならReplitを選びましょう。
見送るべきケース：すでに既存リポジトリがある場合（Cursorを選択）
すでにアプリケーションのリポジトリを保持している経験豊富なエンジニアには、Cursorが最適な選択肢です。Cursor Individual Proは月額$20で、Agentの制限を引き上げつつ、フロンティアモデル、MCP、スキル、フック、クラウドエージェントを利用できます。
Cursorはホスティング、認証、データベースの選定を代行してくれませんが、そうした基盤決定がすでに済んでいる状況においては、まさにそのシンプルさこそが強みとなります。アプリビルダーにプロジェクト全体を都度同期させて再解釈させる無駄を省き、エンジニアがリポジトリを直接編集できるからです。
作業フェーズが「プロダクトの全体像をゼロから模索する」段階から、「確立されたアーキテクチャとレビュー規準のもとで既存コードを修正する」段階へと移行したなら、迷わずCursorへ移行してください。コードを直接所有・管理する作業が中心になる場合は、Codex、Claude Code、Cursorの比較記事もあわせて参考にしてください。
機能解説1：データベースとホスティングを備えたフルスタック試作
Bolt.newの真の強みは、単に綺麗な画面を1ページ生成することではありません。画面UI、データベース、認証機能、初期デプロイ環境を同一のコンテキスト内に密結合させ、1人の担当者が一連のワークフロー全体を検証できる点にあります。そのため、見た目の良さだけが求められるマーケティング用モックアップよりも、問い合わせポータルや予約システムのような実用ツールの構築に向いています。
例として、メールと表計算ソフトで行っていた受付業務をリプレイスする、地域密着型ホームサービス企業の管理ツールを考えてみます。このツールには、顧客向けフォーム、受付レコード、配車担当者用キュー、技術者への割り当て、ステータス履歴が必要です。効果的なBoltの使い方は、「モダンなサービスアプリを作って」と曖昧に頼むのではなく、エンティティや権限の定義から始めることです。
ワークフローとロールを定義する
顧客、配車担当者、現場技術者の各ロール（役割）を言語化します。案件が遷移する各ステータス、各ロールが閲覧できる情報、ステータスを進めるための実行アクションを定義します。これにより、AIに単なる雰囲気ではなく振る舞いの論理モデルが伝わります。
データモデルを明示的に要求する
顧客、サービスリクエスト、割り当て、ステータスイベントの各テーブル作成を指示します。プロジェクトの進行に合わせてBoltは自動でデータベースを作成できますが、モデルを明示することでコードの検証が容易になり、重要な状態がフロントエンドだけに保持されるミスを防げます。
認証と認可のルールを指定する
メールによる会員登録、ログイン、パスワードリセット、ロールベースのアクセス制御（RBAC）の実装を指示します。Boltの公式ドキュメントにある通り、データベースが作成されても認証機能は自動的に追加されない場合があります。公開プレビューを発行する前に、リダイレクトURLや権限設定を必ず検証してください。
検証用のプレビューを公開する
Freeプラン、Proプランのいずれでも
.bolt.hostドメインへの公開が可能です。初期データは使い捨て前提で運用します。実際の配車担当者を招き、案件の受付から割り当て、完了までの流れを一通り操作してもらい、不足している画面状態やエラーハンドリングをすべて洗い出します。重要データを扱う前にコードを退避する
安定した最初のワークフローが完成したら、速やかにGitHubへ接続します。実際の顧客データが蓄積されてから、プロジェクトコード、データベース、本番デプロイの分離方法に頭を悩ませるような事態は避けなければなりません。
Bolt Databaseは初期セットアップの労力を大幅に削減します。アプリの必要に応じてデータベースをプロビジョニングし、認証制御を含み、ログやシークレットを管理画面に表示するほか、セットアップ時にSupabaseを選択することも可能です。Boltがデータベースを作成した場合、漏洩パスワード保護（Leaked-password protection）はデフォルトで有効になります。一方、Supabaseを直接連携またはクレームした場合はSupabaseの契約プランに依存し、Supabase Freeプランではこの保護機能は無効となります。
ここで極めて重要なのは、「自動生成された機能」と「実際に検証された挙動」を厳密に区別することです。ログイン画面が正常に表示されていても、パスワードリセット後のリダイレクト先が誤っていることがあります。また、配車キューのUI上では他人のレコードが隠されていても、データベースポリシーの不備によりAPI経由でアクセスできてしまうケースもあります。Boltの認証設定にはサイトURL、URI許可リスト、プロバイダ、メールテンプレートが用意されていますが、それらを精査するのは人間の役目です。
デプロイの仕様も手軽ですが制限が存在します。Freeホスティングでは.bolt.hostドメインが提供され、帯域幅は10GB、月間リクエスト数はアカウント全体で333,333回に制限されます。Proプランでは30GBの帯域幅、月間100万リクエストに拡張され、カスタムドメインの接続や従量課金によるトラフィック超過への対応が可能になります。小規模アプリの概念実証には十分な容量ですが、これらは「アカウント全体での合算枠」であるため、複数プロジェクトをホストしている場合は枠を奪い合うことになります。
そして最大の壁となるのが、障害発生時の復元です。BoltのプロジェクトVersion Historyは、データベースの復元に対応していません。アプリケーションのファイルを昨日の状態にロールバックしても、データベースは今日の変更されたスキーマやデータのまま取り残されます。この不整合は、コードとデータが同時に戻ると誤認させやすいため、復元ボタンが一切ない状態よりもかえって危険です。
先ほどのホームサービスの例で言えば、ステータス名の変更前にアプリコードだけを巻き戻し、データベース側のスキーマが新しいまま残ってしまうと、UIとデータ構造の不整合によってシステムが動作しなくなります。プロジェクトが重要な段階に入る前に、Boltのタイムライン機能に依存しない独立したデータベースバックアップ、スキーママイグレーション、復元テストの手順を必ず確立してください。
機能解説2：GitHub連携によるコードの完全所有
Bolt.newが囲い込み型のノーコードツールより優れている理由は、生成されたアプリケーションをGitHubで管理し、他のホスティングや開発環境へと自在に移行できる点にあります。ただし、この可搬性（ポータビリティ）は早期に実践してこそ意味を持ちます。リポジトリに一度も連携せず、どのコミットが稼働中のデータベースに対応しているか誰も把握していない状態では、「コードのエクスポートが可能」という仕様は何の復旧プランにもなりません。
BoltのGitHub連携ドキュメントによると、Boltプロジェクトから作成されたリポジトリはmainブランチの非公開設定で開始されます。Boltはプロジェクトを破損させない変更を自動的にコミットし、30秒ごとにGitHubの外部更新をポーリング検知し、ブランチの新規作成や切り替えに対応しています。
推奨される引き継ぎワークフローは以下の通りです。
最初の安定版ができた段階で連携する
プロジェクトがまだ使い捨て可能な初期段階でリポジトリを作成します。必要な構成ファイル、環境変数のサンプル（.env.example）、依存関係の定義ファイルが存在することを確認します。APIキーなどのシークレットは絶対にリポジトリへ含めないでください。
意味のある変更ごとにブランチを切る
決済機能の追加、権限設定の変更、画面のリニューアルなど、大きな変更ごとにブランチを分けます。Boltはブランチごとにコンテキストを分離して保持するため、未検証の変更が本番ラインに誤って混入するリスクを低減できます。
GitHub上でレビューしてマージする
Boltはブランチの作成や切り替えは行えますが、アプリ内でのマージには非対応です。プルリクエストを作成し、エンジニアが差分を精査してGitHub上でマージを実施します。これにより、決定の履歴がリポジトリ側に明確に残ります。
再度プロンプトを打つ前に状態を同期させる
マージされた最新状態がBolt側に反映されるのを待ち、対象のブランチを開いてプレビューを確認します。Boltは30秒ごとに外部の変更を検知しますが、これから変更を加えようとしている状態を自分の目で確認することの代わりにはなりません。
この運用ルールを守ることで、Boltは「抜け出せない囲い込み環境」ではなく「優れた立ち上げ環境」として機能します。エンジニアはBoltを離れてリポジトリを直接編集し、別のインフラにデプロイし、必要に応じて再びBoltに戻ることができます。これは、プロトタイプが成長し、テストコード、可観測性の導入、インフラ構成の見直し、別のバックエンドへの移行が必要になった際に極めて強力な武器となります。
ただし、これを「一般的なGit運用の完全な代替」と見なす前に、2つの制約を認識しておく必要があります。第1に、ブランチのマージはBolt外（GitHub上）で行わなければならないため、非エンジニア主導のチームであってもプルリクエストの概念を理解しているか、対応できる担当者が必要です。第2に、極めて稀な同期競合の挙動として、BoltとGitHubがほぼ同時に更新された場合、Bolt側の変更が優先されGitHub側の内容が上書きされる仕様となっています。
過度に恐れる必要はありませんが、適切な管理意識が求められます。Boltと外部エディタの双方から、同一ブランチに対して同時に変更を加える運用は避けてください。ブランチを適切に使い分け、GitHub経由でマージを行い、リポジトリを唯一の信頼できる情報源（Single Source of Truth）として位置付ける必要があります。複数人のエンジニアが定常的にコミットするフェーズに達したら、Boltはワークフローの「起点」の一つにとどめ、システム管理の中心に据えるべきではありません。
機能解説3：Expoを活用したモバイルアプリ開発
Bolt.newはExpoを経由してクロスプラットフォームのモバイルアプリ開発を開始できますが、最初のプロンプト入力が成否を分けます。BoltのExpo連携ガイドにある通り、Web向けとして開始したプロジェクトを後からモバイルアプリへ簡単に変換することはできません。つまり、「これをスマホアプリにして」という指示は単なる仕上げの追加要望ではなく、根本的なアーキテクチャの変更を意味します。
たとえば献立管理アプリを作成する場合、最初のプロンプトで「iOSおよびAndroid向けのモバイルアプリであること」を明記し、世帯データやレシピの構造、重視すべきスマートフォン特有の操作感を指示する必要があります。これによりBoltは、単一のコードベースからモバイルとWebの双方をターゲットにできるフレームワーク「Expo」を採用して構築を開始します。
実機でのプレビュー確認は非常にスムーズです。モバイルプロジェクトを開き、「Device Preview」を選択して表示されたQRコードをExpo Goアプリでスキャンするだけで、手元のスマートフォン上でアプリを直接操作できます。これにより、PCのブラウザプレビューでは見落としがちな画面レイアウト崩れ、ソフトウェアキーボードの干渉、画面遷移、タッチ領域の不具合を即座に発見できます。
一方、各アプリストアへの本番リリース作業はBolt内だけで完結しません。App StoreやGoogle Playで正式公開するには、コードをダウンロードし、Node.js LTSおよびGitがインストールされたPCのローカルエディタで開き、Expo Application Services（EAS）を設定し、AppleやGoogleのDeveloperアカウントを管理する必要があります。また、電子署名、プラットフォーム固有の依存ライブラリ、各ストアの審査ガイドラインへの抵触によってビルドや審査が失敗することもあります。
この境界線は、誰がそのアプリを所有すべきかを浮き彫りにします。創業者はSwiftやKotlinを習得していなくても、Boltを使ってモバイル向けユーザー体験の妥当性を素早く検証できます。しかし、ストア公開を目指すなら、証明書の管理、ストア掲載情報の整備、プライバシーポリシーの策定、クラッシュログの解析、プラットフォーム審査への対応を主導できる担当者が不可欠です。Expoは開発プラットフォームの重複を排除してくれますが、プラットフォーム固有の運用管理タスクまで消し去ってくれるわけではありません。
推奨するモバイル開発ステップ：
最初のプロンプトでモバイル開発であることを宣言する
コード生成が始まる前に、iOSとAndroidへの対応、主たるスマートフォン操作、オフライン時の挙動、カメラ・通知・位置情報の利用有無を明示します。
早期から実機スマートフォンで検証する
Expo Goを初期段階から活用します。献立を選択し、材料を追加し、アプリを再起動した後に保存されたデータが正しく復元されるかなど、最小限の完全な利用パスを実機でテストします。
ストア申請の準備前にコードをエクスポートする
各ストアの認証情報を設定する前に、コードをGitHubおよびローカルの開発環境へ移行します。リリースプロセスに投入する成果物は、リポジトリ側でレビュー済みのコードでなければなりません。
ストア申請・運用の責任者を決める
証明書の更新、TestFlightやGoogle Playのテストトラック運用、リリースノートの作成、プライバシー要件の確認、クラッシュ解析を担当する明確な責任者を定めます。担当者が不在の場合、そのプロジェクトは実運用可能なアプリではなく、単なるプロトタイプにとどまります。
ユーザー体験のフロー検証が目下の最重要課題である場合は、モバイル用途でもBoltを選択する価値があります。一方で、ネイティブ固有の高度な挙動、バックグラウンド処理、深いハードウェア連携、厳格なストア配信パイプラインの構築こそが課題の中心である場合は、Bolt単体に頼るべきではありません。
機能解説4：デザインシステムを活用したチーム開発
Bolt.newのデザインシステム機能は、すでに共通コンポーネント、スペーシングルール、ブランドガイドラインを保有しているチームにおいて真価を発揮します。ただし、ラフなスタイルガイドを自動的に再利用可能な本番コンポーネントへ変換してくれるわけではありません。インポート元となるソースの品質によって、Boltが本格的なコンポーネントライブラリとして活用できるか、単に色味やフォントを模倣するだけにとどまるかが決まります。
カスタムデザインシステムの読み込みには有料のTeamsプランが必要です。チームはGitHubリポジトリ、NPMパッケージ、Storybook、ドキュメントサイト、あるいはローカルのアップロードファイルをソースとして指定できます。Boltはこれらのソースを解析し、Bolt環境内にStorybookを自動生成するため、開発者は認識されたコンポーネントを視覚的に確認しながら作業を進められます。
最も効果的なのは、ボタン、入力フォーム、ナビゲーション、データテーブルなどのUIコンポーネントをすでにNPMパッケージとして管理しているB2Bソフトウェア企業での運用です。該当のパッケージを登録し、対応するStorybookを連携させ、「非推奨のコンポーネントは除外する」「特定のテーマのみを使用する」といったエージェント向け指示を与えます。これにより、プロダクトマネージャーは汎用的なUIではなく、自社固有のデザインシステムに準拠したプロトタイプを即座に作成できます。
Boltの公式ガイドでも、ソースの品質について率直な見解が示されています。ドキュメントサイト単体よりも、GitHubリポジトリやNPMパッケージの直接連携のほうが安定した結果を生み出します。スクリーンショットや説明文だけのサイトは見た目の雰囲気を伝える程度ですが、実装コードを含むコンポーネントパッケージを読み込ませることで、AIが正確にコードを再利用できるようになるためです。
運用上の制限も存在します。有料チームは、週あたり合計10個までのデザインシステムを追加・同期できます。ローカルファイルからのソース追加は、PDFや画像など最大10ファイルまでに制限されています。異なるフレームワークの混在や過去の古いコード、矛盾するガイドラインを含めると生成精度が低下するため、ソースの数をむやみに増やせば良いというものではありません。
基準となる単一のコンポーネントソースを選ぶ
プロダクトチームが公式として運用しているリポジトリやNPMパッケージを起点とします。非推奨の旧ライブラリと最新ライブラリを同一のソースセットに混在させないでください。
装飾ではなく判断基準を記したドキュメントを添える
各コンポーネントの使い分け、アクセシビリティの考慮事項、テーマ適用のルールを記述したガイドラインを用意します。画面キャプチャだけでは、コンポーネントの振る舞いや制約をエージェントに理解させることはできません。
エージェントへの指示をシンプルかつ具体的に絞り込む
準拠すべきフレームワーク、テーマ、パッケージのバージョン、使用を禁止するコンポーネントを明確に指示します。曖昧な実例を大量に与えるよりも、的を絞った除外ルールを設けるほうが効果的です。
代表的な一連の画面フローを1つ作成して検証する
入力フォーム、バリデーションエラー表示、初期の空状態（Empty state）、検索結果一覧などを含むフローを1つ生成します。全体に展開する前に、実際のコンポーネント構造や挙動が社内基準に沿っているかを精査します。
すでにコンポーネントコードを保有しており、ブランドに準拠したプロトタイプを素早く起こすことで手戻りを大幅に削減できる企業にとって、この機能はTeamsプランの費用を正当化する理由になります。一方で、ロゴとフォントの指定があるだけで再利用可能なコンポーネント資産を持たない創業者が、メンバーあたり月額$30を支払う意義は薄いと言えます。Lovable Proであれば月額$25で無制限のユーザーにデザインシステム機能を提供しています。Boltの価格差に見合う価値が得られるのは、コードレベルでのソース管理とBoltの総合的なインフラ構築環境の両方を必要とする場合に限られます。
Bolt.newの料金体系：全プランと成果あたりのコスト算出
Bolt.newの月額料金体系は明快です。Free（$0）、Pro（月額$25）、Teams（1メンバーあたり月額$30）、そしてカスタムのEnterpriseで構成されています。実質的な課題となるのは、トークン消費量、共有ホスティング枠の制限、メンバー数によって、この基本料金が「完成した成果物あたりのコスト」へどのように跳ね返ってくるかを予測することです。
以下の価格と利用制限は、2026年8月27日時点でBoltの公開価格ページに記載されている情報に基づいています。年払いにより最大28%の割引が適用される旨が記載されていますが、「最大」という表現はすべてのプランに一律適用される年間レートではないため、ここでは月額払いの数値を正確な比較基準として記載します。年払いの正確な見積もりはアカウント内の購入画面をご確認ください。
Freeプラン：実用的なホスティング枠を備えた試用プラン
Freeプランには、公開および非公開プロジェクトの作成、無制限のデータベース作成、.bolt.hostへのデプロイ、月間100万トークン、そして1日あたり300,000トークンの上限が含まれています。Boltの計画策定、生成、公開のプロセスを理解するには十分な枠です。しかし、1日あたりの消費上限に達すると月間枠が残っていても作業が中断されるため、プロンプトを多用する本格的な開発を完了させる手段としては頼りになりません。
ホスティング面でも注意すべき制限があります。Freeプランにはアカウント全体で月間10GBの帯域幅と333,333回のリクエストが含まれています。月間データ制限に達すると、リセット日までサイトのコンテンツ配信が完全に停止します。使い捨てのプレビュー確認であれば許容できますが、常にアクセス可能であるべきビジネス検証用途には適していません。
Proプラン：個人開発者の標準的な選択肢
Proプランは月額$25で、1日あたりの上限なしに月間1,000万トークンから利用を開始できます。Boltのブランド表示が消去され、ファイルアップロード上限は100MBに拡張、非公開共有、カスタムドメイン接続、SEO Boost、外部データベースプロバイダの選択、AI画像編集が利用可能になります。ホスティング環境はアカウント全体で帯域幅30GB、月間100万リクエストまで提供されます。
有料プランで余ったトークンは翌月に1ヶ月間だけ繰り越され、有料契約が有効である限り最大2ヶ月間利用可能です。「Boltの有料トークンは繰り越されない」という過去の情報は現在では誤りです。なお、Freeプランのトークンは繰り越し対象外です。
Proユーザーは従量課金設定（利用上限額の設定が可能）を行うことで、標準枠を超えてサイトのトラフィックを維持できます。ただし、公開ページには超過分の単価が明記されていないため、上限設定によるリスク回避はできても、公開情報だけでトラフィック急増時の請求額を正確に算出することは困難です。
トークンの追加購入にも前提条件があります。Boltの規約上、トークンのチャージは上位の月額Proプランまたは年間契約のProプランでのみ利用可能です。追加費用は契約プランによって異なり、管理画面内でのみ開示されるため、公開されている$25の基本料金だけで高負荷利用時の総予算を設計することはできません。
Teamsプラン：共有プールではなく「人数課金」の仕組み
Teamsプランは1メンバーあたり月額$30です。課金対象となる各メンバーに個別のトークン枠が付与され、それらのトークンはチーム全体でプール（合算共有）されるのではなく、個々のメンバーに紐づいたままとなります。請求の一元化が、開発リソースの共有を意味するわけではありません。
この仕組みは、全員が日常的にアプリを構築する開発チームには適しています。しかし、1人の担当者が集中的に構築し、他のメンバーが主にレビューを行う構成では極めて非効率です。4人チームの場合、追加トラフィックやトークン追加、外部連携サービスを除いた基本料金だけで月額$120、年間$1,440が発生します。
Lovable Proが月額$25（年額$300）で人数無制限の共同編集環境を提供しているのに対し、Boltで4人チームを組むと年間$1,440かかり、その差額は月額$95、年間$1,140に達します。Lovableは100クレジットをチーム全員で共有する形式であり、Boltは個別にトークン枠が付与され独自のインフラ連携ワークフローを持つため、利用容量を直接比較することはできません。それでもこの比較は、購入判断における重要な基準を浮き彫りにします。複数人が実際にBolt上で手を動かして開発するか、あるいはチーム管理機能やデザインシステム連携によって引き継ぎコストが劇的に削減される確証がある場合にのみ、このメンバー単価を支払う価値があります。
Enterpriseプラン：ガバナンス要件が明確な組織向け
Enterpriseプランは個別見積もりとなっています。高度なセキュリティ、SSO、監査ログ、コンプライアンス対応、カスタムワークフローおよびSLA、データガバナンスと保持ポリシー、専任の導入支援、24時間365日の優先サポートが提供されます。
これらの統制機能を必要とする企業は、メンバーあたり$30のTeamsプランを基準に見積もりを立て、後から調達部門に対応させようと考えてはいけません。Enterpriseプランでしか満たせない要件を前提とした実証実験を行う前に、必ず公式のEnterprise見積もりを取得してください。
成果物あたりのコスト算出方法
完成したプロトタイプ1件あたりのツールコストを算出するには、基本利用料を「事前に定義した受け入れ基準をクリアしたプロトタイプ数」で割るのが最も確実です。プロンプトの送信回数は単なる活動量に過ぎず、ビジネス上の成果指標ではありません。
Proプランを利用する個人創業者の場合、年間の基本利用料は$300です。仮に月に4件のプロトタイプが受け入れ基準を満たした場合、完成1件あたりの基本ツールコストは$6.25となります。月に1件しか完成しなかった場合、成果物あたりのコストは$25に跳ね上がります。この計算にはインフラ超過分、データベース利用料、外部API費用、人件費は含まれていませんが、「受け入れ完了率」という最も見落とされがちな変数を浮き彫りにしてくれます。
4人体制のTeamsワークスペースの場合、基本料金は月額$120です。月に8件の完成品を生み出せれば1件あたり$15となりますが、2件しか完成しなければ1件あたり$60に達します。ツール自体が高額になったわけではなく、承認基準をクリアした成果物の創出ペースが落ちたことが原因です。
導入判断を左右する7つの制限事項
Bolt.newの制限事項は、単なる機能不足にとどまりません。それらは共通する特定のタイミングで顕在化します。すなわち、「プロトタイプが実用段階に入り、複数人が関わり始め、データベースの重要性が増し、費用の予測可能性が求められる」フェーズです。この段階で安易に上位のトークン枠を追加購入すると、アーキテクチャの根本的な問題を一時的なリソース不足と見誤ることになります。
1. プロジェクトの成長に伴いトークン消費が急増する
Boltの公式見解によると、トークン消費の大部分はプロジェクトファイルの読み込みと同期処理に起因します。これは、プロジェクトが大規模化するほど、メッセージ1通あたりに消費されるトークン量が増加することを意味します。つまり、同じ内容の指示であっても、開発初期と終盤では終盤のほうが圧倒的にコストが高くなります。
そのため、プロンプトの送信回数だけで利用コストを予測することは極めて困難です。軽微なデザイン修正であっても関連コンテキスト全体の読み込みが必要になる場合があり、曖昧な機能追加指示を出せば、多数のファイルにわたる設計・変更・修正処理が走って大量のトークンが一瞬で消費されます。有料プランの翌月繰り越し機能は作業が少ない月の無駄を緩和してくれますが、巨大化したプロジェクトのトークン消費を抑えられるわけではありません。
これに対する実践的な解決策は、プロンプトの指示範囲を極限まで絞り込み、プロジェクト構造をモジュール化し、ルーチン的なファイル修正については指示文を書くよりも直接コードエディタで編集する運用へ切り替えることです。作業スコープが明確に制御できている段階でのトークン追加購入は合理的ですが、AIエージェントがアーキテクチャを見失って無関係なコードの修正を繰り返している状態でのトークン追加は、単なる費用の浪費です。
2. プロジェクトのロールバックでデータベースは復元されない
Boltのプロジェクト履歴（Version History）はファイル群を過去の状態へ戻す機能であり、データベースの復元には対応していません。以前のアプリケーションバージョンへロールバックしても、現在のデータベースはそのまま維持されます。これは、「フルスタックビルダー」という言葉を「フルスタックの自動復元環境」と誤解しているユーザーにとって、最も致命的な落とし穴となります。
コードとデータベーススキーマは密接に連動して変化します。AIによる生成コードの変更によってカラム名が変更されたり、認可ルールが更新されたり、データ移行が走った後に、アプリコードだけを過去の状態へ巻き戻すと、コードとデータのバージョン不整合が発生します。本番を見据えた運用には、データベース自体の定期バックアップ、マイグレーション管理、そしてコードとデータの双方を対象とした独立した復旧検証が不可欠です。
また、開発環境における小さな注意点もあります。非公開かつ長期間アクセスのない低トラフィックのデータベースは、6日以上経過すると一時停止状態となり、復帰に数分を要することがあります（公開中のデータベースは対象外です）。リソース管理としては一般的な挙動ですが、休眠状態のプロトタイプを使って顧客へいきなりライブデモを見せようとする場合、予期せぬ待ち時間が発生するリスクがあります。
3. GitHub連携は完全なGitワークフローの代替ではない
Boltはブランチの新規作成や切り替えに対応していますが、アプリ内でブランチをマージする機能はありません。マージ作業はGitHub上で行う必要があります。レビューをリポジトリ側で行うという観点からは健全な仕様ですが、「非エンジニアでもすべての操作をBolt内で完結できる」と期待しているとギャップを感じることになります。
さらに注意を要するのが、極めて稀な同期競合時の挙動です。Boltは30秒ごとにGitHubの変更を検知していますが、Bolt側とGitHub側でほぼ同時に変更がコミットされた場合、Bolt側の変更が優先されてGitHub側の内容が上書きされます。複数の作業環境から同一ブランチに対して同時に変更を加える運用は絶対に避けてください。ブランチを明確に分け、信頼できる情報源を単一に保ち、マージ責任者を固定する必要があります。
4. モバイルは開始こそ手軽だが、公開にはローカル開発環境が必須
最初のプロンプトでモバイルアプリを要求すればBoltはExpoを採用し、Expo Goを使ってスマートフォン実機での素早いプレビューを提供してくれます。しかし、Web向けとして開始したプロジェクトを途中でモバイル向けへスムーズに切り替えることはできません。この基本構造の判断は、開発の一番最初に確定させておく必要があります。
さらに、アプリストアへの申請・公開フェーズでは、シンプルなブラウザ環境から完全に抜け出す必要があります。コードをローカル環境にダウンロードし、Node.js LTS、Git、Expoツール群、Developerアカウント、証明書管理、ストア審査基準などを自前でハンドリングしなければなりません。ネイティブコードを個別開発するよりは遥かに効率的ですが、「ワンクリックでストア配信まで完了する」ツールではないことを理解しておく必要があります。
5. ホスティングの停止リスクと超過費用の予測難度
Freeプランの公開サイトは、アカウント合算のホスティング上限枠を使い切ると配信が完全に停止します。Proプランであれば利用上限額を設定した上で従量課金によるトラフィック維持が可能ですが、公開プランページには超過分の従量単価が明記されていません。管理画面にログインして上限を設定することで突発的な高額請求リスクは防げますが、契約前にアクセス増加時の正確なコストシミュレーションを立てることは困難です。
また、提供枠はアカウント全体で合算されます。複数のクライアント向けプレビューやキャンペーン用ツールを同一アカウントで公開している場合、アクセスが集中した1つのプロジェクトが、他のすべてのプロジェクトの利用枠を圧迫することになります。制作会社などで運用する場合は、クライアントごとにアカウントを分離するか、アカウント全体のトラフィック消費を綿密に監視する必要があります。
6. サポート体制は障害発生時の対応レベルで差別化されている
Boltのサポート窓口は、Freeユーザーに対してはDiscordコミュニティのみとなっています。有料プランのユーザーは平日の営業時間内にメールでのサポートを受けられます。24時間365日の優先サポートや専任のアカウント対応が提供されるのはEnterpriseプランのみです。
SaaSの料金体系としては一般的ですが、導入判断においては重要な意味を持ちます。夜間のシステム障害に対して契約に基づく迅速な復旧対応が求められるような本番稼働システムは、月額$25のProプランや月額$30のTeamsプランのサポート範囲外です。厳格なサポート要件を求めるなら、Enterpriseプランの個別契約に進むか、サポート体制が整った独立した運用インフラへコードを移行させる必要があります。
7. チーム統制機能と費用対効果の乖離
Teamsプランはアクセス制御、デザインシステム連携、一括請求などの便利な機能を提供しますが、価格表において最もクリティカルな統制機能群（SSO、監査ログ、コンプライアンス支援、データ保持ポリシー、個別SLA）はすべてEnterpriseプランに配置されています。そのため、開発者の人数面ではTeamsで十分であっても、セキュリティ・ガバナンス要件を満たすためにEnterprise契約を余儀なくされるケースが存在します。
また、メンバーごとの個別トークン制も組織設計とのミスマッチを生みがちです。レビュアーが余らせたトークン枠を、集中的に作業する開発者へ譲渡することはできません。チームをアップグレードする前に、真に手を動かしてコードを生成する人数を正確に割り出し、レビュアーがどのようにプロジェクトに関与するかを整理した上で、Lovableのようなクレジット共有型の代替ツールと比較検討することをお勧めします。
- 月額$25のProプランで、プロンプト主導の開発、データベース、認証機能の選択肢、ホスティング、GitHubへの確実な引き継ぎルートが揃う。
- 生成コードをBoltの外部で完全に保持・運用できるため、エンジニアへの引き継ぎや別インフラへの移行が現実的。
- Bolt Databaseと.bolt.hostデプロイにより、外部サービスを個別契約することなく一連のワークフロー全体を試作可能。
- Expoを利用した実用的なクロスプラットフォーム・モバイル検証環境を提供し、Teamsプランでは実コードに基づくデザインシステムを読み込める。
- 未使用の有料トークンは翌月まで1ヶ月間繰り越し可能であり、過去の「繰り越し不可」という制限は改善されている。
- プロジェクトファイルの肥大化に伴ってトークン消費効率が低下するため、成熟した大規模アプリの運用予算を予測しにくい。
- プロジェクトのVersion History機能ではデータベースを復元できない。
- ブランチのマージはBolt外（GitHub）で行う必要があり、稀に発生する同時同期ではGitHub側の変更が上書きされる仕様。
- モバイルアプリのストア公開にはローカル開発環境の構築と外部のデベロッパーアカウントが必須。
- 公開価格ページに従量課金トラフィックの具体的な単価が明記されていない。
- Freeのサポートはコミュニティのみで、有料プランのメールサポートも平日の営業時間帯に限定され、24時間優先サポートはEnterprise限定。
結論：Bolt.newは「早期引き継ぎ」を前提とした強力な試作環境
Bolt.newは、1人の担当者が要件の固まったワークフローをホスティング済みの検証可能なコードベースへと素早く具現化し、早い段階でGitHubへ引き渡す規律を持っている場合に、課金する価値のある優れたツールです。個人開発者にとって月額$25のProプランは最適な選択肢となります。Freeプランの1日上限やホスティング停止制限は、本格的な開発スプリントを支える基盤としては不十分だからです。
一方で、すでに確立されたアーキテクチャが存在し、複数人のエンジニアが同時にコードを触り、重要な本番データを抱え、厳格な運用契約が求められるプロジェクトでは判断基準が変わります。既存リポジトリへの直接的な機能実装ならCursorが優れています。並列エージェントや仕様として保証されたデータベース復元、広範なクラウド開発環境を求めるならReplitが適しています。そして、コードの細かな制御よりもデザイン重視の共同作業やメンバー数無制限のライセンスを優先するなら、Lovableのほうが適しています。
作業を中断すべき基準（ストップルール）も同様に重要です。AIがアーキテクチャを見失ったり、データベースの復元が困難になったり、外部環境との同期不整合が頻発した際、安易に上位のトークン枠を追加購入して解決しようとしてはいけません。頻繁な手動コードレビュー、綿密なブランチマージ、厳格なマイグレーション管理、継続的な保守運用が必要になった段階で、作業の中心を通常のリポジトリ運用へと完全に移行させてください。その後のBoltは、部分的な画面の試作や特定ブランチへのコード提案ツールとして活用すべきであり、システム全体の運用基盤に据え続けるべきではありません。
1週間で適性を判断する検証ステップ
本番用のデータベースではなく、使い捨て可能なワークフローを使って、5営業日でBoltの適性を評価してください。
月曜日：単一の受け入れ成果物を定義する
対象ユーザー、初期状態、完了状態、必要なデータ項目、制限すべきアクセス権限を書き出します。1人の担当者が最初から最後まで検証しきれる小さなスコープを選んでください。
火曜日：インフラ構成を明示して構築する
データベース、認証方式、ロール、パスワードリセットの要件を具体名で指示します。データが使い捨て可能な段階ではFreeプランを活用し、どのような指示を出すと手戻りが発生するかを記録します。
水曜日：GitHubへ連携する
非公開リポジトリを作成し、機能ブランチを1つ切ってGitHub上でマージを実行します。マージ完了後、Bolt側のプレビューとリポジトリの最新状態が完全に一致しているかを確認します。
木曜日：意図的にエラーケースをテストする
権限のないロールでのアクセス、セッション切れ、無効なリダイレクト、スキーマ変更、休眠データベースからの復帰などを試行します。自動生成されたUIの外側で、どのような手動復旧作業が発生するかを洗い出します。
金曜日：導入基準に照らして判断する
ワークフロー全体が意図通りに動作し、引き継ぎ責任者がコード品質を認め、トークン消費がツールの価値に見合っている場合にのみProプランへ移行します。基準を満たさなかった場合は、課題となっている領域を得意とする代替ツールの採用へ切り替えてください。
より広範な選択肢を検討したい場合は、バイブコーディングツールまとめも参考にしてください。Replitを有力候補としつつ有料プランの費用感を懸念している場合は、Replitの代替となる無料AIアプリ構築ツール比較が次の判断材料になります。
よくある質問（FAQ）
Bolt.newは信頼できる正規のサービスですか？
はい。Bolt.newはStackBlitz社が運営する正規の商用サービスであり、公式な価格表、製品ドキュメント、リリースノート、サポート窓口が整備されています。ただし、ツールの信頼性と「生成されたコードがあらゆる用途に対して安全であるか」は別問題です。機密データを扱う前に、必ずGitHubへコードを退避させ、アクセス権限をレビューし、データベースの復旧手順を独自に確立してください。
Bolt.newは実際に実用レベルで動作しますか？
BoltはWebアプリケーション、データベース、認証、ホスティング、GitHub連携、Expoによるモバイル開発の実働フローを公式にサポートしています。単なる静的モックアップ以上の動作アプリを構築することが可能です。ただし本記事は仕様や規約の検証に基づくものであり、実測ベンチマークではないため、エンジニアによるレビューを経ずに複雑なエンタープライズ本番環境へ耐えうることを保証するものではありません。
Bolt.newはCursorよりも優れていますか？
要件定義のプロンプトから、インフラを含めた最初の実動アプリをブラウザ上で一気に立ち上げたい場合はBoltが優れています。一方で、既存のコードベースを直接編集・拡張したい熟練エンジニアにとってはCursorのほうが適しています。アーキテクチャが固まる前の初期段階にはBoltを、コードの所有権と厳密なリポジトリ運用が主軸となった段階にはCursorを選択してください。
Bolt.newのセキュリティは安全ですか？
Boltは認証管理、URI許可リスト、漏洩パスワード保護、セキュリティ設定画面、Enterprise向けの統制機能を備えています。しかし最終的な安全性は、生成されたコードの認可ルール、環境変数やシークレットの管理、依存パッケージ、データモデル設計、バックアップ運用に依存します。プロジェクト履歴（Version History）にデータベース復元機能が含まれていない点からも、データ保護は独自に設計する必要があります。
Bolt.newは完全無料で使えますか？
Boltには$0のFreeプランが用意されており、公開・非公開プロジェクトの作成、月間100万トークン（1日300,000トークン上限）、無制限のデータベース作成、ホスティング機能を利用できます。ただしBoltのロゴが表示され、ファイルアップロードは10MBに制限され、アカウント全体の帯域幅10GBまたは月間333,333リクエストの上限に達するとサイト配信が停止します。
Bolt.newは1年間無料で使えますか？
現行の公式価格ページには$0のFreeプランが常設されており、これを「1年間の無料体験キャンペーン」とする記述はありません。無料枠はトークン量、アップロード容量、ブランド表示、ホスティング帯域幅によって厳密に制限されています。拡張された有料枠を利用する場合は、月額$25（月払い時）のProプランから申し込む形となります。
Bolt.newの料金プラン体系はどうなっていますか？
現在の料金体系は、Freeが$0、Proが月額$25、Teamsが1メンバーあたり月額$30、Enterpriseが個別見積もりとなっています。年払いを選択することで最大28%の割引が適用されます。Proプランは開始時に月間1,000万トークンが付与され、有料契約が有効である限り、未使用の有料トークンは翌月まで1ヶ月間繰り越して利用できます。
Bolt.newとLovableの違いは何ですか？
プロンプトからコードを生成し、内蔵データベースやホスティングを活用して迅速にGitHubへ引き渡すワークフローを求めるならBoltが適しています。一方で、UIの洗練度やチームコラボレーションを最優先するならLovableが適しています。LovableのProプラン（月額$25）は人数無制限でクレジットプールを共有できますが、BoltのTeamsプランは1メンバーあたり月額$30かかるため、複数人で利用する場合はチーム規模によって総コストが大きく異なります。
AIビジネスワークフロー監査チェックリストのご案内
無料の「AIビジネスワークフロー監査チェックリスト」を活用すれば、新たな開発ツールに課金する前に、対象とする単一プロセスの選定、データ構造と障害発生時コストの試算、責任者の指名、明確なストップルールの設定を整理できます。ニュースレターに登録して最新の検証記事を受け取る。
2026年9月3日
Googleでこのサイトを優先する
omidsaffari.comを優先ソースに設定すると、GoogleがTop Stories・AI Overviews・AI Modeであなたのために優先表示します。
