AIで作ったアプリを公開できたら、次は「少し直して、同じURLで更新する」段階です。ここで新しいプロジェクトを毎回作ると、どれが本番版か分からなくなります。今回は、ロリポップ！デプロイナウで公開した1つのアプリを、GitHubの変更から安全に更新する流れをまとめます。
更新前に決めること
まず、変更を一度に増やしすぎないことが大切です。初心者なら「ボタンの色を変える」「説明文を1行追加する」のように、結果を目で確認できる変更を1つ選びます。今回は前回の1日1デプロイプロジェクトのルールを引き継ぎ、同じプロジェクト・同じ公開URLを更新します。
AIには次のように依頼します。
公開中のアプリに、説明文を1行追加してください。
変更するファイル名、変更前後の内容、確認方法を先に説明してください。
他の機能やファイルは変更しないでください。
「どこを触らないか」まで伝えると、意図しない変更を減らせます。AIの返答を見て、変更対象が想定どおりかを確認してから進めます。
1. 公開中の状態を残す
更新前に、現在の公開URLをブラウザで開きます。トップページが表示されること、主要なボタンが動くことを確認し、必要なら画面のスクリーンショットを保存します。これが変更後と比べる基準になります。
次にGitHubで、最新のコミットがどれかを確認します。コミットは「その時点のファイルを名前付きで保存した記録」です。更新前のコミット名をメモしておくと、問題が起きたときに戻す場所を説明できます。
2. AIの変更を小さく確認する
AIが変更したファイルを一覧で確認します。説明文だけの変更なのに、設定ファイルや秘密情報まで変わっていたら止めます。APIキー、パスワード、個人情報をGitHubへ保存してはいけません。
ローカルで確認できる場合は、次を試します。
- アプリを起動する
- 変更した場所が表示される
- 既存の入力やボタンが動く
- ブラウザの幅を変えても崩れない
分からないエラーが出たら、エラー全文をAIへ渡す前に、キーや個人情報が含まれていないかを確認します。
3. GitHubへ保存する
問題がなければ変更をGitHubへ保存します。メッセージは 説明文を追加 のように、何を変えたかが分かる短い言葉にします。保存後、GitHub上で変更ファイルと差分をもう一度見ます。
この段階ではまだ「公開成功」ではありません。GitHubは保管場所であり、実際の公開ページはデプロイナウの処理が成功して初めて更新されます。
4. デプロイ結果と公開ページを確認する
GitHub連携を設定していれば、pushをきっかけにデプロイが始まります。デプロイナウの履歴やビルド結果で成功を確認し、その後に同じ公開URLを開きます。
- 新しい説明文が表示される
- 変更していない機能も動く
- 古い表示が残る場合は再読み込みする
- エラー画面なら、デプロイ結果とGitHubの差分を確認する
「デプロイが成功した」と「アプリが期待どおり動く」は別です。両方を確認して、初めて更新完了とします。
5. 問題があったときは戻す
更新後にボタンが動かない、画面が真っ白になるなどの問題があれば、さらにAIへ変更を重ねる前に止めます。更新前のコミットへ戻す、または原因を説明して修正案を出してもらいます。原因が分からないまま複数の変更を追加すると、どの変更が問題だったか分からなくなるためです。
まとめ
公開後の更新は、AIに修正を頼む、変更範囲を確認する、GitHubへ保存する、デプロイ結果を見る、同じURLで動作確認する、という順番で進めます。初心者ほど一度に大きく変えず、1日1デプロイプロジェクトの中で小さな変更を1つずつ積み重ねると安心です。公開URLを増やすより、同じアプリを少しずつ育てるほうが、管理もしやすくなります。