Search Console「一括データエクスポート」は必要?BigQuery課金の罠と無料API比較
作成日:

Search Console「一括データエクスポート」は必要?BigQuery課金の罠と無料API比較


論旨

Google Search Console(サーチコンソール)の左メニューにある「設定」を開くと、『一括データ エクスポート(BigQuery に自動的にエクスポートします)』 や 『クロールの統計情報(右上のエクスポート)』 という本格的な項目が並んでいます。「せっかく公式に用意されている機能だから、今のうちに設定しておかないと大切な検索データを逃してしまうのでは?」と迷ったことはないでしょうか。

結論からお伝えすると、個人ブログや数百〜数千記事規模の中規模サイトであれば、『一括データ エクスポート(BigQuery 連携)』の設定も『クロールの統計情報』の手動出力も一切不要 です。むしろ安易に BigQuery 連携を有効化すると、Google Cloud 側のクレジットカード課金登録が必須になり、得られるデータは無料の Search Console API と変わらないのに管理コストと誤課金リスクだけを抱え込むことになります。本記事では、当ラボ(現在公開 650記事)の実機画面と運用データをもとに、無料 API との決定的な違いと「本当に必要になる分岐点」をわかりやすく解説します。

合わせて読みたい深まる関連情報
対象となる方
  • Search Console の「設定」画面で 『一括データ エクスポート(BigQuery)』を見つけて、自分のブログでも設定すべきか迷っている方

  • 「BigQuery に出力すれば、画面では隠されている検索キーワード(匿名化クエリ)まで見えるようになる」という噂の真偽を正確に知りたい方

  • クレジットカード登録や従量課金の心配をせず、完全無料(0 円)のまま検索データやクローラー巡回状況を漏れなく把握したい方

結論:個人や中規模サイトにBigQuery連携は不要

まずは、今回確認した Search Console「設定 > 一括データ エクスポート」の実際の画面を見てみましょう。

Search Console「設定 > 一括データ エクスポート」のBigQuery連携設定画面

Search Console「設定 > 一括データ エクスポート」画面。Google Cloud プロジェクト ID の入力を求められる

この画面は、Search Console が毎日集計している検索パフォーマンスの生データを、Google Cloud の企業向け巨大データウェアハウスである 『BigQuery(ビッグクエリ)』 へ毎日自動で流し込むための設定窓口です。

質問するおじさん

設定画面に「パフォーマンス データを自動的にエクスポートします」なんて書いてあったら、「おっ、今のうちに繋いでおかんと過去のデータが消えて損するんじゃないか?」って焦るんよね。

解説ナビゲーター

そう感じる方はとても多いのですが、安心してください!個人〜中規模のサイトであれば、この画面は何も入力せず閉じたままで 100% 大丈夫なんです。

一括データエクスポートと無料APIの5大比較

なぜ通常のブログや中規模メディアに BigQuery 連携がいらないのか、Web 管理画面・無料の Search Console API・一括データ エクスポート(BigQuery) の 3 つを並べて比較すると理由が一目でわかります。

比較項目 Web 管理画面(標準) Search Console API(推奨) 一括データ エクスポート(BigQuery)
向いているサイト規模 数十記事の小規模ブログ 個人〜数千記事の中・大規模サイト 数万〜数百万ページの超巨大サイト
利用料金・クレカ登録 完全無料(登録不要) 完全無料(クレカ登録不要) Cloud 請求先(クレカ)登録が必須
取得できる行数上限 画面表示は最大 1,000 行 1 日あたり最大 50,000 行 行数上限なし(無制限)
過去データの遡り取得 直近 16 か月分 を閲覧可 設定初日に 過去 16 か月分 を即取得可 不可(設定完了日以降のデータのみ)
匿名化クエリの語句 非表示(合計値には含まれる) 非表示(page 合計値で真値取得可) 行は出るが 語句は空欄(NULL)
個人・中規模サイトにおける2つのデータ取得ルート比較
VS
おすすめ(完全0円)
無料 Search Console API + 手元保存
  • Google Cloud の 請求先(クレカ)登録なしで完全無料
  • 1 リクエスト 25,000 行ページング(1 日 5 万行上限)で中規模サイトなら 100% 全件取得
  • 導入したその日に 過去 16 か月分の履歴を一括回収 でき、手元の SQLite や CSV に永久保存可能
