暗号資産ウォレットでドメイン料金を支払う：アカウント不要

「AIエージェントが代わりにドメインを買える」という話は、どれも最後には同じ壁に突き当たります。エージェントは実際にどう支払うのでしょうか。クレジットカード決済では、人間がフォームに番号を入力し、不正利用の確認を通過し、携帯電話に届くワンタイムコードを確認することが前提です。AIエージェントには、そのどれもありません。Namefiの答えは、カードも保存済みの支払い方法もNamefiアカウントも必要とせず、その場で支払いに署名する暗号資産ウォレットだけを使う決済経路です。この記事では、この流れの仕組み、署名方式によってエージェントに許されることと許されないこと、APIキー決済を選ぶべき場合を詳しく解説します。

AIエージェントによるコマースで決済が最も難しい理由

エージェントに買い物をさせるうえで、検索や価格確認が難題だったことはありません。これらは読み取り専用の呼び出しであり、認可は不要です。エージェントが間違えても失うものはありません。決済は異なります。間違えれば実際のお金を失う唯一の手順であり、現在広く使われている決済システムはどれも、人間が支払いを承認することを前提としているからです。

最も分かりやすい例が、保存済みのカードです。カード情報を保存する決済では、後から再び請求できるトークンを決済処理業者へ渡します。その後は加盟店の判断で、請求時にカード保有者が改めて何かを証明しなくても請求できます。信頼して毎月支払うサブスクリプションなら問題ありません。しかし、自律的に動くプロセスとの相性はよくありません。保存されたカードトークンを持つ者は請求でき、実質的な防御策は、ソフトウェアが悪用しないと信頼するか、後から利用明細で悪用に気付くことだけです。ドメイン登録に限り$50まで支払える保存済みカードをエージェントに渡す方法はありません。カード自体は、何の支払いに使われるのかを知らないからです。

エージェントネイティブなドメインレジストラとは？では、APIがあるだけでなく、決済がエージェントにとって利用可能であるための中核要件の一つだと説明しています。Namefiの暗号資産ウォレット決済は、その要件への具体的な答えです。サービス側がいつでも請求できる保存済みの認証情報を使う代わりに、支払いのたびに、その一取引、その価格だけに対してウォレットが署名します。それ以外には使えません。

Namefiの答え：アカウント作成不要のウォレット署名決済

Namefiで通常ドメインを登録する場合は、NamefiでAIエージェントを使ってドメインを登録する方法で説明しているように、入金済みのNFSC（Namefi Service Credit）残高から請求されるAPIキーを使います。この経路にはアカウントが必要です。誰かがウォレットからキーを生成し、残高へ入金すると、登録のたびにキー経由で残高が差し引かれます。

ウォレット署名経路では、そのすべてを省略します。Namefiが公開しているウォレット決済用の機械可読ドキュメントによると、エージェントのウォレットは、Namefiアカウントを作成せず、APIキーをどこにも保持せずに、USDCで直接支払えます。購入者のウォレットが支払い認可に署名し、その署名が届くと決済が完了して登録が進みます。事前に作成するものも、後から悪用され得る継続的な権限もありません。ウォレットが動作するのは、署名する瞬間だけです。

Namefiは、ウォレットが署名を生成する三つの方法を文書化しています。以下で順に説明するx402プロトコル（主要な経路であり、この記事の中心）、Machine Payable Protocol（MPP）によるチャレンジレスポンス方式、そして、どちらの簡略化された方式も使わないウォレット向けの手動EIP-712署名経路です。

x402の流れを手順ごとに解説

x402は、Cloudflare、AWS、Stripeなどの企業が支援するオープン標準です。長く使われてこなかったHTTPの402 Payment Requiredステータスコードを復活させ、通常のリクエストの中でオンチェーン支払いを構造化して要求できるようにします。別の決済ページへリダイレクトする必要はありません。Namefiは、ドメイン登録エンドポイントにx402を実装しています。

