Cloudflare + Vercel でマルチテナント DNS を設計する実務ノート (日本・2026 年版)

1. なぜ 1 zone に集約するのか — 5 プロダクト × 独自 zone の悲劇

最初にやりがちな失敗が「プロダクトごとに独自ドメインを取り、独立した zone として運用する」です。merci.jp / kotsukotsu.app / kotodama.io と 5 つ買うと、 (a) レジストラ費 5 本 (年 ¥1,500 × 5 = ¥7,500)、(b) DNS レコードが 散らばって「どこで何が動いているか」が把握不能、(c) SSL 証明書の 更新失敗が 5 zone それぞれで起こる、(d) ブランド統一が効かない、(e) メールの SPF/DKIM/DMARC を 5 回書く羽目になる、と管理コストが線形以上に膨らみます。

ClearNets は 2025 年に方針を「1 zone (clearnets.org) にすべての プロダクトをサブドメインでぶら下げる」と決めました。命名規則も シンプルに <product>.clearnets.org。この決定 1 つで、 DNS 管理・SSL・メール・SEO オーソリティ・GA4 プロパティ設計まで一気に 単純化されました。今 zone に生きているサブドメインは以下:

# 現在の clearnets.org zone (2026-08-17 時点、抜粋)
www.clearnets.org          → Vercel (会社 LP)
merci.clearnets.org        → Vercel (Merci チップ決済)
kotsukotsu.clearnets.org   → Vercel (Kotsukotsu 習慣トラッカー)
kotodama.clearnets.org     → Vercel (Kotodama LP)
api.kotodama.clearnets.org → Cloud Run (Kotodama API)
paircon.clearnets.org      → Vercel (家族見守りアプリ LP)
oshitabi.clearnets.org     → Vercel (オシタビ / β移行検討中)
signal.clearnets.org       → Cloudflare Tunnel → 自宅サーバ (Telegram bot)
arb-api.clearnets.org      → Cloudflare Tunnel → 自宅サーバ (Arbitrum bot)
status.clearnets.org       → Vercel (ステータスページ、将来)

1 zone なら「サブドメイン追加 = レコード 1 行足す」だけで済みます。 逆に独立 zone だと「新規プロダクト = 新規 zone 開設 + ネームサーバ設定 + SSL 発行 + WHOIS 情報 + プライバシー保護契約」と 30 分以上の オーバーヘッドが毎回発生する。個人開発の speed to market を殺す 典型的なアンチパターンです。

2. Cloudflare を DNS provider として選ぶ理由

DNS だけなら Route 53 / Google Domains (廃止) / Vercel DNS / お名前.com などいろいろ選択肢がありますが、ClearNets は Cloudflare を選んでいます。 理由は 5 つ:

• 無料枠が圧倒的: 1 zone 無制限、レコード無制限、 クエリ無制限。Route 53 は zone あたり月 $0.50 + クエリ従量、 5 zone あると月 $3 くらい掛かる。
• Anycast DNS の解決速度: 世界どこからでも <20ms。 Route 53 も同水準だが、Cloudflare の Web ダッシュボードのほうが UX が良い (体感)。
• DNS 以外の周辺サービスが 1 UI で完結: R2 (オブジェクトストレージ) / Workers (Edge Function) / Zero Trust (認証プロキシ) / Tunnel (自宅サーバへの逆プロキシ) / Turnstile (キャプチャ) / Images (画像最適化) が同じ zone / 同じ課金アカウント で使える。後述の R2 / Tunnel は Vercel に足りない機能を 埋める要 になります。
• Proxy (オレンジ雲) 経由で WAF / DDoS 保護が無料: Free プランでも標準の DDoS 保護 + rate limit + Bot Fight Mode が 効く。Vercel 単体だとこの層は自分で書く。
• API / Terraform 対応: レコード管理を GitOps 化 できる。ClearNets は現時点で手動運用だが、10 以上サブドメインが 増えたら Terraform 移行を検討予定。

トレードオフ: Cloudflare は「メール受信」はしない (Email Routing は あるが Free 制約あり)。メールは Google Workspace / Fastmail 等に外出し する前提。ClearNets は @clearnets.org の受信は Google Workspace (月 ¥720/user)、 送信は Resend + DKIM/SPF 設定を Cloudflare zone に記述、という分業に しています。

