ブラウザIDEからVercel・Netlifyへデプロイする

明らかなのは、CLI のインストールが面倒、または禁止されているマシンです。Chromebook、学校のラボ PC、ロックダウンされた社用デスクトップでは、ブラウザのタブは開けても Node.js、Git、プロバイダーの CLI をいつも入れられるわけではありません。ブラウザ IDE は編集の時点でその要件をすでに外しています。デプロイはたいてい、開発者をターミナルへ戻す最後の工程です。同じタブに置けばループが閉じます。ローカルツールチェーンなしで編集、プレビュー、公開まで完結します。2 つめは速度です。ランディングページ、プロトタイプ、クライアント向けデモは、リポジトリや CI パイプラインより先に URL が必要なことがあります。ブラウザのパネルは現在のスナップショットを公開し、公開先を表示します。ただし便利さには境界があります。これは直接アップロードであり、デプロイパイプラインではありません。ブランチを監視せず、テストを実行せず、環境間でビルドを昇格させません。それはプロバイダーの Git 連携か CI の仕事です。ブラウザの経路は最初の URL のためであり、リリース工程全体のためではありません。

Deploy ダイアログは 2 つのプロバイダー API の上に載る薄い操作面です。Deploy now を押すと、GB Coder は Download ZIP と同じファイルバンドルを作ります。ここが重要です。スタイルシートを落としたり外部ライブラリを忘れたりする別のパッケージ経路はありません。プレーンなプロジェクトは index.html、style.css、script.js、README になります。React または Vue のプロジェクトは、index.html、package.json、vite.config.js、.gitignore、README、src/ 以下のソースを持つ Vite 形式のツリーになります。ダイアログのバンドル概要には、タブの外へ出る前の正確なファイル数と非圧縮サイズが表示されます。Vercel はデプロイ用エンドポイントにインライン JSON としてファイルを受け取ります。Netlify は ZIP をリクエストの生ボディとして受け取ります。Vercel はビルドまたは配信し、Netlify はアップロードされたファイルを手動デプロイとして公開します。LadeStack のサーバーは間に入らず、あなたのマシンで CLI も動きません。ブラウザがクライアント、プロバイダーがホスト、トークンが唯一の認証情報です。「ワンクリック」はインターフェースの説明であり、作業量の説明ではありません。パッケージ、アップロード、リモート処理、TLS は順番に起こります。

バンドルが異なるのは、2 種類のプロジェクトで扱いが違うからです。プレーンな HTML/CSS/JavaScript プロジェクトには package.json がありません。Vercel にはフレームワークを使わないよう指示し、ファイルを静的サイトとして配信します。Netlify は ZIP をそのまま公開しますが、これも静的ファイルには適しています。インストールもコンパイルもないため、最初のデプロイは通常すぐ終わります。React や Vue のプロジェクトには生成された package.json、Vite 設定、ソースファイルが含まれます。Vercel では、プロバイダーが Vite を検出し、依存関係をインストールし、本番ビルドを実行して出力を公開します。これはブラウザ内のシミュレーションではなく実際のクラウドビルドなので、1 分以上かかることがあります。Vercel が使うのは package.json に記録されたバージョンで、たまたまエディタに読み込まれていたものではありません。Netlify の手動 ZIP デプロイはビルドコマンドを実行しないため、同じ Vite ソースツリーはアップロードされたまま、コンパイルされずに公開されます。Netlify で React や Vue を使う場合は、プロバイダーの Git 連携を使ってください。Netlify のワンクリック経路は静的出力のみを公開します。外部ライブラリと注入設定はすでにバンドルに反映されています。Vercel のビルドがプライベートパッケージ、ネイティブバイナリ、ビルドイメージから届かないサービスに依存していると、ローカルのプレビューが動いてもビルドは失敗します。どのケースかはログで確認できます。

