ロングテールキーワードの見つけ方は？自分のクエリ表で問いごとに束ねる

ロングテールキーワードには何件以下という境目が無いので、自分のブログのロングテールは、サーチコンソールのクエリ表で表示の少ない側の語として見つけます。

キーワード選定の解説で「ビッグキーワードは強いサイトに勝てないので、ロングテールを狙おう」と読んだものの、月間何件以下がロングテールなのかは記事ごとに違い、自分のブログではどの語がそれに当たるのか分からない人に向けて書いています。

読み終えると、自分のクエリ表からテール側の語を拾い、同じ問いの語を束ねて、束の合計を見られるようになります。根拠にしたのは、言葉の出どころの Wired の記事(2004年)と、Search Console ヘルプ3ページ・Google 検索セントラル ブログ1本で、2026年10月20日に原文で確かめました。束ね方は私のやり方で、Google が示している基準ではありません。

ロングテールの境目は何件？決まった数字は無い

ロングテールキーワードの意味と、語の数で決まる分類ではないことは、キーワード選定のやり方は？ブログは表示の有無で使うデータを変えるの「ロングテールキーワードとは」の節に書きました。この記事は、自分のブログでそれがどの語なのかを見つけるほうを扱います。

何件以下ならロングテール、という決まった数字はありません。「月間◯件以下」と書く記事はありますが、それぞれの書き手が置いた目安です。ビッグ・ミドル・スモールの区分にも境目の件数が無いことはミドルキーワードとは？境目の件数は無いので、自分の表示回数で分けるに書きました。

元の記事でも、テールの始まりは主に実店舗の在庫と比べて説明されていた(私の読み)

言葉の出どころは、Chris Anderson が2004年10月に Wired に書いた「The Long Tail」という記事です(Wired「The Long Tail」)。この記事が主に扱っているのは音楽・映画・本の売れ方で、検索語の話ではありません。私がテキストにして確かめた本文には、search も keyword も一度も出てきませんでした。この考え方を誰がいつ検索語に当てはめたのかは、今回は確かめていません。

記事を読むと、テールの始まりも決まった数字ではありませんでした。私の要約で書くと、音楽配信では、平均的な実店舗のレコード店の在庫くらいにあたる上位4万曲より下になると、実店舗の売上は途切れるのに、配信の需要はその先も続いていて、そこを「ロングテール」と呼んでいます。本の例でも、米国の書店チェーン Barnes & Noble の平均的な店の在庫が13万点で、Amazon の本の売上の半分を超える部分が、上位13万点の外から来ている、と書いています。

私はこれを、線を引いていたのは主に「実店舗の棚にどれだけ置けるか」という比べる相手の大きさだ、と読みました。主な例では、曲なら4万、本なら13万と、分野ごとに違います。検索語に当てはめても、どこからがテールかは、何と比べるかで変わると考えています。個人ブログなら、比べる相手は自分のブログのクエリです。

私が読んだ Google のページ4つでは、件数の基準は見当たらない

Google のページも確かめました。読んだのは、Search Console ヘルプのデータの不一致に関するトラブルシューティング、高度なフィルタリングと比較、検索パフォーマンス レポートの概要と基本設定の3ページと、Google 検索セントラル ブログのSearch Console でのパフォーマンス データのフィルタリングと制限の詳細の、合わせて4つです。日本語版と英語版の両方を「ロングテール」と long tail で探しました。

日本語版で「ロングテール」が出てきたのは、トラブルシューティングのヘルプの次の1か所だけです。

表には 1,000 行までしか表示されないため、頻度の低い行やロングテール行が表から省略されることがあります
— Search Console ヘルプ「パフォーマンス レポート（検索結果）: データの不一致に関するトラブルシューティング」

原文はこのあと、表から省略された行もグラフの合計には含まれる、と続きます。英語版は "some rare or long-tail rows" です。ほかに、高度なフィルタリングのヘルプの英語版に、比較したときに値が非常にまれな側のグループについて "a very long tail of results" という言い方が1か所ありました(日本語版は「非常に長い結果の末尾」と訳しています)。どちらも、まれな行の扱いを説明するための言葉で、何件以下をロングテールと呼ぶかは書かれていません。この4ページの範囲では、ロングテールの件数の基準も、ロングテールキーワードの定義も見当たりませんでした。

自分のブログのロングテールは、クエリ表で表示の少ない側に並ぶ

境目が「比べる相手」で決まるなら、個人ブログでいちばん確かな比べる相手は、自分の Search Console のクエリです。そこに並んでいるのは、自分のページが実際に検索結果に載った語なので、他人の件数を当てはめるより、自分のブログにとってのテール側がそのまま見えます。

1. Search Console の「検索パフォーマンス」を開く。期間は既定の過去3か月のままでかまいません
2. 表の「クエリ」タブを開き、表示回数の多い順に並べる。平均掲載順位の列も出しておく
3. 上の数行の大きな語から下へ行くと、表示回数の小さい語が続く。そのうち、上位で表示されていても回数が小さい語が、自分のブログのテール側です