3. Proxy ON (オレンジ雲) vs DNS-only (グレー雲) — 判断基準

Cloudflare Zone の各レコードには「Proxy status」が付きます。オレンジ雲 = Proxy ON (Cloudflare 経由)、グレー雲 = DNS only (直接向く)。ここが Cloudflare + Vercel を使う時の 最大のハマりどころ です。

ClearNets の全 Vercel 向けサブドメインは グレー雲 (DNS only) で固定 しています。理由は以下:

• Vercel の SSL 発行が Let's Encrypt DNS-01 で通る: Proxy ON にすると Cloudflare が SNI を書き換えるため、Vercel 側の 自動 SSL 発行が失敗する。手動で Cloudflare Origin Cert を発行して Vercel に登録する回避策はあるが、証明書更新のオペレーションが 追加で発生する。個人開発で背負う価値はない。
• Real IP が取れなくなる: Proxy ON だと X-Forwarded-For が Cloudflare の Anycast IP になる。 Vercel の Edge Function で client IP を rate limit に使いたい時、CF-Connecting-IP header を明示的に読む書換えが必要。 忘れると全リクエストが同一 IP 扱いで rate limit が誤爆する。
• キャッシュ挙動が二重になる: Cloudflare の CDN と Vercel Edge Network が二重にキャッシュを持つ。ISR 期限切れの 再検証が Cloudflare 側で古いレスポンスを返し続ける事故が起きる。 Cache-Control header を Cloudflare 用にも書く必要があり、複雑化。

逆に Cloudflare Tunnel / Workers / R2 経由 のサブ ドメインはオレンジ雲 (Proxy ON) が前提。Vercel を経由しない 「自宅サーバに逆プロキシ」「Workers スクリプトを動かす」用途は Cloudflare の Edge 網に載せます。この Proxy ON / OFF の判断基準を 規約化して zone 全体で統一する:

# ClearNets zone の Proxy 規約
Vercel 向け サブドメイン → DNS only (グレー雲)
Cloud Run 向け           → DNS only (グレー雲、GCP の LB / SSL 使う)
Cloudflare Tunnel 向け   → Proxy ON (オレンジ雲、Tunnel の要件)
Cloudflare Workers 向け  → Proxy ON (Workers Routes 経由が必須)
R2 Custom Domain         → Proxy ON (R2 の CDN 層を使う)
メール MX / TXT (SPF/DKIM) → Proxy 不可 (DNS only 固定)

4. Vercel サブドメイン追加の実手順 — Zone File と Dashboard の両面

新規プロダクト example.clearnets.org を Vercel に 繋ぐ時の実手順を、DNS レコード書き方と Vercel Dashboard 操作の両面で 整理します。ClearNets ではこの流れで 5 分程度で開通できるように なっています。

1. Vercel Dashboard の Project Settings > Domains で「example.clearnets.org」を追加: この瞬間に Vercel が 「以下のレコードを DNS provider に追加してください」と CNAME 値を 提示してくる。多くの場合 cname.vercel-dns.com (または apex 用の A レコード 76.76.21.21)。
2. Cloudflare Dashboard > DNS > Records で CNAME レコード追加: Type = CNAME、Name = example、 Target = cname.vercel-dns.com、Proxy status = DNS only (グレー雲)、TTL = Auto。保存。
3. Vercel に戻り「Refresh」ボタン: 数秒〜 数分で Vercel 側が DNS 伝播を検知、SSL 発行が始まる。Let's Encrypt DNS-01 chal で 1-3 分で完了。
4. ブラウザで https://example.clearnets.org を確認: SSL warning が出なければ完了。dig / nslookup で dig example.clearnets.org CNAME +short して cname.vercel-dns.com が返れば OK。

# Cloudflare Dashboard で追加する DNS レコード例
# (BIND zone file 形式で書くと以下、実際は UI で登録)
example    IN  CNAME  cname.vercel-dns.com.    ; Proxy: DNS only