巨大サイト専用
一括データ エクスポート(BigQuery)
  • 無料サンドボックス不可で 有効な請求先アカウント(課金設定)が必須
  • 設定した日より前の 過去データは一切遡って入らない
  • 重い SQL 集計(日付絞り込み忘れ等)を回すと 従量課金が発生するリスク あり
1日5万行を超えない限り、無料APIで1行の取りこぼしもなく全件取得できます

当ラボのように公開記事数が 650本 規模のサイトであっても、1 日に発生する「ページ × 検索語句」の組み合わせは数千行ほどです。無料の Search Console API が持つ「1 日あたり最大 50,000 行」という枠の 10 分の 1 にも届かないため、わざわざ有料クラウド倉庫の BigQuery を借りる必要がまったくないのです。

設定前に知るべきBigQuery連携3つの落とし穴

「でも BigQuery にも無料枠があるなら、とりあえず繋いでおくだけなら損はないのでは?」と思うかもしれません。ところが実際に仕様を掘り下げていくと、個人ブロガーがハマりやすい 3 つの落とし穴 が潜んでいます。

無料サンドボックス不可!請求先登録が必須の壁

Google Cloud には、本来クレジットカードを登録しなくても無料で BigQuery を試せる「BigQuery サンドボックス」という仕組みがあります。しかし、Search Console の一括データ エクスポートをこの無料サンドボックスへ繋ごうとしても 稼働できません。

⚠️ なぜ無料サンドボックスでは使えず課金設定が必須なのか
  1. 60 日自動消滅ルールとの衝突 : クレジットカード未登録の BigQuery サンドボックスでは、作成されるすべてのテーブルと日付パーティションに 「60 日で強制的に自動削除される有効期限」 が課されます。一方、Search Console 側からは専用サービスアカウント(search-console-data-export@system.gserviceaccount.com)へ BigQuery ジョブユーザー と BigQuery データ編集者 の権限を与えて継続書き込みを行うため、公式手順でも 「課金が有効な(Billing enabled)Google Cloud プロジェクト」 が前提条件となっています。

  2. 無料枠(保存 10 GiB・クエリ 1 TiB)の裏にある SQL ミス課金 : BigQuery には毎月最初の 10 GiB までのデータ保存 と 1 TiB までのクエリ処理(オンデマンド分析) の無料枠があります。小〜中規模サイトなら保存容量自体は数年間無料枠に収まりますが、怖いのはデータを集計する時です。

  3. 日付フィルタ忘れのフルスキャン罠 : 出力される searchdata_url_impression テーブルは日付(data_date)ごとに分割されていますが、うっかり WHERE data_date = ... の絞り込みを忘れて SELECT * のような集計クエリを連発したり、Looker Studio などの外部ダッシュボードから毎回全期間を読み込ませたりすると、スキャン容量が一気に膨らみます(さらに 1 回のクエリにつき最低 10 MB 分の最小課金カウントが適用されます)。

一方、当ラボで使っている Search Console API であれば、Google Cloud プロジェクトを作る際も 請求先アカウント(クレジットカード)を一切紐付けない状態 で API キー(サービスアカウント JSON)を発行でき、1 円も請求される可能性がない物理的な安心感があります。

匿名化クエリの語句はBigQueryでも空欄のまま

ネット上の一部解説で誤解されやすいのが、「BigQuery へ一括エクスポートすれば、管理画面では隠されている『匿名化クエリ(プライバシー保護された珍しい検索語句)』まで出力される」という話です。

ここには技術的な言葉の綾があります。確かに BigQuery のテーブルには is_anonymized_query(匿名化クエリかどうかを示す真偽値)という列があり、TRUE の行もしっかり書き出されます。

