AI検索時代のトピッククラスターとは？ ── Google公式ガイドと、当サイトのカテゴリ・タグ・逆引き扉を数えてみた（2026年8月時点）

01 「トピッククラスター」を、Googleは公式にどう定義しているか

developers.google.com の中に、この言葉そのものは見当たらない

「トピッククラスター」や「トピカルオーソリティ」というSEO業界の用語を、Google公式のドキュメント(developers.google.com配下)の中で定義したページを探しましたが、確認できた範囲では見当たりませんでした。「ピラーページ」「クラスターページ」といった呼び方も同様です。これらは、HubSpotなど海外のマーケティングツール企業が広めた、業界内の呼び名だと考えるのが実態に近いようです。

報じられた発言と、公式ドキュメントは分けて読む

Googleの検索アドボケイトであるJohn Muellerは、Redditでのやり取りの中で「トピカルオーソリティ」というSEO業界の概念について、否定的な立場を示したと報じられています。関連記事同士をリンクでつなげば「トピカルオーソリティ」というメダルがもらえる、という考え方には根拠がない、という趣旨の反応だったと海外メディアは伝えています(Search Engine Journalの報道)。一方で、サイト全体が広いテーマにおいて実際に優れていれば、そのテーマの検索でそのサイトが表示されうる、とも過去に発言しているとされます。公式ドキュメントでの明文化ではなく、あくまで報じられた発言である点には注意が必要です。

公式ドキュメントが、実際に使っている言葉

Google自身が使っているのは、もっと具体的で地味な言葉です。SEO Starter Guideは、「サイトの構成方法が、Googleのクロールとインデックスに影響を与えることがある」とし、同じトピックのページをディレクトリでグループ化することで、Googleが各ディレクトリの更新頻度を学習しやすくなると説明しています。URLの単語からパンくずリストを自動的に学習する仕組みがある、という記述もあります。「トピッククラスター」という完成した概念ではなく、「グルーピングすると、クロールの効率が上がる」という、もっと機械的な理由づけです。

02 なぜ、いま改めてこの話をするのか

AI Overview・AI Modeが「複数の検索」を裏で行っている

2026年に入り、AI検索の裏側の仕組みについて、Google自身の説明が増えました。公式ドキュメント「Google's Guide to Optimizing for Generative AI Features on Google Search」(2026年7月10日更新)は、query fan-out(クエリのファンアウト)という仕組みを、具体例つきで説明しています。例えば「芝生の雑草対策」というクエリが来たら、システム内部で「芝生用の最適な除草剤」「化学薬品なしの雑草除去」といった、関連する複数のクエリを自動的に生成し、それぞれの検索結果から回答を組み立てる、という説明です。1つのクエリに対して1つのページが答えるのではなく、1つのクエリの背後に複数の検索が走っていることになります。当サイトが独自に運用しているFan-Out APIによる記事の網羅性測定も、同じ考え方を応用したものです。詳しくは07章で触れます。

公式の「マイスバスティング」──やらなくていいこと

同じページには「Mythbusting」という節があり、いくつかの俗説を明確に否定しています。「llms.txtファイルはGoogle検索では使用されない」、そして「コンテンツをAI向けに細分化する必要はない(No requirement to break your content)」という記述です。「特定の書き方でしか書けない」という制約も存在しないとされています。当サイトも、llms.txtを実際に設置してAIクローラーのアクセスを59日以上観測し続けましたが、Googleからのアクセスは確認できませんでした(archives/116)。今日の一次情報の確認結果は、当サイトが半年近くかけて自分で測った結果と、方向性が一致します。

それでも「まとまり」が無関係というわけではない

特別な最適化は不要、というのは「AIのためだけの特別な書式」の話です。サイト構造そのものが評価と無関係になったわけではありません。Googleのクロールインフラのドキュメント「Managing crawling of faceted navigation URLs」(2025年12月18日更新)は、絞り込み用のURLが無秩序に増えると、クローラーが新しい有用なページを見つける時間が、無価値なURLへのクロールに奪われると説明しています。整理されていないサイトは、AI検索以前に、通常のクロールの段階で不利になりうるということです。

「フィード」の最適化は、また別の話