# apex ドメイン (clearnets.org 自体) を Vercel に向ける場合
@          IN  A      76.76.21.21              ; Proxy: DNS only
# ↑ apex は CNAME 不可 (RFC 1912) なので A レコード必須。
#   Cloudflare CNAME Flattening を使えば @ IN CNAME も書けるが、
#   Proxy ON 必須になるので Vercel との相性で今回は A レコード。

ハマりどころ: Vercel Dashboard で 「Invalid Configuration」と表示され続ける時は、以下を疑う:

• Cloudflare で Proxy ON にしてしまっている → OFF (グレー雲) に切替。
• CAA レコードで Let's Encrypt が拒否されている → @ IN CAA 0 issue "letsencrypt.org" を追加、または CAA レコード自体を削除。
• 既存の別 CNAME / A レコードが同じ Name で重複 → 古いレコードを 削除。
• Vercel の別 Project に同じドメインが登録済み → 元 Project から removal してから追加。1 domain 1 project の制約。

5. apex ドメイン (裸ドメイン) の扱い — CNAME Flattening vs ANAME

clearnets.org のような apex (裸) ドメインを Vercel に 向ける時、通常の CNAME レコードは RFC 1912 で使えません (apex には SOA/NS レコードがあるため衝突)。3 通りの回避策があります:

1. A レコード直指定 (Vercel の 76.76.21.21): Cloudflare UI で Type = A、Name = @、Content = 76.76.21.21、Proxy = DNS only。 ClearNets はこの方式。Vercel が IP を将来変更する時にレコード修正 必要な代わりに、Proxy 挙動がシンプル。
2. Cloudflare CNAME Flattening (@ IN CNAME): Cloudflare は独自拡張で apex にも CNAME を書ける。ただし Proxy ON 必須のため Vercel 相性が悪い。Cloudflare Pages に向ける場合は良い選択。
3. www に redirect + www を CNAME: apex を www.example.org にリダイレクト (Cloudflare Page Rules または Vercel の Redirects) して、www 側だけ CNAME する。 ClearNets は clearnets.org → www.clearnets.org のリダイレクトも併用しているので Vercel Redirects で処理。

推奨は「A レコード直 + www リダイレクト」の組合せ。Vercel が Anycast IP を将来変える可能性は低いが、変わったら Vercel Dashboard で 警告が出るので気付ける。

6. Cloudflare R2 を Vercel の bandwidth 節約に使う

Vercel Hobby プランの bandwidth は 100 GB / 月、Pro でも 1 TB / 月です。 画像・動画・PDF などの静的アセットが多いプロダクトはすぐ超過します。 ClearNets はユーザーアップロード画像を Cloudflare R2 に 保存し、Custom Domain (cdn.clearnets.org) 経由で配信 する 構成で bandwidth 課金を回避しています。

• R2 の料金モデル: Storage $0.015/GB/月、Class A ops (書込) $4.50/百万、Class B ops (読取) $0.36/百万、 Egress (転送) は完全無料。S3 / Vercel Blob と比べて egress 無料が決定的に効く。
• Custom Domain 設定: R2 Bucket > Settings > Custom Domain で cdn.clearnets.org を追加。 Cloudflare が自動で CNAME を生成、Proxy ON で CDN キャッシュも効く。<img src="https://cdn.clearnets.org/user/123.jpg"/> で配信可能。
• Vercel Blob との使い分け: 小規模 (5 GB / 10 GB egress 以内) は Vercel Blob で楽、超えるなら R2 に逃す。ClearNets は Kotodama の占い結果画像 (LLM 生成) を R2 に、Merci の店舗写真は Vercel Blob に、と分けている (今のところ両方 Hobby 無料枠内)。

// Next.js Route Handler から R2 にアップロード (S3 互換 SDK)
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const r2 = new S3Client({
  region: "auto",
  endpoint: `https://${process.env.R2_ACCOUNT_ID}.r2.cloudflarestorage.com`,
  credentials: {
    accessKeyId: process.env.R2_ACCESS_KEY_ID!,
    secretAccessKey: process.env.R2_SECRET_ACCESS_KEY!,
  },
});

