Boltで公開・デプロイするときの確認ポイント

Boltで公開するときは、公開ボタンが押せることではなく、初めて訪れる利用者が主要操作を完了でき、誤った権限や秘密情報の露出がなく、問題が起きたときに更新を止める方法が分かることを合格条件にします。公開前は、まず利用者が行う重要な操作を三つ程度に絞り、Previewで同じ順序を試します。その後、実際に公開されたURLで再確認します。

Bolt CloudはappのhostingやdomainなどをBolt内で扱う選択肢を提供し、公開すると共有可能なURLが作られます。とはいえPreviewと公開環境は同じとは限りません。環境設定、database、認証、domain、公開範囲に違いがないかを確認し、live URLを開いただけで「運用可能」と判断しないでください。

先に公開判定の対象を決める

最初に、公開対象が誰に見えるかを決めます。社内確認用か、招待した利用者向けか、誰でも閲覧できるサイトかで、必要な認証とtestが違います。無料の共有URLを得ることと、利用者を限定することは別の設定です。現在のplan・画面で選べる公開範囲を確認し、想定利用者がaccessできるかを試します。

次に、appの中心flowを列挙します。予約アプリなら「予約を探す」「予約を送る」「予約結果を確認する」、業務画面なら「ログイン」「対象を検索」「変更を保存する」といった具合です。すべての小機能を同じ重さで試す必要はありません。データを変更する操作、ログイン、支払い、外部APIなど、失敗したときに利用者や運営へ影響するflowを優先します。

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

Flow	入力	成功状態	失敗状態	live URLで再確認
新規登録	test emailなど	利用者として入れる	形式・重複の案内	必要なら実施
中心操作	架空のtest data	結果が保存・表示される	入力を直せる	必須
権限境界	user A/B	許可された範囲だけ見える	他人のdataは非表示	private dataなら必須
外部連携	test endpoint	success stateが分かる	再試行・案内がある	使用時に必須

test用の値を使い、実userのdataを試しに変更しないようにします。メール送信や料金発生など外部へ作用する機能は、test modeが使えるかを先に確認します。testモードがない状態で本番宛先や実決済を試すのは避けます。

公開先と変更経路を決める

Bolt Cloudの組み込みhostingを使うか、外部hostingへつなぐかは、既存のdeployment方針と必要な機能で決めます。Boltの公式案内では、すべてのprojectにbolt.hostのsubdomainがあり、custom domainは有料利用者向けと説明されています。planや画面の変更があり得るため、公開前に現在表示される条件を確認してください。外部hostingを使う場合は、そのproviderのbuild・environment・domain設定が別途必要です。

公開後の更新経路も先に決めます。一人で試作する場合と、チームで継続運用する場合では、誰が変更をreviewし、いつ公開するかが違います。GitHub連携やversion historyを利用するなら、どちらが変更履歴の正本かを明確にします。Productionの画面を直接変更し続けると、以前の安定版との差分が把握しにくくなります。

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

状況	確認したい運用
個人の短い試作	変更前の状態をversion history等で追えるか
共同開発	誰がdiffをreviewし、公開操作をするか
既存serviceから移行	database、domain、redirect、rollbackの担当
顧客dataを扱う	access権限、backup、incident時の連絡先

外部のcustom domainを接続するときは、現在のDNS・SSLの状態、www有無、公開先の一致を確認します。独自domainは公開操作より影響が広くなることがあるため、既存のwebやemailへ影響しないよう、providerの正式な指示と現在のDNS管理画面で設定します。DNS値は推測せず、指定されたrecordと対象hostを照らし合わせます。

Previewからliveへ進む公開前test

Previewでは、実装されたflowを同じ入力で通します。入力不足・不正な値、正常な値、通信失敗を分け、画面が利用者へ何を伝えるかを見ます。少なくとも、正常系を一回通してから、error系を一つずつ試します。失敗時にspinnerが消えない、buttonが押せないまま、空の画面になるなど、次に何をすればよいか分からなくなる状態を見逃さないようにします。

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

QAケース	何をするか	完了の条件
初回表示	初めてURLを開く	page目的と最初の操作が分かる
入力不足	必須項目を空にする	必須箇所と修正方法が分かる
正常入力	架空dataを送る	成功表示と次の行動が分かる
連続操作	一度成功後に戻って再実行	意図しない重複・二重送信がない
認証	logoutし、保護画面へ進む	認証前後の範囲が正しい
小画面	幅を狭めて同じ操作	button、form、errorが操作可能
reload	結果後にページ再読込	保存仕様どおり表示が保たれる