1. 支払いなしでリクエストする。 エージェントは通常のGETリクエストをNamefiの/x402/domain/{domainName}エンドポイントへ送信します。この時点では価格が分からないため、支払いは添付しません。
2. 価格を含むHTTP 402を受け取る。 Namefiは402 Payment Requiredを返し、レスポンス本文にネットワーク、受け付ける資産（USDC）、金額という支払いオプションを含めます。ここが、x402と通常のエラーの違いです。402ステータスは単に「支払いが必要」と返すのではなく、有効な支払いを組み立てるためにクライアントが必要とする情報をすべて含んでいます。
3. ウォレットがEIP-3009のtransferWithAuthorizationに署名する。 別のブロックチェーントランザクションを送信して確定を待つ代わりに、ウォレットは署名によるトークン送金の認可に特化したEthereum標準、EIP-3009に基づく署名を生成します。EIP-3009のtransferWithAuthorization関数を使うと、トークン保有者は、特定の金額を特定の受取人へ送金することを、特定の時間枠（validAfter / validBefore）内だけ有効なメッセージとして署名できます。その後、第三者がそのメッセージをオンチェーンで提出できます。Namefiのドキュメントには、この手順にNamefiアカウントも事前のEIP-712署名も不要だと明記されています。ウォレットは独立したUSDC送金認可に署名し、それで完了です。
4. 支払いヘッダーを付けてリクエストを再送する。 エージェントは元のリクエストを再送します。今度は、署名済みの認可を格納したX-PAYMENTヘッダーを付けます。
5. 検証、決済、登録を行う。 Namefiは署名を検証し、ドメイン登録の処理を開始して支払いを決済します。USDCは購入者のウォレットから移動し、登録はAPIキー経路と同じように進みます。ドメインはNFT、つまりトークン化ドメインとして、デフォルトでは支払いに使った同じウォレットへ発行されます。

この一連の手順では、エージェントがNamefiアカウントを作成する必要も、Namefiが再承認なしで再利用できる認証情報を保存する必要も、実際に支払う時点より前に資金の管理権を手放す必要もありません。署名が証明するのは、この特定額のUSDC送金を、限られた時間枠内でウォレットが承認したことだけです。

MPPのチャレンジレスポンス方式

x402が主要な経路ですが、Namefiは、別の決済パターンに対応するウォレットやエージェントフレームワーク向けに二つ目の方法も文書化しています。Machine Payable Protocol（MPP）です。構造上はx402を反転させたような形で、単純な402ではなくチャレンジレスポンスを使います。

1. 保護されたエンドポイントへの最初のリクエストでは、再び402 Payment Requiredが返ります。ただし今回は、単純な価格情報ではなく、署名済みチャレンジが含まれます。
2. クライアントは支払いに使うウォレットで、そのチャレンジに署名します。通常は、この署名手順を処理するために専用に作られたNamefiのmppxコマンドラインツールを使います。
3. クライアントは、生成された署名をAuthorizationヘッダーに添付して、元のリクエストを再送します。

最終的な効果はx402と同じです。保存済みの認証情報を使わず、リクエストごとにウォレットで署名して支払います。ただし、MPPでは単純な「402レスポンス内の価格」ではなく、署名済みチャレンジによるハンドシェイクとして構成されます。エージェントがどちらを使うかは、既存の決済ツールがどちらに対応しているかで決まります。Namefiのエンドポイントは両方に対応しています。

手動EIP-712経路

どちらの簡略化された方式も使わないウォレットやスクリプト向けに、NamefiはEIP-712型付きデータ署名を基盤とした、より低レベルで完全に手動の署名経路を提供しています。EIP-712はEIP-3009自体の基盤でもある標準です。この方法で署名したリクエストには、x-namefi-signer（署名するウォレットのアドレス）、x-namefi-signature（16進数でエンコードされた署名）、x-namefi-eip712-type（署名の生成に使用した型付きデータのスキーマ）という三つのヘッダーが含まれます。ペイロードは、payloadType、payload本体、timestamp、nonceを持つエンベロープで包みます。

この手動経路では、安全性に関わる重要な点が二つあります。署名は300秒後に失効し、nonceは一度しか使えません。 300秒が経過した後、またはそのnonceを使ったリクエストが受理された後は、取得された署名を再送しても成功しません。Namefiのドキュメントでは、署名対象となる正確なスキーマは変更される可能性があるため、稼働中のEIP-712型定義を連携側にハードコードせず、リクエスト時に/v-next/eip712/エンドポイントから取得することも定めています。

Namefiは、この方法によるスマートコントラクトウォレットの署名も文書化しています。コントラクトがAPIから検証できるapprovedSigners(address)チェックを実装していれば、承認済みの外部所有アカウント（EOA）がERC-1271または新しいEIP-7702に基づき、コントラクトウォレットに代わって署名できます。