しかし、is_anonymized_query が TRUE になっている行は、肝心の検索ワードが入った query 列が完全に空欄(NULL) の状態で出力される仕様です。つまり、BigQuery に課金設定をして繋いだとしても、「どんな秘密のキーワードで検索されたのか」という文字列が読めるようにはなりません。

質問するおばさん

ちょっと待って!文字が空欄で出てくるなら、「どのページに・匿名化クエリを含めて合計何回クリックがあったか」しか分からへんってこと?

解説ナビゲーター

その通りなんです!そして「匿名化クエリを含めたページごとの正確なクリック数・表示回数」であれば、無料の Search Console API で dimensions: ["page"](ページ単位集計)を指定するだけで、1 クリックのズレもなく 100% 取得できます。

当ラボで実際に API の生データを突合した際も、クリック全体の 89.6% がこの匿名化クエリから発生している事実を無料 API だけで完全に特定できました(詳しい仕組みと自動化コードは Search Console APIで自動診断|クリック9割が非開示クエリの罠と無料SEO監査術 で公開しています)。

過去16か月分は遡れず設定日以降しか貯まらない

3 つ目の落とし穴は、データの 時間軸 です。

一括データ エクスポートは、設定を完了して初回テストが通った後(通常 48 時間以内)から、毎日 1 日分ずつ「未来に向かって」データを積み上げていく仕組みです。設定するより前の過去データは 1 日分たりとも遡って書き出してはくれません。

それに対して無料の Search Console API なら、今日設定したその瞬間に 過去 16 か月分 のデータをさかのぼって一括取得できます。さらに取得したデータを自分の Mac 内の SQLite データベースや JSON・CSV ファイルへ保存していけば、クラウドに毎月倉庫代を払わなくても、手元の SSD に何年分でも無料で永久蓄積していけるのです。

逆にBigQuery連携を導入すべきサイトの明確な基準

では、どのようなサイトになった時に初めてこの「一括データ エクスポート」の出番が来るのでしょうか。迷った時は以下の 3 ステップで即座に判定できます。

自分のサイトにBigQuery連携が必要か見極める3ステップ判定
判定 1
1日5万行を超えるか

1 日の「URL × 検索語句」が 5 万行を超える巨大 EC・求人・辞書サイトなら BigQuery 必須です。

判定 2
社内BIで常時結合するか

社内の複数部署で GA4 や売上 DB と SQL 結合し、Looker Studio 等へ常時配信するなら有力です。

結論
無料API+手元保存で十分

数百〜数千記事のブログ・メディアなら、クレカ不要の無料 API で全件を安全に取得できます。

ステップ1・2に該当しない個人・中規模サイトは、すべてステップ3(無料API)が最適解です

Search Console の Web 管理画面は表が 1,000 行 で打ち切られてしまいますが、Search Console API(searchanalytics.query)は 1 リクエスト最大 25,000 行 のページ送り(startRow 指定)に対応しており、1 日・1 検索タイプあたり 50,000 行 まで無料で引き出せます。

1 日で 50,000 通りの異なる検索キーワードから表示・クリックが発生するというのは、推論ですが月間数百万〜数千万 PV クラスの大型ポータルサイトや全国規模の EC サイト領域です。そこまで育ってから BigQuery 連携をオンにしても遅くありません。

設定画面の「クロールの統計情報」も出力不要な理由

「設定」メニューを開くと、一括データ エクスポートのすぐ近くに 『クロールの統計情報』 という項目もあり、その画面の右上にも「⬇ エクスポート」ボタンが用意されています。こちらも実際の当ラボの画面で見てみましょう。

Search Console「設定 > クロールの統計情報」のクロールリクエスト1.39万回・平均応答時間481ミリ秒の画面

「設定 > クロールの統計情報」の実機画面。10月中旬以降、クローラー巡回が力強く跳ね上がっている

結論から言うと、この「クロールの統計情報」も普段はたまに画面を眺めるだけで十分であり、右上の「エクスポート」ボタンを押してダウンロードする必要はありません。

