ムームードメインで管理しているDNSレコードをスクリプトから変更したい場合、最初に確かめるべきなのは「公式に提供されているAPIがあるか」と「自動操作が利用規約で認められているか」の2点です。筆者が確認した範囲では、ムームーDNSのレコードを外部から操作するための一般向けAPIは案内されていません（2026年10月現在）。この記事では、その状況を自分で確かめる手順と、APIが必要な場面での現実的な代替策（DNSだけを移す、一部のサブドメインだけを任せる、証明書の認証だけを別のDNSで受ける）を説明します。
なぜAPIが必要になるのか
DNSをAPIで操作したくなる場面は、主に次の3つです。
- ワイルドカード証明書の自動更新: Let's Encrypt などでワイルドカード証明書を取るには、DNS-01 という方式で
_acme-challengeの TXT レコードを更新ごとに書き換える必要があります。 - レコードの一括変更: サーバー移転で多数のサブドメインの IP アドレスを一度に変えたい場合です。
- インフラのコード管理: Terraform などでDNSの設定をコードとして管理し、変更履歴を残したい場合です。
目的によって代替策が変わるので、何のためにAPIが必要なのかを先に決めておきます。
手順1: そのドメインのDNSを実際にどこが返しているか確かめる
ムームードメインでドメインを登録していても、DNSは別の事業者で運用していることがあります。まずネームサーバーを確認します。
dig example.com NS +short
whois example.com | grep -i 'Name Server'ムームーDNSを使っている場合は、ムームードメインのネームサーバー名が返ります。レンタルサーバーやCloudflareなどのネームサーバーが返る場合、レコードを管理しているのはそちらです。その事業者がAPIを提供していれば、ムームードメイン側を調べる必要はありません。
手順2: 公式の情報源を確認する
APIの有無は、次の順に確かめます。
- 公式ヘルプとお知らせ: 「API」「自動化」「DNS」などで検索します。新機能はお知らせ欄で案内されることが多いので、提供開始の告知がないかも確認します。
- 利用規約: 管理画面へのログインや操作をプログラムで自動化すること（いわゆるスクレイピング）を制限する条項がないかを確認します。
- サポートへの質問: 公開情報で判断できない場合は、「DNSレコードを外部プログラムから変更できる公式の手段はあるか」と具体的に問い合わせます。回答は記録として残しておきます。
あわせて、DNS自動化ツール側の対応一覧も参考になります。ACME クライアントの lego や acme.sh、Terraform のプロバイダー一覧、octoDNS などは、APIのあるDNS事業者ごとに対応を追加しています。これらに公式の対応がない場合、事業者がAPIを公開していない可能性が高いと考えられます。ただし、これは傍証にとどまるので、最終的には公式情報で判断してください。
非公式ツールを使う前に考えること
インターネット上には、管理画面をブラウザ操作で自動化する非公式のスクリプトが公開されていることがあります。業務で使うのは避けたほうが無難です。
- 規約違反のおそれ: 自動操作を禁じる条項に当たると、アカウントの停止につながる場合があります。
- 画面変更で突然動かなくなる: 管理画面のデザインが変わると、証明書の更新が止まるなど、気付きにくい障害になります。
- 認証情報の扱い: スクリプトにアカウントのパスワードを保存することになり、漏えいしたときの影響がDNSだけでなく、ドメインの移管や契約にまで及びます。二段階認証を有効にしていると、そもそも自動化が難しくなります。
代替策1: ドメインの登録はそのまま、DNSだけを移す
最も一般的なのは、ドメインの契約はムームードメインに残し、ネームサーバーだけをAPIのあるDNSサービスに切り替える方法です。Cloudflare、Amazon Route 53、Google Cloud DNS、さくらのクラウドのDNSなどがAPIを提供しています。
進め方は次のとおりです。
- ムームーDNSに登録しているレコードを、管理画面からすべて書き写して控える（メール関連の MX・TXT を含む）。
- 移行先で同じレコードを作り、移行先のネームサーバーに直接問い合わせて内容を確認する。
- 既存レコードの TTL を短くできる場合は、事前に短くしておく。
- ムームードメインの管理画面で、ネームサーバーを移行先のものに変更する。
- 数日間は、旧DNSのレコードを消さずに残しておく。
# 移行先に直接聞いて、切り替え前に内容を確かめる
dig example.com MX @ns1.new-dns.example.net +short
dig www.example.com A @ns1.new-dns.example.net +shortDNSSEC を有効にしている場合は、切り替え前に無効にし、移行先で改めて設定します。署名の不整合で名前解決が止まるのを防ぐためです。
代替策2: 自動化したいサブドメインだけを任せる
dev.example.com のように、自動化が必要な範囲が一部のサブドメインに限られる場合は、そのサブドメインだけを別のDNSに委任する方法があります。親ゾーン（ムームーDNS）に、サブドメイン用の NS レコードを登録します。この設定がムームーDNSの管理画面で可能かどうかは、登録できるレコードの種類をヘルプで確認してください。
代替策3: 証明書の認証だけを別のDNSで受ける
目的がワイルドカード証明書の自動更新だけなら、_acme-challenge の名前だけを、APIのある別のゾーンに CNAME で向ける方法があります。
_acme-challenge.example.com. CNAME _acme-challenge.example.com.auth.example.net.ムームーDNSにはこの CNAME を一度登録するだけで済み、更新のたびの TXT の書き換えは auth.example.net 側のDNSにAPIで行います。acme.sh の DNS エイリアスモード（--challenge-alias）や、acme-dns のような専用サーバーがこの方式に対応しています。メインのDNSを動かさずに済むので、影響範囲を小さくできます。
ワイルドカードが不要なら、Webサーバーにファイルを置いて認証する HTTP-01 方式を使えば、DNSの自動化そのものが要らなくなります。
APIを使うときの権限の絞り方
代替策でAPIを使う場合、トークンの権限は必要最小限にします。Cloudflare なら特定のゾーンのDNS編集だけを許可したAPIトークン、Route 53 なら対象のホストゾーンへの route53:ChangeResourceRecordSets などに絞った IAM ポリシーを使います。トークンはサーバーの設定ファイルや環境変数で管理し、Git リポジトリに含めないでください。
まとめ
- まず
dig NSで、レコードを実際に管理しているDNSがどこかを確かめます。 - APIの有無は、公式ヘルプ、お知らせ、利用規約、サポートへの質問で確認します。ツールの対応一覧は傍証として使います。
- 非公式の自動操作ツールは、規約、障害、認証情報の面でリスクがあります。
- 代替策は、DNSだけを移す、サブドメインだけを委任する、
_acme-challengeだけを CNAME で別ゾーンに向ける、の3つです。 - APIトークンは対象ゾーンと操作に権限を絞り、リポジトリに含めません。