Namefi

Namefi MCPクイックスタート:Claude Code、Cursor、Windsurf

Claude Code、Cursor、Windsurfのエディター別MCP設定と、新しいアプリから公開中のカスタムドメインまでをエディター内で完結する5段階のクイックスタートです。

Fenwei BianFenwei Bian著者Victor ZhouVictor Zhou編集者Chie KudōChie Kudō翻訳者2026年7月10日約 17 分で読了
  • ai-agents
  • guide
Xでシェア

すでにエディターを開いています。アプリのひな型を作り、最初のデプロイをプラットフォームのサブドメインへ公開しました。利用者に案内する前に残っているのは、本物のドメインだけです。このクイックスタートでは、ブラウザーのタブを開かず、決済フォームに入力せず、アプリを構築したコーディングエージェントのセッションを離れずに登録する方法を説明します。Claude Code、Cursor、Windsurfの正確なMCP接続設定、要点を絞った五段階の手順、そして多くのドメインガイドが省略する部分、つまり登録したばかりのドメインを、公開したばかりのデプロイ先に実際に接続する方法まで扱います。

このガイドが三つのエディターを扱うのには理由があります。OpenAI Codex、Gemini CLI、Claude Desktopを使っている場合は、NamefiでAIエージェントを使ってドメインを登録する方法が、六つのクライアントで検証済みの設定と、MCPを標準対応しない環境向けの直接的なREST手順をまとめた基本ガイドです。ここで紹介する設定はすべて、そのガイドに記載された同じNamefi MCPサーバーへ接続するため、内容に矛盾はありません。このページは開発者ツールを起点に要点をまとめ、基本ガイドにはないデプロイ接続の手順を加えたものです。

エディター内でドメインを登録する理由

「ドメインを登録しに行く」という作業は、五分で終わる内容に対して、非常に大きなコンテキスト切り替えを伴います。エディターを離れてレジストラのサイトを開き、名前を検索し、頼んでもいないプライバシー保護やメールホスティングの追加販売をやり過ごし、支払い、戻ってから追加すべきDNSレコードを調べる必要があります。

代わりに、プロジェクトのひな型を作り、デプロイまで設定した同じエージェントに最後の工程も任せられます。今の会話の中で、名前の確認、登録、DNS接続をすべてツール呼び出しとして処理する方法です。Cloudflareも自社のRegistrar APIで同じ考え方を取り入れた機能を売り出しています。これは一部だけが好む特殊な方法ではなく、複数のレジストラが目指しているワークフローだという証拠です。終盤の比較セクションでは、Cloudflareとの違いを具体的に説明します。Namefiの方式にはトークン化ドメインの選択肢と、アカウントを必要としないウォレット署名決済が加わります。詳細は暗号資産ウォレットでドメイン料金を支払うで説明します。

接続設定:三つのエディター、三つの設定ファイル

以下の三つのエディターはすべて、Streamable HTTPを通じて同じエンドポイントhttps://api.namefi.io/mcpへ接続し、NamefiのAPIキーx-api-keyヘッダーとして送信します。エディターごとに異なるのは、ファイル形式とファイルを書き込むコマンドだけです。

Claude Code

Claude Codeの公式ドキュメントには、カスタムヘッダーを使うリモートHTTPサーバーを追加する直接的なCLIコマンドが示されています。

claude mcp add --transport http namefi https://api.namefi.io/mcp --header "x-api-key: YOUR_KEY"

実際のキーに置き換え、プロジェクトのターミナルから一度だけ実行します。デフォルトではサーバーがlocalスコープに記録され、自分がこのプロジェクト内だけで利用できます。代わりに--scope userを加えると、このマシン上のすべてのプロジェクトで利用できます。claude mcp listで接続を確認してください。

Cursor

Cursorはmcp.jsonからMCPサーバーを読み取ります。プロジェクト用は.cursor/mcp.json、グローバル用は~/.cursor/mcp.jsonです。公式ドキュメントのリモートサーバー形式は、環境変数の展開を使ったヘッダー認証に対応しているため、キー自体をファイルに保存する必要はありません。

{
  "mcpServers": {
    "namefi": {
      "url": "https://api.namefi.io/mcp",
      "headers": {
        "x-api-key": "${env:NAMEFI_API_KEY}"
      }
    }
  }
}

${env:NAMEFI_API_KEY}は、Cursorを起動したシェルでこの変数に入っている値に展開されます。エディターを開く前にexportしてください。

Windsurf(Cascade)

Cascadeという名称のWindsurfのMCP統合機能は、~/.codeium/windsurf/mcp_config.jsonを読み込みます。ここではリモートサーバーにserverUrlフィールドを使い、urlは使いません。headers${env:VAR}のパターンはCursorと同じです。

{
  "mcpServers": {
    "namefi": {
      "serverUrl": "https://api.namefi.io/mcp",
      "headers": {
        "x-api-key": "${env:NAMEFI_API_KEY}"
      }
    }
  }
}

