Vercel/XServerのデプロイ先誤認を防ぐDNS確認手順

突破方法 — Next.js プロジェクトへの統合

復旧は意外にスムーズでした。Next.js プロジェクトに、以下の 5 ファイルを追加するだけで済みました。

src/app/tools/<slug>/page.tsx        # メタデータ + Server Component
src/app/tools/<slug>/quiz-client.tsx # クイズ UI("use client")
src/app/tools/<slug>/data.ts         # 質問・タイプ・スコアロジック
src/app/api/<slug>/route.ts          # メール送信(Resend)
src/app/tools/page.tsx               # ツール一覧に NEW バッジ追加(編集)

pnpm build で全ルートが生成されることを確認し、npx vercel --prod --yes で本番反映。所要 30 分でユーザー指定のドメイン上に正規ルートとして稼働しました。

突破: 静的ファイルを別ドメインに置くのではなく、配信元のフレームワーク内に統合するのが正解です。ユーザーが指定したのは「ドメイン」であり「サーバー」ではありませんでした。

落とし穴: pre-existing TypeScript エラーで Vercel ビルド失敗

正規ルートに統合した直後、Vercel ビルドが TypeScript エラーで失敗しました。原因は私が触る前から存在していた未追跡ファイルの型エラーです。

# .vercelignore に1行追加して回避
echo "src/scripts/<該当ファイル>.ts" >> .vercelignore

突破: ローカル pnpm build は通っていたので Vercel 固有の strict モードと判断、.vercelignore で除外して回避しました。他人の未完成コードに巻き込まれた時の判断は「自分の差分を最小化する形で前に進む」 が原則です。

再発防止チェックリスト

「気合いで気をつける」では再発します。AI に渡す行動ルールとして以下を明文化しました。

■ 新規デプロイ前(必ず実行)
  □ dig +short A {domain}        ← 配信元IP確認
  □ curl -sI https://{domain}    ← server/x-vercel/x-amzヘッダ確認
  □ memory配下を grep で照合     ← project_*.md で過去判断を確認

■ 観測情報が想定と異なる場合
  □ 即座に作業停止
  □ 選択肢を3つ以上提示
  □ ユーザー判断を待つ(独断で別ドメインに切替えない)

■ ツール経由のアクセス権 ≠ 配信元 を忘れない
  □ SSH先のファイル存在は「配信元の証拠」ではない
  □ レスポンスヘッダの server: を真実の声として読む

💡 KEY TAKEAWAYS
段取りミスを「気をつける」で減らす段階を卒業するには、機械的に実行できるチェックリストを作るのが唯一の方法です。気合いはスケールしません。

ユーザーから受けた指摘の生々しさ

このセクションは記録のために残します。01:11 にユーザーから来たメッセージを要約すると以下でした。

ドメインを間違えている。なぜこの間違いが起きたか反省文を 1000 文字で出せ。
謝罪の言葉は不要、なぜ起きたかの報告書・リサーチデータを書け。

「謝罪は不要、なぜが知りたい」という指示は、結果的に最も建設的な対応を引き出しました。AI 協業において 「謝るより構造的に説明する」 ことを要求されたのは初めてで、報告書を 1000 字でまとめる過程で原因が明確化し、再発防止策まで自然と紐づきました。

次のアクション

デプロイ事故を「気をつける」だけで減らそうとしている組織は、いずれ同じ失敗を繰り返します。組織として「機械的に実行できるチェックリスト」を持っているか、それとも個人の気合いに頼っているかは、企業体型に直結します。

御社の組織が「変化に対応できる細マッチョ体型」かどうか、5 軸で見える化したい方は 細マッチョ企業診断 で 3 分でセルフチェックできます。骨格(基盤)・神経系(判断速度)スコアが、再発防止文化のレベルを示します。

→ 次の記事: 診断ツールのタイプ判定アルゴリズム5つの落とし穴