アクセス解析の数字から、自社サイトで直す所を決めてみた：先に直すのは「測り方」だった

サイトを新しくしたあと、「どのページを直せば、お問い合わせが増えるのか」を数字で決めたくなります。クリーヴァも、2026年の夏にコーポレートサイトを作り直しました。公開から2か月がたったので、アクセス解析の数字を見て、次に直す所を決めることにしました。

結論から書くと、最初に直すのはページではなく、数字の測り方でした。見ていた数字には、自社サイト以外の記録が混ざっていました。そして、いちばん知りたい「お問い合わせ」が、そもそも記録されていませんでした。

この記事では、次のことを順に書きます。

• 何を、どう確かめたか
• 数字を分けて分かった4つのこと
• それでも数字から読めたこと
• 直す所と、その順番
• 同じ確認を自社で行うための手順

何を、どう確かめたか

使ったのは、Google アナリティクス 4（以下 GA4）です。対象の期間は、2026年7月24日から10月22日までの91日間です。

確かめたい問いは1つです。「お問い合わせを増やすには、サイトのどこを直せばよいか」。そのために、次の順で数字を見ました。

1. どこから来た人が、どのページに着いたか（流入元と、最初に開いたページ）
2. 着いた人が、どれくらい読んだか（滞在時間と、「エンゲージメントのあったセッション」の割合）
3. 読んだ人が、お問い合わせに進んだか

「エンゲージメントのあったセッション」は、GA4 の用語です。10秒以上続いた、2ページ以上見た、キーイベント（成果として数えるイベント）が起きた、のどれかに当てはまる訪問を指します（Google アナリティクス ヘルプ）。ざっくり言えば、「すぐに閉じられなかった訪問」です。

本当は、3つ目の「お問い合わせに進んだか」から逆にたどって、直すページを決めるつもりでした。ところが、1つ目の段階で数字が合わないことに気づきました。

分かったこと①：記録の3分の1は、自社サイト以外だった

91日間の訪問（セッション）は、合計で3,139回でした。サイトの規模からすると、思っていたより多い数字です。

そこで、記録がどのドメイン（ホスト名）で起きたかを分けてみました。

※ 1回の訪問が複数のホスト名にまたがることがあるため、合計は3,139と一致しません。

自社サイトの記録は、全体の約3分の2でした。残りの約3分の1は、別のメディア、開発中の画面、確認用のページ、そして実在しないアドレスでの記録です。

原因は、同じ計測の設定（GA4 のプロパティ）を、複数のサイトと開発環境で共有していたことです。開発者が手元で画面を確かめるたびに、その記録も同じ場所にたまっていました。

最後の「その他」には、admin.〜 や kibana.〜 のように、クリーヴァでは使っていないサブドメイン名が多く並んでいました。管理画面のありそうな名前を順に試すような並びで、人が見に来たとは考えにくい記録です。

このまま「サイト全体の訪問数」を見ていると、自社サイトの実力より5割ほど多く見積もることになります。 サイトを直したあとに数字が動いても、直した効果なのか、別のメディアや開発作業の影響なのかを区別できません。

数字が混ざる、よくある3つの原因

今回の混ざり方は、珍しいものではありません。サイトを作る側として、ほかの会社のサイトでも見かける原因を3つ挙げます。

1. 複数のサイトで、同じ計測の設定を使い回している：会社のサイトとオウンドメディア、キャンペーンのページなどを、同じ GA4 のプロパティで測っている。サイトごとの数字を見るには、毎回ホスト名で分ける必要があります。
2. 開発中や確認用の画面でも、計測のタグが動いている：本番と同じタグが、手元のパソコンや確認用のURLでも動いている。開発の作業が多い時期ほど、数字がふくらみます。
3. 実在しないアドレスでも、サイトが表示されてしまう：どんなサブドメインを打ち込んでも同じサイトが表示される設定だと、自動で巡回するプログラムが試したアドレスも、そのまま記録に残ります。

防ぎ方は、原因ごとに違います。1は、サイトごとに計測を分けるか、ホスト名で分けて見るルールを決める。2は、本番のドメインのときだけタグを動かす。3は、使っていないサブドメインでサイトを表示しない設定にする。どれも、サイトを公開する前に決めておけば、手間はほとんどかかりません。