export async function POST(req: Request) {
  const buf = Buffer.from(await req.arrayBuffer());
  const key = `user/${crypto.randomUUID()}.jpg`;
  await r2.send(new PutObjectCommand({
    Bucket: "clearnets-assets",
    Key: key,
    Body: buf,
    ContentType: "image/jpeg",
    CacheControl: "public, max-age=31536000, immutable",
  }));
  return Response.json({ url: `https://cdn.clearnets.org/${key}` });
}

R2 の bucket policy は Cloudflare の Custom Domain 経由なら public read で問題ないが、直 endpoint (*.r2.cloudflarestorage.com) を触らせない設定にしておくと 安全 (R2 Bucket > Settings > Public Access で off)。CDN 経由 のみ許可 → Origin URL を隠せる。

7. Cloudflare Tunnel で自宅サーバをドメイン配下に統合

ClearNets の一部プロダクト (Bitcoin API / Arbitrum bot / Signal Service) は自宅の Ubuntu VM で稼働しています。この自宅サーバにPublic IP を開けずに、clearnets.org のサブドメインで 公開する のに Cloudflare Tunnel を使っています。

• 仕組み: 自宅サーバに cloudflared デーモンを起動 → Cloudflare Edge に Outbound TCP 接続を張り続ける → Cloudflare が inbound を受けて Tunnel 経由で自宅に転送。ルータのポート開放不要、家庭用 NAT の 内側でも動く。
• DDoS / TLS / WAF が全部 Cloudflare 側: 自宅サーバ には plain HTTP しか届かない (Cloudflare が TLS 終端)。Origin の 設定は最小限で済む。
• 料金: Free プランで tunnel 数無制限。データ転送 もほぼ無制限 (Cloudflare の AUP 内なら)。ClearNets の Signal Service (Telegram bot) は月 10 GB 程度、完全無料。

# 自宅サーバでの cloudflared 起動 (docker-compose 版)
services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=${TUNNEL_TOKEN}
    restart: unless-stopped

# Cloudflare Dashboard > Zero Trust > Networks > Tunnels で
# tunnel 作成 → 「Public Hostname」タブで
#   Subdomain: signal
#   Domain: clearnets.org
#   Service: http://signal-service:8080  (docker network 内)
# を登録すると、signal.clearnets.org が自動で開通 (SSL + DNS 込み)

ClearNets が実運用している Tunnel 3 本 (bitcoin-api / arb-api / signal.clearnets.org) はすべて Free プランで安定稼働中。VPS を 追加借用する ($5/月 × 3 = $15/月) 選択肢と比べて、自宅の余った 電気代 (数百円/月) だけで済むのは個人開発には効きます。

8. Cloudflare Workers を「Vercel の外側」で使う場面

Vercel Edge Function と Cloudflare Workers は似ていますが、ClearNets では以下の使い分けをしています:

• Vercel Edge Function を使う場面: Next.js の middleware / API Route / Server Component / Server Action の一部。 Next.js の deployment lifecycle に組み込まれている。
• Cloudflare Workers を使う場面: (a) Vercel を経由 させたくない軽量プロキシ (画像リサイズ / URL 短縮 / IP allow list チェック)、(b) 複数プロダクト横断で使う共通処理 (ClearNets の Turnstile 検証プロキシなど)、(c) Vercel の cold start を回避したい 低レイテンシ用途、(d) Workers KV / Durable Objects / R2 と密結合 する処理。

実例: ClearNets の画像リサイズは Cloudflare Images ($5/月 + 従量) を 検討していますが、現在は Workers で自前実装 (cf-image-transform バインディング) → R2 に cache 書戻し、 という構成をテスト中。Workers のメリットは Free プランで 100k req/day 無料、CPU time 10ms 制限内なら十分回せる点。

// Cloudflare Workers 例: /r/{shortId} → 元 URL に redirect
// (KV に短縮 URL mapping を保存)
export default {
  async fetch(req, env) {
    const url = new URL(req.url);
    const m = url.pathname.match(/^\/r\/(.+)$/);
    if (!m) return new Response("Not Found", { status: 404 });
    const target = await env.URL_KV.get(m[1]);
    if (!target) return new Response("Expired", { status: 410 });
    return Response.redirect(target, 302);
  },
};