注意すべき点が一つあります。このガイドの公開日時点で、docs.windsurf.com/windsurf/cascade/mcpdocs.devin.ai/desktop/cascade/mcpへリダイレクトされます。Windsurfのドキュメントは現在、CognitionのDevin製品ドキュメントのドメインにあり、上の設定形式はその現行ページに記載されたものです。古いビルドを利用している場合は、そのバージョンのアプリ内ヘルプが示すドキュメントでフィールド名を確認してください。

五段階のクイックスタート:新しいアプリから公開DNSまで

上記いずれかの接続が有効になれば、利用するエディターに関係なく、その後の流れは同じです。

  1. 新しいドメインを所有するウォレットで生成したAPIキーをnamefi.io/api-keyから取得します。
  2. 上記のエディター別設定を使って接続し、正常に動くか確認します。「Namefiで<yourapp>.comが利用できるか確認し、どのツールを呼び出したか教えて」と依頼してください。これは読み取り専用のcheckAvailability呼び出しなので、資金を用意する前でも動作します。
  3. 登録します。 名前と期間を自然な言葉で確認します。たとえば「一年間登録して」と依頼します。エージェントはregisterDomainを送信し、注文がSUCCEEDEDまたは最終的な失敗状態に達するまでポーリングします。通常の登録は数回のポーリングで完了します。
  4. デプロイ先へ接続します。 次のセクションで詳しく扱う手順です。同じ会話から、ホスティングプラットフォームが求めるDNSレコードを追加します。
  5. 名前解決を確認します。 DNS伝播は瞬時には完了しません。数分待ってから、公開DNSの照会を使うか、ブラウザーでドメインを直接開いて確認します。

新しいドメインをデプロイ先へ接続する

一般的な「ドメインを登録する方法」のガイドがここまで扱うことはありません。登録後にホスティングプラットフォーム側で行う作業だからです。しかし、これこそエディター内で処理する意味です。エージェントはどのプラットフォームへデプロイしたかをすでに把握しているため、登録に続けてDNSも設定できます。

Vercel

Vercelの公式ドメインドキュメントでは、プロジェクトダッシュボードのSettings → Domainsから始まる手順を説明しています。ドメインを追加すると、apexドメインかサブドメインかに応じて、作成すべきレコードが表示されます。apexドメインyourapp.com)には配信IPを指すAレコードサブドメインwww.yourapp.com)にはCNAMEが必要です。古いガイドの例をコピーする前に知っておくべき点として、Vercelのドキュメントは、このCNAMEの接続先がプロジェクトごとに固有であると明記しています。すべてのプロジェクトが共有する固定ホスト名ではなく、ダッシュボードに表示された値を使います。

値を確認したら、DNS側の作業はエージェントへの追加の依頼一つで完了します。

@76.76.21.21を指すAレコードと、wwwがVercelから提示されたCNAMEの接続先を指すCNAMEを追加して」

これによりcreateDnsRecordがレコードごとに一度、合計二回呼び出されます。Namefi上のあらゆるDNS書き込みに使用するものと同じDNSレコードツールです。末尾のドットに関する規則も同じで、CNAMEの接続先を表すrdataには末尾のドットが必要ですが、ドメインを表すzoneNameには不要です。

Cloudflare Pages

デプロイ先がCloudflare Pagesで、ドメインのDNSがまだCloudflareで管理されていない場合、Cloudflareのカスタムドメインに関する公式ドキュメントでは、プロジェクトの.pages.devサブドメインを指すCNAMEレコード一つを求めています。PagesはすべてをそのCNAMEの接続先から配信するため、Aレコードは不要です。まずCloudflareダッシュボードの手順(Workers & Pages → 対象プロジェクト → Custom domains → Set up a domain)を済ませる必要があります。その後でのみ、CNAMEの接続先が正しく解決されます。

appmy-project.pages.dev.を指すCNAMEを追加して」

同じツール呼び出しと、接続先に関する同じ末尾ドット規則を使います。異なるのはプラットフォームだけです。

Cloudflareのエディター内登録との比較

Cloudflareはエディター内での登録を積極的に売り出しているもう一つのレジストラであり、直接比較する価値があります。2026年4月時点でベータ版と報じられたRegistrar APIは、CursorやClaude Codeを含むMCP対応エディターとも連携します。エージェントは現在のコンテキストを離れず、ドメインの検索、価格確認、同期的な登録を行えます。このガイドでNamefiを使って説明したものと同じ中心的な考え方です。同じ報道によると、ベータ時点のCloudflare APIは、移管や更新など登録後の管理にはまだ対応しておらず、2026年後半に提供する予定です。

NamefiのMCPサーバーは現在、登録、DNS、自動更新までのライフサイクル全体をカバーしています。さらにCloudflareの方式にはない二つの機能があります。ドメインはデフォルトでトークン化ドメインNFTとして登録され、受取先に任意のウォレットを指定できます。また、Namefiアカウントなしでウォレット署名による決済を利用できます。詳しくは暗号資産ウォレットでドメイン料金を支払うで説明します。どちらも「エディターを離れない」ワークフローを目指しています。標準的な登録を求めるか、オンチェーン資産でもある登録を求めるかによって、適した方式が変わります。

よくある質問

CodexやGemini CLIも対象ですか?

