屋号だけの個人事業で DUNS 番号を取得するまでにやったこと
法人ではなく屋号だけで活動している状態から、DUNS 番号を取得した。技術的に難しいことは何もないが、順序を間違えると詰まる。実際にやった手順と、判断の理由を残しておく。
なぜ DUNS 番号が必要になったか
直接のきっかけは Apple Developer Program の登録だった。個人名義ではなく事業者として登録する場合、DUNS 番号が求められる。加えて、海外サービスとの契約や将来の取引で「事業として実在していること」を示す識別子が必要になる場面があり、早めに取っておいて損はないと判断した。
DUNS 番号は Dun & Bradstreet が発行する事業者の識別番号で、法人でなければ取れないものではない。屋号で活動している個人事業でも申請できる。
先に揃えるものがある
申請フォームを開いてから気づいたが、申請そのものより「申請できる状態を作る」ほうに手間がかかる。具体的には、独自ドメインのメールアドレスと Web サイトだ。この2つが無いと、事業の実在性を示す材料が住所だけになる。
逆順にすると詰まる。サイトを作ってからドメインを決めると URL が変わるし、メールが通っていない状態で申請すると確認連絡を受け取れない。ドメイン → メール → サイト → 申請、の順で固定しておくのが安全だった。
ドメインの選び方
屋号をそのまま含む .com にした。理由は単純で、事業用の連絡先として一般的に信頼されている拡張子であること、そして屋号との対応が一目で分かることだ。
技術系らしい拡張子も検討したが、プレミアム扱いのものは年間コストが桁で違った。ドメインは持ち続ける限り毎年払う固定費なので、この段階で見栄えのために上乗せする理由がない。
メールは Google Workspace に寄せた
独自ドメインのメールをどう用意するかは選択肢が多い。最終的に Google Workspace を選んだのは、Gmail のインターフェースをそのまま使えること、SPF / DKIM / DMARC の設定手順が枯れていて配信品質が安定していること、そして運用でやることが実質ゼロになることだった。
検討して採用しなかった選択肢は次のとおり。
- Cloudflare Email Routing — 受信は無料で手軽だが、送信は別途 SMTP を用意する必要がある。事業用の連絡先として送受信の両方を安定させたかったので見送った。
- Amazon SES — 送信は問題ないが、受信を成立させるまでの実装と運用のコストが高い。ここに時間を使う場面ではないと判断した。
- .tech などのプレミアムドメイン — 年間コストが桁で違う(十数万円規模)。この段階で払う理由がない。
DNS を Terraform で持つときの詰まり
DNS は Route 53 にした。特別な理由はなく、普段から触っていて学習コストがゼロだったからだ。レコードは最初から Terraform で管理することにした。
ここで一箇所だけ設計が必要になる。ドメイン所有権確認の TXT と DKIM の CNAME は、メール側の管理画面で生成するまで値が決まらない。つまり「Terraform を書く → apply → 管理画面で値を生成 → Terraform を直す → もう一度 apply」という往復が発生する。
往復すること自体は避けられないので、値が未確定の間もコードが壊れないようにした。変数で注入し、空文字ならそのレコードを作らない形にしておく。
# 管理画面で生成するまで値が決まらないレコードは、
# 変数で注入して「空ならスキップ」にしておく
resource "aws_route53_record" "spf" {
zone_id = data.aws_route53_zone.main.zone_id
name = "example.com"
type = "TXT"
ttl = 3600
records = compact([
"v=spf1 include:_spf.google.com ~all",
var.google_workspace_verification_txt, # 未確定なら "" でスキップ
])
}
resource "aws_route53_record" "dkim" {
count = var.dkim_value != "" ? 1 : 0
# ...
}こうしておけば、最初の apply は空のまま通り、値が確定したタイミングで変数を埋めて apply するだけになる。設定後は名前解決を確認してから次に進む。
$ dig +short MX example.com 1 aspmx.l.google.com. 5 alt1.aspmx.l.google.com. ... $ dig +short TXT example.com "v=spf1 include:_spf.google.com ~all"
サイトは最低限でいい、ただし必須
申請の時点で必要なのは、屋号・事業内容・連絡先が読み取れるページだけだった。凝ったデザインも、豊富なコンテンツも要らない。ただし無いと厳しい。事業の実在性を確認する側から見て、参照できる公開情報がドメインとメールしかない状態は弱い。
1ページと、プライバシーポリシー。この2枚を静的ホスティングに載せるところから始めた。
申請で効いた「完全一致」
申請前に決めておいてよかったのが、表記の統一だ。次の4つを完全に一致させた。
- 屋号(Legal Business Name)
- 住所の英語表記
- メールアドレスのドメイン
- Web サイトの URL
特に住所の英語表記は、書き方の揺れが生まれやすい。番地の区切り、都道府県の綴り、建物名の有無。申請フォーム、サイト、メール署名で表記が違うと、確認の手間が増えて審査が長引く要因になる。先に「これで固定する」と決めて、全部の場所で同じ文字列を使った。
なお、屋号だけで活動していても、個人名を完全に伏せることはできない。どこまで公開するかは事前に線を引いておくといい。
申請後は確認の連絡が来ることがある。ここでメールが受け取れないと止まるので、疎通確認を申請前に済ませておくのが効く。番号が発行されてから Apple Developer 側で使えるようになるまでには、さらに1〜2日の反映待ちがあった。
まとめ
DUNS 番号の取得そのものは、フォームを埋めるだけの作業だ。難しいのは、その前提として「事業として参照できる状態」を作る部分にある。ドメイン、メール、サイト。この3つは DUNS のためだけでなく、その後の契約や登録でも同じものを求められ続けるので、最初にきちんと揃えておくと後がずっと楽になる。
逆に言えば、ここに時間をかけすぎる必要もない。完璧なサイトを作ってから申請するのではなく、要件を満たす最小構成で先に通してしまうほうが早い。