Googleアナリティクス（GA4）を開くと、表示回数や利用者数、滞在に関する時間など、多くの数字が並びます。数字が増えたか減ったかは確認できても、「それで何を直せばよいのか」が分からず、画面を閉じてしまうことはないでしょうか。
アクセス解析の価値は、数字を眺めること自体にはありません。数字から違和感を見つけ、なぜそうなったのかという仮説を立て、別のデータや実際のページで確かめ、小さな改善を一つ実施し、結果をもう一度見ることにあります。数字は答えではなく、次に確認することを考える材料です。
この記事では、GA4の基本的な指標を押さえたうえで、Google Search Consoleや実ページと照合しながら「次に何を疑い、何を確認するか」を考える順番を説明します。
最初に「何を知りたいか」を一つ決める
最初からすべてのレポートを確認する必要はありません。先に、今回知りたいことを一文にします。
検索結果には出ているのに、なぜ記事へ来てもらえていないのか
記事へ来た人は、問い合わせ案内まで読めていそうか
先月と比べて増えた流入は、外部の読者によるものか
問いが決まると、見る数字を絞れます。検索結果に出る前後を知りたいならSearch Console、サイトへ来た後の閲覧や流入元を知りたいならGA4が主な確認先です。期間を比べる時は、平日と休日、繁忙期と通常期などの条件が大きく違わないかも確認します。
「アクセスが少ない」のような広い問いのままだと、見る数字も改善案も増えすぎます。まず一ページ、一つの期間、一つの困りごとに絞ると、次の確認へ進みやすくなります。
Search Consoleは検索結果まで、GA4は訪問後を見る
Search ConsoleとGA4は、同じ数字を見る道具ではありません。役割を分けると、数字の意味を混同しにくくなります。
| 知りたいこと | 主に見る場所 | 数字の例 | 数字だけでは分からないこと |
|---|---|---|---|
| Google検索でページが見られたか | Search Console | 表示回数、クリック、CTR、平均掲載順位 | 表示が少ない本当の原因、クリックしなかった人の気持ち |
| どこから訪問したか | GA4の集客レポート | セッション、参照元、チャネル | その流入が社外の見込み客か、内部・テストアクセスか |
| 訪問後に何を見たか | GA4のエンゲージメント関連レポート | 表示回数、利用者数、平均エンゲージメント時間 | 読者が内容を理解したか、満足したか |
| 重要な行動が記録されたか | GA4のキーイベント | 問い合わせ送信などの記録数 | 記録されない原因が需要不足か、計測設定か |
Search ConsoleのCTRは、クリック数を表示回数で割った割合です。平均掲載順位は、個々の検索で常に同じ順位に出ていたという意味ではありません。場所や端末などによって見え方が変わるため、順位の数字一つだけで良し悪しを決めず、表示回数やクリックの変化と合わせて見ます。
GA4では、利用者、セッション、表示回数がそれぞれ別のものを数えます。同じ人が複数回訪れたり、一回の訪問で複数ページを見たりするため、数字が一致しなくても異常とは限りません。また、現在のGA4では、問い合わせ送信など事業上重要な行動を「キーイベント」として扱います。何をキーイベントにするかは、自社で先に決めて計測する必要があります。
数字から違和感を見つけ、原因ではなく仮説を書く
数字に変化があっても、そこから直接原因を決めることはできません。次のように、複数の仮説と確認方法を並べます。
検索結果での表示自体が少ない
「需要がない」とすぐに断定せず、次の可能性を考えます。
- 記事のテーマと実際の検索語が合っていない
- タイトルや本文が検索する人の疑問とずれている
- テーマそのものの検索機会が小さい
- 公開から日が浅いなど、Googleに十分認識されていない
- 競合ページと比べて、その記事で読む理由が弱い
Search Consoleで実際に表示された検索語とページを確認し、記事本文がその疑問へ答えているかを実ページで読みます。表示回数は自社ページが検索結果へ出た回数であり、市場全体の月間検索数ではありません。
表示されているがクリックされない
候補は、タイトルが内容を伝えきれていない、検索意図とずれている、掲載位置が低い、競合の方が答えを明確に示している、サイトへの信頼材料が不足している、などです。
Search Consoleで検索語、ページ、CTR、平均掲載順位を同じ期間で確認します。そのうえで実際の検索結果と記事の冒頭を見比べます。CTRだけを見てタイトルを変えるのではなく、順位が低いのか、検索語と内容がずれているのかを先に切り分けます。
ページは見られるが、読まれていないように見える
考えられるのは、冒頭で期待と内容がずれている、文字や段落が読みづらい、欲しい情報へ到達しにくい、内容が十分でない、内部・テストアクセスが混ざっている、といったことです。
GA4の表示回数やエンゲージメント関連の数字だけで「読まれていない」とは断定しません。実際のページをスマートフォンとパソコンで開き、冒頭、見出し、リンク、表示速度を確認します。利用できる場合は、Clarityなどの行動データも補助にしますが、対象データがなければ想像で補いません。
記事は読まれているようだが、問い合わせにつながらない
サービスの対象が伝わっていない、問い合わせ案内が分かりにくい、記事の読者とサービスが合っていない、信頼材料が不足している、入力項目が多いなど、複数の仮説があります。キーイベントが0でも、需要がないとは限りません。そもそも問い合わせ送信を正しく記録できているか、案内リンクが動くか、フォームを最後まで使えるかも確認します。
これらはすべて「原因」ではなく「仮説」です。仮説には、確かめる方法を一行添えます。
仮説：検索語と記事の冒頭がずれている
確認：Search Consoleの検索語上位と、記事冒頭の答えを見比べる
仮説：問い合わせ導線が見つけにくい
確認：スマートフォンで記事を開き、案内までの位置とリンク動作を見る
分析は「仮説・検証・実施・再分析」までを一組にする
分析の基本サイクルは次のとおりです。
- 数字を見る
- 違和感や変化を一つ見つける
- 「なぜ？」を考え、複数の仮説を立てる
- Search Console、GA4、実ページなど別の情報で確かめる
- 根拠がある改善を一つ実施する
- 実施日と変更内容を記録する
- 同じ条件で結果を再確認する
- 次の仮説へ進む
たとえばCTRが低い時に、タイトル、冒頭、見出し、問い合わせ案内を一度に変えると、後で数字が変わっても何が影響したのか分かりません。最初は一つだけ変えます。変更前の数字、対象期間、変更日、変更内容、次に見る日を短く記録しておくと、記憶ではなく記録を基に話せます。
自社分析でlocal・test trafficを結果から外した例
アナデジラボ自身のアクセス状況を確認した際、流入元に既知のlocal・test環境からの参照が混ざっていることに気づきました。これはGA4の不具合という意味ではありません。テスト中に計測タグが動けば、そのアクセスも条件に応じて記録されます。
実際に行った判断の順番は次のとおりです。
流入元の数字を見る
↓
通常の読者流入とは考えにくい参照を見つける
↓
内部・テストアクセスではないかと仮説を立てる
↓
参照元と運用記録を確認する
↓
読者行動の分析には適さないと判断する
↓
結果の解釈から除外する
大切なのは、数字が記録されているからといって、すべてを見込み客の行動として数えないことです。流入が急に増えた時は、施策の成果だと考える前に、参照元、ページ、日時、社内作業や表示確認の有無を見ます。既知のlocal参照を外しても、別の内部アクセスが混ざっている可能性を解消できない場合は、判断範囲を狭めます。
データが少ない時は「判断しない」ことも分析
アナデジラボでは、この記事自身のデータも確認しました。Search Consoleの2026年8月21日から9月17日では、クリック0、表示6、平均掲載順位は約87.17でした。GA4の2026年8月24日から9月20日では、表示2、利用者1、セッション2、キーイベント0、平均セッション時間は約0.62秒でした。対象ページに結び付くClarityやBingの行も確認できませんでした。
この数字から「記事に需要がない」「読者がすぐ離れた」「この改善が必要」とは決められません。利用者1人の動きを典型的な読者行動として扱えず、内部アクセス混入の影響も完全には切り分けられないためです。そこで、この時点では本文や導線の改善施策を決めず、追加観測が必要だと判断しました。
これは何もしなかったのではありません。データから言えることと、まだ言えないことを分けた結果です。小規模サイトでは、一件のアクセスが割合を大きく動かします。割合だけを出すより、対象期間と元の件数を一緒に見る方が、判断できる範囲を把握しやすくなります。
AIは答えではなく、仮説候補を増やすために使う
データの行が多い時、AIは整理の補助に使えます。たとえば、傾向の要約、異常候補の抽出、複数仮説の提示、仮説ごとの確認方法、改善案候補、実施前後の比較表づくりです。
質問する時は、正解を一つ求めるのではなく、切り分け方まで依頼します。
表示回数は増えているのにCTRが低い。
考えられる原因を複数挙げ、
それぞれ何を確認すれば切り分けられるか教えてください。
断定せず、追加で必要なデータも示してください。
AIの回答は仮説候補です。データの期間、計測方法、サイトの変更履歴、実ページの内容をAIがすべて知っているわけではありません。提案された仮説を人が実ページと元データで確認し、実施する内容を一つ決め、結果を測ります。個人情報、認証情報、非公開の顧客情報は入力せず、利用するサービスと組織のルールも確認します。
AIへ分析を依頼する
↓
複数の仮説候補を得る
↓
人が元データと実ページを確認する
↓
改善を一つ決める
↓
実施日と内容を記録する
↓
同じ条件で再測定する
今日できる最初の一歩
まず一ページを選び、次の五行だけをメモしてください。
知りたいこと：
気になった数字と期間：
考えられる仮説：
仮説を確かめる別データ・実ページ：
まだ判断できないこと：
確認できた根拠があれば改善を一つだけ実施し、次に数字を見る日を決めます。根拠が足りなければ、無理に施策を作らず観測を続けます。
Googleアナリティクスを使うこと自体が目的ではありません。分析 → 仮説 → 検証 → 実施 → 再分析を繰り返し、数字を現場で確認するための手がかりとして使うことが目的です。
