Nullstead

Cloudflare

Cloudflare Registrar APIベータ実践ガイド：AIエージェントにドメイン取得を任せる前に決めるべき7つの設計ポイント

Cloudflare Registrar APIベータを使って、ドメイン検索から登録までを自動化する実践ガイドです。SearchとCheckの違い、非同期ワークフロー、課金事故を防ぐ承認フローまで、個人開発で安全に回す設計を具体例付きで整理します。

約9分

はじめに

AIエージェントに「このサービス名よさそう。ドメイン取っておいて」と言える世界、ついに来ました。便利です。とても便利です。便利すぎて、気を抜くと財布のひもまで自動化されます。

2026年4月、CloudflareがRegistrar APIのベータを公開し、ドメインの検索・在庫確認・登録をAPI経由で実行できるようになりました。しかもCloudflare MCPと同じAPI面に乗っているため、エージェントから呼びやすい設計になっています。

この記事では、公式ブログとドキュメントを読み解きつつ、個人開発者が実際に運用へ落とすときの設計ポイントを整理します。私は「自動化は速さだけでなく、失敗したときに戻れることが本番品質」という立場なので、その観点で書きます。

1. Registrar APIベータで何ができるのか

まず機能の核はシンプルです。

  • Search: 候補ドメインの提案
  • Check: レジストリに対するリアルタイム在庫と価格確認
  • Register: 登録ワークフロー開始

公式ブログでは、エディタやターミナル、エージェント駆動フローでこの3ステップを回せることが強調されています。特に重要なのは、Search結果は高速な探索向けであり、最終判断はCheckで行う前提になっている点です。ここを混同すると、在庫競合で失敗します。

※ レジストリ: TLD（.com など）を管理する元締め組織のことです。販売窓口であるレジストラとは役割が異なります。

また、ベータ時点では拡張子が一部に限定されています。ダッシュボードでは扱えても、APIでは未対応の拡張子があり、Checkで extension_not_supported_via_api が返るケースがあります。ここは実装側で必ずハンドリングが必要です。

2. SearchとCheckを分ける理由

「Searchで registrable が true なら、そのままRegisterでよいのでは」と思いがちですが、ここが最初の落とし穴です。Searchはキャッシュベースの探索結果で、Checkはレジストリ照会ベースの確定値です。

つまり、Searchは不動産サイトの物件一覧、Checkは内見予約の電話確認みたいなものです。一覧に載っていても、さっき申し込み済みかもしれません。

実装ルールとしては次の2行で十分です。

  • ユーザーに見せる候補はSearchで作る
  • 課金が発生する直前に必ずCheckを実行する

さらに運用上は、Check結果の価格を承認画面にそのまま表示し、承認トークンに価格ハッシュを含めると安全です。これで「別の価格で実行された」事故を減らせます。

3. 実装の最小構成（curlベース）

以下は公式ドキュメントの流れに沿った最小構成です。手元で未検証のため、導入時は検証環境で確認してください。

export ACCOUNT_ID="<YOUR_ACCOUNT_ID>"
export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"

3-1. 候補を探す（Search）

curl --request GET   --url "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/registrar/domain-search?q=ai%20notes&limit=5"   --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

3-2. 確定在庫を確認する（Check）

curl --request POST   --url "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/registrar/domain-check"   --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"   --header "Content-Type: application/json"   --data '{"domains":["example.dev"]}'

3-3. 登録ワークフローを開始する（Register）

curl --request POST   --url "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/registrar/registrations"   --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"   --header "Content-Type: application/json"   --data '{"domain_name":"example.dev"}'

このとき、応答は201で即時完了する場合と、202で非同期処理に回る場合があります。202の場合は links.self をポーリングして状態遷移を監視します。

4. 非同期ワークフローを運用できる形にする

ドメイン登録は外部要因が絡むため、同期完了だけを前提にすると壊れます。CloudflareのAPI参照にも、in_progress、action_required、blocked、failed といった状態が定義されています。

ここでの実装指針は次の通りです。

  • in_progress: 指数バックオフで再照会
  • action_required: 自動再試行を止め、人間に通知
  • blocked: 一定間隔で継続監視し、タイムアウトを設ける
  • failed: エラー内容を保存して手動再実行へ

※ 指数バックオフ: 失敗時の待機時間を 1秒、2秒、4秒 のように伸ばす再試行手法です。

実務では action_required を「失敗」と誤判定して無限再試行する事故が起きがちです。状態は言葉通りに扱うのが正解です。特に action_required は人の操作が必要なので、ジョブキューで寝かせても自然回復しません。

5. 課金事故を防ぐ承認フロー設計

公式ブログでも「登録は非返金、既定の支払い方法に課金される」と明記されています。つまり、誤実行のダメージがそのまま金額になります。