手順3で順位も見るのは、表示回数は検索された回数ではないからです。表示回数は自分のリンクが検索結果に載った回数なので、順位が低くて検索結果の後ろのほうにしか出ていない語は、その語がよく検索されていても回数が小さく出ます。表の下のほうには、そういう語も混ざります。表示回数と検索回数の違いは検索ボリュームの調べ方は？キーワードプランナーの数字は4条件で読むの後半に書きました。私は、1ページ目(10位まで)で表示されているのに回数が小さい語をテール側と見て、それより後ろの語は、順位のせいで小さいだけかもしれないので保留(テール側かどうかを決めない)にしています。11位より後ろの語に手を入れるかどうかは、キーワード選定の記事の掲載順位の話で決めます。

回数の線をはっきり引きたいなら、ミドルキーワードの記事で置いた目安をそのまま使えます。いちばん多い語の表示回数の100分の1未満を「自分のスモール」、つまりテール側と見る線です。公式の基準ではなく、自分のブログの中で比べるための目安です。架空の家計簿アプリのレビューブログ(期間3か月)で見ると、次のようになります。

※ 説明のための架空の例です。上から7語はミドルキーワードの記事の例と同じ値で、表示の少ない語を5つ足しました。

いちばん多い語が1,200回なので、12回未満が表示の少ない側です。そのうち10位までで表示されている6語をテール側と見て、「家計簿アプリ 銀行連携 できない」は10位より後ろなので、テール側かどうかを決めない保留にしました。

ただし、表に見えているテールは、実際のテールの一部です。上で引いたとおり、表は1,000行までで、まれな行は省略されることがあります。検索がごく少ない語はプライバシー保護のためにクエリの表から除かれてもいます。その仕組みと、細すぎる語は書いても結果を確かめにくいことは、キーワード選定の記事の「検索がごく少ない語は、書いても結果を確かめられない」に書きました。

ロングテールは1語ずつではなく、問いで束ねて見る

テール側の語は、1語ずつ見ると数回の表示しかありません。1語ずつなら、ミドルキーワードの記事では後回しにし、キーワード選定の記事でも多い順に並べると下に来る語です。私はその語を、束ねて1つの問いとして見ています。

理由は、1語ずつでは、同じ問いが散らばって見えないからです。表のクエリは完全一致なので、語順や言い回しが少し違うだけでも別の行に分かれます(キーワードとクエリの違いは？)。上の例では、「家計簿アプリ 夫婦 共有」「夫婦 家計簿 共有 方法」「家計簿 夫婦 別々 アプリ」「家計簿アプリ 夫婦 2台」の4語は、表ではばらばらの行ですが、言い方は違っても「夫婦で家計簿を共有したい」という同じ問いです。

1語ずつは最大8回でも、束ねると21回で、同じ問いでこれだけ表示されていることが見えてきます。この合計は、束の大きさを見るためのもので、何回以上なら手を付けるという基準ではありません。語を問いの形に直すやり方は、検索意図のずれはどう見分ける？の「表示されている検索語を、問いに直して並べる」と同じです。

束ねるときは、クエリのフィルタを使う

束の合計は、Search Console のフィルタで出せます。高度なフィルタリングと比較のヘルプによると、[+ フィルタを追加] から [クエリ] を選び、[次を含むクエリ] に共通する文字列を入れて [適用] を押すと、その文字列を含むクエリだけに絞られます。大文字と小文字は区別されませんが、それ以外はスペースも含めて書いたとおりに当てはめられます。上の例の4語はどれも「夫婦」を含むので、[次を含むクエリ] に「夫婦」と入れれば足ります。

同じ問いなのに共通の文字列が無い語も入れたいとき、たとえば「夫婦」の代わりに「パートナー」と書いた語もまとめたいときは、[カスタム（正規表現）] を選び、「(夫婦|パートナー)」のように縦線で区切って丸かっこで囲むと、どちらかを含む語をまとめて絞れます。

絞ったあとに「ページ」のタブへ切り替えると、その束がどの記事で表示されているかが分かります。クエリとページはエクスポートしたCSVではつながらないので、この確かめ方は画面での作業になります(サーチコンソールのクエリとページの違い)。

注意が1つあります。トラブルシューティングのヘルプには、次の1文があります。

表のクエリタブでは、匿名化された結果（非常にまれな結果）は表から除外されますが、クエリフィルタが適用されていない限り、グラフの合計数に含まれます。
— Search Console ヘルプ「パフォーマンス レポート（検索結果）: データの不一致に関するトラブルシューティング」

クエリで絞った時点で、匿名化されたクエリのぶんは合計に入りません。束の合計は、その問いで実際に表示された回数のうち、見えている語のぶんだと思って読んでください。

束ねたロングテールは、どこへ持っていく？

