どうも、トラハックです。
みなさんは bolt.new をご存知でしょうか？
StackBlitz 社が提供する「ブラウザ上で動作する統合開発環境（IDE）」と「大規模言語モデル（LLM）によるコード生成」を組み合わせた新サービスです。
類似サービスには Vercel 社の v0 があります。
肩透かしかもしれませんが、結論を述べると bolt.new を実際のビジネスプロジェクト（企業内でのチーム開発を想定）に投入するにはまだまだ多くの課題があります。
しかし現時点でも、個人開発やスタートアップでの MVP 開発、その他プロトタイプ開発においては十分に活用できると思います。
また、今後の発展次第で、将来的に企業内のチーム開発においても bolt.new や同様のサービスが利用されることは考えられます。
前置きが長くなりましたが、この記事では、bolt.new を活用するための Tips を共有し、現時点の課題や注意事項にも触れます。記事を読み終えたときに「試しに触ってみようかな」と思っていただけら幸いです。
なお、bolt.new を活用した Web アプリケーション開発について YouTube ではハンズオン形式でカジュアルに解説しています。
bolt.new がもたらす価値
そもそも bolt.new のような LLM によるアプリケーションコード生成が統合開発環境内で利用できると何が嬉しいのか。
開発速度・生産性の向上
一般的にはこうした "生成AIサービス" は非エンジニア向けに語られることが多いですが、個人的にはソフトウェアエンジニアが利用することで生産性向上に寄与すると考えています。
ソフトウェア開発自体の知識や後述するプロンプトエンジニアリングの知識を有している人間が利用した方が有効活用できるはずです。
また、直近のソフトウェアエンジニアリングにおいて GitHub Copilot, ChatGPT, Claude, Cursor ...etc の活用が当たり前になってきていることを鑑みると、コーディング全般を LLM が担うのは自然な流れのように思います。
コード品質の向上
LLM にコーディングを任せることで人間は何をすべきか？を考えた際、最終的には「LLMが生成した回答（コード）が妥当かを判断する」役割を担うだろう、と考えています。
少し前に X でも話題になっていた @t_wada さんの「労力は外注できるが能力は外注できない」という発言がありました。
この一連の投稿には納得感が多かったです。生成AIによって作業自体は楽になるけれども、そのが妥当かどうかを判断するのは人間であり、そのために私たち職業エンジニアは能力の向上を怠ることはできないなと。
少し話は逸れてしまいましたが、bolt.new を正しく活用することでソフトウェアエンジニアは基本的にレビュワーに回ることになります。
レビュー業務に割く時間を多くとることができ、かつ改善を繰り返すことでレビューの標準化もできるようになるでしょう。
潜在的な不具合の検出と修正
LLM にコーディングを任せることでもたらされるメリットとして、人間が見落としてしまう潜在的な不具合を検出して修正をしてくれる、という点もあると思います。
当然、プロンプトの質が悪かったりハルシネーションが起きることで、逆に潜在的な不具合が仕込まれてしまう可能性はありますが、それは前述したレビューで人間がカバーすべきポイントです。
bolt.new の課題と注意事項
ここまで bolt.new を導入するメリットについて述べてきましたが、冒頭で述べた通り、企業内のチーム開発に導入するにはまだまだ課題が多くあると思います。
従来のローカル開発環境との統合
StackBlitz 社が提供しているサービスということもあり、bolt.new は現状ブラウザからしか利用ができません。開発者にとっては。今まで慣れ親しんだ VSCode や JetBrains 社の IDE を離れるのは心理的抵抗が大きいと思います。
実際に私も bolt.new を利用して開発を行なった際、ちょっとした変更をブラウザの IDE で行なっていましたが、それなりにストレスを感じました。
bolt.new のような LLM によるコード生成を可能とするプラグインが各種 IDE で使えるようになったらなあ...という夢を見ています。
Git との統合
記事執筆時点で bolt.new は GitHub のリポジトリを接続することができません。StackBlitz では GitHub Organization も含めてリポジトリを接続してブラウザ上でプロジェクトを開くことが可能です。
StackBlitz で GitHub リポジトリに接続されていないプロジェクトを開いた場合、 IDE の左上に "Open in bolt.new | AI" というボタンが表示されており、bolt.new の画面に移動可能です。
将来的に GitHub と接続できるようになる可能性は大いにありますが、 Git 管理できないとするとチーム開発で利用することは考えられないでしょう。
セキュリティ・コンプライアンス面での懸念
最も大きい要因はこれかもしれないな...と思います。
企業内で扱うコードやドキュメントには、顧客情報や知的財産、機密プロジェクトといった機密データが含まれることがあります。
LLM に入力するコンテキストやコード断片が外部サーバーに送信・蓄積される場合、機密情報が外部環境に出てしまわないか慎重なチェックが必要です。
また、金融や医療など規制の厳しい業界では、LLMを利用したコード生成が社内セキュリティポリシーや業界基準（ISO、SOC2、GDPR 等）に抵触しないか検討する必要があります。
これらを考慮すると、一定以上の規模の企業で気軽に導入するのはなかなか難しそうだなと感じています。
使い始める前に押さえたいTips
ここまで述べたような課題はあるものの、個人開発やプロトタイプ開発のような小規模・少人数での開発にはすぐに活かすこともできると思います。
LLMプロンプトの最適化手法
「曖昧な質問には、曖昧な答えしか返ってこない」というのは、LLMにおいても同様です。優れた出力を得るためには、最初のプロンプト段階でできるだけ明確な要件と前提情報を与えることが肝心です。
一般的なLLMを利用したサービスと同様に bolt.new の課金体系はトークン消費量に基づきます。特に、無料で利用したい場合はトークンがかなり限られているので、いかに効率よくプロンプトを渡して期待するアウトプットを得られるかが重要だと思います。
bolt.new の GitHub 内の issue でもトークン消費量を抑える tips や bolt.new 自体への要望が議論されていました。
明確な要件定義
たとえば「ユーザー認証機能を実装するコード」と要求するよりも、「JWTを用いたユーザー認証機能をNode.js (Hono)上で実装し、ログインエンドポイントとリフレッシュトークン発行ロジックを含むサーバーサイドコードを提示してください」のように、求める成果を明確かつ具体的に伝えましょう。
コンテキストの付与
同じモデルでも、前後関係（コンテキスト）を正しく与えることで、回答が大幅に洗練されます。プロンプトに要件を伝える際には、機能だけでなく、利用するフレームワーク、言語バージョン、コードスタイル（ESLintのルールやコーディング規約）、テストの有無など、プロジェクト特有のコンテキストを事前に盛り込むと、LLMがより適した回答を導き出しやすくなります。
.bolt/prompt の活用
そのために活用できるのが .bolt という隠しディレクトリ内に prompt というファイルを作成して、その内部に上記のようなプロジェクト特有のコンテキストを定義しておくことです。
実際に弊社のコーポレートサイトを bolt.new で構築する際に利用した prompt ファイルは以下となります。
# Packages
パッケージマネージャーは yarn を使ってください。
TypeScript の最新バージョンを使ってください。
React 18 系の最新バージョンを使ってください。
Next.js 14 系の最新バージョンを使ってください。
Next.js は App Router で構築してください。
スタイリングは CSS Modules で行います。sass を使ってください。
アイコンは Remix Icon を使います。
ESLint と Prettier でコードを静的解析・フォーマットします。
microCMS の JavaScript SDK を入れてください。
Cloudflare Pages にデプロイできるよう wrangler や @cloudflare/next-on-pages などそのほか必要なパッケージを入れてください。
# Directory structure
以下のようなディレクトリ構造としてください。
src
|- components
| |- features // 特定の機能に関心のあるコンポーネントを配置する
| | |- News
| | |- NewsList
| | |- NewsList.tsx
| | |- NewsList.module.scss
| | |- index.ts
| |- ui // 機能に関心のない純粋な UI を提供するコンポーネントを配置する
| |- Header
| |- Header.tsx
| |- Header.module.scss
| |- index.ts
|- constants // 定数を配置する
|- domains // ドメインモデルを定義する
|- pages // Next.js の Pages Rotuer に則る
|- services // microCMS など外部サービスの実装を定義する
|- styles // 共通スタイルを配置する
プロンプトエンジニアリングの勘所と反復改善プロセス
理想的なプロンプトは、一発で完成しないことがほとんどです。最初は多少抽象的な要求から出発し、LLMが返す回答を検証・修正しながら、少しずつプロンプトを精緻化していく流れが一般的です。
短いサイクルでの改善
最初のプロンプトから最良の答えを得るのではなく、「プロンプト → 出力 → 検証 → 改善」というサイクルを高速に回すことが、質の高い成果物につながります。
たとえば、一度目の応答で汎用的な回答しか得られなかった場合は、なぜそうなったのかを考え、より詳細な技術要件や制約を含めて再度プロンプトを投げるといった手順を踏むことで、徐々に出力の質が上がっていきます。
このプロンプトの改善は、いきなり bolt.new 上で実施するのではなく、まず ChatGPT や Claude のような LLM を用いることで、bolt.new の限られたトークンを節約することができます。
評価基準の共有
チーム内で「良いプロンプト」や「求める回答」の基準を可視化しておくと、何をどう直せば良いかを共有しやすくなります。コード品質、可読性、パフォーマンス、セキュリティ要件など、プロジェクト固有の品質指標を明示しておきましょう。
ログと振り返り
改善のためには過去ログが貴重な資源です。bolt.new上で投じたプロンプトや得られた回答を定期的に振り返り、どういった表現が有効だったのか、どんな箇所でハルシネーション（誤回答）が生じたのかを整理することで、将来的なプロンプト設計スキルを高めることができます。
Git のブランチ単位で、利用したコードと変更差分を記録しておくのは有効な手段かもしれません。
まとめ
今回は bolt.new の紹介をしましたがまだまだこれから
最後に、toraco株式会社では2024年11月1日にエンジニア向けのコミュニティを立ち上げました。
Discord のサーバーで運営しており、以下のリンクから無料で参加できます。コミュニティ内では以下のような投稿・活動がされます！
Discussion