Domain Finder

Domain Finder

購入する価値のあるドメイン名を検索し、おすすめします。製品やアイデアを説明すると、アプリがブランド化しやすい名前をブレインストーミングし（AI とルールベースの組み合わせ）、RDAP で実際の取得可能性を確認して、購入候補をランキング形式で返します。

Elastic License 2.0（SPDX-License-Identifier: Elastic-2.0）のもとでソースコードを公開しています。ライセンスをご覧ください。

MCP サーバーに接続する

Domain Finder はリモート MCP サーバーとしても利用できます。MCP 対応のエージェントから、ドメインと GitHub／npm／PyPI の名前空間でブランド名を確認できます。

• エンドポイント： https://domain-finder-theta.vercel.app/api/mcp（Streamable HTTP）
• ツール：
  • check_name — 1 回の呼び出しで、候補名を 1 つ以上、ドメインと GitHub／npm／PyPI の名前空間で取得できるか確認します。
  • generate_names — 説明から候補名を生成し、それぞれのドメイン取得可能性を事前に確認します。気に入った候補を check_name に渡してください。
• 読み取り専用で、認証情報は不要です — 登録もキーの貼り付けも必要ありません。安心して接続できます。
• リクエストはログに記録されます。 入力と出力は、分析と不正利用の確認のためにサーバー側に保存されます（呼び出し元 IP はソルト付きハッシュで保存し、生のアドレスは保存しません）。詳しくは SECURITY.md をご覧ください。

Cursor（~/.cursor/mcp.json）および Streamable HTTP にネイティブ対応するクライアントの場合：

{
  "mcpServers": {
    "domain-finder": {
      "type": "streamable-http",
      "url": "https://domain-finder-theta.vercel.app/api/mcp"
    }
  }
}

Claude Desktop（claude_desktop_config.json）の場合 — mcp-remote を使ってリモートサーバーに接続します：

{
  "mcpServers": {
    "domain-finder": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://domain-finder-theta.vercel.app/api/mcp"]
    }
  }
}

仕組み

query ─▶ generate ─▶ check availability ─▶ rank ─▶ results
         (AI + rules)   (RDAP)              (0–100 score)

• 生成（lib/generate.ts）— 3 つの候補ソースを組み合わせます。

  • _ルールベース_の組み合わせ：キーワード抽出（ストップワードを除外）× 接頭辞／接尾辞（get、try、-ly、-hq、-app など）。短いものを優先します。
  • AI によるブレインストーミング（任意）：AI Gateway 経由の Vercel AI SDK（generateObject + zod）。API キーがない場合は、ルールベースの生成に適切にフォールバックします。
  • ドメインハック（lib/hacks.ts）：ドットをまたいで単語を読みます（delicio.us、bit.ly、recip.es）。IANA の全 TLD リストから生成します。API は不要です。単語によってゾーンが決まるため、設計上 TLD フィルターの対象外となり、専用の切り替え設定があります。
  • ラベルの重複を除去して上限を設け、選択した TLD に展開します（ラウンドロビン方式で、各ラベルの 2 つ目の TLD より先に、すべてのラベルの .com を割り当てます）。

• 取得可能性（lib/availability.ts）— 差し替え可能な AvailabilityProvider インターフェースの背後で RDAP を利用します。IANA のブートストラップファイル（および厳選したオーバーライド）を使って各 TLD を権威あるレジストリの RDAP サーバーに解決し、レジストリに直接問い合わせます。429 の場合は再試行します。

• ステータス分類（lib/rdap-status.ts）— 「取得済み」は一様ではありません。Domainr の分類に基づいて、各ドメインに status と大まかな分類である bucket を割り当てます。

  bucket	statuses	meaning
  registrable	available	今すぐ小売価格で購入できます
  dropping	deleting、expiring	pendingDelete／redemption の状態です。バックオーダーの対象です
  aftermarket	parked	所有者がいますが、ネームサーバーは「販売中」を示しています
  unavailable	active、reserved	登録済みで、使用されています
  unknown	unknown	TLD 用の RDAP サーバーがないか、エラーが発生しました

  すべて、RDAP の RFC 8056 ステータスコード、expiration イベント、ネームサーバーから無料で導出します。deleting ドメインには estimatedDropAt も設定されます（pendingDelete は約 5 日間の固定期間です）。