どちらのプロバイダーも個人アクセストークンで認証します。プロバイダーのパスワードでも GB Coder のアカウントでもありません。ダイアログは選択したプロバイダーのトークンページへリンクし、スコープを平易に説明します。Vercel のトークンは、アカウントまたはチームが到達できるすべてのプロジェクトに公開できます。チームスコープのトークンがある場合はそれを使ってください。Netlify のトークンはアカウントがアクセスできるサイト全体に作用するため、より狭い選択肢がなければアカウント全体として扱います。この用途のためにトークンを作り、必要最小限の有効期限を設定し、不要になったらプロバイダーで失効させます。GB Coder は、Deploy now を有効にする前にトークンの有無とバンドルがローカル上限内かを確認します。トークンは既定ではタブのメモリ内だけに保持されます。Remember on this device はオプトインです。安全なオリジンでは localStorage に書き込む前に AES-GCM で封印し、そうでない場合は平文で保存されることをダイアログが警告します。もっとも重要な管理はスコープと失効です。

プロジェクトを開き、ツールバーの Deploy を選びます。狭い画面ではオーバーフローメニューにあります。既定では Vercel が選択され、Netlify は 1 クリック先です。プロジェクト名は現在のプロジェクトから自動入力されます。GB Coder は小文字にし、無効な文字をハイフンに置き換え、要求するホスト名（例: your-project.vercel.app）を表示します。トークンを貼り付け、記憶するかどうかを選び、バンドル概要を確認します。ファイル数またはサイズが上限を超えている場合、ダイアログは理由を示し、ボタンを無効のままにします。Deploy now を押すと、プロバイダーがプロジェクトまたはサイトを作成し、バンドルを受け取り、デプロイの処理を開始します。デプロイの準備ができると、成功画面に公開 URL、ファイル数、アップロードサイズ、経過時間、スマートフォンで開くための QR コードが表示されます。Copy URL と Visit site は受け渡し用で、Build logs はプロバイダー自身のログ画面を開きます。Netlify のサイト名は世界共通なので、希望した名前が使われていることがあります。その場合は別の名前が割り当てられ、GB Coder は入力した名前ではなく実際に公開されているアドレスを報告します。

進行バーは、パッケージ、アップロード、ビルド、保護、完了の順に進みます。Netlify では、ビルドという表示はプロバイダー側の処理を指し、ビルドコマンドを意味しません。これはクライアントからの報告であり、プロバイダーの予測ではありません。割合は最初の 2 段階で進み、プロバイダーがリモート処理を終える間は 100 未満で止まります。これは意図的です。リモート処理の時間は予測できず、99% まで一気に進むバーは嘘をつくことになります。GB Coder は 1.5 秒ごとにプロバイダーをポーリングし、状態が変わるとメッセージを更新します。アップロードリクエストには 2 分のタイムアウトがあります。パネルはデプロイのポーリングを 3 分で打ち切り、ダッシュボードへ案内します。ブラウザが見るのをやめてもデプロイが完了することがあるからです。キャンセル、ダイアログを閉じる、Escape を押すと、進行中のリクエストとポーリングループが中断されます。プロバイダーがすでにデプロイを受け付けていれば、向こう側でデプロイが続くことがあります。キャンセルがロールバックを意味すると決めつけず、ダッシュボードを確認してください。デプロイが失敗したときは、プロバイダーのログが信頼できる情報源です。

Deploy again はフォームに戻るだけで、最後のバンドルをすぐ再送信しません。プロジェクトが変わった、名前を調整したい、トークンが切れた、といった場合に便利です。そこから Vercel と Netlify は同じアドレスへ別の経路を取ります。Vercel は指定したプロジェクトに対してデプロイを作成し、本番を対象にします。同じプロジェクト名での繰り返しデプロイはそのプロジェクトを更新し、デプロイ固有の URL より本番エイリアスが優先されるため、共有するアドレスは通常安定します。Netlify は新しいサイトを作らず既存サイトを更新するためにサイト ID が必要です。GB Coder はサニタイズされたサイト名をキーに、その ID を localStorage に記憶します。ブラウザストレージを消去した、ブラウザを変えた、名前を変えた、Netlify でサイトを削除した場合、次のデプロイは古いサイトを見つけられず新規作成します。そのため Netlify プロジェクトの名前変更は、以前のサイトをアカウントに残すことがあります。両プロバイダーともデプロイ履歴、カスタムドメイン、アクセス制御、ロールバックをダッシュボードで管理します。GB Coder のパネルが扱うのはアップロードと公開 URL だけです。ここからのデプロイはすべて本番デプロイで、ブランチプレビューや環境選択はありません。