私は最低でも次の3点を必須にします。

  1. 二段階確認
  • Check結果（ドメイン名、初年度費用、更新費用）を表示
  • 人間の明示承認を受けてからRegister
  1. 実行窓の短期化
  • 承認から実行までの有効期限を短くする
  • 期限切れならCheckをやり直す
  1. 監査ログ
  • 誰が、いつ、どの価格を見て、何を承認したかを保存
  • 後から説明できる状態を作る

技術的には地味ですが、ここが最も効きます。エージェントの賢さより、会計部門に説明できるログのほうが長生きします。

6. APIトークンと権限の分離

Registrar APIを回すには、適切な権限を持つAPIトークンと、課金設定済みのアカウントが必要です。ここでありがちな失敗は「とりあえず広い権限のトークンを1本作る」ことです。

最小権限設計の観点では、以下を分離するのが安全です。

  • 読み取り系（Search、Check相当）のトークン
  • 書き込み系（Register実行）のトークン
  • CIやバッチ向けのサービス主体トークン

また、Register実行トークンは人間承認を通ったワークフローからしか呼べないようにします。たとえば、承認済みジョブIDを持つリクエストだけを受けるゲートウェイを前段に置く構成です。

「エージェントに全部渡せば早い」は短期的には正しいですが、長期運用では秘密情報の持ちすぎが必ず負債になります。

7. 個人開発での現実的な導入パターン

ここまで読むと「大げさでは」と感じるかもしれません。わかります。私も最初はそう思います。ですが、個人開発ほど運用者が一人なので、事故時の復旧まで一人です。だからこそ先にガードを置きます。

おすすめは次の段階導入です。

フェーズ1: 半自動

  • SearchとCheckだけ自動
  • Registerは手動コマンド

フェーズ2: 条件付き自動

  • 指定TLDのみ自動化
  • 上限金額を超えたら必ず手動承認

フェーズ3: ほぼ自動

  • 価格上限、禁止語、監査ログ、通知を整備
  • 低リスク案件のみ自動Register

この順序なら、運用知見をためながら自動化率を上げられます。最初から100点を狙うより、壊れない70点を育てる方が結果的に速いです。

8. よくある失敗と先回りチェックリスト

最後に、実装時によく踏む地雷を短くまとめます。

  • 失敗1: Search結果だけで購入する
    → 必ずCheckを直前実行し、価格を再表示します。

  • 失敗2: 非同期状態を2種類しか扱わない
    → action_required と blocked を別物として設計します。

  • 失敗3: 監査ログが薄い
    → 承認者、承認時刻、表示価格、実行リクエストIDを残します。

  • 失敗4: 自動化対象TLDを増やしすぎる
    → 最初は .com と .dev など数種類に絞ります。

  • 失敗5: 「あとで直す」で本番投入する
    → ドメイン登録は後戻りしづらいので、まず小さい運用で検証します。

ここまで守れば、少なくとも「うっかり連打で予算が蒸発」はかなり防げます。システムの品質は、賢い一発より、地味な安全策の積み上げで決まります。

まとめ

Cloudflare Registrar APIベータは、エージェント時代のドメイン運用にとってかなり実用的な一歩です。Search、Check、Registerの分離が明確で、非同期ワークフローも扱いやすく、MCP経由での統合も見通しがよいです。

一方で、登録は課金かつ非返金という強い現実があります。だからこそ、技術設計の本丸は「呼べること」ではなく「誤って呼ばないこと」です。

自動化は、手数を減らす道具です。判断を雑にする免罪符ではありません。AIにドメイン取得を任せるなら、最初に作るべきはプロンプトより承認フロー、そして失敗時に説明できるログです。

明日から実装するなら、まずはこれだけで十分です。

  • Searchで候補を出す
  • Checkで確定値を取る
  • 人間承認後にRegisterする
  • 202時のポーリングを実装する

この4点が動けば、あなたのエージェントは「勢いで買い物する新人」から「家計簿を読める同僚」に進化します。ここ、地味ですが効きます。

参考リンク

  1. Cloudflare Blog: Register domains wherever you build: Cloudflare Registrar API now in beta
    https://blog.cloudflare.com/registrar-api-beta/
  2. Cloudflare Docs: Registrar API guide
    https://developers.cloudflare.com/registrar/registrar-api/
  3. Cloudflare Changelog: Cloudflare Registrar API is now in beta
    https://developers.cloudflare.com/changelog/post/2026-04-15-registrar-api-beta/
  4. Cloudflare API Reference: Registrar resources
    https://developers.cloudflare.com/api/resources/registrar/
  5. Cloudflare Registrar Overview
    https://developers.cloudflare.com/registrar/
Tags #Cloudflare #Registrar API #AIエージェント #自動化 #個人開発
← 記事一覧に戻る ページの先頭へ ↑