検索されている「質問」に、記事は答えられていますか？Search ConsoleとClaude Codeで点検してみました

きっかけは、住 太陽さん（@motoharusumi）のXの投稿でした。

これはマジですごいのでやってみて。あなたのサイトがどんな「質問文」で表示されてるかわかります。 サーチコンソールの検索パフォーマンスレポートで「フィルタを追加」→「検索キーワード」→「カスタム（正規表現）」を選んで、【これからリプに貼る文字列】を入力して「適用」ボタンを押す。 https://t.co/bbUhcFV0HN

— 住 太陽 (@motoharusumi) November 3, 2026

（埋め込みが表示されない場合は、こちらの投稿をご覧ください）

Search Consoleに、ある正規表現を入れるだけで、自社のサイトが「どんな質問文で表示されているか」が見えるという内容です。

正直なところ、読んですぐに、リクトのサイトで試したくなりました。ただ、画面で眺めて終わりにはしたくありません。見つけた質問に自社の記事が答えているかまで確かめるため、Claude CodeでSearch ConsoleのAPIを使って進めることにしました。

住さんの手法は「日本語14文字以上のクエリ」を抜き出すこと

住さんの手法は、とてもシンプルです。

Search Consoleの検索パフォーマンスで、クエリに「日本語が14文字以上含まれるもの」というフィルタをかけます。長いクエリには、質問の形をした検索が、多く混ざっているというわけです。住さんは、こうしたクエリを、AI要約（AIによる概要）で狙うクエリとして紹介していました。

質問を調べて、記事に答えを足すところまで、Claude Codeに任せました

リクトでやりたかったのは、次の3つです。

• その質問を、どの記事が受けているか調べる
• 記事が、その質問に答えているか確かめる
• 足りなければ、書き足す

件数が多いことと、毎月くり返したいことから、Search ConsoleのAPIで取ることにしました。Claude Codeに、Pythonのスクリプトを書いてもらいます。

Search Consoleの閲覧権限を持った専用のアカウント（サービスアカウント）を用意すれば、パスワードを画面に入力せずに、データを取れます。

まず、Search ConsoleのAPIで質問文を取る

APIでは、住さんと同じ正規表現を指定して、過去90日分のクエリを、表示されたページごとに取りました。

結果は、リクトのサイトで412件でした。実際に出てきた質問の一部をご紹介します。

検索された質問	表示回数	平均順位	分類（後述）
サイト高速化 予算 決め方の対策は何でしょうか？	76回	7.8位	A
最新のgoogleのai要約は他と比べてどう？	73回	6.2位	A
ホームページ リニューアル ドメイン そのまま	92回	74.5位	B
パソコンで写真を圧縮する方法	71回	7.3位	C

※ リクトのSearch Consoleより（過去90日）。

語尾で絞らず、412件を全件読んで4つに分けました

最初は、「〜ですか」「教えて」といった語尾で、質問文を絞ろうと考えました。機械的に絞れるので、手間もかかりません。

それでもあえて、語尾では絞らず、412件を全件読んで分けることにしました。理由は2つあります。

1. 語尾のない質問を、取りこぼすから

たとえば「ホームページ リニューアル ドメイン そのまま」は、語尾がありません。それでも、「ドメインはそのままで大丈夫か」と知りたい人の検索です。実際、こうした単語型（下の表のB）は、語尾のある質問文（A）の約3.6倍（2,617回と723回）表示されていました。語尾で絞っていたら、表示の大半を見落とすところでした。

2. 質問の形でも、お客様の質問とは限らないから

「パソコンで写真を圧縮する方法」は、立派な質問の形です。ただ、リクトの事業とは関係の薄い検索でした。語尾だけでは、「自社のお客様が知りたいことか」は分かりません。

幸い、412件は全件を読める量でした。そこで、Claude Codeに全件を読んでもらい、次の4つに分けました。

分類	中身	件数
A 商売に近い質問文	事業に関係があり、問いの形になっているもの	80件
B 商売に近い単語型	事業に関係があり、語尾はないが知りたいことがあるもの	89件
C 商売と無関係	事業と関係の薄い話題（キャッシュの消し方など）	197件
D ノイズ	他社名の検索、検索の演算子（site:など）、文字化けなど	46件

分類のたたき台はAIが作り、私が内容を見て直しています。AIは工程を短くしてくれますが、「これは自社のお客様の質問か」の判断は、人が行うべきだと考えるからです。

質問文のA（80件）は、表示が723回あって、クリックは0でした。順位が高くても、押してもらえていません。

理由のひとつは、AI要約（AIによる概要）かもしれません。検索結果の上に答えが表示されて、そこで満足した人は、記事を開かないからです（推測です）。米国のPew Research Centerの調査では、AI要約が出た検索のクリックは8%で、出ない検索の15%より少なくなっていました（出典：Pew Research Center、2025年3月の閲覧データ）。

そこで、成果の見立てを変えました。「クリックが増えたか」ではなく、「表示されている質問に、記事の中で答えが載っているか」を見ることにしました。

もう一歩進めて、「誰が調べているか」と「ページは誰向けか」で見ました

