Vercel のレジストラAPIでドメインを取得し、既存サイトを無停止で乗り換える

*.vercel.app のサブドメインで運用中のサイトを、独自ドメインへ人手ゼロで移す手順。 ドメインの購入・DNS設定・リダイレクト・検証までAIが実行でき、人間の操作は「支払い方法が 未登録なら登録する」だけになる。実運用で踏んだ罠を全部書いてある。

前提

• Vercel にプロジェクトがあり、API トークンを持っている
• チーム配下なら teamId が全リクエストに必要
• チームに支払い方法が登録済み（Pro プラン等）なら、購入時にカード入力画面は出ず即時課金される

1. 旧APIは使えない

/v4/domains/status と /v4/domains/price は 2025-11-09 に廃止。 呼ぶと This endpoint has been sunsetted が返る。現行は /v1/registrar/...。

GET  /v1/registrar/domains/{domain}/availability   → {"available":true}
GET  /v1/registrar/domains/{domain}/price          → {"years":1,"purchasePrice":11.25,...}
POST /v1/registrar/domains/{domain}/buy

2. 扱えない TLD がある

availability はどの TLD でも available を返すが、price で初めて弾かれる。

GET /v1/registrar/domains/<例>.jp/price
→ {"code":"tld_not_supported","message":"The TLD .jp is not currently supported."}

購入可否の判定は availability ではなく price で行う。 国別 TLD が必要なら、 外部レジストラで買って DNS だけ Vercel に向ける構成になり、人間の操作が増える。 TLD の選択は「手間がゼロで済むか」を判断材料に含めて人に決めてもらう。

3. 購入ボディの必須項目は「わざと価格を外して」調べる

ドキュメントが指す「Get contact info schema」エンドポイントは 404 で存在しない。 エラーメッセージから逆算するしかないが、項目が全部揃った瞬間に購入が成立してしまう。

expectedPrice を実価格と違う値にしておけば、項目が揃っても expected_price_mismatch で必ず弾かれる。 これを安全弁にして形だけ調べられる。

// 購入は絶対に成立しない（実価格と違うので最後に弾かれる）
body: JSON.stringify({
  autoRenew: true, years: 1,
  expectedPrice: 1,            // ← 安全弁。実価格と変える
  contactInformation: contact, // ← 1項目ずつ埋めながらエラーを読む
})

判明した必須項目（gTLD の場合）:

autoRenew / years / expectedPrice / contactInformation{
  firstName, lastName, email, phone, address1, city, state, zip, country
}

phone は +81.9012345678 のように国番号とピリオド区切り。

4. 購入は非同期。注文IDで完了を待つ

buy は即座に {"orderId":"..."} を返すが、status は purchasing。 ドメインAPIを叩いても最初は見つからない。

GET /v1/registrar/orders/{orderId}   → status: purchasing → completed
GET /v5/domains/{domain}             → verified / expiresAt / renew

完了をポーリングするスクリプトを背景実行し、completed を見てから次へ進む。

5. ⚠️ 購入直後に届く確認メールを踏まないとドメインが止まる

これが最大の罠。 gTLD は ICANN 規則で登録者メールの到達確認が要る。 レジストラから [ACTION REQUIRED] Verify Your Domain Contact Information が届き、 15日以内にリンクを踏まないとドメインが一時停止される。

猶予期間中はサイトが正常に動くので、見た目では一切区別がつかない。 「購入API が 200」「サイトが表示される」は手続き完了の証拠にならない。

購入処理の最後に、受信箱でこの種のメールを探す工程を必ず入れる。 件名に ACTION REQUIRED / Verify / 確認 / 以内に を含むものは期限付きを疑う。 確認状態を API で照会できないサービスも多いので、督促メールの再着信を監視項目にする。

6. プロジェクトへの紐付けと www

POST /v10/projects/{project}/domains          {"name":"<domain>"}
POST /v10/projects/{project}/domains          {"name":"www.<domain>"}
PATCH /v9/projects/{project}/domains/www.<domain>
      {"redirect":"<domain>","redirectStatusCode":301}

DNS と SSL は Vercel が自動で張るので、数十秒で https:// が通る。

7. 旧ドメインからのリダイレクトは /(.*) で書く

vercel.json に書く。/:path* はルート / に当たらない（実測でルートだけ 200 のまま残った）。 正規表現形なら空パスも拾う。

{
  "redirects": [
    {
      "source": "/(.*)",
      "has": [{ "type": "host", "value": "<旧ホスト>" }],
      "destination": "https://<新ドメイン>/$1",
      "permanent": true
    }
  ]
}

permanent: true が返すのは 308（301ではない）。検索エンジンは301と同等に扱うので正常。 検証スクリプトを 301 固定で書くと、正しく動いているのに NG と誤判定する。

8. サイト内の旧URLを機械的に置換する

canonical・sitemap・robots・OGP・JSON-LD に旧ドメインが散らばっている。 grep -c で件数を数えてから一括置換し、ゼロになったことを確認する。

検査スクリプト側の許可ドメイン設定も忘れずに更新する。 これを忘れると、置換後に自前の静的検査が「許可外ドメインへのリンク」で落ちる。

9. 切り替えの検証（これを通してから完了と言う）

1. 新ドメインの全ページが 200 で、canonical が新ドメインを指し、旧ドメインの文字列が残っていない
2. 旧URL → 新URL が 301/308 で、パスが保たれている（/pricing → /pricing）
3. www → apex が恒久リダイレクト
4. sitemap.xml / robots.txt が新ドメインを指し、旧が残っていない
5. sitemap の各 URL が「リダイレクトなしで」200 を返す（ここが曲がると検索側で弾かれる）

5 は見落としやすい。サイトマップに書いた URL 自身がリダイレクトすると、 検索エンジンはインデックスを保留する。

10. 移行直後の「リダイレクトのため未登録」通知は無視してよい

検索コンソールが「ページにリダイレクトがあります」と警告するが、これは 検索エンジンが以前から知っている旧URLをクロールして、新設したリダイレクトに当たっているだけ。 新ドメイン側が直接 200 を返していることを確認できていれば、対処不要で、 新URLのインデックスが進めば消える。

掲載先への修正依頼は不要

外部のポータルサイト・地図サービスの投稿・印刷物のQRコードに旧URLが載っていても、 恒久リダイレクトが効いていれば切れない。修正依頼を出さない判断ができることを、 移行前に関係者へ伝えておくと無駄な往復が減る（修正依頼の回数に制限を設けている 掲載先もあるため、ここを節約できる意味は大きい）。