もう1つ、混同されやすいのがGoogle Discover(フィード)です。「Get on Discover」(2026年3月9日更新)によれば、Discoverはクエリへの応答ではなく"content related to their interests, based on their Web and App Activity"(ユーザーのWeb・アプリ利用履歴に基づく興味関心)によって表示するかどうかを決めています。このページには、トピックの網羅性やクラスター構造についての直接的な言及はありません。「フィードの最適化」を検索するとトピッククラスターの記事にたどり着くことがありますが、Discover自体は、記事同士のリンク構造を評価基準として明示してはいません。期待していた答えと違っても、それが一次情報から確認できる正確なところです。有用で信頼性の高いコンテンツ作成という一般的なガイダンスへのリンクが示されているだけで、専用のクラスター設計を求める記述は見当たりませんでした。

03 この記事で使う用語

トピッククラスター:あるテーマについて、複数の記事を相互リンクでまとめ、サイト内で1つのまとまりとして扱う設計のこと。前述のとおりGoogle公式が定義した用語ではなく、SEO業界で広まった呼び名。本記事ではこの意味で使う。

query fan-out(クエリのファンアウト):1つの検索クエリから、AIが関連する複数のサブクエリを内部的に生成し、それぞれの検索結果を統合して回答を組み立てる仕組み。02章で紹介した公式ドキュメントが具体例つきで説明している。

canonical(正規化):内容が重複、または類似する複数のURLのうち、どれを代表としてGoogleに伝えるかを指定する仕組み。<link rel="canonical">タグで指定する。ファセットナビゲーションが生む重複URLへの、代表的な対処法の1つ。

04 型別に見る、整理の作法

🅰 適用範囲 ── どんなサイトで効果を持ちやすいか

公式ドキュメントは、サイトの規模によって推奨が変わることを明示しています。SEO Starter Guideのディレクトリ分類の話は「especially if your site has thousands of URLs」(特に数千以上のURLを持つサイト)という前提つきです。数十本規模のサイトでは、ディレクトリ分類よりも、記事を横断する手作業のキュレーション(後述する「逆引き扉」のような形)のほうが効きやすい場面もあります。逆に、数千本規模のサイトで手作業のキュレーションだけに頼ろうとすると、担当者の作業量が先に破綻します。規模に応じて手段を変える、という当たり前の話ですが、公式ドキュメントの前提条件を読まずに一律の方法論を当てはめてしまう失敗は、よく見かけます。

サイトの規模	効きやすい整理手法	理由
数十本	手作業のキュレーション(逆引き扉・ハブページ)	全記事を人が把握できる規模。機械的な分類より、意図を持った橋渡しが効く
数百本	カテゴリ(少数語彙のタクソノミー)	ディレクトリ単位でクロール頻度の学習が働き始める規模
数千本以上	カテゴリ+タグ+XMLサイトマップの併用	手作業のキュレーションは物理的に追いつかない。機械的な分類とクロール保証の両方が要る

🅱 この記事が測っていないこと

🅲 手順 ── 整理を組み立てる6つの選択肢

実際にサイト構造を整えるとき、選べる手段は1つではありません。ディレクトリ・URL単位のグルーピング、カテゴリという少数語彙のタクソノミー、タグという自由入力のフォークソノミー、人手で悩みから記事へ橋渡しするハブページ、ファセットURLのcanonical戦略、そしてパンくずリストによる構造化データです。どれか1つを選ぶのではなく、サイトの規模に応じて組み合わせるのが実務的です。06章で、それぞれの強みと弱点を並べます。

05 自分のサイトで確認するチェックリスト

13項目、20〜30分の作業

