SEOの記事企画では、「このキーワードの検索意図は何か」だけを調べても、実際の検索行動を十分に捉えられないことがあります。ユーザーは、一度の検索だけで意思決定するとは限らないからです。一般的な言葉で検索した後に条件を追加し、複数の候補を比較し、企業名や商品名を知ってから指名検索することもあります。
こうした検索の流れを分析するのが、複数の検索クエリを一続きの行動として扱う「クエリチェーン」です。この記事では、Google Search Console、SERP（検索結果ページ）の観察、サイト内検索、ユーザーインタビューを組み合わせ、一般検索から比較・再検索・指名検索までの遷移を調べる方法を6つのステップで解説します。
押さえておきたいのは、個人の検索履歴を無理に再現しようとしないことです。複数の証拠から繰り返し現れる遷移パターンを見つけ、記事群や内部リンクの設計へ戻すことが、この調査の目的です。以下では、データの限界、調査の進め方、記録の形式、結果を記事設計へ戻す方法、断定を避けたい場面の順に整理します。
クエリチェーン調査とは何か｜複数の検索を一つの意思決定として分析する
クエリチェーン調査では、一つのキーワードを単独で見るのではなく、同じ目的を達成するまでにユーザーがどのように問いを変えたかを分析します。クエリチェーンを記事設計へ戻す前提となる検索意図の整理、キーワード選定、クラスター設計の全体像は「キーワード戦略とは何か」で確認できます。
BtoBサービスを探しているユーザーの検索は、たとえば次のように変わります。
「勤怠管理 システム」
↓
「勤怠管理 システム 比較」
↓
「中小企業 勤怠管理 おすすめ」
↓
「A社 B社 違い」
↓
「A社 評判」
↓
「A社 料金」
この例では、最初は「選択肢を知りたい」という広い問いでした。そこから比較条件を加え、候補企業を絞り、最後は特定企業を確認する検索へ変わっています。本記事では、このような複数クエリの連続を、実務上の分析単位として「クエリチェーン」と呼びます。
検索ユーザーの問いは、最初の一般検索から比較・条件追加・指名検索へと変化します。クエリチェーンでは、この複数の検索を一つの意思決定として分析します。
ほかの分析方法との違いは、分析単位を比べると分かります。次の表は、4つの分析方法を、分析単位と、そこから分かることで整理したものです。
| 分析方法 | 主な分析単位 | 分かること |
|---|---|---|
| 単一クエリの検索意図分析 | 1つの検索語 | その検索時点で知りたいこと |
| 再検索キーワード分析 | 最初の検索と次の検索候補 | 残っている疑問や次のニーズ |
| クエリチェーン分析 | 複数クエリの連続 | 問いがどう変化し、比較・指名化するか |
| カスタマージャーニー分析 | 検索、広告、SNS、営業など複数接点 | 意思決定全体の接点 |
クエリチェーン調査の中心は、あくまで「検索語の遷移」です。SNS、営業接点、広告などを含むチャネル横断の顧客行動全体を分析するものではありません。意思決定全体の接点を見るのは、表のカスタマージャーニー分析の役割です。
なぜ1回の検索だけでなく「次の検索」を見る必要があるのか
検索の途中でユーザーがクエリを変えることは、検索行動の研究で繰り返し確認されています。ここでは3つの研究を紹介します。
Jansen、Booth、Spinkによる2009年の研究は、964,780件のWeb検索セッション、1,523,072件のクエリを分析し、クエリの再構成が検索行動の重要な要素であることを示しました。研究では、ReformulationとAssistanceに分類された変更が、確認されたクエリ変更の約45％を占めています。これは現在のGoogle利用率を表す調査ではありません。ただし、「一つの検索語だけを分析単位にすると、検索行動の途中変化を落とす」という点を理解する基礎研究として参考になります。
2020年のTamineらの研究では、単に一定時間内に行われた検索をまとめるだけでなく、「同じタスクを達成するために行われた検索」を分析単位に加えることで、クエリ変更をより理解しやすくなると報告されています。つまり、時間が近い検索を機械的につなぐだけでなく、「何を解決しようとしていたか」を合わせて見る必要があります。
2021年のWicaksonoとMoffatの研究も、多くの情報ニーズは一つのクエリで解決せず、自然に複数クエリからなる検索セッションへつながることを前提に、セッション単位で検索効果を評価しています。
これらの研究を踏まえ、SEO担当者は、「最初に検索されたキーワード」だけで記事を作るのではなく、その答えを知ったユーザーが次に何を確認するのかまで設計対象にする必要があると考えます。
クエリチェーンはSearch Consoleだけでは完全には取得できない｜組み合わせて使うデータ
クエリチェーンを調べる前に、各データで何が分かり、何が分からないかを確認しておきます。限界を知らないまま進めると、集計データから個人の行動を言い当てるような誤りにつながるためです。
Google Search Consoleでは、自社サイトをGoogle検索上で表示・クリックした検索クエリを確認できます。一方、プライバシー保護のため一部のクエリは匿名化され、すべてのクエリ行が表示されるわけではありません。
また、Search Consoleのクエリデータは集計データです。「同じ人が最初にAと検索し、次にBと検索した」という個人単位の連続履歴を確認する機能ではありません。
Google Analytics（GA4）とSearch Consoleを連携すると、検索クエリに関するSearch Console指標と、オーガニック検索から到達したランディングページでのユーザー行動を分析できます。ただし、Search Consoleのクエリディメンションと、Analyticsのユーザー行動のディメンションを、自由に組み合わせられるわけではありません。
したがって、クエリチェーンは一つのツールから取得するのではなく、複数のデータを組み合わせて分析します。次の表は、各データで確認できることと、単独では分からないことをまとめたものです。
| データ | 確認できること | 単独では分からないこと |
|---|---|---|
| Search Console | 検索クエリ、表示回数、クリック、掲載ページ | 個人ごとの検索順序 |
| SERP観察 | 関連する質問、検索結果、次の問いの候補 | 実際に同じユーザーが検索したか |
| GA4 | 流入後のページ閲覧やイベント | Google上で行ったすべての検索語 |
| サイト内検索 | 自社サイト内で入力された検索語 | サイト訪問前のGoogle検索 |
| インタビュー・検索課題調査 | 実際の検索順序とその理由 | 大量ユーザーの発生比率 |
Search Consoleだけでは個人ごとの検索順序は確認できません。複数のデータ源から得られる断片を組み合わせ、検索クエリの遷移を仮説・検証します。
どのデータも単独では不完全です。複数の証拠が同じ遷移を示しているかを見ることが、クエリチェーン調査の基本です。
クエリチェーンを調査する6ステップ
クエリチェーン調査は、検索タスクの設定から頻出パターンの抽出まで、次の6ステップで進めると整理しやすくなります。
クエリチェーン調査では、最初に検索タスクを定義します。次にSERPで仮説を作り、実際の検索順序を確認して、複数ケースから共通パターンを抽出します。
STEP1｜最初に「検索タスク」を決める
最初に決めるのはキーワードではなく、「ユーザーが何を達成しようとしているか」という検索タスクです。たとえば、次のような単位で決めます。
- SEO会社を比較して相談先を決めたい
- 勤怠管理システムを選びたい
- Googleマップの口コミを増やしたい
- 採用サイトの改善方法を知りたい
同じ時間帯に検索されたキーワードでも、目的が違えば同じチェーンには含めません。反対に、時間が多少離れていても、同じ意思決定のために続けられた検索であれば、同一タスクとして分析する価値があります。タスク単位でクエリ変更を見る重要性は、検索行動研究でも指摘されています。
STEP2｜Search Consoleで対象テーマのクエリを分類する
次にSearch Consoleから、対象テーマに関係するクエリを抽出し、次の6つに分類します。
- 一般クエリ
- 課題クエリ
- 比較クエリ
- 条件付きクエリ
- 指名クエリ
- 指名＋評判・料金・事例などの確認クエリ
Search Consoleでは、2025年3月以降のデータについて、条件を満たすサイトでは「ブランド」と「非ブランド」のクエリを分けて分析できる機能も提供されています。ただし、「非指名検索した人が後日指名検索した」とSearch Consoleだけで断定してはいけません。ここで整理するのは、チェーンの候補となるクエリ群と、各段階で表示されているURLです。
STEP3｜SERPから「次に生まれる問い」を集める
対象クエリを実際に検索し、検索結果に現れる論点を確認します。見るべきなのはキーワードそのものだけではありません。次の項目を記録します。
- 上位ページのタイトル
- 比較軸
- 「関連する質問」
- 検索結果上で強調されている条件
- 企業名・商品名
- 料金、評判、事例など次の判断材料
ここで重要なのは、SERP上の関連語を「実際に同じユーザーが次に検索した語」と断定しないことです。SERP観察で得られるのは、次検索の仮説です。
STEP4｜実際の検索順序を少数でも確認する
次に、検索ユーザー本人から検索順序を確認します。インタビューでは、たとえば次のように時系列で質問します。
「最初に何と検索しましたか」
「その検索結果を見て、次に何を知りたくなりましたか」
「候補企業の名前を知った後は何と検索しましたか」
「相談する直前には何を確認しましたか」
可能であれば、記憶だけに頼らず、本人の同意を得たうえで検索履歴や画面を見ながら振り返る方法が有効です。インタビューはクエリチェーン分析そのものではなく、「集計データから作った遷移仮説が実際の行動と合っているか」を確認する補助データとして使います。
STEP5｜クエリ間の変化を分類する
集めた検索を、単なるキーワード一覧ではなく「前の検索から何が変わったか」で分類します。実務では、次の6種類から始めると整理しやすくなります。
| 遷移タイプ | 例 | ユーザー側で起きていること |
|---|---|---|
| 具体化 | SEO → SEO 内部対策 | 条件を絞っている |
| 比較化 | SEO会社 → SEO会社 比較 | 選択肢を比べ始めている |
| 条件追加 | SEO会社 → SEO会社 BtoB | 自分に合う条件を加えている |
| 言い換え | 検索順位 改善 → SEO 順位 上げ方 | 表現を変えて探している |
| 指名化 | SEO会社 比較 → A社 | 候補企業を確認している |
| 検証化 | A社 → A社 評判 | 候補を選ぶ前に不安を確認している |
表の「例」は、前の検索から次の検索への変わり方を示しています。集めた検索を1件ずつ見比べ、「ユーザー側で起きていること」の列に近いものを当てはめて分類します。
クエリ変更を「追加・削除・言い換え」といった変化から分析する考え方は、検索行動研究でも継続して扱われています。
STEP6｜複数チェーンを重ねて頻出パターンを探す
最後に、一人の検索履歴をそのまま「典型的なユーザー行動」とみなさず、複数ケースを並べます。たとえば、次の遷移が複数ケースで確認できれば、記事群として対応する価値が高くなります。
一般検索
↓
方法検索
↓
比較検索
↓
指名検索
↓
評判確認
一方、一人だけが行った特殊な検索は、例外として記録しておきます。クエリチェーン調査の目的は、きれいな一本道を作ることではなく、「繰り返し起きる遷移」と「例外的な遷移」を分けることです。
クエリチェーンは1行1検索で記録すると分析しやすい
調査データは、1行に1回の検索を記録する形式で整理できます。次の表は記録の形式を示す例で、同じChain IDの検索が順番に並び、各行に段階、遷移、データ源、関連URLが付きます。遷移の列には、STEP5の6種類に加え、最初の検索を示す「起点」を使います。
| Chain ID | 順番 | クエリ | 段階 | 遷移 | データ源 | 関連URL |
|---|---|---|---|---|---|---|
| C001 | 1 | 勤怠管理 システム | 探索 | 起点 | インタビュー | 記事A |
| C001 | 2 | 勤怠管理 システム 比較 | 比較 | 比較化 | インタビュー | 記事B |
| C001 | 3 | A社 B社 違い | 候補絞り込み | 指名化 | インタビュー | 比較ページ |
| C001 | 4 | A社 評判 | 検証 | 検証化 | インタビュー | 事例・FAQ |
| C001 | 5 | A社 料金 | 最終確認 | 条件追加 | インタビュー | 料金ページ |
さらに、次の項目を列として追加すると、記録をそのままコンテンツ設計へ移せます。
- 確認できた事実
- 仮説
- 根拠の強さ
- 現在担当しているURL
- URLが存在しないか
- 次に案内すべきページ
分析結果は、記事群・内部リンク・担当URLの設計へ戻す
調査結果は、キーワード一覧を作って終わりではありません。最終的に決めるのは「どの問いを、どのURLが担当するか」です。判断の基本は次の表のとおりです。
| 状態 | 基本対応 |
|---|---|
| 同じ検索意図の具体化 | 既存記事のH2・H3で対応 |
| 独立した比較ニーズ | 比較記事を用意 |
| 次の大きな意思決定 | クラスター記事として独立 |
| 指名後の不安確認 | FAQ、事例、料金、サービスページで対応 |
| 複数記事に同じ役割がある | 担当URLを整理・統合 |
| 次の問いに対応する記事がない | 新規記事候補にする |
クエリチェーン分析は、検索語を並べて終わりではありません。各段階の問いを担当するURLを決め、ユーザーの次の疑問へ内部リンクで案内します。
特に内部リンクは、「SEO上関連している記事」だけで決めるのではなく、読者が次に検索しそうな問いへ進めるように設計します。たとえば、次の検索遷移が確認できたとします。
「SEO会社の選び方」
↓
「SEO会社の費用」
↓
「SEO会社を比較するときのチェック項目」
↓
「自社に合う支援範囲の判断方法」
この場合は、同じ順序で記事間を内部リンクでつなぐ設計が考えられます。再検索キーワードを次の記事企画や内部リンクへ利用する考え方自体は、既存のSEO実務でも使われています。クエリチェーン分析では、さらに前後の検索をつなぎ、「どのURLから、どのURLへ渡すべきか」まで決めます。
指名検索が増えても「一般検索から指名化した」とすぐ断定しない
クエリチェーン分析で特に注意したいのが指名検索です。Search Consoleでブランド系クエリと非ブランド系クエリを分けて確認できるサイトでは、次の項目を比較できます。
- 一般検索の表示・クリック
- 指名検索の表示・クリック
- 対応するページ
- 時系列の変化
ただし、一般検索と指名検索の両方が増えたからといって、「一般検索したユーザーが、その記事を読んで指名検索した」とは証明できません。広告、SNS、営業、口コミ、展示会など、別の接点でブランド名を知った可能性もあるからです。そのため、次の順番で判断します。
「集計データ上で一般検索と指名検索の両方が増えている」
↓
「同じ遷移が起きているという仮説を立てる」
↓
「ユーザー調査や問い合わせ時のヒアリングなどで確認する」
確認が取れるまでは、遷移が起きていると決めず、仮説として扱います。
クエリチェーン調査で避けたい5つの誤り
クエリチェーンを分析するときは、次の5点に注意してください。
- SERPの関連語を実際の検索履歴だとみなさない
- Search Consoleの集計クエリを個人単位で無理につなげない
- 時間が近いだけの別目的検索を同じチェーンへ入れない
- 一人の検索行動を全ユーザーの代表にしない
- すべての検索意図を一つの記事へ詰め込まない
2つ目の誤りに関わる点として、Search Consoleでは、一部クエリがプライバシー保護のため匿名化され、表示される行にも制約があります。クエリチェーンは「完全なログの復元」ではなく、利用できるデータから再現性の高い遷移仮説を作る分析だと捉えてください。
最初は重要テーマ1つからクエリチェーンを作る
すべてのキーワードを一度に分析する必要はありません。まずは、問い合わせや売上との関係が深いテーマを一つ選び、次の順で進めます。
- Search Consoleから関連クエリを抽出する
- 一般・比較・指名などに分類する
- SERPから次の問いの仮説を作る
- 少数のユーザー調査で実際の検索順序を確認する
- 複数ケースで共通する遷移を探す
- 各検索意図の担当URLを決める
- 足りない記事と内部リンクを追加する
この7つの作業のうち、1〜5は、ここまでの6ステップのSTEP2〜STEP4とSTEP6を短くまとめたものです。6と7は、前の節で説明した、結果を担当URLと内部リンクの設計へ戻す作業にあたります。
補助データとして、サイト内検索も使えます。Google Analyticsでは、自社サイトにサイト内検索がある場合、view_search_resultsイベントとsearch_termを使って、訪問後にユーザーが何を検索したかを分析できます。Googleはサイト内検索データをコンテンツやナビゲーション改善に利用できると案内しています。
外部検索の完全なチェーンではありませんが、「検索流入後にサイト内で何を探したか」という補助データとして利用できます。
まとめ
検索行動のクエリチェーン調査は、一つの検索語だけを見るのではなく、一般検索、比較、再検索、指名検索など、ユーザーが目的を達成するまでに問いをどう変えたかを分析する方法です。ただし、Search Consoleだけで個人単位の検索チェーンを取得することはできません。
そこで、Search Consoleの集計データ、SERP観察、GA4やサイト内検索、ユーザーインタビューなどを組み合わせ、次の3点まで整理します。
「どの遷移が実際に繰り返されているか」
「各段階をどのURLが担当すべきか」
「次の問いへどの記事を内部リンクすべきか」
単一キーワードを起点に記事を増やすのではなく、ユーザーが次に何を調べるかを起点に記事群を設計すると、検索行動に沿ったコンテンツ構造を作りやすくなります。最初の一歩は、問い合わせや売上との関係が深いテーマを一つ選び、Search Consoleから関連クエリを抽出して分類することです。
参考文献・データ元
この記事で参照した情報を確認できます。
- Google Search Console Help「Performance report (Search results): Dimensions and data groupings」：Search Consoleのクエリデータ、匿名化、ブランド・非ブランド分類の仕様確認に使用。
- Google Search Console Help「Performance report (Search results): Common tasks and use cases」：ブランド・非ブランドクエリの分析方法確認に使用。
- Google Analytics Help「Connect Search Console to Google Analytics」：Search ConsoleとGA4連携時のデータ範囲と制約確認に使用。
- Google Analytics「Events / view_search_results」：サイト内検索イベントとsearch_termの仕様確認に使用。
- Jansen, B. J., Booth, D. L., & Spink, A. (2009). “Patterns of query reformulation during Web searching.” Journal of the American Society for Information Science and Technology, 60(7), 1358–1371. DOI: 10.1002/asi.21071。クエリ再構成の大規模検索ログ研究として使用。
- Tamine, L., Lovón-Melgarejo, J., & Pinel-Sauvagnat, K. (2020). “What Can Task Teach Us About Query Reformulations?” ECIR 2020, pp.636–650. DOI: 10.1007/978-3-030-45439-5_42。時間単位とタスク単位の検索セッション分析の比較に使用。
- Wicaksono, A. F., & Moffat, A. (2021). “Modeling search and session effectiveness.” Information Processing & Management, 58(4), 102601. DOI: 10.1016/j.ipm.2021.102601。複数クエリからなる検索セッションの研究として使用。
‹ 親記事: キーワード戦略とは何か｜検索意図の基本から選定プロセス、クラスター設計までを整理する