セキュリティモデル：エージェントにできること、できないこと

この署名方式が実際に何を制限するのかは、仕組みが提供する以上に強い保証があるかのように説明せず、正確に捉える必要があります。

制限できること。 どの経路でも、Namefiに継続的な認証情報を渡すのではなく、現在のリクエストに対する署名をウォレットに求めます。ただし、リプレイ防止の仕組みはプロトコルごとに異なります。手動EIP-712経路では署名が300秒後に失効し、一度限りのnonceが消費されます。x402では、EIP-3009認可が特定の金額と受取人に結び付けられ、validAfter / validBeforeで有効期間が制限され、nonceでも保護されます。MPPではクライアントがサーバー発行のチャレンジに署名するため、有効期限とリプレイ防止条件はそのチャレンジの指定に従います。ウォレットがNamefiに対し、将来の請求を独自に開始できる継続的な権限を渡すことはありません。保存済みカードと比較すると違いが分かります。加盟店がカードトークンを得た後は、トークン自体に翌月の請求額や、侵害されたシステムによる再利用を制限する仕組みはありません。いずれの方式でも、ウォレットの秘密鍵が外へ出ることはありません。エージェントは現在のリクエストに対する署名をウォレットへ依頼し、それ以上の権限を渡しません。

それ自体では制限できないこと。 Namefiのドキュメントには、プロトコル自体が強制する、組み込みの1取引あたりのドル建て支出上限は記載されていません。プロトコルごとに異なる失効条件とリプレイ防止条件は、認可をいつ、どのように再利用できるかを制限しますが、1回の署名済みリクエストで認可できる金額には上限を設けません。 実際にエージェントの支出を管理する仕組みは、この方式の外側にあります。ウォレットへ入れるUSDCの金額と、エージェントとウォレットの秘密鍵の間に置くポリシー層です。たとえば、追加の承認を必要とするマルチシグウォレットや、エージェントが署名する前に人間の確認を求める手順です。エージェントネイティブなドメインレジストラとは？とNamefiでAIエージェントを使ってドメインを登録する方法でも、保護策の観点から同じ点を説明しています。無人で動くプロセスに使われても構わない金額だけをウォレットへ入れ、どの段階で人間の承認を必要とするかを事前に決めてください。

継続的に有効な認証情報がないこと、取引ごとの認可が限定されていること、入金額が実質的な支出上限になること。この組み合わせにより、保存済みカードと同じ仕組みを暗号資産風にしただけではなく、リスクの形そのものが異なります。漏えいしたカード番号や侵害された決済トークンは、誰かが気付いて解約するまで何度でも請求に使われる可能性があります。取得された支払い認可は、各プロトコル固有の失効条件またはリプレイ防止条件を満たすと拒否されます。手動EIP-712経路では300秒後またはnonceの消費後に拒否され、x402のEIP-3009認可ではvalidAfter / validBeforeの時間枠外またはnonceの使用後に拒否されます。MPPの認証情報は、署名済みチャレンジに含まれる有効期限とリプレイ防止条件に従います。

代わりにAPIキー決済またはNFSC決済を使う場合

ウォレット署名経路は、購入前にアカウントが存在しないこと自体が重要な場合に適しています。完全に自律的なスクリプト、ログイン情報を共有せず他者の代理で動くエージェント、または暗号資産ネイティブなウォレットだけをIDとして使いたい場合です。ただし、すべての状況で自動的に最適な手段になるわけではありません。

NamefiでAIエージェントを使ってドメインを登録する方法で詳しく説明している、入金済みNFSC残高に対するAPIキー決済は、次のような場合に適しています。エージェントがドメインを繰り返し登録し、毎回新しい支払いに署名するよりも、いつでも確認できる残高の方が便利な場合。オンチェーン送金から支出を再構成するより、単一のダッシュボードで支出を確認したい場合。または、クライアントがヘッダー値を安全に保存できる一方で、秘密鍵を保持して署名する簡単な方法がない場合です。支払いが決済された後は、どちらの経路でも同じ登録とDNS操作を利用できます。選択の違いは認可の仕組みにあり、その後に登録または管理できる内容ではありません。

よくある質問

暗号資産ウォレットで支払うにはNamefiアカウントが必要ですか？