分かったこと②：自社サイトの2割は、海外からの数秒の訪問だった

次に、creava.co.jp の2,067回だけを、流入元と国で分けました。

「直接」は、ブックマークやURLの直接入力など、どこから来たか分からない訪問です。

シンガポール、アメリカ、中国、ドイツ、イギリスからの直接の訪問を合わせると、428回ありました。自社サイトの訪問の約2割です。クリーヴァは国内の企業向けに仕事をしていて、英語のページもありません。滞在時間も十数秒以下で、ほとんどがすぐに閉じられています。

GA4 は、既知のボット（自動で巡回するプログラム）の訪問を自動で除外しています（Google アナリティクス ヘルプ）。それでも、知られていない自動の巡回や、監視のサービスなどは残ります。今回の海外からの訪問も、その一部だと考えています。ただし、1件ずつ確かめたわけではないので、「全部がボット」とは言い切れません。

ここで大事なのは、海外からの短い訪問が、平均の数字を大きく引き下げていることです。自社サイト全体の「エンゲージメントのあった割合」は44%（2,067回のうち908回）でした。日本からの検索の訪問だけで見ると65%になります。全体の平均だけを見て「読まれていない」と判断すると、直さなくてよいページまで直すことになります。

分かったこと③：お問い合わせが、1件も記録されていなかった

いちばん大きかったのは、これです。

91日間で、成果として数える「キーイベント」は0件でした。お問い合わせがなかったのではありません。お問い合わせを数える仕組みが、なかったのです。

クリーヴァのお問い合わせは、サイトの外にあるフォームのサービスで受け付けています。ヘッダーの「お問い合わせ」も、ページ下の「無料相談を申し込む」も、外部のフォームへ移動するリンクです。旧サイトにあった /contact/ のページも、2026年9月末に、外部のフォームへそのまま転送する設定に変えました。

この形だと、GA4 からは、利用者がフォームを送信したかどうかが見えません。見えるのは、せいぜい「お問い合わせのボタンを押して、サイトの外へ出た」ところまでです。

ところが、その「ボタンを押した」ことも記録されていませんでした。GA4 には、別のサイトへ移動するリンクのクリックを自動で記録する「拡張計測機能」の離脱クリックがあります（Google アナリティクス ヘルプ）。これが有効なら、外部のフォームへのクリックは click というイベントで残ります。今回の91日間には、click のイベントが1件もありませんでした。

皮肉なことに、旧サイトのお問い合わせのページがあったころは、少なくとも「お問い合わせのページを開いた回数」は分かっていました。91日間のうち、このページは175回表示されています。週ごとに見ると、9月28日から始まる週を最後に、記録が止まっています。外部のフォームへ転送するようにしたことで、利用者の手間は1つ減りましたが、サイトの側で数えられる数字も1つ消えていたのです。

つまり、サイトのどのページから、何人がお問い合わせのボタンを押したのかが分かりません。「お問い合わせが多いページ」から逆にたどって直す所を決める、という最初の計画は、この時点で使えなくなりました。

なお、せんせいAI の広告用のページだけは、ボタンのクリックやフォームの送信を、独自のイベントで記録しています。こちらは広告を始める前に準備したので、数字が残っています（くわしくは検索広告を始めて3日の記事に書きました）。会社全体のお問い合わせにも、同じ準備が必要でした。

分かったこと④：記事から別のサイトへ送った人数が分からない

10月22日に、PHPの脆弱性について解説した記事を公開しました。この記事では、より詳しい対応の手順を書いた SucSak の記事へ、本文の3か所からリンクしています。

公開した当日、この記事を最初に開いた訪問は118回ありました（うち検索からが112回）。話題になっていたテーマだったこともあり、新しい記事としては多い数字です。

では、そこから何人が SucSak の記事へ進んだのか。同じ日に、SucSak のページが「creava.co.jp から来た」と記録されたのは2回だけでした。

ただし、この2回が実際の人数とは限りません。ブラウザは、別のサイトへ移るとき、元のページのURLではなく、ドメイン（creava.co.jp）だけを伝えるのが標準の動きです（MDN）。そのため、どの記事から来たのかは、受け取った側では分かりません。加えて、前の項目で書いたとおり、外部へのクリックも記録されていません。

