さくらのクラウドの DNS は API で操作できますが、日常の作業を curl の手書きで続けるより、目的に合った既存の道具に任せるほうが安全です。レコードの確認とバックアップは usacloud、ゾーン全体の管理は Terraform、証明書の DNS-01 認証は lego などの ACME クライアント、と役割を分け、1つのゾーンを書き換える道具を1つに決めるのが基本になります。この記事では、認証情報の渡し方、それぞれの道具での操作の流れ、道具同士がぶつからないようにする設計、作業後の確認方法を説明します。
ツールのサブコマンドやオプション、プロバイダーのバージョン、コントロールパネルの表記は変わることがあります（2026年10月現在）。コマンドは例として示すので、使っているバージョンのヘルプと公式ドキュメントで確かめてから実行してください。
前提：なぜ「書き換える道具を1つ」にするのか
この記事が扱うのは、さくらのクラウドのコントロールパネルでゾーンを作る DNS（DNS アプライアンス）です。さくらのドメインやレンタルサーバの会員メニューにあるゾーン編集は別のサービスで、ここで紹介する道具の対象ではありません。どちらを使っているかは dig example.com NS +short で返るネームサーバー名で見分けられます。
さくらのクラウドの DNS は、API の上ではゾーンのレコード一覧をまとめて置き換える形で更新します。そのため、Terraform とスクリプトと手作業がそれぞれ「今の一覧を読んで、書き換えて、送る」を行うと、後から送ったほうの内容で上書きされ、先の変更が消えることがあります。道具を増やす前に、どのゾーン（またはどの名前）をどの道具が受け持つかを決めておくことが、事故を防ぐいちばんの近道です。
認証情報を用意して渡す
コントロールパネルで API キーを作成すると、アクセストークンとアクセストークンシークレットが発行されます。用途ごとに別のキーを作り、許可する範囲を必要最小限にします。たとえば、バックアップ用は閲覧だけ、Terraform 用と証明書用は編集もできる、のように分けておくと、どれかが漏れたときに止める範囲を小さくできます。
usacloud、Terraform のプロバイダー、lego は、いずれも環境変数からトークンを読めます。値はコマンドラインやスクリプトに直接書かず、権限を絞ったファイルに置いて読み込みます。
# ~/.sakuracloud.env（chmod 600。値は発行されたものに置き換える）
export SAKURACLOUD_ACCESS_TOKEN="your-access-token"
export SAKURACLOUD_ACCESS_TOKEN_SECRET="your-access-token-secret"chmod 600 ~/.sakuracloud.env
. ~/.sakuracloud.envこのファイルは Git のリポジトリに入れないようにし、CI で使う場合は CI のシークレット機能から環境変数として渡します。
usacloud でゾーンを確認し、バックアップを取る
usacloud は、さくらのクラウドの公式ドキュメントでも案内されているコマンドラインツールです。インストール方法はその案内に従い、まず DNS 関連のサブコマンドを確認します。usacloud はバージョンによってサブコマンドの構成が変わっているため、ネット上の古い記事のコマンドがそのまま動かないことがあります。
usacloud --version
usacloud dns --helpゾーンの一覧と、特定のゾーンの内容は次のように確かめられます。出力形式の指定方法もバージョンで違う場合があるので、--help の表示に合わせてください。
usacloud dns list
usacloud dns read 123456789012 --output-type json > "dns-backup-$(date +%Y%m%d).json"この読み取りを cron などで毎日実行して日付付きのファイルに残しておくと、誤った更新があっても、どの時点のレコードに戻せばよいかがすぐ分かります。バックアップ用のキーは閲覧権限だけにしておけば、スクリプトが誤ってゾーンを書き換える心配もありません。
usacloud にはレコードを追加・変更する操作もありますが、ゾーン全体を置き換える仕組みは同じです。Terraform で管理しているゾーンを usacloud で書き換えると、次の terraform apply で元に戻されるので、変更はどちらか一方で行います。
Terraform でゾーンをコードとして管理する
レコードの変更が定期的にある、複数の人で変更を確認したい、という場合は Terraform が向いています。さくらのクラウド用のプロバイダー（sacloud/sakuracloud）では、ゾーンとレコードを次のように書けます。
terraform {
required_providers {
sakuracloud = {
source = "sacloud/sakuracloud"
version = "~> 2.0"
}
}
}
# 認証は環境変数 SAKURACLOUD_ACCESS_TOKEN / SAKURACLOUD_ACCESS_TOKEN_SECRET から読む
provider "sakuracloud" {}
resource "sakuracloud_dns" "example" {
zone = "example.com"
record {
name = "@"
type = "A"
value = "203.0.113.10"
ttl = 600
}
record {
name = "www"
type = "CNAME"
value = "example.com."
ttl = 600
}
}バージョンの指定は例です。使える属性や推奨される書き方はプロバイダーのドキュメントで確認してください。
すでにコントロールパネルで作ったゾーンを Terraform に移す場合は、いきなり apply しないことが大切です。ゾーンを Terraform の管理下に取り込み（import）、今あるレコードをすべてコードに書き写し、terraform plan で差分が出なくなるまで調整してから運用を始めます。コードに書き忘れたレコードは、次の apply で削除されます。
terraform init
terraform import sakuracloud_dns.example 123456789012
terraform planimport の書き方や対応状況はプロバイダーのバージョンで異なることがあります。作業の前には usacloud で取ったバックアップを手元に置いておきます。
Terraform の状態ファイル（tfstate）には、ゾーンの内容やリソースの情報が保存されます。複数人で使うならリモートに保存してロックをかけ、リポジトリには入れません。また、ゾーンの中に record ブロックで書くレコードと、レコード単位のリソースを同じゾーンに混ぜると、互いに相手のレコードを消そうとする差分が出ることがあるため、1つのゾーンではどちらかの書き方にそろえます。
lego で証明書の DNS-01 認証を自動化する
ワイルドカード証明書を Let's Encrypt で取るには、DNS-01 認証で _acme-challenge の TXT レコードを一時的に置く必要があります。lego はさくらのクラウドの DNS に対応したプロバイダーを持っており、環境変数のトークンを使って TXT の追加と削除を自動で行えます。
. ~/.sakuracloud.env
# まず Let's Encrypt のステージング環境で動きを確かめる
lego --email admin@example.com --dns sakuracloud \
--server https://acme-staging-v02.api.letsencrypt.org/directory \
--domains example.com --domains '*.example.com' runステージングで成功したら --server の指定を外して本番の証明書を取り、更新は renew で行います。オプションの書き方は lego のバージョンで変わることがあるため、lego --help で確かめてください。
ここで問題になるのが、Terraform と同じゾーンを書き換えることです。証明書の更新中に terraform apply が走ると、追加された TXT が消されたり、Terraform 側に想定外の差分が出たりします。避ける方法は2つあります。
- 実行の時間をずらす：証明書の更新と Terraform の適用を同じ時間帯に行わないようにします。手軽ですが、ずれた運用は崩れやすいです。
- 認証用のゾーンを分ける：メインのゾーンに
_acme-challenge.example.comから認証用の別ゾーンへの CNAME を一度だけ置き、lego には別ゾーンのほうへ TXT を書かせます。lego は_acme-challengeの CNAME をたどる動作に対応しているため、メインのゾーンは Terraform だけが書き換える状態を保てます。対応状況はドキュメントで確認してください。
証明書用のキーは、可能であれば認証用のゾーンだけを扱えるようにしておくと、漏れたときの影響をさらに小さくできます。
変更後に確かめること
どの道具を使った場合でも、API が成功を返したことと、ネームサーバーが新しい値を返していることは別に確かめます。ゾーンに割り当てられたネームサーバーへ直接問い合わせると、キャッシュの影響を受けずに確認できます。
dig @ns1.gslb1.sakura.ne.jp www.example.com CNAME +norec +short
dig @ns2.gslb1.sakura.ne.jp www.example.com CNAME +norec +shortネームサーバー名は例です。usacloud の出力やコントロールパネルに表示されたものに置き換えてください。あわせて、前日のバックアップと今のゾーンの内容を diff で比べると、意図しない削除が起きていないかをすぐに確かめられます。
まとめ
- さくらのクラウドの DNS は一覧の置き換えで更新されるため、ゾーンごとに書き換える道具を1つに決めます。
- API キーは用途ごとに分けて権限を絞り、環境変数で各ツールに渡します。
- usacloud は読み取りと日々のバックアップ、Terraform はゾーン全体の管理に使い、既存ゾーンは import と plan で差分をなくしてから運用します。
- lego で DNS-01 を自動化するなら、認証用のゾーンを分けて Terraform との衝突を避けます。
- 変更後は割り当てられたネームサーバーへの dig と、バックアップとの差分で確かめます。