# wrangler.toml
name = "clearnets-url-shortener"
main = "src/index.ts"
compatibility_date = "2026-08-01"
routes = [
  { pattern = "r.clearnets.org/*", zone_name = "clearnets.org" },
]
[[kv_namespaces]]
binding = "URL_KV"
id = "xxxxxxxxxxxxxxxxxxxxxx"

9. Zero Trust で「開発中プロダクトの LP」に認証をかける

β 公開前の LP や社内向けダッシュボードに Basic 認証以上のちゃんとした 認証をかけたい時、Cloudflare Zero Trust (旧 Access) が刺さります。 Free プランで 50 seat まで無料、Google/GitHub SSO で自分の メールアドレスだけ通す設定が数分で完了。

• Application 登録: Zero Trust Dashboard > Access > Applications > Add Application > Self-hosted。Application domain に staging.clearnets.org を指定。
• Policy 設定: 「Emails ending in @clearnets.org」または特定メールアドレス allow list。第三者は 403。
• Identity provider: Google / GitHub / One-time PIN (メール送信) を選択。個人利用なら One-time PIN が楽。

ClearNets では β 前のオシタビ LP を Zero Trust で自分 + 招待メンバー だけに公開していた時期があります。Basic 認証と違って(a) SSO 済なら ログイン省略、(b) session 期限を設定可能、(c) Cloudflare Access JWT が Origin にも渡る ので Vercel 側で「ユーザ ID = 認証済メール」として扱える (Cf-Access-Authenticated-User-Email header)。

10. DNS Migration — 既存 zone を Cloudflare に移行する手順

既存 zone (お名前.com / Route 53 / Google Domains 廃止移管など) を Cloudflare に移行する時の実手順を整理します。ClearNets は 2 zone 移行済み (clearnets.org / donuts-ufo.com プライベート zone)。

1. Cloudflare で「Add a Site」: zone 名を入力、 Free プラン選択。数分で「既存 DNS レコードを scan した結果」が 表示される。この scan は完全ではないので、旧 provider の zone 全レコードを別途 export してつき合わせる。
2. 不足レコードの補完: Cloudflare の scan で漏れて いた MX / TXT (SPF/DKIM/DMARC) / CAA / SRV レコードを手動追加。 旧 provider から BIND zone file を export できるなら Cloudflare UI の「Import DNS Records」で bulk 投入。
3. ネームサーバ変更: レジストラ (ClearNets はお名前 .com) の管理画面で「ネームサーバを Cloudflare の指定 2 本 (例: aria.ns.cloudflare.com / brody.ns.cloudflare.com) に変更」。 変更後、DNS 伝播に最大 24-48 時間 (実際は 1 時間以内が多い)。
4. DNSSEC の再設定: 旧 provider で DNSSEC 有効化して いた場合、レジストラ側の DS レコードを Cloudflare のものに 張替える。放置すると DNSSEC validation 失敗で全 resolver から 「zone 破損」扱いされる (ClearNets は 2025 に 1 度踏んだ)。
5. Proxy ステータス点検: Cloudflare は移行時に一部 レコードを自動 Proxy ON にすることがある。Vercel 向け・API 向け・ MX / TXT は必ず DNS only に手動修正。

# 移行後の検証コマンド
# 1) NS がちゃんと Cloudflare を指しているか
dig clearnets.org NS +short
# → aria.ns.cloudflare.com. brody.ns.cloudflare.com. が返れば OK

# 2) 主要レコードが引けるか
dig www.clearnets.org +short
dig merci.clearnets.org +short
dig clearnets.org MX +short

# 3) DNSSEC が有効か
dig clearnets.org DS +short
dig clearnets.org DNSKEY +short

# 4) SSL 発行が通っているか (Vercel が証明書を再発行済か)
echo | openssl s_client -connect www.clearnets.org:443 -servername www.clearnets.org 2>/dev/null | openssl x509 -noout -issuer -dates

11. Custom Domain 移行時の SEO 事故対策 — canonical / sitemap / og:image