右上のエクスポートよりサーバー生ログが100倍正確

実は Search Console API には、この「クロールの統計情報」のグラフを一括取得する API エンドポイントが用意されていません(個別記事の最終巡回日時を調べる urlInspection API のみ)。そのため「画面から手動エクスポートしておいた方がいいのかな?」と思いがちですが、ここから出力される CSV は日別の合計回数や一部のサンプル URL リストに丸められた概要データだけです。

もし「どの記事に・何時何分に・どのクローラーが何回読みに来たか」を正確に調べたい時は、Search Console の統計エクスポートではなく、レンタルサーバー(エックスサーバー等)のサーバーパネルから取れる『生アクセスログ(access_log)』 を見る方が 100 倍正確だからです。

🔍 クロール統計エクスポートより『サーバー生ログ』が圧勝する理由
  • 全記事・全リクエストが 1 秒単位で残る : サンプル抽出ではなく、どの URL に 200(正常)や 301(転送)、404(未検出)を返したかが 1 件残らず記録されています。

  • ChatGPT や Claude の AI ボットも丸見えになる : Search Console のクロール統計には Google 系のボット(Googlebot や GoogleOther)しか載りませんが、サーバーの生ログなら OpenAI の GPTBot / OAI-SearchBot や Anthropic の ClaudeBot、Perplexity の巡回状況まで一括で把握できます(具体的な確認コマンドは Googlebot巡回診断・サーバー生ログ解析・URL検査 を参照してください)。

応答481ミリ秒と緑チェック「過去の問題」の見方

それよりも大切なのは、この「クロールの統計情報」の画面を サイトの健康診断モニター として正しく読むことです。上の当ラボの実機画面からは、以下の 3 つの嬉しいサインが読み取れます。

🩺 クロールの統計情報で確認すべき3つの健康サイン
  1. クロール リクエスト 1.39 万回と右肩上がりの波形 : 10 月中旬以降、記事の拡充と双方向内部リンクの整備に反応して、1 日最大 1,000 回超のペースで Google のボットが活発に巡回してくれています。

  2. OK (200) が 95%・平均応答時間 481 ミリ秒 : 海外(米国)にある Google クローラーからの太平洋往復の通信時間を含めても 0.5 秒未満(481 ミリ秒) で HTML を返し切っています。データベースの毎回生成をなくした Astro 静的サイト構成と、足回りの速い国内サーバー(エックスサーバー)の組み合わせがクローラーの快適さに直結しています。

  3. 「以前、ホストで問題が起きています」は緑チェックなら放置で OK : 一見するとドキッとする文言ですが、これは 過去 90 日以内に 1 回でも一時的な通信瞬断や設定変更中のエラー応答があると、90 日間だけ履歴として残る仕様 です。左端のアイコンが 緑色のチェックマーク になっていれば「現在は 100% 正常」という意味ですので、何もせず放置しておけば 90 日経過で自然に消えます(より詳しい 90 日ウィンドウの仕様は Search Consoleの更新が1週間〜10日止まる原因と「GoogleOther(29%)」の正体 で解説しています)。

ノルウェージャンフォレストキャット

海の向こうから読みに来るボットさんにも 0.48 秒でお返事できてるなら、よけいな有料クラウドなんて繋がんでも健康そのものでちぃ!

クローラーの応答速度を安定させつつ、いざという時に生アクセスログをすぐ取り出せる定番サーバー基盤としては、当ラボでも長年愛用している エックスサーバー(XServer) が鉄板です。仮にスタンダードプラン(12 か月契約等で月あたり約 1,000 円前後)を 1 日 24 時間稼働のインフラとして時間割りすると、推論ですが 1 時間あたりわずか約 1.4 円(1 日約 33 円) という缶コーヒー 1 本未満のコストで、高速応答と毎日の自動バックアップ・生ログ解析環境が手に入ります。

エックスサーバー(XServer)国内シェアNo.1 高速・高安定レンタルサーバー
🏆 稼働率99.99%以上|初期費用0円・独自ドメイン2つ永久無料・10日間無料お試し

