本文へスキップ

GLOSSARY

登録ドメイン(registered domain)

ホスト名を「実際に登録できる単位」まで刈り込んだ形。www.example.co.jp を example.co.jp に寄せることで、引用をサイト単位で数えられます。

とうろくどめいん8分で読めます

登録ドメイン(registered domain)とは、ホスト名を「実際に登録できる単位」まで刈り込んだ形です。AI検索の引用を数えるときは、URLをそのまま数えるのでも、TLDのように粗く束ねるのでもなく、この単位で数える場面がいちばん多くなります。この項では、登録ドメインの範囲がどこまでなのか、Public Suffix Listが何をしているのか、そして集計でどこを間違えやすいかを整理します。

登録ドメインとは何か

ドメイン名は右から左へ階層になっていますが、「どこから下を自由に登録できるか」はTLDごとに違います。com の下は example.com から自由に登録できます。一方 jp の下は、co.jp や ne.jp といった区切りがさらに置かれていて、実際に登録するのは example.co.jp の位置です。この「その下でしかドメイン名を登録できない区切り」を公開サフィックス(public suffix)と呼び、公開サフィックスに左隣のラベルを1つ足したものが登録ドメインになります。

同じURLから取り出せる3つの単位。数えるときにどれを使うかで結果が変わります。

元のURLホスト名公開サフィックス登録ドメイン
https://www.example.com/pathwww.example.comcomexample.com
https://news.example.co.jp/2026/news.example.co.jpco.jpexample.co.jp
https://blog.example.tokyo.jp/blog.example.tokyo.jptokyo.jpexample.tokyo.jp
https://example.jp/example.jpjpexample.jp

横にスクロールできます

どこが公開サフィックスなのかは、規則から機械的に導けるものではありません。co.jp が公開サフィックスで example.com がそうでないことは、TLDごとの登録の決まりを知っていないと判断できないためです。そこで使われるのがPublic Suffix List(=公開サフィックスを列挙した一覧)で、Mozillaのボランティアと各レジストリからの登録で保守されています。ブラウザがCookie(=サイトが端末に保存する小さなデータ)を他のサイトへ漏らさないようにする用途で作られた一覧ですが、いまはURLを組織の単位へ寄せる処理で広く参照されています。

ぜ重要か(AI検索での位置づけ)

AIの回答に付く出典は、URLの形で返ってきます。これをそのまま数えると、ページ単位の集計になります。ページ単位は「どの記事が引用されたか」を見るには適していますが、「どのサイトが引用されているか」は分かりません。同じサイトの別ページが何本も引用されている場合、ページ単位ではばらけたままになるからです。

かといってTLDまで刈り込むと、今度は粗すぎます。com に何件、jp に何件と出ても、どのサイトが引用されているかは分かりません。登録ドメインはこの中間にあたる単位で、ちょうど「1つの運営主体が押さえている場所」に近いところで束ねられます。引用ランキングを組むとき、行の単位に据えるのはこの登録ドメインになります。

BigQueryで寄せる(NET.REG_DOMAIN)

BigQuery(=Google Cloudの大規模データ分析基盤)には、URLからこの3つの単位を取り出す関数が用意されています。NET.HOST がホスト名、NET.PUBLIC_SUFFIX が公開サフィックス、NET.REG_DOMAIN が登録ドメインを返します。NET.REG_DOMAIN は公式ドキュメントで「公開サフィックスと、その左隣のラベル1つ」を返すと定義されていて、参照する一覧はpublicsuffix.orgのものです。集めた出典URLをこの関数に通すだけで、サブドメインは自動的に寄ります。

BigQueryのNet関数が返す3つの単位(公式ドキュメントの実行例より)。

関数返すものwww.Example.Co.UK での結果
NET.HOST(url)ホスト名(正規化しない)www.Example.Co.UK
NET.PUBLIC_SUFFIX(url)公開サフィックスCo.UK
NET.REG_DOMAIN(url)登録ドメインExample.Co.UK

横にスクロールできます

注意したいのは、大文字小文字がそのまま残る点です。公開サフィックスを探すときは内部で小文字に直しますが、返ってくるのは元の文字列の一部なので、Example.Co.UK のように入力の見た目が保たれます。集計キーとして使うなら、そのあとで小文字にそろえる処理を自分で入れます。また、ホスト名を取り出せない場合や、公開サフィックスしか含まない場合はNULLが返るため、NULLの行がどれだけ出たかも一緒に数えておくと取りこぼしに気づけます。

1つ、Public Suffix Listにはprivate domain(=ホスティング事業者などが自分で登録した区画)の欄がありますが、BigQueryのNet関数はこれを公開サフィックスとして扱いません。公式ドキュメントの例では、us.com がprivate domainとして載っていても NET.REG_DOMAIN("foo.us.com") は us.com を返す、と説明されています。ブログサービスのサブドメインを別サイトとして分けたい場合、この関数だけでは分かれないということです。

よくある誤解・注意点