記事を「別のサイトへ送るための入口」として使うなら、送り出す側でクリックを数える必要があります。 今回は、それができていませんでした。

それでも、数字から読めたこと

測り方に問題はありましたが、分けて見れば読めることもありました。

検索から来た人は、よく読んでいる。 日本から検索で来た625回のうち、65%はすぐに閉じずに読み進めていました。平均の滞在時間は約3分25秒です。検索で来る人は、知りたいことがあって来ているので、合うページに着けば読まれます。比べると、同じ期間に検索広告から来た110回は、読み進めた割合が46%、平均の滞在時間は約1分でした。広告は、まだ自社を知らない人にも届くぶん、読まれ方が浅くなりやすいと考えています。広告の数字と自然な検索の数字は、混ぜずに別々に見る必要があります。

検索の入口は、ほぼトップページと最新の記事だけ。 検索から自社サイトに来た訪問のうち、最初に開いたページはトップページが299回で、ほぼ半分でした。次がPHPの記事の112回で、会社情報が続きます。それ以外の記事は、91日間でも1本あたり数回です。会社名やサービス名で探して来る人がほとんどで、困りごとを調べて記事に着く人は、まだ少ないということです。

話題になっているテーマは、公開した日から読まれる。 PHPの記事の118回は、公開から1日で集まった数字です。ふだんの記事が91日で数回なので、差がはっきりしています。毎日の記事の中に、その週に話題になっているテーマを入れる意味は、数字の上でも確かめられました。

直す所と、その順番

最初は「どのページを直すか」を決めるつもりでしたが、ページを直す前に、次の順で測り方を直すことにしました。この記事を書いた10月23日の時点では、まだどれも直していません。

1. 自社サイトの数字だけを見られるようにする

GA4 には、データフィルタという機能があります。社内のIPアドレスからの訪問や、開発者の確認用の訪問、特定のホスト名からの記録を除くことができます（Google アナリティクス ヘルプ）。

ただし、データフィルタは、作った時点より後のデータにしか効きません（同じヘルプ）。過去の数字は、レポートの上でホスト名を creava.co.jp に絞って見ることにします。あわせて、SucSak は別の計測に分けるか、少なくとも毎回ホスト名で分けて見るルールにします。

2. お問い合わせのボタンのクリックを記録し、成果として数える

外部のフォームの送信そのものは、GA4 からは見えません。そこで、サイトの中で確実に記録できる「お問い合わせのボタンを押した」ことを記録します。どのページの、どの場所のボタンだったかも残します。そのうえで、このイベントを GA4 のキーイベントに設定します。

フォームのサービス側に残る「実際の送信数」とは、月に1回、数字を突き合わせます。ボタンを押した数と送信の数の差は、フォームの入力で離れた人の数の目安になります。

お問い合わせのフォームが外部のサービスにある場合、測り方にはおもに3つの選び方があります。

クリーヴァでは、せんせいAI の広告用のページで3つ目のやり方を使っています。会社全体のお問い合わせは、まず1つ目から始めます。2つ目と3つ目は、使っているフォームのサービスで何ができるかを確かめてから決めます。

どの方法でも、サイトの数字だけで「申込の数」を確定させないことが大切です。計測は、広告ブロックの機能や、利用者の同意の設定によって、取りこぼしが出ます。正確な数は、フォームのサービス側の記録を正とし、サイトの数字は「どのページから来たか」を知るために使います。

3. 海外からの短い訪問を、分けて見る

ボットかどうかを1件ずつ判定するのは難しいので、まずは「日本からの訪問」に絞った見方を、毎週のレポートの基本にします。海外の訪問を消すのではなく、別の行で見ます。急に増えたときに、すぐ気づけるようにするためです。

4. 記事から外へ送った数を、送り出す側で数える

SucSak や事例のページなど、記事から外へ案内するリンクのクリックを記録します。どの記事の、どのリンクが押されたかが分かれば、どの書き方で次の記事へ進んでもらえるのかを比べられます。

後回しにしたこと

ページの見た目や文章を直すのは、1〜4が終わって、2〜4週間分の数字がたまってからにします。いまの数字のままページを直しても、直した効果を正しく測れないからです。

毎週見る数字も、あわせて決めた

測り方を直したあとに、毎週月曜に見る数字も決めました。数を絞ったのは、見る数字が多いと、変化に気づけなくなるからです。

