AIにコードを書いてもらい、ブラウザで画面が動いた。ここから「他の人がURLを開いて使える状態」にするには、公開先の選定、GitHubへの保存、ビルド設定、環境変数、独自ドメイン、公開前テストが必要です。
ただし、公開作業はファイルをアップロードするだけではありません。ローカルでは動いていたのに公開後は白い画面になる、APIキーが漏れる、問い合わせ内容が保存されない、といった事故は珍しくありません。本記事では、コードに詳しくない人でも判断できるように、公開前の設計から本番確認までを7ステップで解説します。
目次
結論：初心者は「GitHub＋プレビュー環境＋本番環境」で公開する
最初のWebアプリなら、次の流れが管理しやすいです。
- アプリの種類と必要な機能を確認する
- 不要なファイルと秘密情報を除外する
- GitHubへコードを保存する
- Vercelなどの公開サービスと連携する
- まずプレビューURLでテストする
- 問題がなければ本番公開する
- 公開後の監視と更新手順を決める
Vercelの公式資料でも、ローカル・プレビュー・本番は別の環境として扱われています。いきなり本番へ反映せず、プレビューURLで確認してから本番へ進めることが、初心者ほど重要です。
ステップ1：そのアプリが「静的」か「サーバー処理あり」か確認する
最初に、公開したいアプリの構成を見分けます。ここを間違えると、公開先を選び直すことになります。
静的サイトで公開しやすいもの
- HTML、CSS、JavaScriptだけで完結する診断ツール
- 入力内容をブラウザ内だけで計算する料金シミュレーター
- 会社紹介、ポートフォリオ、ランディングページ
- 外部APIやデータベースを使わない小型ツール
サーバー処理が必要なもの
- OpenAIなどのAPIキーを使うAIアプリ
- ログイン機能や会員情報を扱うサービス
- 問い合わせや予約情報をデータベースへ保存するアプリ
- 決済、メール送信、ファイルアップロードを行うアプリ
APIキーをブラウザ側のJavaScriptへ書く構成は避けてください。利用者はブラウザの開発者ツールや通信内容から値を確認できます。AI APIを使う場合は、ブラウザから自分のサーバー側APIを呼び、サーバー側だけが外部AIサービスへ接続する構成にします。詳しくはAPIキーを安全に管理する方法も確認してください。
判断に迷ったら、AIへ次のプロンプトを渡します。
このプロジェクトを公開したいです。コード全体を確認し、
1. 静的サイトだけで公開できるか
2. サーバー側処理が必要か
3. データベースが必要か
4. 環境変数へ移すべき値があるか
5. 公開先で必要なビルドコマンドと出力先
を、初心者向けに表で説明してください。
推測せず、判断に使ったファイル名と該当箇所も示してください。ステップ2：公開してはいけない情報を除外する
GitHubへ送る前に、APIキー、パスワード、データベース接続情報、顧客データが含まれていないか確認します。
特に注意するファイルは、.env、.env.local、設定ファイル、テスト用CSV、ログ、画面キャプチャです。秘密情報を環境変数へ移しただけでは不十分で、元ファイルをGitの追跡対象から外す必要があります。
.env
.env.*
!.env.example
node_modules/
dist/
*.log.env.exampleには変数名だけを残し、実際の値は書きません。
OPENAI_API_KEY=
DATABASE_URL=すでにGitHubへAPIキーを送った場合、ファイルを削除するだけでは安全になりません。キーを失効・再発行し、履歴に残った秘密情報も対処します。「誰も見ていないはず」ではなく、漏えいした前提で対応してください。
ステップ3：GitHubへコードを保存する
公開サービスとGitHubを連携すると、コードの変更履歴を残しながら自動公開できます。初心者は最初から複雑なブランチ運用をする必要はありませんが、本番用のmainと確認用ブランチを分けると事故を減らせます。
最低限、リポジトリには次を用意します。
README.md：アプリの目的、起動方法、必要な環境変数.gitignore：秘密情報と不要ファイルの除外.env.example：必要な変数名のみpackage.json：起動・ビルド方法- ライセンスや利用条件：再利用を許可する範囲
個人情報や顧客案件のコードがある場合、公開リポジトリにしないでください。非公開リポジトリでも、共同編集者の権限と外部連携サービスのアクセス範囲を確認します。
ステップ4：公開サービスへ接続し、ビルド設定を確認する
Vercel、Netlify、Cloudflare Pagesなどは、Gitリポジトリと連携して公開できます。サービス名だけで選ばず、次の条件で判断します。
| 確認項目 | 判断基準 |
|---|---|
| フレームワーク | 使用中のNext.js、React、Viteなどに対応しているか |
| サーバー処理 | APIや認証に必要な実行環境があるか |
| 無料枠 | 商用利用条件、帯域、実行回数を確認したか |
| 独自ドメイン | DNS設定とHTTPSに対応しているか |
| ログ | ビルド失敗・実行エラーを確認できるか |
| 移行性 | コードとデータを別サービスへ移せるか |
接続時に確認する主な設定は、フレームワーク、ルートディレクトリ、ビルドコマンド、出力ディレクトリです。Viteならビルド結果がdist、Next.jsならフレームワーク側の標準設定を使うことが多いですが、AIの回答だけで決めず、実際のpackage.jsonと公開サービスの検出結果を照合してください。
ステップ5：環境変数をプレビューと本番に登録する
APIキーやデータベース接続情報は、公開サービスのプロジェクト設定から環境変数として登録します。VercelではPreviewとProductionなど、環境ごとに値を分けられます。また、環境変数を変更しても過去のデプロイには反映されず、通常は再デプロイが必要です。
注意したいのは、NEXT_PUBLIC_やVITE_など、ブラウザへ公開される用途の接頭辞です。名称にPUBLICが付く変数へ秘密鍵を入れてはいけません。
登録後は、次の3点を確認します。
- プレビュー環境と本番環境の両方に必要な変数がある
- 変数名の大文字・小文字がコードと一致している
- 値をログやエラー画面へ表示していない
ステップ6：プレビューURLで公開前テストを行う
本番公開前に、スマートフォンとPCの両方でプレビューURLを確認します。自分のブラウザだけでなく、ログインしていないシークレットウィンドウでも試してください。
最低限のテスト表
| 分類 | 確認内容 | 合格条件 |
|---|---|---|
| 正常系 | 正しい入力で実行 | 想定した結果が表示される |
| 未入力 | 必須項目を空にする | 分かりやすい案内が出る |
| 異常系 | 長文・記号・不正な形式 | 画面が壊れず安全に拒否する |
| 通信失敗 | APIエラーを発生させる | 秘密情報なしの案内が出る |
| 再読み込み | 結果画面で更新する | 消えて困るデータを説明している |
| モバイル | 幅の狭い画面で操作 | 横スクロールやボタン欠けがない |
| 権限 | 未ログインで管理URLへアクセス | 管理機能を操作できない |
加えて、利用規約、プライバシーポリシー、問い合わせ先、運営者情報が必要かを判断します。個人情報を収集する場合は「何を、なぜ、どこへ保存し、いつ削除するか」を説明できる状態にします。
ステップ7：本番公開し、公開後の戻し方を決める
プレビューで問題がなければ、本番ブランチへ反映して公開します。公開直後はトップページだけでなく、主要機能、フォーム、OGP画像、404ページ、独自ドメイン、HTTPSを確認します。
公開前に「問題が起きたらどう戻すか」も決めてください。
- 直前の正常なデプロイを特定できる
- 本番を一時停止する判断者が決まっている
- APIキーを失効する手順が分かる
- 問い合わせ窓口と障害告知方法がある
- データベース変更前にバックアップがある
コードだけを前の版へ戻しても、データベース構造は戻らない場合があります。データを扱う更新では、バックアップと復元手順を先に確認します。
初心者に多い5つの失敗
1. ローカルで動いたので、そのまま本番へ出す
ローカルと本番ではURL、環境変数、権限、HTTPSが異なります。必ずプレビュー環境を挟みます。
2. APIキーをフロントエンドへ書く
画面上で見えなくても、ブラウザへ配信された値は秘密ではありません。サーバー側へ移します。
3. AIの「公開できました」を確認せず信じる
AIは実際のDNS、権限、課金状態を確認できないことがあります。最終確認は公開URLと管理画面の事実で行います。
4. 無料枠だけでサービスを選ぶ
商用条件、上限超過時の挙動、ログ保存期間、データ移行方法も確認します。費用の考え方はAIホームページ制作の費用も参考になります。
5. 公開後に誰も保守しない
依存ライブラリ、API仕様、ドメイン、証明書、請求方法には変更があります。月1回は動作と請求、アクセス権を確認します。
公開前チェックリスト
- ☐ 静的サイトか、サーバー処理ありか説明できる
- ☐ APIキーやパスワードがコードとGit履歴にない
- ☐
.gitignoreと.env.exampleを用意した - ☐ ビルドコマンドと出力先を確認した
- ☐ プレビュー環境で正常・異常・モバイルテストを行った
- ☐ 個人情報の保存先、利用目的、削除方法を確認した
- ☐ 独自ドメイン、HTTPS、404、OGPを確認した
- ☐ 障害時に前の正常版へ戻せる
- ☐ 公開後の担当者と点検日を決めた
まとめ
AIでWebアプリを作る時間は短くなりましたが、公開後の安全性と信頼性まで自動で保証されるわけではありません。初心者は「構成確認→秘密情報の除外→GitHub→プレビュー→テスト→本番→監視」の順番を守るだけでも、多くの事故を防げます。
これからアプリ自体を作る場合はAIでWebアプリを作る方法、指示の出し方はWeb制作プロンプト集、実装の進め方はAIコーディング初心者ガイドから先に読むと、制作から公開までを一続きで進められます。
公式参考資料
関連記事
