バイブコーディングにもドメインが必要：フローを中断せずに登録する

プロンプトを入力するとファイルツリーが次々に埋まり、30秒後にはチャットに公開URLが表示されました。これこそがバイブコーディングの魅力です。「アイデアがある」状態から「インターネット上で実際に動くものがある」状態までの隔たりが、コーヒーを1杯飲むほどの時間に縮まりました。ただし、目の前のURLはmy-app-a3f9.vercel.appやmy-app.lovable.appのような文字列で終わっています。名刺に載せたい名前ではなく、プラットフォームのサブドメインです。そこから自分が本当に所有するドメインへ移る段階で、作業の流れはたいてい途切れます。しかし、途切れさせる必要はありません。

「バイブコーディング」とは何か

まだこの言葉になじみがなければ、Wikipediaではバイブコーディングを「ソフトウェア開発者がプロジェクトやタスクをプロンプトで大規模言語モデル（LLM）に説明し、モデルがソースコードを自動生成する、人工知能（AI）の支援を受けたソフトウェア開発手法」と定義しています。特徴は単にAIがコードを書くことではありません。以前からオートコンプリートでコードを書くツールは数多くありました。バイブコーディングでは、モデルが返したコードを受け入れ、すべての行を読む代わりに、次の変更を自然言語で伝えながら反復することがよくあります。Teslaの元AI部門責任者でOpenAI共同創業者のAndrej Karpathyが2025年2月にこの言葉を生み出しました。急速に広まり、1か月もしないうちにMerriam-Websterが流行中のスラングとして取り上げ、その後Collins English Dictionaryが今年の言葉の一つに選びました。

これは、その手法を批判する話ではありません。欲しいものを説明するだけで動くアプリが返ってくるのは、まったく新しい開発方法です。Cursor、Lovable、Replit、bolt.new、v0、Claude Codeといった周辺ツールも進歩し、動くプロトタイプを作ることは、もはや難所ではなくなりました。難しいのは、少なくともまだ2015年のように見えるのは、「動いた」後の作業です。アプリに名前を付け、本物のアドレスを与える部分です。

最後の一歩：プラットフォームのサブドメインから独自ドメインへ

これらのプラットフォームはどれも、同じ問題を同じ方法で解決します。まず公開し、プラットフォーム自身のドメインのサブドメインへデプロイし、カスタムドメインは後から設定画面で追加できる任意の手順にします。これは適切な初期設定です。アイデアが本当に動くか確認する前にドメインを所有している必要はありません。しかし、プラットフォームのサブドメインは経由地であって、目的地ではありません。口頭では伝えにくく、覚えにくいうえ、アドレスバーを見た人に「まだ他社ツールの無料プランを使っている」と知らせることになります。

本物のドメインを登録する作業そのものは小さなものです。名前を検索し、購入し、DNSレコードをいくつか設定するだけです。しかし従来は、バイブコーディングの一連の作業の中で、この手順だけがまったく別の場所で行われていました。

エディターを離れるとフローが途切れる理由

実際の摩擦は、ドメイン登録が難しいことではありません。作業場所が別にあることです。従来の方法でドメインを登録するには、コーディングエージェントとの会話を止め、ブラウザーのタブを開き、レジストラのトップページへ移動して名前を検索します。その後、不要なプライバシー保護、メールホスティング、ウェブサイトビルダーという三つの追加オプションを勧められ、どのチェックボックスを外せばよいか確認してから支払います。さらに、一般的なドメイン解説では省かれがちな作業が続きます。利用中のホスティングプラットフォームが求めるDNSレコードを特定し、別のダッシュボードでその値を探し、三つ目のタブへ貼り付ける作業です。

これは一つのタスクではありません。互いに、あなたが何を作ったのか、どのプラットフォームへデプロイしたのかを知らない三つの製品にまたがる、五つのタスクです。コンテキストを切り替えるたびに実際のコストが生じます。作業の流れを見失い、別のタブで何かに気を取られ、1時間後に戻ってくる可能性もゼロではありません。5分で済む作業にしては、大きな負担です。

チャットを離れずに登録する

解決策は、ドメインをデプロイと同じように扱うことです。別の用事ではなく、同じ会話内のもう一つのツール呼び出しにします。アプリのひな型を作り、デプロイしたエージェントは、アプリ名と稼働中のプラットフォームをすでに把握しています。そのため、名前の確認、登録、DNSの接続も同じエージェントに任せるのが合理的です。

要点だけに絞ると、流れは三つの手順です。

1. エージェントに名前を確認してもらう。 「myapp.comは空いていますか？」という問い合わせは読み取り専用なので、書き込み権限を伴う接続を設定する前でも利用できます。
2. 確認して登録する。 「1年間登録して」と指示すると注文が送信され、エージェントは完了するまで状況を確認します。
3. デプロイ先へ向ける。 ホスティングプラットフォームが指定するレコード（ルートドメインならAレコード、サブドメインならCNAME）をエージェントに渡すと、レコードを書き込みます。DNSを完全にホストへ任せる場合は、代わりにドメインの委任先となるネームサーバー（NSレコード）自体を変更します。