公開後は、Previewと同じ入力・同じ順序でlive URLを操作し、結果を比較します。Previewだけ成功しlive側で失敗するときは、環境変数、APIの許可origin、databaseの接続先、auth redirect先などの差を分けて確認します。画面上の文言が同じでも、接続先dataが異なる可能性があります。

公開されたURLが第三者から開けるかも確認します。想定利用者が限定されるなら、logout状態や別accountから保護画面へaccessできないことを試します。逆に公開サイトなら、loginを要求せず中心の閲覧操作が完了するかを見ます。公開範囲と個人情報の取扱いを同時に確認してください。

まずは使ってみる

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

• 

  Bolt.new

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

Secretsとdatabaseをproduction条件で扱う

API key、database secret、OAuth credentialなどは、公開frontendやHTML、source map、browser consoleへ含めません。server-side functionやhosting providerのsecret設定が利用できる場合でも、値を設定しただけで安全と決めつけず、どのcodeがその値を読み、どのrequestで使うかを確認します。

databaseを使うappでは、Previewのtest dataとproduction dataが混ざらないか、権限・table・接続先を見ます。未ログイン、user A、user B、管理者でどのrecordを読めるかを分け、直接URLやrequestからもtestします。buttonを隠しているだけではaccess controlになりません。data変更を伴う公開前には、backupまたはversioned migrationと復旧手順を用意してください。

外部APIにはrate limitや失敗があり得ます。連続clickやtimeoutを試したとき、同じ処理が二重実行されないか、errorに内部credentialが含まれないか、retryが可能かを確認します。公開画面の成功状態とbackendの処理成功を混同しないでください。成功UIが表示された後でも、実際の保存・外部送信が確認できないなら、flowは完了とは言えません。

Mobile、browser、公開後の変更確認

Previewで見やすくても、スマートフォン幅でCTAが隠れたり、formが横にはみ出したりすることがあります。小画面では、最初の一画面、主要な入力、error文、送信後の結果を確認します。幅を変えるだけでなく、長い文言やvalidation messageが出た状態でも操作します。

公開先のbrowserでCSSやJavaScriptが読み込めない場合、見た目だけでなくbuttonやnavigationが動きません。代表的なChrome系browserなど、利用者が使う環境で主要flowを再確認し、resource failureやconsole errorがあればfirst-partyか外部serviceかを分けます。特に初回表示、form送信、別routeへの移動、再読込を見ます。

公開後の小さな修正にも変更記録を残します。変更した内容、確認したflow、公開したversion、問題時の戻し方を記録すれば、あとで原因を追いやすくなります。更新後は変更箇所だけでなく、その変更に隣接するflowも短く再確認します。

問題が出たときに戻す判断

公開後に問題が見つかったら、影響範囲、利用者が困る操作、data整合性を先に判断します。重大な機能停止や誤ったdata公開がある場合は、修正promptを重ねるより、公開更新を止める・以前の安定versionへ戻す・accessを一時制限するなどの選択を検討します。実際にどの方法が使えるかはhostingやversion管理方式で異なるため、事前に現在の設定を確認します。

「戻せる」とは、履歴buttonがあるだけではありません。どのversionへ戻すか、database変更を含むのか、更新後に作られたdataをどう扱うかが説明できる状態です。database migrationがある場合、古いcodeだけ戻してschemaが残ることで新たな障害になることもあります。code・data・configurationを分けて復旧計画を作ります。

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

変更種別	公開前に残す情報	問題発生時の問い
UI / code	commit・version・diff	前のcodeへ戻せるか
database schema	migration・backup	dataを失わずschemaも戻せるか
secret / environment	key名・対象環境	値を再表示せず再設定できるか
domain / routing	current recordと切替条件	利用者を旧endpointへ戻せるか

AIものさしの判断

公開可否は「URLができたか」ではなく、公開対象に合った主要flowを完了できるか、秘密情報やdataの境界が保たれるか、問題が出た時に止められるかで決めます。まずPreviewで正常・失敗を試し、live URLで同じ操作を再実行します。独自domainやproduction databaseの変更は、公開の一部ではなく別の影響がある操作として確認します。

今すぐ行うことは、主要flowと合格条件を表へ記入し、test用account・架空dataを用意することです。すべての条件が見えてから公開し、live側で同じ一往復を再確認します。確認できていないhosting、plan、SSL、databaseの性質は推測で埋めず、現在のBolt公式案内とproject設定へ戻ってください。