行き先は、ブログのネタ切れは？サーチコンソールのずれた語から次の記事を探すの表と同じ線で決めます。束が表示されている記事のタイトルのまま1節足して答えられるなら既存記事に足し、記事の問いを変えないと答えられないなら新しい記事の候補です。

束ねたときだけ気をつけることが2つあります。ページのタブで、束が自分の2本以上の記事に分かれて表示されていたら、行き先を決める前に、同じ問いに自分の記事が重なっていないかをキーワードカニバリゼーションの確認方法で確かめます。束ねても表示がほとんど無いなら、まだ決めず、期間を長めに取って見直します。

よくある質問

月間の検索ボリュームが何件以下なら、ロングテールですか

決まった件数はありません。私が読んだ Search Console のヘルプなど4ページにも件数の基準は見当たらず、元の Wired の記事でも、テールの始まりは主に実店舗の在庫の量と比べて説明されていました(私の読み)。件数で見たいなら、自分のクエリ表の中で、いちばん多い語と比べてください。キーワードプランナーの検索ボリュームの読み方は検索ボリュームの調べ方は？にまとめました。

クエリ表で表示回数が少ない語は、全部ロングテールですか

全部とは言えません。表示回数は自分のリンクが検索結果に載った回数なので、順位が低いだけで、検索はよくされている語も回数が小さく出ます。平均掲載順位も見て、1ページ目(10位まで)で表示されていても回数が小さい語をテール側と見てください(私の見方)。

ロングテールキーワードだけを狙えば、アクセスは増えますか

増えるとは限りません。1語あたりの検索は少ないので、1語だけを狙って書いても表示は小さく、細すぎる語は Search Console の表にも出てこないことがあり、結果を確かめにくくなります。私は、1語ではなく同じ問いの束で見て、束の合計で表示されている問いから手を付けています。

ブログを始めたばかりで、クエリ表に語がほとんど無いときは、どうすればいいですか

その段階では、この記事の見つけ方は使えません。クエリ表に語が並ぶまでは、読者の言葉・サジェスト・実際の検索結果から語を選ぶことになり、その手順はキーワード選定の記事の前半にまとめています。表に語が並び始めたら、この記事のやり方で自分のテール側を見てください。

まとめ

• ロングテールキーワードに、何件以下という決まった境目は無い。元の Wired の記事(2004年)でも、テールの始まりは主に実店舗の在庫の量と比べて説明されていた(私の読み)。私が読んだ Search Console のヘルプなど4ページにも、件数の基準は見当たらなかった
• 自分のブログのロングテールは、Search Console のクエリを表示回数の多い順に並べたときの、表示の少ない側(テール側)の語。線を引くなら、いちばん多い語の100分の1未満(ミドルキーワードの記事の目安で、公式の基準ではない)
• 表示回数は検索された回数ではないので、平均掲載順位も見る。1ページ目(10位まで)で表示されていても回数が小さい語をテール側と見て、それより後ろの語はテール側かどうかを決めない(保留。私の見方)
• 表に見えているテールは一部。表は1,000行までで、検索がごく少ない語は除かれることもある
• 1語ずつでは同じ問いが散らばって見えないので、同じ問いの語をクエリのフィルタ([次を含むクエリ] や正規表現)で束ね、束の合計で見る(私のやり方)。クエリで絞ると、匿名化されたクエリのぶんは合計に入らない

この記事で確かめた Google のページは4つです。Search Console ヘルプの「データの不一致に関するトラブルシューティング」「高度なフィルタリングと比較」「検索パフォーマンス レポート（検索結果）: 概要と基本設定」と、Google 検索セントラル ブログの「Search Console でのパフォーマンス データのフィルタリングと制限の詳細」で、2026年10月20日に日本語版と英語版の本文を取得し、引用は日本語版の原文と照合しました。Search Console ヘルプの日本語版には AI 翻訳を含む場合があるという注記があるので、細かい条件は英語版もあわせて確かめてください。Wired の記事(英語)も同じ日に本文を取得して読み、記事内の説明は私の要約です。

以下は自作の有料ツールの紹介で、宣伝にあたります。

束ねた語を既存記事に足すと決めたら、リライトレーダーにその記事のURLを入れて、見出しや本文の直す点を見てみてください。記事が何本もあるなら、Search Consoleのデータを入れると、直す順番まで出ます。URLの診断で送るのは入れたURLだけで、本文は保存しません。Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位4.0〜20.5位のページから手を入れる候補を順に並べます。判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで3記事分(候補が4件以上のときだけご案内)、生成の期限は購入から90日間で、月額課金はありません。CSVはブラウザの中で読み、送るのは候補ページのURLと、診断カードを出すときの狙いキーワード・順位・表示回数・CTRだけです。

⚠️ URLの診断は本文だけを読み、順位・表示回数・CTRは使いません(それらを使うのはSearch Consoleのデータを入れたときです)。クエリの表は読まず、ロングテールの語を探したり束ねたりもしません。