以下は、公開済みのサイトに対して、今日から確認できる動作に翻訳したものです。最初の5項目はファセットナビゲーションまわりの点検、6〜9番目は内部リンクとクロール保証、10〜11番目は分類の網羅性、最後の2項目は運用の習慣に関わるものです。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• 自分のサイトのカテゴリ一覧・タグ一覧のページ(存在すれば)を開き、カテゴリ数とタグ数を数える
• タグ一覧の上から10個を見て、同じ意味の語が別表記で重複していないか確認する
• 絞り込み用のURLに、存在しない架空のキーワードを入れて開き、返ってくるHTTPステータスコードを確認する
• robots.txtを開き、絞り込みURLのパラメータ(?tag=や?category=など)への記述があるか確認する
• 絞り込みページのソースを開き、canonicalタグがどのURLを指しているか確認する
• 公開済みの記事を1本選び、そこから他の記事へのリンクが何本あるか数える
• そのリンクのアンカーテキストが「こちら」「詳しくはこちら」になっていないか確認する
• Search Consoleの「ページ」レポートで「検出 - インデックス未登録」のURL数を控える
• サイトマップに、カテゴリ・タグの絞り込みURLが含まれているか確認する
• パンくずリストが、ランダムに開いた3ページすべてに表示されているか確認する
• 自分のサイトのカテゴリ名を書き出し、1本も記事が属していないカテゴリがないか確認する
• 新しい記事を公開したとき、既存記事から最低2本のリンクを張ったか確認する
• 半年以上前に自分が書いた記事を1本開き、そこに書いたサイト構造の説明が、今の実装と一致しているか確認する

最後の1項目が、今回いちばん効いた

今回この記事を書くにあたって実際にいちばん効いたのは、最後の「半年前の自分の記事を読み返す」項目でした。01章と08章で触れているとおり、archives/6で書いた内容の一部は、今の実装と食い違っていました。書いた時点では正しいつもりでも、サイトは動き続けています。3番目の項目(架空のキーワードで絞り込む)も、07章で紹介する実際の発見につながりました。

06 整理の手段は1つではない

5つの手法を並べる

「トピッククラスターを作る」といっても、具体的な実装手段は複数あります。それぞれが解決する課題と、抱える弱点を整理しました。

手法	何を解決するか	弱点
カテゴリ 分類学	記事を少数の大分類に固定し、一覧・絞り込みを提供する	粒度が粗く、複数テーマにまたがる記事をうまく表現できない
タグ フォークソノミー	記事固有の専門用語を、柔軟に付与できる	語彙が揃わないと断片化する(07章で実測)
逆引き扉 ハブページ	読者の悩みや目的から、複数記事へ人手で橋渡しする	人手のメンテナンスコストがかかり、記事が増えると追いつきにくい
XMLサイトマップ	クローラーに全URLの存在を保証する	ユーザーには見えず、優先度や関連性を示す仕組みではない
パンくずリスト	階層構造を、ユーザーとGoogleの両方に明示する	タグのような、階層をまたぐ横断的な関係は表現できない

内部リンクは、5つの手法をつなぐ土台

SEO Link Best Practices for Googleは、"Every page you care about should have a link from at least one other page on your site"(関心のあるページには、サイト内の少なくとも1つの別のページからリンクを張るべきだ)と明記しています。カテゴリもタグも逆引き扉も、最終的には本文中のリンクという形で読者とクローラーの両方に届きます。同じドキュメントは、アンカーテキストについて「Click here」のような汎用表現を避け、リンク先の内容を具体的に表す文言を使うことも求めています。

07 当サイトの実測

羅針盤 ── 10部屋・8シリーズ・129記事

AI Ronブログには、「WEBディレクターの羅針盤」という逆引き型の扉ページがあります。実データ(ron-gateway-map.json、2026年8月18日時点)を確認すると、10の「部屋」(「AI検索時代の基礎を、ゼロから掴みたい」のような悩みの入口)と、8つの「シリーズ」(連載軸)、さらに緊急度(今すぐ確認すべき/今週の動き/じっくり学ぶ)とレベル(入門/実務/上級)という2つの軸があり、これらを組み合わせて129本の記事を案内しています。1本の記事が複数の部屋・複数のシリーズに同時に属することも珍しくありません。これは06章の表でいう「逆引き扉」に、緊急度・レベルという追加の軸を足した形です。

seo_articleのカテゴリ・タグは、まだ10本にしか使われていない

一方、このサイトにはもう1つ、seo_articleという別のコンテンツ群があります。こちらはflg_enable=1の記事が1,294本ありますが、2026年8月18日にカテゴリ(catetype)とタグ(tags)の列を新設したばかりで、実際にこの2つの値が入っているのは、書き直しが完了した10本のみです。1,294本のうち0.8%にとどまります。

カテゴリ語彙	使用記事数
SEO	10本
技術	5本
マーケティング	5本
AI	2本
GEO	1本
アクセシビリティ	0本