ClearNets が 2026 年 6 月に踏んだ痛い事故がこれです。OSHITABI の Production URL を oshitabi-clearnets.vercel.app から oshitabi.clearnets.org に移行検討した際、 sitemap.xml / canonical link / og:image / structured data の URL が 全部 vercel.app 固定でハードコードされていて、両 URL が同時に Google に index されて重複コンテンツ扱いで SEO オーソリティが 分散する 危機がありました。

対策として STABLE_PRODUCTION_URL を export const で 1 ヶ所に集約し、全参照はそれ経由に リファクタしました。この設計だと Domain 移行時に 1 ヶ所差替えで 完結します。

// lib/site-config.ts (1 ヶ所に集約)
export const STABLE_PRODUCTION_URL =
  process.env.NEXT_PUBLIC_SITE_URL ??
  "https://www.clearnets.org";

// sitemap.ts / robots.ts / og-image / metadata.alternates.canonical
// 全部これを import して使う
import { STABLE_PRODUCTION_URL } from "@/lib/site-config";

export const metadata: Metadata = {
  alternates: {
    canonical: `${STABLE_PRODUCTION_URL}/blog/xxx`,
  },
  openGraph: {
    url: `${STABLE_PRODUCTION_URL}/blog/xxx`,
    images: [`${STABLE_PRODUCTION_URL}/og/blog-xxx.png`],
  },
};

Domain 移行時の追加チェックリスト:

• 301 リダイレクト: 旧 URL (vercel.app) を新 URL に 301 (Permanent Redirect) で全 route 転送。Vercel の next.config.js の redirects() で書ける。
• Google Search Console の Change of Address: 新 URL プロパティを追加、旧 URL プロパティから「Change of Address」ツール で申告。オーソリティ移譲が 30 日程度で反映される。
• robots.txt の再確認: 旧 URL が Disallow: / になっていないか。ClearNets は 2026-06 に OSHITABI で robots.txt が 本番でも Disallow: / になっていて 3 日間検索から 消えていた事故を経験。NEXT_PUBLIC_* env の優先順 ミスが原因、テストの必要性を痛感。
• Sitemap の再送信: 新 URL の sitemap を Search Console から再送信、旧 URL の sitemap は削除。

12. メール送信の DNS レコード (SPF / DKIM / DMARC / MX)

ClearNets はメール送信を Resend、受信を Google Workspace で分けて います。この構成で必要な DNS レコード全体像を整理:

# clearnets.org zone のメール関連レコード
# MX (Google Workspace 受信)
@   IN MX  1  smtp.google.com.

# SPF (送信元 IP 許可)
# Resend と Google の両方を allow する
@   IN TXT "v=spf1 include:amazonses.com include:_spf.google.com ~all"

# DKIM (Resend 発行、Resend Dashboard で確認)
resend._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq...(長い文字列)"

# DKIM (Google Workspace 発行、Admin Console で確認)
google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq...(長い文字列)"

# DMARC (両方の DKIM/SPF を組合せてポリシー宣言)
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@clearnets.org; ruf=mailto:dmarc@clearnets.org; sp=quarantine; adkim=r; aspf=r; pct=100"

ハマりどころ:

• Cloudflare の TXT レコードは 255 文字を超えると自動で分割される (RFC 準拠)。DKIM 公開鍵は長いので分割されるが、送信側は連結して 扱うので問題なし。手動で分割して入れないこと (二重分割で壊れる)。
• SPF の ~all (soft fail) vs -all (hard fail) の選択。運用初期は ~all 、DKIM/DMARC が 安定稼働してから -all に厳格化するのが安全。
• DMARC の p=quarantine か p=reject か。初期は p=none で monitoring only、rua レポートで 異常がないことを 2 週間確認後 p=quarantine に上げる。
• MX レコードは Proxy 不可 (Cloudflare の Proxy は HTTP/HTTPS のみ、 SMTP は素通せない)。UI で自動的に「Not Proxied」になるはず。

13. 実運用トラブル 4 事例と教訓

ClearNets が実際に Cloudflare + Vercel で遭遇した本番トラブルを 4 つ、原因と復旧手順で整理します。

