プレビューデプロイで安全に動作確認する

新しい料理をレストランのメニューに出す前、まずは厨房で味見しますよね。 プレビューデプロイ（＝本番公開前に、インターネット上のテスト環境で動作を確認すること） は、まさにその「味見」です。

この Atom では、あなたが AI ツールと一緒に作った Web アプリの変更を、 本番環境（＝みんなが見る場所）に反映する前に、安全に確認する方法を学びます。 所要時間は約 15 分です。

---

この Atom を進める前に、以下が済んでいる必要があります。

• Vercel（＝Web アプリをインターネットに公開するサービス）にプロジェクトがデプロイ（＝公開）されていること
• コードが GitHub（＝コードを保存・共有するサービス）で管理されていること

どちらもまだの場合は、先に「Vercel へのデプロイ」Atom を済ませてから戻ってきてください。

確認方法: ブラウザで Vercel のダッシュボード（管理画面）を開き、あなたのプロジェクト名が表示されていれば OK です。

---

料理でいうと、「メインの調理台とは別に、試作用の小さな机を用意する」イメージです。 本番のコードに影響を与えずに変更を試すための作業部屋を ブランチ と呼びます。

AI に指示する

Claude Code（ターミナルで使う AI アシスタント）を開き、次のように入力してください。

プロンプト例（そのままコピペ OK）:

「main ブランチから feature/preview-test という名前のブランチを作って切り替えて」

Cursor や ChatGPT を使っている場合も同じ指示で大丈夫です。AI が git checkout -b feature/preview-test というコマンドを実行してくれます。

良い例: feature/preview-test、fix/header-color のように、何のための変更かがわかる名前

悪い例: test、aaa、update のように、後で何の変更かわからない名前

なぜ大事？: 名前がわかりやすいと、Vercel のダッシュボードでどのプレビューがどの変更か一目でわかります。

---

試作用の机（ブランチ）が用意できたので、実際に小さな変更を加えてみましょう。 いきなり大きな変更をするのではなく、タイトルの文字を変えるくらいの小さな変更で OK です。

AI に指示する

プロンプト例:

「トップページのタイトルを『テスト表示中 🚀』に変更して。変更するファイルと、何を変えたかも教えて」

ポイントは「何を変えたかも教えて」と付け加えること。AI が変更内容を説明してくれるので、自分で確認しやすくなります。

良い例: 「トップページのタイトルを『テスト表示中 🚀』に変更して」 → 変更箇所が明確

悪い例: 「何か適当に変えて」 → 何が変わったかわからなくなる

---

変更内容を GitHub に送ることを プッシュ（＝変更をサーバーにアップロードすること） と呼びます。 その前に、変更に名前をつけて保存する コミット（＝変更にメモを付けて保存すること） をします。

AI に指示する

プロンプト例:

「変更をコミットして GitHub にプッシュして。コミットメッセージは『feat: タイトルをテスト表示に変更』にして」

AI が次の 2 つを順番に実行してくれます。

1. git add + git commit → 変更を保存する
2. git push → GitHub にアップロードする

良い例: コミットメッセージに「feat: タイトルをテスト表示に変更」と書く → 何をしたか後からわかる

悪い例: コミットメッセージに「fix」や「update」とだけ書く → 後から見て意味不明

AI 活用ポイント: 「コミットメッセージを考えて」と AI に頼むと、変更内容に合ったメッセージを提案してくれます。

---

GitHub にプッシュすると、Vercel が自動的にテスト専用の Web ページを作ってくれます。 これが プレビュー URL です。

確認手順

1. ブラウザで Vercel のダッシュボード（管理画面）を開く
2. プロジェクト名をクリックする
3. 上部の Deployments（＝公開履歴）タブを開く
4. 一番上にある「Preview」と書かれた行を探す
5. 右側に表示される Visit ボタンまたは URL をクリックする

プレビュー URL は your-project-git-feature-preview-test-username.vercel.app のような 少し長い URL になります。これは本番の URL とは別物なので、ここでの確認は他の人には影響しません。

ポイント: プレビュー URL が表示されるまで、通常 1〜3 分 かかります。「Building」と表示されている間はまだ準備中です。コーヒーを一口飲んで待ちましょう。

AI 活用ポイント: もしビルドに時間がかかっている場合、Claude Code に「Vercel のデプロイ状態を確認する方法を教えて」と聞くと、CLI での確認方法も教えてくれます。

---

プレビュー画面を開いたら、次のチェックリストを上から順に確認していきましょう。

• ページが正しく表示されるか（真っ白になっていないか）
• 変更した部分（タイトルなど）が反映されているか
• リンクやボタンが正しく動くか
• スマートフォン表示: ブラウザの幅を狭めたときにレイアウトが崩れていないか

すべて ✅ なら、次のステップに進みます。

もし問題が見つかったら: AI に「プレビューを確認したらタイトルが変わっていないんだけど、原因を調べて」のように伝えると、考えられる原因を一緒に調べてくれます。

---

味見をして「これは OK！」となったら、メニュー（本番環境）に反映します。 試作用の机の内容をメインの調理台に持ってくる作業を マージ（＝ブランチの変更を本番用のコードに統合すること） と呼びます。

AI に指示する

プロンプト例:

「feature/preview-test ブランチを main ブランチにマージして GitHub にプッシュして」

マージが完了すると、Vercel が自動的に本番環境を更新します。 1〜3 分後に本番 URL にアクセスして、変更が反映されているか確認しましょう。

良い例: 「feature/preview-test を main にマージして」 → 方向が明確

悪い例: 「マージして」だけ → どのブランチをどこにマージするかわからず事故のもと

---

「Building」のまま 5 分以上たっても終わらない

• Vercel ダッシュボードでエラーマーク（赤い ×）が付いていないか確認する
• エラーがあれば、AI に次のように頼んでください:

「Vercel のビルドエラー（＝コードから Web ページを作る際のエラー）のログを見て、原因を教えて」

変更が反映されていない気がする

• ブラウザの キャッシュ（＝以前のデータを覚えている仕組み） が原因のことが多いです
• Ctrl + Shift + R（Mac は Cmd + Shift + R）で強制的に再読み込みしてみてください
• それでもダメなら、プレビュー URL をシークレットウィンドウ（プライベートブラウズ）で開いてみてください

マージの向きを間違えてしまった

• 必ず「feature ブランチ → main ブランチ」の方向でマージしてください
• 逆にすると、本番のコードが試作用の内容で上書きされてしまう可能性があります
• 心配なときは AI に次のように丁寧に指示してください:

「まず main ブランチに切り替えて、それから feature/preview-test をマージして」

プレビュー URL がどこにあるかわからない

• GitHub 側でも確認できます。GitHub のリポジトリページで Pull Requests タブを開くと、Vercel が自動でプレビュー URL をコメントしてくれている場合があります
• AI に「GitHub でプルリクエストを作って」と頼むと、プレビュー URL が GitHub 上にも表示されて便利です

---

お疲れさまでした！ この Atom であなたは次のことができるようになりました。

1. ブランチを作って安全に変更を試す
2. GitHub にプッシュしてプレビュー環境を自動生成させる
3. プレビュー URL で動作確認する
4. 問題なければマージして本番に反映する

この「ブランチ → プッシュ → プレビュー確認 → マージ」の流れは、プロの開発者も毎日行っている基本ワークフローです。 一度身につければ、本番環境を壊す心配なく、どんどん改良を試せます。

成果物チェック

次の 2 つが手元にあれば、この Atom は完了です。

• プレビュー URL で変更が反映されている画面のスクリーンショット
• 本番 URL で変更が反映されていることの確認