デプロイ4回失敗した話——サイト公開の裏側

前回までで、サイトの見た目はできていた。記事も2本書いた。あとは「公開」するだけ。

それが意外と一筋縄ではいかなかった。

「公開する」ってどういうこと?

昔のWeb制作を知っている人なら、「サーバーにファイルをアップロードして終わり」というイメージがあると思う。レンタルサーバーを借りて、FTPソフトでファイルを置く。サーバーの中にコードもデータベースも画像も全部入っている。

今回の構成はまったく違う。

  • Sanity:記事と画像を保管している
  • GitHub:コードを保管している
  • Vercel:コードを受け取って、Sanityからデータを引っ張ってきて、サイトを組み立てて配信する
  • Xserver:ドメイン(matsuuratomoko.com)を管理している

全部バラバラ。一つのサーバーに全部入りではなく、役割ごとにサービスが分かれている。「公開する」とは、このバラバラのサービスを正しく繋ぐことだった。

4回目でようやく成功した

VercelにGitHubのリポジトリを繋いで、「Deploy」ボタンを押す。これだけのはずだった。

1回目:型エラー。サイトマップを生成するコードで、TypeScriptの型が合わないと怒られた。ローカルでは動いていたのに、Vercelのビルド環境だと厳密にチェックされる。Claude Codeに「直して」と言って修正。

2回目:チーム制限。Vercelの無料プラン(Hobby)は、コミッター(コードを書いた人)が1人しか許可されていない。Claude Codeがコミットしたとき、著者名が自分と違う名前になっていた。これもClaude Codeに「コミッターを自分の名前に直して」でforce push。

3回目:トークン無効。SanityのAPIトークン——つまりVercelが「Sanityさん、記事のデータください」と言うための合言葉——が期限切れになっていた。Sanityの管理画面で新しいトークンを発行して、Vercelの環境変数を更新。

4回目:成功。matsuuratomoko-site.vercel.appにサイトが表示された。

3つのエラーに共通しているのは、どれも「サービスとサービスの繋ぎ目」で起きたということ。コード自体は問題なかった。設定の不整合、認証の期限切れ、プランの制約。昔なら「サーバーの中」で完結していたトラブルが、今は「サービスの間」で起きる。

ドメインを繋ぐ——住所を引っ越す感覚

Vercelへのデプロイが終わっても、まだ「matsuuratomoko-site.vercel.app」という仮の住所でしかアクセスできない。本来の住所である「matsuuratomoko.com」に繋ぐ必要がある。

これはDNS(Domain Name System)という仕組みの設定変更。ざっくり言うと、「matsuuratomoko.comにアクセスしたら、Vercelのサーバーに案内してね」という転送設定を書き換える作業。引っ越しで郵便局に転送届を出すのに近い。

具体的には、Xserver(ドメインの管理元)にログインして、2つのレコードを変更した。

  • matsuuratomoko.com → VercelのIPアドレスに向ける
  • www.matsuuratomoko.com → Vercelが指定したアドレスに向ける

設定後、VercelのDashboardで「Valid Configuration」と表示され、SSL証明書も自動で発行された。https://matsuuratomoko.com でサイトが表示された瞬間は、素直に嬉しかった。

振り返ると、自分がやったのは「判断」だった

サイトが公開されて、ふと振り返った。コードを自分で書いた場面はほぼない。

型エラーが出れば、ビルドログを読んで原因がTypeScriptの型不一致だと把握した上で、Claude Codeに修正を任せた。コミッター制限に引っかかったときは、Vercelの無料プランの仕様を理解した上で、force pushで対応する判断をした。トークン期限切れは、SanityとVercelの認証の繋がりを理解していたから、どこを直せばいいかすぐわかった。

ブラウザ版のClaudeには、Vercelの設定画面やXserverの管理画面のスクリーンショットを共有しながら、設定手順を確認していった。途中でセッションが切れて、別の会話で経緯を伝え直すところから再開する場面もあった。これが今の「AIとの仕事」のリアルだと思う。スムーズな一本道ではなく、中断と再開を繰り返しながら進める。

関係者を整理すると、こうなる。Claude Code(コーディング)、Claudeブラウザ版(設定ナビゲーション)、GitHub、Sanity、Vercel、Xserver。手を動かしたのはほぼAI。でも、どのサービスをどう繋ぐか、エラーが出たときに何が原因かを切り分けて、次に何をするか決めたのは自分だった。

従来のWeb制作なら、見積もりを取って、コンセプト詰めて、デザイナーやエンジニアに外注して、数ヶ月はかかる。今回はリサーチから公開まで、トータル約5時間。自分個人の情報発信サイトといえど、早すぎる。(デプロイで何度もつまずかなければ、もっと早く終わっていた)

「こういうサイトを作りたい」と言語化すること。技術を選ぶこと。トラブルの原因を切り分けること。判断すること。——これ、今までやってきたPM(プロジェクトマネージャー)の仕事とまったく同じだなと思った。

お仕事のご依頼・ご相談はこちらから。

Contact →