タグは10本の記事に対して延べ73個付与され、平均すると1記事あたり7.3個です。異なりで数えると58個のタグがあり、そのうち複数の記事にまたがって使われているのは11個だけ(最多は「Search Console」の5回)で、残る47個は、いまのところ1記事にしか付いていません。

タグは、記事の下で内部リンクに変わる

06章で「カテゴリもタグも逆引き扉も、最終的には本文中のリンクという形で読者とクローラーの両方に届く」と書きました。実装を確認すると、当サイトのタグは、記事の下部で実際にリンクに変換されています。テンプレート(detail.php)を見ると、タグは記事下部に1つずつチップとして並び、それぞれが/seo_article?tag=タグ名への実リンクとして出力されます。カテゴリも同様に、一覧ページのカード上でチップとして表示され、カテゴリ一覧ページへの導線を作っています。メタデータとして記事に付与された値が、そのまま実際のクロール可能なリンクに変わる設計です。これは、リンク集を別途手作業で用意しなくても、タグを付与する作業自体が内部リンクの追加を兼ねる、という意味でもあります。

絞り込みURLを、Googleの推奨事項と照らし合わせる

05章のチェックリスト3番目(架空のキーワードで絞り込む)を、当サイトの/seo_article?tag=で実際に試しました。存在するタグでも、存在しない架空のタグでも、いずれもHTTP 200が返ります。ページ内の<link rel="canonical">は、絞り込み前の一覧ページを指しており、これはファセットナビゲーションの公式ガイドが挙げる、複数の絞り込みURLを1つのURLに集約する設計として、許容される選択です。

ただし、同じガイドは"Return an HTTP 404 status code when a filter combination doesn't return results"(絞り込みの組み合わせが結果を返さない場合、HTTP 404ステータスコードを返すべき)とも明記しています。実際に架空のタグで絞り込んだページを確認したところ、記事のカードは0件のまま、ページ自体はHTTP 200で返っていました。ここは、公式ガイドの推奨とはズレています。robots.txtにも、この絞り込みパラメータについての記述は現時点でありません。声高に「壊れている」と言うほどの話ではありませんが、実測すると分かる、地味なギャップです。

08 このテーマの、これまで

半年前、内部リンク設計について書いた

2026年3月、当サイトはarchives/6で「内部リンク設計とトピカルマップの実践ガイド」というタイトルの記事を公開しています。当時は「記事007(GEO)をピラーページとし、各記事がクラスターとして相互リンクする」という、単一のピラー中心の構造を目指すと書いていました。ピラーページはテーマ全体を包括的に扱う1本の中心記事、トピッククラスターはその中心記事と複数の関連記事が相互リンクでつながる集合を指す、という使い分けが業界内では一般的です。

今日、07章で実際の実装を数えてみると、いま動いているのはそれとは違う形でした。単一のピラーではなく、10の部屋と8つのシリーズを組み合わせた、逆引き型の多軸構造に発展しています。半年前に描いた設計図と、今の実装は、同じ形をしていません。設計図を書いた時点で嘘をついていたわけではなく、サイトが動き続けた結果として、書いた通りにはならなかったということです。

重複記事の整理も、同じ根っこの作業

2026年8月には、archives/129で「同じサイトに同じ記事が2本ないか」を確かめる記録を公開しました。タイトルの一致で探すと45組、元記事の一致で探すと139組、探し方によって3倍の差が出たという内容です。分類を整えることと、重複をなくすことは、どちらも「サイトの地図を正しく保つ」という、同じ作業の両輪です。分類だけを整えても、同じテーマの記事が別々のURLで重複したままでは、読者もクローラーも、どちらを見ればよいのか分かりません。

このカテゴリ・タグ機能自体も、まだ実装の途中

07章で見たとおり、seo_articleのカテゴリ・タグは1,294本中10本にしか付いていません。この数字は固定されたものではなく、新方式で記事を書き直すたびに、毎日少しずつ増えていく途中経過です。E-E-A-Tやレーター向けガイドラインについて書いた別の記事や、構造化データがAIにどう読まれているかを検証した別の記事も、同じ枠組みの中でカテゴリ・タグを持つ10本に含まれています。整理の仕組みそのものが完成してから公開するのではなく、作りながら実測を公開するのが、このサイトのこれまでのやり方です。