競合記事を分析するときは、上位ページの見出しを寄せ集めるのではなく、同じ検索語にどんな種類の回答が並び、どの論点をどの根拠で答えているかを比較します。読者がこの記事を読み終えて行うことは、競合の模倣ではありません。自サイトで答えるべき必須論点、独自に追加できる情報、別記事に任せる範囲を決めることです。
分析結果は、確認条件と根拠が追える「SERPスナップショット」として残します。順位やページ内容は変わるため、確認日と地域を記録しない一覧は後から判断材料として使えません。
目次
先に固定する調査条件
同じQueryでも地域、言語、デバイス、検索時期、検索機能によって結果が違うことがあります。分析前に次の条件を記録してください。
表は横にスクロールできます
| 記録欄 | 例・確認内容 |
|---|---|
| Query | 実際に調べる検索語。言い換え語と混ぜない |
| 地域・言語 | 読者が検索する市場 |
| 端末 | DesktopかMobileか。分かる範囲で記録 |
| 確認日 | SERPを見た日 |
| 取得方法 | 手動検索、Search Console、組織の計測手段等 |
| SERPの構成 | 公式ページ、比較記事、How-to、動画、掲示板など |
ログイン状態や個人化を完全に揃えられない場合は、その制約も残します。検索結果の一回分を市場全体の固定意図とみなさず、Search Consoleに自サイトの表示実績があれば期間とページの条件を合わせて参照します。
ページを論点へ変換する
上位ページを開き、URLとページ種別を記録した上で、各ページが読者のどの疑問に答えているかを短くまとめます。見出しをそのままコピーすると、記事の順番や言い回しだけ似たものができます。分析用の単位は見出しではなく論点です。
表は横にスクロールできます
| 論点 | 必要性 | 根拠のタイプ | 上位ページでの回答 | 自サイトで足すもの |
|---|---|---|---|---|
| 用語・前提 | 必須／条件付き | 公式・定義等 | どの範囲で説明されるか | 対象読者向けの前提 |
| 選択・比較軸 | 必須／条件付き | 仕様・条件・実測 | 何を比較しているか | 使い分けを決める条件 |
| 手順・出力 | 必須／条件付き | 画面・サンプル・一次データ | 実行できるところまであるか | 入力例、QA、失敗対応 |
| 制限・例外 | 必須／条件付き | 公式規約・提供条件 | 注意事項が明示されているか | 自分の条件での確認方法 |
「共通論点」は、複数のページが扱うという観察結果です。それだけでGoogleの順位要因や必須項目と断定しません。反対に一ページだけの具体例や更新情報も、独自価値になり得ますが、正確さと読者の必要性を別途確かめます。ページに見当たらない情報を「競合が隠している」と表現せず、確認した範囲で「今回確認したページでは見つからなかった」と記録します。
引用・データ出典
公式情報を編集部が見た内容です。Hands-on未実施の記述は本文かここに分けています。
同じ説明でも、公式仕様、独自の検証、取材、推測では読者に示せる強さが異なります。競合分析ではページごとに、主張と根拠URLを対応させます。料金や機能条件のように変わりやすい情報は、第三者記事の引用を正本扱いせず、提供元の現行情報で確認します。
自社で試していない機能を「使った」「精度を比べた」と書くことはできません。画面上で観察したこと、公式文書から確認したこと、未確認のことを別の列にします。競合ページの本文全体をAIへ貼る場合は、著作権や利用条件、社内ポリシーに沿う範囲で扱い、必要な論点の要約にとどめてください。分析目的は他者の表現を再利用することではなく、読者の課題を理解することです。
不足情報を見つけるための比較手順
-
同じQueryで表示されたページを、公式・How-to・比較・レビューなどに分類する。
-
各ページの主なReader Jobを一文にする。
-
各ページが答える論点を、ページ固有の表現ではなく共通の項目名に置き換える。
-
根拠の種類と、条件・対象読者・確認日が書かれているかを記録する。
-
自サイトの既存記事も同じ表に追加する。
-
読者が完了するために必要なのに、既存ページで答えが不足している点を探す。
-
自社が根拠を得られるかを確認し、追加する価値があればArtifactを決める。
-
不足を埋める担当が既存記事か新規記事かを、Job・結論・Next Actionで決める。
この順序なら、競合にある見出しをすべて採用せず、記事の役割に合う差だけを残せます。たとえば比較意図のSERPなのに、自社記事が用語定義だけなら不足は選択基準です。一方、技術的な設定記事に料金表がないことは、読者の作業に不要なら欠落とは限りません。
AIへ論点整理を頼む入力例
Query：＿＿＿
調査日・地域・端末：＿＿＿
確認したページURLとページ種別：＿＿＿
各ページで観察した見出し・回答の要約：＿＿＿
自サイトの既存記事・Reader Job：＿＿＿
与えた情報だけを使い、回答論点、根拠の種類、対象条件、未回答に見える箇所を表に整理してください。検索順位やページの品質を推測しないでください。本文や見出しをコピーせず、論点名に抽象化してください。根拠が読み取れない欄は「不明」としてください。最後に、自サイトのReader Jobに必要な追加Artifact候補を最大3つ挙げ、なぜ必要かを説明してください。
AIの表は観察を整理する補助です。ページを読んだ人がURLと該当箇所へ戻って確かめ、誤分類や情報の取りこぼしを直します。
「独自価値」を企画へつなぐ
不足項目を見つけても、すべて記事へ足す必要はありません。まず、その情報がReader Jobに必要か、信頼できる根拠を得られるか、自社なら具体的に示せるかを判断します。追加できる独自価値は、同条件の比較、読者の入力例と出力例、設定の分岐、失敗の診断、公式条件を使ったチェックリストなどです。実測をしていない場合は、実測値の代わりに条件の見方や再現可能な確認手順を提供します。
表は横にスクロールできます
| 追加候補 | 読者の困りごと | 自社が持つ根拠 | Artifact | 判定 |
|---|---|---|---|---|
| 比較条件の整理 | 候補の違いが分からない | 公式仕様・同じ比較軸 | 判断表 | 根拠がそろう場合のみ追加 |
| 実行の具体例 | 読み終えて始められない | 再現した入力・手順 | Input/Output | 実施していない例は例示と明記 |
| 制限の確認 | 契約・利用時に困る | 現行の公式ヘルプ | 確認Checklist | checkedAtを残す |
| 共通説明の追加 | 検索結果にあるから | 根拠なし | なし | 追加しない |
Search intentの競合を見分ける
似たテーマを扱っていても、読者のJobが異なる場合があります。「比較して選ぶ」と「設定して使う」は同一Toolを扱っていても、回答形式とNext Actionが違います。統合や役割分離を考えるときは、Reader Job、主結論、必要Artifact、次Actionを既存Article Mapと照合します。Topicが同じ、キーワードが近い、同じ製品が出るという理由だけでカニバリと判断しません。
一方、二つの記事が同じ検索者へ同じ判断基準・同じ手順・同じ次Actionを返すなら、どちらを担当ページとするか、既存側をどう補うかを検討します。URLやStatusをこの分析だけで変更せず、確かな衝突があればSEO判断候補として分離して記録します。
記入例：同じ競合群でも必要な構成は異なる
検索語が「AIで議事録を作る」なら、検索結果には製品比較、会議の設定手順、文字起こし後の要約方法が混在する可能性があります。ここでは実際にSERPを確認したと主張せず、調査表を埋める方法の例として使います。
表は横にスクロールできます
| 観察対象 | 記録例 | まだ言えないこと |
|---|---|---|
| Tool比較ページ | 料金・連携・対応言語を紹介 | その製品が最良、または精度が高い |
| How-toページ | 音声をアップロードし要約する流れ | すべての会議で同じ結果になる |
| 公式ヘルプ | 対応形式やアカウント条件 | 他社との性能差 |
| 自サイトGuide | 記事の回答と次Actionを要約 | 未確認Queryからの流入規模 |
この表の「まだ言えないこと」は重要です。比較記事に製品の料金表があっても、同一条件で操作・出力を比較していないなら、品質順位を付ける根拠にはなりません。公式ヘルプに対応言語の記載があっても、日本語会議での認識精度や話者分離の正確さまで保証するわけではありません。競合ページの主張を事実として転載するのではなく、どの根拠に基づくのか追います。
調査の粒度を決める
上位ページを全て精読できない場合は、ページ数を無理に増やさず、ページ種類の違いが分かる範囲を選びます。広告枠、動画、公式ページが混ざる検索結果では、自然検索ページと同じ一覧へ混ぜないよう区別します。Search Consoleの観測値を使う場合は、QueryとPageのフィルタ、検索タイプ、期間、地域、端末を記録します。条件を変えて比較するなら、前後で同じ設定を維持します。比較期間の端が不完全だったり、匿名Queryがあったりする場合は、その制限をメモに残し、単純な件数差を需要の変化と断定しません。
一つのページが複数のJobを扱っているときは、主要Jobと補助Jobを分けます。見出しだけでは判断できないため、導入・例・結論で一番強く解決しているものを確認します。もしページが料金から操作方法まで広く触れていても、各論点を読者が実行できる粒度で説明していなければ「完全な回答」とは記録しません。
次の記事設計へ渡すGap Brief
調査結果を次の執筆工程へ渡す際は、漠然と「競合より詳しく」と指示せず、根拠と追加物を指定します。
Reader Job：
今回確認したSERP条件と日付：
既存ページの担当範囲：
読者が完了できていない作業：
上位ページで共通する期待論点：
現行記事で不足している回答：
公式情報または自社で確認できるEvidence：
追加するArtifactとその利用方法：
今回は扱わない論点：
このBriefに書かれていない仕様や実測結果は追加しない。根拠がないGapを作らない。見出し案を出す前に、追加論点がReader Jobの完了に必要な理由を説明する。
このBriefに答えが出ない場合、構成生成を止めて調査を続けます。特に不足情報が公式情報に存在するのか、自社の独自確認が必要なのか、読者自身が自分の条件を入力すればよいのかを分けると、誤った「不足」を埋めるための不要な作業を減らせます。
完了判定と次の作業
SERP表を作成したあと、以下に答えられれば分析成果を企画へ渡せます。
-
誰が何を完了したい検索か、一文で説明できるか。
-
複数ページの共通論点と固有論点を区別できるか。
-
自サイトの既存担当ページと不足箇所を示せるか。
-
追加する情報に、確認できる根拠または実施した作業があるか。
-
追加するArtifactが読者の次の判断・作業につながるか。
-
根拠が得られない項目を「未確認」と残しているか。
答えが出ない項目は、記事を生成して埋めるのではなく調査タスクへ戻します。SERPの変化を確認する場合は同じ条件を再現し、前回の確認日と並べて観察します。順位の変化だけで原因を断定せず、Search Consoleの観測値、ページ内容、検索結果の構成を別々に扱います。
AIものさしの判断
競合分析の完了条件は、上位記事の見出しが揃うことではありません。どの回答が必要で、根拠は何で、自社が何を追加でき、既存ページのどこが担当するかを説明できる状態です。見つけた差が読者のJobに不要なら採用せず、根拠がなければ未確認のまま残します。その線引きが、競合の要約と読者に役立つ分析を分けます。
情報の根拠 / 確認した公式情報
確認日：2026-10-10
Google Search Central：ユーザーを第一に考えた有用で信頼できるコンテンツ https://developers.google.com/search/docs/fundamentals/creating-helpful-content（新しいタブで開く）
Google Search Central：SEO Starter Guide https://developers.google.com/search/docs/fundamentals/seo-starter-guide（新しいタブで開く）
Google Search Central：Search Essentials https://developers.google.com/search/docs/essentials（新しいタブで開く）
Google Search Console：検索パフォーマンスについて https://support.google.com/webmasters/answer/10268906?hl=ja（新しいタブで開く）
Google Search Console：パフォーマンスレポートの比較 https://support.google.com/webmasters/answer/17011165?hl=ja（新しいタブで開く）