分類を進めるうちに、もうひとつ気づいたことがあります。質問が多く検索されていても、その人がお客様とは限りません。語尾や言葉だけでは、誰が調べているかまでは分かりません。

そこで、2つの軸を足しました。

• 軸1：質問を調べる人 …… お客様（見込み客）か、そうでない人かです。区分はサイトごとに決めます。
• 軸2：着地ページが狙う人 …… 質問を受けているページが、見込み客向けか、一般向けか。ページの見出し・本文・相談への導線から判断します。

軸1の区分の例です。リクトなら「ホームページの発注を考える会社」と「個人・学習者・同業」、外壁塗装の会社なら「施主」と「同業者・DIYの人」です。

この2つを組み合わせると、次の4通りに分かれます。

調べる人	ページ	意味
お客様	お客様向け	一致。守って伸ばす
お客様	一般向け	ミスマッチ。改善の最優先
お客様でない人	お客様向け	お客様でない人が来ている
お客様でない人	一般向け	一致。Cのまま

大切なのは、2つめの「お客様なのに、一般向けのページに着地している」ものです。質問は検索されているのに、受け皿のページが、その人向けに作られていません。記事の改善で、一番効果が出やすい場所だと考えました。

この判定は、Claude Codeのスキル（決まった作業の手順書）に組み込み、別のサイトで試しました。ページの判定は、まだ精度を上げている途中です。

質問を受けているページを調べて、記事を読みました

次に、Aの質問を、受けているページごとにまとめました。上位は、表示速度の高速化の記事、ホームページ作成ソフトの比較記事、AI要約とAIモードの違いの記事でした。

記事は、Claude Codeに本文を読んでもらい、質問に答えを足す案を作りました。決めたルールは3つです。

• 答えは、記事に書いてある内容だけで作る
• 記事に材料がない質問は、作らない
• 材料がないものは、私への質問にして、まとめて確認する

たとえば、表示速度の記事には「ホームページの表示速度は、どうやって調べられますか？」「サイトを速くする作業には、どのくらいかかりますか？」といった質問が、検索されていました。

金額や作業時間のように、記事に書いていないことは、社内の作業記録をもとに、私が答えを決めています。実績のある事例は、お客様が特定されないよう、匿名にしました。

公式ページで確かめたら、古い情報が見つかりました

Q&Aを足すつもりが、根拠を公式ページで確かめるうちに、記事の古い情報が見つかりました。

表示速度の記事は、2022年に書いたものでした。確認して分かったのは、次のようなことです。

• 紹介していた測定ツール「Test My Site」は、Googleの公式の案内で、サービス終了とされていた
• 「Lighthouse」の説明が、実際の役割と違っていた
• サーバーの説明は、「最も評判がいい」と言い切っていたが、裏付けがなかった
• 「CSSやJavaScriptの数を減らす」という説明が、いまの通信方式（HTTP/2）を踏まえていなかった

Test My Siteの終了には、正直、気づいていませんでした。

AI要約の記事には、「FAQの充実や構造化データの設定が重要」と書いていました。ところが、Googleの公式ページ（Search Central）は、AI要約に載るために「特別な設定は不要」と説明しています。こちらも、公式に合わせて書き直しました。

質問を拾う作業が、そのまま、古い記事の点検になりました。

WordPressのREST APIで、記事に反映しました

記事への反映は、WordPressのREST APIを使いました。Claude Codeから、いまの本文を取り込み、変更後の全文を作って、更新する手順です。

公開済みの記事は、いきなり書き換えません。まず変更前の本文をバックアップとして保存し、変更後の全文を確認してから、公開中の記事に反映しました。確認は、ローカルのMarkdownやWordでもできます。今回は、WordPressの別の下書きにも、変更後の全文を作りました。

この日は、表示速度の記事にQ&Aを10問と、古い情報の訂正を反映しました。AI要約の記事にも、Q&Aを4問と、本文の書き換えを反映しています。

やってみて分かった3つのこと

1. 語尾で絞らず、全件を読む

数百件なら全件を読める量なので、語尾の形に頼らず、お客様の知りたいことを自分の目で拾えます。

2. クリックではなく、「質問に答えられているか」で見る

数字の増減を追うより、答えが記事に載っているかを確かめるほうが、改善につながりました。

3. 公式ページの確認を省かない

AIが作った答えを、そのまま載せるのは危険です。公式ページで確かめたことで、記事の古い情報にも気づけました。

まとめ

住さんの手法は、画面で質問文を拾うだけでも、十分に役立ちます。それをClaude Codeと、Search ConsoleのAPI、WordPressのREST APIにつなげると、「拾う→答えを足す→反映する」までを、くり返せる作業にできました。

今回の数字は、リクトのサイトのものです。検索のされ方は、サイトによって違うかもしれません。

「自社のサイトは、どんな質問で表示されているのだろう」と気になった方は、まず住さんの方法を、Search Consoleの画面で試してみてください。

記事への反映や、サイトの点検でお困りの場合は、ホームページ診断（毎月先着2社まで無料）や、お問い合わせもお待ちしています。