Boltで生成したコードを修正するときの進め方

Boltで生成したcodeの不具合を直すときは、同じ指示を何度も送り直す前に、「再現条件」「期待結果」「実際の結果」を分け、修正範囲を一つに絞ります。文字・色・余白などの見た目の調整と、state・API・認証・保存に関わるlogic修正では、調べる場所も確認方法も違います。生成されたdiffを確認し、最初に失敗した操作を同じ条件で再実行できる状態が、修正完了の目安です。

この記事の目的は、Boltの編集機能を紹介することだけではありません。直したい現象を再現可能な報告に変え、広い再生成を避け、影響範囲に合ったテストと復旧方法を選べるようにします。実際のcodeを読み切れない場合でも、AIへ渡す情報を整理し、変更後に見るべき点を決めることはできます。

症状を「入力・操作・結果」で記録する

「フォームが壊れた」「表示が変」とだけ伝えると、AIは原因を特定できず、関係のない画面まで作り直すことがあります。まず、どの画面で、何を入力し、何を操作したとき、何が起きたかを書きます。期待していた結果も一文で添えます。

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

記録欄	具体例
画面と条件	mobile幅、ログイン済み、予約編集画面
入力	開始時刻を10:00、終了を11:00に設定
操作	保存ボタンを一度押す
実際の結果	buttonは押せるが、spinnerが消えた後も画面が変わらない
期待結果	保存済み表示となり、再読込後も11:00が見える
再現頻度	毎回 / 特定recordだけ / 一度だけ
変更してよい範囲	保存処理と成功表示だけ
変更してはいけない範囲	database schema、色、他画面

再現しない現象を「常に起きる」と書くと、修正の検証条件まで誤ります。発生した回数や条件が曖昧なら、そのまま「未確認」と書き、まず再現testを作ります。error messageが出る場合は、秘密情報や個人情報を含まない形で、全文と発生手順を残します。

見た目の修正か、動作の修正かを切り分ける

buttonの色や文字、余白が違うだけなら、表示要素を選んで調整するvisual editや、対象を限定したpromptが候補です。一方、保存されない、遷移しない、別userのdataが見える、API responseが空といった現象は、CSSだけで直そうとしません。まず関連するcomponent・handler・request・stateの流れを調べます。

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

症状	最初に見るところ	修正依頼に含めること
文字や色のズレ	対象要素・style・responsive条件	対象範囲、変更値、他に触れない範囲
buttonが反応しない	click handler、disabled条件、error	操作と期待される状態遷移
保存されない	request、response、validation、認証	入力、network結果、再読込後の期待
重複して保存される	submit連打、retry、idempotency	一回の操作を識別できるか
他userのdataが見える	認証状態、query、server/database policy	roleごとの直接access test
build error	compile errorの先頭、変更file	errorを直す最小範囲

ここでの分類は診断の入り口です。たとえばbuttonの見た目がdisabledらしくても、実際にはhandlerが起動していてresponseで失敗しているかもしれません。画面だけを見て原因を確定しないでください。BoltはVisual EditsやCode viewなどの編集手段を提供していますが、どれが使えるか・編集可能かは現在のprojectやbrowserの状態も確認します。

AIへ渡す修正依頼の型

修正promptは長い説明より、境界と検証条件が明確な方が使いやすくなります。毎回ゼロから書かず、次の順で情報を入れます。

目的: 何を直すか

再現: どの入力と操作で起きるか

期待: 修正後にどうなるか

範囲: 変更してよいcomponent / behavior

禁止: 変えてはいけないschema / page / style

確認: 同じ操作に加えて、どの回帰ケースを試すか

説明: 変更前に原因候補と編集fileを説明し、完了後に差分を要約する

例：

「ログイン後に保存したメモを再読込すると一覧から消えます。user Aで新しいメモを入力して保存し、一覧へ戻ってからページを再読込すると再現します。期待結果は同じuser Aで一覧に残ることです。まず、client stateだけへ保存しているのか、database writeやreadで失敗しているのかを切り分けてください。対象はメモの保存・一覧取得に関係する範囲です。認証方式、table schema、別画面のstyleは変更しないでください。変更前に原因と対象fileを説明し、変更後は保存・再読込・user Bからの非表示を確認してください。」

