集計しています 初回は 10 秒ほどかかることがあります
FEATURE ／ データの正しさ
「クエリが減った」の何割かは、減っていない。API が黙って切っている。
Search Console API は 50,000 行を超えた分をエラーなく捨てます。順位の単純平均は表示回数を無視して狂います。このダッシュボードは、上限を検知して期間を分割し、表示回数で重み付けした順位を出し、すべてのデータに欠落リスクを付けて保存します。
50,000行上限が黙って切る仕組み
Search Console API（Search Analytics）は、1日・1サイト・1検索タイプあたりの返却行数に 50,000 行の上限があります。クエリ×ページのように次元を組み合わせると、中規模サイトでも 28 日分の合計が上限を超えます。
問題は超えたときの挙動です。エラーは返りません。 上位 50,000 行が正常に返り、表示回数の少ない下位のクエリ・ページがそのまま消えます。取得側が行数を数えていなければ、欠けたことに気づけません。
この状態で先週と比べると、次のような誤読が起きます。
- 「ロングテールのクエリ数が減った」…… 実際は上限で切れただけ
- 「表示回数の合計が下がった」…… 下位が欠けた分だけ合計が小さく見える
- 「新規クエリが増えた」…… 先週は切れていた行が、今週は上位に入っただけ
検知 → 分割 → 重み付き再集計
検知
取得した行数を数え、上限の80%以上で「上限に近い」、50,000行で「上限到達」を記録する。
2 → 4 → 7 分割
上限到達なら期間を2分割して取り直す。まだ到達するなら4分割、7分割（週ごと）まで細かくする。
重み付き再集計
分割した結果を同じクエリ×ページで束ね、クリック・表示は合計、順位は表示回数で重み付けして戻す。
実測: onet.co.jp・180日
| 取得方法 | 取得行数 | 欠落リスク | 備考 |
|---|---|---|---|
| 分割なし（1回の取得） | 50,000 | 上限到達 | 上限に到達。下位のクエリ×ページが黙って切れている |
| 2 → 4 → 7 分割して再取得 | 71,323 | なし | +21,323行（+42.6%）を回復 |
分割しない取得では 50,000 行ちょうどで止まり、分割後は 71,323 行になりました。差の 21,323 行（+42.6%）は、分割しなければ「存在しない」ことになっていたクエリ×ページです。
ただし限界もあります。1日単位で 50,000 行を超える巨大サイトでは、7分割（1日ごと）でも全件は取れません。その規模では BigQuery 一括エクスポートが適切です（無期限蓄積）。
欠落リスク3段階の読み方
すべてのスナップショットに、取得時の行数から決めた欠落リスクを付けて保存します。画面の上部と MCP の応答（meta）の両方に出ます。
| 値 | 条件 | 読み方 |
|---|---|---|
| なし（none） | 取得行数が上限の80%未満 | 下位データの欠落はない。増減をそのまま論じてよい |
| 上限に近い（near） | 上限の80%以上 | 下位のクエリ・ページが欠け始めている可能性。下位の増減を論じない |
| 上限到達（hit） | 50,000行に到達 | 下位は確実に欠落。期間を分割して再取得する。「減った」と結論しない |
「上限に近い」でも上位のクエリ（表示回数が多いもの）は欠けていません。惜しい順位や低CTRのような上位側の判定は使えます。使えないのは「ロングテールが増えた・減った」「クエリ数の合計」といった下位側の話です。
AVG(position) が誤りである理由
複数のクエリ・ページ・期間をまとめるとき、順位を単純平均すると数値が狂います。表示回数10のクエリと10,000のクエリが同じ重さになるからです。
| クエリ（例） | 順位 | 表示回数 |
|---|---|---|
| クエリ A | 2 | 10,000 |
| クエリ B | 40 | 10 |
| 単純平均 AVG(position) | 21.0 | — |
| 表示回数で重み付け | 2.04 | — |
この例では、実際に検索者が目にした順位はほぼ2位です。単純平均の 21 位は、誰も見ていないクエリBに引きずられた数字で、何も表していません。
順位 = Σ(順位 × 表示回数) ÷ Σ(表示回数)
このダッシュボードと MCP ツールは、期間の合算・分割再集計・ページ単位のまとめ、すべてでこの式を使います。Looker Studio や自作 SQL で AVG(position) を使うと、ここが狂います。Search Console の画面自体は重み付きで正しく出しています。
匿名化クエリの注意
Search Console は、プライバシー保護のためごく少数の検索しかないクエリを匿名化し、クエリ別のデータからは除外します。サイト全体のクリック合計には含まれるので、次のズレが必ず出ます。
- 「クエリ別の合計」＜「サイト全体の合計」。差分が匿名化分
- ページ別の合計はクエリ別より大きい（ページ次元では匿名化されない）
- ロングテールが多いサイトほど差が大きく、数十%になることもある
これは上限の欠落とは別の現象で、分割しても回復しません。BigQuery 一括エクスポートでも匿名化クエリは同様に除外されます。クエリ別の合計を「全体」として報告しないでください。
「減った」と結論しない運用ルール
数値が下がったとき、原因を言う前に確認する順番です。BizFun の運用ルールをそのまま書いています。
- 欠落リスクを見る。 「上限に近い」「上限到達」なら、下位の増減は語らない。分割再取得の結果を待つ。
- 比較している2つの窓の欠落リスクが揃っているか。 前回「上限到達」、今回「なし」なら、増えたように見えるのは回復分。
- 合計はクエリ別かサイト全体か。 クエリ別の合計は匿名化分だけ小さい。全体はサイト合計で見る。
- 順位は重み付きか。 別ツールの数字と比べるとき、相手が単純平均なら比較にならない。
- 28日窓のズレを確認する。 週次スナップショットは21日重複している。「先週比」は7日分の入れ替わりでしかない。
- ここまで揃って初めて、 競合・自サイト変更・SERP機能の変化を疑う。
MCP ツールも同じルールで動きます。応答の meta に欠落リスクが「近い」「到達」で入っているとき、Claude は「クエリが減った」という結論を出しません（Claude から使う）。計算式の正本は 指標の定義 です。