# 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` で必ず弾かれる。** これを安全弁にして形だけ調べられる。 ```js // 購入は絶対に成立しない（実価格と違うので最後に弾かれる） 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":""} POST /v10/projects/{project}/domains {"name":"www."} PATCH /v9/projects/{project}/domains/www. {"redirect":"","redirectStatusCode":301} ``` DNS と SSL は Vercel が自動で張るので、数十秒で `https://` が通る。 ## 7. 旧ドメインからのリダイレクトは `/(.*)` で書く `vercel.json` に書く。**`/:path*` はルート `/` に当たらない**（実測でルートだけ 200 のまま残った）。 正規表現形なら空パスも拾う。 ```json { "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が載っていても、 恒久リダイレクトが効いていれば切れない。**修正依頼を出さない判断ができることを、 移行前に関係者へ伝えておく**と無駄な往復が減る（修正依頼の回数に制限を設けている 掲載先もあるため、ここを節約できる意味は大きい）。 ---