エックスサーバー(XServer)国内シェアNo.1 高速・高安定レンタルサーバー

第5世代AMD EPYC™&全ストレージNVMe RAID10構成。WordPressクイックスタート対応はもちろん、Astro等の完全静的HTML高速配信の母艦としても抜群の安定性と緊急セキュリティ即応力を誇ります。

まとめ:過剰なクラウド課金を避け執筆に集中しよう

Search Console の設定画面にある本格的なメニューを見ると「全部オンにしないとプロっぽい分析ができないのでは」と不安になりますが、ツールの目的とサイズ感を知っていれば迷うことはありません。

📌 Search Console「設定」2大エクスポートの結論まとめ
  • 『一括データ エクスポート(BigQuery)』は設定不要 : クレジットカード(Cloud 請求先)登録が必須になるうえ、匿名化クエリの語句も空欄(NULL)のままです。1 日 5 万行を超えない個人〜中規模サイトなら、完全無料の Search Console API で過去 16 か月分も含めて 100% 取得できます。

  • 『クロールの統計情報』も手動エクスポート不要 : たまに画面を開いて「応答時間が数百ミリ秒で安定しているか」「ホストのステータス左端が緑チェックになっているか」を眺めるだけで十分です。詳しいボット巡回調査にはレンタルサーバーの生アクセスログを使いましょう。

  • 浮いた時間とお金は「一次情報の記事づくり」へ : 大企業向けのクラウド基盤の保守や課金監視に神経をすり減らすよりも、読者の悩みを解決する丁寧な記事を 1 本増やす方が、結果として Googlebot も AI 検索もずっと喜んで巡回してくれます。

最後に、「自分のブログの記事数やアクセス規模だと、無料 API をどう組むのが一番ラクか?」を手元の AI エディタ(VS Code / Antigravity / Claude Code 等)に診断させるためのコピペ用プロンプトを用意しました。安全設計や API 制限の読み飛ばしを防ぐため、実行時は軽量モデルではなく必ず 『Gemini 4 Argon』 または同等以上の最上位推論モデルを選んで相談してみてください。

🤖 読者環境向け・BigQuery要否&無料API設計相談プロンプト(Gemini 4 Argon 推奨)
以下の記事の判断基準を参考にして、私のサイト環境で Search Console のデータを無料かつ安全に自動取得・保存する最適な構成を診断してください。
参考URL: https://lab.chihouzakki.com/blog/review/search-console-bulk-data-export-bigquery-vs-free-api-guide/

【私の現在の環境】
・おおよその公開記事数:(例:150記事)
・月間の検索クリック数またはPV目安:(例:月3,000クリック)
・使っているPC環境:(例:Mac / Windows)
・サイト構成:(例:Astro / WordPress)

【AIへのお願い(いきなりコードを書かず、まず調査・計画から)】
1. 上記の規模において、BigQuery 一括データエクスポートが不要で無料 Search Console API で十分と言えるか検算してください。
2. Google Cloud で「請求先アカウント(クレカ)を紐付けず完全無料のまま」Search Console API 用のサービスアカウントを発行し、秘密鍵(JSON)を Git に絶対誤コミットさせない安全な保存手順を案内してください。
3. まずは私の現在のフォルダ構成を確認し、最小限のスクリプトで直近のページ別・クエリ別データを手元へ保存する計画を提示して、私の合意を得てから実装に進んでください。
質問するおじさん

なるほどなぁ。「設定できる場所がある=全部埋めないといけない」じゃないんじゃね。クレカ登録もいらん無料 API で十分じゃと分かって、胸のつかえがスッキリ取れたわい!

解説ナビゲーター

本当にそうですね!立派な機能ほど「超巨大サイト向けの業務機能」だったりするので、自分のサイトに合ったシンプルで無料の道具だけを選んで、身軽に楽しくブログを育てていきましょう!

こちらをじっと見つめるノルウェージャンフォレストキャット

むずかしい設定画面は閉じて、今日もゆっくり記事を書くでちぃ