このガイドでは扱いません。意図的にClaude Code、Cursor、Windsurfに限定しています。NamefiでAIエージェントを使ってドメインを登録する方法には、Codex CLI、Gemini CLI、Claude Desktop向けに、同じく正確に検証済みの設定があります。

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

いいえ。読み取り専用の利用可能性確認には認証が不要なので、APIキーを生成したり資金を用意したりする前に、上記のどのエディターでも接続して手順2のテストプロンプトを実行できます。

デプロイ先がVercelやCloudflare Pagesではない場合は?

どの環境でも基本は同じです。プラットフォームのダッシュボードに必要なDNSレコードタイプが表示されます。ほとんどの場合、apexドメインにはAレコード、サブドメインにはCNAMEです。その値をエージェントに渡し、createDnsRecordで書き込ませます。

この方法で登録すると、ドメインは自動的にトークン化されますか?

はい。リクエストで別のnftReceivingWalletを指定しない限り、デフォルトではAPIキーに紐づくウォレットに対して、Base上のNFTとしてドメインが登録されます。初めて知った場合は、トークン化ドメインとは?をご覧ください。

APIキーを完全に省略できますか?

はい。ただし条件があります。Namefiのウォレット署名によるx402決済では、資金のあるウォレットが、アカウントもAPIキーも使わずに登録料金を支払えます。別途説明が必要な仕組みなので、暗号資産ウォレットでドメイン料金を支払うで詳しく扱います。

アプリと一緒にドメインも公開する

ドメインは、デプロイ先やデータベースと同じインフラです。アプリを公開する要素のうち、ドメインだけがツールを離れてウェブフォームに入力しなければならない理由はありません。上の三つの設定から一つを接続して五段階の手順を実行すれば、ブラウザーのタブを一つも開かずに、エージェントが構築したデプロイ先を指すドメインが公開されます。

Namefi APIキーを生成し、すでに開いているエディターで利用可能性確認のプロンプトを試してください。全手順を詳しく確認したい場合は、注釈付きの対話記録を含むClaude Code完全ガイドをご覧ください。

出典と参考資料

執筆・編集メンバー

Fenwei Bian
ソフトウェア開発者・ライター • Namefi

Fenwei Bianは30代のソフトウェア開発者です。仕事中はプルリクエストに向き合い、 週末は土やおがくずに手をまみれさせています。GitHubで長年オープンソースに携わる 中で、名前はインターフェースだと学びました。良い名前は明快で、何をするものかを 正直に伝え、次にそれを使う人への思いやりがあります。

園芸をするのは、忍耐には応えてくれる一方、都合のよい思い込みは通用しないからです。 木工をするのは、継ぎ手が合うか合わないかはごまかせないからです。どちらの習慣も、 彼女のネーミングに関する文章に表れています。二度測り、出典を確認し、粗い箇所を 上辺だけ磨いて誰にも気づかれないことを願ったりはしません。

Namefiでは、ドメイン市場が実際にどう動くのか、名前をトークン化して転売する際の 現実的なトレードオフ、そして20年後も所有していてよかったと思えるドメインの選び方に ついて執筆しています。

Victor Zhou
Victor Zhou編集者
創業者・標準仕様エディター • Namefi

Victor Zhouは、デジタルアイデンティティと信頼を専門とするテクノロジー企業の創業者で、 標準仕様のエディターでもあります。Namefiを創業し、Ethereum Improvement Proposalsの 編集に携わっています。以前はGoogle Labsでスマートコントラクトのアーキテクチャ設計を 率いていました。

彼の仕事は、ネーミング、所有権、そして人々がオンラインで自らのアイデンティティを 確立するために使うシステムが交わる場所にあります。だからこそ、名前が個人的な意味、 社会的な認知、デジタルインフラの間をどのように行き来するのかに強い関心を持っています。

Namefiでは、永続的なデジタルアイデンティティとしてのドメインについて編集・執筆して います。名前が所有可能なオンチェーン資産になる仕組み、トークン化が保管と信頼をどう 変えるのか、そして人々がオンラインでアイデンティティを確立するために使うシステムから ネーミングが何を学べるのかを扱っています。

Chie Kudō
Chie Kudō翻訳者
日本語ローカライゼーション翻訳者 • Namefi

Chie Kudō(工藤 知恵)は、福岡を拠点とする30代の翻訳者です。電機メーカーで ハードウェアQAエンジニアとして製品資料の作成と確認に携わった後、英語と日本語の 間で技術記事や編集記事をローカライズする仕事に転じました。

品質保証で身につけた習慣は、今の仕事にも生きています。用語の一貫性はもちろん、 ブランド名を漢字、かな、ローマ字のどれで表すか、半角と全角をどう使い分けるか、 借用元の英語とは異なる意味を持つ和製英語をどう扱うかといった、日本語組版ならではの 細部を厳しく確認します。小さなベランダ菜園を楽しみ、週末にはボルダリングをします。

Namefiでは、ドメインとネーミングに関する記事を日本語にローカライズしています。 名前がページ上でどう読めるか、そして最初から正しく入力してもらえるかに目を配っています。

関連ガイド

この記事について議論する

Namefi Discussで議論を見る