1. 事例 1: Vercel の SSL 発行が 3 日通らない (2025-11)
   症状: 新規サブドメイン (kotsukotsu.clearnets.org) を追加したが Vercel Dashboard で「Configuration issue」が消えず、SSL 発行が 回らない。
   原因: Cloudflare で誤って Proxy ON にしていて、Let's Encrypt DNS-01 の chal record を Cloudflare が返せていなかった。
   対処: Cloudflare の該当レコードを DNS only (グレー雲) に変更、 Vercel Dashboard で「Refresh」ボタン → 数十秒で SSL 発行完了。 規約: 「Vercel 向けは常に DNS only」を規約化。
2. 事例 2: ネームサーバ移行後の DNSSEC 破損 (2025-09)
   症状: Cloudflare にネームサーバ移行した翌日から、一部 ISP (楽天モバイル) から clearnets.org が引けない苦情。
   原因: 旧 provider (お名前.com) 時代の DNSSEC 設定 (DS レコード) が Cloudflare の DNSKEY と不一致になっていた。DNSSEC validating resolver からは全部 SERVFAIL。
   対処: レジストラ (お名前.com) の管理画面で古い DS レコードを 削除、Cloudflare で新規 DNSSEC を有効化して新 DS レコードを レジストラに登録。数時間で回復。教訓: ネームサーバ移行時はDNSSEC は一旦無効化してから移行、Cloudflare 側で 安定してから再度有効化。
3. 事例 3: Cloudflare Tunnel の再起動で全 bot down (2026-04)
   症状: 自宅 VM の OS 更新後、Cloudflare Tunnel 経由の 3 プロダクト (bitcoin-api / arb-api / signal) が全部 offline。
   原因: cloudflared コンテナが単一 compose にまとまって いて、tunnel restart 時に 3 プロダクト同時 down。
   対処: 各プロダクトごとに docker-compose.yml を分離、cloudflared コンテナもプロダクト単位で持たせる 構成に変更 (bitcoin-api / arbitrum-arb / signal-service の 3 compose)。以降は 1 プロダクト死んでも他は生存。CLAUDE.md にも この構成方針を明記。
4. 事例 4: DMARC 有効化で自社メールが SPAM 判定 (2026-02)
   症状: DMARC を p=quarantine に上げた翌日から、 Resend 経由で送っていた Kotodama のパスワードリセットメールが Gmail で SPAM フォルダに直行。
   原因: Resend の DKIM は登録済だが、SPF レコードに Resend の include (amazonses.com) を追加し忘れていた。 DMARC が「SPF fail かつ DKIM は pass だがドメインアラインメントに 問題」で quarantine 判定。
   対処: SPF レコードに include:amazonses.com 追加。 翌日から通常配信復帰。教訓: DMARC を上げる前に 2 週間 p=none で rua レポートを確認、SPF / DKIM alignment が両方 pass することを検証してから厳格化。

14. まとめ — 1 zone に集約し、Proxy 判断を規約化する

Cloudflare + Vercel の組合せは、個人開発〜少人数チームで複数プロダクト を回すのに最強コスパです。ClearNets の 5 プロダクト + 3 Tunnel が全部無料枠 or 最低限 ($0-5/月) で回っていて、 DNS / SSL / DDoS / メール / ストレージ (R2) / 認証 (Zero Trust) が 1 UI で完結します。

本記事の要点 4 つに絞ると:

1. 1 zone に集約 — プロダクトごとに zone を作らず、<product>.clearnets.org で命名統一。
2. Proxy 判断を規約化 — Vercel は DNS only、Tunnel / Workers / R2 は Proxy ON。混在させると SSL / IP / cache が壊れる。
3. STABLE_PRODUCTION_URL を 1 ヶ所に集約 — Domain 移行時に SEO 事故を起こさないための最重要リファクタ。
4. 移行時は DNSSEC を一旦切る — ネームサーバ切替と DNSSEC の同時変更で破損する事故を防ぐ。

これらを踏まえておけば、Cloudflare + Vercel は「小さく始めて プロダクトが増えても料金・複雑度が線形以下」で運用できる、個人開発の インフラ標準構成として非常に強力です。