登録ドメインに寄せるかどうかは、何を知りたいかで決まります。「どのサイトが引用されているか」を知りたいなら寄せます。一方で、同じ運営でもサブドメインごとに中身が独立している場合は、寄せると別のものを1つに混ぜてしまいます。集計の目的を先に決めて、寄せる/寄せないを固定し、レポートには必ずどちらで数えたかを書き添えます。

  • 寄せると見えなくなるものがあります:サブドメインごとの差は、登録ドメインに寄せた時点で消えます。両方の粒度で数えておくと後から比べられます。
  • 公開サフィックスの一覧は更新されます:いまNULLになる入力が、あとから値を返すようになることがあります。集計をやり直したときの差は、この更新で説明が付く場合があります。
  • Punycodeを揃えます:日本語ドメイン名は xn-- で始まる形で記録されることがあり、見た目の文字列だけで突き合わせると別物として数えます。
  • ページ単位の集計も残します:登録ドメインだけにすると、どの記事が引用されたかが追えなくなります。
  • 1組織1行にはなりません:グループ会社が別ドメイン名を持っていれば行は分かれます。名寄せの方針は人が決めます。

実務の進め方

  1. AIの回答から出典URLを取り出し、質問・日付・モデルとひもづけて保存します。
  2. URLを NET.REG_DOMAIN に通し、登録ドメインの列を作ります。あわせて NET.HOST の列も残します。
  3. 登録ドメインを小文字にそろえ、集計キーにします。
  4. NULLになった行の件数を数え、URLの形が壊れていないかを確かめます。
  5. 登録ドメイン別に引用回数を数え、母数と期間を添えて並べます。
  6. 同じ運営とみなすドメイン名がある場合は、名寄せの対応表を別に持ち、寄せる前と寄せたあとの両方を残します。

登録ドメインとホスト名は何が違いますか。

ホスト名はURLに書かれているサーバーの名前そのもの(www.example.co.jp)で、登録ドメインはそれを実際に登録できる単位まで刈り込んだ(example.co.jp)です。サブドメインの違いは登録ドメインでは消えます。

サブドメインは寄せるべきですか。

目的次第です。「どのサイトが引用されたか」を数えるなら寄せます。サブドメインごとに中身が独立していて、その差を見たい場合は寄せません。どちらで数えたかをレポートに明記することのほうが大切です。

ブログサービスの個人ページは、書き手ごとに分けられますか。

BigQueryの NET.REG_DOMAIN では分かれません。この関数はPublic Suffix Listのprivate domainを公開サフィックスとして扱わないため、サービスの登録ドメインに寄ります。書き手ごとに分けたい場合は、URLのパスまで見て自分で切り分ける処理が要ります。

同じ集計をやり直したら数字が少し変わりました。なぜですか。

公開サフィックスの一覧は時間とともに更新されるため、以前はNULLだった入力が値を返すようになることがあります。集計のたびに、NULL件数と使ったデータの期間を記録しておくと、差の原因を切り分けられます。

関連する出典

この記事の根拠にした一次情報(=発表元がみずから出している資料)です。

  1. Google Cloud: BigQuery Net functions(NET.HOST / NET.PUBLIC_SUFFIX / NET.REG_DOMAIN)(新しいタブで開く)https://cloud.google.com/bigquery/docs/reference/standard-sql/net_functions
  2. Public Suffix List: Learn more(一覧の目的と成り立ち)(新しいタブで開く)https://publicsuffix.org/learn/
  3. Public Suffix List: 一覧の本体(新しいタブで開く)https://publicsuffix.org/list/
  4. IANA: Root Zone Database(TLDの全一覧)(新しいタブで開く)https://www.iana.org/domains/root/db

関連用語

TLD(トップレベルドメイン)

てぃーえるでぃー

ドメイン名のいちばん右にある区切り。.jp・.com のように、そのドメイン名がどのレジストリ(=登録を管理する組織)の下にあるかを表します。

サイテーション/引用(citation)

さいてーしょん

AIの回答が、根拠としてあなたのサイトを出典に挙げること。多くはリンクや番号付きの参照が伴います。回答本文で名前が触れられるだけの「言及(mention)」より一段強い、AI検索での可視性の本丸。

引用率

いんようりつ

AI回答が自社を出典として挙げる割合。当ラボの中心的な計測指標で、GEO/AEOの成果を測る温度計にあたります。

ログ解析

ろぐかいせき

サーバーが記録した全リクエストのログを集計し、AIボットの訪問回数・頻度・巡回範囲を可視化する分析手法。

リファラー

りふぁらー

訪問者がどのページ経由で来たかを示すHTTPヘッダー。AI検索からの流入は付かない・独自表記になることが多く計測が難しいです。

シェア・オブ・ボイス

しぇあおぶぼいす

ある話題での露出全体のうち、自社ブランドが占める割合。もとは広告費の占有率を測る指標で、AI回答での言及シェアに応用されます。

可視性(visibility)

かしせい

AI検索や従来検索の回答面で、自社がどれだけ見つけられ・参照されるかを測る総合指標。本丸は引用・言及であり、クロール量ではありません。

AI検索

エーアイけんさく

生成AIを使って答えを導く検索の総称。

CONTACT US

お問い合わせ

調査・取材・共同研究のご相談を承ります。

FOLLOW US

最新情報をチェック

新着のレポートと研究員コラムをお知らせします。

調査レポート日本のAI検索 実態レポート 第1回:通信キャリア編