複数の現象がある場合は、修正単位を分けます。「一覧が遅い」「色が違う」「ログインできない」を一つのpromptへまとめると、変更と結果の対応が崩れます。まず利用者が完了できない中心の問題を選び、他の問題は別の再現メモに残します。

まずは使ってみる

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

• 

  Bolt.new

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

差分を読んでから採用する

生成結果が動いているように見えても、変更したfileと動作条件を確認します。Bolt Code viewはproject codeを確認・編集する方法の一つです。どのfileが変わったか、元の動きがどう変わるかを把握してから適用します。変更diffが読めず、影響範囲も説明できないなら、特に認証やdatabase変更を含むdiffはそのまま採用しません。

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

差分の種類	確認すること	追加テスト
文言・style	対象の画面以外へ広がっていないか	desktop/mobileで対象を確認
form validation	clientとserverの両方で必要条件がそろうか	空欄、境界値、形式違い
state / navigation	成功・失敗後の遷移が戻れるか	初回、再入力、戻る、更新
API request	endpoint、payload、error handling	success、4xx/5xx、timeout
auth / access	roleごとにread/writeが制限されるか	未login、user A、user B
schema / migration	drop・rename・既存rowへの影響	cloneまたはtest database

「一つの原因に絞る」は、変更fileが必ず一つという意味ではありません。ひとつのbehaviorを直すため複数fileが必要なら、依存関係を説明し、まとめて同じ変更として確認します。逆に、見た目とbackendの変更が独立しているなら、別の修正として分けます。

影響範囲に合わせて回帰testを選ぶ

修正後は失敗した操作を同じ入力で再現し、期待結果になったかを確認します。それだけでなく、関連する成功と失敗のケースも少数確認します。画面の見た目だけを直した場合でも、テキストがbuttonを押し出していないか、mobile幅でelementが重ならないかを見ます。

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

変更	必須の再確認	条件に応じて追加
文言 / style	対象screen、desktop、mobile	同componentを使う別page
routing	直接URL、内部navigation、戻る	refresh後、unknown route
data保存	create、read、update、reload	retry、重複送信、空data
認証	login/logout、未login状態	token expiry、user間の境界
schema	新規rowと既存row	migration rollback、data volume
responsive	問題viewportと隣のbreakpoint	長文、空、error state

画面操作が成功しても、server responseや再読込で失われるなら永続化は未完了です。認証画面が表示されても、別userのrecordを直接指定できるならaccess controlは未完了です。各要件に対して合格条件を別々に置きます。

失敗結果の記録は、「直った / 直らない」だけでなく、修正前後の操作と値を残すと次の担当者が再現できます。test dataは架空のものを使い、個人情報や本番secretをprompt・log・screen captureへ入れないでください。

直らないときはpromptを連打しない

同じ指示を繰り返しても症状が変わらない場合、変更を増やすのではなく、現象を再現できているか、確認しているenvironmentが同じか、errorが表示されているかを見直します。preview URLと公開URL、未ログインとログイン済み、保存前と保存後などの条件差が原因のことがあります。

原因が分からないまま広い修正が提案された場合は、いったん「変更は行わず、再現条件と関連箇所、仮説を説明する」と依頼します。Boltのversion historyやGitHub等のsource controlが利用できる場合は、変更前の状態やdiffを確認します。復旧方法を持たないままdatabaseや認証を変更しないでください。復元手段が分からない場合は、修正を止める判断自体が安全な次の行動です。

AIものさしの判断

Boltのcode修正では、「promptか直接編集か」を先に選ぶ必要はありません。見た目の局所調整ならvisual edit、狭い機能変更なら境界付きprompt、原因が分からない動作不具合なら再現条件とdiffを手掛かりに根本原因を調べます。作業方法は症状に合わせ、合格条件を同じtestで確認します。

次に行うことは、ひとつの不具合について「入力・操作・実際・期待」を書き、変更可能範囲と禁止範囲を分けることです。修正後は最初の再現ケースを通し、変更の種類に応じた回帰testを足します。手元で確認していない修正成功率や速度を断言せず、Diffと実際の結果で判断してください。