いいえ。x402とMPPのどちらも、事前にNamefiアカウントやAPIキーを作成せず、ウォレットで署名した支払いによってドメイン登録を決済できます。APIキーが必要なのは、NFSC残高を使う決済経路だけです。

Namefiのウォレット決済では、どの暗号資産を利用できますか？

USDCです。Namefiのx402エンドポイントは、価格提示と決済の両方をUSDCで行います。そのため、価格が提示されてから決済されるまでの間に、ETHのような価格変動の大きい資産がもたらす価格変動リスクを避けられます。

ウォレットで支払いに署名することは、エージェントへ秘密鍵を渡すことと同じですか？

いいえ。署名は秘密鍵自体を一切公開せずにウォレット内で生成されます。エージェントまたはエージェントが呼び出すツールは、具体的で範囲が限定された認可への署名をウォレットに依頼します。鍵は最初から最後までウォレット内にとどまります。

以前に生成した支払い署名を、誰かが再利用できますか？

取得された署名は、それぞれの失効条件またはリプレイ防止条件により拒否されるまでは使用できる可能性があります。三つの経路に共通する一律のルールはありません。手動EIP-712経路では、署名は300秒後に失効し、nonceは一度しか使えません。x402のEIP-3009認可はvalidAfter / validBeforeの時間枠内だけ有効で、nonceも二度は使えません。MPPでは署名済みチャレンジを使うため、有効期限とリプレイ防止条件は、そのチャレンジで確認する必要があります。

この方法で支払うと、ドメインは自動的にトークン化されますか？

はい。デフォルトでは、別の受取ウォレットを指定しない限り、登録されたドメインは、支払いに使った同じウォレットへNFTとして発行されます。APIキー経路と同じトークン化の動作です。ウォレットネイティブな決済やトークン化された所有権をまったく提供しないレジストラとの違いは、Cloudflare vs Name.com vs Namefi：エージェントネイティブレジストラをご覧ください。

ウォレット決済は、保存済みのカードで支払うより安全ですか？

リスクをすべてなくすのではなく、異なる種類のリスクを制限します。侵害されたシステムが無期限に再利用できる継続的な認証情報はなく、支払いごとに新しいリクエスト単位の署名が必要です。リプレイ防止の仕組みは経路ごとに異なります。手動EIP-712では300秒の有効期限と一度限りのnonce、x402のEIP-3009認可ではvalidAfter / validBeforeとnonce、MPPでは署名済みチャレンジに記載された条件が使われます。いずれの仕組みも、1回の署名済みリクエストで認可できる金額には上限を設けません。そのため、エージェントが実際に使える金額の上限は、ウォレットへ入れる金額と、マルチシグなどの追加承認ポリシーによって決まります。

Namefiでウォレットを使ってドメインを購入する

エージェントと購入の間に人間のアカウントを置かないことが目的なら、Namefiのウォレット署名決済は、まさにそのために作られています。ICANN認定レジストラによる正式なドメイン登録の料金を1回の署名済みUSDC認可で支払い、トークン化された所有権は支払いに使った同じウォレットへ渡ります。詳しい仕組みはnamefi.io/web3/llms.txtを、より広い設定手順はNamefiでAIエージェントを使ってドメインを登録する方法をご覧ください。

Namefiでドメインを検索して登録する。

出典と参考資料

• Namefi — namefi.io/web3/llms.txt（x402の流れ、MPPのチャレンジレスポンス方式、手動EIP-712署名経路、署名の失効とnonceのルール、ERC-1271/EIP-7702によるスマートコントラクトウォレット署名の一次資料）
• Namefi — namefi.io/llms.txt（NFSC/APIキー決済経路、および上記ウォレット決済資料への案内）
• x402.org — x402：インターネットネイティブな決済標準（Namefiが実装する、HTTP 402を基盤としたオープンな決済プロトコル）
• Ethereum — EIP-3009：Transfer With Authorization（transferWithAuthorization手順の基盤となる署名標準、validAfter / validBeforeによる時間制限、一度限りのランダムnonce）
• Ethereum — EIP-721：非代替性トークン標準（トークン化されたドメイン所有権の基盤となるNFT標準）
• Namefi — NamefiでAIエージェントを使ってドメインを登録する方法（APIキー/NFSC決済経路と、より広い保護策の案内）
• Namefi — Cloudflare vs Name.com vs Namefi：エージェントネイティブレジストラ（エージェント向けの三つのレジストラにおける、ウォレットネイティブ決済の比較）