所有権の証明を、コードに置くかDNSに置くか
Google Search Console（GSC。Googleが無料で提供している、自分のサイトが検索でどう見えているかを確認できるツール）にサイトを登録するとき、「プロパティの種類」は「URLプレフィックス」と「ドメイン」の2択がある。このアイデアではすでに「URLプレフィックス」を採用する方針が決まっていた。理由は、ドメインプロパティだと所有権確認（「このサイトは本当に自分のものです」とGoogleに証明する手続き）がDNSのTXTレコード登録一択になり、「コード変更だけで完結させる」という当初の狙いと噛み合わないから、というものだった。
ただ、あらためて考え直してみた。「機能面ではどっちが優れているのか」「開発の規模はどれくらい変わるのか」を突き詰めると、最初の理由づけだけでは説明しきれない部分に気づいた。今日はその整理の記録。
結論：開発の要・不要を決めるのは「プロパティの種類」ではなく「証明書の置き場所」
最初は、「URLプレフィックス＋HTMLタグ方式」と「ドメイン＋DNS TXT方式」の差を、プロパティの種類の違いだと思っていた。でも実際に開発規模を左右していたのは、プロパティの種類そのものではなく、**所有権確認の「方法」**の方だった。
GSCの所有権確認には、Googleが用意した複数の方法がある。
- HTMLタグ：
<meta name="google-site-verification" content="...">という一行（metaタグ。ページの<head>に書く、ブラウザには表示されない補足情報）を、ページの<head>に埋め込む - HTMLファイル：指定されたファイルをサイトのルート直下に置く
- Google アナリティクス／タグマネージャ：既に導入済みのトラッキングコードを流用する
- DNSレコード（TXT）：ドメインを管理するDNSサーバー（ドメイン名の「住所録」のような仕組み）にTXTレコードを追加する
たとえるなら、これは「証明書をどこに貼るか」の違いだ。
- HTMLタグ方式は、証明書を家の中の壁に貼るようなもの。Googleは実際にその家（ページ）を訪ねてきて、中に入って壁の証明書を確認する。つまり証明の在り処は「アプリケーションが実際にブラウザへ返すHTML」の中にある。
- DNSレコード方式は、証明書を家の中ではなく、町内会の掲示板（DNSサーバー）に貼るようなもの。Googleは家を訪ねずに、掲示板だけを見に行く。ページの中身がどうなっているかは一切関係ない。
この違いが、そのまま開発の要・不要に直結する。
Next.jsでHTMLの<head>の中身を変えるということは、layout.tsx（アプリ全体やページ共通のhead情報をまとめて設定するファイル）のmetadata設定を変えるということであり、それはコードの変更そのものだ。環境変数を足し、ビルドし、デプロイし、本番でタグが出力されているか確認する。今回のタスクリストに並んでいた「開発」「品質」タスクは、すべてこの「ページの中身を変える」という一点から発生していた。
一方、DNSレコード方式では、Googleはページを一切見に行かない。ドメインのDNSサーバーに対して「このTXTレコードは存在するか」を問い合わせるだけだ。ドメインの情報を外から引く操作であり、アプリケーションのコードにも、デプロイにも、ビルドにも一切関係がない。DNS側でレコードを1行追加するだけで完結する、純粋なインフラ設定の話になる。
まとめると、開発が必要かどうかを決めているのは「プロパティの種類」ではなく、「証明書をどこに置くか」だった。
- ページの中（HTML）に置く → アプリケーションのコードを変える必要がある → 開発が発生する
- DNSの中に置く → アプリケーションには一切触れない → 開発は発生しない
プロパティの種類は「選べる方法の幅」を決めているだけ
ここでもう一段掘り下げると、面白いことに気づいた。
- ドメインプロパティは、確認方法がDNS TXTレコードのみに固定されている。選択の余地がない
- URLプレフィックスプロパティは、HTMLタグ・HTMLファイル・GA・GTM・DNSレコードの中から選べる
つまり、URLプレフィックスプロパティを選んだ場合でも、確認方法として「DNSレコード」を選べば、ドメインプロパティと同じく開発ゼロで済むということになる。
これはタスクリストを見返して気づいた点で、所有権確認方法の一覧には「ドメイン名プロバイダ」という選択肢も並んでいた。当初の設計ではHTMLタグを選ぶ前提でこの選択肢を除外していたが、それは「コード変更だけで完結させたい」という狙いがあったからで、開発ゼロを狙うならむしろ選ぶべき選択肢だったことになる。
整理すると、実は3つの組み合わせが存在する。
| プロパティ種別 | 確認方法 | 開発規模 | スコープ |
|---|---|---|---|
| URLプレフィックス | HTMLタグ | 開発あり（layout.tsx変更等） |
厳密（登録URLのみ） |
| URLプレフィックス | DNSレコード | 開発ゼロ | 厳密（登録URLのみ） |
| ドメイン | DNSレコード（一択） | 開発ゼロ | 広い（サブドメイン・プロトコル横断） |
「開発ゼロにしたい」という理由だけなら、プロパティ種別を変える必要はなく、確認方法をDNSレコードに変えるだけで達成できる。厳密なスコープを保ったまま開発規模だけを減らす、という選択肢が実は最初から用意されていた。
今日の学び
- 「開発が必要かどうか」は、GSCのプロパティ種別ではなく、所有権確認の「方法」（証明書をどこに置くか）で決まっていた。ページの中に置けば開発が要り、DNSの中に置けば要らない
- ドメインプロパティは確認方法がDNSレコード一択だが、URLプレフィックスプロパティも確認方法としてDNSレコードを選べる。「URLプレフィックス＝開発あり」「ドメイン＝開発なし」という対応関係は、実は確認方法の選び方次第で崩せる
- 「コード変更だけで完結させたい」という当初の狙いと、「開発規模を最小化したい」という狙いは、似ているようで実は別の基準だった。前者を優先するとHTMLタグ、後者を優先するとDNSレコードという、逆方向の答えになる
最初は「プロパティの種類」を比較していたつもりが、本当に比較すべきは「確認方法」だった。設計判断の理由づけを一段掘り下げると、選択肢そのものが増えることがある。
本記事は Sonnet 5（claude-sonnet-5）が生成しました。