基本的な流れは以上です。各エディターが読み込む設定ファイルや、VercelとCloudflare Pagesが求める具体的なDNS値など、正確な手順はNamefi MCPクイックスタート：Claude Code、Cursor、Windsurfですでに段階ごとに説明しているため、ここでは繰り返しません。この三つ以外の環境、たとえばOpenAI Codex、Gemini CLI、Claude Desktop、その他MCP対応ツールでコーディングしている場合は、NamefiでAIエージェントを使ってドメインを登録する方法に、それぞれ検証済みの設定と、MCPに対応していないツール向けの直接REST経路がまとまっています。

名前のアイデア出しもエージェントに任せる

名前を考える手順も、購入と同じくらい作業の流れを途切れさせるため、個別に触れておく価値があります。従来の流れでは、名前を考え、レジストラのタブへ移り、取得済みだと分かれば別の名前を考え、元のタブへ戻ります。候補が見つかるか、諦めて末尾に数字を足すまで、この作業を繰り返します。

NamefiのAPIには一括空き状況チェックがあります。各エージェントが参照する同じnamefi.io/llms.txtでは、「多数の名前を一度に絞り込む」方法として説明されています。候補を一つずつ試す代わりに、候補一覧をエージェントへ渡し、一度の往復で実際に空いているものを確認できます。実際には、名前探しが一つのプロンプトで済みます。「このアプリはStreakyという習慣トラッカーです。streaky.com、streaky.app、getstreaky.com、streaky.ioを確認して、空いているものを教えて」と指示します。エージェントが一括チェックを実行して結果を返すため、すでに登録済みの名前を気に入ってしまうことなく、本当に取得できる候補から選べます。

実例：プロンプトから公開URLまで

午後の時間を使って、小さなツールをバイブコーディングしたとします。既存のアプリが使いにくかったため、自分で作った共有買い物リストです。プラットフォームのサブドメインですでに動いており、友人が数人、リンクを欲しがっています。同じチャット画面で、その後のセッション全体は次のように進みます。

cartly.appが空いているか尋ねます。空いています。「1年間登録して、さっきデプロイしたものへ接続して」と伝えます。エージェントは登録を送信し、完了するまで確認します。次に、購入したドメインに必要なDNSレコードをホスティングプラットフォームのダッシュボードで一度だけ確認します。この例ではwwwサブドメインではなくルートドメインを使うため、Aレコードです。その値を会話へ貼り付けると、エージェントがレコードを書き込みます。数分後、DNSの伝播に少し時間はかかりますが、cartly.appは友人が別のタブですでに開いているアプリとまったく同じものを表示します。エディターから離れた時間はゼロ。アプリ開発ですでに使っていたもの以外に開いたタブもゼロです。

よくある質問

この作業にはDNSの知識が必要ですか？

データベースのインデックスを使うのに、その仕組みを理解する必要がないのと同じです。エージェントがホスティングプラットフォームへ必要なレコードを確認して書き込みます。手作業で値を組み立てるのではなく、主に値を確認するだけです。

どのバイブコーディングプラットフォームでも使えますか？それとも特定のものだけですか？

登録とDNSの部分はプラットフォームに依存しません。ドメインとDNSレコードは、どのツールでアプリを作ったかに関係なく同じように機能します。異なるのはホスティングプラットフォームが指定するレコードタイプであり、VercelとCloudflare PagesについてはNamefi MCPクイックスタートで具体的に説明しています。

この方法で登録したドメインはトークン化されますか？

はい。標準でトークン化されます。NamefiはICANN認定レジストラであり、通常のドメイン登録と同時に、そのドメインをBase上のNFTとして、APIキーに紐づくウォレットへ登録します。通常どおり動作するドメインとオンチェーンの所有権記録の両方を得られ、どちらか一方を選ぶものではありません。

欲しい名前がすでに登録されていたらどうなりますか？

そのために、前述の一括空き状況チェックがあります。候補を一つずつ試すのではなく、複数の候補（TLD（トップレベルドメイン）違い、接頭辞、類義語）をエージェントへ渡し、実際に空いているものを報告してもらいます。

試す前にNamefiアカウントが必要ですか？

いいえ。空き状況チェックは読み取り専用で認証も不要です。APIキーを生成したり入金したりする前に、接続を設定して名前を試せます。

今のフローのまま、ドメイン名も公開する

ドメインは別のプロジェクトではありません。ホスティングプラットフォームを選ぶのと同じ種類のインフラ上の判断です。アプリを公開する作業の中で、ドメインだけが今もブラウザーのタブと決済フォームを必要とする理由はありません。次にエージェントが、プラットフォームのサブドメインで動くアプリを返してきたら、その会話にとどまり、名前を確認するよう頼んでみてください。

**Namefi APIキーを生成**して今作っているものですぐに試すか、Namefi MCPクイックスタート：Claude Code、Cursor、Windsurfの詳しい手順から始めてください。

出典と参考資料

• Wikipedia — バイブコーディング（定義、Andrej Karpathyによる2025年2月の命名、普及の経緯）
• Namefi — namefi.io/llms.txt（一括空き状況チェック用エンドポイント、MCPサーバーURL、登録とDNSのリファレンス）
• Namefi — Namefi MCPクイックスタート：Claude Code、Cursor、Windsurf（エディター別の設定、全5ステップ、VercelとCloudflare PagesのDNS設定）
• Namefi — NamefiでAIエージェントを使ってドメインを登録する方法（Codex、Gemini CLI、Claude Desktopの設定と直接REST経路）
• Model Context Protocol — modelcontextprotocol.io（プロトコル概要）