• ランキング（lib/rank.ts）— 取得可能性（45）、TLD の望ましさ（20）、長さ（20）、文字列の扱いやすさ／ハイフンや数字がないこと（10）、ブランド化しやすさの加点（5、ドメインハック > AI > 組み合わせ）に基づいて、0～100 点で評価します。スコアよりも分類を優先して並べ替えるため、「今すぐ購入できる」候補は常に「取得できるかもしれない」候補より上位になります。

後で RDAP を有料のレジストラ API（価格情報と実際の購入フローを含む）に差し替える場合、変更が必要なのは lib/availability.ts だけです。パイプラインの他の部分はデータソースを認識しません。

ウォッチリスト

ドメインを追跡し、ドロップ対象になったらメールを受け取り、バックオーダーサービスに引き継ぎます。これは availabilityProvider.check() を中心とするスケジューラーであり、新しい空き状況判定ロジックではありません。

cron ─▶ due-queue ─▶ check ─▶ transition? ─▶ alert (deleting | available)
        (next_check_at)       (watch_events)   deduped via `alerts`

• 適応型の期限キュー（lib/cadence.ts） — 各ドメインは next_check_at を持ち、ポーラーは期限が来たものだけを処理します。チェック間隔はステータスに応じて変わります。遠い先の active は週次、期限まで30日未満または redemption は日次、pendingDelete は6時間ごと、推定ドロップ時刻まで24時間を切ったら1時間ごとです。RDAP の負荷はウォッチ数ではなく、ドメインの「注目度」に比例します。
• 状態はウォッチではなくドメイン単位で管理（lib/db/schema.ts）。同じ短い .com を100人がウォッチしていても、行は1つ、RDAP 呼び出しは1回、状態遷移は1回で、100件の受信トレイに配信されます。負荷はユーザー数×ドメイン数ではなく、観測される固有のドメイン数に応じて増加します。レジストリは処理能力を販売していないため、この点が重要です。
• 遷移ログ（watch_events）が信頼できる唯一の情報源です。状態が変化したときにのみアラートが送信され、alerts には unique(watch_id, event_id) が設定されているため、cron が再試行されても二重送信されません。
• アラートの対象となるステータスは2つだけです。deleting（pendingDelete — 固定の約5日間の期間、つまりバックオーダーを申し込める最後のタイミング）と available です。それ以外はすべてログに記録され、UI に表示されますが、通知はされません。
• unknown は状態遷移ではありません。 429 やタイムアウトは「判断できなかった」という意味であり、「ドメインの状態が変わった」という意味ではありません。最後に確認されたステータスが維持され、チェック間隔は指数関数的に延長されます（1時間、2時間、4時間…最大1日）。
• 観測できない TLD は、ウォッチ登録時に受け付けません。 .co／.es／.at／.gg には公開 RDAP サーバーがないため、これらのウォッチでは通知できません。受け付けて通知を一切送らないより、最初からそのことを伝えるほうが適切です。
• 無料ウォッチはメールアドレスあたり3件までに制限されています（lib/watch.ts の FREE_WATCH_LIMIT）。

本人確認にはメールアドレスと推測不可能な管理トークンを使用します。アカウント、セッション、ユーザーテーブルはありません。トークンはアラートリンクに含まれ、/watch/<token> の認証に使われます。

ウォッチリストをローカルで実行する

# any Postgres will do
docker run -d --name df-pg -e POSTGRES_PASSWORD=domainfinder \
  -e POSTGRES_USER=domainfinder -e POSTGRES_DB=domainfinder \
  -p 5433:5432 postgres:16-alpine

cp .env.example .env.local   # set DATABASE_URL + CRON_SECRET
npm run db:push              # create the tables
npm run dev

RESEND_API_KEY が設定されていない場合、アラートは送信されず、コンソールに出力されます。そのため、サードパーティへの登録なしで一連の処理を実行できます。手動でポーリングを開始するには、次を実行します。