最後の行は、判断に使う数字ではなく、異常に気づくための数字です。ここが急に増えたら、ほかの数字もいったん疑ってかかります。

同じ確認を、自社で行う手順

ここまでの確認は、GA4 の標準のレポートと、探索の機能だけでできます。所要時間は、慣れていれば1時間ほどです。自社のサイトでも、次の順に確かめてみてください。

1. ホスト名で分ける：レポートに「ホスト名」の項目を足し、自社のドメイン以外の記録がないかを見る。開発環境や別のサイトの記録が混ざっていないか。
2. 国と流入元で分ける：「国」と「デフォルト チャネル グループ」を並べ、海外からの直接の訪問が多くないかを見る。あれば、滞在時間を確かめる。
3. キーイベントが記録されているかを見る：お問い合わせや資料の請求が、キーイベントとして数えられているか。0件が続いていたら、「申込がない」のか「数えていない」のかを確かめる。
4. お問い合わせの仕組みを確かめる：フォームがサイトの中にあるか、外部のサービスか。外部なら、ボタンのクリックを記録しているか。
5. イベントの一覧を見る：click、scroll、file_download などの自動のイベントが記録されているか。どれも無ければ、拡張計測機能が使われていない可能性がある。
6. ここまで確かめてから、ページ別の数字を見る：最初に開いたページ、読まれた時間、次に進んだページ。

この順番にした理由は、今回の経験のとおりです。ページ別の数字を先に見ると、混ざった数字のまま判断してしまいます。

サイトを作り替えるときに、あわせて確かめたいこと

今回の問題の多くは、サイトを作り替えたときに生まれていました。これからサイトを新しくする会社は、公開の前に次のことを確かめておくと、あとで数字を疑う手間が減ります。

• 計測のタグは、本番のドメインでだけ動くか：確認用のURLや手元の開発環境の記録が、本番の数字に入らないか。
• お問い合わせを、どこで数えるか：フォームの置き場所を変えるなら、変えたあとにどの数字で申込を数えるかを、先に決めておく。
• 古いURLから、新しいURLへ転送されるか：検索結果やブックマークに残っている古いURLが、行き止まりになっていないか。クリーヴァでも、旧サイトのURLを新しいURLへ転送する設定を入れています。
• 転送したことで、消える数字はないか：転送先が外部のサービスなら、そのページで取れていた数字は取れなくなる。代わりの数え方を用意しておく。

サイトの作り替えは、見た目や文章に目が向きがちです。けれども、公開した日から正しく数字が取れていなければ、作り替えの効果を確かめることもできません。

この確認の限界

最後に、今回の確認で分からなかったことも書いておきます。

• 期間が短い：91日間で、途中にサイトの切り替えもありました。季節による増減は分かりません。
• ボットの判定はしていない：海外からの短い訪問をボットと断定はしていません。国と滞在時間から見た推測です。
• 検索の言葉は見ていない：どの言葉で検索されて来たかは、Search Console という別の道具で見る必要があります。今回は GA4 の数字だけを使いました。
• 記録されない訪問もある：広告ブロックの機能を使っている人などの訪問は、そもそも GA4 に記録されません。今回の数字は「記録された訪問」の中での比較です。
• お問い合わせの実数とは照らしていない：フォームのサービス側の送信数と GA4 の数字は、まだ突き合わせていません。

おわりに

アクセス解析は、開けば何かの数字が出てきます。そのため、数字が正しく測れているかを確かめないまま、ページの良し悪しを判断してしまいがちです。今回のクリーヴァの自社サイトも、そうなる手前でした。

直す所を探すときは、まず「この数字は、自分たちのサイトの、自分たちが知りたいことを測っているか」を確かめる。そのうえで、知りたいこと（多くの場合はお問い合わせ）を数える仕組みを、サイトを直す前に入れておく。今回の結論は、この2つです。

業務システムでも同じことが起きます。システムを入れたあとに「効果が出ているか」を確かめようとして、そもそも効果を測る数字を取っていなかった、ということは珍しくありません。何を数えれば効果が分かるかは、作る前に決めておくのが理想です。システムの効果の測り方については、DXと投資対効果（ROI）の考え方でも書いています。

1〜4を直したら、数字がどう変わったかを、あらためてこのコラムで報告します。