タブの外へリクエストが出る前に 2 つの上限が適用されます。900 ファイルと、非圧縮で 64 MB です。プロバイダー自身の上限より低く設定し、巨大なアップロードがブラウザセッションの途中で失敗しないようにしています。メディアの多いサイトは、大きな画像や動画をプロジェクトバンドルではなく CDN や Git に置くべきです。エラーは原因別に分かれます。401 はトークン拒否、403 は通常アカウントまたはチームへの権限不足、413 または 429 はペイロード過大かレート制限、422 はプロジェクトが無効として拒否されたこと、5xx は通常一時的です。Vercel では、フレームワークのビルド失敗は別です。アップロードは成功し、ビルドが失敗しているので、新しいトークンを貼るのではなくログを読んでください。Vercel のビルドで環境変数が必要な場合も別の境界です。デプロイダイアログに環境変数のエディタはありません。Vercel のプロジェクト設定で値を設定し、再度デプロイします。最初のビルドは、設定先のプロジェクトができる前に失敗することがあります。Netlify の手動 ZIP 経路にはビルド手順がないため、これは当てはまりません。3 分のポーリング上限はデプロイの失敗ではなく、待機の失敗です。

デプロイ経路は直接です。ブラウザがトークンを使って api.vercel.com または api.netlify.com を呼びます。認証情報を保存するプロキシはなく、パネルの利用に LadeStack アカウントも不要です。トークンは既定でセッションのみで、安全なオリジンで記憶を選んだ場合に限り AES-GCM で封印されます。これはブラウザプロファイルのバックアップやサポートバンドル内で読めるトークンを防ぎますが、タブが開いている間に同じオリジンで動く悪意あるコードは防げません。利用可能な中で最も狭いトークンを使い、有効期限を設定し、作業が終わったらプロバイダーで失効させてください。所有権はトークンに従います。プロジェクトまたはサイトは、それを所有するプロバイダーアカウント内に、その規約、割り当て、ログ、請求のもとで作成されます。GB Coder は local-first のままですが、デプロイはプロジェクトをプロバイダーへ明示的にエクスポートする行為です。プロバイダーはサイトのソースを受け取り、結果は既定で公開 HTTPS URL になります。パスワード保護、SSO、カスタムドメインはプロバイダーの機能です。ブラウザプロファイルがプロジェクトの唯一の保管場所にならないよう、ZIP か GitHub のコピーを残してください。

小さなサイトをすぐ公開したいときにこの経路を使います。ランディングページ、ポートフォリオ、授業のデモ、クライアントレビュー用プロトタイプ、静的なドキュメントページなどです。プロジェクトがすでに GB Coder にあり、代わりに ZIP を書き出してターミナルを開き、自分のものではないマシンで CLI を設定するしかない場合にも向いています。モノレポ、データベース付きのサーバーレンダリングアプリ、プライベートレジストリの認証情報が必要なビルド、ブランチプレビューと承認でリリースするチーム、アップロード上限を超えるアセットには向きません。それらはプロバイダーの Git 連携、CI パイプライン、デスクトップ環境の仕事です。2 つの方法は共存できます。ブラウザで下書きと反復を行い、履歴に値する段階でソースを GitHub に push し、本番ビルドは CI に公開させます。実用的な手順は短いものです。スマートフォン幅でプレビューを確認し、バンドル概要を見て、デプロイし、別の端末で公開 URL を開き、ビルドログを保存します。試すには /app/projects のプロジェクトダッシュボードを開き、プロジェクトを作成または開いて Deploy を選んでください。設定のリファレンスはドキュメントにあります。