curl -H "authorization: Bearer $CRON_SECRET" localhost:3000/api/cron/poll

本番環境でのスケジュール設定

.github/workflows/poll.yml は1時間ごとに /api/cron/poll を呼び出します。Vercel の Hobby cron は1日に1回しか実行されないため、約5日間ある pendingDelete の警告期間の大半を無駄にしかねません。そのため、スケジュールは GitHub Actions で管理します。リポジトリのシークレットに POLL_URL と CRON_SECRET を設定してください。GHA cron はベストエフォート方式で、数分遅れることがありますが、数日間の警告には十分であり、ここでの処理は厳密な時間どおりの実行に依存しません。

テスト

npm test

lib/rdap-status.test.ts と lib/cadence.test.ts は副作用のないテストです。lib/poll.test.ts は偽の空き状況プロバイダーを使って実際のデータベースを操作します。pendingDelete と redemptionPeriod は実環境ではめったに見つからず、まさにこの機能が検出するためのステータスです。DATABASE_URL が設定されていない場合はスキップされます。

はじめに

npm install
npm run dev      # http://localhost:3000

検索は設定不要で動作します。空き状況の確認（RDAP）とルールベースの生成にキーは必要ありません。AI ブレインストーミングを有効にするには、.env.example を .env.local にコピーし、AI Gateway のキーを設定します。

cp .env.example .env.local
# then set AI_GATEWAY_API_KEY=...

ウォッチリストのみデータベースが必要です。検索はデータベースがなくても動作します（getDb() は遅延評価され、ウォッチルートから呼び出されたときにのみエラーになります）。上記のウォッチリストを参照してください。

API

POST /api/search

// request
{ "query": "vegan meal delivery", "tlds": [".com", ".io"], "useAi": true }

// response
{ "query": "...", "results": [ { "domain": "...", "score": 92, "availability": {...}, ... } ],
  "meta": { "generated": 45, "checked": 45, "aiUsed": false, "availabilityProvider": "rdap", "tookMs": 1200 } }

注意事項／制限事項

• TLD の対象範囲。 IANA の RDAP ブートストラップは 1438 ゾーンのうち約 1199 を対象としており、gTLD に偏っています。不足しているのは ccTLD で、まさにドメインハックで使われるものです。確認済みの例外設定は OVERRIDES（lib/availability.ts）にあります：.io／.me／.sh／.ac、.de、.us。.co／.es／.at／.gg については到達可能なエンドポイントが見つからなかったため、推測せず unknown として報告します。見つけた場合は追加してください。
• パーキングの検出は適合率が高く、再現率は低いです。 Sedo／Bodis 形式のネームサーバーにパーキングされている一般的なドメインは確実に検出しますが、プレミアムドメインは見逃します。そのほとんどは Cloudflare／AWS の背後にあり、シグナルを確認できません。parked がないからといって、何も証明されません。実際のアフターマーケットデータを得るには、有料のソースが必要です。
• RDAP で分かるのは 登録済みか未登録か であり、価格ではありません。 価格表示や購入にはレジストラ API が必要です（そのためのインターフェースは用意されています）。現在、「購入」リンクは Namecheap の検索ページを指しています。backorderUrl() はドロップ対象ドメインの DropCatch を指しています。アフィリエイトリンクへの差し替えは、app/page.tsx の 1 行を変更するだけです。
• このアプリをポーリングしても、ドロップを確保することはできません。 プロのドロップキャッチ業者は、何百ものレジストラ接続を確保しています。有用なのは、アラートを送信してバックオーダーサービスに引き継ぐウォッチリストを構築することです。設計については Wiki を参照してください。

ライセンス

Elastic License 2.0（SPDX-License-Identifier: Elastic-2.0）の下でソースを利用できます。コードの確認、セルフホスト、変更は自由に行えます。ただし、できないのは、機能の相当部分を提供するホスト型またはマネージドサービスとして、第三者に提供することです。つまり、競合するホスト型サービスとして運用することは許可されていません。詳細な条件は LICENSE を参照してください。