Search Consoleのクエリ一覧には、実際に検索された語句（検索クエリ）が並びます。その中には、企業名を含む指名検索、課題を探す非指名検索、比較検討、地域名を含む検索など、目的の異なるものが混ざっています。すべてを合算すると、ブランドを指定しない検索で接点が広がったのか、ブランド検索が伸びたのか、比較段階の需要が増えたのかを見分けにくくなります。かといって、毎月担当者の感覚で仕分けると、月ごとに基準がぶれて数字を比べにくくなります。
そこで、分類軸・辞書・例外・更新ルールを先に決めておきます。要点は、1つのクエリに複数の属性を付けられる設計にすることです。同じクエリが指名でもあり、比較でもあり、地域条件を含むこともあるためです。
本記事では、この考え方で再利用できるクエリ分類ルールを作る手順を、標準機能との使い分け、辞書と判定順、データの取り方、KPIの集計、版管理、毎月の運用の順に説明します。読み終えると、自社の分類辞書と、分類結果を記録する台帳の列、毎月の作業手順を設計できます。
結論｜「指名・非指名・比較・地域」は1列に押し込まず、複数の軸で分類する
Search Consoleのクエリ分類では、「指名」「非指名」「比較」「地域」を1つの排他的なカテゴリとして扱いません。これらは性質が別だからです。指名・非指名は「ブランドとの関係」、比較は「検索の目的」、地域は「検索の条件」を表します。
クエリ分類を含むSEO計測全体の見方は、SEOの効果測定と改善方法で整理しています。
指名・比較・地域は排他的な分類ではありません。同じ検索クエリへ複数の属性を付ければ、検索目的や条件を残したまま集計できます。
たとえば「Example社 SEO 比較 東京」というクエリは、指名検索であり、比較検討でもあり、地域条件も含みます。これを1つだけに分類すると、残りの情報が失われます。
そこで実務では、最低でも次のように列を分けます。比較は、比較・検討を示す語を含むかどうかのフラグとして持ちます。brand_classのunknownは、辞書で判定できなかったクエリを表します。
| 分類軸 | 主な値 | 何を評価するか |
|---|---|---|
| brand_class | branded / non_branded / unknown | ブランドを指定した検索か、指定していない検索か |
| comparison_flag | true / false | 比較・検討を示す語を含むか |
| intent_class | information / action / other | 何をしようとしている検索か |
| geo_flag | true / false | 地域条件を含むか |
| exception_rule | 例外IDまたは空欄 | 通常辞書では誤判定する語を上書き |
| rule_version | 例：2026-09-v1 | どのルールで分類したか |
| review_status | confirmed / review | 人の確認が必要か |
この形なら、「非指名×比較」「非指名×地域」「指名×比較」といったKPIを同じデータから作れます。分類の目的は検索語をきれいに並べることではなく、SEO成果を目的別に比較できる状態を作ることです。
Search Consoleの標準機能でできる分類と、自社ルールが必要な分類を分ける
まず、標準機能で何ができるかを確認します。2026年のSearch Consoleには、ブランドクエリと非ブランドクエリを自動的に分ける「Branded / Non-branded」フィルタがあります。Googleは、ブランド名だけでなく表記揺れ、スペルミス、ブランドに密接な商品・サービスまでAI支援システムで判定すると説明しています。
ただし、この分類は正規表現による固定ルールではなく、文脈に応じて判定されます。Google自身も誤分類が起こる可能性を案内しており、サブプロパティや表示回数が少ないサイトでは利用できません。
もう1つ、Search Console Insightsには、似たクエリをAIでまとめる「クエリグループ」があります。グループは大まかな傾向をつかむためのもので、時間とともに変化する可能性があります。自社の「比較」「地域」「料金」などの固定KPI分類を置き換えるものではありません。
次の表は、方法ごとの向いている用途と注意点です。
| 方法 | 向いている用途 | 注意点 |
|---|---|---|
| Branded / Non-brandedフィルタ | ブランド検索と非ブランド検索の傾向把握 | AI判定であり、自社定義と完全一致するとは限らない |
| クエリグループ | 類似クエリの大きな傾向把握 | グループが変化する可能性があり、固定KPIには不向き |
| カスタム正規表現 | 特定語群の抽出・確認 | 一度のフィルタであり、分類履歴や版管理は別途必要 |
| 自社分類辞書 | 月次KPI、継続比較、部門共通レポート | 辞書・例外・更新責任者を決める必要がある |
整理すると、Googleの標準機能は「確認用」、自社の分類辞書は「継続計測用」と役割を分けると運用しやすくなります。自社の分類辞書は手順2、正規表現は手順4で作り方を説明します。
手順1｜最初に「何を評価したいか」をKPIの問いとして固定する
分類辞書を作る前に、クエリを分ける目的を決めます。目的がないまま細かく分類すると、使わないカテゴリが増え、担当者によって判断が変わりやすくなるためです。
たとえばBtoBサイトなら、次の4つの問いから始められます。分類は、それぞれの問いに数字で答えられるように設計します。
- 非指名検索の表示回数・クリックは増え、ブランドを指定しない検索での接点が広がっているか
- 指名検索の表示回数・クリックは増え、ブランドを指定して探す需要が伸びているか
- 比較・検討系クエリのクリックは増え、意思決定に近い検索へ接点を持てているか
- 地域系クエリの表示回数・クリックは増え、商圏内の検索需要を取れているか
ただし、「東京 SEO会社 比較」のように、地域と比較が同時に現れるクエリがあります。どちらか1つの問いにだけ割り当てると、もう一方の問いの数字から漏れてしまいます。複数の軸で分類する前提が必要になるのは、このためです。
軸を決めるときは、検索意図の考え方が参考になります。検索意図には情報・ナビゲーション・取引などの古典的な分類があり、AI検索を含む現在の情報探索では新しい分類枠組みも研究されています。ただ、実際の運用では、学術的な分類をそのまま使うより、自社の意思決定に必要な軸へ変換する方が実用的です。
手順2｜指名・比較・地域の「分類辞書」を作る
分類辞書は、誰が実行しても同じ結果になる文字列一覧として管理します。高表示回数・高クリックのクエリから作り、毎月、未知の語を追加します。ここでは、指名、比較・検討、地域の順に、辞書に入れる語を整理します。
指名辞書は企業名だけでなく、表記揺れ・サービス名まで含める
指名辞書には、少なくとも次を入れます。
- 企業名・ブランド名
- ひらがな、カタカナ、英字などの表記揺れ
- 略称
- よくあるスペルミス
- 固有の商品名・サービス名
- ドメイン名の主要部分
- 旧名称が検索される場合は旧名称
GoogleのBrandedフィルタも、ブランド名だけでなく表記違い、誤記、ブランド固有の商品・サービスを対象にしています。自社辞書を作るときも、この範囲を確認すると漏れを見つけやすくなります。
ただし、一般名詞と同じサービス名には注意が必要です。一般語としても使われる名称を単独で指名扱いすると、非指名検索を誤分類するおそれがあります。こうした語は、手順3で説明する例外として先に判定します。
比較・検討辞書は「比較」だけでなく、意思決定語をまとめる
比較・検討の初期辞書には、次のような語を候補にできます。
比較 / 違い / vs / おすすめ / ランキング / 選び方 / 評判 / 口コミ / 料金 / 費用 / 事例
ただし、「料金」は必ず比較とは限りません。「自社名 料金」は指名後の確認、「SEO 料金」は相場調査という可能性があります。そのため、辞書は「語が入ったら検索意図が確定するルール」ではなく、「比較・検討フラグを付けるルール」として使います。こうすると誤判定を減らせます。
地域辞書は都道府県だけでなく、市区町村・駅名・商圏語も管理する
地域分類では、都道府県名だけでは足りません。次も辞書に入れます。
- 都道府県
- 市区町村
- 駅名
- 地域の通称
- 「近く」「周辺」などの近接表現
- 自社が営業対象とする商圏名
辞書は自社の商圏に合わせます。地名を含む会社名やサービス名がある場合は、地域の判定より先に例外として判定します。
手順3｜「例外 → 各分類軸 → 未分類」の順で判定する
分類を安定させるには、通常の辞書より先に適用する例外ルールが必要です。たとえば、一般語と同じ名前のサービスや、地名を含む社名は、通常の辞書に先に当てると誤判定するおそれがあります。おすすめの処理順は次のとおりです。
- 完全一致または明示的な例外ルールを適用する
- 指名辞書でbrand_classを判定する
- 比較・検討辞書でcomparison_flagを付ける
- 地域辞書でgeo_flagを付ける
- 必要なら情報収集・行動などのintent_classを付ける
- 判定できないものはunknownとして残す
- unknownのうち表示回数・クリックが大きいものから人が確認する
この順序のポイントは、通常辞書より例外ルールを先に適用することと、自動判定できないクエリをunknownとして残すことです。すべてを手作業で確認せず、KPIへの影響が大きいunknownのクエリから確認し、低頻度の曖昧語に時間を使いすぎないようにします。unknownをゼロにする必要はありません。
次の表は、この順序で判定した結果の例です。1つのクエリに複数の属性が付く点に注目してください。
| クエリ例 | brand_class | comparison_flag | geo_flag |
|---|---|---|---|
| Example社 | branded | false | false |
| Example社 料金 比較 | branded | true | false |
| SEO会社 比較 | non_branded | true | false |
| SEO会社 東京 比較 | non_branded | true | true |
| SEO対策 東京 | non_branded | false | true |
この方式なら「指名か比較か」の二者択一が不要になり、検索ユーザーがどの状態で、何を条件に探しているかを残せます。
手順4｜Search Consoleの正規表現は「抽出」に使い、分類台帳は別に持つ
Search Consoleのクエリフィルタでは正規表現を使えます。Google公式ヘルプによると、構文はRE2で、初期状態は部分一致・大文字小文字を区別しない判定です。複数語は|でOR条件にでき、^で先頭、$で末尾を指定できます。
辞書の語が実際のクエリに当たるかを確かめる確認用の初期パターンは、たとえば次のように作れます。
- 指名候補：
(example|エグザンプル|exampleサービス) - 比較候補：
(比較|おすすめ|ランキング|違い|vs|評判|口コミ) - 地域候補：
(東京|大阪|名古屋|新宿|渋谷|近く|周辺)
ここで注意したいのが、Search Consoleが採用するRE2では、先読み・後読みなどのlook-aroundや後方参照がサポートされないことです。PCREなどで動く(?=...)を、そのままSearch Consoleへ持ち込まないようにします。
また、正規表現フィルタは「その場で条件に合うクエリを表示する」機能です。毎月同じ分類を再現し、例外や変更履歴まで管理するには、スプレッドシート、Search Console API、BigQueryなどで分類列を持つ方が適しています。
手順5｜データ量に合わせてCSV・API・BigQueryを使い分ける
Search Consoleの画面から直接エクスポートできる表は、代表的なデータの最大1,000行に制限されます。中規模以上のサイトで大量クエリを継続分類する場合、画面エクスポートだけでは不足する可能性があります。方法ごとの向き不向きは次のとおりです。
| 方法 | 向いている状況 | 主な制約・注意 |
|---|---|---|
| 画面からCSV / Sheetsへ出力 | まず試す、少量データ、単発分析 | 表データは最大1,000行の代表例 |
| Search Console API | 定期取得、中規模サイト | 1日・検索タイプ・プロパティあたり最大5万行 |
| BigQueryへの一括エクスポート | 大規模サイト、日次蓄積、複数分類 | BigQuery設定と費用管理が必要 |
データ量と更新頻度に応じて、APIやBigQueryへ移行します。
BigQueryへの一括エクスポートでは、匿名化されたクエリを除き、Search Consoleで利用可能なパフォーマンスデータを日次で蓄積できます。
分類辞書をSQLや参照テーブルで管理すれば、同じルールを継続して適用しやすくなります。
手順6｜KPI集計では「合計してからCTRを計算する」
分類後のKPI集計で間違えやすいのは、クエリ行のクリック率（CTR）を単純平均してしまうことです。CTRはクエリごとの母数が異なるため、カテゴリ全体ではクリック数と表示回数を合計してから再計算します。
カテゴリCTR = カテゴリ内クリック数の合計 ÷ カテゴリ内表示回数の合計
たとえば、10回表示でCTR50%のクエリと、1,000回表示でCTR2%のクエリを単純平均すると26%になります。しかし実際のクリック数は5回と20回なので、合計CTRは25 ÷ 1,010で約2.5%です。単純平均ではカテゴリの実態を大きく誤認します。
図は、クエリ行を単純平均した26%と、クリック数と表示回数を合計してから再計算した約2.5%の差を示しています。
月次レポートでは、少なくとも次を同じ条件で比較します。
- 指名：表示回数、クリック、CTR
- 非指名：表示回数、クリック、CTR
- 比較・検討：表示回数、クリック、CTR
- 地域：表示回数、クリック、CTR
- 非指名×比較：表示回数、クリック、CTR
- 非指名×地域：表示回数、クリック、CTR
指名比率（指名検索が全体に占める割合）は、非指名検索が伸びるだけでも下がります。比率だけでなく指名検索の絶対数も確認します。
集計の注意点｜Search Consoleのクエリ合計が全体と一致しない前提でKPIを設計する
手順6で合計したクエリの数字が、画面上の全体の数字と合わないことがあります。ここでは、その理由と、KPIを設計するときの前提を説明します。
Search Consoleでは、プライバシー保護のため匿名化されたクエリが表から除外されます。また、内部制限により表示されない行もあります。匿名化クエリは、クエリフィルタをかけていない場合はグラフ合計に含まれるため、クエリ行を合計しても全体クリック数・表示回数と一致しないことがあります。
そのため、「分類済みクエリの合計＝検索全体」とは考えません。社内レポートでは、次のような補助指標を持つと安全です。
可視クエリクリック被覆率 = 分類対象クエリのクリック合計 ÷ 同期間のSearch Console総クリック
これは「全検索を何％分類できたか」を厳密に示す指標ではなく、Search Console上で確認・分類できるクエリが全体クリックのどの程度を占めるかを見る運用指標です。前月との比較では、期間、検索タイプ、国、デバイスなどの条件を揃えます。
手順7｜分類辞書にバージョンを付け、過去値の意味を変えない
分類辞書は運用すると必ず変わります。新サービスが増える、商品名が変わる、地域を拡大する、誤判定が見つかるといった変更が起こるためです。
辞書を更新したら、最低限次を記録します。
- rule_version
- 更新日
- 追加・削除した語
- 変更理由
- 影響する分類
- 過去期間へ再適用するか
- 更新者
辞書変更だけでKPIが動くことがあるため、継続比較では過去月のルールを保持します。最新定義で比較し直す場合は、対象期間をまとめて同じルールで再集計し、検索行動の変化と辞書変更を分けます。
毎月の運用は「抽出→分類→未分類確認→辞書更新→集計」の5工程に固定する
運用担当者が変わっても再現できるよう、毎月の作業順を固定します。
- 対象プロパティ、期間、検索タイプなどの集計条件を固定してデータを抽出する
- 当月のrule_versionで自動分類する
- unknownと例外候補を、表示回数・クリックの大きい順に確認する
- 必要な語だけ辞書・例外へ追加し、更新理由を記録する
- 指名・非指名・比較・地域と組み合わせKPIを集計する
人が確認するのは、新しく現れた重要クエリと、分類結果が不自然なクエリを中心にします。
そのまま使えるクエリ分類台帳の列
クエリ分類台帳の最小構成は次のとおりです。前半の5列はSearch Consoleの元データ、後半は分類結果と記録のための列です。
| 列 | 内容 |
|---|---|
| query | Search Consoleの検索クエリ |
| clicks | クリック数 |
| impressions | 表示回数 |
| ctr | 元データのCTR |
| position | 平均掲載順位 |
| brand_class | branded / non_branded / unknown |
| comparison_flag | true / false |
| geo_flag | true / false |
| intent_class | information / action / otherなど |
| matched_rule | 判定に使った辞書語・ルールID |
| exception_rule | 例外ルールID |
| review_status | confirmed / review |
| rule_version | 分類辞書の版 |
| classified_at | 分類日 |
特にmatched_ruleとrule_versionを残すと、「なぜこのクエリが指名扱いなのか」「先月と数字が変わったのは検索行動か、辞書変更か」を追跡できます。
よくある失敗｜分類数を増やすより、再現性を優先する
分類ルールの運用で起こりやすい失敗を5つ挙げます。
指名・比較・地域を排他的なカテゴリにする
同じクエリが複数の特徴を持つため、1列だけでは情報が失われます。ブランド軸、検討軸、地域軸を分けます。
担当者が毎月目視で分類する
同じ語でも人によって判断が変わり、過去比較が難しくなります。辞書と例外を先に適用し、人はunknownと重要例外だけを確認します。
辞書を更新しても変更履歴を残さない
分類基準が変わるとKPIの意味も変わります。rule_versionと更新理由を必ず残します。
Search ConsoleのAI分類を自社分類と完全に同一視する
Branded / Non-brandedは便利ですが、GoogleのAI支援分類です。自社が管理する指名定義と一致しないことがあるため、差分が大きいクエリを確認し、必要なら自社辞書を修正します。
クエリグループを固定分類として保存する
Search Console Insightsのクエリグループは、似た検索を俯瞰するには有効ですが、グループは変化する可能性があります。月次KPIは自社の分類辞書で固定し、クエリグループはテーマ発見や異常確認の補助に使います。
まとめ
Search Consoleのクエリ分類は、「指名・非指名・比較・地域のどれか1つを選ぶ」作業ではありません。ブランドとの関係、比較・検討の有無、地域条件などを別軸で持ち、同じクエリに複数の属性を残すことで、SEO成果を目的別に評価できます。
実務では、最初にKPIの問いを固定し、分類辞書と例外ルールを作り、rule_versionを付けて運用します。Search ConsoleのBranded / Non-brandedフィルタやクエリグループは確認・補助に使い、継続レポートは自社の分類辞書で集計します。
まずは直近1〜3か月のクエリを抽出し、指名辞書、比較・検討辞書、地域辞書の3つを作ってください。そのうえでunknownの上位だけを人が確認すると、毎月同じ基準で更新できる分類基盤を作れます。
参考文献・データ元
この記事で参照した情報を確認できます。
- Google Search Console Help「パフォーマンス レポート（検索結果）: 一般的なタスクとユースケース」
ブランド・非ブランド分類、クエリ分析方法を確認。
URL：Google Search Console Help - Google Search Central Blog「Search Console にブランドクエリ フィルタを導入」2025年11月20日公開、2026年3月11日更新
Branded / Non-brandedの定義、AI支援分類、利用条件を確認。
URL：Google Search Central Blog - Google Search Central Blog「Search Console Insights にクエリ グループを導入」2025年10月27日
AIによる類似クエリのグループ化と、グループが変化し得る点を確認。
URL：Google Search Central Blog - Google Search Console Help「Performance report: Advanced filtering and comparison」
正規表現フィルタ、RE2、部分一致、OR条件などの仕様を確認。
URL：Google Search Console Help - Google Search Console Help「Performance report: Dimensions and data groupings」
匿名化クエリ、クエリデータの省略と集計差を確認。
URL：Google Search Console Help - Google Search Console Help「Export data directly from a Search Console report」
画面エクスポートの最大1,000行制限を確認。
URL：Google Search Console Help - Google Search Console Help「Export Search Console data using the Search Console API」
パフォーマンスデータの1日・検索タイプ・プロパティあたり最大5万行という上限を確認。
URL：Google Search Console Help - Google Search Console Help「About bulk data export of Search Console data to BigQuery」
BigQueryへの一括エクスポート対象と匿名化クエリの扱いを確認。
URL：Google Search Console Help - Google RE2
Search Consoleが採用するRE2でlook-aroundや後方参照がサポートされないことを確認。
URL：Google RE2 - Andrei Broder, “A taxonomy of web search,” ACM SIGIR Forum, 36(2), 2002. DOI: 10.1145/792550.792552
情報・ナビゲーション・取引という検索意図分類の基礎研究として参照。
URL：ACM Digital Library - Elsa Lichtenegger, Aleksandra Urman, Aniko Hannak, “A New Taxonomy of Web Search: A User-Centered Framework for Search Intent in the AI Era,” CHI 2026. DOI: 10.1145/3772318.3791050
AI時代における検索目的分類の再検討を確認。
URL：ACM Digital Library
‹ 親記事: SEOの効果測定と改善方法｜見るべきKPI・CTR低下・検索流入減少の原因まで解説
関連記事
- › ゼロクリック検索対策とは？流入減を防ぎAI検索時代に指名・CVを増やす方法
- › SEO競合分析のやり方｜検索結果・コンテンツ・被リンク・サイト構造を比較する手順
- › コンテンツディケイの見つけ方｜検索流入が徐々に落ちる記事を特定して改善する方法
- › SEO順位急落の初動対応方法｜技術障害・アルゴリズム・競合・計測異常を切り分ける
- › 検索意図の変化を確認｜SERP・上位ページ・クエリから判断
- › SEO施策の効果検証を設計する方法｜対照ページ・観測窓・Search Consoleで寄与を測る
- › SERP機能を確認する方法｜強調表示・関連質問・画像の機会を探す
- › 検索結果のタイトル書き換えを確認｜CTR低下の原因を切り分け
- › SEOの季節変動を分析する方法｜前年同月・検索需要・順位・CTR・CVを分けて施策効果を判断
- › Google Discover流入をSearch Consoleで分析する方法｜検索流入と分けて記事寿命を追う
- › SEO記事のリライト優先順位を決める方法｜流入減・順位・CV・情報鮮度で更新順を整理
- › SEO月次レポートの作り方｜流入・順位・CV・実施内容・次月計画を1枚で社内共有
- › SEO改善の優先順位を決める｜影響度・工数・リスクで整理
- › 検索順位が上がったのに問い合わせが増えない原因の切り分け方｜検索意図・流入先・CTA・指名検索を確認
- › SEO経由の問い合わせはあるのに商談化しない原因は？リード適合・期待差・営業引き継ぎを診断
- › 表示回数は増えたのにクリックが伸びない原因は？Search Consoleで順位・検索意図・タイトル・SERPを切り分ける方法
- › SEO記事のリライト効果はいつ判断する？再クロール・順位・CTR・CVの確認手順
- › SEO記事を更新したのに古いタイトルが検索結果に出る原因｜再クロール・タイトルリンク・canonicalを確認
- › SXOとは？SEOとの違いと検索体験を改善する指標・進め方
